Welcome to my blog, stay tunned :
Home | Blogs | Stephane Eyskens's blog

PowerShell, SharePoint 64 bits and OS redirection


As many of you might know already, when you run PowerShell in 32 bits mode against a SharePoint 64 bits, you'll get unexpected troubles when dealing with some assemblies. For instance, SPFarm.Local is always null...

So, you might think that the fix is easy, we just need to use the 64 bits version of PowerShell and this is true! However, if for some reason, you launch PowerShell from a 32 bits environment (cmd), even if you specify the absolute path of PowerShell 64 bits: c:\windows\system32\windowspowershell\...., windows will automatically and silently redirect your call to PowerShell 32 bits which will lead you to troubles with the SharePoint DLLs.

The operating system performs indeed a redirection, so when a 32 bits process starts a 64 bits process, Windows will always try to find its 32 bits equivalent...but without letting you know :). That oprating system switch between 64 bits and 32 bits is most of the times transparent with Dotnet binaries since they usually are compiled in "Any CPU" mode but that's not the case of PowerShell.

This process and how to avoid that behavior is well described here:


However, if you're running Service Pack2, you don't need to install this fix but on my environment, I was still not able to access Sysnative.

I then, decided to follow Microsoft's recommendation specifying that you can create an NTFS junction. Indeed, if you run:

linkd Sys64 %windir%system32
set path=%path%;Sys64

You'll be able to call your PowerShell script that way (and basically any other 64 bits process):

Sys64\windowspowershell\v1.0\powershell scriptname.ps1

In that case, Windows won't perform the redirection to the 32 bits version of PowerShell.

You can find more info on NTFS junctions here:


Have fun!