#productcode

A short, versatile domain ideal for a product model, tech project, or internal tool. Compact, brandable, and easy to integrate.

Something we came across this week is how the Detection Method by Registry in SCCM 2012 really works.

I’ll start by saying that I’m a big fan with this whole new Detection Method feature. I made a lot of scripting in the past to come around this functionality, and I was very excited when I first heard that SCCM 2012 was going to come with this option built right in. Of course, AppV and MSI packages, being treated natively by SCCM, make it even easier when it comes to detect the presence of these package formats on a given computer. But when there’s the need to use a « script-like » package (aka: other than MSI or AppV), you absolutely have to enter a way to detect the presence of such package.

I have to say that my current customer is very stubborn to use AppV or MSI every way possible – which is absolutely fine by me! When you’ve made packages in a « pre-MSI era » like in my case, MSIs and AppVs are such a charm! But we came across a problematic MSI package (graciously provided by McAfee) where we needed to update the Endpoint Encryption Agent but have been provided with a newer version that contains the exact same ProductCode GUID as the current version has, which is a no-no in Windows Installer best practices. We first had the idea to rename the ProductCode by generating a different GUID right in the MSI provided by manufacturer , but this is also not recommended particularly when a customer risks having his support voided by the vendor. The manufacturer has no intention to correct this mistake as they claim it is their way to have his clients avoid deploying two (2) different versions of their agent (it’s crazy how so many people have no idea how the UpgradeCode property works).

Anyway, we had to treat this MSI with SCCM2012 as if it were a « script » package format and had to come up with a Detection Method which we found a registry entry for. This is where we stumbled! Something we thought would be fixed in seconds got us to dig a little deeper. In fact, even books and Internet references had very little to say about this.

To summarize our findings, let just say that the way Microsoft uses the registry terminology in SCCM2012 is not quite accurate.

Let’s take the following fictitious as an example:

They way Microsoft refers to each of these registry components: • HKLM\SOFTWARE\VMware, Inc.\VMWare Tools = the Registry Key • InstallPath = The Registry Name • REG_SZ = the Registry Type (or Registry Data Type) • C:\Program Files\VMWare\VMware Tools\ = the Registry Data or Registry Value

So, now looking at the Detection Rule by Registry Clause and trying to fit our chosen Registry entry for our problematic MSI:

Our first reflex is to think that the “Value” field located in the middle of the Clause window really means the “Registry Value” (or “Registry Data” depending on how you call it), which forces us to think that the Registry Name should be appended to the complete Registry Key.

The result was really not what was expected: SCCM kept reinstalling the updated version Endpoint Encryption Agent again and again, never finding the given registry key.

Reflecting on how this Detection Method by Registry really works, we’ve re-disposed the different registry information as such:

• « Key » = The actual Registry Key as it should be referred to • « Value » (the one in the middle of the Clause Windows) = The Registry Name • « Data Type » = the actual Registry Data Type • Then : choose your « Operator » (we used the « Equals » for our specific need here) • And finally the last « Value » field at the bottom = the actual Registry Value