Deploying Winget Auto Updates (WAU) gives you a functional update baseline, for full functionality we need to configure more to get ready for production. If servers query the Winget repository at different times you might end up with inconsistent versions and unplanned outages.

Introduction to schedule WinGet Auto Updates

We have learned how to install Winget Auto Updates using a GPO in the last article “Centralized Software Patch Management: Deploying Winget Auto Updates (WAU) via Active Directory GPO”. In the video below from this article we also deployed the ADMX file needed in this article.

By combining WAU with Active Directory Administrative Templates (ADMX) and a centralized inclusion/exclusion lists stored on a file share, you transform this tool into a automated software deployment tool. This approach ensures that essential utilities are always present while preventing sensitive workloads from receiving unapproved or risky updates.

Checking Package Availability in Winget

Before adding software to your baseline, verify that each package exists in the public Winget repository and confirm its exact identifier. Incorrect IDs cause silent failures, stalled update cycles, or repeated error entries in WAU logs.

Examples:

• AD Account Lockout Tool: Not available in the public Winget repository. Tools like this must be deployed via a traditional GPO software installation.
• My favorite Event Log viewer from this article “Modern Windows Event Viewer – EventLogExpert” is EventLogExpert and it is not available. So we will use Snake Tails with the identifier: snakefoot.snaketail
• For tailing use Klogg as recommended here as it is available. Use the identifier: Variar.klogg

Personally I like using https://winget.run/ to verify for new packages as explained in my previous articles “WinGet and IaC – Take Winget to the next level” and “https://hartiga.de/tools/easily-manage-applications-with-winget-v1-x/“

Advanced Centralized Configuration via GPO

Romanitho’s WAU ADMX templates allow you to control the entire WAU client configuration through Group Policy with no locally managed config files and per-machine drifts.

Here are our first steps:

• Open gpmc.msc
• Create a new GPO: LAB-Computers-Software-WAU-Configuration
• Link it to your server OU
• Navigate to: Computer Configuration → Policies → Administrative Templates → Winget-AutoUpdate

Enforce Machine-Wide Installation Scope

By default, Winget may install software into %LocalAppData%, making it invisible to other users and background tasks. In the WAU template, force machine-wide installation to ensure all binaries land in standard system paths such as Program Files. This is essential for predictable server behavior.

The inclusion and exclusion list reality

A common point of confusion when looking at configuration storage folder structures is trying to use both lists simultaneously. In WAU’s architectural design, the application update logic modes are mutually exclusive.

If Use WhiteList instead of BlackList is left Not configured, WAU runs in global Blacklist mode. It scans the server, patches every existing Winget app it finds, and strictly references excluded_apps.txt to see what it must skip.

If you enable the Whitelist setting, the engine shifts entirely, only checking and updating packages explicitly declared in included_apps.txt while ignoring the rest of the machine.

Crucially, neither list mode will perform a fresh installation of a missing tool. WAU is strictly an updater; if Klogg or EventLogExpert is completely missing from a newly provisioned server, WAU will simply bypass them.

To standardize your environment, you must explicitly define if you want to maintain a white or a blacklist. WAU supports this through two centralized list files:

• included_apps.txt (Acts as your allowlist if you enable the Whitelist policy configuration)
• excluded_apps.txt (Acts as your blacklist)

Both should be stored on a read-only, highly available UNC path. I will be using the path you should know from previous blog articles around GPO: “\nas-file-2025\Software\WAU-Config”

Example included_apps.txt

snakefoot.snaketail
Variar.klogg

Example excluded_apps.txt

I try to exclude critical components like MS SQL Server, which i manage using WSUS or tools that have their own automatic update configuration, i.e. Google Chrome

Microsoft.SQLServer.*
Google.Chrome

Dynamic Scheduling and Service Management to schedule WinGet Auto Updates

WAU installs a scheduled task that runs under NT AUTHORITY\SYSTEM, giving it the required permissions to update software silently in the background.

You can check the settings in the task scheduler. The default settings are below and you can see tzhe active triggers are “At log on of any user” and “at 6:00 am every day.”

To enforce a deterministic update window at 3am with no updates at login, we have to configure this:

• Open your WAU configuration GPO
• Set Update Interval to Daily
• Set Execution Time to 03:00
• Set Updates at Login to disabled

Important: Winget only updates the registry and scheduled settings daily at 6am. You need to run the task highlighted below manually or execute this script once:

Why does it matter to schedule WinGet Auto Updates

We want to automate, but control the risk. So we want to prevent updates to critical workloads (exclusion) and maintain a consistent set of tool across our servers during working hours. This combines automation with minimized operational risk with a significantly increased machine configuration standardization.

Common Mistakes and How to Avoid Them

Even well-designed WAU deployments can fail due to small oversights. These are the issues I see most often:

• Incorrect package identifiers: A single typo in included/excluded lists causes silent failures. Always verify with “winget search” and use copy and paste.
• Wrong ADMX language folder: If WAU.adml is placed in the wrong locale folder, the GPO settings will not appear. Stick to en-US.
• UNC paths not reachable at startup: If the file share is unavailable during boot, WAU falls back to defaults.
• Winget not accessible to SYSTEM: Some security tools block the WindowsApps folder for SYSTEM. WAU cannot run without it and you need to configure exclusions with your IT Security contacts.
• User-scope installations: Software installed under %LocalAppData% will cause issues. Enforce machine-wide scope.
• Metered connection false positives: Hybrid cloud routing can trigger metered-connection blocks. Enable the override if needed.

Hint: If used on RDP Sessions by a larger group of people in your organization I would consider disabling the notification UI.

Conclusion

By moving third-party update logic into Group Policy, you turn WAU into a predictable, centrally governed update engine. With fixed package identifiers, controlled inclusion/exclusion lists, and a strict 03:00 execution schedule, your servers follow the same lifecycle every day. No drift, no surprises.

In the next article, we’ll dive into advanced WAU tuning, including notification suppression, custom repository integration, and hardened baseline enforcement.

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