Detection Failing on x86 Devices

[Scott Fairchild]

Detection is failing on x86 Devices on for multiple x64 applications. I'll use Notepad++ 8.4.8 (x64) in this example.

I have an All Workstations collection that contains both x86 and x64 devices. I deployed Notepad++ 8.4.8 (x64) as available. On x86 devices AppDiscovery fails with the following error:

In-line script returned error output: Get-ItemProperty : Cannot bind argument to parameter 'Path' because it is null.
At C:\Windows\CCM\SystemTemp\b84e7186-f1f3-4ebe-9979-7d335070f026.ps1:532 char:47

I dug into the detection script and see $Architecture = 'x64'

When the script runs the Get-PMPInstalledSoftwares function, it checks if it is running on a 64bit system, and since it is not, it does not set the $PathsToSearch variable, which is why I'm getting a Null error

The code is

if (-not ([IntPtr]::Size -eq 4)) {
   'Software\Microsoft\Windows\CurrentVersion\Uninstall\*'
}

If I set $Architecture = 'Both' the script runs fine.

I cannot edit the detection script directly in the console. I had to copy the script to an external file, set $Architecture = 'Both', delete the digital signature and then import the script. After that the detection logic worked.

Even though the Requirements on the application are set to only x64 Operating Systems, the detection logic always runs first before Requirements are checked.

I would rather not have to manually update the detection logic every month.

Is there an easy solution to this issue?

Thanks,
Scott

[Spencer (Patch My PC)]

Hey Scott,

Based on this post it soundd like you're trying to install a 64-bit update on a 32-bit device (OS). Since those applications/updates can't be installed on a 32-bit OS the detection has been coded to show as not applicable when trying to install a 64-bit product on a 32-bit OS.

I would recommend create a separate collection with those 32-bit devices then target all 32-bit updates to that specific collection. That should help resolve any errors in the AppDiscovery Log since those updates will be applicable.

[Spencer (Patch My PC)]

Hey Scott,

After talking with the Devs here, we may have some ideas of how to better tweak the detection logic to help in these scenarios.

Check back with us soon and we may have a solution for this!

At this time however, the suggestions above may help you in the meantime!

[Scott Fairchild]

I'm not trying to install x64 apps to x86 devices. The Restrictions on the deployment will prevent that. I just advertised an x64 application out to All Workstations.

I could split out the collection to All x86 Workstations and All x64 Workstations, but then when deploying monthly patches and other software, I'd have to do it twice, instead of just once like I do today.

I understand the workaround, but since collections can contain both x86 and x64 devices based on any criteria in the query rule, it is not practical to create two collections for every rule.

In the SCCM console on the Monitoring node under Deployments, the x86 devices are showing Error - Evaluation failed, instead of showing up in the Requirements Not Met tab. Once I updated the detection script setting $Architecture = 'Both', the x86 devices now show up on the Requirements Not Met tab. This is the functionality I am looking for.

It's not a critical issue, as it just affects reporting, but I wanted to bring it to your attention in case other clients are in the same situation.

I'm looking forward to what the devs have to say.

Thanks,
Scott

[Spencer (Patch My PC)]

Completely understand the issue and thank you for bringing this to our attention! I see now how this can affect reporting and since the requirements are handling the architecture portion then the detection scripts should just identify and check for both architecture types.

We'll need to check and see how this will affect other products but now that this is on our radar, we can get it addressed!