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. CM provides features such as metering, asset intelligence, and improved remote client administration. For example, CM users can easily determine what product versions are installed (including patches) without having to write a complicated query.
This documentation is for administrators familiar with managing networked environments via CM. it is not intended to replace the CM documentation.
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:
Reader Classic track 2020 transition catalog:
Update ready for distribution
The SCUP catalogs require items defined by Microsoft.
Use SCUP 5.0 or later. The latest tested version is 6.0.283.0.
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.
Update validation before deployment. Verify patch installation on the intended target for a manual install first (outside the 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 get synchronized.
Refresh often: Often once a task completes, updates may not appear in the various UI components and you may not see changes take effect. 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. Always expire a no longer used component to ensure it’s 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.
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:
Download the catalog for your product.
In the SCUP Console, choose Actions > Import Updates.
Choose Single Catalog Import.
Browse to the downloaded catalog.
Click Accept Adobe as a Trusted Publisher and then click OK.
After import, 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
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 can also import the update manually or post on the Adobe forum.