Managing Username Changes in Service Manager

From time to time people reach out to me to assist them with a name change due to marriage or other changes in circumstance and the affect that this has to System Center Service Manager (SCSM) and the Cireson portal.

Change of name in AD is a pain for SCSM as it retains the SID for the username and so long as that does not change it seems not to want to change any associated details.

Quite some time ago Rob Davies wrote a TechNet article on this topic explaining how to deal with this issue. You can get to the original article here: https://blogs.technet.microsoft.com/manageabilityguys/2013/06/17/managing-username-changes-in-service-manager/
Or I have made a similar copy of it here below to ensure it does not get lost in the wide world.

When someone in your organisation changes their name one of first things we do in IT is to change their details in AD.

In this example I’m going to assume the usernames are in the format of <Firstname><First Initial of last name>. (My username would be BrettM) This will mean that when their name gets changed in AD their username will also be changed to match.

In the example that I am going to use Chris McGurk would have a user name in the Service Manager CMDB, as an AD User:

Opening up the user CI form within the SCSM console, we can see the users details, which were pulled from the Active Directory Connector, including the username, which is read-only.

Most importantly, we can see the relationships the user object has – relationships to work items like Incidents or Service Requests. We’ve also got relationships to Configuration items the user owns.

When the person changes their name IT Support would go in to AD Users and Computers and change their last name and username:

After the Active Directory Connector runs within Service Manager, there will be two objects in the CMDB for this user, one with their old name and another with their new name.

Why do we have two objects in Service Manager?
They’re still the same single object, with the same SID in Active Directory but they are two different configuration items in SCSM.
This is because the user object in Service Manager has a key attribute of Domain + Username. Therefore, if the AD Username changes, we’re going to have a different key and as a result, be a different Service Manager object. This is because user objects may be created from other sources, aside from AD.

Opening the new user CI within Service Manager, the new user does not have any of the relationships to work items as they are still associated to the old user CI object.

This can also cause some confusing if you’re searching for the user to add them on a new Incident and both users will appear in the affected user list.

The goal is to remove the ‘old’ user object for, so we use the new name from this point on. However, if the old user object is simply deleted from Service Manager, all the relationship information will be lost. This is a bad thing because if there are open work items, where the old user object is the affected user, the work item will lose the association to the user.

What we want to do is to move the relationships from the older user object to the new one, then delete the old object.

There are a number of ways of doing this:

• Manually through the console
• Orchestrator
• SDK
• PowerShell
• etc.

Personally, I like the PowerShell solution. This can be triggered manually when somebody changes their username, or, even better, add this step to a “Change Username” request offering that automates the process via the user Self-Service portal. This PowerShell code can then be added as an Orchestrator Runbook Activity, or a Cireson PowerShell Activity in the workflow of the Service Request to ensure the correct process is followed.

In the below example (Lifted from the TechNet article by Rob Davies), the PowerShell script will delete relationships from one user, and recreate them on the new one.

The following relationship types are ‘copied’:

• Affected User
• Incident Closed by
• Work Item created by
• Work Item assigned to
• Work Item resolved
• Configuration Item Owned by

If there are additional relationships the you want to add, or remove, you can easily edit the example script. The script below was intended to cover the most common relationships, which you see on the ‘Related Items’ tab. After running the script successfully, you’ll see the new user with the same related items as the old one.

The PowerShell script example is pasted below or downloadable from the original blog article on TechNet. You can simply run it, supplying the AD Usernames of the users to alter:

• oldADUser is the old username you want to copy the relationships from
• newADUser is the username where the relationships will be copied to

For example:

.\Move-Relationships.ps1 –oldADUser "Chris.McGurk" –newADUser "Chris.Philips"

After copying across these successfully, the old user can be deleted and the Cireson Cache Builder service either manually restarted to accelerate the sync process or wait until the Cireson Cache Builder detects the change and does the sync automatically.

[CmdletBinding()]
Param(
  [Parameter(Mandatory=$True,Position=1)]
   [string]$oldADUser,
 
   [Parameter(Mandatory=$True)]
   [string]$newADUser
)

if (!(Get-module System.Center.Service.Manager))
{
 #TODO: You may need to alter the location of the PowerShell Module:
 import-module 'C:\Program Files\Microsoft System Center 2012\Service Manager\PowerShell\System.Center.Service.Manager.psd1';
}

#Get the old and new user objects from the CMDB
$oldName = Get-SCClassInstance -Class (Get-SCClass -Name "System.Domain.User") -Filter "UserName -eq $oldADUser";
$newName = Get-SCClassInstance -Class (Get-SCClass -Name "System.Domain.User") -Filter "UserName -eq $newADUser";

#Get relationships targeted at the old user object
$relatedItems = Get-SCRelationshipInstance -TargetInstance $oldName;

foreach ($item in $relatedItems)
{
 #Figure out the type of each of those relationships & check against the list
 $relType = Get-SCRelationship -Id ($item.RelationshipId);
 if ($relType.Name -eq "System.WorkItem.TroubleTicketClosedByUser" -or
  $relType.Name -eq "System.WorkItemAffectedUser" -or
  $relType.Name -eq "System.WorkItemCreatedByUser" -or
  $relType.Name -eq "System.WorkItemAssignedToUser" -or
  $relType.Name -eq "System.WorkItem.TroubleTicketResolvedByUser" -or
  $relType.Name -eq "System.ConfigItemOwnedByUser")
 {
  #delete the old relationships & recreate them with the new user object
  Remove-SCSMRelationshipInstance -Instance $item;
  New-SCRelationshipInstance -RelationshipClass (Get-SCRelationship -Name $relType.Name) -Source $item.SourceObject -Target $newName;
 }
}