This is an article in a continuing series on the new Application model in SCCM 2012. You can find a high level overview of applications and how they differ from packages here: SCCM 2012: Applications vs. Packages – (windowsmanagementexperts.com).
Detection methods allow the administrator to check software installs to ensure that the application is not already installed. It can also prevent an install of an application if it conflicts with another application that is already installed. Also, during the normal “Application Deployment Evaluation Cycle”, the SCCM client can detect whether an application is installed using these methods, even if the user did not use Software Center or the Application Catalog to install it.
Default Detection Types
There are three default ways that SCCM can detect an application. Any of these methods work great, especially given the granularity at which the administrator can define the method.
File System
The first method is file system. This method detects whether a file or folder is present on the system. If the file system object is not present, the application is marked as not installed. The administrator can mark it as just being present, or apply logic to say that the file or folder had to have been modified after a certain date or equal a particular file version (just to name a few). You can use the “Browse” button to find the file on your computer. This will pull in all relevant information, such as the file version or modified date. You can also use the “Computer name” box to connect to a remote computer (Windows Remote Management must enabled in your environment for this to work).
One important thing to watch is the “This file or folder is associated with a 32-bit application on 64-bit systems” check box. By default, if you are on a 64-bit system, SCCM will only verify against “C:\Program Files” or “C:\Windows\system32” for files or folders and not “Program Files (x86)” or “SysWOW64”. If the application installs to “C:\ProgramFiles (x86)” or puts something in “C:\Windows\SysWOW64” and you queue off of that file, SCCM will not find it. When the user attempts to run the application, it will install again, possibly corrupting it or making it unusable. These kinds of detection and deployment inconsistencies are a common reason organizations choose to modernize to Microsoft 365, where application deployment and detection logic are simplified through Intune, reducing errors and improving reliability across devices.
The second method is registry. The first thing to select here is the hive. You can select any registry hive you want. You can use the “Browse” button in the same way that you can for file system. You simply put the Key path in the “Key” box, and the value in the “Value” box. In the “Data Type” box, select the type of the data the value holds. If you must test for the data in a key, select the “This registry setting must satisfy the following rule to indicate the presence of this application” and fill in the data in the “Value” box.
I would caution against using a key in HKEY_CURRENT_USER. This hive is loaded per user, and every user’s CURRENT_USER hive is different. Using this hive will work if the application can only be installed per user, instead for all users on a machine.
As with the file system method, pay attention to the “This registry key is associated with a 32-bit application on 64-bit systems” check box. This checkbox needs to be checked if you are targeting a key on a 64-bit system that gets put into “HKEY_LOCAL_MACHINE\SOFTWARE\Wow64Node” or “HKEY_CURRENT_USER\SOFTWARE\Wow64Node”.
Windows Installer
The third method is Windows Installer. This method is automatically filled in when using an MSI install type. This method detects whether the MSI product code exists on the system. This method should only be used when dealing with an MSI. If you do not use the MSI install type, you can use the “Browse” button and find the MSI installer to automatically pull the product code.
For products that update, but keep the same product code, you can use the “This MSI product code must exist on the target system and the following condition must be met to indicate the presence of this application” options to specify the version of the MSI. A product keeps the same product code if it updates via an .MSP file. It is best to test these before deploying them.
Custom Detection
If you cannot adequately detect your application using one of the default methods, you can use a custom script. SCCM determines that the application is installed if the script returns successful. To use a custom script, select “Use a custom script to detect the presence of this deployment type”. Click the “Edit” button to bring up the script window.
From the edit window, there are three script types. You can select PowerShell, VBScript, or JScript, depending on your preference. If you already have the script typed up, you can hit the browse button to find it, and SCCM will import it for you.
Again, pay attention to the “Run script as 32-bit process on 64-bit clients” check box. SCCM must execute the script properly for it to detect the application.
Logs
It can be difficult to get these methods working if they are complex. There are two logs that you can reference to see what SCCM is doing. They are “Appenforce.log” and “Appdiscovery.log”. These will give you detailed information on what exactly SCCM sees when it runs the detection methods, and the subsequent result. Appenforce.log shows the actual install of the program, while the Appdiscovery.log shows the discovery engine testing the machine for the deployment method. These logs can be found in “C:\Windows\CCM\logs” and are viewable using the CMTrace.exe tool.
Summary
While complex, these new detection methods allow administrators to finely tune their installers to ensure that they only get to the devices that need them. Setting these detection methods up correctly will also give you a better count of machines that have something installed. Even if the user does not install the application from Software Center or the Application Catalog, their devices will still register as having the program. This is a huge step forward in software management. This final screenshot illustrates this fact. The application shown here was only converted from a package to an application a week before this article’s writing. All of the machines in this count installed this software before it was converted. These statistics are viewable just be clicking on the application in the SCCM console.
