I've encountered this a couple of times in my travels, and I thought it was worth mentioning.
When deploying scripts that modify the File System and Registry to 64-bit hosts using SCCM 2007, the built-in File System Redirector can cause some unexpected behavior:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx
This behavior pops up mostly when dealing with the registry and %ProgramFiles% location on 64-bit machines.
Recently, I was asked to deploy a registry key change to a number of machines to re-write a set of ODBC values to point to a new server location.
In general, ODBC values for Windows XP and above live in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
If one were to deploy a script/reg key/whatever in SCCM 2007 to 32-bit machines to modify a value at this location, it would work without any issue.
For example, my SCCM program would be something like:
cmd.exe /c update-odbc-regkeys.bat
However, if I were to deploy the same SCCM program to a 64-bit machine, the magical behind the scenes file-redirector would transparently write the keys to the following location instead:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
Sometimes this is the desired behavior, sometimes it is not.
In order to get the same script to bypass the FS Redirector behavior, I can modify my SCCM Program as follows:
%windir%\sysnative\cmd.exe /c update-odbc-regkeys.bat
By invoking my script using the "sysnative" path instead, the aforementioned script would then modify the registry values at the HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ location, not HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\.
This can also be handy to ensure that something is written to ":\Program Files" instead of ":\Program Files (x86)".
It should be noted that modifying the command line to invoke the "sysnative" call *only* works on 64-bit machines. So for SCCM 2007, you would need a separate program that calls the modified command-line with platform restrictions limiting it to 64-bit targets. Also, for good measure, you should ensure that your "original" program has platform restrictions limiting it only to 32-bit targets.
Does this behavior change in SCCM 2012? I believe so, as the there is a native 64-bit client in 2012, but I'm still stuck on 2007 (as I'm sure quite a few people are...) so I can't say for certain.
This is a very in-depth topic, and this post barely scratches the surface, but hopefully can point someone else in the right direction.
sources:
http://msmvps.com/blogs/installsite/archive/2012/08/22/using-sysnative-to-access-the-64-bit-system-folder-from-a-32-bit-application.aspx
http://practicaladmin.wordpress.com/2010/07/16/powershell-x64-and-filesystem-redirection/#more-62
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx
http://blog.danovich.com.au/2010/04/21/considerations-when-scripting-for-64-bit-machines-with-sccm/
