If you’ve been using “Run .NET Script” activity in System Center Orchestrator (formerly known as Opalis), you are probably aware that, Orchestrator use 32-bit version of PowerShell.exe, to run PowerShell scripts, since the product itself is 32-bit. This is a problem, if you want to use Exchange 2010 cmdlets, since there are no 32-bit management tools available. Let me explain: Power Shell snap-in “Microsoft.Exchange.Management.PowerShell.E2010”, which must be loaded to run Exchange cmdlets, is only available in 64-bit version of PowerShell.exe. So simply loading the module in “Run .NET Script” activity will not work.

One of the possible solutions to this problem is running 64-bit version of PowerShell.exe inside the script. You can do this like that:

You may wonder what, the “Sysnative” folder is all about. Well, it’s not actually a folder, but an alias. Let me explain: In x64 Windows systems 64 bit system files are stored in “%WINDIR%\System32” folder, 32 bit files are in “%WINDIR%\SysWOW64”. So in order to run 64 bit version of PowerShell.exe, we must run PowerShell.exe from “C:\Windows\system32\WindowsPowerShell\v1.0” folder. But that wound not work due to WoW64 File System redirection. So we would always end up in “C:\windows\SysWOW64”. “Sysnative” is the special alias recognized by WoW64 subsystem (responsible for running 32 bit applications), which indicates that the file system should not redirect the access to SysWOW64 folder.

Maybe it is obvious, but keep in mind that, Exchange Management Tools must be installed on run book server, in order to use Exchange PowerShell snap-in. And another thing: You have to set “$ErrorActionPreference” to “Stop”, as shown above, so orchestrator will recognize activity as failed, if any exceptions occur.