Hello World,

Lately, I’m working a lot with Powershell scripting. My customer needs to automate a bunch of tasks related to Active Directory.  The infrastructure is based on Microsoft Technology and we can use SCCM infrastructure to efficiently deploy and schedule the tasks to be run by the script.

You would think that deploying Powershell scripts through SCCM is an easy task and you should not have any major issues…. Well, you might not be correct.  I have to say that I’ve spent some hours to find out why my scripts were not running correctly when deployed with SCCM but worked perfectly when started manually…..

You wanna how to fix this (so you do not loose your hair like I did :-).  Keep reading…..

Problem Description…

I have developed a nice script accepting parameters performing different operations at Active Directory level.  The script has to be run from a Windows 2008 R2 (64-bit-you will see this element will become important) because we are using Active Directory Powershell modules….

As mentioned earlier, if I would run the script manually, I would not encounter any issues. The script run just fine and create a log of the actions performed.  As soon as we run the script using SCCM, we’ve got errors and these errors are saved into the log file.

Note : Within SCCM console, the exit code would be zero meaning that for SCCM the script has run correctly…but we know that this is not the case….

What you have to know !!!

Windows 2008 R2 is a 64 bit operating system. In 64-bit version of the operating system, the %windir%\system32 folder is reserved for 64-bit applications.  Yes, you read it correctly. This can be confusing but the system32 folder location is effectively used by 64-bit processes.  To support 32-bit, there is an emulator that can be used (called Windows on Windows 64 or Wow64).  The 32-bit application will then get access to the following folder location%windir%\SysWow64.

The other thing you have to know is that the SCCM 2007 R3 agent is a 32-bit application (there is no 64-bit client for this version of sccm).  This means that each time SCCM advertise the package and run the task, it’s a 32-bit process that will start.

To summarize, the sccm 32 bit application was trying to access %windir%\system32 folder. The problem is that the 32-bit application cannot access this folder.  Thus, the 32-bit application cannot start any 64-bit application in system32 folder and the script would fail to run properly on the target computer.

The solution

After identifying the problem, I started googling and found this marvelous kb from  Microsoft Web Site. http://support.microsoft.com/kb/942589

After reading this KB, I’ve discovered that Windows on Windows 64-bit (WOW64) was providing file system redirection.  In other words, each time a 32-bit application tries to access the System32 folder, access will be redirected to the %windir\sysWow64 folder.  Note that this redirection is enabled by default.

So, in order to successfully run your script through SCCM, you have to specifically use the folder %WinDir%\Sysnative.  W0W64 recognizes this folder as a special alias and the file system will not redirect access away.

So, the solution here is to bypass the system redirection by using in the sysnative folder in the command line that will be executed by SCCM. So, in the SCCM, you have to specify a a command line similar to the following

• %winDir%\Sysnative\windowsPowershell\v1.0\Powershell.exe  .\Name_of_the_Script.ps1

 

Note :  If you try to locate the sysnative folder (from a 64-bit), you won’t find it. You have to do this from a 32-bt version.

 

Final Words

I hope this post will be helpful to other people…. I’ve really spent some hours in order to figure out what was the problem.  Hopefully, the next version of sccm will be shipping a 64-bit version of the client and we should not have this problem any more…. let’s hope

Till next time

See ya