The situation
A recurring vulnerability-management problem
Adobe applications were deployed through the Creative Cloud Desktop application, but automatic updates were not enabled. During routine vulnerability-management work, applications such as Photoshop appeared consistently in reporting because installed versions were falling behind.
I investigated the cause and researched Adobe's enterprise update mechanisms. That led me to Remote Update Manager (RUM), a standalone Adobe utility capable of triggering updates for installed Creative Cloud applications.
The design
Using inventory to make targeting automatic
I created an SCCM collection for each patchable Adobe application. Dynamic membership rules used the existing application inventory to identify devices in scope. Keeping the collections application-specific meant that future installations could be detected automatically, including applications that were not present in the estate when the solution was first built.
The individual collections then fed a deduplicated master collection. This provided one definitive group of devices requiring RUM, without repeatedly targeting machines that had several Adobe applications installed.
- SCCM inventoryDetect installed Adobe applications
- Application collectionsMaintain dynamic device scope
- Master collectionDeduplicate update targets
- AD group and GPODeliver and schedule RUM
Integration
Connecting SCCM targeting to Group Policy
SCCM could consume Active Directory group membership, but it did not natively provide the reverse synchronisation needed by this design. The organisation already had a SCORCH-based function that could reproduce an SCCM collection's membership in an equivalent AD group.
I then used Group Policy to target the synchronised AD group. The policy copied the RUM executable to each device and created a weekly scheduled task. RUM ran in the system context with the required administrative permissions, so updates did not depend on a user being signed in.
The scheduled command used RUM's update-all behaviour. SCCM determined which devices needed the mechanism; RUM handled the compatible Creative Cloud applications installed on each device.
Validation and rollout
Piloted before controlled release
I used an Adobe trial licence to reproduce the scenario and pilot the complete workflow on my own device before releasing it to the managed estate. The production rollout then passed through the organisation's formal change-control process.
RUM logging was enabled to support troubleshooting and verification, while SCCM collection membership provided visibility of the devices being brought into scope.
Scale and outcome
A small device group with broad application coverage
The final scope was relatively small—approximately 30 devices—but covered around 20 individual Adobe applications. That made automated targeting worthwhile: the number of application and device combinations would otherwise have created recurring manual maintenance.
Vulnerability reporting appeared to improve following implementation, although no formal reduction metric was recorded. The solution remained owned by the Operational Development team and was still operating when I left the NHS.
Engineering principle
Integration before reinvention
The solution did not depend on introducing another management platform. It combined inventory, orchestration and policy capabilities that already existed in the environment with Adobe's supported update utility.
The useful engineering decision was not simply to automate RUM. It was to make SCCM inventory the source of truth, reuse an existing integration between platforms and ensure that future Adobe installations entered the patching process automatically.
That changed Adobe maintenance from a repeated response to vulnerability findings into a scheduled process that could continue after the original implementation work was complete.