Let me start by saying I love Powershell. It’s a extremely powerful and strangely fun language to code with that can make virtually any aspect of my day faster and easier. Along those same lines I love Orchestrator, because it can take those tasks and automate them. You can even integrate your runbooks with something like Service Manager Self Service Portal to offer delegation of your automated tasks to other users so you don’t spend your day running reports off of scripts you wrote or some other tedious task.
With all of that being said, writing Powershell scripts that work as expected with Orchestrator can be a pain, unless you’re running a 32-bit Windows 7 machine, more on that later.
The Problem with Powershell scripts in Orchestrator 2012
The ability to run Powershell scripts in Orchestrator is accomplished using the Run .Net Script Activity, which comes as part of Orchestrator. The problem is that not only is Orchestrator stuck in a time warp at Powershell version 2, it runs it in 32-bit as well. Not convinced? Plug the below script into a Run .Net Script Activity in Orchestrator and see for yourself.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
if([Intptr]::size -eq 8) { $arch = "64-bit Powershell" } elseif([Intptr]::size -eq 4) { $arch = "32-bit Powershell" } else { $arch = "Unknown Powershell Architecture" } Set-Content -Path C:\Temp\ps_ver.txt -Value "$arch Version $($host.Version.Major)" |
Now it’s true that the differences between 32-bit and 64-bit are minimal (As Done Jones states quite concisely here) there can be some issues when using some Snap-ins and such. However, the differences between Powershell version 2 and version 4 are extensive. Most notably, compatibility with various modules, including the Active Directory module installed via Server Manager in Server 2012 and the module for SCCM 2012. Also a lot cmdlets were updated, adding additional parameters and functionality. There are few things more frustrating than writing a Powershell script just to find that Orchestrator’s Powershell instance can’t load the module or a cmdlet you’re using doesn’t exist.
How to make Orchestrator 2012 script debugging a little easier
So with all of this being said, I have made my life a lot simpler but creating a shortcut that launches a 32-bit version 2 instance of Powershell. Unfortunately, there’s no way to launch Powershell ISE as version 2 if you have a later version of Powershell installed, at least not that I know of.
To Setup your shortcut, copy and paste the following into the Target of a new shortcut:
|
1 |
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -version 2 |
Now if we launch our new shortcut and look at the value of the $host variable, we’ll see we’re running version 2, and since we launched it from the SysWOW64 directory, it’s the 32-bit version.
Powershell Version 2 Instance
Now we can write our Powershell scripts in ISE (Or your code editor of choice), save them, then launch them from our mock Orchestrator 2012 instance to debug them for compatibility issues.
Do you guys have any methods for streamlining Orchestrator script development? If you do, I’d love to hear about them, leave me a comment below. Happy automating!