One thing you have to keep in mind with Private Cloud Computing is the fact that requirements for CMDB change dramatically. Not only that your CMDB needs to manage new classes (e.g. Virtualization Hosts, Hypervisors, Guests, Clouds etc.) and Relationships (e.g. VM belongs to Cloud, Cloud uses Virtualization Hosts, Virtualization Hosts run Hypervisor etc.,), but it must also be able to be enough dynamic to support Cloud scenarios. Cloud configurations are dynamic (e.g. VM Live Migration, VM Storage Migration), configuration changes can happen any time and can be triggered in many different situations (e.g. System Maintenance, End user Self Service). I had a speech about this topic some days ago at a Microsoft TechNet Event in Switzerland and I’d like to share that information with my blog readers.

You can find the Slide Deck on my SkyDrive –> https://skydrive.live.com/#!/view.aspx?cid=5752DB4B025958B6&resid=5752DB4B025958B6%21386

Important note: the Slide Deck only shows “some” of the challenges with CMDB’s today, not all of them.

One exciting thing I demonstrated in the 60 Minutes Live Demo was how to use System Center Orchestrator to bring any kind of information from your environment to the Service Manager CMDB. In this post I will go through the different steps and will show how to read information from Active Directory (in this example “Organizational Units”) and bring the results to the CMDB (as Configuration Items). You can of course adapt the procedure in this post to bring any kind of information to the CMDB in a very easy way.

Step 1 – Create the needed class, properties and views

As mentioned, the goal is to bring all Organizational Units of an Active Directory Domain to the CMDB. To store that kind of information, we need a defined class with the correct attributes. Because there’s no “OU” class available by default, we have to create it first. I will do this with the Service Manager Authoring Tool.

Create a new MP, then create a new Class with the needed properties. For this example I create the Class “Organizational Unit” with two properties“OU ID” (Key, Autoincrement, Default Value) and “OU Distinguished Name”. If you need any details about using the Authoring Tool to create classes check out these posts:

http://blog.scsmfaq.ch/2011/01/01/creating-classes/
http://blog.scsmfaq.ch/2011/06/04/autoincrement-property-ids/

(Class “Organizational Unit”)

(Property “OU ID”)

(Property “OU Distinguished Name”)

Now lets import the MP and create a view to see and manage objects of the new class.

You could now start creating OU CIs manually, but that’s of course not what we want. Now comes the fun part …

Step 2 – Creating the Orchestrator Runbook

The Orchestrator Runbook must do two things: first read the available OUs from ADDS, and second write that information into the CMDB using the class we created before. very easy, huh? The simplest version of our runbook could look like this:

The first “Monitor Date/Time” activity is used to define the schedule, in my example the runbook is executed every hour and is started immediately after it has been checked in and started.

The second “Get Organizational Unit” activity comes from the Active Directory Integration Pack and is used to read all OUs from ADDS. I use no special criteria here because I want to read information from all OUs.

The third “Get Object” activity is from the Service Manager 2012 Integration Pack and is used to check if a CI for an OU already exists in the CMDB. For this I get all Objects of the “Organizational Unit” class and use a filter to check if a DN from a found OU matches a DN of an already existing OU CI.

The next Link needs to be configured, so that the runbook only continues if no match was found (what means that an OU does not exist as CI in the CMDB).

The last “Create Object” activity comes from the Service Manager 2012 Integration Pack and is used to create new Objects, in this examples new CIs of type “Organizational Unit”. To bring the information from the second activity in, I use published data to populate the property values.

I now check in and execute the Runbook. After some seconds, the OUs should be created as CIs in the CMDB. Let’s take a look …

Cool, that seems to work! Now just keep in mind that our Runbook does not check if an OU was deleted in ADDS. But this could also be configured in the runbook. If this is the case, the CI object status could be changed to “Pending Delete” or something similar. Runbooks in Orchestrator are very flexible and of course you can configure your Runbook to behave exactly how you want it. I will not go any deeper here because this would end up in a 100 page blog post But with the basic information in this post, imagine how far you can go to make your Service Manager CMDB enough flexible to fit your needs and manage all kind of cloud scenarios.

Have fun playing around!
Marcel