4 Replies Latest reply on Oct 13, 2016 4:04 AM by AlasdairRobertson

    Updating employee loginid and primary email at the same time

    nino Rookie

      We have been supporting another company that has usernames and emails outside of my company's standard. Recently we have purchased the company that we were supporting and they are looking to change their email addresses and usernames(loginid) at the same time. The LDAP servers will be changing as well so we will be able to stop the old ldap import but where the users are getting migrated to will be on the active LDAP import so we can only stop that for a short period of time.

       

      Has anyone done a migration like this. If so, any best practices.

        • 1. Re: Updating employee loginid and primary email at the same time
          florian1 Expert

          Hi Nino,

           

          first of all: You should store the LDAP objectGUID for each user. Use this attribute as the unique identifier for your LDAP import instead of "samaccountname" or "mail" (and check the "overwrite login" option).

          Otherwise you will always run into issues every time when someone changes his/her LoginID (e.g. after marriage).

          There are some additional steps needed to get WIS working again after a name change but this is way less administrative effort.

           

          I would then do it in the following way:

          Note: I assume that the affected accounts currently do not reside in your Active Directory.

          I do not recommend to import all the new users and remap the old Incidents, MyItems etc. since this isn't really "clean" (the users are still the same!).

           

          In my example, my LoginId changes from "flo.deutsch" to "f.deutsch":

           

          1) stop & disable all your current ldap import jobs

          2) create/migrate the former external company's users in your Active Directory

          3) Get a mapping list of all the affected accounts in this format:

          samAccountName_OldsamAccountName_NewobjectGUID

            a) Export all the current users' loginid to be migrated into column 1 (samAccountName_Old)

            b) Export all migrated/created accounts and map them with their old accounts (fill column 2, 3)

          -> Your mapping list should now have data like this:

          samAccountName_OldsamAccountName_NewobjectGUID
          flo.deutschf.deutsch123456789abcdef012340123456789a

          4) Update all the Employees via CSV/XML:

          Source Unique Key: samAccountName_Old

          Target Business Object: Employee

           

          Mappings:

          objectGUID => XTN_objectGUID (your guid field in HEAT! - char(32))

          samAccountName_Old => LoginId

           

          5) Since you are on prem, you could simply update all the existing Incidents/Service Requests / Changes etc. as needed with SQL.

          But best practice (because of auditing) should be the following:

           

          a) Create saved searches to find active Incidents (and other objects) with the old email:

          - show all Incidents where PrimaryEmail != ContractEmail ($([Frs_CompositeContract_Contact#.IncidentAssociatedCustomer]PrimaryEmail)) and Status != 'Closed'

          - show all ServiceReq

          - [...]

           

          b) Create a quickAction in each object:

          Incident: Email =

          $([OtherObject]PrimaryEmail)
          
          

          ServiceReq:

          [...]

           

          c) Create a workflow with Run for Search (and each QuickActions):

          - Run For Search Incident

          - Run For Search ServiceReq

          - [...]

           

          __

          The SQL way (snippet):

          -- Update existing Incident Customer Email
          UPDATE Incident
          SET Email = e.PrimaryEmail
          FROM Incident i
          JOIN Employee e ON i.ProfileLink_RecID = e.RecId
          WHERE e.PrimaryEmail != i.Email
          AND i.Status != 'Closed'
          
          

           

          6) Get the objectguid for all existing users once (otherwise you will receive duplicate key errors when trying to import using the objectGUID as identifier)

           

          7) Enable & Run the LDAP sync once. Filter by distinguidshedName and only import 1 user to see the results more quickly.

          The users' LoginId and email address should be updated.

           

           

          Cheers,

          Florian

          1 of 1 people found this helpful
          • 2. Re: Updating employee loginid and primary email at the same time
            florian1 Expert

            You will migrate all users at once, right?

            If not, this will be more tricky.

             

            Just a thought:

            If you have a free (temporary) AD attribute (e.g. extensionAttribute1) in your target site, mark these accounts as "to be migrated" and exclude them with an LDAP filter.

            Clear the attribute once this account is migrated (=objectGUID is present in HEAT).

            • 3. Re: Updating employee loginid and primary email at the same time
              nino Rookie

              Thank you. It will be conducted in stages so that information if extremely helpful.

              • 4. Re: Updating employee loginid and primary email at the same time
                AlasdairRobertson ITSMMVPGroup

                If you are changing the LoginId of an employee beware, this value is used in lots in lots of objects for example on Incident: CreatedBy, Owner, ClosedBy, LastModBy, ResolvedBy.

                 

                In addition to Florian's comments, you need to create an OldLoginId field copy the logins over before you migrate your domain.  the once you have completed the LDAP resync then run a script to change all the login data over so your analysts don't loose their tickets e.g. My Active Incidents, My Open Task etc.

                 

                Again the update can be done within HEAT using Quick Actions or just run a script and backup your DB first.

                 

                Copy loginId's to a new field

                --Update Employee Record with PreviousLogin ID prior to LDAP Sync
                
                
                Update Employee
                Set AC_PreviousLoginID = LoginID
                
                

                 

                Post update to reset LoginId's

                --Incident Update
                Update Incident Set CreatedBy = Employee.LoginId from Employee Inner Join Incident on Employee.AC_PreviousLoginID = Incident.CreatedBy
                Update Incident Set ClosedBy = Employee.LoginId from Employee Inner Join Incident on Employee.AC_PreviousLoginID = Incident.ClosedBy
                Update Incident Set LastModBy = Employee.LoginId from Employee Inner Join Incident on Employee.AC_PreviousLoginID = Incident.LastModBy
                Update Incident Set [Owner] = Employee.LoginId from Employee Inner Join Incident on Employee.AC_PreviousLoginID = Incident.[Owner]
                Update Incident Set ResolvedBy = Employee.LoginId from Employee Inner Join Incident on Employee.AC_PreviousLoginID = Incident.ResolvedBy
                Update Incident Set LoginId = Employee.LoginId from Employee Inner Join Incident on Employee.AC_PreviousLoginID = Incident.LoginId
                
                

                 

                The above example is for Incident this apply to all the core business objects and and custom objects using these types of field.

                 

                I have discussed this with support and ask for a RM to be raised currently there does not appear to be a way of dealing with this.

                 

                This is a big job so put some time aside to manage it properly, run it in staging first to ensure all the elements work and then get some users to test as well.

                2 of 2 people found this helpful