MDM Essentials 3 - Custom Detection Methods (Win32 Apps)
Intune currently offers a couple of well known detection method rule types by default in Intune Win32 Apps:
1) Detect by File,
2) Detect by Registry,
3) Detect MSI.
These can be used in combination with each other, but only in an “AND” capacity, not “OR”. Up to 25 detection methods can be added, mixed, and matched from these rules, but all of them must be met in order for the Win32 App to be detected.
If the default detection methods for Win32 Apps are not quite covering your needs, custom detection methods can be a great help - if you can test for it in PowerShell, you can create a custom detection method with it.
What could I detect that the native rules can’t?
Here are a few ideas to get you thinking
I want to detect the version of a BIOS. You can use Get-CimInstance to get the version of a BIOS from Win32_BIOS, and then compare it to the version you desire, Custom Detection Method - BIOS Version
I want to ensure that a new config file has been delivered as part of the install. You can use something like Get-FileHash to verify the exact hash value for a file (associated with your app) has been installed, Custom Detection Method - File Hash
I want to detect some security settings (unsupported in Intune Configuration Profiles) that I have delivered using a Win32 App. You can pull them out of the operating system, store them in variables or arrays, and compare them to your model/ideal values.
Considerations when writing a Custom Detection Method script
When working with custom detection methods you need to plan your PowerShell scripts carefully. If you want to detect “success” you need your script to exit with success (exit code “0”), but also write some output to “STDOUT” from your script using “Write-Host” or “Write-Output”.
Peter van der Woude uses the table below, in this excellent article on the subject, to illustrate this:
Or alternatively, if your brain works like mine, it might be easier to visualise it like this:
An example could be as simple as:
if (Get-Item “C:\Program Files\HeathKellyConsultingApp\CustomConfig.xml”) {
Write-Host "I found it!"
Exit 0}
else {Exit 1}
This script will successfully return “Detected” to Intune if “C:\Program Files\HeathKellyConsultingApp\CustomConfig.xml” exists. Notice the blue text will provide data for STDOUT using “Write-Host”, followed by exit code of 0 using “Exit 0”.
But it could also be simplified to:
if (Get-Item “C:\Program Files\HeathKellyConsultingApp\CustomConfig.xml”) {
Write-Host "I found it!"}
else {}
It is not compulsory to manually supply the exit codes yourself, as the default exit code from your script will be “0” anyway, as long as it doesn’t hit a terminating error. You really only need to supply some output text to STDOUT in your planned “Detected” block of PowerShell, and provide no STDOUT at all in the “Not Detected” areas of your script.
Test for the unexpected before uploading to Intune
Prepare to test your new custom detection method script thoroughly against the desired results. You might find that another function you are using is writing to STDOUT (causing unexpected “Detected” results), or perhaps it returns a terminating error that you don’t care about - you may need to catch and discard it…
Example tests - I want the registry value to be “1” to indicate “Detected”:
Test what happens if the registry value is “2”,
Test what happens if the registry value doesn’t exist,
Install your Win32 App and run the script again - does it now return “Detected”?
Once you get confident writing custom detection method scripts you’ll be able to solve a lot of challenges using Win32 Apps!