This post will describe the how and why I created a extended System Center 2012 Integration pack. This will be a series of blogs explaining exactly how you can create your own integration packs and activities.

If you like authoring and want to know more on exactly how can you build an OIP please watch closely for the upcoming series. I will completely start with describing the process of using Visual Studio, C# and he System Center 2012 SDK to create a multi functional Integration pack.

                       <<<<<———>>>>> Download Latest version <<<<<———->>>>>

SYNC MPS across your environment!

If you just want to have the benefits of the Integration pack it is here for you to take advantage and use it.

I have though one small request to the people using this Integration pack:

Please send me your feedback on how it works.

If you feel you are missing activities in any on the System Center Suite products please let me know and I will work on adding those into this pack.

A little back ground

As you might know I have been playing with OpsMgr since MOM 2005 and started with Service Manager 2010 in the pre-Beta releases. The thing which fascinated me ever since SCSM 2010 come in the picture is the design of both products. I have posted a series on System Center Central to explain why I got really excited about both products. They are similar? Yes! although we have no agents living in SCSM the base is the same. And that’s where the fun starts. Al the knowledge valid on OpsMgr you can re-use on SCSM. Cool isn’t it ?

And now with the whole System Center line being one Suite there are no boundaries to do whatever you want! Woohoo!

I had Orchestrator on my wish list for a long time but didn’t have time to dive into it. But finally I had some time and a request from a customer to find a way to automate stuff!

The first look at Orchestrator / Opalis I noticed something which I found a little strange.

Why they divided the integration packs of System Center?

If there was a time to show the integration and the suite altogether this was the time. Orchestrator the never ending workflow beneath System Center! It would have been more logical to build a System Center integration pack for the whole suite.

I haven’t seen a customer lately who uses one of the products and Orchestrator. Simply because it is a suite and orchestrator being the orchestrator behind the fully automated self service portals and automatic deployments.

The reason for this will probably lie in the fact the different integration packs are easier to manage around the products then one integration pack. This being said let’s take a look at the reason for building this pack and starting a new adventure.

The Reason

The reason for the integration pack is the lack of a nice way to synchronize management packs across the different systems. The most obvious one being SCOM –>SCSM I simply couldn’t live with the fact a customer will have to manually import packs in SCSM. And more important when they updated a pack in SCOM they again needed to follow the exact same procedure.

Let’s explain this some more.

From the beginning of OpsMgr we have been writing packs with custom classes and monitors to monitor the business critical applications and put them in Distributed applications. Now we have the option to install a SCOM CI Connector to synchronize these into SCSM. There are some steps to be taken but these are not really hard and only need to be done once.

The problem lies in the fact you need to import the SCOM packs which hold the classes into SCSM. If this is one pack, well still not really nice but we can live with this. What if you have like a 100 packs in OpsMgr all custom?

Not only this but OpsMgr authors keep on building, changing and updating these packs so you need to have some kind of way to automate the Management Pack Sync. Well the solution to this is within reach!

The hard way or the scripted way?

First I started to play around with Opalis and PowerShell. With not to much effort I managed to find a “dirty” way to sync packs. basically a couple of PowerShell scripts pulling data and putting it in Orchestrator. Despite this “worked” I had some serious doubts on this solution and well although PowerShell is great I wanted a more universal solution.

Well then there was the other end of the solution which was writing code myself……

Sometimes I think I really like pain and frustration, working long nights and endlessly testing and the occasionally bang my head against the wall. (Would have pulled my hair but unfortunately this is already to late….probably lost those starting writing management packs and learning XML with no experience what so ever…..)

But since I am an optimistic guy and really like a challenge…why not start with reading C# and eventually writing it as well. That’s one part after an hour you can write something saying hello to the world! never understood why you want to say hello to the world though..???? When you are the only person watching your screen, so snap out of it you are not saying HELLO to the world!

And after a while you can do smarter things but man I don’t have months to learn this stuff. And after months saying Hello world in 50 different ways wouldn’t deliver me an integration pack on C#. A little Site note here :

With the power of Orchestrator you can Actually say Hello to the world!

You can attach it to twitter and because of orchestrator you are finally able to actually say HELLO to the world….finally after years and years teaching people to say hello to the world and the only one they where saying hello to where themselves…..

I needed to go a smarter way to bring me up to speed with C# the rest of this story you can read in the upcoming series!

So I decided to go once again the hard way! And to be honest the feeling you get once you manage to get the results you want are worth every minute of pain and frustration ! Hell Yeah!

The results

As explained I went the hard way and managed to write the integration pack and because of this I don’t see limitations in things you can achieve by this. So challenge me

The end result is because we have a nearly similar SDK for both SCSM as well as SCOM I have written a couple of activitiies which are the same code and can both run on both systems. Yes talking about efficiency !

Activities in the pack:

 

 

 

 

 

Export ManagementPack – Activity with possible filters to export any management pack from both SCOM as well as SCSM into a directory.

Get Class – Activity to get a class with possible filters on every property to het classes from both SCOM and SCSM.

Get Rule – Activity to get a rule with possible filters on every property to het classes from both SCOM and SCSM.

Import ManagementPack – takes a directory and imports any managementpack from the directory into the management group works on SCOM and SCSM.

List Managementpack – activity to get a management pack with possible filters on every property to get management packs from both SCOM and SCSM.

Seal Managementpack – Takes a directory with unsealed XML;s, a keyfile and company name and seals every management pack and sends the exported management packs to a separate directory.

Now with these activities you can synchronize management packs across your environment. Imagine you have a Test, acceptance, production setup or something similar and you can now with ease sync your management packs sealed or not across! Or you can backup your MP’s with one runbook from all environments!

SCSM –>SCSM

SCOM –>SCSM

SCOM –>SCOM

Al you need is to create a run book and one important thing!

Seal your custom management packs with 1 key otherwise you are not able to seal the management packs! or need to create a different runbook for every MP which is not really automation

Remember SCSM needs to have sealed management packs to enable data warehouse synchronization unsealed classes never get in the data warehouse. That’s why you need to seal!

Next I will show hot to setup a little runbook which does al this!

Runbook to Sync Management Packs

First You nee to setup the connections to SCOM and SCSM:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The end result your runbook should look something similar to below:

 

You can now schedule the runbook to run a sync on a regular basis! Or create backup runbooks or ……wel tons of other possibilities. Please share them and we can manage a real extended Integration pack for really going the extra miles with orchestrator!

Improvements

Although this works like a charm there is still a Manual step required within SCSM.

You need to Approve the packs for the SCOM CI Connector after running the runbook.

 

 

 

 

 

 

 

 

Another problem could be you are missing dependent management packs in SCSM for the import to fail.

So this isn’t perfect yet but next release will include more cleverness!

Wrap Up

Thing still missing are:

a dependent management pack check.

The next big challenge is to create a activity to approve the packs, this is a pretty complicated task but it should be possible but will take more and serious testing before I can release this activity.

After these I will be working on maintenance mode with the possibility to put groups of objects in maintenance including some clever mechanism to really schedule this in an exchange calendar.

There are probably tons of other runbooks to create with these activities so therefore here you have version 1.

During the series I will include these as well and explain the procedures around the activities and how to write and use them! Keep posted for the next version, I am planning to put the entire project on Codeplex once finished for everyone to learn and benefit from this.

 

Happy Authoring,

Oskar Landman