© 2017 Adobe Systems, Inc. All rights reserved.

Updated Feb 12, 2018.


10.x and later products support SCCM deployments and SCUP. System Center Updates Publisher (SCUP) is a stand-alone tool that is used in conjunction with Microsoft’s System Center Configuration Manager (CM hereafter) to allow administrators to more accurately and efficiently install and update software. Together, CM and SCUP are Microsoft’s latest change and configuration management solution that replaces older methodologies such as SMS and GPO. Unlike those technologies, CM provides features such as metering, asset intelligence, and improved remote client administration. For example, CM users can easily determine what products versions are installed including all dot and double dot patches without having to write a complicated query.

SCUP is a catalog system and is very convenient for those who use it, but doing so is not required. As the successor to SMS, SCCM can deploy without SCUP. Other supported deployment methods include bootstrapper and AIP.


This documentation is for administrators familiar with managing networked environments via CM. it is not intended to replace the CM documentation. For details about using CM and SCUP, refer to Microsoft’s documentation.

Available catalogs

SCUP files are hosted on a public server for manual or scripted download as needed. There are two types of files:

  • cab: cab files are the actual catalog.
  • xml: xml files contain a hash for verifying the cab file’s authenticity.

The following SCUP catalogs are available:

Update ready for distribution


System requirements

The SCUP catalogs DC products require the items documented at http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11940. In particular, SCUP 5.0 should be used. The use of 4.5 throws the error “The update failed SoftwareUpdateRules validation”.

Note that SCUP catalogs used to push updates from Win 8 & Windows Server 2012 require the latest version of WSUS v3.0 SP2 (3.2.7600.226) with the latest hotfix .

SCCM-SCUP basics


SCCM users should note that SCUP catalogs can’t deliver anything but a generic installer. Because enterprises use different configurations, there is no way for Adobe to provide installers tailored to individual organizations. However, MSPs do not change existing settings, and MSI deployments always involve using an MST to migrate settings.

Best practices

  • Update validation before deployment. Verify patch installation on the intended target for a manual install first (outside SCCM context).
  • Don’t test deployments during SCCM server changes
  • Be patient: While operations appear to return UI control back to the user immediately (i.e. Run Synchronization), some operations are batch processes that run in the background and take some time to complete.
  • Always Run Synchronization after integrating a SCUP catalog. Doing so ensures the WSUS and Configuration Manager Console gets synchronized.
  • Refresh often: Often once a task completes, updates may not appear in the various UI components and you may not see changes take affect. Always refresh using the Refresh link or context sensitive menu item.
  • Consider whether or not you should mark an expiration time (deadline) for publication. Once an update has expired, it will no longer be offered by the SCCM client. If you accidentally choose the wrong date or use the wrong UTC date setting, updates won’t be issued in the managed client.
  • Define boundaries for the managed environment.
  • Ensure all your managed clients are hosted within the desired domain, and that clients that should not be managed similarly are outside of that domain. For example, you could have an Active Directory Server define the managed domain; anything outside that domain will not be managed by my SCCM server.
  • Do not delete SCUP catalog components. Deleting the catalog component in SCUP simply deletes the SCUP reference to the package component (i.e. Reader English 9.3.3). Always expire a no longer used component to ensure its synchronized with the WSUS server and Configuration Manager Console before deletion. Otherwise, dangling pointers will prevent you from expiring the actual WSUS package component without some serious hacks.
  • Do not use prerequisite rules in the catalog.
  • For 10.x deployments, consider not using Supersedence as SCUP 4.5 does not support Supersedence properly.

Catalog import

This section provides a short example using SCUP 4.5.

There is one catalog for Reader and one for Acrobat. The file names are static, so scripted downloads should be relatively straightforward.


It may also be useful to understand the differences between quarterly updates, out of cycle patches, and the possible file types. While SCUP catalogs provide a way to automate installs, you should understand what gets installed and why. For example, Acrobat updating always involves installing every MSP update in order. Reader updates may involve quarterly MSI files that don’t require installing previous updates.

To import the SCUP catalog:

  1. Download the catalog for your product.
  2. In the SCUP Console, choose Actions > Import Updates.
  3. Choose Single Catalog Import.
  4. Choose Next.
  5. Browse to the downloaded catalog.
  6. Click Accept Adobe as a Trusted Publisher and then click OK.

After import, the a summary screen displays information about the current updates. You are now ready to deploy updates using the CM-defined workflow.

SCUP: Imported update catalog


Troubleshooting FAQs

Why does my install fail with a “dependency does not exist” error?

When the WSUS database is not properly synced, you may see the following error:

PublishItem: Update 'Reader XI English Upgrade (UpdateId:'
c448bd67-9e61-42d7-9a22-f87c14ef28a0' Vendor:'Adobe Systems, Inc.'
Product:'Adobe Reader')' cannot be published as its dependency
'59653007-e2e9-4f71-8525-2ff588527978' does not exist in both
the updates publisher database and in WSUS. Updates Publisher

To fix this issue, resync the WSUS database to get the requisite public detectoids. There is no way to push these through SCUP as it is used for only third party updates. The dependencies listed in your log are the detectoids for X86 and x64 based systems described by Microsoft:

  • x86-based systems: 3E0AFB10-A9FB-4c16-A60E-5790C3803437
  • x64-based systems: 59653007-E2E9-4f71-8525-2FF588527978

These are not authored by Adobe and as per the message in the log must be present in the WSUS database.

Why don’t I see all the updates after importing the SCUP catalog?

Sometimes there are refresh issues on the backend and the latest update might not appear immediately after a release. If this happens, verify the update appears in Microsoft’s list of partner catalogs. You an also import the update manually or post on the Adobe forum.