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

6 Answers 6


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:

For 32-bit software on 64-bit Windows:

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.

  • 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. May 22, 2014 at 16:18
  • 1
    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.
    – Wes Sayeed
    May 22, 2014 at 18:15

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.

Adobe Reader Executable Contents

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

RequireOS=Windows 2000


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:

"ProductName"="Adobe Reader XI (11.0.06)"

From the MSI installer:

"ProductName"="Adobe Reader XI (11.0.06)"

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

From the user downloaded executable installer:


From the SCCM deployed MSI installer:


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.

  • 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. Mar 17, 2014 at 23:27

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 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. Mar 18, 2014 at 19:36
  • 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. Jan 29, 2015 at 16:42

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=''"
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.