Thomas Ellermanns view on System Center

This blog will discuss features, functions and views on Operations Manager and Service Manager

Orchestrator Runbook to reassign SCSM Incidents

Orchestrator Runbook to reassign SCSM Incidents

  • Comments 2
  • Likes

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: http://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"}*'}

 

 

Comments
  • Hi Thomas,

    Great guide, thanks a lot.

    I'm using some of your guide (set assigned to user) for a different purpose, and have run into a problem.

    I'm getting a "Resolved by User"-relationship, then Get Object of that GUID, and setting this to Assigned to User, but I get this error when that event is executed:

    [d085cf0d-2ce6-93b5-fd5a-7e66ebb5ddba] is not an instance of class [Microsoft.AD.UserBase].

    Do you have any idea why? Thanks.

  • Okay, I figured out that I need to "Get Related Object Guid" from the relationship, and now I don't get the error anymore.

    But, the "Assigned to" field in the incident does not update, even though the event runs successfully. It just remains blank.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment