If you’ve ever worked with Service Manager, you’ve probably tried to automate a few processes. Now, in a lot of cases, working with System Center Orchestrator will get the job done just fine. The easily installed System Center 2012 Integration Packs encompass a number of functions that you’ll need to use, and in most cases, probably are enough to get the job done.
At some point however, you’ll want to do more than Orchestrator will let you. Or you might want to do it *faster* than the Orchestrator Integration Packs will do it. That’s where SMLets comes in! It’s a glorious land of PowerShell commandlets that let you do almost everything that Orchestrator can do, but faster and with more control! You can use all the PowerShell logic and syntax you know and love, and use it to make Service Manager all the more awesome.
But don’t forget all about Orchestrator! It’s still an excellent triggering mechanism for our SMLets based PowerShell scripts. So now we’re talking about using Orchestrator to trigger our scripts (think time-based or event-based monitors), and then moving right into a PowerShell activity to run our SMLets based logic. We’ll use the Orchestrator, ‘Run .Net Activity’ to make this all work. Awesome! Except for one minor detail…
Orchestrator only runs PowerShell version 2.
Crazy right? It’s one of those things that we just have to live with for now, but thankfully, there’s a workaround! You can invoke a separate PowerShell process from the initial Orchestrator activity, and that’ll drop you into a PowerShell 3+ environment (this will drop you into the local PoSh version on the box). It’s really quite simple!
powershell.exe { <YOUR CODE HERE >}
Now while that works fine for short snippits, some of the automation I’ve been doing for a customer lately has led to some massive scripts that I’m trying to pass to PowerShell 3, and PowerShell just doesn’t like it. I get some pretty not fun errors, like the following:
“System.Management.Automation.ApplicationFailedException: Program ‘powershell.exe’ failed to execute: The filename or extension is too long”
So, I took one night when I decided once and for all that I was going to find this limit, and document it for everyone else out there who might run into the same problem. After a lot of trial and error, I have an answer! The largest size scriptblock that you can pass to powershell.exe is….
12190 bytes
Now that’s really good to know and all, but we’ve still got to get around this somehow! Well, we’ve got a few options:
1. Write all our PowerShell functions into modules, so we can load the modules and reference them instead of taking up lines in our .Net Activity. This is a great idea and is an excellent long-term plan. I’ve worked with several customers who have really run with this and have made some awesome modules! That said, this requires a bit more time and PowerShell expertise, and so maybe this isn’t the best.
2. Use the technique found on only a single blog on the internet! Check this out: http://www.sc-orchestrator.eu/index.php/scoblog/128-run-the-powershell-version-of-windows-executing-the-orchestrator-runbook-service-in-run-net-script-activity
So yes, after all this time, a simple registry key will allow us to run native PowerShell within our .Net Activities in Orchestrator! When I read this for the first time, I almost didn’t believe it, but lo! We actually got this tip from a customer (who happens to be a PowerShell MVP…) and they’ve been using it successfully for over 9 months, so I can even say that this has been battle-tested!
The quick route to making it work is, as follows:
1. Use regedit to navigate to the following key on your runbook servers: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework
2. Add a new DWORD entry and value of: OnlyUseLatestCLR = 1
3. Sit back, take a deep breath, and bask in the glory of having accomplished something wonderful!
And, as they say, the proof is in the pudding. Well, my pudding has set and is ready to eat! Here’s a quick screenshot of this all in action:
Happy Automating!
