Intune Win32 Install Script Runs 32-Bit: WOW6432Node Fix

Your install script works when you run it from an elevated PowerShell window. Deployed through Intune as a Win32 app, the same script reports success, but the registry values it wrote land under HKLM\SOFTWARE\WOW6432Node, a file you copied to C:\Windows\System32 is sitting in C:\Windows\SysWOW64, and the detection rule that looks in the 64-bit locations says the app isn’t there.

The cause is documented on the Add and assign Win32 apps page:

Calling powershell.exe in either of these fields will result in a 32-bit Powershell instance being launched. To force 64-bit Powershell execution, use the following command:

%SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe

“These fields” are the Install command and Uninstall command. Your test console was 64-bit. The Intune Management Extension (IME) started a 32-bit one, and on 64-bit Windows a 32-bit process sees a redirected file system and registry.

I haven’t reproduced this on a live tenant for this article. The behavior and paths below come from Microsoft Learn, linked inline. The diagnostic snippets are read-only and I have not run them against an Intune deployment.

Quick Fix checklist

1. Open the app’s Program page and read the Install command. If it starts with plain powershell.exe, the script runs 32-bit on 64-bit clients.
2. On an affected device, look for the script’s registry writes under HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node and its file writes under %windir%\SysWOW64.
3. Change the command to %SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File .\Install.ps1 (adjust the script name and arguments). Do the same for the Uninstall command.
4. If the app uses the PowerShell script installer type instead of a command line, check the script’s runAs32Bit property (more below).
5. Make the detection rule match where the app really writes. On 64-bit clients the registry rule’s Associated with a 32-bit app on 64-bit clients option picks the view.
6. Clean up the stray WOW6432Node keys and SysWOW64 files from the earlier runs, then redeploy to a test device.

What redirection does to your script

Two WOW64 features explain every symptom.

The file system redirector sends a 32-bit process that touches %windir%\System32 to %windir%\SysWOW64 on x64 Windows. Microsoft lists a few exempt subdirectories, such as %windir%\system32\drivers\etc and %windir%\system32\spool. That’s also why powershell.exe resolved from a 32-bit parent is the 32-bit copy in SysWOW64.

The registry redirector maps redirected keys under Wow6432Node. Microsoft’s example: HKEY_LOCAL_MACHINE\Software is redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node. The same page says the physical location is reserved by the system and applications shouldn’t access it directly. So the fix is to run in the right bitness or ask for a registry view explicitly, not to hardcode WOW6432Node paths.

Per Accessing an alternate registry view, a 32-bit application on WOW64 reads and writes the 32-bit view by default. Your script didn’t do anything wrong. It ran in a process that was given a different view of the machine.

Fix 1: call 64-bit PowerShell through Sysnative

Microsoft’s file system redirector page describes Sysnative as a special alias that tells WOW64 not to redirect, and calls it “the recommended mechanism to bypass file system redirection.” It also notes that 64-bit applications can’t use Sysnative because it’s a virtual directory. Microsoft’s documented fix for the Intune install command relies on exactly this alias.

%SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File .\Install.ps1

The path is Microsoft’s. -ExecutionPolicy Bypass -File .\Install.ps1 is a common pattern for packaged scripts; swap in your own script name and parameters. Remember the Uninstall command too. Learn also notes that environment variable expansion isn’t supported in the Uninstall command; if you need it there, Microsoft says to wrap the command in a script inside the package and call that script.

Fix 2: the PowerShell script installer type

Intune now has a second way to run install logic. On the Program page, Installer type offers Command line or PowerShell script. With PowerShell script you upload the script itself (maximum size 50 KB), and Microsoft says Intune “runs it in the same context as the app installer” and reports results from the script’s return code.

The same page names the script property that controls bitness, runAs32Bit, in a note about Multi-Admin Approval: “script properties like enforceSignatureCheck and runAs32Bit can be edited without MAA requests, but this behavior will change in a future update to require MAA approval.”

What I could not confirm on Learn: the exact admin center label for this setting on install scripts and its default value. So treat it as something to check, not assume. If install scripts on 64-bit devices write to WOW6432Node, open the script settings on the app and confirm the script isn’t set to run as 32-bit. If you can’t tell from the UI, the diagnostic below tells you from the device side.

For comparison, two neighboring Intune features document their switches clearly, and they default differently, which is how people get mixed up:

• Win32 app script detection rules: Run script as 32-bit process on 64-bit clients, default No, so the detection script runs 64-bit. (Add and assign Win32 apps)
• Platform scripts under Devices: Run script in 64-bit PowerShell host, default No, which runs the script in a 32-bit host. (Add PowerShell scripts to Windows devices)

So a detection script and the install command in the same Win32 app can run in different bitness out of the box. That is the classic “install succeeded, detection failed” split.

Fix 3: make the script bitness-proof

If you can’t change how the script is launched, have it ask for the 64-bit registry view explicitly. .NET exposes Microsoft.Win32.RegistryView with Registry64 and Registry32, and reg.exe has /reg:64 and /reg:32 switches that select the view.

# Writes to the 64-bit HKLM view even from 32-bit PowerShell. Not executed for this article.
$base = [Microsoft.Win32.RegistryKey]::OpenBaseKey(
    [Microsoft.Win32.RegistryHive]::LocalMachine,
    [Microsoft.Win32.RegistryView]::Registry64)
$key = $base.CreateSubKey('SOFTWARE\Contoso\App')
$key.SetValue('Version', '1.2.3', [Microsoft.Win32.RegistryValueKind]::String)
$key.Close(); $base.Close()

reg add "HKLM\SOFTWARE\Contoso\App" /v Version /t REG_SZ /d 1.2.3 /f /reg:64

HKLM\SOFTWARE\Contoso\App is a placeholder. I’d still prefer Fix 1: forcing one view in one line of the script leaves every other line (file copies, child installers, $env:ProgramFiles) running 32-bit.

Confirm the bitness on the device

Add a line like this near the top of the install script while you test, and write it to a log your package already creates:

# Read-only diagnostic. Not executed for this article.
"Is64BitProcess=$([Environment]::Is64BitProcess) Is64BitOS=$([Environment]::Is64BitOperatingSystem) PSHOME=$PSHOME"

Environment.Is64BitProcess returns true if the process is 64-bit. If you see Is64BitProcess=False on a 64-bit OS, the redirection above applies. For where the IME writes its own logs, see reading AppWorkload.log and the IME logs.

Line up detection with the install

After the install runs 64-bit, check the detection rule:

• Registry rule: Associated with a 32-bit app on 64-bit clients set to No (default) searches the 64-bit registry; Yes searches the 32-bit registry.
• File rule: the same option set to Yes expands path variables in the 32-bit context; No (default) uses the 64-bit context.

Both come from Add and assign Win32 apps. If you use a custom detection script, the 32-bit detection script registry view article covers that side, and exit code 0 but detection fails covers the general mismatch.

What not to waste time on

• Hardcoding WOW6432Node into the detection rule to “match” the broken install. Microsoft calls that physical location reserved. Fix the install bitness instead.
• Raising Installation time required or adding retry return codes. The script finished; it wrote to the wrong place.
• Switching Install behavior between System and User. That changes the account, not the bitness. See system vs user install context if the account is your actual problem.

Prevention

Make 64-bit execution the default in your packaging template: Sysnative path in both commands, a bitness log line in every script, and detection rules that state their 32-bit option on purpose. If a vendor app really is 32-bit and writes to WOW6432Node by design, keep it that way and set the detection rule’s 32-bit option to Yes.

If this app is blocking an Autopilot ESP, the Deployment Doctor is the read-only tenant check I built for that broader class of setup failures.

Get the Deployment Doctor

Kit 1 founding presale is open: $39 (regular $49). The Autopilot + Device Prep Deployment Doctor checks your tenant, read-only, for the config that breaks ESP and Device Preparation. You pay now and get the files by Tuesday, December 1, 2026, sooner if they’re ready. Full refund any time before delivery, then 14 days after delivery. The founding price runs until Friday, December 4, 11:59 PM MT.

Want to look first? The free, read-only beta scripts are on GitHub: autopilot-deployment-doctor-beta. Its README says they haven’t been run against a live tenant.

FAQ

Why does my Intune Win32 install script write to WOW6432Node?

Microsoft Learn says calling powershell.exe in the install or uninstall command launches 32-bit PowerShell. On 64-bit Windows, the registry redirector maps HKLM\Software to HKLM\Software\Wow6432Node for 32-bit processes.

How do I force 64-bit PowerShell in an Intune Win32 app?

Use %SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe in the install and uninstall commands, as documented on Microsoft Learn.

Does the Win32 detection script run as 32-bit?

Not by default. Run script as 32-bit process on 64-bit clients defaults to No, so detection scripts run 64-bit on 64-bit clients.

Sources

All retrieved 2026-10-26.

• Add and assign Win32 apps to Microsoft Intune, Microsoft Learn: 32-bit powershell.exe, the Sysnative path, installer types, runAs32Bit, uninstall variable expansion, detection rule 32-bit options.
• File System Redirector, Microsoft Learn: System32 to SysWOW64, exemptions, Sysnative.
• Registry Redirector, Microsoft Learn: Wow6432Node mapping.
• Accessing an Alternate Registry View, Microsoft Learn.
• Add PowerShell scripts to Windows devices, Microsoft Learn: platform script 64-bit host setting.
• reg add, Microsoft Learn: /reg:32 and /reg:64.
• RegistryView enum, Microsoft Learn and Environment.Is64BitProcess, Microsoft Learn.