When Microsoft bought Opalis and re-christened it “System Center Orchestrator,” it was obvious the company was...
making a big play in the runbook automation space.
It’s hardly surprising: Microsoft's been on an automation tear for a while now, having finally acknowledged that while one Windows server is easy to administer via the GUI, scaling that across thousands of servers is becoming difficult. And, as servers start to migrate out of the data center into collocated hosting, the cloud, and so forth, the GUI gets even harder to work with.
Not that Windows Server 8 and PowerShell v3 are getting rid of the GUI. Far from it, in fact: They’re starting to enable a much better-integrated runbook automation strategy than Microsoft has ever had access to before.
Running the book
So what is a “runbook?” In some IT shops, it’s literally a book -- often a thick three-ring binder -- that contains all of the department’s operational procedures. Need to reboot a server? Follow these instructions. Fixing a failed hard drive? Here are the steps. The runbook will usually include the steps we tend to forget about when we’re in panic mode: Notifying users, taking down dependent systems, that kind of thing. The runbook is our script, and if we follow it we’re less likely to make a mistake.
Script being the key word. Look, if you can write something down in enough detail that even the new help desk guy can follow the directions and accomplish the task… well, then you can write it in a language that a computer could follow. Hence, the runbook automation idea. At a very simple level, runbook automation is just using something like Task Scheduler to schedule scripts. At a more complex level, a runbook automation system could run scripts (or workflows, or sequences, or batches, or whatever you want to call them) in response to operational conditions, automatically launching repairs and so forth. Imagine, if you will, an environment where you have an Operations Monitor watching over things, triggering responses in the Orchestrator… hey, there’s a reason it’s called the System Center family, right?
Where Windows 8 and PowerShell v3 fit in
One problem Microsoft’s always struggled with is the fact that, in order to automate something, you really have to get below the GUI. It’s tough to automate button clicks. Although there always are Resource Kit utilities, VBScript, and stuff like that, they’ve rarely been all-inclusive, meaning there were always things we needed to go back and deal with manually, in the GUI. Running out of DHCP addresses and need to spin up a new scope? Tough to automate from the command-line.
Microsoft’s promise with PowerShell -- a promise they made around six or seven years ago -- was that, eventually, it would rebuild all the management functionality into the shell. From there, Microsoft could layer a GUI atop it, or you could interact directly with commands. There would be commands for everything, thus exposing everything to the helping hands of a runbook automation system.
Windows Server 8 is the fulfillment of that promise. With more than 81 add-in shell modules, this OS lets PowerShell touch darn near everything and anything that’s currently missing may well make it into the final product (keep in mind, it’s not even in beta yet).
So there’s the stack: PowerShell and Windows commands at the bottom level, floating up to full runbook automation at the top.
So wait, it’s just scripts and task scheduler?
System Center Orchestrator is certainly a lot more. For one, it encompasses quite a dramatic GUI, meaning you can drag-and-drop sequences rather than hand-typing them. Sure, it’s using PowerShell under the hood, but who cares? Of course, you can always hand-code your own tasks, and then reuse them across whatever sequences you want.
Combined with PowerShell’s Remoting capabilities, System Center Orchestrator can really become an orchestrator, coordinating tasks across multiple servers all in a single sequence. Need to reboot your database server? Well, that means taking the Web server offline for a bit first, and then bringing everything back up in the right order. Orchestrator, handle it for me, will you?
PowerShell: the foundation
PowerShell is truly emerging as an enabling, low-level technology upon which many tools – GUI and otherwise – will be built. I suspect you’ll actually be able to ignore PowerShell for some time, as Microsoft builds more tools atop it. Me, I’d rather be able to dig my hands into the guts of the computer and make it do exactly what I want – and fortunately, PowerShell enables that, too.
ABOUT THE AUTHOR
Don Jones is a Senior Partner and Principal Technologist for Concentrated Technology, LLC, a strategic consulting and analysis firm. Contact him through the company's Web site, http://ConcentratedTech.com.