Chat now with support
Chat with Support

Reference Materials for Migration 8.15 - Tips and Tricks

Introduction Environment Assessment, Planning, and Testing Basic Migration Steps Considerations for Active Directory Migration and Resource Update Considerations for Exchange Migration Preferred Settings for the Directory Synchronization Agent Directory Synchronization Agent Placement Indexing Service Attributes Full Directory Resynchronization Conclusion Environment Preparation Checklist Exchange Migration without Trusts Active Directory Migration without Trusts

Step 4. Move End-user Workstations and Servers to the Target Domain

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:

  • Until the computer is rebooted (after the move), a user can use cached credentials to log on to the source domain.
  • Once the computer is moved and rebooted, attempts to log on using cached credentials will be unsuccessful.
  • Accordingly, we advise doing either of the following:
  • Reboot laptop computers while the user is in the office, connected to LAN. Then he or she can log on to the target domain, and the new credentials will be cached.
  • Hibernate laptop computers rather then switch them off before taking them home. At home the users can restore the laptop from hibernation and successfully log on to the domain using cached credentials. The next day at work, the laptop users can plug the machine in the network and reboot. Once they are logged on to the target domain, their new credentials are cached and can be used offline.

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.

Locked Workstations

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.

Step 5. Process BackOffice Servers

Microsoft BackOffice includes SQL, Exchange, and SMS server products. To update BackOffice server permissions for the target accounts, use the following processing wizards:

BackOffice Server Wizard Description
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.

Step 6. Move BackOffice Servers to the Target Domain

Microsoft BackOffice includes SQL, Exchange, and SMS server products. The recommendations for them are different, and are explained in the sections below.

SQL Servers

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.

Exchange Servers

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.

SMS Servers

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.

Step 7. Stop Directory Synchronization (Optional)

If you established directory synchronization in step 1, stop and uninstall the Directory Synchronization Agents.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating