In this post I will show you a idea how you can connect Service Manager 2010 with Opalis. The demo scenario is very common, create user account based on a change request. In this demo the change request will be in Service Manager and the user will be created in Active Directory.
Opalis 6.3 will include new Integration Packs for the four remaining System Center suite products – Configuration Manager, Data Protection Manager, Virtual Machine Manager and Service Manager. These four new packs along with the existing Operations Manager pack provide deep, dynamic integration within the Datacenter. And of course you can go cross-platform and cross-application with the 26 other Integration Packs. Opalis 6.3 will be released Q4 CY2010, in other words pretty soon 🙂 More info about 6.3 here. Keep in mind that the information in this article is based on a beta version of the Opalis IP for Service Manager and is subject to change
We will extend Service Manager with a new activity for creating accounts in Active Directory. When Opalis find a instance of the new activity, in “in progress” state, it will read the properties of it and create the account in Active Directory based on them. Opalis will then update the activity in Service Manager so it can continue with other activities in the change. To get this to work we need to perform two major steps, extend service manager and build the workflow in Opalis. The Service Manager step includes two parts, first to author the new management pack with the authoring tool and then create templates in the Service Manager console.
Before we begin, please note that the purpose of this post is to give you a idea what you can do with the new Service Manager integration pack. This is not a production ready solution, for example the Opalis workflow is very simple and without any error handle. Lets begin!
- Begin with start the authoring tool for Service Manager. In the management pack explorer pane, right-click classes, select “Create other class…”
- In the Base Class window, select Activity as base class
- In the Create class window, input contoso.createaccount
- In the contoso.createaccount pane, delete the default Property_16 property
- Create the following properties in the contoso.createaccount class
- Select the Department property and then in the details pane change data type to list
- In the Select a list window, click Create List…
- In the create list window, input Departments as internal name and displayname. Select your new list and click OK
- In the Management Pack Explorer pane, right-click Forms and select Create
- In the Base Class window, select contoso.createaccount
- In the Create form window, CreateAccountForm as internal name
- Design the form as the picture below. Bind each text box to a propety according to the list below
- First name = First
- Last name = Last
- Department = Department
- Add one extra label, and bind (binding path) it to the OpalisInfo property, without any default values. Opalis will populate it later
- Save your new MP
- Switch to the Service Manager 2010 console and import it into Service Manager 2010
- Navigate to Library/Lists and populate the Department list with your departments. Note that this is stored in the management pack. So if you edit the MP in the authoring tool and import it again you will have a blank department list. Instead export the MP from the service manager console and import it in the authoring tool when you need to edit it.
- Navigate to Library/Templates and click “Create Template” in the tasks pane
- In the Create Template window, input “Create Account” as Name and Description, select “contoso.createaccount” as class and contoso.autoaccount as management pack. Click OK
- In the “Form Host” window, click OK to save
- Click “Create Template” in the tasks pane again
- Input “New User Account” as name, select “Change Request” as class and contoso.autoaccount as management pack. Click Ok
- In the “form host” window, change area, priority and risk to suitable value
- Click the Activities tab
- On the Activities tab click Add, add the “Create Account” activity and click OK and save the new template.
Now we have built the new activity in Service Manager and a change template that use it. The next step is to build a workflow in Opalis that picks up this activity and create the account in Active Directory. The following picture show you how a very simple version of that workflow could look. Please note that this workflow is not production ready and only for demo. To get some ideas how you should build your workflow take a look at this (Fault-tolerance in Opalis policies) and thispost (Opalis creating accounts in Active Directory).
The following pictures show the configuration of my three workflow objects. The first object monitors for new objects of our new class (contoso.createaccount). When it finds a object it moves on to the Active Directory object that will create the user account based on information in the contoso.createaccount object. The Active Directory object could of course include a lot more information about the users, but for this example I only use department, first and last name. When the user account is created the Service Manager object udates the object, both with a new status and with information about the account. The account information is written in the opalisinfo property of the contoso.createaccount class. We did add a blank textbox in the form and bound it to the opalisinfo property. That is where this info will be displayed. Ad you can see in the picture below, the “get object” object will query Service Manager to get a list of your classes, and we can easy select our new class.
Note that we can use any property of the new class, Opalis will query Service Manager and show us all the properties we created in the Authoring Tool. It will in the last step update the service manager object, in this scenario the activity.
I don’t use many of the settings that we can use in Opalis when working with Active Directory and Service Manager. My workflow picks up the new instance of our new activity class. It creates a Active Directory user based on the information that we filled in in the change form. When the workflow has created the user, it updated the form with information about the account, see below. Some things that you might want to add is fail tolerance, what if the user name is already in use? Or if there is anything else that interrupts the workflow. See my post about Opalis failover for more ideas around that. You could also input more properties of the user in the change form, so you get more information inserted into Active Directory direct.
This post showed you a simple example of the integration between Opalis 6.3 and Service Manager 2010. The Opalis IP for Service Manager could be used in a number of ways to integrate system and services to and from Service Manager. I guess you have already figure out a number of scenarios where you can use this integration. Good Luck!