Why does pwsh think I'm not in an administrator shell when I provide LocalMachine, but not CurrentUser, as the -Scope of Set-ExecutionPolicy?
#25729
Answered
by
jborean93
RokeJulianLockhart
asked this question in
Q&A
-
ContextI'm attempting to unrestrict the execution policy: 1 #!/usr/bin/env pwsh
#Requires -PSEdition Core
#Requires -Version 7.6.0
#Requires -RunAsAdministrator
If ($IsWindows) { Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy Unrestricted -Force }...for microsoft/WSL#13224 (comment): #!/usr/bin/env pwsh
#Requires -PSEdition Core
#Requires -Version 7.6.0
#Requires -RunAsAdministrator
& "$Env:UserProfile\Downloads\collect-wsl-logs.ps1"...which fails, since it's somehow restricted itself since I last ran that script:
Attempted Elevation Methods
Environment
Footnotes |
Beta Was this translation helpful? Give feedback.
Answered by
jborean93
Jul 6, 2025
Replies: 2 comments 8 replies
-
|
Somehow, #!/usr/bin/env pwsh
#Requires -PSEdition Core
#Requires -Version 7.6.0
#Requires -RunAsAdministrator
- Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy Unrestricted -Force
+ Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted -Force...works:
However, this doesn't explain the error, so I shan't close the thread. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
You're trying to set the execution policy for local machine, so I would suggest two things:
|
Beta Was this translation helpful? Give feedback.
8 replies
-
|
@SamErde, thanks! That worked: 1 #!/usr/bin/env pwsh
#Requires -PSEdition Core
#Requires -Version 7.6.0
If ($IsWindows) { sudo psexec.exe -s -i powershell.exe -NoExit -Command 'Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy Unrestricted -Force; $?' }...as
Weirdly,
Perhaps, there's a bug with the MSIX'd Powershell, since
Footnotes |
Beta Was this translation helpful? Give feedback.
-
|
Try it again with the MSI PowerShell instead of the MSIX version. I have a feeling that'll work better, too. |
Beta Was this translation helpful? Give feedback.
-
|
@SamErde, perhaps it's due to MSIX's abstractions, yeah. I'd presumed that it was because of the PowerShell Code rewrite. |
Beta Was this translation helpful? Give feedback.
-
|
Msix/store apps are installed and protected with an ACE that only See https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.5#known-limitations for known limitations around this. |
Beta Was this translation helpful? Give feedback.
Answer selected by
RokeJulianLockhart
-
|
@jborean93, thank you. I've filed
Have I misunderstood? I'm using V7.6 (Preview). |
Beta Was this translation helpful? Give feedback.
-
|
See the next sentence
The note you shared about 7.2 is for the virtualised FS and registry locations outside of the application’s root/ |
Beta Was this translation helpful? Give feedback.
-
|
@jborean93, thanks! I'd read that, but didn't understand, and was consequently worried that I'd filed an invalid bug. :O |
Beta Was this translation helpful? Give feedback.
-
When this is detected the package will be deemed modified, marked in a 'bad' state and cannot be used until remediated/repaired. MSIX's integrity and security promises preclude this sort of hackery, by design. You're doing what essentially will be identified as malware damaging the system, and Windows will respond accordingly. The recommended solution is mentioned here |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Msix/store apps are installed and protected with an ACE that only
NT SERVICE\TrustedInstallerhas access to. Technically as an admin you can change the owners or add yourself/any user with write access but that needs to be explicitly done before you can modify the files/directory.See https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.5#known-limitations for known limitations around this.