Repository navigation
Tracking: MSIX packaging gaps for PowerShell 7 #27565
Description
Activity
To have lack of Server Core support and incompatibility with Group Managed Service Accounts added do issues need opened?
Reacted by Karl Wester-EbbinghausIf 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) realistically this should all be tracked in a project as well
Reacted by Khaled JCan 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} /qnThanks
Reacted by Khaled JAdding 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 theGet-WindowsOptionalFeaturethat 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.
Reacted by soredake and Khaled JThis 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
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)Reacted by God-damnit-allNick 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.
Reacted by Karl Wester-EbbinghausPlease try running the
winget upgradecommand.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.Reacted by Khaled JAs 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?
Reacted by Karl Wester-EbbinghausNot 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 underC:\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-CommandInDesktopPackagewill 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.
Reacted by Staffan GustafssonNick 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 :-)
Reacted by Artem PronichkinReacted by William MarshallSlightly 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.
Reacted by Howard Kapustein and Karl Wester-EbbinghausCould 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.
Reacted by 孟武.尼德霍格.龍#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.
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:
pwshinvisible to automationMSIX 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 contextCovers: 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 MSIXThe 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.Get-WindowsOptionalFeature -Onlinefails on PowerShell from MSIX installation - [Get-WindowsOptionalFeature: Class not registered] #13866 —Get-WindowsOptionalFeature -Onlinefails on MSIX PS7🟡 Enterprise Configuration: PS7 cannot write its own config
$PSHomeis 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-PSSessionConfigurationwrite.psscto$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 administratorsAdmins 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.
🟢 Other confirmed gaps (tracked, not on critical path)
.ps1files with PowerShell installed via.msixbundle#27277 —.ps1file association broken with MSIX installStatus
.pssclocation (#9278)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.