Home » System Center Service Manager (Page 3)

Category Archives: System Center Service Manager


Welcome to contoso.se! My name is Anders Bengtsson and this is my blog about Azure infrastructure and system management. I am a senior engineer in the FastTrack for Azure team, part of Azure Engineering, at Microsoft.  Contoso.se has two main purposes, first as a platform to share information with the community and the second as a notebook for myself.

Everything you read here is my own personal opinion and any code is provided "AS-IS" with no warranties.

Anders Bengtsson

MVP awarded 2007,2008,2009,2010

My Books
Service Manager Unleashed
Service Manager Unleashed
Orchestrator Unleashed
Orchestrator 2012 Unleashed
Inside the Microsoft Operations Management Suite

Add a new activity to a existing service request

A couple of weeks ago I was working on a scenario were we needed to add a review activity to a service request with Orchestrator. Part of the solution for that scenario were a couple of runbooks that I want to share in this blog post. These runbooks adds a new review activity to a existing service request. All runbooks require a input parameter when it starts, the service request ID. These runbooks set the domain admins group as reviewers in the new review activity.

When adding a new activity to for example a service request it is always added as the first activity. If there are already two activities the new activity is added before them, in other words the new activity is the one that will run first. You can control this by working with the sequence ID parameter. The first activity have value 0 and the second have value 1 and so on. If two activities have the same value they will run at the same time. You can update activities already existing in the service request and insert the new activity in any order you need, as the 70.2 runbook do.

This example is built on three runbooks.

  • 70.1. This runbook adds a new review activity to a existing service request. The new review activity is added as the first activity (sequence ID equals 0) and the Domain Admins security group is set as reviewers.
  • 70.2. This runbook is used to update current activities with a new sequence ID. The runbook simple add one (+1) to each sequence ID value. This is because in the example we want to add the new activity as the first activity, as we add one to each existing activity there will no longer be a activity with sequence id equals 0. We can then create the new activity and add it with sequence id equals 0.
  • 70.3. This runbook is used to get current activities and each sequence ID. The result is written as platform events. This runbook is not really needed but it is nice to have to see the current configuration
We should 70.2 first and then 70.1.


The result is that a new review activity is created in the service request. Domain Admins are set as reviewers on the new review activity.

You can download my example runbooks here, 20120730_addActivity_Sanitize , please note that this is provided “as is” with no warranties at all.

In this blog post I show how activities in a service request can be updated by a runbook activity, for example dynamic approval steps.

Idea around Group Management with Service Manager and Orchestrator

One of the most common tasks for an IT department is administration of security groups. Security groups are used to control access to most of today’s applications. Memberships of some groups are modified often, for example group that control access to project work spaces. Often I see this modification handle as a request to service desk that service desk either does it manual or they escalate it to 2nd line that does it manually. Often it is done direct in Active Directory Users and Computers whit a user account that has unnecessary high permissions. The risk of human errors are always there, as often the Active Directory tool is run with a high privilege account and the engineer modifying the group can misunderstand what to do.

In this blog post I will show a idea how to handle group management with the self service portal in Service Manager and configure Orchestrator to execute all modification. A nice benefit by using Service Manager is that you get tracking of everything, who submitted the change, who approved it and so on. A nice benefit of using Orchestrator is that is will be done the same every time and no manual steps are required. In this example a manager, a user that is configured as manager on a security group in Active Directory can, with the self service portal in Service Manager

  • Add member to security group
  • Remove member from security group
  • Request a list of members of a security group

I wrote a blog post a couple of weeks ago around password reset with Service Manager and Orchestrator. This idea around group management is very similar to the password reset idea, for that reason I will not write down all the steps again. Look at the password reset post how this build the integration between Orchestrator and Service Manager. One difference compared with the password reset post is that I use Business Phone instead of Pager to store the manager value. That is affect both runbooks and when you build the portal offering,

The group management idea is built on a number of runbooks

  • 10.1.1 Invoke 10.1.2 and 10.1.3 to list group members, update the service request and then send a updated list of members to the manager
  • 10.1.2 List group members. This is done with a customer assembly. The Active Directory integration pack includes a “Get Group” activity, but it do not get members of the group, only the group itself. I created a new activity that use Powershell to list group members.
  • 10.1.3 Updates the service request with a new description
  • 10.1.5 Handle add member to group
  • 10.1.6 Handle remove member from group

List group members

A manager navigates to the self service portal and request a list of group members. The manager can select only groups where the manager is owner. Read more about details how that works in the password reset blog post. The 10.1.1 runbook executes, as it is part of the service request template for the list group members offering. The runbook ends with sending a e-mail to the manager. The e-mail contains a list of all members of the security group.


Add/remove member of group

A manager (owner of at least one group) navigates to the self service portal and select either the Add User To Group offering or the Remove User From Group offering. Select which group and input the username of the user to add or remove to/from the security group.


This was a simple example of what you could do with Service Manager and Orchestrator. You can of course add a lot more features and  details. I didn’t spend any time on fault tolerance or error handling in the runbooks as this is an example, but for all production runbooks you should really spend time on that.

You can download my custom assembly file for list group members in Active Directory, Service Manager management pack and Orchestrator runbooks here, 20120716_GroupManagement. Please note that this is provided “as is” with no warranties at all.


Richer Incident Reporting with the Service Manager self-service portal

With default settings you can report incident with the self-service portal in Service Manager. But the form is generic, and often you want to customize it. For example if someone reports a issue with e-mail you might want them to submit some e-mail specific details like Outlook version and location. I was looking into this last week and want to share with you some ideas. We can publish incident templates in the self-service portal the same way we can do with service request. They are both published as request offerings. When we configure a request offering we setup a number of user inputs. We can do this with a incident template too, but there are not many suitable fields on a incident to store custom data, like Outlook version. Instead we can create activities on a incident template and on each of them store data, but out of the box we have only the manual activity to use, and lets say we want to store five custom fields, we don’t want to use five manual activities in the incident template. Instead we can create a new activity class, that includes for example five generic fields. To do that we need to start in the Service Manager Authoring Tool

  1. Start Service Manager Authoring Tool
  2. Create a new Management Pack, for example ContosoManualActivity
  3. Right-click Classes and select Create Other Class
  4. Base Class, select Manual Activity as base class
  5. Create Class, input Contoso.Manual.Activity as internal name
  6. Delete the default property named something like Property_XX
  7. Click Create property, input internal name, for example text01
  8. Click Create property, input internal name, for example text02
  9. Click Create property, input internal name, for example text03
  10. Click Create property, input internal name, for example text04
  11. Click Create property, input internal name, for example text05
  12. Save the management pack
  13. Seal the management pack, more info how to seal a management pack and generate a key file here
  14. Start the Service Manager Console, import the seal management pack (mp file)
  15. Restart the Service Manager console to reload class structure
  16. In the Service Manager console navigate to Library/Templates
  17. Click Create Template in the Tasks pane
  18. Create Template, input a name, for example Contoso – Template – Manual Activity. Select the Contoso.Manual.Activity class (under basic classes). Create a new management pack named for example Contoso Activity where you store the template
  19. Manual Activity Template, input a title, for example Contoso – Manual Activity. Click OK
  20. Click Create Template again
  21. Create Template, input a name, for example Contoso – Template – Mail Incident. Select Incident as class and select the same management pack as before
  22. Incident Template, configure classification category, source, impact, urgency
  23. Click on the Activities tab
  24. Click Add…
  25. Select a class, select Contoso.Manual.Activity and click OK
  26. Select Template, select Contoso – Template – Manual Activity
  27. Click OK
  28. Click OK to close the Incident Template form
  29. Time to publish this as a Request Offering. Navigate to Library/Service Catalog/Request Offerings, click Create Request Offering from the Tasks Pane
  30. Create Request Offering, General,
    1. input title Exchange Issue
    2. Template name, Contoso – Template – Mail Incident
  31. Create Request Offering, User Prompt. Note that we use only strings here. You could configure your management pack properties to be true/false or any other data type. You can then also use the same data type in Service Manager user input, for example let the user select Outlook and Windows version from a drop down menu.
  32. Create Request Offering, Map Prompts,
  33. Create Request Offering, Publish. Change Offering Status to Published. Finish the wizard
  34. Create a new Service Offering, named for example Incident, and include the request offering you just created. Don´t forget to change the service offering status to Published.
  35. Browse to the self-service portal now
A user can now choose Incident as a category. Under Incident there is a offering named Exchange issue. The Exchange issue form includes the questions we added. Might be a good idea to also include a free text description field and map it to the default incident description field.

If the user then submits the incident you can see all the custom data under the activities tab. As we added the text fields to the new activity class. That is not optimal to have it there, as it will require some extra clicks to show it.

You can of course solve this with Orchestrator 🙂 I have create a simple runbook that picks up the incident and merge the User Input data with the Description field. The User Input field is a default field on a incident that contains all the data we added to the custom text fields on the activity. You could trigger this runbook automatically when a new incident of this type is created. One thing to think about is that you want to merge the User Input data with the already existing Description field, make sure not to overwrite it. As you can see in the last image we also get the XML code from User Input. I did not create a runbook to clean that, but you could of course do that with a runbook too, to only keep the user input text.

The result, you can use custom input fields, different for different type of incident, to let user report incident with the self-service portal.


As usual thanks to Patrik  for Service Manager authoring support

Please note that this is provided “as is” with no warranties at all.

Password reset with the Service Manager self-service portal

In this blog post I will show you how you can setup password reset with the self-service portal, Service Manager and Orchestrator. The scenario is that a manager should be enable to reset password for colleagues reporting to he or she. The manager could also be something like instructor or teacher for a class. The request offering for password reset should only be shown to members of the “Manager” user role, and the manager should only be enable to reset password for members of their team. To make this work you need to configure the manager attribute on your users in Active Directory, as shown in the image below. We will use a dynamic query based list to show only people reporting direct to the manager. In this example I use Orchestrator to generate a 10 characters complex password, but you could also add “New Password” as a parameter to the service request. Then you input the new password in the service portal. You could also configure the runbook to check the “User must change password at next logon” checkbox on the user account. That check box sometimes result in issues for some applications so I have not included it in this demo.



  • Start
  • Get Runbook Activity. Gets the runbook activity, we submit the ID as a input parameter to the runbook from Service Manager
  • Get Related Service Request. We pickup the service request from the runbook activity, by the relationship
  • Get Related User. When we configured the query list in Service Manager we configured that the user should be set as a related item to the runbook activity. This activity gets the related user
  • Get Service Request. Read the Service Request item
  • Get User. Read the User object
  • Generate New Password. Generates a 10 characters complex password
  • Reset User Password. Set the password to the generated complex password
  • Update Service Request. Update the description field on the service request with the new password and account information

The runbook is quite simple, we start with the runbook activity as we get it from Service Manager as ObjectID. We then pickup related service request and user. We generate a new password and set it on the user. We then update the service request with new description, including the new password.


Service Manager Side

  1. Start the Service Manager console
  2. Synchronize the runbook over to Service Manager by using the Orchestrator connector
  3. Navigate to Library/Runbooks, select the runbook (2.2.1 Password Reset) and click Create Runbook Automation Activity Template in the Tasks pane
  4. Create Template,
    1. Input a name, for example Contoso – Runbook Activity – 2.2.1 Password Reset.
    2. Create a new management pack, for example Contoso Password Reset.
    3. Click OK
  5. Runbook Activity Template,
    1. Check Is Ready For Automation
    2. Input title, for example Contoso – Runbook Activity Template – 2.2.1 Password Reset
    3. Click the Runbook tab
    4. Map ObjectID to Object/ID
    5. Click OK
  6. Navigate to Library/Templates. Click Create Template from the Tasks pane
  7. Create Template,
    1. input name, for example Contoso – Service Request Template – Password Reset
    2. Select Service Request as Class
    3. Select the Contoso Password Reset management pack
    4. Click OK
  8. Service Request Template,
    1. Input title, for example Contoso – Service Request – Reset Password
    2. Click the Activities tab
    3. Add “Contoso – Runbook Activity – 2.2.1 Password Reset” as activity
    4. Runbook Activity Template, click OK
    5. Click OK
  9. Navigate to Library/Service Catalog/Request Offerings
  10. Click Create Request Offering in the Tasks pane
  11. Create Request Offering – General, input title, for example Password Reset
  12. Create Request Offering – General, select Contoso – Service Request Template – Password Reset as template
  13. Create Request Offering – User Prompts, add one prompt named User and configure it as query result
  14. Create Request Offering – Configure Prompts, select the User prompt and select Configure
  15. Configure Query Results,
    1. Select Class, change to Combination classes and select User (advanced)
    2. Configure Criteria, select Manages User and select Pager, click Add Constraint. Configure as image below. Use “Set Token”. Why do we use Pager? The Token: Portal User Name is in format CONTOSO\leni (DOMAIN\username). We don’t store that on a user CI in Service Manager, we store username and domain, but not in that format. Instead I have updated each manager with that information in the Pager attribute, as we don’t use it for anything else in this environment. You can easy update the Pager attribute with a runbook, the export file includes a example of that.
    3. Display Columns. select User (advanced), the Object/DisplayName and Domain User or Group/User Name
    4. Options, select “Add User-selected objects to template objects as related item: select the Runbook Automation Activity
    5. Click OK
  16. Create Request Offering – Map Prompts,
  17. Create Request Offering – Publish, change offering status to Published
  18. Create the request offering
  19. Navigate to Library/Service Catalog/Service Offering
  20. Click Create Service Offering from the Tasks pane
  21. Create Service Offering
    1. General, fill in title for example Manager
    2. Request Offerings, add the Password Reset request offering
    3. Publish, change offering status to Published
    4. Finish the wizard and create the service offering
  22. Navigate to Library/Groups. Click New Catalog Group
  23. Create Catalog items group,
    1. General, group name, for example Contoso Managers
    2. Included Members, click Add, add the Password Reset request offering and the Manager Service offering
    3. Finish the wizard and create the group
  24. Navigate to Administration/Security/User Roles
  25. Click Create User Role > End User
  26. Create User Role,
    1. General, Name, for example Contoso Managers
    2. Management Packs, select the Contoso Password Reset management pack
    3. Catalog item Groups, select Contoso Managers
    4. Users, add managers
    5. Finish the wizard and create the user role
Now, navigate to the Service Manager portal with a manager and try the new server, password reset. As you can see in the images below members of the Managers user role can see Manager service offering, and in it there is the Reset Password request offering. When the manager go to the request form a dynamic list of all user that report to the manager is shown. The manager can select one account and click Next, Submit. The runbook execute and reset the password and update the service request. The manager can then look under “My Requests” in the portal and see the new password.


You can download my example runbook here, 20120617_PasswordReset_WOLF

Please note that this is provided “as is” with no warranties at all.

VM lifecycle in Service Manager with Orchestrator magic

A couple of weeks ago I was speaking at a System Center 2012 event in Stockholm/Sweden. My session was around Orchestrator and Service Manager integration. On stage I created and demo a scenario where Service Manager, Virtual Machine Manager and Orchestrator was used to administrate lifecycle of virtual machines and virtual services. My laptop only hosted Orchestrator and Service Manager so in many of the example runbooks I only create a computer object in Service Manager. But as you realize you could re-place that with any kind of Virtual Machine Manager activity. In this post I will share with you the demo files, runbooks and management packs I used.

The demo scenario was that someone could order a virtual machine or a service (service template) from the self service portal in Service Manager. Orchestrator and Virtual Machine Manager then created the machines and so on. When you order a new virtual machine you needed to input a expire date, for how long will you need the virtual machine. You also need to input a cost center, to know who should approve and how will pay for it. When a virtual machine is close to the expire date it is picked up by a runbook that notify the owner. The owner can use the portal to extend the date or simple don’t. If the machine pass the expire date Orchestrator will shut it down. When it has been shut down for some months it is deleted. The demo also showed how to generate reports to follow up which how much each cost center should pay. When the order is complete the user can see the result in the Service Manager portal


The cool thing about this demo is not only that we can create any kind of virtual environment with Virtual Machine Manager 2012, instead of just deploying machines we can follow up on who order, who approved and we can also see how much each cost center is using.

The solution is divided into multiple steps

  1. Extend the Windows Computer CI class in Service Manager with a couple of extra properties, like order date, cost center, owner, expire date, approver and cost. (MP attached)
  2. Create a new CI class in Service Manager to store cost information (MP attached)
  3. Create a runbook that creates computer objects (export file attached)
  4. Publish a service in the self-service portal in service manager (not included in this post, ping me if you need step by step guide)
  5. Create a report to follow up number of orders and total cost per cost center
  6. Create runbooks to administrate removal of expired objects (export file attached)

Extend the Windows Computer Class

To add extra attributes to all Windows Computer CI objects in Service Manager we need to extend the Windows Computer class. We can do that with the Service Manager Authoring Tool, download here. (http://www.microsoft.com/en-us/download/details.aspx?id=28726). When the Authoring Tool is installed follow these steps to extend the Windows Computer class

  1. We need to seal the management pack we will create in the Authoring Tool. If we don’t seal it we cant use it with Orchestrator or the data warehouse. To seal it we need a keyfile. SN.EXE (.NET Framework Strong Name Utility) is a tool that we can use to generate that key file. Open a command prompt and navigate to C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A\bin
  2. To generate a key pair run, SN.EXE -k C:\temp\snKey.snk
  3. Start Service Manager Authoring Tool
  4. From the File menu choose New
  5. New Management Pack, save the new management pack in a suitable folder, for example C:\TEMP\Contoso.WinCompExt
  6. Use the Class Browser to find the Windows Computer class, right-click it and select View
  7. In the Management Pack Explorer pane, note all the default properties. Right-click on the Windows Computer class and select Extend Class
  8. Target Management Pack, select Contoso.WinCompExt to save the extension in the management pack
  9. Click Create Property and add the following properties. Edit each property in the Details pane
    Internal NameNameData TypeNote
    ContosoOrderDateOrder DateDate Time
    ContosoCostCenterCost CenterString
    ContosoExpireDateExpire DateDate Time
  10. Save your management pack
  11. In the Management Pack Explorer pane, right-click Contoso.WinCompExt and select Seal Management Pack
  12. Seal Management Pack,
    Output Directory: C:\TEMP
    Key File: C:\temp\snKey.snk
    Company: Contoso
    Click Seal and then Close
  13. Start Service Manager Console and import the sealed Contoso.WinCompExt management pack from C:\temp\Contoso.WinCompExt.mp (make sure to select the .MP management pack, MP=Sealed XML=Unsealed)
  14. Close the Service Manager Console and open it again, this will re-load class information
  15. Navigate to Configuration Items/Computers/All Windows Computers and open a computer. Note all the new properties that are shown on the Extensions tab. We have now extended the Windows Computer class with the properties we need for the computer lifecycle demo.

The pricelist

One of the properties we extended the Windows Computer class with is Cost. My idea is to use this field to show the monthly price of the configuration item, the computer. We could input that price manual but we can also build a price list inside of Service Manager. To do that we can use the Authoring Tool to create a new CI class, Contoso Price List.

  1. Start Service Manager Authoring Tool
  2. From the File menu create a new management pack, for example C:\TEMP\ContosoCost
  3. In the Management Pack Explorer pane, right-click Classes and select Create Configuration Item Class
  4. Create Class, input ContosoCostItem as internal class name
  5. In the Details pane change the Name to Cost Item
  6. Delete default Property_4
  7. Add two properties, AvailabilityLevel and Cost. Change AvailabilityLevel name to Availability Level. Change data type to Integer for the Cost property. Change Key to TRUE on the Availability Level property
  8. Save the managemente pack
  9. Seal the management pack the same way we did with the first management pack
  10. Import the management pack into Service Manager. Remember to import the sealed version, MP file.
  11. Restart the Service Manager Console
  12. Navigate to Configuration Items
  13. Create a new folder, name it Price List. Create a new management pack, for example Contoso, and store the folder in it
  14. Select the Price List folder and click Create View in the Tasks pane
  15. Create View
    Name: All Items
    Criteria: All objects of the ContosoCost Item class, where object status does not equals Pending Delete
    Display: Availability Level and Cost
  16. Select the new All Items view and click Create Contoso Cost Item from the Tasks pane
    DisplayName: Gold
    Availability Level: Gold
    Cost: 100
  17. Click Create Contoso Cost Item from the Tasks pane
    Contoso Cost Item Properties
    DisplayName: Silver
    Availability Level: Silver
    Cost: 70
  18. Click Create Contoso Cost Item from the Tasks pane
    Contoso Cost Item Properties
    DisplayName: Bronze
    Availability Level: Bronze
    Cost: 40
  19. Click OK
We have now created a new CI class and 3 instances of it. Next step is to create a runbook that creates computer accounts in Active Directory. This runbook will be syncronized to Service Manager and used as a runbook activity. The runbook will read the price for each computer that is order from the new CI class we just created.


This example use a number of runbooks, all included in the export file attached to this blogpost. I will explain each one of them and you can import them and look at the in the Orchestrator Runbook Designer

  •  700.10 Cost. This runbook will get the correct price for the new computer based on the price list in Service Manager
  • 700.11 Count Machines. This runbook counts existing machines to figure out a suitable computer name for the new machine
  • 700.2 Update Approver. This runbook updates the approver step in the service request template based on the cost center. The runbook attach approver to the manual approval step
  • 700.3 Create VM (picture) creates the new computer
  • 700.4 Update Service Request, updated the Description attribute on the Service Request. This is used when the machine is create to communicate the new computer name to the user. The user will see this in the self-service portal
  • 700.5 This one will find all VMs that are close to expire date (2 months or less) and send a e-mail to the owner of the machine. Also flag the virtual machine that e-mail has been sent
  • 700.6 Get Cost Center. This runbook gets approver for each cost center. This could be done with a external database or any other way
  • 700.7 When a VM have passed expire date it is shut down in Virtual Machine Manager
  • 700.8 Deleted expired VM, when the VM has been shutdown for 2 months it is deleted
  • 700.9 Update expire date, if the user order a new expire date for the computer in the portal, this runbook will update the virtual machine with the new expire date
  • 500.1-500.3, these runbooks are used to generate the HTML based report. One master runbook and then one runbook for each cost center



Reporting have changed a lot with Service Manager 2012. We now have cubes to analyze the data and we use Excel to easy drag and drop fields to build table. The first image below show a table with everything that cost center 2 is running right now. If you want to sum everything into a one cell, total cost, it is a bit more difficult now when we are running cubes. We need to extend the cube to include that field. If you don’t know how to do that you could solve it with SQL reports or using Orchestrator. In the second image below you can see a HTML based report generated by a couple of runbooks in Orchestrator.


Runbooks, SC12day_demo_wolf
Management packs SC12 day MPs


Please note that this is provided “as is” with no warranties at all.

Convert a incident to a service request, with a bit of Orchestrator magic

A couple of days ago there was a question about converting a incident in Service Manager to a service request. The scenario was around a support call first register as an incident, but later the operator finds out it should be a service request. Out of the box in Service Manager there is no tool to move the data we have already input in the incident over to a new service request. But of course we could use Orchestrator to do it 🙂 We could also build this workflow as an internal workflow in Service Manager… but that would take me a lot of hours; this runbook only took two cups of coffee. In this post I will show a idea how to build a task that you can run against a incident in Service Manager to “convert” it into a service request. The incident is not really converted, we copy the info we have in the incident over to a new service request, link them together and close the incident.

The runbook is trigger by a task in Service Manager, input parameter is only the incident ID.




  1. Initialize Data. Input parameter is IncidentID. ID of the incident we want to “convert” to a service request
  2. Get Object. Gets the incident from Service Manager. This step also verify that the incident don’t have Closed as status
  3. Send Platform Event. If the incident is closed or cant be found a platform event is generated. For example if you trigger the runbook with a incorrect incident ID from the Orchestrator console it will not run
  4. Get Relationship. Gets related Active Directory User to the incident
  5. Get Object. Gets the user that step 4 found
  6. Create Object. Creates a new service request and writes info to it from the incident
  7. Create Relationship. Create a relationship between between the service request and the affected user (relationship type = user)
  8. Create Relationship. Create a relationship between the service request and the incident (relationship class = is related to work item)
  9. Format Date/Time. Gets the current time stamp in a correct format, will be used when creating comments on the incident and the service request
  10. Run .NET Script. A small PowerShell script that generates a GUID. The GUID will be used as ID for the incident comment
  11. Create Related Object. Creates a Trouble Ticket Action Log (action log comment) on and relates it to the incident. The runbook writes a comment saying the incident has been converted to a service request (relationship type = Trouble Ticket Has Action Log)
  12. Update Object. Resolve the incident, change status to Resolved
  13. Run .NET Script. A small PowerShell script that generates a GUID. The GUID will be used as ID for the service request comment
  14. Create Related Object. Creates a Trouble Ticket Analyst Comments (log comment) and relates it to the service request. The runbook writes a comment saying the service request was based on the incident
  15. Send Platform Event. Writes a platform event with service request ID and incident ID

That is the runbook, the next component is the task in Service Manager. We could trigger the runbook from Orchestrator console and input the incident ID manually, but it is easier with a task in Service Manager. In the Service Manager console, in the Library workspace you can create a new task with the following settings.

  • General/Task name: Contoso – Convert Incident to Service Request
  • General/Target class: Incident
  • Categories/Categories: Incident Management Folder Tasks and Incident Support Groups Folder Tasks
  • Command Line/Full path to command: C:\TEMP\ORT251\ORTRunbookLauncherCLI.exe
  • Command Line/Parameters: /IncidentID=$Context/Property[Type=’WorkItem!System.WorkItem’]/Id$
    (the parameter is the work item ID that you can insert from the  “Insert Property” button)
As you can see I use ORTRunbookLauncherCLI.exe to start the runbook. ORTRunbookLauncher.exe is part of Orchestrator Remote Tool that you can download from Codeplex. These tools provide a way to launch Orchestrator runbooks remotely from a UI or a command-line. Note that before you can run ORTRunbookLauncherCLI.exe you need to run ORTUIGenerator to generate a config (XML) file for the runbook you want to trigger. Lets look at a example
We select a incident and click the “Contoso – Convert incident to Service Request” task
…the task starts and as we can see the task forward the incident ID to the runbook and starts the runbook

…the runbook runs and generates a platform event

…if we look at the incident it is now resolved and has a new comment

…also a relationship to the new service request

…and when look at the service request we can see that data has been copied over from the incident

Summary: We have built a task in Service Manager that use the Orchestrator Remote Tool to trigger a runbook. The runbook connects to Service Manager, copies the data we have in the incident over to a new service request, resolve the incident and update both incident and service request with relationships and comments.

You can download my runbook example here, 20120410_Incident2ServiceReq_WOLF.  Please note that this is provided “as is” with no warranties at all.


Dynamic approval steps in Service Manager with a bit of Orchestrator magic

In Service Manager we can configure an approval step with “Line manager should review”. That means that the manager for the user who created the for example service request needs to approve. The manager is configured on user account in Active Directory.  This works dynamic and fine as long as it is actually the manager that needs to approve. But what if we request a service and the approver depends on who is requesting the service and what kind of settings of the service? Then we can’t use the “line manager should review” feature and we don’t want to create one template for each possible scenario.

In this blog post I will show how you can build dynamic approval steps in Service Manager together with Orchestrator. I will use Orchestrator and Service Manager 2012, but it works almost the same in Service Manager 2010 with the Service Manager Integration pack for Orchestrator or Opalis. The really cool thing is that we use a runbook to update an approval step within the same service request.

In my scenario engineers can request temporary permissions from the Service Manager self-service portal. Instead of engineers have accounts with all permissions that they can possible need, they need to request permissions when they need it, and the permissions are removed after X hours. If we lose an account it doesn’t have any permission after X hours and no engineer will have an account with too much permission.

High level steps

1. Engineers request permissions for a system from the self-service portal. The engineer fills in a form with all needed information based on a service request template. The engineer can select system from a drop down menu.

2. The service request template includes tree steps

2a. Update manual approval step (Runbook)

2b. Manual approval step (Default approval step in Service manager). This approval step is blank, no configuration by default. Instead it is the first runbook activity that updates this approval step with reviewers.

2c. Grant engineer permissions (Runbook)

3. The first runbook activity in the template run and update the approval step with suitable approval group based on which system the engineer request permission. For example if the engineer have request permissions to Exchange the manual update step will be configure with the Exchange Expert Team group.

4. An expert team approves the request. This step is blank in the template; the previous runbook activity will add a security group as reviewers depending on the permissions that were requested.

5. The second runbook activity run and adds the engineer to a suitable security group in Active Directory depending on what kind of permissions that was requested. The runbook also writes a log to a log database and updates the service quest with the result.

6. The engineer can track the service request during the process and also see the result of the service request in the self-service portal


Let’s look at the runbooks


This first runbook starts with the runbook activity ID; it then gets the related service request. After that it maps the service the engineer input to a security group in Active Directory. After that it finds related Review activity and creates a related reviewer object. It then gets the group of reviewers from the CMDB and creates a relationship between the new reviewer object and the group from the CMDB. The second runbook is the runbook that will grant the engineer permissions. It starts after the manual approval step that the first runbook configured.

The second runbooks goes from runbook activity ID to service request, and then it gets the requesting user from the input in the Service Request. The runbook creates a time stamp plus the number of hours that the engineer requested permissions for. Then it maps the service in the service request to a security group in Active Directory and adds the user to the group, it then writes the settings to a log database. The last activity triggers next runbook. This runbook updates the service request with the result.

Looking at the process from the self-service portal it will look like

The runbook that grants permissions to the engineer writes all settings to a database. This database will be used to figure out when it is time to remove engineers from security groups again.  The database in my example is very simple, see picture. You can schedule a runbook like the one below to Query the database every X minute to see if there is any expire date passed, and if there are the user will be removed from the security group. You can also use this database as source for a report showing current temporary permissions. You can use SQL Report Builder to build a report like that, download Report Builder here.

None of my example runbooks have any activities for error handling; please see this blogpost for more info around fault tolerance in runbooks. I have not uploaded an export file of these runbooks, as it is a lot of values to re-configure in every environment. Instead I have uploaded a ZIP file,  20120319, with screenshots of all settings in all activities.

 Please note that this is provided “as is” with no warranties at all.

Integrate Service Manager and SharePoint announcements with a bit of Orchestrator magic

In this post I will show you some ideas how you can administrate announcements in SharePoint with Service Manager and Orchestrator. The idea is that announcements are owned by Service Manager and you only use the Service Manager console to create, update and delete announcements. Everything around announcements are then synchronized to SharePoint with Orchestrator. In Service Manager 2012 the announcement part is removed from the self-service portal, but there is an announcement webpart in SharePoint that you can use. To add an announcement webpart to your Service Manager 2012 self-service portal you can

  1. Browse to your Service Manager self-service portal with an administrator account
  2. Click Home to navigate to the root page
  3.  On the Site Actions menu, select edit page
  4. Click the Insert tab and select Web Part
  5. Select Lists and Libraries/Announcements and click Add
  6. Now, select the Announcements web part and from the List Tools menu select List/List Settings
  7. On the List Settings page, select Create Column
  8. Name the new column Announcement and click OK to save. We will use this column to store the Service Manager announcement ID, to keep the link between an announcement in Service Manager and and announcement in SharePoint.


The first runbook is monitoring new announcements in Service Manager. When a new announcement is created in the Service Manager console this runbooks is triggered. The runbook first converts the text that Service Manager has in the announcement from rich text format to plain text. During tests I found some issues around publish text in rich text format on the SharePoint site, so now all text gets published as plain text. The last activity comes from the SharePoint Integration Pack that you can download from Codeplex. The activity creates a list item in the new announcement webpart.


As you can see in the pictures we created a announcement in the Service Manager console, the runbook picked it up and created a list item in SharePoint. The title on the list item in SharePoint  is a mix of the announcement title and priority. Next runbook handle updates. When you update a announcement in Service Manager this runbook writes the changes to SharePoint. We use the column we added in the announcement webpart to keep the link between announcement in Service Manager and list item in SharePoint.

It get a bit more complicated when looking at how to handle deleted announcements. Many items in Service Manager have a status that we can look at, for example if the status is equals to closed or resolved. Announcement is deleted as soon as we delete them from the console. Orchestrator can monitor for changes on objects and when a object is created. But we cant monitor when a object is deleted with Orchestrator. But, Service Manager can do that. Service Manager can trigger a workflow when a object is deleted. That is how we will do, we will have a internal Service Manager workflow that will run when a announcement is deleted, it will trigger a runbook that will remove the corresponding list item in SharePoint. The Service Manager workflow will actually drop a file in a folder that Orchestrator will pick up. You can build the workflow with Service Manager Authoring Tool. If you want to look at the example I use you can download it here, SCSMAnnouncements . The picture below show the script that the workflow run. As you can see it writes the announcement ID to a file, the file is named with a GUID and stored in a remote folder on the \\FIELD-SCO02 server.


Orchestrator will monitor the folder and pick up any file written to the folder. The file includes the announcement ID of the deleted announcement. Orchestrator will find the corresponding list item in the announcement web part in Sharepoint and delete it.

I also created one runbook that will start when a new problem is created in Service Manager with priority 5 or lower. It will then create a announcement in Service Manager with information from the problem work item. It will also update the action log of the problem work item with information about the announcement. The other runbooks could then trigger on the announcement and create the announcement in SharePoint. This runbook includes a Run .NET script activity that generates a GUID. The GUID is used as ID for the trouble ticket action log on the problem work item. The runbook also includes a Map Published Data activity, that is because the Service Manager announcement and the problem work item handle priority different.

These runbooks use a “RTF to Plain Text” activity that my friend Patrik Sundqvist have built for the community. You can download the RTF-to-PlainText integration pack here. Thanks for the help Patrik, as always!

Please note that this is provided “as is” with no warranties at all.

Automate Operations Manager with Orchestrator and Service Manager

Lately I have been working with a number of automation scenarios where we use Service Manager and Orchestrator to automate Operations Manager. The scenarios have not really been target to end-users, instead to Operations Manager administrators and subject matter experts (SME). For example install agent and uninstall agent, maintenance mode and disable alerts. All this can be done from the Operations Manager console, but that require first knowledge and then of course permission. Another benefit with automate it based on a form is that is will be done the same everytime, independent on which administrator performing the task.

For example if you want to allow subject matter experts, like your Exchange team, to install Operations Manager agent on new Exchange machines, you will need to give them Operations Manager administrator permissions. Alternative they will contact your Operations Manager administrator’s team and request to get the agent installed. With Service Manager 2012 self-service portal you can publish this as a service request. Anyone with enough Service Manager permissions can request an agent in the portal, an operations manager administrator can approve it and then Orchestrator will install the agent.

Another common scenario is that a team gets an alert that they don’t want. For example a service is not running on server X. Instead of forwarding this ticket to the Operations Manager team they could simple disable it for the server themselves, after an Operations Manager administrator have approved it in Service Manager.

In this blog post I want to share with you a runbook that disable a rule or monitor based on ticket ID from Service Manager. The scenario is that a team, for example the Exchange team, gets an incident in Service Manager; the incident is generated from an alert in Operations Manager. After some thinking they realize that they no longer want to monitor that for that server. They browse to the self-service portal and input the incident ID (ticket ID in Operations Manager), after approval, Orchestrator find the rule or monitor generate that alert and disables it for the machine. The Orchestrator runbook also handle override management pack. The Exchange team could also browse to the Orchestrator console and start the runbook.

Another discussion is if this is a service request of a change request. The current build of Service Manager 2012 allows us to publish service requests direct in the portal, not change requests. Therefor I will use Service Requests in this example.

  1. The first activity, gets Ticket Id and target server name as input. Which Operations Manager management server the runbook is using is controlled by a variable. All activities use the same variable to contact the same management group.
  2. This activity is used to format date and time which is used for the management pack backup folder
  3. Powershell script, loads the Operations Manager module and gets the alert with the ticket ID we input when the runbook was started. The script then checks if the alert is from a rule or a monitor. As we need to use different cmdlets to disable a rule or a monitor we need to know if the source is a rule or a monitor. Next step finds out the orginal management pack, the management pack that stores the alert source. The script checks if there is a suitable override management pack. The override management pack name is “Organisation – orginal name” for example “Contoso – Microsoft Unix Library”. “Contoso” is controlled by a variable. All steps will echo to the logfile, default path is C:\TEMP\logfile.txt
  4. If there is no suitable override management pack this activity creates it, as a XML file in the C:\TEMP folder
  5. Imports the override management pack created in step 4
  6. Overrides the rule or the monitor
  7. If there is a override management pack already step 7 makes a backup of the management pack. The backup of the management pack is stored in C:\TEMP by default. The script will create a folder with the current timestamp and then stores the management pack in it
  8. Overrides the rule or the monitor

An example of this could be that first an alert is generated in Operations Manager and syncronized to Service Manager. Service Manager writes back the incident number to Operations Manager

A SME finds out that this rule or monitor can be disabled for this or a machine. The SME can then navigate to the Orchestrator Console or browse to the Service Manager self-service portal and input the ticket ID and the server for which the monitoring should be disabled

Either way the runbook will be executed and create the override

Summary: Self-service can be target to engineers and SME teams, not only end-users. We use self-service with the Service Manager self-service portal or with the Orchestrator Console to execute tasks that the engineer normally dont have deep skills of or permissions to do. In this example disable a rule or monitor in Operations Manager. We save time both for the engineer and the Operations Manager team. With the Orchestrator console we can use Orchestrator as a “proxy” to carry out complex tasks in a very simple way. With Service Manager we can build a approval flow to make sure every change is approved in a correct way.

If you want to build a runbook that deploys agent to untrusted networks or workgroup machines, where you need certificate based authentication, look at, Deploy OPSMGR agent to untrusted zones with Opalis. Also look at the posts around fault tolerance and logging. If you want to build a runbook to uninstall (and install) the Operations Manager agent, that can be triggered from the Orchestrator console and the Service Manager self-service portal, this is an example

You can download the runbook here, 20111227_DisableRuleMonitor. Please note that this is provided “as is” with no warranties at all.

Discovery Sources in Service Manager 2010

Each configuration object in the Service Manager CMDB has a discovery source, or multiple discovery sources. This list contains all connectors or sources that have updated the object during its lifecycle. For example if we synchronize an active directory user object to the CMDB the AD connector is the first discovery source. If we later update the object with another connector or manually, that connector will be discovery source two for the object. If we update the object manually it is register as SDKDefaultConnector discovery source. When there is no discovery source left, the object will be deleted from the CMDB. In some scenarios you need to find out which discovery objects a object have. In this example I have an account named John Connor. If I use a Active Directory connector to synchronize the account over to the Service Manager CMDB I get the following information in the CMDB.

If I add another AD connector, that also synchronize this John Connor account, I can see in the database that the account now I have discovery sources

If I now delete the first AD connector, field.local, and run the query again, we see that the John Connor accounts now have only one discovery source, the “Accounts OU” Active Directory connector.

If I now delete the second AD connector too, and run the SQL query, I see that the object now is deleted as there is no longer any discovery source. All incidents where John Connor was affected user now have a blank affected user field. If I create a new Active Directory connector, Account OU v2, I can see that the account is back in the CMDB and the new connector is discovery source. For the incident that John had before, the affected user field is still blank. Even if we synchronize the same account into the CMDB, it is not mapped together with the incident again

If I update the user object manually, for example adding the Office attribute, I can see an update in the database from the SDKDefaultConnector

If I now delete the Active Directory connector, the user object will not be deleted, as the manually modification of the object is a discovery source, and Service Manager will not delete an object with discovery sources.

If I modify a user in the Service Manager console, and then delete the modification again, for example let’s say I add department, then I remove it again in the service manager console, the user will still have the
SDKDefaultConnector as discovery source.  The result would be that even if I delete the Active Directory connector, the user will not be deleted as there is a discovery source left for the object. Therefor it could be a good idea to update the object in the data source, in this example in Active Directory.

This is the query I use to get discovery source of a object. Replace John Connor with any displayname

SELECT     DS.ConnectorId, BaseManagedEntity.DisplayName AS [Connector DisplayName], BaseManagedEntity_1.DisplayName AS [Object DisplayName]
FROM         DiscoverySource AS DS INNER JOIN
DiscoverySourceToTypedManagedEntity AS DSME ON DSME.DiscoverySourceId = DS.DiscoverySourceId INNER JOIN
Connector ON DS.DiscoverySourceId = Connector.ConnectorId INNER JOIN
BaseManagedEntity ON Connector.BaseManagedEntityId = BaseManagedEntity.BaseManagedEntityId INNER JOIN
BaseManagedEntity AS BaseManagedEntity_1 ON DSME.TypedManagedEntityId = BaseManagedEntity_1.BaseManagedEntityId
WHERE     (BaseManagedEntity_1.DisplayName = N’John Connor’)