1 of 1 people found this helpful
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_Old samAccountName_New objectGUID
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_Old samAccountName_New objectGUID flo.deutsch f.deutsch 123456789abcdef012340123456789a
4) Update all the Employees via CSV/XML:
Source Unique Key: samAccountName_Old
Target Business Object: Employee
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 =
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.
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).
Thank you. It will be conducted in stages so that information if extremely helpful.
2 of 2 people found this helpful
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.