In this post I want to give a simple example how you can use Opalis to save time for your service desk. Often the 1st line do the same tasks over and over again. For example when a user calls in a incident around access to the intranet, service desk connect to the desktop machine, check the same things every time and it is almost every time the same issue. Doing this every day is boring and it is easy that there is a difference between how service desk engineers perform these tasks.

This is where Opalis can help. Instead of resources from your service desk should do these simple tasks, let Opalis do them and then update the incident. Opalis will do it quick and exactly the same every time. If you need to change anything, change the workflow, and Opalis will instant start using the new settings. The following workflow is a example of what you could build to save some time. The next obvious phase would be to add more steps to also fix any problem that Opalis detect.

1. The first activity checks for new incidents in Service Manager with classification category equals Desktop Problem
2. Update the incident status to Opalis. This is to show that Opalis is working on the incident
3. Get related computer, affected item, from the incidents. This is the machine where we will do all tests, as this is the machine the end-user has a problem with.
   
4. Gets the windows computer object with the object GUID that we get from the “get related computer” activity
5. Trigger the first troubleshooting workflow, “ping policy”
6. If the first troubleshooting workflow did not found any issues the next troubleshooting workflow will start, process policy
7. Change the incident status back to the status it had before activity 2 in the workflow

The first troubleshooting workflow is shown below. It will start by simple check if the desktop machine is accessible on the network with a simple ping. the workflow till update the incident with the result and then publish the result on the databus. I trigger the same workflow for both a good and a bad result. There are both disadvantage and advantage with that solution. I can use the same workflow for all my troubleshooting policies and that results in simple workflows. A disadvantage is that I cant add that much custom details to the incident update, for example in this example I will only update the incident action log saying the “ping policy” failed. There will be no info around number of pings that failed. I try to keep number of tests in my troubleshooting workflows to a minimum, so if a workflow fails we know direct what it is. For example instead of testing five processes in the same workflow, I can build multiple workflows with one test in each, then simple update the incident with the incident that failed. As the workflow only test one thing I know what the problem is, and I can use same error logging for all workflows.

The incident update workflow generate a random number that will be used as ID for the action log comment in the incident. From each workflow that trigger it the workflow gets result, policy name of the calling workflow and computer name. These three attributes are used to generate the action log update.

Incident action log updated by Opalis. The header of the action log comment is <Workflow name> <Result>, the comment is <Result> <Workflow name> <Computer name> as shown in the figure above, result below. This makes the update action log workflow easy to use for all workflows, they just need to forward workflow name, computer and incident number.

The second troubleshooting workflow checks a process and a service on the machine, and then updates the incident.

This export file have meet “mr Wolf” so it should not contain any unnecessary settings or objects. You can download my policies here, ZIP-file, please note that this is provided “as is” with no warranties at all. Also please read this blog post about export and import of policies.

I have created a Opalis workflow that checks number of active incidents related to a business service. If there are more the X (in my example 4) incidents active a problem work item will be generated. The problem work item will be assign to the problem managers Active Directory group.

The policy is divided into three parts. Part one will find the business service and active related incidents. 

1. Starts at 6 am every day
2. Deletes the temporary file if it exists. The link after “Delete temp file” is configure to continue even if the “Detete temp file” activity fail, becurse there is no file to delete.
3. Gets the business service, in my example “Contoso – Extranet”
4. Gets related incidents to the business service
5. Gets the incident workitem for each incident that is in relationship with the business service
6. If the incident status is equals active, the policy continue over the link, else nothing more will happen

Part two will count number of active incidents and see if there are more incidents then the threshold. In my example the threshold is 4.

1.  If the status of the related incident in the first part of the policy is active, the GUID of the incident will be echo to a temporary file.
2. The Junction activity is used to combine multiple threads to one. As multiple incidents can get back from “get related incidents” we need to make sure the rest of the policy is not ran in multiple threads, we use a junction activity for that.  
3. The combine activity is configure not to publish any data, that why we need to get the business service again. If we choose to publish data the policy might run multiple times and we dont want multiple problem work items.
4. This activity count the number of lines in the temporary file
5.  Checks if number of lines in the file (number of active related incidents) are equal or more then the incident threshold
6. If there are enough with related incidents the policy will move on

Part three will create a problem and assign it to problem managers. It will also link the problem to the business service and all the incidents to the problem.

1. Created a problem work item with some dynamic text depending on the settings in the rest of the policy
2. Link the new problem work item to the business service
3. Query Active Directory to get the Problem Managers (in my example) security group
4. Writes a platform even with the problem work item ID
5. Assign the problem work item to the Active Directory group found in “Get Problem Managers from AD” activity
6. Reads each line in the temporary file. Each line is a GUID of a related and active incident
7. Link each active and related incident from the temporary file to the problem work item

The following two images show the problem work item created in Service Manager. Note that all incidents are related to the problem work item and that it is assign to problem managers.

To save some data processing you could move the “Get Business Service GUID” activity to the other side of “Compare Values” activity. Then you could not contact Service Manager a second time if there was not enough with incidents. The “Get Business Service GUID” result is used in the “Link Problem to Service” activity.

This export file have meet “mr Wolf” so it should not contain any unnecessary settings or objects.

You can download my policies here, 21 Problem Management clean, please note that this is provided “as is” with no warranties at all. Also please read this blog post about export and import of policies.

I read a question on the forum about creating a incident in Service Manager with Opalis. The question was about all the fields you see in the incident form in Service Manger, but not on the “Create Incident with template” activity in Opalis. Many things we see in Service Manager as one form is a combination of objects and relationships between classes. Some more info about that in this post. Opalis handle this object per object and relationship per relationship. In the following policy I create a incident and create a relationship to a user and a computer. The computer is added as related CI and affected CI.

1. Creates a incident in Service Manager
2. Gets a user from the CMDB
3. Create a relationship between the incident and the user
4. Gets a computer object
5. Create a relationship between the incident and the computer, as related CI
6. Create a relationship between the incident and the computer, as affected item
7. Sends a platform event

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!

1. Begin with start the authoring tool for Service Manager. In the management pack explorer pane, right-click classes, select “Create other class…”
2. In the Base Class window, select Activity as base class
3. In the Create class window, input contoso.createaccount
4. In the contoso.createaccount pane, delete the default Property_16 property
5. Create the following properties in the contoso.createaccount class
   1. First
   2. Last
   3. Department
   4. Opalisinfo
6. Select the Department property and then in the details pane change data type to list
7. In the Select a list window, click Create List…
8. In the create list window, input Departments as internal name and displayname. Select your new list and click OK
9. In the Management Pack Explorer pane, right-click Forms and select Create
10. In the Base Class window, select contoso.createaccount
11. In the Create form window, CreateAccountForm as internal name
12. Design the form as the picture below. Bind each text box to a propety according to the list below
    1. First name = First
    2. Last name = Last
    3. Department = Department
13. Add one extra label, and bind (binding path) it to the OpalisInfo property, without any default values. Opalis will populate it later
    
14. Save your new MP
15. Switch to the Service Manager 2010 console and import it into Service Manager 2010
16. 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.
    
17. Navigate to Library/Templates and click “Create Template” in the tasks pane
18. 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
19. In the “Form Host” window, click OK to save
20. Click “Create Template” in the tasks pane again
21. Input “New User Account” as name, select “Change Request” as class and contoso.autoaccount as management pack. Click Ok
22. In the “form host” window, change area, priority and risk to suitable value
    
23. Click the Activities tab
24. 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!