In-Depth
Active Directory Migration Gets Easier
Microsoft’s recently released Active Directory Migration Tool v2 offers important enhancements over the first version. One of Hewlett-Packard’s top AD experts briefs us on the improvements.
When Windows 2000 was still in beta, Microsoft realized that one of the major obstacles Windows NT customers would face would be migrating users, computers and groups from the older environment to Win2K. Microsoft was upfront in admitting it didn’t have time or resources to develop sophisticated tools for the job, so it partnered with several third-party companies to create those tools. NetIQ, Aelita Software, BindView and Quest Software are among the leading vendors of migration tools and all have mature products at this point. Microsoft did provide some simple migration tools, including the GUI-based Active Directory Migration Tool (ADMT), command-line tools like Movetree.exe, Ldifde.exe and Netdom.exe, and the clonePrincipal scripts. These tools all had limitations, and multiple tools were often required to accomplish various migration tasks. Microsoft’s Domain Migration Cookbook is an excellent resource describing these tools. ADMT v1 was actually created by Mission Critical Software (now NetIQ) as a subset of its migration tool; and while ADMT was limited in functionality, it did have its place in small migrations and moving security principals between as well as within domains and forests.
Microsoft has recently released ADMT version 2, which offers some big improvements over the v1 product, making it a more viable candidate for small and mid-level migrations. ADMT v2 is available on the Windows Server 2003 Server CD (i386\admt.msi) and from Microsoft’s download site, noted at the end of this article.
ADMT v2 can migrate security principals, trusts and service accounts; and it can perform security translation.
ADMT v2 features a GUI that looks much the same as v1. Figure 1 shows
the GUI, listing the various migration tasks. Unlike v1, the new version
features fairly powerful scripting and command-line interfaces as well
as inter-forest password migration.
 |
| Figure 1. ADMT migration options. |
Other new features include:
Delegated migration. ADMT v1 required the user
running the tool to have Administrator rights in the source and target
domains. ADMTv2 doesn’t perform that check, 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 each time ADMT is run. The
number of log files is configured through the registry at HKLM\software\
microsoft\admt\loghistory.
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 source domain.
One limitation in ADMT v1 was the fact that the source domain had to be
available for security translation until the migration was complete. ADMT
v2 now stores that information in the Protar.mdb file. Once stored, the
source domain need not be available, and can be decommissioned. If you
have upgraded ADMT v1 to v2, the protar.mdb will be upgraded to the new
format and discover any new source domains.
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.
Note: This isn’t a complete list, but, in my opinion, the most
significant new features. The scripting, command-line interface and inter-forest
password migration features are important improvements in ADMT v2. Let’s
examine each in more detail.
Scripting Support
Scripting is an important feature in any migration tool and a severe limitation
to ADMT v1. ADMT v2 offers a scripting interface that allows access to
wizard functions using any scripting language that supports COM interfaces.
This feature makes ADMT v2 much more powerful by offering the administrator
the flexibility to manage multiple migration tasks in a complex environment.
HP consultants I talked to emphasized that this is the one improvement
in ADMT that makes it somewhat palatable in a mid-size migration.
By scripting, the administrator can migrate objects to multiple domains and OUs in a single operation. Scripting also allows you to migrate users, groups, computers and security translation in a single operation. Note that in the GUI you have to do each of these in a separate operation. Scripts are also useful in collapsing or expanding a domain structure, and adding users from existing corporate (non-AD) databases. Another great thing about scripting is that you have a record of how the migration was accomplished (i.e., the script itself). Thus, if you have need to see how or why the migration was accomplished, you have the record. You can also reuse it as a starting point to other migrations. This may come in handy if migration team members leave the company or you hire that infamous consultant that you can never find when things go wrong!
Scripting, however, has some drawbacks. It requires skilled programmers
who are able to develop complex scripts to accomplish migration tasks,
including configuration checking and error handling. Also, since not all
operations are scriptable there are some limitations. While Microsoft
pushes scripting migrations as mostly suitable for large organizations,
smaller companies can use it because of the ability 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. It
uses input directly from the command line or from option files structured
in the .ini format, allowing the administrator to create lists of groups,
users, and the like in a file for input to the ADMT command-line interface.
The interface can also be called from a script or .bat file.
In the example shown in Figure 2, the following options were used:
/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
CompanyX – 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)
Note that scripting and the command-line interface require ADMT to be
run on a DC in the target domain.
 |
| Figure 2. A sample of the User migration option
from the command line. (Click image to view larger version.) |
Improved Password Migration
Along with scripting and command-line support, ADMT v2 now provides for
inter-forest password migration and makes ADMT a viable migration tool.
ADMT v2 supports password migration with several options (see Figure 3):
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, this makes it easy for the
user but is somewhat insecure 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 up.
 |
| Figure 3. Password migration options as seen in the
ADMT GUI. |
The inter-forest password migration entails more than just checking an option in the GUI. You must make a couple of modifications to Registry keys, install the password migration .dll on the source domain controller and configure a BDC (for NT) or a peer DC (Windows 2000 and 2003) to serve as the password export server. Refer to the release notes in the ADMT download file as well as the knowledge base articles noted in “Additional Information” for details. The ADMT download also contains files needed for password migration.
Although ADMT v2 has added significant functionality and performance
features, there are still some drawbacks. I queried a few of HP’s consultants
who’ve used ADMT v2 and asked what kind of an environment or size of migration
ADMT would realistically support. I also asked what their impression of
v2 was. Let me share a few of the comments I heard.
What the Consultants are Saying
What’s ADMT’s performance compared to third-party tools?
Performance is similar—roughly 500 user objects per hour, and re-ACLing performance is acceptable. However, judging ADMT’s ability to perform a migration should be based 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 won’t 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 2.0.
What’s the complexity limit you’d recommend in choosing
to use ADMT v2?
A single-source domain with 10,000 users could be done in a single batch over a weekend. It’s possible that ADMT v2’s scripting and command-line interface could make it possible to do multiple batches and increase this.
What operations have you used ADMT v2 for?
We’ve used it to interactively to:
Migrate users.
Migrate user profiles.
Migrate workstations and Servers.
Re-ACL files and Exchange mailboxes.
Securely copy passwords.
Update user profiles in use (much improved over ADMT v1).
What’s your overall impression of ADMT v2?
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 took the time
to build the framework, ADMT v2 could be enterprise-capable—assuming your
environment is simple enough.
| Additional
Information |
The following Microsoft resources consist
of Knowledge Base articles and release notes that come
with the ADMT download.
Download ADMT v2 from http://www.
microsoft. com/windowsserver 2003/ downloads/default.mspx#ToolsAddins.
Go down in the list to Tools and Add-ins and you’ll
find the link there. The file comes in at slightly under
a 5MB.
326480: “How to Use Active Directory Migration Tool
Version 2 to Migrate from Windows 2000 to Windows Server
2003.”
325851: “How To: Set Up ADMT for a Windows NT 4.0-to-Windows
Server 2003 Migration.”
322981: “How to Troubleshoot Inter-Forest Password Migration
with ADMT v2.”
260871: “How to Set Up ADMT for Windows NT 4.0 to Windows
2000 Migration.”
Readme.txt file that comes with the download. |
|
|
The bottom line: ADMT v2 is significantly better than v1, and although
it’s not at the level of the third-party offerings available, it does
have its place. Best of all, it’s free! If you have a limited migration—a
single domain, about 10,000 users, that you could accomplish in a weekend—it’ll
work fine. It’s also useful for maintenance operations such as moving
users, groups and computers between domains. It still has some limitations;
but if you keep it within its realm, you can save some money.