MMS 2013: Best Practices For Orchestrator & Swedish Hamsters…

Yesterday I attended an awesome session all about Best practices for Orchestrator. This session was presented by the two Über Geeks of Orchestrator, Pete Zerger and Anders Bengtsson, both authors of the book System Center Orchestrator 2012 UNLEASHED:

During this session Anders and Pete openly shared their own experience gained in the field, enabling the audience to avoid many of the potential pitfalls they themselves stumbled upon.

Some of the takeaways of this session:

• Start small and simple. SkyNet wasn’t build in one day.
  (Learn yourself to use Orchestrator by building small and simple Runbooks and go from there);
• Use the Runbook Automation Reality Funnel in order to decide to automate something or not:
  
  (Picture taken from the slide deck of this session.)
  Additional explanation: Only automate those items which are worth to be automated and worth the effort. For example when it takes a week to build a Run Book automating a task which takes 10 minutes to perform manually and only happens twice a month, it will take too much time for the investment to pay back when automating it;
• Automating garbage is still garbage. The only ‘advantage’ with Orchestrator is it will be repeating your mistakes endlessly and way much faster;
• DDD is the starting point not the end station (Drag > Drop > Done).
  Basically meaning: Get the workflow in the design area so it seems to work and go from there.
• After DDD, add controls, checks and fault tolerance;
• When a control or a check returns an error, the workflow has to clean up everything it has done so far so no garbage is left;
• Check yourself before you WRECK yourself!
  (a Runbook might return a success status and yet still fail);
• Don't put too many activities in one RB. It's better to divide them in other RBs and invoke them. It makes the Runbook easier to understand, maintain and the part RBs to reuse in other RBs;
  
  (Picture taken from the slide deck of this session.)
• When building a Runbook, start on the left side of the screen and work to the right. Don’t go up or down since it will make it harder to understand the workflow;
• Use colors for the links:
  Green for success, Red for warning/critical and orange for ‘could be’ situations;
• Use a naming convention for your Runbooks. So when something goes wrong it’s relatively easy to troubleshoot by pinpointing the culprit;
• Exporting a Runbook? Use a ‘Proxy’ Orchestrator environment!
  When a Runbook needs to be exported to another Orchestrator environment it needs to be cleaned so it doesn’t contain references anymore to the environment it came from. The way to go about it is to build a virtualized one server Orchestrator environment which is totally blank. Snapshot it before importing the Runbook. When the Runbook is imported, clean it step by step. Export it so you have a clean Runbook. And then revert to the snapshot so the Orchestrator environment is totally blank again.

So I learned a lot from this session and know for sure all my Runbooks will be different from now on. Really a good session it was. One thing worries me though. Anders kept on mentioning something about hamsters but the real clue eluded me. Perhaps Anders can enlighten me .

Anyone running Orchestrator should see the video recording of this session since there is so much to learn from it. It will help you to make your Runbooks better and help to avoid many of the pitfalls (which I bumped into myself as well).

Channel 9 has all the video recordings of the MMS 2013 sessions. And the good news is, this session can already be viewed online or even downloaded.