SummaryCopy Link

Customers deploying the ARM64 variant of an update, such as Microsoft Edge, in Intune may see it report as Installed on x64 devices, even when the Intune requirement rule is configured to target ARM64 systems only. This article explains why this happens, the current impact, and recommended workarounds while a permanent fix is developed.

SymptomCopy Link

  • An x64 device shows a deployment status of Installed for the ARM64 update app, even though ARM64 app was never installed on that device.
  • This typically occurs on devices that already have a sufficiently current x64 build of the app.
  • Some devices in the same targeted group may correctly show Not applicable, which can make the behavior look inconsistent.

Root CauseCopy Link

The detection script used by each update checks for an existing install (in 2 stages if it’s an MSI):

  1. Primary check for MSI (MSI product code match)
    Each architecture variant of an update has its own unique MSI product code, so this check is architecture-safe by design. A GUID match can only occur if the matching architecture’s variant is actually installed.
  2. Primary check for EXE / Fallback check for MSI (Application name and version)
    If no GUID match is found, the script falls back to checking whether any uninstall registry entry named, for example: “Microsoft Edge”, meets or exceeds the target version. This fallback does not inspect architecture on its own, because, using this example, Edge’s display name is identical across x64 and ARM64 installs, and the version number does not indicate CPU architecture.

Using Edge as an example again, the x64 variant update script’s fallback check includes an additional safeguard. It also verifies an Edge update registry value (ap) contains an x64 architecture tag before confirming detection.

Edge’s ARM64 variant fallback check does not currently include an equivalent architecture safeguard. As a result, using our previous example, if a device has any Edge installed (of any architecture) at or above the target version, the ARM64 script’s fallback path can report the update as already present – regardless of whether ARM64 Edge is actually installed.

Note: The Win32 app evaluation order dictates detection runs before requirement rules. If detection reports the app as already installed, Intune records the app as Installed and does not evaluate the requirement rule at all. The requirement rule is only evaluated when detection reports the app as not installed. At that point Intune checks whether the device meets requirements, and marks the app Not applicable if it doesn’t.

ImpactCopy Link

This behavior affects only the deployment status displayed in Intune. No ARM64 software is installed, modified, or attempted on x64 devices as a result of this behavior. The ARM64 installer cannot execute on x64 hardware, and in this scenario Intune does not attempt an install action at all, since detection has already reported the app as installed.

The practical impact is limited to reporting accuracy. Deployment status for the ARM64 update app may show devices as Installed when they should show as Not applicable, making it difficult to use Intune’s deployment status view to distinguish which devices genuinely have the ARM64 build versus which have a different architecture’s build at the same version.

Current StatusCopy Link

Our team is looking to update the ARM64 detection script’s fallback logic to include an architecture check equivalent to the one used in the x64 script. This will close the gap so the fallback path only matches Edge installs of the correct architecture. This KB will be updated once the fix is released.

Until the updated detection logic is released, we recommend using Intune assignment filters to restrict the ARM64 Edge update app to ARM64 devices, in addition to the existing requirement rule.

  • Filters are evaluated at assignment, independently of both the requirement rule and the detection script, so they provide an additional, more reliable architecture gate.
  • Example filter rule: (device.deviceManufacturer -eq "value") and (device.cpuArchitecture -eq "arm64"), or filter directly on device.cpuArchitecture -eq "arm64".
  • This does not fix the detection script itself, but it prevents the ARM64 app from being assigned to x64 devices in the first place, which avoids the false “Installed” result from ever being evaluated.

We recommend applying this filter as a precaution on any architecture-specific app deployment, since the requirement rule alone will not stop the ARM64 app from reporting Installed on an x64 device once the detection script has produced a false positive. Filters avoid this by preventing the app from being assigned to the wrong architecture in the first place, so the false detection result is never evaluated at all.