Background Back in 2022, after a lot of testing, I developed a way to install any machine wide installer in SYSTEM context using WinGet . For the most part this worked great, however I noticed that if I deployed an application targeted to a device group, the application would not reliable install during autopilot / OOBE. This is because the DesktopAppInstaller UWP appxpacakage needs to be installed under a user account before WinGet is available to use.

Microsoft relecently released the new Microsoft Store integration for Intune . The new integration allows admins to easily search the store and deploy traditional APPX/UWP packages as well as a limited number of new Win32 app packages. WinGet (the Windows package manager) is the technology behind this new experience. This new experience greatly simplifies application deployment through Intune and is intended to replace the Microsoft Store for Business which will be retired in the first half of next year.

The Why In a previous article , I demonstrated how to deploy applications to Intune using WinGet . I recieved a request to demonstrate how to use WinGet to update applications, and more importantly, how to run this on a schedule to keep applications updated. Since then, I found a really handy PowerShell wrapper module for WinGet called WinGetTools by Jeffrey Hicks . I made a small contribution to this module to allow it to work running under SYSTEM context.

Ever since the WinGet package manager was announced, I wanted to find ways to leverage the package manager to simplify deploying software to endpoints. After doing some research and testing, I found that WinGet was unfortunately not designed to be run in SYSTEM context. It was designed to be run under a user account. There is an open issue on GitHub currently and many admins, myself included, would really like WinGet to be designed with enterprise use in mind.