How to Deploy Adobe Reader Updates Through ConfigMgr in 2026

— there’s nothing left to patch or deploy, and any environment still running Flash content needs a migration plan, not an update strategy. System Center Updates Publisher (SCUP), the tool this post originally used to import third-party catalogs into WSUS, has also been retired by Microsoft — it’s no longer the supported path for third-party update publishing.

Adobe Reader/Acrobat, on the other hand, is still very much alive and still needs regular patching. Here’s how that actually works now.

Option 1: ConfigMgr’s built-in third-party software update support

Current ConfigMgr (the branch formerly called SCCM/MECM) has built-in support for third-party update catalogs, configured under Administration > Overview > Cloud Services > Updates Publisher (or the equivalent third-party catalog node, depending on your console version) — this is the direct successor to what SCUP used to do, integrated into the console rather than a separate tool. Adobe Reader/Acrobat catalogs are among the long-supported entries here.

1. In the console, enable third-party update support and subscribe to the Adobe Reader/Acrobat catalog.
2. Once synced, Adobe updates appear alongside Microsoft updates in Software Library > Software Updates, and deploy through the exact same deployment/maintenance-window workflow you already use for OS patches.

Option 2: A third-party catalog management tool (Patch My PC and similar)

Several vendors (Patch My PC being the most commonly used alongside ConfigMgr) provide a dedicated publishing service that maintains and syncs third-party application catalogs — including Adobe Reader — directly into ConfigMgr’s software updates workflow, with faster catalog turnaround and broader application coverage than relying solely on the built-in catalog list. This is worth considering if you’re patching more third-party apps than just Adobe Reader, since it consolidates them all through one subscription rather than hunting for individual vendor catalogs.

Option 3: Application deployment instead of “updates”

Rather than treating Adobe Reader as a patchable OS-style update at all, some environments manage it as a regular Application in ConfigMgr with a detection method checking the installed version, and a script or MSI-based install/uninstall pointing at Adobe’s current release. This sidesteps the update-catalog question entirely — a scheduled task or Task Scheduler-triggered script checks for new Adobe Reader releases via Adobe’s version-check API/feed, and a new Application revision gets pushed through a standard application deployment when one’s available. More manual to maintain than a catalog subscription, but useful if you specifically don’t want a third-party catalog dependency in your environment.

A note on Adobe Reader’s own auto-update

Adobe Reader/Acrobat also has a built-in background updater by default. In a managed environment this is normally disabled via GPO/registry (bUpdater = 0 under the relevant Adobe policy key) so that patching stays centrally controlled through ConfigMgr rather than each machine silently updating itself on its own schedule — worth confirming this is set correctly if you’re seeing version drift across machines despite a ConfigMgr deployment being in place.