On a Windows x64 machine
1) A 32-bit application maps as follows:
- c:\windows\system32 -> c:\windows\syswow64 (32-bit)
- c:\windows\syswow64 -> c:\windows\syswow64 (32-bit)
- c:\windows\sysnative -> c:\windows\system32 (64-bit)
2) A 64-bit application maps as follows:
- c:\windows\system32 -> c:\windows\system32 (64-bit)
- c:\windows\syswow64 -> c:\windows\syswow64 (32-bit)
- c:\windows\sysnative -> not valid
This will also affect registry keys. When needing to write to the actual 64bit registry you need to call the reg command from sysnative. If you are using a batch that has parameters the batch will switch back to 32bit redirects due to switches when executed by the agent.
In scripting and Custom Inventory the redirects can be avoided by telling the KBOX when you are looking to read/write to 64bit keys by adding a 64 to the end of the primary key name. This will only be needed for those keys that have both 32bit versions and 64bit versions in the OS like HKEY_LOCAL_MACHINE.
Examples:
To access the 64bit HKEY_LOCAL_MACHINE you would use HKLM64 instead of the typical HKLM.
If the redirects aren't accounted for the expected outcome will typically not be achieved. The agent logs themselves contain the paths being called while executing the various functions. More details on Registry access
here.
Keep this in mind when using PowerShell as well. If you are executing against a x64 system you will want to call
c:\windows\sysnative\WindowsPowerShell\v1.0\powershell.exe to make sure you are executing the 64bit version of PowerShell, otherwise you might not get the results you are planning for.
