Problem with AD user SID and DisplayName

Roman_NepomniashchiiRoman_Nepomniashchii Customer IT Monkey ✭
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).

Answers

  • Shane_WhiteShane_White Cireson Support Advanced IT Monkey ✭✭✭
    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_NepomniashchiiRoman_Nepomniashchii Customer IT Monkey ✭
    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_WhiteShane_White Cireson Support Advanced IT Monkey ✭✭✭
    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_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    @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_FlintNick_Flint Customer Advanced IT Monkey ✭✭✭
    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_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    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_FlintNick_Flint Customer Advanced IT Monkey ✭✭✭
    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 :-)
Sign In or Register to comment.