We recommend you first move end-user workstations to the target domain after they have been processed and then move the servers.
Move End-user Workstations to the Target Domain
This step is called the user switch. We recommend you move user workstations using Resource Updating Manager. In this case, after a computer is moved to the target domain, the default logon domain name that is displayed in Windows logon dialog is changed to the target domain name. This helps a user log on to the target domain and start working with his or her target account without having to select the target domain manually in the Windows logon dialog.
Caution: You should always make sure that user profiles have been processed before you move their workstations to the target domain. If you selected the Change last logged-in domain to the target domain option when moving computer accounts, the default logon name will be changed to the target domain name on each computer that has been moved. If user names were not changed during the migration, most probably users will not notice the change and will log on to the target domain. If their profiles have not been updated yet, they will get new profiles.
NOTE: The ChangeProfile utility from the Migration Manager Resource Kit associates the profile of users currently being migrated with their previous (source) accounts. It can help to link a target user account to the old profile. Refer to the Quest Migration Manager for Active Directory Resource Kit - User Guide for more details.
Laptop Users and Cached Credentials
Many users now work with portable laptop computers. When such users are in the office, they plug their computers into the local area network (LAN) and log on to the domain using their credentials. These credentials are then automatically cached by the system on the laptop computer. These users may also often work out of the office, not connected to the LAN. In these cases they log on to the system with the same username, password, and domain name as they used in the office. The system authenticates the user using the credentials that were cached.
However, if you move a computer to another domain and then reboot it, all cached credentials are automatically cleared by the system on that computer after reboot. Thus, a user is no longer able to log on using the cached credentials. The system behaves as follows:
However, if the cached credentials have already been cleaned and the user is at home, the or she can still log on to the target domain by selecting the Log on using dial-up connection option in the Windows logon dialog and connecting to LAN via dial-up.
When a workstation is moved to another domain, the list of trusted domains (the domains trusted by the domain to which this workstation belongs) that is stored in system registry is automatically cleared by the system.
An issue may occur if a user workstation was locked when it was moved to the target domain and if the user tries to unlock it right after it is moved, without waiting for the domain list to be rebuilt. In this case, when pressing Alt-Ctrl-Del, the user will only be able to choose from the local workstation and the target domain to log on. To resolve this, the user should press Esc and then press Alt-Ctrl-Del again; the trusted domain list is rebuilt and the last logged-in domain (the default domain) setting is returned to the source domain. The user is then able to unlock the workstation.
Move Servers to the Target Domain
Next, move file and print servers and servers running scheduled tasks using Resource Updating Manager.
For procedures for moving servers running IIS and other applications and services, refer to the product’s documentation. Be sure to test these procedures first in your test environment.
Moving Cluster Servers
To move a cluster server whose nodes are all member servers of some domain to a different domain, select all the nodes in Resource Updating Manager and move them simultaneously. After a couple of minutes all nodes and the virtual cluster server will appear in the new domain.
CAUTION: Always move all cluster nodes to the new domain simultaneously.
Do not move a virtual cluster server to the new domain.
NOTE: The Cluster service account is not changed when moving a cluster server to another domain.
Microsoft BackOffice includes SQL, Exchange, and SMS server products. To update BackOffice server permissions for the target accounts, use the following processing wizards:
|Exchange Server||Exchange Processing Wizard||Updates client and administrative permissions on mailboxes, public folders, and all other Exchange objects.|
|SQL Servers||SQL Processing Wizard||Automatically detects the SQL Server version and performs the updates accordingly.|
|SMS/SCCM||SMS Processing Wizard||Updates Microsoft Systems Management Server and Microsoft System Center Configuration Manager permissions to reflect the migration.|
NOTE: For details on supported backoffice server versions, refer to Processed Platforms section of the System Requirements and Access Rights document.
For more information about the processing wizards listed above, refer to the Quest Migration Manager for Active Directory Resource Processing Guide.
Centralized BackOffice Server Updating
To update BackOffice servers from a central location, in Migration Manager select Resource Processing from the Tools menu and select the appropriate wizard.
Delegated BackOffice Server Updating
The best practice for delegating BackOffice server update is to create a resource processing task and delegate it to the other administrators. In addition, you can create a setup package for the task and send it to the administrator, who installs the package and runs the task at his or her location. For more information on these techniques, refer to the Step 3. Process Distributed Resources topic.
Alternatively, you can update BackOffice servers using INI files.
Microsoft BackOffice includes SQL, Exchange, and SMS server products. The recommendations for them are different, and are explained in the sections below.
SQL servers can be moved to the target domain easily after they have been processed. You can do this manually or from Resource Updating Manager.
Exchange 5.5 Servers
Instead of moving Exchange 5.5 servers to the target environment, we recommend using Quest Exchange Migration Wizard to migrate Exchange 5.5 to Exchange. For more details on Exchange migration scenarios, refer to the Quest Exchange Migration Wizard—User’s Guide.
Use Migration Manager for Exchange to migrate messaging system from the source Exchange organization to the target. After the inter-org Exchange migration is completed, you can decommission the old Exchange environment.
Due to SMS implementation complexity, we recommend you re-deploy SMS in the target environment instead of moving the SMS servers.
If you do choose to move your BackOffice servers to another domain, refer to the procedures described in the Microsoft BackOffice documentation and in the Microsoft Knowledge Base for more information.
If you established directory synchronization in step 1, stop and uninstall the Directory Synchronization Agents.