Migrating users and computers from one Microsoft domain to another (and from one Exchange mail server to another) is a complex series of actions consisting of preparations and testing, moving objects, and standardization and cleanup. There are several tools that can be used for migrations, such as: Microsoft?s Active Directory Migration Tool (ADMT) 3.0, NetIQ?s Domain Migration Administrator (DMA), and Quest?s Migration Suite.
Identify inactive users and computers. Getting an accurate count of users, computers, and mailboxes will allow the team to better plan the migration. Identifying and removing inactive user and computer accounts makes migrating easier. Computers should be remotely verified a number of times before the migration. This will ensure technicians aren?t troubleshooting a problem that stems from computers not really existing on the network.
Install equipment, new versus temporary servers. A decision needs to be made early on whether to use new or temporary servers. New servers will cost more and things like power, rack space, and connectivity need to be considered. Using existing servers may be preferred but quantity, warranty, and standardization need to be considered as well. If there are not enough existing servers to perform a full migration one might consider using temporary server resources while waiting for new servers to be purchased. In the short-term it may be cheaper to migrate using temporary servers. Please note: it will cause the customers and technicians more work in the long run when they migrate off the temporary servers.
Stable physical connectivity between the old and new domain controllers/mail servers is necessary. This cannot be over emphasized. Ensure the network infrastructure is operating correctly before starting a migration.
Logical connectivity needs to be considered (IPSEC/DNS/WINS/LMHOST/Trusts) when setting up Active Directory and Exchange. Setting up the new domain (if in an existing forest) requires connectivity back to the forest.
DNS/WINS and LMHOST provide the logical connectivity between the domains. After logical connectivity is created a trust can be established to allow permissions and privileges to be shared between the domains. It is common to establish a temporary two-way trust between the domains to facilitate the migration. After the migration the two-way trust can be broken and re-established as a one-way trust. The old domain will trust the migrated users of the new domain to use its resources.
SIDHistory should be enabled if resources in the old domain will still need to be accessed by users in the new domain. SIDHistory will enable users to access their old resources without immediately requiring all the permissions to be changed.
Migrating Exchange 5.5 to Exchange 2003 considerations. The new Exchange 2003 server can be joined to the old Exchange 5.5 site to allow native mailbox moves. To join them the old Exchange server must replicate with the established Exchange topology. This requires breaking and reconnecting GAL replication. The GAL will drop out and be repopulated. After Directory Replication is established the Site Replication Service (SRS) will populated its database. An Active Directory Connector should also be created. An ADC links Exchange 5.5 to the new Active Directory domain controllers. ADC will replicate distribution lists and create users for mailboxes that don?t match up with already migrated users. Exchange 5.5 uses its own database and can be inconsistent with the NT or AD domain.
Migrating Exchange 2003 to Exchange 2003 considerations. An Exchange 2003 server in one AD forest cannot be joined to an Exchange 2003 site in a different forest. Mailboxes will be migrated from the old E2K3 server to the new E2K3 server. The free Microsoft tool to perform the migration only moves the mailbox contents. It does not move permissions (shared calendar), rules (out of office), etc? During the move all mail flow must be stopped at the boundary (or SMTP relays) to prevent messages from bouncing back to the sender. After the migration is complete the DNS MX records should be updated to reference the new E2K3 server.
Misc Server Setup. Before objects are migrated other servers need to be setup. System Management Server (SMS) needs to be installed for patching and reporting. Symantec Anti-Virus Server (SAV) needs to be installed for virus prevention. Directory Resource Administrator (DRA) or Active Roles Server (ARS) needs to be installed for user/computer administration.
Same Domain NetBIOS Name. When building the new domain controllers the same NetBIOS domain name as the old domain cannot be used. A trust cannot be properly established between the domains with the same name.
Exchange setup ? Account Invalid. When joining an E2K3 server to the E5.5 site an ?Account Invalid? error can frequently occur during setup. Microsoft recommends checking the DNS/WINS/LMHOST configurations and re-establishing the trust. Another alternative is to use an account in the new domain to run the E5.5 services in the old domain.
Equipment should be deployed ahead of time to allow server preparation and migration testing. Domain configuration can take up to 10-20 days. Exchange setup (which relies on domain prep) may take another 10-20 days. Another week should be allocated for testing and documentation. Proper timing will allow the objects to migrate from old to new servers with minimal impact on the customer.
Copying user and group objects. Migrating user and group objects from old to new domains is relatively easy and painless. It can be done early in the process as it doesn?t immediately affect the users in the old domain.
CAC Login & Passwords. Migrating the CAC login and passwords between old and new domains is not too difficult. Migrating passwords between domains requires setting up a Password Export Service (PES) in the old domain. Ample testing should be performed to ensure PES is functioning before mass migrating user accounts, if the old passwords are needed.
Migrating computers/servers. Being able to remotely connect to the computer or workstation via a Remote Procedure Call (RPC) is critical in migrating. Things that can stop a RPC connection: the Windows Firewall, local Administrator permissions, incorrect computer name to IP mapping (DNS/WINS), incorrectly applied file/share permissions. Most migration tools will be able to remotely join a computer/server to the new domain. Most migration tools come with pre-check software to verify the computers are prepared. The pre-check software can verify permissions, connectivity, drive space, etc?
The process of migrating a computer to the new domain should occur when users are not logged onto the computer. The computer will be forced to reboot when it is joined to the new domain. If the profile translation was successful the user will be able to logon to the new domain and still maintain their old settings.
Moving mailboxes. If moving mailboxes from E5.5 to E2K3 then the procedure is simple (profiles do not need to be rebuilt/reconnected, the user will hardly notice a difference). We would recommend joining the new E2K3 server to the old E5.5 site. If moving between E2K3 servers in different forests things are a little more complicated (no permissions or rules will be carried over). Both moves require ample planning and testing. The time it takes to move mailboxes depends on the number of items in a user?s mailbox and the size of the mailbox. Also when moving it?s a good idea to break the users into categories: users, operational, tier 1, and organizational. Tier 1/organizational accounts should be moved last. Having the user logged off the mailbox is not necessary for the migration, but it is recommended.
Duplicate objects (users/groups/computers). If migrating to a domain that is already established then duplicate objects may already exist in the new domain, i.e. there is a john.smith in the old domain and a different john.smith in the new domain. Nearly every migration tool will allow for de-conflicting the accounts during the migration. Most times the tool will ask during the setup if a prefix or a suffix is desired for conflicting accounts.
CAC Login. If setting up a new domain ensure the Certificate Authority is configured to send the domain controllers the Certificate Revocation List. Also ensure the workstations and domain controllers can make the CA requests through the firewall/proxy. Ensuring the User Principal Name (UPN) is CACNumber@company in the new domain is the biggest concern. The migration tools like to change the @mil of the UPN to @newdomain.company.
Exchange 5.5 Issues. If a mailbox is over its size limits it will not be allowed to move during an E5.5 to E2K3 migration. Every mailbox must be linked to a ?Primary NT Account?. This is most noticeable on organizational accounts.
This phase obviously impacts the customers more then any other phase. Testing should have been extensively performed and potential problems documented before beginning the move. Leadership and customers should have been informed of potential problems and contingency plans. If timed correctly this phase can be accomplished over two weekends depending, on customer size. Migrate computers and servers the first weekend. Resolve problems and test Exchange during the week. Migrate mailboxes the second weekend.
Standardization & Cleanup
? Anti-Virus Updates. Do the computers need to point to a new anti-virus server?
? SMS Reporting/Patching. Will there be a new SMS server? Is the SMS boundary configured correctly? Was SMS turned off before migrating computers to the new domain?
? Mail Storage Limits. Will management enforce size limits before migrating?
? Admin Account Renaming. Administrative and service accounts generally cannot be migrated due to name conflicts and Active Directory restrictions.