Making the Active Directory Leap

Windows Server 2000 support ended in mid-July, leaving more than a few Active Directory domains running on unsupported servers.

In a situation that mirrors the scenario affecting many agencies, I worked with a school system with 65 domains (one for each location) to address the end-of-support hammer for Server 2000. The school system migrated to Server 2008, slimming down to a single domain in the process.

Here are three tips to help you prepare for such a migration.

Tip 1: Calculating Dollars and Sense

Start with a budget. Microsoft provides a free tool, the Active Directory Migration Tool. ADMT is currently in Version 3.2. There are a variety of tools on the market too, and a solid option is Quest Software’s Migration Manager for Active Directory.

Other than the simple fact that one tool is free and the other has a fee, they both work well. Granted, Quest offers better reporting, excellent support and handholding through the process and easier rollback of migration operations. Early versions of ADMT barely worked in a lab environment, but the current version exceeded my expectations and was the tool we used for the school system migration.

You need to look at both your needs and your budget, so that you can choose appropriately.

Tip 2: Setting the Scope

Once we decided to forge ahead with ADMT, the next part of the process was to take its extensive guide, which runs hundreds of pages, and whittle it down to a much smaller document that would apply to the environment at hand.

For starters, the guide includes both intra-forest and inter-forest moves. Intra-forest moves are performed between domains within the same forest and typically relate to a cleanup or restructuring of an existing domain structure. In my scenario, we were going with an inter-forest move because we were consolidating domains. That’s the type of refocusing of scope that you will want to do before the migration begins because it will keep the project moving.

Tip 3: Establishing a Benchmark Migration

Use the first domain to define the process for all the domains to follow. As you begin your migration process on the first domain, document every wall you hit and every fix you design. I use a research-fix-proceed process for each failure. It’s extremely important to perform a test migration of every aspect of your move before you migrate production workstations, users, profiles, groups or servers.

With our inter-forest migration, for instance, we had to create a cross-forest trust relationship and turn off security-identifier filtering so that accounts could continue to access resources in the old domains during a period of coexistence until the servers had been migrated. After we had the prerequisite configuration in place and had tested the ability to move objects, we began moving in bulk for the first domain.

If one system migrates and another fails, you should note the differences between the two systems, attempt to determine what might have caused the failure, and then document those findings.