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 1 shows the GUI, listing the various migration tasks you can choose from.
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 2 shows a sample of the user migration option from the command line.
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)
