ConfigMgr: Using PowerShell for Application Deployment Detection Methods

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.


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.


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.



Contact Us

On Key

More Posts

WME Security Briefing 27 May 2024

Kinsing Hacker Group Exploits Docker Vulnerabilities Overview Recent investigations have shown that the hacker group Kinsing is actively exploiting Docker vulnerabilities to gain unauthorized access to systems. The modified hacker group targets misconfigured Docker API ports deployed with cryptocurrency mining malware.

Read More »
WME Cybersecurity Briefings No. 010
Cyber Security

WME Security Briefing 20 May 2024

Advanced Persistent Threats: North Korean Hackers Launch Golang Malware Overview A new malware strain, called Titan Stealer, is currently actively circulating in the threat landscape, targeting a variety of personal data and linked to North Korean state-sponsored cyber espionage

Read More »
WME Cybersecurity Briefings No. 009
Cyber Security

WME Security Briefing 08 May 2024

Exploitable vulnerability in Microsoft Internet Explorer, used to deploy VBA Malware Overview Cybersecurity researchers discovered a severe exploitation targeting a bug that had already been patched in the Microsoft Internet Explorer browser. Their report added that

Read More »
Be assured of everything

Get WME Services

Stay ahead of the competition with our Professional IT offerings.