Friday, July 27, 2012

Orchestrator (#scorch) and Service Manager (#scsm): A Learning Story

systemcenter_2_2d9647a3I am the first person to admit that I sometimes tackle things a little arse-about-face – often because I don’t know better and fumble my way through following my own logic, and my baby-dev skills contribute greatly to this too.

I embarked on this journey at the beginning of this month, and have finally reached a workable solution, with much Orchestrator and Service Manager magic.

My scenario was simple (or so I thought): We have a distribution list that receives email notifications for P1 incidents in the environment, and we need to consolidate these into Service Manager. These P1 incidents come from a variety of sources, so it isn’t as simple as an integration into OpsMgr, or simply processing the emails with the SCSM Exchange connector.
Furthermore, updates to each P1 is sent to the same distribution list, again in different formats and flavours – another reason not to simply use the Exchange connector.

capture-20120726-100154-codesnipThese notifications use a specific template, so searching for keywords is fairly simple, but the email template is HTML, which causes some issues with searching the body of the mail for patterns – especially because each person likes to add their own little flair to the template. An underline here, a colour splash there, and suddenly you are sitting with bloated HTML that cannot be processed that easily. And injecting that into a Service Manager incident became so messy, not even Martha Steward could clean it up.

So began my quest for something that will sanitise the message, stripping out the HTML and leaving only the text. Of course, I ran into a couple of other challenges because of human inconsistencies, and discovered that the only thing these emails have in common is the reference number used by the third party who manages our service desk.

capture-20120726-101110-codesnipThe next thing that I had to do was to decypher the message body programmatically, and pick out the functional area that the incident belongs to, because the ultimate goal is to have a dashboard displaying current P1 incidents with their functional areas.

So, starting with my first IP, I quickly absorbed as much C# as my brain could hold, and quickly expanded this to a company specific integration pack with several activities built in. Now I had the ability to pull out the third party reference number, clean the junk out of the message, retrieve the incident status as well as the functional area owning the incident. Fantastic.

Next up, I built runbooks. I built many of them, until I worked out all the little kinks and bits and bobs and we could start seeing some results. And then I realised I could combine the many runbooks into one runbook. And my super runbook was born, that looks a like this:

capture-20120726-101153-superrunbook

And I wrote this little report:

capture-20120726-101540-firstdash

Awesome. Only, not really.

It was ok, but you couldn’t really, at a glance, see where the problem areas are. So, the next little report was born.

capture-20120726-113707-piereport

capture-20120726-100429-smallpieAnd suddenly, we have something we can use to manage all the high priority incidents in our environment, even though they are logged into a 3rd party system that doesn’t touch our network. The pie graph provides an at-a-glance picture of where the issues are, and the table provides the view, complete with SLA indicators (green for in SLA, red for out of SLA). And I can go ahead and create some Sharepoint widgets and whatnots for easy display (like this one ^).

I learnt some very important things over the last couple of weeks, which I would like to share with you – and is really the point of this post. Most of what I learnt wasn’t really System Center related though, but these are very important learnings and considerations if you are planning on deploying System Center 2012 in your environment to automate some of those pesky little problems, like my scenario.

  1. Ensure that your processes are defined and documented. They may not be perfect, but if they aren’t documented you will have a hard time using them with the technology you plan on implementing.
  2. You cannot use technology to fix processes, but you can use it to identify issues in your existing processed and to drive behaviours around already defined processes.
  3. Sometimes you have to fail at doing something many times to get it right in the end.
  4. Sometimes, you have to start at the end and work backwards to get something right.
  5. Label every object with a meaningful name, and use the description fields too. You will thank yourself later.
  6. Optimise, optimise, optimise. And when you think it is perfect, go back and optimise some more.
  7. Create documentation as you go along – don’t wait until you’re done. (This is not new to me and is how I generally work anyway, but will help anyone who doesn’t currently do this)
  8. Plan before you do, and spend a lot of time planning. It will save you a lot of time in the long run.
  9. There is apparently nothing Orchestrator cannot do – other than predicting the winning Lotto numbers. But its ok, we will forgive it, this time.

Happy Authoring!

No comments:

Related Posts with Thumbnails