| ADMT v2.0 installs very easily but requires a thorough knowledge of the various wizards to be used properly. In addition, best-practice processes should be used when migrating from one domain to another. The migration example in the following sections describes the most common use of the Active Directory Migration Tool: an interforest migration of domain users, groups, and computers into another domain. This procedure is by no means exclusive, and many other migration techniques can be used to achieve proper results. Subsequently, matching the capabilities of ADMT with the migration needs of an organization is important. Using ADMT in a Lab Environment ADMT v2.0 comes with unprecedented rollback capabilities. Not only can each wizard be tested first, but the last wizard transaction can also be rolled back in the event of problems. In addition, it is highly recommended that you reproduce an environment in a lab setting and that the migration process is tested in advance to mitigate potential problems that may arise. You can develop the most effective lab by creating new domain controllers in the source and target domains and then physically segregating them into a lab network, where they cannot contact the production domain environment. The Operations Master (OM) roles for each domain can then be seized for each domain using the ntdsutil utility, which effectively creates exact replicas of all user, group, and computer accounts that can be tested with the ADMT. ADMT v2.0 Installation Procedure The ADMT component should be installed on a domain controller in the target domain, where the accounts will be migrated to. To install, follow these steps: 1. | Insert the Windows Server 2003 CD into the CD-ROM drive of a domain controller in the target domain.
| 2. | Choose Start, Run. Then type d:\i386\admt\admigration.msi, where d: is the drive letter for the CD-ROM drive, and press Enter.
| | | 3. | At the Welcome screen, as illustrated in Figure 17.17, click Next to continue.
Figure 17.17. Installing ADMT. 
| 4. | Accept the end-user license agreement (EULA) and click Next to continue.
| 5. | Accept the default installation path and click Next to continue.
| 6. | When ready to begin the installation, click Next at the next screen.
| 7. | After installation, click Finish to close the wizard.
|
ADMT Domain Migration Prerequisites As previously mentioned, the most important prerequisite for migration with ADMT is lab verification. Testing as many aspects of a migration as possible can help to establish the procedures required and identify potential problems before they occur in the production environment. That said, several functional prerequisites must be met before the ADMT can function properly. Many of these requirements revolve around the migration of passwords and security objects, and are critical for this functionality. Creating Two-Way Trusts Between Source and Target Domains The source and target domains must each be able to communicate with each other and share security credentials. Consequently, it is important to establish trusts between the two domains before running the ADMT. Assigning Proper Permissions on Source Domain and Source Domain Workstations The account that will run the ADMT in the target domain must be added into the Builtin\Administrators group in the source domain. In addition, each workstation must include this user as a member of the local Administrators group for the computer migration services to be able to function properly. Domain group changes can be easily accomplished, but a large workstation group change must be scripted, or manually accomplished, prior to migration. Creating Target OU Structure The destination for user accounts from the source domain must be designated at several points during the ADMT migration process. Establishing an organizational unit (OU) for the source domain accounts can help to simplify and logically organize the new objects. These objects can be moved to other OUs after the migration and this OU collapsed, if you want. Modifying Default Domain Policy on the Target Domain Unlike previous versions of Windows operating systems, Windows Server 2003 does not support anonymous users authenticating as the Everyone group. This functionality was designed in such as way as to increase security. However, for ADMT to be able to migrate the accounts, this functionality must be disabled. When the process is complete, the policies can be reset to the default levels. To change the policies, follow these steps: 1. | Open the Domain Security Policy (Start, All Programs, Administrative Tools, Domain Security Policy).
| 2. | Navigate to Security Settings\Local Policies\Security Options.
| 3. | Double-click Network Access: Let Everyone Permissions Apply to Anonymous Users.
| 4. | Check Define This Policy Setting and choose Enabled, as indicated in Figure 17.18. Click OK to finish.
Figure 17.18. Modifying the domain security policy. 
| 5. | Repeat the procedure for the Domain Controller Security Policy snap-in.
|
Exporting Password Key Information A 128-bit encrypted password key must be installed from the target domain on a server in the source domain. This key allows for the migration of password and SID History information from one domain to the next. To create this key, follow these steps from the command prompt of a domain controller in the target domain where ADMT is installed: 1. | Insert a floppy disk into the drive to store the key. (The key can be directed to the network but, for security reasons, directing to a floppy is better.)
| 2. | Change to the ADMT directory by typing cd C:\program files\active directory migration tool and pressing Enter, where C: is the OS drive.
| | | 3. | Type admt key <SourceDomainName> a: <password>, where <SourceDomainName> is the NetBIOS name of the source domain, a: is the destination drive for the key, and <password> is a password that is used to secure the key. Refer to Figure 17.19 for an example. Then press Enter.
Figure 17.19. Exporting the password key. 
| | | 4. | Upon successful creation of the key, remove the floppy and keep it in a safe place.
|
Installing a Password Migration DLL on the Source Domain A special password migration DLL must be installed on a domain controller in the source domain. This machine will become the Password Export Server for the source domain. The following procedure outlines this installation: 1. | Insert the floppy disk with the exported key from the target domain into the server's disk drive.
| 2. | Insert the Windows Server 2003 CD into the CD-ROM drive of the domain controller in the source domain where the Registry change will be enacted.
| 3. | Start the Password Migration Utility by choosing Start, Run and typing d:\i386\ADMT\Pwdmig\Pwdmig.exe, where d: is the drive letter for the CD-ROM drive.
| 4. | At the Welcome screen, click Next.
| | | 5. | Enter the location of the key that was created on the target domain; normally, this is the A: floppy drive, as indicated in Figure 17.20. Click Next to continue.
Figure 17.20. Setting up the password migration DLL. 
| 6. | Enter the password twice that was set on the target domain and click Next.
| 7. | At the Verification page, click Next to continue.
| 8. | Click Finish after the installation is complete.
| 9. | The system must be restarted, so click Yes when prompted to automatically restart. Upon restarting, the proper settings will be in place to make this server a Password Export Server.
|
Setting Proper Registry Permissions on the Source Domain The installation of the proper components creates special Registry keys but leaves them disabled by default, for security reasons. You need to enable a specific Registry key to allow passwords to be exported from the Password Export Server. The following procedure outlines the use of the Registry Editor to perform this function: 1. | On a domain controller in the source domain, open the Registry Editor (Start, Run, Regedit).
| 2. | Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
| 3. | Double-click the AllowPasswordExport DWORD value.
| 4. | Change the properties from 0 to 1Hexadecimal.
| 5. | Click OK and close the Registry Editor.
| 6. | Reboot the machine for the Registry changes to be enacted.
|
At this point in the ADMT process, all prerequisites have been satisfied, and both source and target domains are prepared for the migration. Migrating Groups In most cases, the first objects to be migrated into a new domain should be groups. If users are migrated first, their group membership will not transfer over. However, if the groups exist before the users are migrated, they will automatically find their place in the group structure. To migrate groups using ADMT v2.0, use the Group Account Migration Wizard, as follows: 1. | Open the ADMT MMC snap-in (Start, All Programs, Administrative Tools, Active Directory Migration Tool).
| | | 2. | Right-click Active Directory Migration Tool in the left pane and choose Group Account Migration Wizard.
| 3. | Click Next to continue.
| 4. | On the next screen, shown in Figure 17.21, you can choose to test the migration. As mentioned previously, the migration process should be thoroughly tested before actually being placed in production. In this example, however, you want to perform the migration. Choose Migrate Now and click Next to continue.
Figure 17.21. Choosing to migrate in the Group Account Migration Wizard. 
| 5. | Select the source and destination domains and click Next to continue.
| 6. | On the subsequent screen, you can select the group accounts from the source domain. Select all the groups required by using the Add button and selecting the objects manually. After you select the groups, click Next to continue.
| 7. | Enter the destination OU for the accounts from the source domain by clicking Browse and selecting the OU created in the steps outlined previously. Click Next to continue.
| | | 8. | On the following screen, there are several options to choose from that determine the nature of the migrated groups. Clicking the Help button details the nature of each setting. In the sample migration, choose the settings shown in Figure 17.22. After choosing the appropriate settings, click Next to continue.
Figure 17.22. Setting group options. 
| | | 9. | If auditing is not enabled on the source domain, you will see the prompt shown in Figure 17.23. It gives you the option to enable auditing, which is required for migration of SID History. Click Yes to continue.
Figure 17.23. Enabling auditing. 
| | | 10. | Another prompt may appear if auditing is not enabled on the target domain. Auditing is required for migration of SID History and can be disabled after the migration. Click Yes to enable and continue.
| 11. | A local group named SOURCEDOMAIN$$$ is required on the source domain for migration of SID History. A prompt asking to create this group is displayed at this point, as shown in Figure 17.24, if it was not created beforehand. Click Yes to continue.
Figure 17.24. Creating a local group. 
| 12. | Another prompt may appear asking to create a Registry key named TcpipClientSupport in the source domain. Once again, this is required for SID History migration. Click Yes to continue.
| | | 13. | If you created the Registry key, an additional prompt then asks whether the PDC in the source domain will require a reboot. In most cases, it will, so click Yes to continue.
| 14. | The next prompt, shown in Figure 17.25, exists solely to stall the process while the reboot of the Source PDC takes place. Wait until the PDC is back online and then click OK to continue.
Figure 17.25. Waiting for the source domain PDC reboot. 
| 15. | The subsequent screen allows for the exclusion of specific directory-level attributes from migration. If you need to exclude any attributes, they can be set here. In this example, no exclusions are set. Click Next to continue.
| 16. | Enter a user account with proper administrative rights on the source domain on the following screen. Then click Next to continue.
| 17. | Naming conflicts often arise during domain migrations. In addition, different naming conventions may apply in the new environment. The next screen, shown in Figure 17.26, allows for these contingencies. In this example, any conflicting names will have the XYZ- prefix attached to the account names. After defining these settings, click Next to continue.
Figure 17.26. Handling naming conflicts. 
| | | 18. | The verification screen is the last wizard screen you see before any changes are made. Once again, make sure that the procedure has been tested before running it because ADMT will henceforth write changes to the Target Windows Server 2003 Active Directory environment. Click Finish when you're ready to begin group migration.
| 19. | The group migration process then commences. Changing the refresh rate, as shown in Figure 17.27, allows for a quicker analysis of the current process. When the procedure is complete, the log can be viewed by clicking View Log. After finishing these steps, click the Close button to end the procedure.
Figure 17.27. Altering the migration progress of group accounts. 
|
Migrating User Accounts User accounts are the "bread and butter" of domain objects and are among the most important components. The biggest shortcoming of ADMT v1.0 was its inability to migrate passwords of user objects, which effectively limited its use. However, ADMT v2.0 does an excellent job of migrating users, their passwords, and the security associated with them. To migrate users, follow these steps: 1. | Open the ADMT MMC snap-in (Start, All Programs, Administrative Tools, Active Directory Migration Tool).
| | | 2. | Right-click Active Directory Migration Tool and choose User Account Migration Wizard, as indicated in Figure 17.28.
Figure 17.28. Starting the User Account Migration Wizard. 
| 3. | Click Next at the Welcome screen.
| 4. | The next screen offers the option to test the migration before actually performing it. As previously mentioned, this process is recommended, so for this example, perform the full migration. Select Migrate Now and then click Next.
| 5. | Select the source and target domains in the subsequent screen and click Next to continue.
| | | 6. | The following screen allows you to choose user accounts for migration. Just click the Add button and select the user accounts to be migrated. After you select all the user accounts, click Next to continue.
| 7. | The next screen, shown in Figure 17.29, allows you to choose a target OU for all created users. Choose the OU by clicking the Browse button. After you select it, click Next to continue.
Figure 17.29. Selecting the target OU. 
| | | 8. | The new password migration functionality of ADMT v2.0 is enacted through the following screen. Select Migrate Passwords and then select the server in the source domain in which the Password Migration DLL was installed as covered in the "Installing a Password Migration DLL on the Source Domain" section. Click Next to continue.
Note Depending on if other wizards have already been run, there may be additional steps at this point that happen one time only to set up proper registry settings, reboot DCs, and create special groups. These steps and dialog boxes are documented in steps 914 of the "Migrating Groups" section that precedes this section. | | | 9. | The subsequent screen deals with security settings in relation to the migrated users. Click Help for an overview of each option. In this example, select the settings as shown in Figure 17.30. Then click Next to continue.
Figure 17.30. Setting the account transition options. 
| 10. | Enter the username, password, and domain of an account that has Domain Admin rights in the source domain. Click Next to continue.
| | | 11. | Several migration options are presented as part of the next screen. As before, clicking Help elaborates on some of these features. In this example, select the options as shown in Figure 17.31. Click Next to continue.
Figure 17.31. Setting user options for the User Account Migration Wizard. 
| 12. | The next screen is for setting exclusions. Specify any property of the user object that should not be migrated here. In this example, no exclusions are set. Click Next to continue.
| | | 13. | Naming conflicts for user accounts are common. Designate a procedure for dealing with duplicate accounts in advance and enter such information in the next wizard screen, as shown in Figure 17.32. Select the appropriate options for duplicate accounts and click Next to continue.
Figure 17.32. Setting naming conflict settings. 
| | | 14. | The following verification screen presents a summary of the procedure that will take place. This is the last screen before changes are written to the target domain. Verify the settings and click Next to continue.
| | | 15. | The Migration Progress status box displays the migration process as it occurs, indicating the number of successful and unsuccessful accounts created. When the process is complete, review the log by clicking View Log and verify the integrity of the procedure. A sample log file from a user migration is shown in Figure 17.33. Click Close when finished.
Figure 17.33. Viewing a sample user migration log. 
|
Migrating Computer Accounts Another important set of objects that must be migrated is also one of the trickier ones. Computer objects must not only be migrated in AD, but they must also be updated at the workstations themselves so that users will be able to log in effectively from their consoles. ADMT seamlessly installs agents on all migrated computer accounts and reboots them, forcing them into their new domain structures. Follow these steps to migrate computer accounts: 1. | Open the ADMT MMC snap-in (Start, All Programs, Administrative Tools, Active Directory Migration Tool).
| 2. | Right-click Active Directory Migration Tool and choose Computer Migration Wizard.
| 3. | Click Next at the Welcome screen.
| 4. | Just as in the previous wizards, the option for testing the migration is given at this point. It is highly recommended that you test the process before migrating computer accounts. In this case, because a full migration will take place, choose Migrate Now. Click Next to continue.
| 5. | Type the names of the source and destination domains in the drop-down boxes on the next screen and click Next to continue.
| 6. | In the following screen, select the computer accounts that will be migrated by clicking the Add button and picking the appropriate accounts. Click Next to continue.
| 7. | Select the OU the computer accounts will be migrated to and click Next to continue.
| | | 8. | The next screen allows for the option to specify which settings on the local clients will be migrated. Click the Help button for a detailed description of each item. In this example, select all items, as shown in Figure 17.34. Click Next to continue.
Figure 17.34. Specifying objects that will be translated. 
| 9. | The subsequent screen prompts to choose whether existing security will be replaced, removed, or added to. In this example, replace the security. Click Next to continue.
| 10. | A prompt then informs you that the user rights translation will be performed in Add mode only. Click OK to continue.
| 11. | The next screen is important. It allows an administrator to specify how many minutes a computer will wait before restarting itself. In addition, you can define the naming convention for the computers, as shown in Figure 17.35. After choosing options, click Next to continue.
Figure 17.35. Selecting computer options. 
| | | 12. | Just as in the previous wizards, exclusions can be set for specific attributes in the following wizard screen. Select any exclusions needed and click Next to continue.
| 13. | Naming conflicts are addressed in the subsequent screen. If any specific naming conventions or conflict resolution settings are required, enter them here. Click Next to continue.
| 14. | The Completion screen lists a summary of the changes that will be made. Review the list and click Finish when ready. All clients that will be upgraded are subsequently rebooted.
| 15. | When the migration process is complete, you can view the Migration log by clicking the View Log button. After verifying all settings, click Close.
| 16. | The client agents are subsequently distributed to all clients that have been migrated. Each agent is installed automatically and counts down until the designated time limit set during the configuration of the Computer Migration Wizard. At that point, the dialog box in Figure 17.36 appears on each workstation.
Figure 17.36. Notifying users of automatic workstation shutdown. 
| 17. | Click Close on the ADMT MMC snap-in to end the wizard.
|
Migrating Other Domain Functionality In addition to the Group, User, and Computer Migration Wizards, several other wizards can be used to migrate specific domain-critical components. These wizards operate using the same principles as those described in the preceding sections, and are as straightforward in their operation. The following is a list of the additional wizards included in ADMT v2.0: Security Translation Wizard Reporting Wizard Service Account Migration Wizard Exchange Directory Migration Wizard Retry Task Wizard Trust Migration Wizard Group Mapping and Merging Wizard
Virtually all necessary functionality that needs replacing when migrating from one domain to another can be transferred by using ADMT v2.0. It has proven to be a valuable tool that gives administrators an additional option to consider when migrating and restructuring Active Directory environments. |
