In modern Windows environments, more and more built-in applications such as Calculator, Snipping Tool, Notepad, Paint, and Photos are delivered via the Microsoft Store. These apps are often based on the Universal Windows Platform (UWP), an architecture introduced with Windows 10.
While this offers advantages in terms of distribution and consistency, it also presents specific challenges in managed enterprise environments.

No updates in a VDI Environment
In our environment, we use a reference image as the foundation for deploying VDI workspaces. During the creation of the Master Image, we apply optimizations using tools such as OSOT (Windows OS Optimization Tool for Omnissa Horizon). One of the standard optimizations is to disable access to the Microsoft Store, a logical step from both a security and management perspective.
This setting is relatively easy to reverse. However, once Microsoft Store access is re-enabled, it turns out that updates still need to be performed manually and only when there is an active user session which connect to the Microsoft Store.
During the image build process, this is far from ideal. The goal is to maintain full control, repeatability, and automation, without manual steps or user interaction. That’s why additional tooling is needed to update Microsoft Store apps in an automated and user independent way.
Another side effect of missing updates is that UWP apps may not display in the correct language for the end user. Many Microsoft Store apps only load full language support after an update or reinstall.
Using WinGet for Microsoft Store Apps
In this investigation, I explored the use of WinGet, the Windows Package Manager, as one of the ways to address this issue. WinGet allows us to install and update Microsoft Store apps based on their Store ID, without requiring the Store itself to be accessible to end users.
Step-by-step approach
- Cleaning up unwanted UWP Apps
We use Aaron Parker’s script (Remove Universal Windows Platform / AppX apps | Windows Enterprise Defaults) to remove unwanted apps in advance. In our customized version, only UWP apps such as Edge, OneDrive, and Teams are retained. - Installing WinGet (if needed)
We check whether WinGet is already present. If not, we install it using the Microsoft.DesktopAppInstaller bundle: https://aka.ms/getwinget - Installing Microsoft Store Apps via WinGet
Using a script, we install apps based on their Store ID. These IDs can easily be retrieved via the Microsoft Store.winget.exe install -e --id $App --accept-source-agreements--accept-package-agreements --silent --scope machine
- Logging and Monitoring
Logs are stored in a central location, including a summary of installed apps and their versions. This gives us clear insight into what has been deployed.
Conclusion
Updating Microsoft Store apps in a VDI environment without user interaction remains a challenge. In this investigation, I explored WinGet as one of several possible solutions to automate this process. By using WinGet effectively, we can manage and update Microsoft Store apps without relying on the Microsoft Store interface or manual actions, offering a scalable, secure, and manageable approach for enterprise environments.


Leave a Reply