{"id":493,"date":"2025-02-20T12:35:00","date_gmt":"2025-02-20T11:35:00","guid":{"rendered":"https:\/\/digitalmaterial.ch\/blog\/?p=493"},"modified":"2025-02-18T07:47:45","modified_gmt":"2025-02-18T06:47:45","slug":"run-win32-apps-from-intune-in-64-bit-powershell","status":"publish","type":"post","link":"https:\/\/digitalmaterial.ch\/blog\/run-win32-apps-from-intune-in-64-bit-powershell\/","title":{"rendered":"Run Win32 Apps from Intune in 64 Bit PowerShell"},"content":{"rendered":"\n

As you may know (or have not realised so far) is that all your Win32 apps in Intune are being run in the 32 Bit environment. Usually this is not an issue as most executables elevate themselves into the 64 Bit environment if required. But there are some edge cases, where this is relevant, like creating some entries in the registry.<\/p>\n\n\n\n

But let’s start from the beginning: We usually pack more complex Applications into a Win32 App \/ Intune-Win File. There we pack the executable and usually two PowerShell Files for installation and uninstallation and those a triggered as follows from Intune: powershell.exe -ExecutionPolicy Bypass -WindowStyle hidden -File install.ps1<\/code><\/p>\n\n\n\n

As mentioned above, this script is being run in a 32 Bit environment and if you need to create registry items in the HKLM:\\SOFTWARE\\<\/code> node, you will notice, that the items you just added are ending up in the HKLM:\\SOFTWARE\\WOW6432Node<\/code>. Not what you wanted and expected.<\/p>\n\n\n\n

We can check that behaviour by adding the following lines of code to our PowerShell script and make sure the output is being saved by Start-Transcript or another solution for logging.<\/p>\n\n\n\n

PowerShell<\/span><\/path><\/path><\/svg><\/span>
Write-Host<\/span> <\/span>"checking environment"<\/span><\/span>\nWrite-Host<\/span> <\/span>"    PowerShell Version: <\/span>$(<\/span>$PSVersionTable<\/span>.PSVersion<\/span>)<\/span>"<\/span><\/span>\nWrite-Host<\/span> <\/span>"    is 64bit os:      <\/span>$(<\/span>[<\/span>Environment<\/span>]::Is64BitOperatingSystem<\/span>)<\/span>"<\/span><\/span>\nWrite-Host<\/span> <\/span>"    is 64bit process: <\/span>$(<\/span>[<\/span>Environment<\/span>]::Is64BitProcess<\/span>)<\/span>"<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
On a 64 Bit system, this will then return the following output:<\/p>\n\n\n\n
PowerShell<\/span><\/path><\/path><\/svg><\/span>
checking environment<\/span><\/span>\n    PowerShell Version: <\/span>5.1<\/span>.<\/span>26100.2161<\/span><\/span>\n    is 64bit os:      True<\/span><\/span>\n    is 64bit <\/span>process<\/span>: False<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
So, what can we do about that? We can simply trigger the 64 Bit PowerShell to run our commands. And if you were wondering, the PowerShell 5 executable is hiding under the following path if you’re in a 32 Bit environment.<\/p>\n\n\n\n
PowerShell<\/span><\/path><\/path><\/svg><\/span>
"<\/span>$(<\/span>$env:SystemRoot<\/span>)<\/span>\\sysnative\\WindowsPowerShell\\v1.0\\powershell.exe"<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
There are multiple options to solve that issue, and we’re going to look into the following three:<\/p>\n\n\n\n