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.

the good thing about MSIX is that it's an actively developed technology.

It's an installer that doesn't support system installs.

It's an installer that doesn't support machine installs.

Just to clarify it can technically be installed for all users if that's what you mean by machine installs. You use Add-AppxProvisionedPackages and any existing plus new profiles will have the app provisioned automatically.

What it does not have yet is running under the SYSTEM context which is tracked here.

It's an installer that doesn't support machine installs.

Like a fridge that can only heat. But they are working hard on an update so it can cool. At least a little bit.
But we have to be happy because somehow it is doing something. Not what the user asked for and what is needed, but it works. Somehow.

It's an installer that doesn't support machine installs.

Just to clarify it can technically be installed for all users if that's what you mean by machine installs. You use Add-AppxProvisionedPackages and any existing plus new profiles will have the app provisioned automatically.

What it does not have yet is running under the SYSTEM context which is tracked here.

Right, sorry, I meant to say system.

I personally completely avoid MSIX for any applications I build and manage because it's absolutely trash.

the good thing about MSIX is that it's an actively developed technology. And this very issue is a living proof of that. We're making significant investments to make it work for PowerShell. And once it's good enough for PowerShell, it should be good enough for pretty much everything else. And if it's not, we'd like to hear about that.

On Linux you just sudo install and you're done. Problem solved. Why does Powershell need this much complication?

on Windows, you already can do a winget one-liner to install any app, MSIX or not. This applies to packaged apps just as to any other app. And in the future, that'll be even easier.

Especially when Core and Nano Server are critical path for Powershell moving forward?

Yes, and Server Core is 100% in scope for these investments.

Appreciate the reply. The challenge is the Windows ecosystem can't just upgrade to Server 2025 or some newer versions of Servers.

The automations that come out for Windows are usually not back ported to even supported versions of the platform: for example, there is no winget for Server 2019. I have no reason to believe this won't be the same situation in this case, particularly since the underlying fixes are Windows issues.

In short, the Powershell team should avoid this move until all fixes are in all supported versions of Windows--and if that means waiting until 2019 and 2022 are out of support, then so be it. People are going to run these platforms for as long as security patches come out, regardless of whether there is a cut off to extended support mode.

My concern is this move is a complete disregard for the reality of the Windows install base, ecosystem, and Systems Administrators out there.

This release basically tells everyone who manages Windows LTSC or ESU versions that they should go back to PowerShell 5.1. Any development on the Windows side to make PowerShell Core work again ¹ is unlikely to be backported. Staying on PowerShell 7.6 is not an option because its EOL is earlier than those LTSC/ESU versions.

PowerShell 7.7 on Windows at this moment is broken by design. Full stop. Don't tell me I can manually unzip and copy files or similar hacks. Any admin worth his job title will laugh you off. ↩

This release basically tells everyone who manages Windows LTSC or ESU versions that they should go back to PowerShell 5.1. Any development on the Windows side to make PowerShell Core work again ¹ is unlikely to be backported. Staying on PowerShell 7.6 is not an option because its EOL is earlier than those LTSC/ESU versions.

Second that.
And with every day even in my home use I am noticing more glitches.

Today opening Microsoft Terminal missing PS 7.
Opening Microsoft Store searching for PowerShell tells me it's installed, I can even open the 7.7 version. Using winget installn, installing PowerShell 7 again. Then it showed up in Terminal again.

Questions:

Why it disappeared in Terminal
While being able to launch from Store
While not appearing in start / search
Winget install doesn't even have a problem installing it, even the previous msix was installed.

I understand that this is all worth repros, a seperate issue report, but that's not my point of reporting this. Seeing the list known regressions, if I had a magic wand, I would postpone msix until major blockers are resolved.

And even this is all unfeasible by now. The far early release of msix through msix, accidently or not, made clear, we cannot just swap msi to msix or vice versa because installers are not compatible at all.

Thank you for your consideration and spending time on a plan B.

PowerShell 7.7 on Windows at this moment is broken by design. Full stop. Don't tell me I can manually unzip and copy files or similar hacks. Any admin worth his job title will laugh you off. ↩

This isn't necessarily a PowerShell-specific issue so I'm not sure if I should create a new issue for it, but as it atands, provisioned packages under Administrator Protection do not create an execution alias for the shadow account, i.e., elevated accounts cannot find pwsh.

I think that is source of problem is about using of different accounts and missing definition in PATH variable ...

For the administrator protection issue you need to do a one off manual registration in the scope of the shadow admin user. Run Start-Process powershell.exe -Verb Runas then run the following PowerShell command to register the provisioned package for the user.

Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.PowerShell_8wekyb3d8bbwe

Typically registration is done automatically on the next interactive logon, RDP or direct logon, for the user but the admin shadow user never goes through this process. By triggering the registration manually the provisioned package is registered for the user which include the app exec aliases in $env:LocalAppData\Microsoft\WindowsApps so it can found in the PATH. Once registered any future updates to that provisioned package is automatically re deployed to the user so the registration is only needed once.

Microsoft should probably fix this so it happens automatically but that's unfortunately outside the scope of PowerShell and probably needs to be provided through the feedback hub.

the good thing about MSIX is that it's an actively developed technology.

It's an installer that doesn't support system installs.

Agree. Unless I'm missing something, how did this go GA? The new MSIX bundle is three times the size and can't do system wide installs. I guess just revert and pin it till it's fixed

C:\Windows\System32>winget install --id Microsoft.PowerShell --version 7.6.10.0 --source winget --installer-type wix
Found PowerShell [Microsoft.PowerShell] Version 7.6.10.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://github.com/PowerShell/PowerShell/releases/download/v7.6.10/PowerShell-7.6.10-win-x64.msi
  ██████████████████████████████   112 MB /  112 MB
Successfully verified installer hash
Starting package install...
Successfully installed

pwsh no longer has a reliable path to use for scheduled tasks. It's now buried in c:\program files\windowsapps\microsoft.powershell_X.X.X.X__x64__[random characters]\pwsh.exe

This is a complete nonstarter for automation, scheduled tasks, etc. This should be reverted immediately.

One solution. Assuming you had a working PowerShell installation, you could write a Windows PowerShell script to delete all the files in the PowerShell folder (the working installation). Then use the Install-PowerShell.ps1 file in this repo to copy the release zip file into that folder. Then all should be well.

pwsh no longer has a reliable path to use for scheduled tasks. It's now buried in c:\program files\windowsapps\microsoft.powershell_X.X.X.X__x64__[random characters]\pwsh.exe

You are not meant to use that path. It is by design that MSIX packages are installed to a versioned path and are made to be immutable. This ensures that MSIX packages can be updated even when it is in use by any user and that any files like dll’s are not tampered with. It is certainly a change from the MSI way but the entrypoint for pwsh is in the $env:\LocalAppData\Microsoft\WindowsApps\pwsh.exe which is unversioned. This folder is in the user’s PATH so that it’ll be usable as pwsh.exe as soon as the package is registered for the user.

As for scheduled tasks it can be used for users but SYSTEM is a known gap as stated in this issue.

With all those "pwsh.exe not in Path" problems:
Since Windows Vista, i.e. for about 18 years now, NTFS hardlinks are extensively used by the system. If you install https://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html you can see that nearly all MS-Files in Windows\System32 are hardlinks. This save a huge amount of disk space, AND still makes those .exe/.dll/.etc available for the system, in %PATH%. This tech is still there, and has been improved with each version of Windows.
I can't wrap my head around WHY Microsoft does not, at least, make a hardlink to a system wide available path, for compatibility reasons I suggest C:\Program Files\PowerShell\7\pwsh.exe, when we install it system-wide. The tech to do so has in Windows for, like I wrote above, 18 years. Yet whoever does the .MSIX package, or those who push their "we have to do it that .MSIX way, no matter what it breaks" agenda, do not manage this simple thing?
(This, among a lot of other things, is why I firmly believe: Since somehwere around 2020, Microsoft as a whole company not single employed persons, hates sysadmins and enthusiasts and deliberately ignores them)

Link Shell Extension

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

11 remaining items

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

11 remaining items

God-damnit-all commented on Nov 11, 2026

jborean93 commented on Nov 12, 2026

Tragen commented on Nov 12, 2026

God-damnit-all commented on Nov 12, 2026

miketheitguy commented on Nov 12, 2026

mawosoft commented on Nov 12, 2026

Footnotes

Karl-WE commented on Nov 12, 2026

Footnotes

Still34 commented on Nov 12, 2026

michalzobec commented on Nov 12, 2026

jborean93 commented on Nov 12, 2026

jlpetz commented on Nov 12, 2026

yllekz commented on Nov 13, 2026

doctordns commented on Nov 13, 2026

jborean93 commented on Nov 13, 2026

Joachim-Otahal commented on Nov 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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