{"id":1040,"date":"2026-11-06T03:17:28","date_gmt":"2026-11-06T03:17:28","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/?p=1040"},"modified":"2026-11-06T03:17:28","modified_gmt":"2026-11-06T03:17:28","slug":"winget-chocolatey-silent-upgrades-windows-server","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/winget-chocolatey-silent-upgrades-windows-server\/","title":{"rendered":"Winget and Chocolatey for Silent Upgrades on Windows Server: A Working Setup"},"content":{"rendered":"
\n

Windows Server has no equivalent of a Linux distribution’s unattended-upgrade daemon, and Windows Update covers only Microsoft’s own patches. For third-party software \u2014 Git, 7-Zip, Python, Node, SQL Server tooling \u2014 you need a package manager, and the two realistic choices on Server 2019, 2022 and 2025 are winget and Chocolatey.<\/p>\n

Both can run unattended on a schedule, both have sharp edges when run under a service account, and both will silently do the wrong thing if you point them at the wrong scope. This is a working setup rather than an overview: what to install, how to pin, how to log, and where each tool breaks.<\/p>\n

Which tool for which job<\/h2>\n

Winget is Microsoft’s package manager, shipped with modern Windows and available as an MSIX bundle on Server 2019 onward. It resolves packages from the winget community repository, which mirrors vendor installers. Its strength is that it uses the vendor’s own installer, so licensing and signatures are exactly what the vendor intended. Its weakness is that many vendors ship interactive MSIs, and winget’s silent switches may not suppress every UI prompt.<\/p>\n

Chocolatey wraps installs in PowerShell scripts and has a much longer history on servers. It handles silent flags per package, has a large maintained repository, and its business edition adds package internalisation \u2014 downloading the installer once, then installing from a local cache, which matters if your VPS has flaky outbound access. The community edition is free and adequate for a small fleet.<\/p>\n\n\n\n\n\n\n\n
Aspect<\/th>\nWinget<\/th>\nChocolatey<\/th>\n<\/tr>\n
Install source<\/td>\nVendor installer via manifest<\/td>\nPowerShell script wrapping installer<\/td>\n<\/tr>\n
Machine scope<\/td>\nYes, with admin context<\/td>\nYes, default for admin<\/td>\n<\/tr>\n
Pinning versions<\/td>\nYes, per package<\/td>\nYes, via --version<\/code><\/td>\n<\/tr>\n
Offline cache<\/td>\nLimited<\/td>\nBusiness edition internalise<\/td>\n<\/tr>\n
Server support<\/td>\n2019+, best on 2022\/2025<\/td>\n2012+<\/td>\n<\/tr>\n<\/table>\n

Installing both without breaking each other<\/h2>\n

Install winget first. On Server 2025 it is present; on 2019 and 2022 you add it via the App Installer MSIX bundle, which requires the Desktop Experience \u2014 winget does not run on Server Core. Chocolatey installs from a one-line PowerShell bootstrap and places its binaries in C:\\ProgramData\\chocolatey\\bin<\/code>, which is already on the machine PATH.<\/p>\n

# AllUsers scope, non-interactive\n$env:ChocolateyInstall = 'C:\\ProgramData\\chocolatey'\nSet-ExecutionPolicy Bypass -Scope Process -Force\n[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12\niex ((New-Object Net.WebClient).DownloadString('https:\/\/community.chocolatey.org\/install.ps1'))\n\nchoco --version\nwinget --version<\/pre>\n
Keep the two package sets disjoint. Installing the same application through both managers leads to a state where each thinks it owns the install and upgrades fight over the same files. Pick one manager per application and record the choice in a short table in your runbook.<\/p>\n
Unattended upgrade patterns that actually work<\/h2>\n
Winget’s upgrade verb is the simplest option and covers everything installed through it:<\/p>\n
winget upgrade --all --silent --accept-package-agreements --accept-source-agreements --disable-interactivity<\/pre>\n
Chocolatey’s equivalent upgrades only packages it manages, and needs -y<\/code> to avoid prompts:<\/p>\n
choco upgrade all -y --no-progress --limit-output --execution-timeout=2700<\/pre>\n
Run both from a scheduled task as SYSTEM, not as your interactive user, so the machine-scope registry and Program Files are writable and the job does not depend on anyone being logged in. Log to a file with timestamps, because “the upgrade ran” and “the upgrade succeeded” are different claims.<\/p>\n
Pinning, exclusions and rollback<\/h2>\n
Blindly upgrading everything is how a working box breaks at 2 a.m. Pin anything whose major version you have not tested:<\/p>\n