Orchestrator Runbook to reassign SCSM Incidents

I was working at a customer that was doing a domain migration. Service Manager was installed in the new domain, but up til now the analysts and users have used their old accounts. The task was to create a runbook, that reassinged all Incidents from the old user account to the new account.

It was a fairly new installation and there was less than 5.000 incidents to go through. So I decided to use Orhcestrator to be able to run the job, whenever new users were domain migrated.

I created the following runbook:

First part in the runbook was a Read line activity, to parse a file that contained the newest batch of migrated users. The file had a format of Username,Old_Domain.

Second part in the runbook found the relevant user in the CMDB, based on the input from the Read Line activity. In order to read the username  and domain, I used the following filters:

[Field('{Line text from "Read Line" }',',',1)]

[Field('{Line text from "Read Line" }',',',2)]

Third part in the runbook was a powershell script, this runs the SMLets locally on the Orchestrator Server and and returns a list of incidents, where the user is the Affected User.
Note: To get SMLets to run remotely I normally follow these guidelines: https://datacenterautomation.at/?p=233

Import-module smlets

$computername = "SCSM Management Server"

$incident = Get-SCSMIncident -ComputerName $computername | Where-Object {$_.AffectedUser -like '{Display Name from "Get Old User details" }*'}

if ($incident -ne $Null)

{

    $Incidentlist = @()

    foreach ($ir in $Incident)

        {

            $IncidentList += $ir.ID.value.tostring()

        }

}

The powershell script returned a variable named 'IncidentList' with the related incidents.

It's not best practise using the Where-Object function, but my limited powershell skills on how to do a filter instead, forced me to use the where-object. Luckily the environment didn't contain that many objects and I belive, it didn't affect performance in general.

Fourth part in the runbook, used in output from the powershell script to load all the incidents

Fifth part in the runbook, loads the newly migrated user account. I knew the username was the same as the source account and also the name of the new domain. So I read the username from the input file and hardcoded the domain name.

Last and final part of the runbook change the Assigned to user with the newly migrated User object for all the Incidents that was previuosly returned.

I also created a similar runbook that changed the Affected User, which only requires a few changes in the powershell script and the last activity.

Get-SCSMIncident -ComputerName $SCSMServer | Where-Object {$_.AffectedUser -like '{Display Name from "Get Old User details" }*'}