Troubleshooting Application Evaluations in SCCM2012

I am running into an interesting issue with some applications not evaluating properly in SCCM 2012. The example software I have is Adobe reader 11. When I install using an MSI deployment through software center, everything works great. The problem comes up when someone goes to the adobe website and downloads the executable installer and runs that. Now software center detects the software as uninstalled and will list is as an available title.

I am using the "Windows installer" detection method and looking for this GUID "{AC76BA86-7AD7-1033-7B44-AB0000000001}". When I look in the AppDiscovery.log, all I get is an "+++ Application not discovered." message.

So here's the question: Where can I see what the detection method is querying and what it gets back?

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

Thanks in advance

Solution 1:

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.

Solution 2:

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