Detection logic is where application deployment fails silently. The application installs. The user can open it. The help desk has no tickets. And Intune keeps reinstalling it every few hours because the detection rule never returns true.
This happens more often than people expect, and it’s almost always a detection logic problem rather than an installation problem. Understanding why requires understanding what Intune actually does with detection rules – and why getting them wrong produces behavior that looks like success from the outside while creating unnecessary work for the platform and unnecessary noise in the deployment reports.
Intune uses detection rules to determine whether an application is installed on a device. After installation, the platform evaluates the detection rule on a periodic basis. If the rule returns true – meaning the application is detected – Intune considers the deployment successful and stops attempting installation. If the rule returns false – meaning the application is not detected – Intune assumes the application isn’t installed and attempts installation again. This evaluation loop is continuous for the life of the device. A detection rule that is inconsistent, unreliable, or simply wrong produces repeated installation attempts that consume bandwidth, generate log noise, and in worst cases cause application instability.
Detection logic doesn’t just confirm installation happened. It’s the mechanism Intune uses to decide whether installation needs to happen again. A bad detection rule means the application never stops being deployed.
For MSI-based applications, Intune can use the MSI product code for detection automatically. This is reliable when available – the product code is specific to the installed version and Intune queries it directly from the Windows Installer database. The problem with product code detection is that it’s version-specific. When the application updates to a new version with a new product code, the detection rule no longer matches and Intune considers the application uninstalled. For applications that update frequently, product code detection requires active maintenance of the deployment as versions change.
File-based detection checks for the existence of a specific file, optionally with a version comparison. This is the most flexible and most commonly used custom detection method. Done correctly – checking for a specific executable at a known installation path with a version requirement – file detection is reliable and version-aware. Done carelessly – checking for a file that ships with the OS, exists in a temporary location, or doesn’t uniquely indicate the application is installed – it produces false positives that make Intune think the application is installed when it isn’t, or conversely causes reinstall loops when the file is temporarily absent.
Registry-based detection queries a specific registry key or value. This is appropriate for applications that write reliable registry entries on installation. The caution is that registry entries aren’t always cleaned up reliably on uninstall – a detection rule that checks a registry key may return true even after the application has been removed, which prevents Intune from reinstalling when it should. Test uninstall behavior explicitly when using registry detection.
Custom script detection is the most powerful and most dangerous option. A PowerShell script runs on the device and Intune evaluates the exit code – zero means detected, non-zero means not detected. Script detection can handle complex scenarios that file or registry detection can’t – checking multiple conditions, querying WMI, validating configuration state alongside installation state. The risk is that scripts introduce their own failure modes. A script that throws an unhandled exception, times out, or produces unexpected output can return an incorrect result and cause detection to fail even when the application is correctly installed.
The best detection rule is the simplest one that uniquely and reliably identifies the application as installed. Complexity in detection logic is complexity in every evaluation cycle, on every device, indefinitely.
The most common detection logic mistakes in practice: checking a file path that exists on the OS regardless of whether the application is installed, using a product code that changes with every update without updating the detection rule, writing registry detection that survives uninstall, and writing PowerShell detection scripts that aren’t tested for the uninstalled state. That last one is particularly common – detection scripts are usually tested after installation, but the behavior when the application isn’t present is equally important and often not validated.
Test detection logic in both states before deploying to production: installed and uninstalled. The detection rule should return true in exactly one of those states, consistently, across different device configurations. That validation step is the difference between a deployment that works and one that silently generates reinstall loops for months.
Intune Deployment Guide · Phase 7: Applications
‹ Previous: [7.2] Packaging Models: Win32, LOB, MSIX, and When to Use Each
Next: [7.4] Assignment Intent: Required, Available, and Uninstall ›
