Migration Tools

Whether you are using the restructure method to migrate an entire domain structure or just need to migrate from another Windows 2000 or Windows Server 2003 forest, a number of tools are available. Microsoft provides the free ADMT included on the Windows 2003 CD. The following section identifies significant features in ADMT 2.0 that was released with Windows Server 2003. Other tools from third-party vendors are listed with a basic description and a pointer to the vendor's Web site. Because these tools change often, the vendor sites will be updated, whereas the printed information here will be quickly dated.

ADMT

When Windows 2000 was still in beta, Microsoft realized one of the major obstacles Windows NT customers would face would be migrating users, computers, and groups from the Windows NT environment to Windows 2000. Microsoft was up front in admitting it didn't have time or resources to develop sophisticated tools and partnered with several third-party developers to create those tools. Microsoft did provide some simplistic migration tools, including Cloneprincipal and ADMT. Mission Critical Software (now NetIQ ) created ADMT as a subset of its migration tool. Although ADMT was limited in functionality, it did have its place in small migrations and moving security principals between domains and forests.

note

ADMT v2 is available on the Windows Server 2003 CD in \i386\ADMT and from Microsoft's download site at http://www.microsoft.com/downloads. It's listed in the Tools and Add-Ins section.

ADMT v2 can migrate security principals from Windows NT to Windows 2003, Windows 2000 to Windows 2003, Windows NT to Windows 2000, and within Windows 2000 or Windows 2003 forests. Like ADMT v1, ADMT v2 features a Graphical User Interface (GUI) that looks much the same as v1. Figure 3.17 shows the GUI, listing the various migration tasks you can choose from.

Figure 3.17. ADMT options exposed in the GUI.

ADMT v2 has added a number of features to correct serious limitations in ADMT v1. Some of these improvements include

• Delegated migration : ADMT v1 required the user running the tool to have Administrator rights in the source and target domains. ADMT v2 does not perform that check at the target, thus enabling delegation. This would allow an OU Administrator to be delegated rights to perform migration operations when his or her OU is the target of the migration.

• Increased logging : ADMT v1 created only one log file, which was overwritten each time ADMT was run. ADMT v2 provides for up to 20 log files, creating a new log for each time ADMT is run.

• Repair user's group membership : ADMT v1 builds the user's group membership in the target domain just as it existed in the source domain, even if the group no longer exists in the target. ADMT v2 allows the Administrator to disable this functionality.

• Support for InetOrgPerson migration : Windows Server 2003 includes the InetOrgPerson object class, as does Windows 2000 with the InetOrgPerson kit and Exchange 2000. ADMT v2 supports migration of the InetOrgPerson object.

• Improved ability to decommission the source domain : ADMT v1 required the source domain to remain online for security translation, delaying the decommission of the source domain. ADMT v2 stores the security translation information in the protar.mdb database, allowing the source domain to be immediately decommissioned.

• Improved reporting : ADMT v2 includes SIDs in addition to friendly names of accounts, making it easy to create SID mapping files, used in mapping Access Control Entries (ACEs) of security principals in the source domain with those in the target domain. ADMT v2 also omits null references, including only accounts with an ACE in the Access Control List (ACL).

In addition to the features listed here, scripting, command-line interface, and password migration are perhaps the most significant improvements in ADMT v2. The following sections examine them in detail.

Scripting Support

Scripting is an important feature in any migration tool and a severe limitation to ADMT v1. However, ADMT v2 offers a scripting interface that allows access to wizard functions using any scripting language that supports the Component Object Model (COM) interfaces. This feature makes ADMT v2 much more powerful by offering the Administrator the flexibility to

• Migrate objects to targets in multiple domains and OUs in a single operation

• Combine multiple migration operations such as migrating users, groups, computers, and security translation in a single operation

• Add new groups or ACEs during the migration operation

• Add custom code for such things as adding users from an HR database

• Customize the migration in a cross-forest migration, such as collapsing or expanding the source OU structure in the target domain or replicating the structure

• Use archived scripts as a record of migration details for later evaluation

Scripting, however, has some drawbacks. It does require skilled programmers who are able to develop complex scripts to accomplish migration tasks, including configuration checking and error handling. Also, because not all operations are scriptable, there are some limitations as to what scripting can do. For example, you can perform only Exchange Directory Migration, Undo Last Migration, Retry Task, Trust Migration, and Group Mapping and Merging functions by using the wizards. Although Microsoft touts scripting migrations as mostly suitable for large organizations, I've seen smaller companies utilize it in other migration tools because of the capability to customize and perform multiple functions in a single operation.

Command-Line Interface

The command-line functionality provides the Administrator with a quick and easy interface to perform simple migration operations such as moving users from an OU in one domain to an OU in another domain or forest. The interface uses input directly from the command line or from option files structured in .ini format, allowing the Administrator to create lists of groups, users, and so on in a file for input to the ADMT command-line interface. The command-line interface can also be called from a script or .bat file. Figure 3.18 shows a sample of the user migration option from the command line.

Figure 3.18. Executing migration operations from the command-line interface in ADMT.

In the example here, we used the following options:

 /f:"\admt\ntuser.ini" is the include file  a text file of users to be migrated /tm:Yes (use test migration option) /IF:Yes (Inter-forest migration =Yes) /sd:Corpnt (NetBIOS name of the source domain is CorpNT  an NT domain /td:CompanyX (NetBIOS name of the target domain is Corp  a Win2K domain /to:stage1 (Target OU is Stage1) /po:complex (Password Option is Complex. This will generate a random complex password for  the migrated accounts in the target OU. The passwords are stored in a plain text file on  the disk.) /migrateSIDs:Yes (enable SIDhistory) 

Improved Password Migration

Along with scripting and command-line support, password migration makes ADMT a viable migration tool. Specifically, ADMT v1 did not support inter-forest account password migration. ADMT v2 supports password migration with several options:

• Generate Complex Passwords : These are randomly generated complex passwords and are stored with the account name in a plain text file in \program files\active directory migration tool\logs\passwords.txt.

• Password Matches Username : Combined with the requirement for the user to change the password at the first login, makes it easy for the user, but is somewhat unsecure as it makes the passwords easy to guess until the user changes it.

• Migrate Password : This option migrates the existing password on the source account to the new account in the target domain or OU. This requires considerable work to set it up. Figure 3.19 shows the password-migration options in the GUI.

  Figure 3.19. Password migration has several options exposed in the ADMT GUI.

  
  

Other Features

Just like its third-party peers, although not as flashy, ADMT allows the Administrator to

• Decide how naming conflicts should be resolved (see Figure 3.20). If there is a user, group, or computer in the source domain that is the same as the target domain, you can set the rule on how to deal with it, such as giving a standard suffix or prefix to the name.

  Figure 3.20. ADMT offers several choices of how to deal with name conflicts when the source accounts are moved to the target domain.

  
  

• Decide what to do with the source and target accounts (see Figure 3.21). You might want to disable the old account in the source domain to force the users to use the new one, or disable the target accounts and enable them one by one as the user is ready.

  Figure 3.21. ADMT allows the Administrator to enable or disable the source and target accounts as part of the migration.

  
  

• Test the migration in Reporting mode, which is a trial run. It doesn't actually do the migration, but it does generate a report that includes errors encountered . The following report shows an operation that migrated five user accounts:

   2004-02-11 16:01:54 2004-02-11 16:01:54 Active Directory Migration Tool, Starting... 2004-02-11 16:01:54 Starting Account Replicator. 2004-02-11 16:01:55 Account MigrationWriteChanges:No CORPNT CORP CopyUsers:Yes  CopyGlobalGroups:No CopyLocalGroups:No CopyComputers:No DisableSourceAccounts:Yes StrongPwd:All 2004-02-11 16:01:57 CN=NTUser11          - Created 2004-02-11 16:01:57 CN=NTUser12          - Created 2004-02-11 16:01:57 CN=NTUser13          - Created 2004-02-11 16:01:58 CN=NTUser14          - Created 2004-02-11 16:01:58 CN=NTUser15          - Created 2004-02-11 16:01:59 Operation completed. 

  
  

ADMT's Value

How good is ADMT v2.0? I queried a few of HP's consultants who have used ADMT v2 and asked what kind of an environment or size of migration ADMT realistically would support. When asked to compare ADMT's performance to third-party tools from companies such as BindView, Aelita, NetIQ, and Quest, the consultants indicated that performance is similar; that is, roughly 500 user objects per hour , and performance in re-ACLing (changing the security ACLs to reflect new security in the new domain) is acceptable. However, ADMT's capability to perform a migration should be judged on the complexity of the source environment. If you have to split up the migration into multiple tasks (for different locations, business units, and so on), ADMT will not make it easy. Also if you have shared resources that are ACL'd from multiple trusted domains, it will be difficult and time-consuming with ADMT v2.

When asked what complexity limit they would recommend using with ADMT v2, the response was that a single source domain with 10,000 users could be done in a single batch over a weekend . It is possible that ADMT v2's scripting and command-line interface could make it possible to do multiple batches and increase this limit.

When asked to name the operations they have used ADMT v2 for, the response was that they used it to interactively

• Migrate users

• Migrate user profiles

• Migrate workstations and servers

• ReACL files and Exchange mailboxes

• Securely copy passwords

• Update user profiles that are in use (much improved over ADMT v1)

When asked what their overall impression was of ADMT v2, the response was that, in general, it's very reliable and easy to use, and seems to work as documented. Scripting support is the biggest improvement in v2. If you were to take the time to build the framework, ADMT v2 could be enterprise-capable, assuming your environment is simple enough.

note

At this writing, ADMT v3 is being developed. Microsoft has indicated that this version will use a SQL database (presumably the Microsoft Data Engine [MSDE] will work) and will store information so the target and source don't have to be online at the same time. Monitor Microsoft's Web site for this new version of the tool.

Third-Party Products

A number of companies are selling AD migration tools. The most mature ones are listed here. These tools have been around a long time ”since Windows 2000 was released. I'm not selling or recommending them, but simply listing them here with a short feature list so you can be aware of what's out there. These products have clear advantages over ADMT, but they cost a lot more, too. Large migrations in terms of users, remote sites, and so on will benefit from these tools, where ADMT is probably sufficient for smaller organizations as noted in the previous section. These products all run from a separate member server and map credentials needed for the migration to accounts in the tool to give migrators proper permissions. That can all be safely removed after the migration so it doesn't mess with actual permissions, and running separately on a member server, they aren't intrusive into the domain. They all have an "undo" function so you can back out of an operation, they let you organize "projects" so you can design the stages of the migration autonomously, and they feature SIDHistory Cleanup and reporting to allow you to test a migration sequence and see the result, including errors, giving you a chance to correct them before the live migration.

Quest Software

Quest features the Fastlane suite of products, including Fastlane Migrator and Fastlane NDS Migrator. Quest was one of the initial three vendors who worked with Microsoft in the beta days of Windows 2000, and the Fastlane products are as mature as any on the market. The easy-to-navigate Quest Web site at http://www.quest.com/solutions/allproductsatoz.asp lists all the products with quick links to the product information and a link to the trial download. The features of the Fastlane Migrator include

• A Migration Guide with step-by-step instructions for the migration

• Integration of the Exchange 2000 Active Directory Connector (ADC)

• Drag and drop of objects (users, computers, and so on) to migrate between domains and forests

• Object level "undo" capability so you can back out of the migration

• Updating of Exchange mailboxes, mailbox data, AD objects, and public folders (for Exchange migrations)

Aelita Software

Aelita Software, http://www.aelita.com, markets a couple of interesting products in regard to migration. Aelita also has AD-management products. The Domain Migration Wizard has the following features:

• Processing of ACLs, including owners , auditing, and permissions

• Full Windows NT migration

• Netware 5.0 Migration Directory Synchronization Tool (MSDSS) migrates security descriptors that allow access to Netware shares, folders, and files during the migration

• Exchange mailboxes and permissions are modified for migrated accounts

• Password migration for migrated accounts

• SIDHistory Cleanup

• Security management on Microsoft SQL data stores to reflect account migrations

• Windows NT domain reconfiguration enables merging and splitting of Windows NT domains

Aelita also has a feature called ZeroImpact that aids in migration of the user profiles without Administrators visiting each workstation. The company also lays claim to being able to perform migrations much faster (elapsed time) than its competitors . A number of whitepapers are on Aelita's Web site at http://www.aelita.com/products/domainmigrationwizard/documentation.asp .

BindView

BindView has several products that provide migration capability and are sold separately or bundled together as a suite. Details are noted on the BindView Web site at http://www.bindview.com/Products/DirAdminMig/Migration/index.cfm .

The products include

• bv-Admin for Windows Migration : For migrating Windows NT and Windows 2000 to Windows 2003 and intra-forest migrations.

• bv-Admin for Exchange Migration : Supports migration from Exchange 5.5 and Exchange 2000 to Exchange 2003.

• bv-admin for Novell Migration : Migrates complete or partial NDS hierarchy, manages file and resource permissions including translation from NDS security to AD security, and maps NDS user accounts to AD user accounts.

BindView was one of the original migration tools developed for Windows 2000 and used by Compaq in its Windows NT to Windows 2000 migration. This tool offers all the features noted earlier in this section, such as Project-based management, rollback, and so on.

NetIQ

NetIQ, also one of the original three migration tools for Windows 2000, offers three products in the migration arena as well as a number of products for AD administration. Microsoft's ADMT is actually a stripped-down version of NetIQ's Domain Administrator product; NetIQ wrote the original ADMT. NetIQ's suite of products, which can be purchased and used separately or as a suite, include

• Domain Migration Administrator : Used for migrating Windows NT or 2000 domains to Windows Server 2003. This tool allows the target domain to be mixed mode, whereas some other tools, such as ADMT, require it to be native. More information at http://download.netiq.com/CMS/DATASHEET/NetIQ_DS_Domain_Migration_Administrator.pdf.

• Exchange Migrator : Moves mailboxes, distribution lists, public folders, and custom recipients, and supports Exchange 5.5, Exchange 2000, and Exchange 2003. More details are available in a document at http://download.netiq.com/CMS/DATASHEET/NetIQ_DS_ExchangeMigrator.pdf .

• Server Consolidator : Supports hardware consolidations, including cluster implementations ; and supports data, shares, and printer settings. More information at http://download.netiq.com/CMS/DATASHEET/NetIQ_DS_Server_Consolidator.pdf .

ProLiant Tools

A number of powerful ProLiant tools will be instrumental in a successful migration. Some of these include improvements to SmartStart, ProLiant Essentials Foundation Pack, Remote Deployment Utility (RDU), and Systems Insight Manager (SIM), which have all been described in Chapter 2. Chapter 7 includes further discussion on their utilization in the deployment phase. In addition, Chapter 9 is dedicated to the RDP, a powerful utility that greatly simplifies deploying software, including the OS on servers in your infrastructure. It is estimated that only about 13% of the ProLiant community is unaware of these tools and doesn't use them. These tools are state-of-the-art and without peers. If you have ProLiant systems and are not taking advantage of these tools, use the relevant chapters in this book to find out how they can help you.

Let's now turn our attention to some actual case studies of companies that have performed migrations to Windows Server 2003 from Windows NT and Windows 2000.