Deploying Winget Auto Updates for Software Patch Management for managing third-party software updates across an IT infrastructure typically requires expensive enterprise solutions. This article provides a technical guide on how to automate and centrally enforce Winget Auto Updates (WAU) across an Active Directory domain using native Group Policy Objects (GPO).

Introduction to 3rd Party Software Patch Management

Relying on localized scripts or individual task schedulers to maintain third-party software creates configuration drift and administrative overhead. Without central management, tracking update failures or maintaining standardized application baselines across multiple endpoints is difficult to scale.

By integrating update processes with Active Directory Group Policy Objects, control is shifted entirely to the domain layer. Utilizing administrative templates removes the need to modify configuration files on individual machines. Instead, deployment schedules, notification behaviors, and software exclusions are managed from a single interface and automatically replicated to all target clients.

There are good 3rd party solutions like PatchMyPc and a lot cloud native solutions, but I wanted something that i know the background (Winget), that is on premise and community driven for my homelab. If you are new to Winget, please check these two blog articles first: WinGet and IaC – Take Winget to the next level & Easily manage Applications with WinGet v1.x

Important: For your enterprise / medium sized workstation with over 1.000 workstations and requirement like multi-language, dedicated rollout & maintance windows I would recommend to evaluate that market. If you want to utilize automation like ansible for automation large scale, please contact me directly.

What is WAU?

Winget, the Windows Package Manager is Microsoft’s native command-line tool for installing and managing applications. However, Winget is primarily designed for user-driven interactions. The open-source project Winget-AutoUpdate (WAU) by Romanitho bridges this gap for automated environments. WAU deploys a scheduled task that runs Winget in the system context. This allows third-party software like browsers, runtimes, and developer tools to be updated silently in the background.

Technical Implementation to deploying Winget Auto Updates

For a clean and scalable deployment, we utilize the Active Directory Central Store. This ensures that all domain controllers access the exact same administrative templates. Check my blog to get started with the intial setup for the Active Directory Central Store

First, the current policy components must be downloaded from the Romanitho GitHub repository. These consist of the structure definition (ADMX) and the language file (ADML).

Copy the extracted files into the following directories of your domain controller:

• The WAU.admx file is placed in the path \Your-Domain-Controller\sysvol\Your-Domain-Name\Policies\PolicyDefinitions\
• The language file WAU.adml belongs in the corresponding subfolder for the language, for example \Your-Domain-Controller\sysvol\Your-Domain-Name\Policies\PolicyDefinitions\en-US\

Important: The target path in the network corresponds to the standard architecture for centralized GPO templates under Windows Server and if it is missing for you, please check here: https://hartiga.de/azure/policydefinitions-folder-is-missing/

Staging the Installation Files for deploying Winget Auto Updates

Before creating the rollout policy, you need to stage the installation script or MSI installer files on an accessible network share. Download the latest installation assets from the repository and move them onto a file server inside your network.

To organize this correctly, we follow the standard directory structure and file management pathways established in our foundational automation guide. Review the file hosting patterns here: https://hartiga.de/windows-server/automation-using-group-policy/

Creating the Deployment GPO

Open the Group Policy Management Console (gpmc.msc) and create a brand-new, standalone GPO named “LAB-Computers-Software-WAU-Servers”. Link this policy directly to the Organizational Unit (OU) housing your target servers.

Inside this deployment GPO, configure a Startup Script or an MSI software installation package under Computer Configuration -> Policies -> Software Settings. Point the path directly to the fileserver UNC path you mapped out in the previous step. This ensures that when target machines boot up, they evaluate and install the base WAU client binaries in the local system context.

I highly recommend using a Computer Group “GG-Computer-Server-Automatic-Patching” and add servers with patching to that group. You will come into situations, where you want to disable it and “Opt-In” by adding systems to this service is my approach.

Important: We intentionally separate the deployment task from the actual WAU configuration policies. Splitting these duties into two independent GPOs aligns with enterprise lifecycle best practices, that i shared here. It allows you to target or freeze application rollouts independently from changing global runtime configurations (like adjusting exclusion lists or update interval changes later down the line).

Verification after the initial deployment

With the default configuration Winget AU will automatically update the detected software. You will see a small popup in the Notification Area of your Windows Server 2025 on your next login. When you want more details check your logfile on the client in this folder: C:\Program Files\Winget-AutoUpdate\logs

This is the logfile on my Azure Arc joined Client with WAC after the first run of WAU.

Conclusion on Deploying Winget Auto Updates

At this stage, you have established the base deployment infrastructure. WAU is now actively installing across your targeted endpoints and will run under its default behavior. Note that at this point, WAU will only update existing, already installed third-party software it identifies on the machine.

In the next article around Deploying Winget Auto Updates, we will take a deep dive into the absolute granular configuration of WAU via our centralized ADMX administrative templates, showing you how to lock down notification levels, adjust execution times, and maintain standardized application blacklists.

I have seen some people success with automating Winget on this level for home labs with scheduled tasks. When i tried that approach it was very complex due to the way Winget is installed and integrated into the OS. I personally use and recommend this approach for homelab, smaller networks and medium sized organizations. This is especially true, when we look into the next article of this small series.

If you have any questions please don’t hesitate to reach out to me on LinkedIn, Bluesky or check my newly created Adaptive Cloud community on Reddit.

LinkedIn: https://www.linkedin.com/in/andreas-hartig/

Bluesky: https://bsky.app/profile/hartiga.de

Adaptive Cloud community on Reddit: https://www.reddit.com/r/AdaptiveCloud/

My YouTube Channel: https://www.youtube.com/@hartiga