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.

Deploying updates through ConfigMgr is one route. The other, older approach is to publish them into Windows Update itself, so they arrive the same way any Microsoft patch does — see delivering Adobe updates via Windows Updates using SCUP and WSUS, which also stops the Adobe updater nagging users who do not have local admin rights.