Troubleshooting Application Evaluations in SCCM2012

OK, this will be a long post, but there's good stuff here.

First off, the GUIDs for installed software are located in the following locations...

For 32-bit Windows, and 64-bit software on 64-bit Windows:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

For 32-bit software on 64-bit Windows:
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

The problem you are running into is that the GUID string is incorrect. The MSI you downloaded from Adobe is the US English version, hence the 1033 in the 3rd part of the GUID string (1033 is the ANSI code page for US keyboards).

The EXE installer, however, is the MUI version, which has a GUID of {AC76BA86-7AD7-FFFF-7B44-AB0000000001} -- note the FFFF in place of the 1033, which means it's multilanguage.

In your detection method, you need to add an OR clause so it will recognize either GUID as a valid install.

Two gotchas you should also be aware of:

1) You should specify the version number in your detection method. All versions of Reader 11 have the same GUID (i.e. 11.0.1 is the same as 11.0.7) so it will cause your detection method to return a false positive if users are on an older version.

2) If you care about security patches for Reader, then you should know that Adobe releases their patches only for the MUI version. You cannot "upgrade" from, say 11.0.1 to 11.0.7 with their MSIs without doing an uninstall/reinstall of the whole product. If you try, it will just tell you the product is already installed (because the GUID is the same).

Here is the correct way to manage Adobe Reader with SCCM: You need two deployment types in your application.

1) Configure the 11.0.0 MSI just as you already have (make sure the detection method has the version number of 11.0.00 specified -- do not just use the GUID) and save and close it.

2) Go back in and add another deployment type. This time, select Script Installer as the type (SCCM does not handle MSP files natively). Point it to your MSP file and use msiexec /update (instead of the usual msiexec /i) as your command line. For the detection method, use the same GUID, but 11.0.07 (or whatever) as the version. Specify the first deployment type as its dependency. Then make sure the patch has a higher priority in the list. Now save and close it again.

Now, when a client that does not have reader installed requests the application, both will be installed. If the person already has the EXE version installed, it will be patched. If it's already patched, then it will just show as already installed.

So after a bit of research and realizing that it was Adobe Flash player that was giving me fits, I formed a possible hypothesis. From what I can tell, SCCM looks in the following WMI location:

Namespace: root\CCM\CIModels
Class: CCM_MSIProduct

From what little I know about WMI, this is created by the SCCM client, which makes a twisted kind of sense when you think about how SCCM works.

I got this location from the "Deployment Monitoring Tool" that you can get in the System Center 2012 Configuration Manager Toolkit. If you look in the deployments area and the Enforcement tab, you can look at the DiscoverySourceXML to see what the detection returned.

I just found this out today so I haven't been able to fully test it yet. This location could be just the results store for the application discovery process. So far, it's good enough to let me know what product codes work with the SCCM application evaluation process.

I really need an SCCM developer to see this and set me straight.

Extra Stuff

Powershell script to list WMI objects:

Get-WmiObject -Namespace root\ccm\CIModels -Class CCM_MSIProduct | Sort-Object ProductName |Format-Table ProductName,ProductCode,ProductVersion

Where can I see what the detection method is querying and what it gets back?

I don't think there is a way to do this natively in SCCM although in really wish there was, especially for Global Conditions. There's nothing more frustrating than building your Detection Log in the wizard, having it not work as you expected and you are left with the opaqueness of user interface as your troubleshooting information.

What I would do, is find a test computer (or preferably a VM so you can use snapshots) that is in the condition that breaks your Detection Logic, start ProcMon, run the Application Deployment Evaluation Cycle and see what you find.

When performing a "Windows Installer" detection, where does the system look for that GUID?

If my reading of MSDN is correct MSIs register the ProductCode in HKLM\Software\Classes\Installer\Products. A reasonable assumption is that the Application Detection checks that location, again you could confirm this with ProcMon.

As for your issue where the executable installer of Adobe Reader breaks your Detection Logic I did a little testing in my "lab" (i.e., my workstation) and was able to reproduce your issue.

I think all Adobe Reader executable does is unpack and run an MSI installer.

If you look at the contents of setup.ini you can see that all the executable does is start the MSI installer:

[Startup]
RequireOS=Windows 2000
RequireMSI=3.0
RequireIE=6.0.2600.0

[Product]
msi=AcroRead.msi

Either way, the installer did properly register the ProductCode so if that is all your running your Detection logic on there is no discernible difference between the two installation methods. However, if you do a compare of the Registry Keys for executable installer and the MSI installer you can see some differences:

From the executable installer:

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\68AB67CA7DA73301B744BA0000000010]
"ProductName"="Adobe Reader XI (11.0.06)"
"PackageCode"="08610D4D4ABC0E74BB0257B5EDD58107"

From the MSI installer:

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\68AB67CA7DA73301B744BA0000000010]
"ProductName"="Adobe Reader XI (11.0.06)"
"PackageCode"="26A6583616073E04583DBCA6F0289EEB"

The PackageCode is different. The Installation Sources should be different too.

From the user downloaded executable installer:

C:\ProgramData\Adobe\Setup\{AC76BA86-7AD7-1033-7B44-AB0000000001}\

From the SCCM deployed MSI installer:

C:\Windows\ccmcache\6f\

Notice that the SCCM deployed version came from the local CCM cache.

You can add these to your Detection Logic or Requirements as appropriate to correct detect this condition.

That makes sense, sccm won't detect when applications get installed outside of it. It uses a wmi table to keep track, that's why if one ever deletes the wmi repo to 'cure' corruption, it will reinstall all sms packages that are required for that workstation/user. In 2007 the wmi table was called SMS_InstalledSoftware, though I can't find what it's called for '12.

Now, I don't do Windows installer installations, but I know there is a wmi table called Win32_Product that holds the guids for installations you'd find in Add/Remove Programs, my guess is it looks there, though I could be wrong. A drawback is that if they install a different version msi (thus a different guid) then this won't show up in your detection, possibly.

What I do sometimes is a software inventory check on the .exe, to see if someone has this installed already and if so what version. I can't get around people taking it upon themselves to install apps outside of sccm, but that's policy and is not really what sccm is for.

I know its old but couldn't resist adding my piece especially about Win32_Product as it can have negative effects!

I can't comment on @Dotknuckle reply above so had to do a whole new reply. Win32_Product is a bad idea and takes longer because it re-registers every MSI read this. http://www.itninja.com/link/why-win32-product-is-bad-news

As for SMS_InstalledSoftware this also exists with SCCM 2012 and is under the namespace root\cimv2\sms it is a bit safer than Win32_Product and is also quicker.

The same probably applies to the CCM_MSIProduct class as to why it is quicker. I am using SMS_InstalledSoftware as it returns more information.

I have been using my own custom detection scripts in powershell that basically do something like this.

$SPSS22 = Get-WmiObject -namespace Root\cimv2\sms -class SMS_InstalledSoftware -filter "ARPDisplayName LIKE '%SPSS Statistics%' AND ProductVersion='22.0.0.0'"
If($SPSS22){return $true}

On occasion I get app not detected; even the logs say it installed without issue. But then it says not detected right below where it says returned error code 0; success.

Go to Add/Remove programs or do Windows-R and type appwiz.cpl look to see if the application is installed. If it shows then make note of the exact name as it shows in add/remove programs. Remove it. If it quickly uninstalls then there are bigger issues. What you have to do next is then open the registry editor and then press F3 to do a search. Type the name of the application as it was listed in add/remove. Once you start finding it in the registry you will either be deleted keys or values with a depends. You delete keys if it is some place like Uninstall, Install, Product, Feature in the registry. Needless to say be very careful with what you delete, you may break your computer. Once done, just do another search to ensure you deleted everything. Now try installing again via system center, if it installs then YAY! If it doesn't then there are still some underlying registry keys or values that need to be deleted.