SCCM Client 32bit Client Stopping Registry Keys In SYSWOW64 Context Only Using SYSNATIVE

Posted on by

Background

I use SCCM, Operating System Deployment (OSD) and Microsoft Deployment Toolkit (MDT) 2010 update 1 to deploy Windows 7 SP1 (x64) and application installs during the build process.  The problem was a .vbs script which populates some auto-logon keys called via SCCM OSD during the application installation process was being hit with registry redirection, forcing any registry entries to go into
HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\WinLogon
rather than HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon.

Problem

The vbscript was being called from an SCCM Program using cscript.exe AUTOLOGON.vbs.  Since the SCCM Client is a 32bit application, any native executable is run in a 32bit context and therefore registry redirection occurs. Certain registry writes are are then filtered away from the 64bit registry nodes and directed to the Wow6432Node instead.  Any 32bit application running on a 64bit OS is then redirected to Wow6432Node, without the knowledge of the 32bit application.

Unfortunately, this behaviour was not required during the installation process for our AutoLogon.vbs script, it explicitly needed to write these to the 64bit part of the registry for them to autologon the device after the build had completed.  In this case I was running cscript.exe however under the covers it runs C:\Windows\SYSWOW64\cscript.exe, and not the version of cscript.exe that exists in the 64bit file system of C:\Windows\system32\cscript.exe.

Solution ‘sysnative’

I then stumbled sysnative which is an alias that can be used in a commandline, to say ‘I am running on a x64 bit OS therefore run the 64bit version’.  In this case within the SCCM Program Name I changed the command line to %WINDIR%\sysnative\cscript.exe AutoLogon.vbs.  Now when SCCM Client runs cscript.exe it will run from within the 64bit context and the registry keys within the .vbs script are also written to the 64bit registry in this case HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon.

See http://msdn.microsoft.com/en-gb/library/windows/desktop/aa384187(v=vs.85).aspx