This post will discuss our experiences defining and extending the SCSM incident data model and forms used in our SCSM implementation. Our team (MPSD) provides a comprehensive monitoring and management service used by Microsoft.com, TechNet, Windows Update, Windows Intune and Microsoft Security Essentials. Across these teams ~5,000 servers are monitored by SCOM and SCSM.
When planning our move to SCSM, we met with the different support teams to understand their requirements. Since our monitoring and management service is used by several independent teams, we needed to take into account all of the different data model properties needed by the different teams.
To add properties to the System.WorkItem.Incident class we used the authoring tool. I found it very easy to create new properties. By using the Extension=True attribute defined on the extension class declaration we extended the built in Incident class to make the additional properties available to add into an Incident form. When you add a property to the Incident class you will notice a new tab called ‘Extensions’ is automatically added to the Incident form.
If you don't want the extension tab as was our case you can add the following to your management pack.
<Categories>
<Category ID="HideIncidentFormExtensionTab" Target="MPSD_Incident_CustomForm" Value="Admin!Microsoft.EnterpriseManagement.ServiceManager.UI.Administration.Enumeration.HideExtensionTab" />
<Category ID="MPSD_Incident_CustomForm.PopOutFormCategory" Target="MPSD_Incident_CustomForm" Value="SMConsole!Microsoft.EnterpriseManagement.ServiceManager.UI.Console.PopOutForm" />
</Categories>
See this blog post for more details.
To make viewing the new properties easy, I used the authoring tool to add a tab to the incident form. On the new tab I added the appropriate controls (textboxes and user pickers) and bound them to the new properties. The authoring tool creates a new management pack to store these customizations in so they can be easily transported from one SCSM environment to another. When you import the management pack into SCSM the class extensions and incident form customizations are added to the system.
Here are some of the properties we added to incident class and form to help our support engineering teams manage their incidents:
· Engineer 1 – 5 – Used to assign engineers to work on the incident.
· Asset Map - Describes what application is associated to the computer
· SCOM Event ID and Event Source - We look these up in SCOM using a custom workflow when an incident is generated from an event data source monitor alert.
· Asset (Computer) - Used so the incident view can include the computer name because views cannot display columns of data showing properties of objects which are related over relationship types with max cardinality greater than one.
See this blog post for more details.
· KB URL - Contains a link to the KB article support engineers will use to resolve the Incident. A custom workflow looks up the appropriate KB URL when an incident is generated and populates this field automatically.
· Email TO and CC. We extended the Exchange connector to add these properties to enable better round trip email communication about incidents
The event ID, event source and asset are all added to the incident views. This allows our support engineers to quickly sort by these values giving them a quick view of what is happening across many systems.
You are likely wondering where the data comes from to fill out these new properties. The first is a sync service that imports data from a database that contains information on all our applications. This service fills in the contact name and asset map. The other program is called by a SCOM workflow and runs for each new alert-generated incident. That program looks up the Event ID and Event source in SCOM and gets the Email TO and CC information from the Exchange connector for mail incidents.
I will write more about our implementation of these programs in a future blog.