I’m pushing a PowerShell script to update registry keys on my Windows fleet, but it’s acting weird. Hexnode says ‘Success,’ but when I check the device, the registry key hasn’t actually changed. It’s like the script is running in a ghost environment. How do I make sure my registry edits actually land in the right spot?
27 Views
Replies (1)
Marked SolutionPending Review
Hexnode Expert
2 weeks ago
May 09, 2026
Marked SolutionPending Review
Hi there! This is a very common hurdle when working with UEM (Unified Endpoint Management) agents.
The issue isn’t your script, it’s Windows Architecture Redirection. Most MDM agents run as 32-bit processes. When they launch PowerShell, they launch the 32-bit version. Because Windows wants to maintain compatibility, it automatically “redirects” any 32-bit attempt to modify HKLM:\SOFTWARE into a separate folder called WOW6432Node.
Your script “succeeds” because it did write to the registry, it just wrote to the 32-bit version of the path instead of the 64-bit one that your application is actually using.
To fix this, you need to tell your script to check if it’s running in a 32-bit session and, if so, restart itself in the native 64-bit environment.
Paste this code at the very beginning of your script:
|
1 2 3 4 5 6 7 8 9 10 11 |
PowerShell # Check if the script is running in a 32-bit (syswow64) session if ($PSHOME -like "*syswow64*") { Write-Output 'Relaunching in 64-bit context to avoid redirection...' # Use the 'sysnative' alias to access the 64-bit powershell.exe & (Join-Path ($PSHOME -replace 'syswow64', 'sysnative') powershell.exe) -File $Script:MyInvocation.MyCommand.Path @args Exit } # --- Place your actual registry commands below this line --- |
This ensures that no matter how the MDM agent starts the process, your script will always pivot to the native 64-bit environment before making changes. For more detailed explanation please refer our documentation: https://www.hexnode.com/mobile-device-management/help/deploying-powershell-registry-fixes-windows/
Save
