Home » System Center Service Manager » Incident Management in System Center Service Manager

Contoso.se

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
MVP awarded 2007,2008,2009,2010

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

Incident Management in System Center Service Manager

I have been testing Incident Management (IM) with focus on the notification part of IM in System Center Service Manager beta 1.

The main goal of the IM process is to get back to a normal service operation as quickly as possible and to minimize the impact on the business, in other words ensuring that the best possible levels of service quality and availability are maintained. “Normal service operation” is defined within Service Level Agreement (SLA).

 In my test environment I built the following workflow:

Incident templates can be utilized to achieve IM flexibility. Incident templates include common settings for different types of incidents. For example when a service desk receives a call from a user who can´t access a network folder, the service desk operator can then apply the network issue incident template and make sure all the necessary information is collected from the user reporting the incident. The templates also guarantee that incidents are configured with correct owner, category, priority and other related items.

System Center Service Manager has a connector to System Center Configuration Manager that synchronizes hardware information and other relevant information to Service Manager. When a service desk creates an incident and selects which machine the affected user is working from, the service desk can see all information synchronized from Configuration Manager.

In Service Manager there are a number of workflows out of the box and you can also create your own. One of them is Incident Change.

In my test environment I built the following four workflows:

1. One workflow sends e-mail to the affected user when new incidents are created. It is always good for the user to have the incident ID and to know which service desk has begun working on the incident.

2. One workflow sends an e-mail notification to the operator who is configured as “assigned to” in the incident. If it is not the same operator creating the incident who will be working on it, it is good to send a notification.

3. One workflow sends an e-mail notification to the operator who is configured as “assigned to” in the incident. If another operator adds a comment or information to the incident a notification will be sent to the operator who is assigned to the incident.

4. One workflow sends an e-mail notification to both the affected user and the operator who is configured as “assigned to” in the incident.

Service Manager synchronizes information from Active Directory through an AD connector so e-mail addresses and other account information already exists in Service Manager. Here we don’t have to create recipients the same way as we do with subscribers in Operations Manager.

It is reasonably easy to configure incident templates and notifications based on them. There are a couple of scenarios where I could see a need of more detailed criteria parameters. But as this is Service Manager beta 1 I guess we will see a lot more features in the RTM version. I think that the biggest obstacle will not be to how to configure Service Manager but instead how to plan and design all your workflows before you can input them into Service Manager.


1 Comment

  1. […] It is reasonably easy to configure incident templates and notifications based on them. There are a couple of scenarios where I could see a need of more detailed criteria parameters. But as this is Service Manager beta 1 I guess we will see a lot more features in the RTM version. I think that the biggest obstacle will not be to how to configure Service Manager but instead how to plan and design all your workflows before you can input them into Service Manager. View article… […]

Comments are closed.