Install Microsoft Store on Windows 10 and Windows 11 LTSC or IoT Enterprise systems that do not include it.
The PowerShell script downloads packages directly from Microsoft's Store delivery service. It installs Microsoft Store, Store Purchase App, Xbox Identity Provider, App Installer with winget, and their framework dependencies. You can also download packages for an offline installation.
Microsoft Store running on Windows 11 IoT Enterprise LTSC.
Open PowerShell and run:
irm https://raw.githubusercontent.com/Softhe/Store-LTSC/main/install.ps1 | iexAccept the UAC prompt if PowerShell is not already running as administrator. After installation, open Microsoft Store from the Start menu. Reboot first if this is a fresh LTSC or IoT Enterprise installation.
To read the script before running it, download install.ps1 and Install-Store.cmd into the same folder. Review the PowerShell script, then double-click Install-Store.cmd.
- Windows 10 or Windows 11, build 19041 or later. This includes LTSC 2021 and LTSC 2024. Older LTSC releases are below the script's minimum build.
- An x64, ARM64, or x86 system.
- Windows PowerShell 5.1 with FullLanguage mode. The script relaunches in Windows PowerShell if you start it in PowerShell 7, or in a 32-bit process on 64-bit Windows.
- Administrator rights to install packages. Download-only mode does not require elevation.
- For online downloads, access to
displaycatalog.mp.microsoft.com,fe3.delivery.mp.microsoft.com, and*.dl.delivery.mp.microsoft.com. The command above also needs access toraw.githubusercontent.com.
The minimum build check does not guarantee that every current Store package or app supports every Windows version.
To pass options when running the script from GitHub, use this form:
& ([scriptblock]::Create((irm https://raw.githubusercontent.com/Softhe/Store-LTSC/main/install.ps1))) -SkipWinget| Option | Effect |
|---|---|
-SkipWinget |
Skip App Installer and winget. |
-NoProvision |
Install for the current user without provisioning packages for other users. Administrator rights are still required. |
-DownloadOnly |
Download packages without installing them. |
-DownloadDir D:\StorePkgs |
Save downloads in this folder and keep them after installation. |
-Source Online |
Download packages from Microsoft. This is the PowerShell script's default. |
-Source Local -WorkDir D:\StorePkgs |
Install packages from this folder without downloading. |
-Source Auto -WorkDir D:\StorePkgs |
Use local packages if the folder contains a Store package. Otherwise, download them. |
-KeepDownloads |
Keep packages in the run's temporary download folder. The log shows its path. |
-DownloadTimeoutSeconds 1800 |
Set the time limit for each package download attempt. The default is 1800 seconds. |
-LogDir D:\StoreLogs |
Write logs to this folder. |
-WorkDir defaults to the script's folder when running a saved copy. The command launcher uses -Source Auto by default and passes through any options you supply.
On a Windows machine with internet access, download the packages:
& ([scriptblock]::Create((irm https://raw.githubusercontent.com/Softhe/Store-LTSC/main/install.ps1))) -DownloadOnly -DownloadDir D:\StorePkgsDownload-only mode selects packages for the downloading machine's architecture and Windows build. Prepare the folder on a machine with the same architecture and Windows version as the offline target.
Save install.ps1 and Install-Store.cmd in D:\StorePkgs, alongside the downloaded packages. Keep the generated store-packages.json manifest in the folder. Copy the folder to the target machine, then double-click Install-Store.cmd.
When a manifest is present, the script checks the target architecture, requested apps, file sizes, SHA-256 hashes, and Microsoft signatures before installation. Legacy folders without a manifest still work, but do not receive those independent hash and Microsoft-signer checks.
You can also run the saved script from an elevated Windows PowerShell window:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File D:\StorePkgs\install.ps1 -Source Local -WorkDir D:\StorePkgsIf you have license XML files, put them beside the packages and name them <PackageFamilyName>.xml. For example, use Microsoft.WindowsStore_8wekyb3d8bbwe.xml for the Store. Without a matching license file, the script provisions packages with -SkipLicense.
In online mode, the script looks up the apps in Microsoft's Store catalog and requests package metadata from the Store delivery service. It selects app packages by the service's package rank, then version and architecture. It downloads the selected apps first, reads the dependencies declared in their manifests, and downloads only those frameworks, using the newest offered version for each architecture. Frameworks for older app versions or unused architectures are not downloaded. Local folders follow the same rule: frameworks that no app declares are skipped. Apps you later install from Microsoft Store bring their own dependencies.
For each download, the script checks the file size and the hash supplied by Microsoft over HTTPS. It uses SHA-256 when available and falls back to SHA-1. It also requires a valid Microsoft Corporation code signature before replacing the destination file. Failed attempts remove their temporary files, and the script retries before reporting a failure.
For local packages, the script reads identities and dependencies from package manifests. It filters unsupported architectures and Windows versions before selecting apps. Missing Microsoft Store dependencies and framework dependency cycles stop the run before installation. A companion app with missing dependencies is skipped and reported as a partial failure.
The script installs frameworks in dependency order, followed by Microsoft Store and the companion apps. By default, it provisions packages in the Windows image and registers them for the current user. -NoProvision skips provisioning. Missing requested companion apps produce a partial-failure result, including in download-only mode.
Windows cannot deploy an older copy of a framework that is already present. When the same framework is already provisioned or registered at the same or a newer version, the script skips that step. If provisioning rejects an older framework because a newer one is installed, the script logs a warning and defers the decision to verification.
After installation, the script asks Windows for the result. It confirms that each installed app is registered for the current user with status Ok. When provisioning, it also confirms that each app is provisioned and that every dependency is provisioned at the required version for new users. Anything not confirmed is a partial failure, and the final summary lists every failure by name.
When run as SYSTEM, such as through Intune, SCCM, or MDT, the script only provisions packages. Windows registers them for users at sign-in. Do not combine SYSTEM execution with -NoProvision.
Each run uses a separate temporary download folder. The script verifies ownership before deleting that folder when installation finishes. -KeepDownloads, download-only mode, and a custom -DownloadDir keep the packages.
If the script needs to relaunch, it runs a snapshot of the same executing revision and preserves the supplied options.
The online downloader relies on an undocumented Microsoft service. Changes to that service can break downloads. Local mode uses the packages you have already saved.
The console shows a short summary of the run: one line per package with its status (OK, SKIP, WARN, or FAIL), the verification results, and the outcome with its exit code. Problems are listed again at the end. The log file keeps every step with timestamps, including package file names and complete error messages.
The script prints its log path when installation starts and again at the end. Saved copies normally write logs to Logs inside the working folder. When run through the online command, or if that folder is not writable, logs go to %TEMP%\StoreInstall-Logs.
If Microsoft Store does not open, reboot after a fresh Windows installation, then check the installation log. You can also check Event Viewer under Applications and Services Logs > Microsoft > Windows > AppXDeployment-Server.
For download failures, check access to the Microsoft domains listed in the requirements and review any proxy or firewall restrictions.
| Code | Meaning |
|---|---|
| 0 | Completed successfully. |
| 1 | Administrator rights are missing, or elevation was declined or unavailable. |
| 2 | Windows build is below 19041. |
| 3 | PowerShell is not in FullLanguage mode. |
| 4 | A required package or dependency is missing, incompatible, or invalid. |
| 5 | A requested app is unavailable, an installation or provisioning step failed after the Store step succeeded, or verification could not confirm a companion app or a new-user dependency. Download-only sets can also be incomplete. |
| 6 | The Store installation or provisioning step failed, or the Store is not registered for the current user afterwards. |
| 7 | A fatal error or invalid configuration stopped the run. |
| 8 | Package lookup, download, or verification failed. |
When run through irm | iex, the script returns the result in $LASTEXITCODE and leaves the PowerShell window open. Early checks, such as a rejected language mode or Windows build, can stop the script before it creates a log.
See installer reliability and validation for offline manifest details, regression test commands, and the remaining LTSC installation qualification steps.