Program Files redirection on x64 systems

In SCCM 2007 I have created a package/program to install several Windows Server 2008 R2 language packs. The command is:

lpksetup.exe /i * /r /s /p %~dp0

Basically it installs all Windows language packages that are found in the current folder. The following error message was shown when I’ve run lpksetup.exe from a batch file:

‘lpksetup.exe’ is not recognized as an internal or external command, operable program or batch file.

The same message appeared when I have added the full path to the lpksetup.exe (c:\windows\system32\lpksetup.exe). There is no doubt about it, the exe file is there! After some minutes thinking about it, I thought it might be related to the x64 redirection. As an easy test if my assumption was true, I have copied the lpksetup.exe to the c:\windows\syswow64 folder and run my batch file again – with success. He was able to find the exe and the error message disappeared. Then I recalled that SCCM 2007 is only running as a 32bit application and that is why the installation via SCCM didn’t work. A 32bit application cannot access the physical c:\windows\system32 nor c:\program files. Both folders are automatically redirected to c:\windows\syswow64 / “c:\program files (x86)”. The same behaviour exists with HKEY_LOCAL_MACHINE\SOFTWARE. If a 32bit application access this key, it gets automatically redirected to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node.

So the next question was how I can access the real system32 folder from a 32bit application. I’ve found the solution at http://system-center.de/cgi-bin/weblog_basic/index.php?p=80:

@set ComSpec64=%SystemRoot%\sysnative\cmd.exe
@if not exist "%ComSpec64%" goto Main
@:SwitchTo64
@"%ComSpec64%" /c %0 %*
@exit
@:Main
@REM *** ...add additional commands

The sysnative folder allows you to access the x64 cmd.exe.

Office 2010 Language Pack download issues in SCCM

I came across the issue that the download of the “Office 2010 language pack” packages didn’t work. It was downloading the package into the local client cache, but then stopped at one point. It was always a different time it was stuck. After checking the SCCM  log files, I couldn’t find any indications. What finally solved my issue was the IIS log file:

HEAD /SMS_DP_SMSPKGD$/ZUC00083/FILES/PFILES/MSOFFICE/
OFFICE11/1031/FPNWIND.MDB – 80 – IPAddress Microsoft+BITS/6.7 404 7 0 187

As you can see in red, there was a problem downloading the .mdb file because the status code 404.7 means File extension denied. I was having in mind that there is a Request Filtering option in IIS that prevents the access of files with a specific extension. By default it doesn’t allow the access of .mdb files. So I have removed this rule and afterwards the client was able to download .mdb files via HTTP.

There was an additional 404 status code that I had to resolve:

HEAD /SMS_DP_SMSPKGD$/ZUC00083/FILES/PFILES/COMMON/
MSSHARED/WEBSRVEX/60/BIN/1031/NORTBOTS.HTM – 80 – IPAddress Microsoft+BITS/6.7 404 8 0 171

The slightly different status code 404.8 indicates Hidden namespace. That’s as well a filtering option from IIS that needs to be changed (see screen shot). Under Hidden Segments I have removed Bin because this was a folder in the path the the above listed .htm file.

After the listed changes I was able to download the full package locally to the client.

Request Filtering in IIS