Winget for RMM: Silent Software Deployment at Scale

LIMEHAWK - Managed IT

Home>Incident Reports>Winget for RMM: Silent Software Deployment at Scale

The challenge

New client onboarding. 85 workstations needed a standardized software stack: Chrome, Adobe Reader, 7-Zip, Zoom, Teams, and 12 other applications. The previous MSP had been installing software by RDP'ing into each machine and running installers by hand — about 45 minutes per workstation on a good day. We needed silent deployment with no user interaction and a repeatable process we could re-run for every new hire's machine.

Why winget for RMM?

Windows Package Manager (winget) is Microsoft's answer to apt-get and homebrew. It's baked into Windows 11 and available as an install on Windows 10. For MSP use the advantages line up nicely:

- 60,000+ packages: the Microsoft-curated repository covers most business software already
- silent install flags: --silent and --accept-package-agreements work for roughly 99% of packages
- upgrade all: a single command updates every installed application — perfect for patch compliance
- no licensing: unlike PDQ Deploy or SCCM, winget is free and built into Windows

The catch: winget does not work out of the box when scripts run as SYSTEM, which is how most RMM tools execute them. The winget.exe binary exists, but it's not on SYSTEM's PATH and its app execution alias behaves differently under the SYSTEM context. We built a three-script toolkit to solve this cleanly.

Script 1: winget setup

First challenge: winget isn't always installed, especially on older Windows 10 builds or fresh deployments. This script downloads the latest release from GitHub (Microsoft.DesktopAppInstaller) and installs it in a way that works for SYSTEM-context execution.

Key insight: when running as SYSTEM, winget.exe exists but isn't in PATH. We use Resolve-Path to find it in C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_* and call the full path directly.

Script 2: install any package

This is the workhorse. It uses SuperOps runtime text replacement so technicians can deploy any winget package without editing the script. Just enter the package ID (Google.Chrome, Mozilla.Firefox, Adobe.Acrobat.Reader.64-bit) when running the job.

Common package IDs we deploy most often:

- Google.Chrome
- Mozilla.Firefox
- Adobe.Acrobat.Reader.64-bit
- 7zip.7zip
- Zoom.Zoom
- Microsoft.Teams
- VideoLAN.VLC
- Notepad++.Notepad++

Find a package ID with: winget search "application name"

Script 3: upgrade all

The real power of winget is keeping everything updated. We run this weekly via a scheduled job. It upgrades every winget-managed application to the latest version silently, and handles the log churn automatically — we keep 14 days of upgrade logs for troubleshooting and purge the rest.

Outcome

The 85-machine deployment that would have taken 64 hours of manual RDP work finished in 3 hours. We ran winget_setup first to normalize the fleet, then batch-deployed all 15 applications in parallel from the RMM. Weekly upgrade jobs now keep everything patched automatically — no more chasing Chrome ZDIs the day after a release.

machines deployed: 85 (full software stack)
time to deploy: 3 hours vs 64 hours manual
applications: 15 per machine
weekly updates: automated, silent

Key takeaways

Takeaway

winget works in SYSTEM context if you locate the exe in WindowsApps directly and call the full path.

Takeaway

SuperOps runtime replacement makes one script work for any package — no fork per app.

Takeaway

weekly "upgrade all" jobs eliminate manual patch management for third-party apps.

Takeaway

Microsoft's own repository covers the vast majority of what a small business stack needs.

Need help with something like this? Contact us

• Automating CrushFTP Upgrades and In-Place Updates (Automation)

• PC Replacement: Zero Data Loss User Profile Migration (Automation)

• Mass BIOS & Driver Updates: Dell Fleet Vulnerability Patching (Automation)