Reset-Appx: Function Test-WinGetApp should use system context #10
Comments
|
Hi Thomas, thank you for the info. The script is intended to be run in the SYSTEM context. Does your observation still apply in that scenario? Thanks
Sent from Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Thomas Redmer ***@***.***>
Sent: Monday, September 18, 2023 3:52:50 PM
To: byteben/MEM ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [byteben/MEM] Reset-Appx: Function Test-WinGetApp should use system context (Issue #10)
Hi Ben and all,
I am currently testing your superb script. My intent is to move some thousands existing systems with Company Portal user context installs to system context installs.
Maybe I am mistaken and get the script logic wrong. But I am wondering why the Test-WinGetApp function does not use the --scope machine parameter for its winget.exe calls? Without it, it defaults to the user scope. Which leads to an unnecessary call of the Install-WinGetApp function (with its explicit machine scope).
For me, when executing manually as SYSTEM (via psexec)...
...without explicit scope:
PS C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.20.2201.0_x64__8wekyb3d8bbwe> .\winget.exe list --id 9WZDNCRFJ3PZ --source msstore --accept-source-agreements
No installed package found matching input criteria.
...with explicit user scope:
PS C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.20.2201.0_x64__8wekyb3d8bbwe> .\winget.exe list --id 9WZDNCRFJ3PZ --source msstore --accept-source-agreements --scope user
No installed package found matching input criteria.
...with explicit machine scope:
PS C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.20.2201.0_x64__8wekyb3d8bbwe> .\winget.exe list --id 9WZDNCRFJ3PZ --source msstore --accept-source-agreements --scope machine
Name Id Version
-----------------------------------------------
Microsoft.CompanyPortal 9WZDNCRFJ3PZ 11.2.179.0
My winget version:
.\winget.exe -v
v1.5.2201
It's an easy change to Test-WinGetApp. Just add the machine scope explicitly. Happy to submit a pull request if needed.
—
Reply to this email directly, view it on GitHub<#10>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKSAHIDYTX5QQ3DKERASRODX3BN4FANCNFSM6AAAAAA443MCBY>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
Yep, running the tests with psexec -i -s. |
|
I can confirm what Thomas reported a while ago, without the --scope machine switch the Company Portal is not recoginzed: |
|
I submitted my fix with PR #11 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi Ben and all,
I am currently testing your superb script. My intent is to move some thousands existing systems with Company Portal user context installs to system context installs.
Maybe I am mistaken and get the script logic wrong. But I am wondering why the
Test-WinGetAppfunction does not use the--scope machineparameter for itswinget.execalls? Without it, it defaults to the user scope. Which leads to an unnecessary call of theInstall-WinGetAppfunction (with its explicit machine scope).For me, when executing manually as SYSTEM (via
psexec)......without explicit scope:
...with explicit user scope:
...with explicit machine scope:
My winget version:
It's an easy change to
Test-WinGetApp. Just add the machine scope explicitly. Happy to submit a pull request if needed.The text was updated successfully, but these errors were encountered: