Get Teams Notifications About Failed Custom Detection Scripts or Proactive Remediations

I’ve been developing a significant blog post that has led to several smaller ideas, including this one. Occasionally, a complex custom application or customization needs deployment across endpoints. For such scenarios, Win32 apps are often the ideal solution. However, this approach can also be employed for a proactive remediation script. This concept emerged from reconsidering the traditional role of a custom detection script. Technically, a custom detection script still runs on the endpoint, so can we enhance its purpose beyond merely detecting certain objects? Several weeks back, I wrote a post about troubleshooting custom detection scripts with multiple rules (Troubleshoot Intune Win32Apps with multiple detection rules – SMBtotheCloud). For instance, you might want to check for the existence of a file, a registry key, and gather some PowerShell output, all of which together define the detection for your software/customization. While we could analyze the IME log on the impacted devices to see which part of the rule is malfunctioning, it’s far more convenient to have that information sent directly to us in Teams when the detection rule fails.

It’s important to note that this isn’t a flawless solution. Before a Win32 app gets installed, the custom detection script runs to perform the detection. This step determines whether Intune will proceed with the installation. Thus, you’ll always encounter an initial failure for new machines or applications. The alerts for new apps and machines should be obvious, as not all custom detection rules will likely be met. To alleviate this, we could generate a dummy file during the initial run of the detection script. Based on the existence of that file, we can modify our output so that the notifications appear distinct after the first detection script run. I didn’t dive deeply into this here, but it would be a straightforward way to differentiate the initial detection script run from subsequent failed runs. If time permits in the future, I might refine this further. Regardless, this can serve as a template for other ideas. Here’s how to set everything up.

Configuring the Teams Webhook:

At a high level, Teams incoming webhooks enable external services to send well-structured JSON data directly to a Teams channel. If you’re curious to learn more, check this link – Webhooks and connectors – Teams | Microsoft Learn. The first step is to create your webhook. In Teams, right-click on the channel where you wish to receive notifications and select connectors.

Search for and create an incoming webhook:

Provide a name for the webhook and add a custom image if desired. The name will be displayed in the Teams messages. Click Create.

Copy and save the URL, then click Done. Your webhook creation is now complete.

The Custom Detection Script:

The custom detection script follows the same structure we’re used to, but in the else block, we include additional actions. I had a vision for how I wanted this to work, but I needed to discover how to send a correctly formatted message via an incoming webhook using PowerShell. For that, I referred to this post – How to Send a Message to Teams Channel with PowerShell? | Windows OS Hub (woshub.com). With a foundational understanding and an example in hand, we’re ready to create our custom detection script. Keep in mind that this script serves merely as a demonstration to show functionality. It’s designed to fail so we can generate a Teams message. Certain variables will need adjustments before you test with your applications. The script is also available on GitHub here.

1. The three variables $program1, $file1, and $reg1 are example values representing PowerShell output, a file, and a registry key you are checking for. Modify these for your rules.
2. $application should represent the name of your Win32 app, which will be shown in the Teams notification.
3. Insert your webhook URL as the value for the $myTeamsWebhook variable.
4. You can personalize everything under “Text” if desired. In the format I’ve used, it will display the hostname, the application name from the $application variable, and details about the failure. You will receive True/False results for the file and registry checks, along with the output from the $program variable. This helps identify which of the multiple rules has failed:

$program1 = $chrome = Get-Package -name '*zoom*' -ErrorAction SilentlyContinue | select -ExpandProperty "Name"
$File1 = "c:\temp\file1.txt"
$Reg1 = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP"
$filedetect = Test-Path $File1
$regdetect = Test-Path $Reg1
#
If (($filedetect -and $regdetect -eq $true) -and ($program1 -ne $null)) {
    Write-Output "App Detected"
    exit 0
}
else {
$hostname = hostname
$application = "MyWin32App"
$myTeamsWebHook  = "YOUR WEBHOOK URL"
$webhookMessage = [PSCustomObject][Ordered]@{
"themeColor" = '#0037DA'
"title"      = "Win32 App No Longer Detected"
"text" = "`n
Device: $Hostname `n
Application: $application `n
Failure Details: `n
$File1 = $filedetect `n
$Reg1 = $regdetect `n
Get-Package Name: $program1"
}
$webhookJSON = convertto-json $webhookMessage -Depth 50
$webhookCall = @{
"URI"         = $myTeamsWebHook
"Method"      = 'POST'
"Body"        = $webhookJSON
"ContentType" = 'application/json'
}
Invoke-RestMethod @webhookCall
exit 1
}

An Example Teams Notification:

Let’s execute a test against the installation of Zoom and observe the results. We can note the initial detection failure before the app installation, followed by another failure following an intentional misstep in the detection script. As mentioned earlier, expect to see at least one detection failure for new application installs, along with additional failures if the app detection does not succeed, as illustrated in the GIF below. To differentiate between the initial detection run and subsequent failures, you’ll need to devise some sort of indicator on the local machine and in the detection script that confirms the script has been run at least once.