Troubleshooting Application Evaluations in SCCM2012

Question

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

Comments

[Doltknuckle]

Thank you for the long response. I've seen that area in the past and it's a red herring for SCCM deployments. SCCM is looking looking elsewhere when you perform the "Windows Installer" detection method. I'm sure I could add it into the logic, but I'm looking to avoid checking multiple places for the presence of the app. To make something work, I need to match the GUID to a location that have the version number. If I don't, I won't be able to perform minor updates.

[Doltknuckle]

I did find a class that seems to hold the information (Namespace=root\CCM\CIModels;Class=CCM_MSIProduct). When I install an MSI file, both this location and the Win32_Product update with the GUID and such. What's really interesting is that the CCM_MSIProduct is a lot faster at returning a query result in powershell. Don't know if that is significant.

[Doltknuckle]

It's important to note that the "unistall" registry location is used to list programs in the "Uninstall a program" section of the control panel. From what I can tell, this could be deleted and msiexec will still be able to find the package if you feed it the "/x {GUID}" command. For 99% of all programs, I can use this location to detect programs, but it is not an authoritative source.

[Wes Sayeed]

It is true that MSIs can be "pre-staged" to a computer without actually being installed. But the Uninstall registry keys can be considered authoritative because that's where SCCM builds the SMS_G_System_INSTALLED_SOFTWARE table from. And it populates that table from the Win32_Product WMI class (which uses the uninstall keys as well). If such a pre-staged MSI were present on the system, SCCM would not be able to detect it.

[Doltknuckle]

That is an interesting bit of info. The link you gave didn't return a page so I did some google searching. Found these pages to backup this statement: blogs.technet.com/b/askds/archive/2012/04/19/… ::: myitforum.com/cs2/blogs/gramsey/archive/2011/01/25/…

[Doltknuckle]

BTW - After some help from @d4rkcell it turns out that Win32_Product does more than just hold data. The TLDR result of this info is to stay out of this WMI Class.