App install using System Account fails

[mdonaghy325]

Brief description of your issue

App install using System Account fails with 0x80070520 error

Steps to reproduce

Use winget to install an app using the System Account

Expected behavior

Application to install successfully

Actual behavior

App install fails with 0x80070520 error

Environment

winget --info
Windows Package Manager v1.4.10173
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19044.1889
System Architecture: X64

Logs: %TEMP%\WinGet\defaultState

User Settings: %LOCALAPPDATA%\Microsoft\WinGet\Settings\defaultState\settings.json

[Trenly]

https://github.com/microsoft/winget-cli/issues/2490#issuecomment-1235715314

[denelon]

@mdonaghy325 As WinGet is installed via MSIX, the system level access isn't directly supported. We've built a NuGet package with the COM APIs used to enable system level access. We're still working on documentation and guidance on how to work in the system context.

It's the same mechanism used by the Intune integration and is supported for third-party MDM type solutions.

Duplicate of #215

• #215

[microsoft-github-policy-service[bot]]

@mdonaghy325 we've identified this Issue as a duplicate of another one that already exists. This specific instance is being closed in favor of tracking the concern over on the referenced Issue. Thanks for your report! Be sure to add your 👍 to the other issue to help raise the priority.

[mdonaghy325]

HI

Thanks for reply

We run a Managed Service for 400,000 users in the Education Sector

The outcome we are looking to achieve is:

Use GPO to prevent end users installing apps with winget Use System Account to install / update apps for end users with winget

Is this something that is available now or will be possible with the NuGet package?

Many thanks,

Matthew

[denelon]

There is still work in progress on additional GPO to enable the COM APIs required for the system level access as a separate policy from the current "Disable WinGet" policy.

The current policy would block both interfaces, so we're building a separate one to allow the system context access to the COM API while blocking the user level access to the WinGet CLI.

[mdonaghy325]

Thanks – we have seen the outcome on both interfaces when using current GPO ☺

Sorry for this question - Any indicative timelines for additional GPO – weeks, few months, half a year, 1 year?

[denelon]

My current best guess is a few months to get it all rolled out with artifacts here at GitHub. We will update the ADMX files here along with the updated client with the support for the behavior. It takes longer for changes made to the Windows base image to be rolled out with the releases of Windows.

[mdonaghy325]

Thanks – it will allow me to set some expectations

& just to clarify will this allow us to achieve our desired outcome running winget commands:

Prevent end users installing apps with winget Use System Account to install / update apps for end users with winget

[denelon]

Yes, you will essentially be integrating with the COM API via the NuGet package we publish to gain access to winget on the system and it will actually "run" on the user's machine. There are still plenty of gotchas with getting user level installs via the system context and I'm sure we'll uncover additional edge case, but we're heading in the right direction.

[mdonaghy325]

Thanks for confirming – does this require InTune

[denelon]

Intune has already done the integration work with the "in process" COM API. For other MDM providers or scenarios, one would need to integrate with the same NuGet package and call the COM API.

[mdonaghy325]

Would there be any update on timeline for feature to enable system account to install apps via winget and block standard users installing apps via winget

Our environment is Windows 10 managed by GPO (not intune)