Autoclosing resolved incidents with SMLets and a custom workflow

To automatically close incidents that have been resolved for a number of days is a pretty common request among customers who've been working with Service Manager in production for a while. Even though this can be handled manually, it's much more convenient to automate this process. The thought behind all of this is that when the Analysts change that status of the incident to resolved, the Affected User has a number of days to contact IT before the incident is closed. If the Affected User contacts IT before the incident is closed, the incident gets re-activated, otherwise a new incident has to be opened.

Getting ready

Make sure that SMLets and the Authoring Tool is installed and working properly and that you have read and understood these previous recipes in this chapter:

  • Downloading and installing SMLets
  • Using SMLets to delete a work item
  • Creating a custom workflow in the Authoring Tool - exporting your unsealed management packs

How to do it...

In this recipe, we will be using the SMLets to handle the actual automatic closure of resolved incidents. We will then put the PowerShell script in a custom workflow and schedule it to run once a day-just as we did in the previous recipe.

Tip

Keep in mind that we are creating a script/workflow to modify a large number of incidents and if you mistype something you might end up closing every incident in your system! I strongly suggest that you test this in a lab environment before implementing it into a production environment.

  1. Start the Service Manager Authoring Tool.
  2. Open an existing or create a new Management Pack to store this workflow in.
  3. Create a new workflow by right-clicking on Workflows in the Management Pack Explorer and selecting Create.
  4. Give the workflow a proper name, such as AutocloseResolvedIncidents, and then click on Next.
  5. Make sure that the Run at a scheduled time or at scheduled intervals is selected and click on Next.
  6. Now specify when you want the workflow to run and click on Next.

    Tip

    It might be a good idea to trigger this workflow outside your business hours since doing it during the day might be confusing to your Analysts. What if they actually are trying to re-activate the incident when the script is executed?

  7. In the Summary step, make sure that everything looks okay, and then click on Create, followed by Close.
  8. Now drag the Windows PowerShell Script activity onto the workspace.
  9. With the Windows PowerShell Script activity selected, go to the Details pane and change the name to AutocloseResolvedIncidentsPS. Then go to the Script Body field and click on the ... button.
  10. Click the blue View or Edit Script bar and enter the following code:
          Import-Module SMLets  
      $NumberOfDaysResolved = 7  
      $Now = (Get-Date).ToUniversalTime() 
      $ResolvedDate = $Now.AddDays(-$NumberOfDaysResolved) 
      $IncidentClass = Get-SCSMClass System.WorkItem.Incident$  
      $ResolvedStatusId = (Get-SCSMEnumeration
      IncidentStatusEnum.Resolved$).Id 
 
      $CriteriaType = 
      "Microsoft.EnterpriseManagement.Common.
      EnterpriseManagementObjectCriteria" 
      $CriteriaString = "Status = '$ResolvedStatusId' and ResolvedDate 
     <= '$ResolvedDate'" 
      $Criteria = New-Object $CriteriaType 
      $CriteriaString,$IncidentClass  
 
      $ResolvedIncidents = Get-SCSMObject -Criteria $Criteria 
 
      if ($ResolvedIncidents -ne $null) {  
      $Propertyhash = @{"Status" = "Closed"; 
      "ClosedDate" = $Now;} 
      $ResolvedIncidents | Set-SCSMObject -PropertyHashtable 
      $Propertyhash 
      } 
 
      Remove-Module SMLets

    Tip

    Before proceeding to the next step, you should try this script in a lab environment to make sure it works as planned. If something is mistyped, you might end up modifying every Incident in your system! We will go through each line of code in the How it works... section later on.

    How to do it...

  11. Click on the OK button to close the Configure a Script Activity dialog.
  12. Now Save the management pack and copy the AutocloseResolvedIncidents.dll to the installation folder of Service Manager on the management server. When that is done, import the management pack.
  13. Verify that the workflow is listed under Workflows | Status.

How it works...

The preceding steps are almost the exact same steps as in the previous recipe, what's interesting and new here is the actual script. So let's go through all the code:

Import-Module SMLets
$NumberOfDaysResolved = 7
$Now = (Get-Date).ToUniversalTime()
$ResolvedDate = $Now.AddDays(-$NumberOfDaysResolved)

As with most scripts, we start with importing the SMLets PowerShell module to be able to use all the commands. Then we set a variable to the number of days an incidents should have been resolved in order to be autoclosed. If you want the incidents to stay Resolved for another number of days, this is where you change that. Next we retrieve the current datetime in UTC format and then calculate the actual timestamp to use when looking for matching incidents to close.

$IncidentClass = Get-SCSMClass System.WorkItem.Incident$
$ResolvedStatusId = (Get-SCSMEnumeration  IncidentStatusEnum.Resolved$).Id

Here we use the Get-SCSMClass cmdlets to retrieve the incident class and the other line of code is to retrieve the GUID of the Incident resolved status enumeration. To get the actual enumeration object you can use the Get-SCSMEnumeration cmdlets, but in this case we are only interested in the GUID and that's why we are just getting the ID.

$CriteriaType =  "Microsoft.EnterpriseManagement.Common.EnterpriseManagementObjectCrit eria"
$CriteriaString = "Status = '$ResolvedStatusId' and ResolvedDate <=  '$ResolvedDate'"
$Criteria = New-Object $CriteriaType $CriteriaString,$IncidentClass
$ResolvedIncidents = Get-SCSMObject -Criteria $Criteria

This part of the code is pretty tricky. It is where we retrieve the Incidents with the Get- SCSMObject cmdlet. But instead of using the -Filter parameter, we are using another one called -Criteria. The reason for this is because -Filter can only handle one argument. So we could either retrieve the incidents with status Resolved or get the ones with a resolved date that is less than the one we calculated earlier. If you want to use several arguments when retrieving objects you will have to use the -Criteria parameter. The criteria type should always be Microsoft.EnterpriseManagement.Common. EnterpriseManagementObjectCriteria, but you will have to change the criteria string to fit your needs. See a link to an official blogpost on where to read more about this under See also...

Tip

If you run the code to this point, the  $ResolvedIncidents  variable should contain all the incidents that would autoclose if you ran the complete script. Use this to verify that your code is retrieving the incidents you expect it retrieve. 

if ($ResolvedIncidents -ne $null) { 
    $Propertyhash = @{"Status" = "Closed";
                      "ClosedDate" = $Now;}
    $ResolvedIncidents | Set-SCSMObject -PropertyHashtable $Propertyhash
}
Remove-Module SMLets

The final part of the script will check if the $ResolvedIncidents variable contains any objects. If it does it will change the status of these to Closed and set the Closed Date. Finally, we unload the SMLets module from the PowerShell session.

See also

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset