Tracking: MSIX packaging gaps for PowerShell 7

PowerShell 7 is moving to MSIX packaging as part of the inboxing initiative. This issue tracks all known gaps between MSIX-packaged PS7 and the full capability set customers depend on today.

Each sub-issue below is a discrete gap with its own engineering scope. This issue will remain open until all blockers are resolved.

🔴 Blocker — System Context: `pwsh` invisible to automation

MSIX packages register per-user only. The SYSTEM account, LocalSystem, and service identities cannot locate or invoke pwsh, breaking any automation that doesn't run as an interactive user.

[NEW] PS7-packaged: pwsh not discoverable in SYSTEM / LocalSystem context #27562 — PS7-packaged: pwsh not discoverable in SYSTEM / LocalSystem context
Covers: scheduled tasks as SYSTEM, Windows Services, MDM scripts (Intune/ConfigMgr), deployment agents.
[NEW] PS7-packaged: WinRM / PowerShell Remoting broken under MSIX #27563 — PS7-packaged: WinRM / PowerShell Remoting broken under MSIX
The WinRM plugin (pwrshplugin.dll) has ACL and registration requirements incompatible with the per-user MSIX model.

🔴 Blocker — DISM API: Windows Capability commands fail from PS7

Add-WindowsCapability, Get-WindowsOptionalFeature, and related DISM cmdlets fail with "Class not registered" when called from MSIX-packaged PS7. This breaks on-device setup and configuration scripts for OpenSSH, WSL, App SDK, and similar.

[EXISTING] Get-WindowsOptionalFeature -Online fails on PowerShell from MSIX installation - [Get-WindowsOptionalFeature: Class not registered] #13866 — Get-WindowsOptionalFeature -Online fails on MSIX PS7

🟡 Enterprise Configuration: PS7 cannot write its own config

$PSHome is read-only under MSIX. Session configuration, machine-wide profiles, updatable help, and any tooling that writes to PS7's home directory fails with access denied or silently does nothing.

Solution substrate: an admin-writable, all-users-readable per-machine data store ("MachineFolder"). Design and rollout:

[NEW] [Design] MachineFolder: a per-machine writable data store for MSIX-packaged PowerShell #27697 — [Design] MachineFolder: a per-machine writable data store for MSIX-packaged PowerShell — shared mechanism; system-wide config relocation implemented in PR Place System-Wide Config in the Machine Folder for MSIX Packages #27632.
[EXISTING] Some cmdlets and config require writing to $PSHOME\SessionConfig folder #9278 — Register/Set-PSSessionConfiguration write .pssc to $PSHome\SessionConfig — narrowed to the SessionConfig write-location (WinRM/remoting activation is tracked in PS7-packaged: WinRM / PowerShell Remoting broken under MSIX #27563).
[NEW] PS7-packaged: $profile.AllUsersAllHosts not writable by administrators #27564 — PS7-packaged: $profile.AllUsersAllHosts not writable by administrators
Admins cannot write the machine-wide profile — a common enterprise configuration pattern.
[NEW] PS7-packaged: Update-Help -Scope AllUsers fails under MSIX ($PSHOME read-only) #27699 — PS7-packaged: Update-Help -Scope AllUsers fails under MSIX ($PSHome read-only)
[NEW] PS7-packaged: provide a cmdlet to export the fully merged / effective configuration #27698 — PS7-packaged: provide a cmdlet to export the fully merged / effective configuration

🟡 Server Core

MSIX packages cannot register/activate on Windows Server Core. See #27610 for root cause and fix direction.

PS7-packaged: Server Core cannot register/activate MSIX packages #27610

🟢 Other confirmed gaps (tracked, not on critical path)

[EXISTING] Provide a way to associate .ps1 files with PowerShell installed via .msixbundle #27277 — .ps1 file association broken with MSIX install
[EXISTING] Return a more actionable error description when the user attempts to write to an MSIX-installation's root. #25733 — No actionable error when writing to MSIX root (silent failure → should be a clear error)

Status

Gap	Status
SYSTEM / LocalSystem context	In progress
WinRM / Remoting	In progress
DISM (Add-WindowsCapability)	In progress
MachineFolder data store (#27697)	In progress (config in PR #27632)
SessionConfig `.pssc` location (#9278)	Under investigation
AllUsersAllHosts write access (#27564)	Under investigation
Updatable help AllUsers (#27699)	Not started
Export effective config cmdlet (#27698)	Not started
.ps1 file association (#27277)	Not on critical path
Silent write error (#25733)	Not on critical path
Server Core MSIX activation (#27610)	In progress

We are committed to resolving the blocker gaps before PS7 ships as the inbox shell. Updates will be posted to each individual issue as progress is made.

To have lack of Server Core support and incompatibility with Group Managed Service Accounts added do issues need opened?

If I may add here: It's important that existing pwsh processes are not killed when the MSIX package is updated (that is, when there is a version upgrade), especially since administrators will have less control over when updates are applied.

Jason Helmick (@theJasonHelmick)

Jason Helmick (@theJasonHelmick) realistically this should all be tracked in a project as well

Can we add another gap here

The newly added Microsoft Enterprise App catalog for Intune, the managed application for Powershell Core is still using the MSI (this is separate from the store deployment version in intune and manually registered win32 installs)

So Microsoft will need to update/approve changes to that method too at some point

Install command
"%SystemRoot%\System32\msiexec.exe" /i "PowerShell-7.5.4-win-x64.msi" /qn

Uninstall command
"%SystemRoot%\System32\msiexec.exe" /X {E8159677-ACF8-4D64-9D36-5C36B8BBEA39} /qn

Thanks

Adding some remarks from #27213 for housekeeping and consolidation. Thanks for creating this thread and adding this to the OP

Here are some side-effects this change brings:

Affected OS: All supported versions of Windows Server, Windows and Azure Stack HCI OS (Azure Local).

Winget:
No update path from msi to msix using winget. Winget has no logic that it would remove the msi to replace it with MSIX when upgrading the package. Removing a package is not covered by the dependency logic winget already has, it can just add packages beforehand.
Please consider to consult with winget PM about this change. This change will break deployment logic and causing regressions, status quo.

adding to "Blocker — DISM API: Windows Capability commands fail from PS7":
It is not necessarily the API but how the DISM PowerShell works and how MSIX is limited in terms of permissions.

It's identified that some modules, such as Windows and Windows Server inbox DISM module causing a regression with the MSIX. method.
Execution will fail because of access / permission issues. To my knowledge this is by-design of MSIX.
It is not only the Get-WindowsOptionalFeature that is affected. There are more commands from DISM module affected, such as:
Repair-WindowsImage.

While, as Windows Server MVP I could file a feature request for updating dism module, also adding missing commands/parameters, unlikely such update will happen in time and alignment of this change. Also backports need extended time.

This is the very reason that I don't like .msix installers.
I had to compile a few various packages (including PowerShell itself) from source just to get around this problem.
I hope this gets sorted soon.

If I may add here: It's important that existing pwsh processes are not killed when the MSIX package is updated (that is, when there is a version upgrade), especially since administrators will have less control over when updates are applied.

Packages can declare <uap17:UpdateWhileInUse>defer</> to defer updates while they're running. Terminal and others user this.

And same can be specified for a specific deployment operation (regardless what's in the manifest).

If the package is in use and this is defer/true, the deployment operation succeeds but the work is deferred until the next opportunity (e.g. after the running process(es) quit).

https://learn.microsoft.com/uwp/schemas/appxpackage/uapmanifestschema/element-uap17-updatewhileinuse

https://learn.microsoft.com/uwp/api/windows.management.deployment.addpackageoptions.deferregistrationwhenpackagesareinuse

One possible gap or at least change to note is how updates are handled.

We utilise WSUS to control updates for PowerShell 7, when installing via the MSI there is an option to update via Windows Update / WSUS.

How does this work with an MSIX?
AFAIK they will update using the Windows Store infrastructure and if so then we will lose our current controls? (Without disabling updates for all store apps)

Nick Ireland (@nixtar)

Nick Ireland (@nixtar) Microsoft Store only handles updates of MSIX PowerShell if you install it via the Microsoft Store. If you manually download and install the published *.msixbundle release packages, updates are your responsibility.

AFAIK, there is no automated update process for MSIX installed this way; you'll need to monitor and install updates yourself.

Please try running the winget upgrade command.

I noticed today that Winget will not list PowerShell via the source 'msstore' seperately anymore.
The source 'winget' will install the MSIX.

How did I find out about this?
When I tried to upgrade the MSI-installed version, it no longer got stuck, but correctly reported that another installer version had been used, and advised me to remove and reinstall.

As of today noticed that winget will not enlist PowerShell via source msstore but the regular winget source will install the msix.

Could you please rephrase that?

Not a blocker in any way but one issue I've recently encountered with MSIX packaged PowerShell is no longer being able to debug binary modules for PowerShell in VSCode. This probably affects other IDEs like Visual Studio or Rider but I have not tested them.

Ultimately what is happening is the C# attach/run debugger tries to load mscordbi.dll, mscordaccore.dll, and maybe other .NET runtime dlls, that is shipped with PowerShell. These dlls are present but under C:\Program Files\WIndowsApps\$PowerShellPackageName\ which only grants executable rights to processes with the MSIX package identifier attribute. As the C# debug server process does not have this attribute it fails to load those dlls.

The only two workarounds I know are:

Don't use the MSIX PowerShell as the process hosting the binary module being debugged
Use Invoke-CommandInDesktopPackage to launch VSCode under the PowerShell package identity

To use that cmdlet to launch VSCode you need to do the following:

if (Get-Process -Name Code -ErrorAction Ignore) {
    throw "Existing VSCode processes are running, please close them all before trying again"
}

$pkg = Get-AppxPackage Microsoft.PowerShell

$invokeParams = @{
    # Corresponds to the Application Id for pwsh.exe in the MSIX manifest
    # https://github.com/PowerShell/PowerShell/blob/9337fa14110c76f05c3222ac141ad72a27abf37a/assets/AppxManifest.xml#L44
    AppId = 'App'
    PackageFamilyName = $pkg.PackageFamilyName
    Command = 'code'
    PreventBreakaway = $true
}
Invoke-CommandInDesktopPackage @invokeParams

Invoke-CommandInDesktopPackage will only work if there are no existing VSCode processes running so you need to ensure that any VSCode instance is closed before running this.

Once VSCode is running it now has the required access token to load those dlls which the C# debug server will inherit.

If I find any other workarounds I'll edit this comment.

Nick Ireland (@nixtar) Microsoft Store only handles updates of MSIX PowerShell if you install it via the Microsoft Store

Slightly incorrect. Store only scans your PC for Store-signed MSIX packages. Doesn't matter how the package gets delivered to the PC -- Store, winget, Intune, sneakernet, ... -- that that what's on the PC is Store signed.

It's not unusual for developers to submit their package to the Store, then once approved they download the signed .msix package(s) and post on a webserver or other distribution channel in addition to (or instead of) Store distribution. APPDATA.EXE 3.2.0 is one such example :-)

Slightly incorrect. Store only scans your PC for Store-signed MSIX packages. Doesn't matter how the package gets delivered to the PC -- Store, winget, Intune, sneakernet, ... -- that that what's on the PC is Store signed.

I would add that we're working on more documentation about update mechanism(s) and the controls available to admins. Please hold tight for this.

Could you please rephrase that?

it is more understandable now?

Could you please rephrase that?

it is more understandable now?

Yes. That's a very serious problem...

Nick Ireland (@nixtar) Microsoft Store only handles updates of MSIX PowerShell if you install it via the Microsoft Store

Slightly incorrect. Store only scans your PC for Store-signed MSIX packages. Doesn't matter how the package gets delivered to the PC -- Store, winget, Intune, sneakernet, ... -- that that what's on the PC is Store signed.

It's not unusual for developers to submit their package to the Store, then once approved they download the signed .msix package(s) and post on a webserver or other distribution channel in addition to (or instead of) Store distribution. APPDATA.EXE 3.2.0 is one such example :-)

This is really good to know!

I've gone hunting for documentation about how this mechanism works in the past as we have run into MSIXs that do update via the store ( Powershell's MSIXs from this repo for eg ) and ones that do not.

From our prospective (very large education environment with ~280k windows clients and thousands of windows servers) this is still a gap as we lose control of the version (without disabling the stores auto updates completely).

We have our own layers of governance when it comes to patching/supporting applications in our environment that require us to be able to delay or even skip versions where required.

Perhaps a "non store signed" version of the MSIX's could be a workaround so we can opt to patch by manually repackaging/pushing the target version. Might also cause confusion so the documentation around this will need to be carefully articulated.

#27603 would be another blocker. Codex's sandbox cannot run in elevated mode because it uses a different user that doesn't have access to %LOCALAPPDATA% where the pwsh.exe app execution alias for the MSIX package is.

Navigation Menu

Repository navigation

Tracking: MSIX packaging gaps for PowerShell 7 #27565

🔴 Blocker — System Context: `pwsh` invisible to automation

🔴 Blocker — DISM API: Windows Capability commands fail from PS7

🟡 Enterprise Configuration: PS7 cannot write its own config

🟡 Server Core

🟢 Other confirmed gaps (tracked, not on critical path)

Status

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking: MSIX packaging gaps for PowerShell 7 #27565

Description

🔴 Blocker — System Context: pwsh invisible to automation

🔴 Blocker — DISM API: Windows Capability commands fail from PS7

🟡 Enterprise Configuration: PS7 cannot write its own config

🟡 Server Core

🟢 Other confirmed gaps (tracked, not on critical path)

Status

Activity

JAK1047 commented on Jun 5, 2026

MisterSausage commented on Jun 16, 2026

kilasuit commented on Jun 20, 2026

BlackV commented on Jul 7, 2026

Karl-WE commented on Jul 17, 2026

khaledJ-hash commented on Aug 3, 2026

DrusTheAxe commented on Aug 10, 2026

nixtar commented on Aug 14, 2026

marshallwp commented on Aug 17, 2026

Karl-WE commented on Aug 17, 2026

God-damnit-all commented on Aug 18, 2026

jborean93 commented on Aug 19, 2026

DrusTheAxe commented on Aug 19, 2026

pronichkin commented on Aug 19, 2026

Karl-WE commented on Aug 19, 2026

God-damnit-all commented on Aug 20, 2026

nixtar commented on Sep 2, 2026

Alovchin91 commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

🔴 Blocker — System Context: `pwsh` invisible to automation