Quantcast
Channel: scsm – marcelzehner.ch
Viewing all articles
Browse latest Browse all 27

Service Manager: Count the number of incident support group changes

$
0
0

A customer of mine recently asked me if it’s possible to easily see (and later also use reports for), how many times an incident was moved between support groups. There are different approaches for this and in this post I will describe a simple solution for that.

Additional information: make sure you also read part 2 –> https://marcelzehner.ch/2014/06/24/create-a-report-for-support-group-changes/

First we extended the incident class with a new “int” property “Support Group Changes” with a default value of “0” (zero). This can either be done in the Authoring Tool or using Visual Studio and VSAE.

image

To increment the counter we created a custom workflow in the Authoring Tool that checks for support group changes. Every time this happens, a PowerShell script will be executed that increments the value of the “Support Group Changes” property.

The workflow uses a trigger and a singe PowerShell script activity.

image

Lets take a look at the trigger first. This workflow should trigger every time a support group will be changed for an incident. So I configured the trigger to watch for objects of the incident class that will get updated.

image

In the advanced criteria section we can configure the criteria to make sure the workflow does not trigger for all incident updates but only for support group changes. The configuration we want cannot be configured in the GUI. So for now we just select some dummy entries.

image
(Changed from)

image
(Changed to)

We will change the criteria to the correct settings afterwards. Now lets first take a look at the PowerShell script activity. First we need the incident ID from the incident that triggered the workflow and pass it to the PowerShell script activity. This configuration will add a “param” section to our script. I used “IRID” as the variable name and passed the incident class property “ID”.

image

image

This is the script we are using. As you can see, the variable IRID can now be used to pass the incident ID.

image

Here is the full script. As you can see, after importing the detault SCSM PowerShell module I get back the incident object, increment the actual value of the property and update the incident afterwards.

try{

$regkey = “HKLM:\SOFTWARE\Microsoft\System Center\2010\Service Manager\Setup”
$ModuleFile = “System.Center.Service.Manager.psd1″
$SMInstallDir = (Get-ItemProperty -Path $regkey).InstallDirectory
$FullModulePath = $SMInstallDir +”PowerShell\” +$ModuleFile

import-module $fullmodulepath -force

$class = Get-SCSMClass -name system.workitem.incident
$incident = Get-SCSMClassInstance -class $class -filter “Id -eq $IRID”
$incident.incidentsupportgroupchanges++
Update-SCSMClassInstance -instance $incident

remove-module system.center.service.manager -force

}

catch{throw}

Done! After saving the MP, we now need to change the criteria for the trigger. Open the MP with an XML editor and search the criteria.

image

Now change the criteria configuration to this.

image

This configuration will check if the support group value is different from “Pre” (before the change) compared to “Post” (after the incident was modified and changed). If this is the case, the workflow will be triggered and the number will be incremented. So after importing the MP and copying the appropriate dll file to the installation directory of Service Manager on the workflow server, the workflow will work and increment the value every time the support group will be changed.

image

Have fun!
Cheers Marcel


Viewing all articles
Browse latest Browse all 27

Trending Articles