On our systems we apply hardening policies by all kinds of available techniques. Being local policies, PowerShell scripts or classic batch files even. All the settings are eventually applied by a central installer that takes care of the installation, reboots and validation of the settings. Recently on one of our older systems we ran into something that appeared to be magical at first. Simply put we tried to apply a registry setting that was logged as being successfully set, however it never was applied. Although so it seemed to be the case. After a morning of testing we discovered that the registry key was actually applied (as indicated by the logging) but on another location in the registry. The key showed up in a location that’s used for 32 bit processes on 64 bit systems.
Windows has something called redirection for 32 bit processes when running on a 64 bit system. Normally when an application writes content to the registry (Such as a batch file) it’s a 64 bit process, however, as it turns out, our main installer on 64 bit systems is still 32 bit, hence Windows will redirect all writes to “HKLM\Software” to the “HKLM\Software\WOW6432Node” node. If you want to give it a try, open up “cmd.exe” from the “C:\Windows\SysWOW64” folder and add something to “HKLM\Software” using “reg.exe“. The key will be redirected to the “HKLM\Software\WOW6432Node” node.
Under normal circumstances this is a good thing to separate 32 bit application from native 64 bits application. In our case not so much, because it’s an installer, not an application. The solution to this problem is rather easy. Adding the parameter:
after the command-line tells the redirector to act as if it’s a 64 bit application and ignore the 32 bit status. Easy does it.