Adobe products are notoriously difficult to patch and manage. And Adobe hasn’t done us any favors by incorrectly authoring their latest msp release 9.3.2 so that it cannot be consumed by SCUP (System Center Update Publisher). The purpose of this post is to provide a work around to leveraging SCUP to consume improperly authored msp updates. I make no claims that it is a pretty work-around but it works and that’s what counts in the end.
I dusted off my old friend SMS Installer and my intent is to wrap the Adobe Acrobat msp in an exe. A screenshot of my installer script follows – I decided it was best to wrap the payload in the exe as well so I used the Install file option. I know I could have wrapped in an msi but I didn’t want to risk SCUP balking at an improperly authored msi and the exe was the simplest to create.
OK now that I have it all wrapped up in an exe it was back to SCUP and creating the actual update.
So for my Pre-requisite Rules I used the Basic Rule for Windows Architecture and included both x86 or x64 – remember pre-requisite rules are high level rules so keep them as simple as possible and as high level as possible – Essentially when Windows Update scans for an update the first rule it evaluates is the pre-requisite rule if the system doesn’t evaluate to true no further scanning for that update is done.
Next I needed to define my Applicability Rule – Now all of this could have been much simpler for me had I been able to consume the msp directly as SCUP simply scrapes the applicability logic right out of the msp (msp know whether or not they can update or not). I decided to use the MSI Patch Installed Rule – Ill need two of these rules since the 9.3.2 msp can patch both 9.3 and 9.3.1 versions of Acrobat – Also keep in mind that if you have multiple products ids for the various installs of Adobe Acrobat base you’ll need rules for those as well. Lucky for me in this scenario I only had the single base install product code to deal with. The example of one rule follows.
Now the msi product code is fairly easy to grab and if the msp was engineered nicely you might be able to scrap the patch id from the registry. But nothing comes easy with Adobe – I used ORCA to look at the details of the msp’s for the previous patch versions (you’ll need to look at both 9.3 and 9.3.1 to capture the patch ids.
And finally I needed to define the Installed Rule – I decided to go with two detection rules – File Version and MSI Patch Installed – An example of the file version rule follows:
OK now we have a Adobe Acrobat Standard/professional patch ready to inject into SCCM and deploy using Software Updates.
My apologies to all the ConfigMgr Admins out there who are outraged by my wrapping a perfectly usable msp into an exe – I know it screams against everything we prefer as far as deployable and manageable – The solution is provided as a quick and dirty work-around to a very annoying problem with an incorrectly authored msp.
The GOOD NEWS is Adobe did manage to correct that problem with its Reader 9.3.2 msp and that can be consumed just fine using SCUP and the msp as is unwrapped.
Adobe is working to correct some of these things as announced at MMS2010 this year but they are a big company and the product groups inside Adobe are silo’d so getting all the dev teams on the same page can be a challenge – in the meantime I hope my work around helps someone. Just one little disclaimer – This shouldn’t be your standard nor regular approach to creating updates in SCUP – By order of preference when creating updates in SCUP they should come in one of the following forms:
MSP – The BEST if authored correctly – SCUP does a schema check and will fail if the msp doesn’t pass mustard – For guidance on creating msps – check out this website: http://msdn.microsoft.com/en-us/library/aa370578(v=VS.85).aspx
MSI – The next best option
EXE – Binary payload type of the last resort