Guide

ARP Identity for Intune Win32 Detection: Observed, Declared, and Why It Matters

How Haivix ranks Add/Remove Programs identity for Intune Win32 detection, separates predicted vs observed evidence, and exports a custom script.

By Haivix Team 3 min read
Abstract Haivix-style panels suggesting Windows app detection and registry identity

Packagers often detect Win32 apps with an MSI ProductCode, a brittle file path, or a hard-coded uninstall registry subkey. Experienced teams also use Add/Remove Programs identity — DisplayName, sometimes Publisher, and DisplayVersion — because those fields can survive ProductCode churn when names stay stable.

The Intune Detection Rule Generator treats ARP Identity as a first-class strategy: it ranks uninstall candidates, explains where each conclusion came from, and can export an Intune custom detection script that searches uninstall hives instead of requiring one fixed key path.

ARP Identity vs an exact uninstall key

Microsoft Intune registry detection wants a specific key and value. That works when the uninstall GUID is stable. It is awkward when vendors change ProductCodes across major upgrades while the ARP DisplayName stays recognizable.

ARP Identity flips the model: match the identity Windows shows in Apps & features, then exit 0 with STDOUT from a custom detection script. Portal multi-rule registry detection still ANDs every rule — a script gives controlled name/publisher/version evaluation in one place.

Observed, Declared, and Inferred

Haivix labels evidence so recommendations are not a black box:

  • Observed — found on an installed machine by the local PowerShell analyzer (live uninstall entries).
  • Declared — explicit installer metadata, such as MSI ProductName / Manufacturer / ProductVersion (predicted ARP until verified).
  • Inferred — a Haivix heuristic, such as self-update risk from known product names.

Predicted ARP from an MSI is declared evidence, not proof the app is installed. Confidence stays a packaging heuristic; provenance answers “where did this come from?”

UpgradeCode-aware ranking (without a new rule type)

When an MSI UpgradeCode is available, Haivix can boost ARP candidates whose DisplayName and Publisher match even if the uninstall key GUID is not today’s ProductCode. That helps across versions without inventing an Intune “detect by UpgradeCode” rule type — ProductCode detection remains preferred when a stable code exists.

If several uninstall entries compete, the workbench shows ranked candidates, flags close scores, and lets you pick a runner-up before generating the script.

What this is not

Haivix is focused on analyze → recommend → explain → verify → export. It is not a packaging catalog, PSADT wrapper, .intunewin factory, or Graph deployment ring system. Those are useful products; they are a different job.

Shareable community note

Short draft you can paste into packaging or Intune threads:

  • Built ARP Identity into our browser-local Intune detection workbench (Haivix).
  • Philosophy: DisplayName + optional Publisher + DisplayVersion — the same pattern packagers use manually.
  • Important split: Declared/predicted from MSI metadata vs Observed after install via a read-only local analyzer.
  • Export is a custom detection script (exit 0 + STDOUT), not AND-ed portal registry keypaths.
  • Still ranks MSI ProductCode first when stable; ARP Identity helps for EXE/post-install and ProductCode churn — not a one-size-fits-all default.
  • Provenance badges: Observed / Declared / Inferred so recommendations stay explainable.
  • Try it: https://haivix.com/tools/intune-detection-rule-generator/

Try it

Open the Detection Rule Generator, drop an MSI or import haivix-analysis.json after a test install, review the ARP candidates and provenance panel, then export the script or Graph artifacts. Always verify on a representative device in the same install context Intune will use.