As you might have noticed, Orchestrator can be a bit grumpy when it comes to running Powershell scripts. Some cmdlets will simply not load in a .Net Script Activity.
Running scripts in a .Net Script Activity is really nice, because we have the possibility to publish variables in the script directly to the data bus.
A way around this could be to run scripts remotely on another server or add: Powershell{ /script\ } around your script, but in both cases we loose the possibility to publish all variables to the data bus.
The Problem
Orchestrator runs all powershell scripts in powershell v2 and in 32-bit mode. We can simulate this by:
- Starting a Powershell (x86) console
- Loading version 2 by typing: powershell -version 2
- If we try to load the cmdlets: import-module activedirectory you will see it will fail to load with some strange errors
The Cause
Active Directory cmdlets are compiled using the .Net4 assemblies, and poweshell v2 will only load .Net2 by default.
You can verify this by typing: [Environment]::version in your powershell console. “Major” is the version of the currently loaded .Net assembly.
If you compare on a regular x64 powershell console, and in a x86 v2 console like the one we started in the section above, you will see the difference.
The Solution
Add the following REG_DWORD registry key on the Orchestrator server and set the value to 1, to make Powershell (x86) always load the latest .Net assemblies :
hklm\software\wow6432node\microsoft\.netframework\OnlyUseLatestCLR
Worked like a charm. Thank u very much! we’ve until now used painful workarounds to resolve this but now we can skipp this 🙂
Just a note on this. The presence of this key will stop Operations Manager Console installing on the server so ensure that this is present first before adding the key.
Will this affect current .net scripts and make them unable to run? Or will they continue to work as normal?
I guess that depends on what types of cmdlets you use in your other scripts, and how they will react, but other then that, no.