Click on the Category button to get more articles regarding that product.
The normal Intunes Agent that is running on a Windows 10/11 64-bit OS is a 32-bit Agent.
INTUNES-MEM: 32 or 64-bit Runtime and Registry Hive explained (WOW6432Node) Short sample why you maybe landed here….
|
What is the problem that we often see:
A Win32APP with import_registry.cmd or import_registry.ps1 is run via Intunes. Before deployment you test the cmd/ps manual without intunes on a W10/W11 and all looks fine. Then you make a package in Intunes and run the package on a test vm. To verfify installation you use Detection rules with Registry like you tested manual > Intunes package fails, Registry key not there where you excpected it |
|
WHY:
Because the Intunes Agent runs in 32-bit on a 64-bit OS and WIN32APP with cmd.exe or Powershell commandline will run in 32-bit any import/write in Registry will populate the special HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\* and not what you expected on a 64-bit OS the HKEY_LOCAL_MACHINE\SOFTWARE\* |
We seen an old Deployment (Modern Workplace) pitfall come back.
It also happens, no matter what you use for deployment: SCCM, Enteo, Matrix, MEM, Intune, etc. So this is not realy an Intunes problem it is just how Microsoft handels the architecture mix.
Often, you overlook that an application that does something is 32-bit code and queries the wrong registry hives.
There is no option to run WIN32APPS as 32-bit or 64-bit from Properties of Windows app (Win32).
Also the solution has no possibilities like Ivanti/Frontrange/Enteo, where you could define per line of script code if it should be run 32/64-bit and under user or system or, most importantly, any other credentials (like for LDAP operations)
If you have larger complex packages with a 32/64-bit mix (yes, that is possible if the producer repacks certain apps and runtime into one big one), you may have to split them into several single Intune packages. You are back to square one and have to repackage everything into a Windows Installer MSI package and put the logic there.
Not so modern workplace right?
Intunes agent operation:
All components in the modern workplace are designed for 64-bit operation, but what about their agents?
The standard Intune Agent running on Windows 10/11 (64-bit) is actually a 32-bit agent.
By default, the agent will write to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node if you don’t handle it specially. Windows perceives it as an old 32-bit application (including the new Intune Agent), and automatically redirects registry writes to the WOW6432Node hive. However, when you manually evaluate or test deploy the application on a VM running Windows 10/11, it operates as a 64-bit application and writes to the regular registry hive.
Here are the individual parts which may help you.
Powershell handling in WIN32APP
For PowerShell on a 64-bit OS (W10/W11) via Intune Agent and within a WIN32APP there is also such a behaviour. You can handle that with sysnative path
if you want to run a WIN32APP which included PS as 64-bit or you may use a architecture check and re-run the PS automatic from that code.
MS reminds you but people oversee that:
|
%windir%\windowspowershell\v1.0\powershell.exe %systemroot%\windowspowershell\v1.0\powershell.exe |
%windir%\Sysnative\windowspowershell\v1.0\powershell.exe %systemroot%\Sysnative\windowspowershell\v1.0\powershell.exe |
|
PS comes as 32-bit application Will write to Registry WOW6432Node HIVE
An example:
%SystemRoot%\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden –File import_registry.ps1 |
PS comes as 64-bit application Will write to regular Registry HIVE not the redirect on 64BIT OS
An example:
%SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden –File import_registry.ps1 |
|
# V2.0, 19.01.2024, www.butsch.ch, First Release as sample # Check and handle 32/64-bit mismatch for PS # The Intunes agent runs with 32-bit even on a 64-bit. This is why you have to re-route some things if ($env:PROCESSOR_ARCHITECTURE -eq “AMD64”) { try { Start-Process -FilePath “$env:SystemRoot\SysNative\WindowsPowershell\v1.0\PowerShell.exe” -ArgumentList “-File $PSCOMMANDPATH” -Wait -Passthru } catch { throw “Error with $PSCOMMANDPATH” } Exit } # Main script code starts here
# Your existing script content goes here # … # … # End of the script |
|
|
This sample at the top should check the OS architecture and if it is 64-bit it will re-run the current executed script as with the 64-bit sysnative parser
$PSCommandPath Contains the full path and filename of the script that’s being run. This variable is valid in all scripts. |
|
Command Prompt (Manual Test on Windows 11)
cmd.exe shell on 64-bit OS (W11) with reg.exe without the /reg:32 or /reg:64 option
Client has a Registry entry “TEST” installed from an older 32-bit application. Lets try how we can see it?
|
|
|
|
|
|
So reg.exe query works like we think it should. Now lets write something with reg.exe add on a W11 64-bit OS with different calls to cmd.exe manual.
|
|
|
|
|
|
|
|
|
Doing the same with Intunes and a Win32APP
We utilize reg.exe IMPORT to import an existing file.reg. It’s crucial to remember that, by default, a 32-bit process like the Intune Agent or a Windows Installer MSI for 32-bit packages on a 64-bit OS machine will use a 32-bit view of the registry: HKLM\SOFTWARE\Wow6432Node.
|
FILE 64BIT_HIVE_TEST.reg |
FILE 32BIT_HIVE_TEST.reg |
|
install_64.intunewin |
install_32.intunewin |
|
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\TEST] “mytestflag”=”1.0” |
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\TEST] “mytestflag”=”1.0” |
|
install_64.cmd |
install_32.cmd |
|
set “regFilePath=%localfolder%\setup\%package%\64BIT_HIVE_TEST.reg” reg.exe IMPORT “%regFilePath%” :: We do not use /reg:32 or /reg:64 to show you what happens |
set “regFilePath=%localfolder%\setup\%package%\32BIT_HIVE_TEST.reg” reg.exe IMPORT “%regFilePath%” :: We do not use /reg:32 or /reg:64 to show you what happens |
|
Manual import test > Works
|
Manual import test > Works
|
|
Manual import with our batch as Administrator > Works
|
Manual import with our batch as Administrator > Works
|
Our Manual test works so lets test when running our two batches as intunes packages.
|
install_64.intunewin |
install_32.intunewin |
|
install_64.cmd |
install_32.cmd |
Both packages give us the same result.
OK lets PROOF once again what happens. Normal call with “install.cmd” > Will not do what you think or tested manual…
|
NORMAL_HIVE_TEST.reg |
|
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\TEST] “mytestflag”=”1.0” |
|
install.cmd |
|
set “regFilePath=%localfolder%\setup\%package%\NORMAL_HIVE_TEST.reg” reg.exe IMPORT “%regFilePath%” |
|
We do not use /reg:32 or /reg:64 to show you what happens |
1st RUN with just direct “install.cmd” in Intunes package:
Lets change to %systemroot%\sysnative\cmd.exe /c install.cmd
In this way we FORCE the Intunes Agent to call the command console cmd.exe 64BIT Version of the Windows 11 64BIT we test.
If we start the install.cmd VIA the 64-bit cmd.exe console the Registry Engine will write the values to the regular HKLM\Software\test HIVE.
OS is 64-bit and the process which writes is now 64-bit.
Now the key is there where you would think it should be and NOT under the WOW6432Node.
Option to success if you want to handle it PER line/command in a batch with Intunes
Reg.exe hat a commandline Option where you can mention which part of the 32/64-bit Registry shall be used.
/reg:32 : Force REG.exe to read/write to the 32-bit registry location.
/reg:64 : Force REG.exe to read/write to the 64-bit registry location.
|
Use /reg:64 to force REG.exe to read/write to the 64-bit registry location |
Use /reg:32 to force REG.exe to read/write to the 64-bit registry location |
|
reg add HKEY_LOCAL_MACHINE\SOFTWARE\TEST /v mytestflag /t REG_SZ /d “1.0” /f /reg:64 |
reg add HKEY_LOCAL_MACHINE\SOFTWARE\TEST /v mytestflag /t REG_SZ /d “1.0” /f /reg:32 |
Intunes APP Detection Rules
A flow explains all…
Intunes APP Detection rules with Powershell Script
If you use a Powershell Script to for the Detection rules you can choose how the PS will run.
Intunes APP Detection rules with Registry
At the bottomt here is an option to select the 32-bit or 64-bit Hive.
MS says:
For a 32-bit application running on 64-bit clients, the following logic applies:
Choose “Yes” to check the 32-bit Registry on 64-bit clients.
Opt for “No” (which is the default) to check the 64-bit Registry on 64-bit clients.
For 32-bit clients, the search will invariably be conducted in the 32-bit registry.
In other words: Ensure that you indicate “No” for being associated with a 32-bit app on 64-bit clients. This instructs it to look in the 64-bit registry. Selecting “Yes” here would lead it to search in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft. We want to avoid that.
What is if you have two binary Source to download or install 1) 32BIT Version 2) 64BIT Version of same software release
Lets start without Intunes and MEM making it so complicated.
If you think you understood you can take a look at this key. Is that what? A 32-bit process on a 64-bit OS writting 32-bit? Nevermind lets take a simple path…
MS writes:
The registry in 64-bit versions of Windows is divided into 32-bit and 64-bit keys. Many of the 32-bit keys have the same names as their 64-bit counterparts, and vice versa.
The default 64-bit version of Registry Editor (Regedit.exe) that is included with 64-bit versions of Windows displays both 64-bit keys and 32-bit keys. The WOW64 registry redirector presents 32-bit programs with different keys for 32-bit program registry entries. In the 64-bit version of Registry Editor, 32-bit keys are displayed under the HKEY_LOCAL_MACHINE\Software\WOW6432Node registry key.
We write:
The Windows Registry is a hierarchical database that stores configuration settings and options for the operating system and installed applications on Microsoft Windows. When it comes to 32-bit and 64-bit applications, the registry on a 64-bit Windows system is divided into two parts. We try to netter explain this with a real word sample.
The opensource Packer 7ZIP can be downloaded in a 32-bit and 64-bit Version.
We install and old 32-bit and a new 64-bit Version on same system so you see the difference better.
32-bit 7ZIP Version 19.00
64-bit 7ZIP Version 23.01
1. 32-bit Registry (WoW64Node) sample with 32-bit 7ZIP Version 19.00
- On a 64-bit Windows system, there is a 32-bit registry subsystem known as WoW64 (Windows-on-Windows 64-bit). It allows 32-bit applications to run on a 64-bit Windows system.
- 32-bit applications running on a 64-bit system have a separate section in the registry called `Wow6432Node`. This is where the 32-bit applications store their registry keys and values.
Here you see the 32BIT 7ZIP Registry.
Because it’s installed on a W11 74BIT and the APP is a 32BIT its writes it content into the WOW6432Node hive.
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\7-Zip
2. 64-bit Registry 64-bit 7ZIP Version 23.01:
- 64-bit applications interact with the standard 64-bit registry.
- The registry keys and values for 64-bit applications are located in the standard locations without any redirection.
Here you see the 64-bit 7ZIP Version Registry.
Because it’s installed on a W11 64BIT and the APP is a 64BIT its writes it content into the normal HIVE.
The redirection of registry access helps maintain compatibility between 32-bit and 64-bit applications on the same system. This separation ensures that 32-bit applications do not unintentionally read or modify data intended for 64-bit applications, and vice versa.
In summary, on a 64-bit Windows system, there are two parts to the registry: one for 32-bit applications (with redirection to `Wow6432Node`) and one for 64-bit applications. The operating system handles the redirection automatically, allowing both types of applications to coexist on the same system without conflicts in registry data.