The Joy of File System Redirection

You have all seen it before, the option when we deploy our applications to make the application run as 32bit on a 64bit system or to disable the 64bit file redirection in a task sequence. What do these options actually do though and why does it matter?

The %windir%\System32 directory is reserved for 64-bit applications. Most DLL file names were not changed when 64-bit versions of the DLLs were created, so 32-bit versions of the DLLs are stored in a different directory. WOW64 hides this difference by using a file system redirector.

In most cases, whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64. Access to %windir%\lastgood\system32 is redirected to %windir%\lastgood\SysWOW64. Access to %windir%\regedit.exe is redirected to %windir%\SysWOW64\regedit.exe.

If the access causes the system to display the UAC prompt, redirection does not occur. Instead, the 64-bit version of the requested file is launched. To prevent this problem, either specify the SysWOW64 directory to avoid redirection and ensure access to the 32-bit version of the file, or run the 32-bit application with administrator privileges so the UAC prompt is not displayed.

So…?

With this information in mind what does this mean in ConfigMgr terms? Well you are probably all familiar with the following screenshot which comes from the Run Command Line task sequence step.

Disable 64-bit file system redirection

By default, when running on a 64-bit operating system, the executable in the command line is located and run using the WOW64 file system redirector so that 32-bit versions of operating system executables and DLLs are found.  Selecting this option disables the use of the WOW64 file system redirector so that native 64-bit versions of operating system executables and DLLs can be found.  Selecting this option has no effect when running on a 32-bit operating system.

I have been to customers where this box is always ticked “because they think it should be”, however consider the scenario where you are running a 32-bit application which actually due to it been written for a 32-bit operating system calls a binary and then fails. This would be because the application or DLL is trying to access as a 32-bit application 64-bit resources which will fail.

In summary then, what I am saying here is don’t disable this option, this way you let the operating system take care of what it needs to run instead of forcing it to run something which may lead to a failure. In systems management it’s always important to understand the applications you are deploying, not only for regular deployments but also in operating system deployment where one failure can lead to a whole task sequence failing.

Advertisements

Tags: , , , , , ,

About Martyn

Martyn is one of the Senior Cloud Architects and DevOps Team Leader at one of the worlds leading Cloud Transformation Specialists Inframon. Martyn is responsible for the architecture of some of the largest Azure deployments in EMEA and is a advisor to a many businesses on their strategies. Martyn is a regular speaker at Microsoft events and community events on Azure and DevOps, giving his insight to a growing number of audiences.

2 responses to “The Joy of File System Redirection”

  1. Tony says :

    Hello Martyn!

    In my SCCM task sequence I am attempting use the Microsoft.SMS.TSEnvironment COM object, but have some questions. Using the the ‘Run Power Shell’ task, the command of $tsenv=New-Object -COMObject Microsoft.SMS.TSEnvironment works, but when using it a ‘Run Command Line’ task it fails with this error: New-Object : The term ‘New-Object’ is not recognized as the name of a cmdlet, function, script file, or operable InstallSoftware . Do you know what different is between these two has? Second, do you know how to make $tsenv=New-Object -COMObject Microsoft.SMS.TSEnvironment work using the ‘Run Command Line’ task? I need to be able to use it there because I need to be able to specify credentials for other portions of the script.

    Here is a post on TechNet that provides more details about what I am trying to accomplish.

    https://social.technet.microsoft.com/Forums/en-US/a7a217ff-ff32-4b48-9827-8286cd13f9f4/run-powershell-script-vs-run-command-line?forum=configmanagersdk#f995bdbf-3121-4456-aaa2-ffd59bd5868d

    Hope you are willing to help Martyn!

    Thanks!

    -Tony

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: