From 1866d176a0bbf2e56bd685b775e3ce8043348785 Mon Sep 17 00:00:00 2001 From: Roy <59626501+RDMacLachlan@users.noreply.github.com> Date: Wed, 26 Aug 2026 12:19:32 -0700 Subject: [PATCH 1/2] Document MSIX deployment from SYSTEM context Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b1fc3d9b-9b30-4b7d-930d-615894e9c9df --- .../managing-your-msix-deployment-overview.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/msix-src/desktop/managing-your-msix-deployment-overview.md b/msix-src/desktop/managing-your-msix-deployment-overview.md index aa9583de..b9344ad4 100644 --- a/msix-src/desktop/managing-your-msix-deployment-overview.md +++ b/msix-src/desktop/managing-your-msix-deployment-overview.md @@ -1,7 +1,7 @@ --- description: This article provides all the details you need to manage deploying your MSIX applications in an enterprise and retail environment. This article is targeted at enterprise and IT Pros. title: Manage your MSIX deployment Overview -ms.date: 04/15/2026 +ms.date: 08/26/2026 ms.topic: concept-article keywords: windows 10, deployment, msix ms.assetid: @@ -16,6 +16,20 @@ In order to successfully deploy MSIX, you need to consider the following: * What dependencies do I have? * How will I provide the best support for my customer? +## Choose a deployment mechanism for the execution context + +MSIX package registration is per user. Registration creates user-specific package state and makes the package's applications available in that user's session. A package can also be staged on the device without being registered, and a package family can be provisioned so that Windows registers the latest staged package for users. + +The LocalSystem account, also shown as **SYSTEM**, can't have packages registered. A process that runs as LocalSystem therefore can't use a per-user deployment mechanism to install an MSIX package for the signed-in user. This limitation commonly affects services and device-context management agents. + +| Goal | Execution context and supported mechanism | +| --- | --- | +| Install for the current user | Run the [App Installer app](../app-installer/app-installer-root.md), [Add-AppxPackage](/powershell/module/appx/add-appxpackage), or a Package Manager add operation in that user's interactive context. These mechanisms stage and register the package for the caller. Don't run them as LocalSystem with the expectation that they register the package for another user. | +| Make the package available to users on a device | From an elevated administrator or LocalSystem context, use [Add-AppxProvisionedPackage](/powershell/module/dism/add-appxprovisionedpackage) or the corresponding [DISM app package servicing command](/windows-hardware/manufacture/desktop/dism-app-package--appx-or-appxbundle--servicing-command-line-options). Provisioning stages the package and adds its package family to the provisioned list. Windows registers the latest applicable staged package for each user, other than LocalSystem, at sign-in. | +| Stage package files only | Use a deployment API stage operation, such as [StagePackageAsync](/uwp/api/windows.management.deployment.packagemanager.stagepackageasync). Staging is machine-wide, but staging alone doesn't make the package's applications available to a user; registration or provisioning is still required. | + +If a management tool runs in device or system context but the deployment must remain per user, configure the tool to run the install in the target user's context. Otherwise, use provisioning for the all-users experience. For more information about the relationship between staging, registration, and provisioning, see [Preinstalling packaged apps](deploy-preinstalled-apps.md) and [MSIX per-user versus all-users deployment](https://devblogs.microsoft.com/insidemsix/msix-per-user-vs-all-users/). + ## Who is my customer? How you deploy often depends on who is your customer and your role as a developer or administrator. It is important to identify your role to know what tools to use. From 06aa1cb7783cd7c7a9349a563a3c3bdace5b8975 Mon Sep 17 00:00:00 2001 From: Roy <59626501+RDMacLachlan@users.noreply.github.com> Date: Thu, 27 Aug 2026 09:57:04 -0700 Subject: [PATCH 2/2] Refine LocalSystem deployment guidance Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- .../desktop/managing-your-msix-deployment-overview.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/msix-src/desktop/managing-your-msix-deployment-overview.md b/msix-src/desktop/managing-your-msix-deployment-overview.md index b9344ad4..6ce67876 100644 --- a/msix-src/desktop/managing-your-msix-deployment-overview.md +++ b/msix-src/desktop/managing-your-msix-deployment-overview.md @@ -1,7 +1,7 @@ --- description: This article provides all the details you need to manage deploying your MSIX applications in an enterprise and retail environment. This article is targeted at enterprise and IT Pros. title: Manage your MSIX deployment Overview -ms.date: 08/26/2026 +ms.date: 08/27/2026 ms.topic: concept-article keywords: windows 10, deployment, msix ms.assetid: @@ -24,11 +24,11 @@ The LocalSystem account, also shown as **SYSTEM**, can't have packages registere | Goal | Execution context and supported mechanism | | --- | --- | -| Install for the current user | Run the [App Installer app](../app-installer/app-installer-root.md), [Add-AppxPackage](/powershell/module/appx/add-appxpackage), or a Package Manager add operation in that user's interactive context. These mechanisms stage and register the package for the caller. Don't run them as LocalSystem with the expectation that they register the package for another user. | -| Make the package available to users on a device | From an elevated administrator or LocalSystem context, use [Add-AppxProvisionedPackage](/powershell/module/dism/add-appxprovisionedpackage) or the corresponding [DISM app package servicing command](/windows-hardware/manufacture/desktop/dism-app-package--appx-or-appxbundle--servicing-command-line-options). Provisioning stages the package and adds its package family to the provisioned list. Windows registers the latest applicable staged package for each user, other than LocalSystem, at sign-in. | +| Install for the current user | Run the [App Installer app](../app-installer/app-installer-root.md), [Add-AppxPackage](/powershell/module/appx/add-appxpackage), or [`PackageManager.AddPackageAsync`](/uwp/api/windows.management.deployment.packagemanager.addpackageasync) in that user's interactive context. These mechanisms stage and register the package for the caller. Don't run them as LocalSystem with the expectation that they register the package for another user. Check the selected API overload's requirements before calling it. Packaged callers need the applicable restricted package-management capability; an unpackaged full-trust caller is still subject to deployment permissions and registers the package for its own user context. | +| Make the package available to users on a device | From an elevated administrator or LocalSystem context, use [Add-AppxProvisionedPackage](/powershell/module/dism/add-appxprovisionedpackage) or the corresponding [DISM app package servicing command](/windows-hardware/manufacture/desktop/dism-app-package--appx-or-appxbundle--servicing-command-line-options). Provisioning stages the package and adds its package family to the provisioned list. Windows registers an applicable staged package when registration is initialized for a user. Provisioning doesn't register a package for LocalSystem. A user who previously removed the package might not receive it again through regular reprovisioning; for that scenario, see [Force Provisioning](deploy-preinstalled-apps.md#force-provisioning). | | Stage package files only | Use a deployment API stage operation, such as [StagePackageAsync](/uwp/api/windows.management.deployment.packagemanager.stagepackageasync). Staging is machine-wide, but staging alone doesn't make the package's applications available to a user; registration or provisioning is still required. | -If a management tool runs in device or system context but the deployment must remain per user, configure the tool to run the install in the target user's context. Otherwise, use provisioning for the all-users experience. For more information about the relationship between staging, registration, and provisioning, see [Preinstalling packaged apps](deploy-preinstalled-apps.md) and [MSIX per-user versus all-users deployment](https://devblogs.microsoft.com/insidemsix/msix-per-user-vs-all-users/). +If deployment must remain per user, configure the management tool to run in the target user's context. Otherwise, use provisioning to make the package available for per-user registration; provisioning isn't machine-wide package registration. For more information about the relationship between staging, registration, and provisioning, see [Preinstalling packaged apps](deploy-preinstalled-apps.md) and [MSIX per-user versus all-users deployment](https://devblogs.microsoft.com/insidemsix/msix-per-user-vs-all-users/). ## Who is my customer? How you deploy often depends on who is your customer and your role as a developer or administrator. It is important to identify your role to know what tools to use.