Problem with AD user SID and DisplayName

Roman_Nepomniashchii

Hey, friends,

We have very often case when our female employee changes her last name after marriage.

So we do next things in our system: 

Step 1. I created a user in my AD, when AD connector syncs, this user appears in SCSM.

Step2. When later I change display name and login of this user in AD and AD connector syncs with SCSM, another user appears with the same SID but different display name, and both users have status active. But valid user is only one that have last modified DisplayName. 

Question is:

What do we need to do if we want only one active user stays in the system (who appears last in the system).

Shane_White

Hi @Roman_Nepomniashchii

What version of the Portal are you running as there was a bug that sounds similar to the same behaviour you are getting?

Also, have you tried truncating the CI$User Table and LastModified Table in Service Management to let them rebuild (best to do this out of hours)

One last thing you can check in the SCSM Console is if there are any users sat inside Administration > Deleted Items and if there are then remove them.

Thanks,
Shane.

Roman_Nepomniashchii

Shane_White said:

Hi @Roman_Nepomniashchii

What version of the Portal are you running as there was a bug that sounds similar to the same behaviour you are getting?

Also, have you tried truncating the CI$User Table and LastModified Table in Service Management to let them rebuild (best to do this out of hours)

One last thing you can check in the SCSM Console is if there are any users sat inside Administration > Deleted Items and if there are then remove them.

Thanks,
Shane.

Current Portal Version: 8.2.0.2016

Management Pack Version: 7.7.2016.185

Re-sync not help((((
In Deleted Items "No items found" but I see deleted item through PowerShell

Main problem - I have SID and I have many DisplayName on this SID((((((( in DB ServiceManagement

Shane_White

Hi @Roman_Nepomniashchii

Did run the following in SQL against the Service Management DB:
TRUNCATE TABLE Dbo.CI$User
TRUNCATE TABLE LastModified

If you can see these users in PowerShell then I would recommend removing all duplicate users from your System either through Console and/or PowerShell.

Thanks,
Shane.

Tom_Hendricks

@Roman_Nepomniashchii I do not think this is an issue with the portal, it is with SCSM.  @Shane_White is on the right track, recommending that you remove duplicate users, but this may not be as simple as we would all hope.

Changing the name (LastName/sn field in AD) is fine, the new name should just sync over without any problems.  But changing the login/UserName is not something SCSM likes or handles very well (no idea if 2019 handles this better with its new connector or not). IMO, you really just shouldn't do it.

You may not have a choice for customer service reasons, but for this and other systems it is better to never change the UserName and if you must give them a new one, disable this account and provide them with a new one.

Assuming that first/last names must be part of the login and you therefore must change it, here is how to fix that account, at a high level.  I can provide more detail if this proves to be your situation.  I would not call the fix simple, and parts of it may not even be supported by MS.

1. Verify the issue: Using either PowerShell or SQL (or the console if you hate yourself ), search for objects of class System.Domain.User with a displayname that contains the new login name for the account.  If one such user object, with nearly no other properties except UserName and Domain populated, has been created, you do have this issue.
2.  Create a temporary user object with a name you will remember (using the console is fine for this).  Using PowerShell (nothing else recommended...) copy all the object relationships from the user object that still has the "old" login name to this new temp user.  Here is a great tutorial on that.
3. Delete the account with the "old" login name, then remove it from deleted items (using either console or PowerShell)
4. Using SQL, check to see if the correct user info is already staged.  Select * FROM ServiceManager.LFXSTG.AD_User WHERE UserName = 'theNewLoginName'.  If found, this is the part that is probably not supported by Microsoft:  You need to update that record so that the Lfx_Timestamp column is later than your next AD connector run in the future.  I recommend taking the scheduled time of the next run and adding 15 minutes to the time/date.  If you do not do this, the record will just sit there forever.
5. AFTER the next AD sync, you should see the account pulled in correctly now.  You can follow the same tutorial from step #2 to move all the object relationships back from the temporary user onto this new account, then delete the temporary user.
   

Nick_Flint

When I have User records like @Tom_Hendricks describes (only data is username and domain), I create a new AD connector and sync it up. Then I delete the old AD Connector. 

Deleting the old AD Connector causes any objects imported by it to be deleted. By creating and syncing the new AD connector first, you ensure that your current valid AD Users are not deleted by SCSM because they were also imported by the new AD Connector.

Tom_Hendricks

This sounds like a pretty good approach as well, @Nick_Flint.  Does it keep the object relationships with the "old" ID and apply them to the new one?  Assuming that it would not is why I have not used this approach instead of the one I listed above.  It would certainly be simpler!

Nick_Flint

I've actually never checked; but your assumption sounds reasonable to me. If this is associated with an AD account change, I haven't made the connection before. I'll pay more attention next time :-)

Tom_Vanden

For what it's worth, I combined both of your suggestions and corrected this very issue today. For some reason, when we do an AD name change the original user account in Service Manager gets booted to the "Deleted Items" folder under Administration, and the name-changed account shows up with just the UserName and Domain info populated as described above.

Here are the steps I took to fix this PITA situation:

1) Create Dummy Account in SM Console.

2) Ran the referenced Script to move incident relationships from the Original User account to the Dummy Account.

3) Deleted the Original and Name Changed Accounts from the SM Console (Found in Deleted Items under Admin, and Users under Configuration Items)

4) Created new AD Connector to Holland Users group and ran it.

5) Verified that the Name Changed account was been properly synced.

6) Delete or Disable old AD Connector.

7) Re-ran referenced Script to move relationships from Dummy Account to Name Changed account and verify they are showing up.

8) Deleted the Dummy Account.