In 2009 Microsoft acquired Opalis. They made some improvements to it, and this year they re-wrote it, renamed it “Orchestrator”, and placed it under the “System Center” moniker. It’s a tool aimed at process automation. We’ve been told repeatedly that it’s aimed at ‘non-developers’ and that it’s drag and drop Runbooks would facilitate quick and easy automation for everyone, freeing up the System Admins from having to figure out exactly what the end user wants.
Now, in theory, this sounds pretty nice, right? We don’t have to try to decipher exactly what people want, nor do we have to take up our valuable time by working on a complicated automation. Now, I run into two issues with this. One being that although runbooks are easier than coding up a solution, it’s still not easy enough for the average end user. So we’ll still end up doing it – but hey, at least it’ll be quicker, right? Maybe. And two – this is just yet another automation tool in the System Center family – one that’s fairly ripe with it, considering that every System Center tool offers some kind of automation already builtin.
So what’s it good for then?
Good question. And I’ve think I’ve found a few traditional solutions for it – the largest being that it can act as a mediator in between different systems, especially those that are on different platforms. So it will make a nice middleware piece to quickly integrate data retrieved from a Windows application into a Unix application. While everyone should be using web services these days for data transformation, it just doesn’t exist at the level I’d like to see. So this is a nice fix – not exactly a bandaid, but not the most robust solution ever, either.
However, Orchestrator is kind of awesome for doing crazy things with it. Which is what I’m going to show you. Read on to learn the scenario and what we’re going to do.
