Tag: 0x87D30006

Intune Win32 App Detection Woes? The Registry Path in Manual Detection Rules Might Be Your Culprit!

Are you an Intune administrator tearing your hair out over Win32 app deployments that report "The application was not detected after installation completed successfully (0x87D1041C)"? Or perhaps you're getting the cryptic "Invalid detection rule or unable to parse detection rule (0x87D30006)" error?

If your app installation seems fine, but Intune just won't acknowledge it, and you're relying on registry key detection, especially for user-specific settings (HKCU), you've landed on the right page. This post will detail a common pitfall and how I recently overcame it, hopefully saving you hours of troubleshooting!

The Scenario: User-Context App, HKCU Registry, and Frustrating Errors

I was deploying a Win32 application through Intune, specifically an Outlook add-in, that needed to modify settings in the current user's registry hive (HKEY_CURRENT_USER). My installation script successfully set the LoadBehavior for the add-in to 2 (disabled) under HKCU:\SOFTWARE\Microsoft\Office\Outlook\Addins\.... Outlook on the target machines was 64-bit.

Everything seemed to work on the client side: the add-in was disabled as expected, and I could confirm the registry entries were present and correct in regedit.

However, Intune stubbornly reported:

  • 0x87D1041C: "The application was not detected after installation completed successfully."

This was incredibly frustrating. The app was installed and configured. Why couldn't Intune see it?

Initial Suspicions (and why they weren't the main issue here)

Like many, my first thoughts turned to:

  1. 32-bit vs. 64-bit Registry Redirection (WOW6432Node): This is a classic trap. If a 32-bit app writes to HKLM\SOFTWARE on a 64-bit OS, it gets redirected to HKLM\SOFTWARE\WOW6432Node. But in my case, Outlook was 64-bit, and the registry path was HKCU, which generally doesn't involve WOW6432Node redirection in the same way. So, this wasn't the culprit.
  2. Timing Issues: Could Intune's detection scan be running too quickly, before the registry entries were fully committed? While possible, it's less common for direct registry writes in HKCU after an installer completes.
  3. Typos in Path/Value: Double and triple-checked – the paths and value names were correct.

The Real Culprit: Intune UI's Specific Registry Path Syntax

After much digging and trial-and-error, the issue boiled down to a subtle but critical detail: the precise syntax expected by Intune's manual registry detection rules, especially for HKEY_CURRENT_USER.

My instinct, coming from a PowerShell background, was to use HKCU:\SOFTWARE\Microsoft\.... When that didn't work, I tried SOFTWARE\Microsoft\... (omitting the hive altogether), which led to a new error:

  • 0x87D30006: "Invalid detection rule or unable to parse detection rule."

This error was the key! It told me that Intune wasn't just failing to find the key; it couldn't even understand the format of the path I was providing.

The Solution:

There is not definitive guidance from Microsoft on the correct and expected values in application detection rules when it comes to Registry rules. The documentation, though subtle, points to the answer: Intune's manual registry detection rule UI expects the full, standard Windows registry hive name (or its traditional short form) without a colon after the hive, followed by a backslash.

For HKEY_LOCAL_MACHINE, this is commonly seen as HKEY_LOCAL_MACHINE\Software\... or HKLM\Software\....

Following this logic, the correct syntax for my HKEY_CURRENT_USER detection rule was:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Outlook\Addins\ShoreTel.CASConnHostAddIn

And similarly for the second add-in:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Outlook\Addins\ShoreTel.UCBAddIn

Once I updated the "Key path" in my Intune Win32 app detection rules to this precise format, the app instantly detected correctly, and my deployment reported "Installed"!

Key Takeaways for Intune Registry Detection:

  • For HKEY_CURRENT_USER: Always use HKEY_CURRENT_USER\ as the prefix for your Key Path in Intune's manual detection rules.
  • For HKEY_LOCAL_MACHINE: Use HKEY_LOCAL_MACHINE\ or HKLM\ as the prefix.
  • Avoid PowerShell PSDrive Syntax: Do NOT use HKCU:\ or HKLM:\ in the Intune UI's "Key path" field for manual detection rules.
  • Leverage IntuneManagementExtension.log: For any detection issues, the log file at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log on the client device is your best friend. Search for your app name or "Detection" to pinpoint the exact failure. It will tell you if the rule failed to parse or if the value didn't match.
  • 32-bit vs. 64-bit on HKLM: Remember the "Associated with a 32-bit app on 64-bit clients" checkbox for HKLM paths if your app is 32-bit and running on a 64-bit OS. (This wasn't an issue for my 64-bit Outlook and HKCU paths, but it's a common trap!)

I hope this detailed explanation saves you the headaches I experienced. Share your own Intune troubleshooting tips in the comments below!

Verified by MonsterInsights