- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
Many years ago telephone switchboard operators were made redundant by automation and this is exactly what’s happening in the IT world. Don’t worry, this isn’t going to be another rant about how the cloud is going to do all us IT Professional’s out of a job but it is a reminder that the times are changing.
The Orchestrator 2012 Runbook Designer – a lot easier to become friends with than PowerShell.
In my close to 20 years’ experience as an IT consultant I’ve learnt many things, the most important is that what requires specialist knowledge and time today will be easy tomorrow and automated next week. Installing a network card in 1995 was a challenge (jumpers to configure, IRQ levels to consider etc.), a few years later plug and play made it a mostly painless experience and now it’s simply a check box in a VM’s configuration. I’m sure you can think of many other similar examples from your own experience.
This automation of tasks is now spreading to interconnected systems and that’s why it’s so important for IT Pros not to dismiss the overhyped cloud / private cloud idea as a fad. Because if most of your job consists of repeated, simple tasks, you’re going to be replaced by Orchestrator 2012 or similar products. My advice is to learn what Orchestrator is all about and become the hero in the team who automates the boring tasks; becoming invaluable instead of replaceable.
Runbook Automation
System Center 2012 Orchestrator (Orchestrator from now on) grew out of Microsoft’s acquisition of Opalis Integration Server. It’s a Runbook Automation (RBA) tool, sometimes called IT Process Automation (ITPA). The term runbook (in IT at least) stems from the days of mainframes – where thick volumes of technical documentation defined the manual steps to take to remedy a particular issue. The next step was to automate those steps – hence runbook automation.
Seasoned sysadmins might think– why bother, I can use (Perl, Python, PowerShell – delete as appropriate) to automate tasks. Yes you can, but writing scripts is time consuming, especially if your scripts need to be robust and check for different conditions. Furthermore scripts that are shared amongst IT staff may be altered with no real way of tracking changes. Finally scripts only work in environments where they can reach systems they need to alter, one really big strength of Orchestrator is the many systems it can “talk” to. There’s still a place for scripts in the Orchestrator world, they can be part of a runbook, it’s just a matter of using the best tool a particular job.
The thing to keep in mind when exploring Orchestrator is that just because you can automate a particular process (and almost anything can be), should you? After all, if you automate a bad process you’ve only achieved a very fast way of doing something in a bad way. It’s been said that a day of meetings and decisions about processes results in an hour of work in Orchestrator. In other words, implementing Orchestrator isn’t about the technology, it’s about getting IT and the rest of the business to sit down and nut out their processes so that they can be automated in the best way.
Look at the most time-consuming current processes, or where service levels suffer the most, or common problems that take a long time to resolve; they’re good candidates for automation. A practical example could be that instead of being woken up in the middle of the night when you’re on emergency duty to fix a critical service, System Center Operations Manager has already picked up the failure; a runbook has attempted to restart the service twice and pinged the server in question before notifying you. The standard troubleshooting steps have already been taken and only after that are you involved – with a bit of luck you won’t even be woken up!
In this first part of five where we look at Orchestrator 2012 we covered what Runbook automation is and how Orchestrator fits into it. In the next part we’ll delve into the different pieces of Orchestrator and the installation experience.
