MSI product codes, patch codes and registry keys

Once again I’ve been spending time deploying software patches via SCCM using the newer state-based Application model and this time I thought I’d write down some of my notes.

In the SCCM 2012 R2 Application model you can use the ‘New Application’ wizard in the SCCM console to import an .MSI file. This extracts all sorts of useful stuff from the installer file which SCCM then uses to automatically populate Application settings to do with things like the install/uninstall string for the MSI; and often, most critically, the application-detection rules which the CM client will use to detect whether the product has been installed.

It is this last bit of information that is probably the most useful since you can specify application-detection rules which the CM client will use to determine:

1. Whether the required software is present and so should be installed or not
2. When an install completes another check is run to see if the product is now detected*
3. During Application Deployment Evaluation Cycles (by default every 7 days) whether the required software is currently installed

* If the product fails to be detected post-install then this gets reported back up to SCCM and you’ll see it in your Deployment reports regardless of the exit-code of the installer.

However, at the present time SCCM 2012 R2 still doesn’t have a built-in, supported way of importing an .msp (patch) file as it does with .msi files. Now, as is the case with .msi files, there can be simple scenarios where you define application-detection rules by simple criteria such as the version number of an on-disk executable. This often works for MSI installers but not always with MSP patches because vendors do not always update all files in a given patch. Indeed, it would be sufficient if they updated, for example, the main-executable on each patch with the new version number, but sadly this doesn’t always happen.

The option I’m often left with is figuring out exactly what the detections rules should be and, to a lesser extent, what the MSI uninstall string should be. Now, the uninstall string is relatively simple:

1. Grab yourself a copy of Orca
2. Open up the MSI/MSP file using Orca
3. Use the menus to go to: View > Summary Information

msiexec /x {0D4BCDCD-6225-4BA5-91A3-54AFCECC281E}

MSP files are a little bit different in that Orca will display 2 values: “Patch Code” and “Targets”.

The real challenge, however, comes when you need to create the SCCM detection-rules for the MSP.