Way back in 2013, we wrote a post entitled SCCM 2012: Application Deployment Detection Methods where we discussed the possible detection methods you could use in ConfigMgr 2012. We discussed using file detection, registry detection, MSI installer detection, and using a script for detection. This post assumes that you understand the concepts discussed in the first post.
In this post, we’re going to go a little more in-depth about how to use a script for detection. We’ll focus on using PowerShell, but VBScript and JScript are still options. I’m writing this post using ConfigMgr 1910.
Script Detection Basics
To use script detection, you need a basic understanding of scripting with PowerShell. You can use any cmdlets you like, assuming that those cmdlets are present on the computer where the application is being installed. You should write and test your script and the application on a computer with the lowest version of the Windows Management Framework (WMF) available in your environment. If you still have Windows 7 computers in your environment, this means doing all of this work from a Windows 7 computer, as Windows 7 will likely either have WMF 2.0 or 3.0. Windows 7 does not contain all of the cmdlets that a newer Windows 10 system will have, so you may see different results if this initial work is done from Windows 10.
Next, you need to be aware of how to return results to the ConfigMgr client to determine whether or not the application is installed. ConfigMgr takes the output of the script, whether that be exit codes, return values, etc. to determine whether or not the application is installed. I prefer a very simple method for doing this: return $true. As long as this is the only output of the detection script, ConfigMgr will consider the application installed. You will also need to suppress any other output to ensure that ConfigMgr behaves properly. Piping a cmdlet to out-null will usually do this (i.e. <script block> | out-null). We’ll look at this later in some examples.
Examples
We’ll look at two examples of a detection script. The first one is really simple and will only look at a file. We can do this by using the simpler built-in file detection, but this will be good to illustrate how the script method works.
So assume we have an application that installs Mozilla Firefox. I could use some PowerShell cmdlets to determine whether or not it’s installed based on files.
if ((test-path “$env:programfiles\Mozilla Firefox\firefox.exe”) -eq $false) { exit }
if (((get-childitem “$env:programfiles\Mozilla Firefox\firefox.exe”).versioninfo).fileversion -eq “74.0”)
{ return $true }
The first line detects whether or not firefox.exe is present, and if not, exits the script without returning anything to ConfigMgr. This will cause ConfigMgr to not detect the application. The second line checks the version of firefox.exe. As you can see, if the version check passes, I’m returning $true to ConfigMgr.
In the next example, I’m setting some BIOS settings on a Dell computer. I can use Dell’s cctk command line tool to query the BIOS. In this example application, I’m disabling PXE boot, so I need the script detection to make sure that PXE is disabled.
# test for presence of cctk
if ((test-path $env:ProgramFiles\Dell\cctk\X86_64\cctk.exe) -eq $false) { exit }
# set variable for compare
$detection = “embnic1=onnopxe”
# get current settings
$settings = $env:ProgramFiles\Dell\cctk\X86_64\cctk.exe –embnic1
# test settings, return if they match
if ($settings -eq $detection) { return $true }
Since I need another tool other than PowerShell to run this detection, I first check for the presence of that tool (cctk). Next, I set the detection variable ($detection) to what I expect the output of the command to be. Next, I run the cctk tool and save the output to a variable. Finally, I use an if statement to see if the detection variable and the output from the command match. If they match, I return my $true value.
Hopefully this helps illustrate this useful tool and some possible uses.
Disclaimer
All content provided on this blog is for information purposes only. Windows Management Experts, Inc makes no representation as to accuracy or completeness of any information on this site. Windows Management Experts, Inc will not be liable for any errors or omission in this information nor for the availability of this information. It is highly recommended that you consult one of our technical consultants, should you need any further assistance.
