There's a risky way to patch third-party apps.
Open a terminal. Run everything. Hope nothing breaks.
That's not patch management. That's a bet.
WinGet helps a lot, but inside an RMM it still needs discipline: inventory, catalog mapping, maintenance windows, result evidence, and follow-up when something fails.
1) Start with inventory, not the command
Before you think about updating, you need to know what's actually installed.
It's not enough to say "there's Chrome, 7-Zip, Zoom, or some runtime on the machine." You need name, version, publisher, device, and operational context. Otherwise, you're patching blind.
The right question is:
which third-party apps are installed, at which version, and on which endpoints?
That inventory is the bridge between software inventory and patch management. Without it, WinGet may find updates, but your operation doesn't know how important each one is.
Practical tip: group apps by impact. Browsers, PDF readers, remote tools, and common runtimes usually deserve more attention than rarely used utilities.
2) Map against the right catalog
WinGet works with package sources. Microsoft documents WinGet as a tool for discovering, installing, upgrading, removing, and configuring applications on Windows, and its source documentation warns that sources should be secure and trusted.
That matters because the name installed in Windows doesn't always map cleanly to the package identifier.
You'll run into cases like:
- product name differs from package id;
- apps installed by MSI, EXE, or Store;
- versions reported incompletely;
- packages that require source agreements;
- pinned or excluded applications.
Serious mapping stores the relationship between detected software and candidate package. It shouldn't rely on "the name looks close enough."
Practical tip: use the exact package ID whenever possible. If the match is ambiguous, keep it in review instead of pushing it to production.
3) Test before opening the maintenance window
A third-party update can fail because of permissions, an interactive installer, open apps, language, architecture, dependencies, or a version that won't replace cleanly.
The healthy flow looks like this:
1. Detect installed apps. 2. Map the WinGet package. 3. Test on a small group. 4. Review result and reboot needs. 5. Open the maintenance window. 6. Verify the final installed version.
NIST frames patch management as preventive maintenance, not improvised reaction. That mindset fits perfectly here: plan first, execute next, verify after.
Practical tip: define a pilot group per client or endpoint type. If something fails there, you can still adjust before touching the whole fleet.
4) Don't confuse "executed" with "resolved"
The classic mistake is closing the work when the command exits.
But a finished command can mean many things:
- it upgraded correctly;
- it didn't find the package;
- it found an ambiguous package;
- it asked for interaction;
- the installer failed;
- the app was already current;
- it needs a reboot;
- the installed version couldn't be read.
Post-update verification is where the RMM earns its place. You read inventory again, compare expected version against real version, and separate successful endpoints from pending ones.
Practical tip: track two numbers separately: completed executions and endpoints actually updated. If you only track the first, the report can look good while exposure remains.
5) Connect third-party patches with vulnerabilities
Not every pending app update deserves the same urgency.
If an update fixes a vulnerability being actively exploited, it moves up. If it's a minor fix in a rarely used app, it can wait for the next window.
This is where the workflow should connect with RMM vulnerability management: inventory, CVEs, CISA KEV, EPSS, endpoint criticality, and patch status should talk to each other.
It's also worth using a weekly RMM console review so pending work doesn't disappear into an endless list.
Practical tip: create three queues: critical today, scheduled maintenance, and follow-up. That keeps everything from looking urgent while the important work gets buried.
6) What this should look like inside an RMM
A good third-party patching workflow shouldn't force you to jump between console, terminal, spreadsheet, and ticket.
It should answer quickly:
- which apps have an update available;
- which WinGet package will be used;
- which endpoints are targeted;
- which maintenance window applies;
- what failed and why;
- which version was installed after the update.
Lunixar RMM connects inventory, monitoring, and patching so this work doesn't live as loose commands. The goal isn't "run WinGet." The goal is operational control: know what changed, where it changed, and what's still pending.
To evaluate the full flow, review patch management, inventory, and device monitoring.
Practical tip: before automating broad updates, document your exclusion rules. Some business apps shouldn't update without validation.
