I'm deploying several custom Win32 applications through Intune and need a dependable way to detect whether each installation succeeded. File or folder detection is not ideal because I also need to compare installed versions and reuse the approach for applications that are not packaged as MSI files.
For example, I packaged Kyocera printer drivers for Windows laptops. The installation itself works, but Intune reports the app as failed because my detection rule does not identify the installation correctly. What detection method do you use for custom PowerShell-based Win32 apps? Would creating a registry key and storing the installed version be a good organization-wide pattern, and are there any examples of scripts that compare that value with the required version?
3 Answers
Make the installation script responsible for both installing the software and recording its state. After a successful install, have it create a 64-bit registry key with a consistent path and a version value. The Intune detection rule can then check that key and require the value to be greater than or equal to the packaged version. Be careful to run the install and detection scripts in the same system or user context, and account for 32-bit versus 64-bit registry redirection.
Avoid using Win32_Product as a general detection method. It can be slow and may trigger MSI consistency checks or repairs on installed products. For MSI applications, use the MSI product code and version detection where possible. For everything else, a deliberately created registry marker with a normalized version string is usually easier to control and maintain.
For custom Win32 packages, a common pattern is to have the installer or install script write a registry value under a dedicated key, such as the application name, along with the installed version. Configure Intune to detect that registry value and use a version comparison against the required version. This is more reliable than checking for a file that might remain after an incomplete or outdated installation, and it works well for PowerShell-based installers and driver packages.
That is the kind of organization-wide approach I was looking for. I’ll test writing a dedicated registry key and version value from the installation script.
For printer deployments, the same idea works well if the script installs the driver or printer and then writes the registry marker only after every step succeeds. That prevents Intune from reporting success when the script stopped halfway through.