Do make sure that your support staff is brought up to speed before you begin migrating any production system. Depending on the size and structure of your organization, you should have a help desk staff taking support calls. For a complex project like Active Directory, it's a good idea to make a couple of network engineers available as well. Be sure to train all members of the support staff involved in the process. Otherwise, you'll have IT staff fielding questions that they don't know how to answer, and frustration will abound on all sides.
Do establish a test bed that mimics your production environment as closely as possible in terms of hardware specifications and network speed. Leave nothing to chance in the testing phase.
Don't automatically make the assumption that everything will function without any problems post-upgrade. All applications and processes need to be tested, tested and tested again.
Don't forget about any down-level clients that you may still be supporting. Windows 2000 and XP clients can use pure DNS for name resolution, but Windows
Don't overlook migration tools offered by Redmond when planning and performing your Active Directory upgrade. Sysprep will allow you to create Windows 2000 disk images for automated client rollouts, and the Active Directory Migration Tool (ADMT) is entirely useful in restructuring your NT4 domains (especially in a multi-domain model) into a viable Windows 2000 AD structure. See http://www.microsoft.com/windows2000/downloads/tools/admt/default.asp for more information and detailed instructions. Though I found that ADMT more than did the trick in my case, depending on the complexity of your configuration, you may want to examine third-party migration tools offered by NetIQ, BindView and others.
Do test name resolution and replication before deploying Active Directory in production. Unlike replication under NT4, Active Directory replication not only works but is possibly the single most important item required for AD to function correctly. Second only to file replication for a happy AD implementation is name resolution. Whether you are deploying WINS or DNS, ensure that all systems that need to can effectively talk to one another. Neglect these functions at your own peril!
Don't deploy group policy objects without fully understanding their implications. In some ways, Microsoft does not protect you from yourself when applying GPO settings; as a result, you could very easily render portions (or even the whole) of your network inaccessible and unusable.
Don't assume that your production PDC must necessarily be the first machine to be upgraded. Since Windows 2000 uses a multi-master role in which all controllers are essentially equal, you can bring a completely different machine online in your NT4 network, promote it to the PDC role, then use that machine to perform the AD upgrade. This flexibility will allow you to perform the upgrade with a minimum of exposure to your production servers.
Do take an NT4 BDC offline before beginning the upgrade. (As described in the item above, you can easily build one from scratch.) If you need to roll back to NT4, demote the Windows 2000 controllers, then boot the "spare" BDC and promote it to the PDC role. This will allow the NT4 directory and domain information to repopulate itself within your network.
Don't leave your users out of the loop during this process. Even though the Active Directory process can be largely transparent to end users, ensure that they are aware of any timelines and scheduled downtime that might affect their workday. This is especially important if you are not migrating client operating systems at the same time.
The most important "do" in implementing Active Directory is: do remember to plan. Similarly, the most important "don't" is: don't forget to plan. Though I'm sure you're eager to jump in and start playing with all the new features offered by Windows 2000 and Active Directory, make sure that there's water in that pool before you go headfirst off of the diving board. The late nights you save could be your own.
About the author: Laura Hunter has spent many years working in the trenches of network design, administration and user support and has earned a myriad of vendor certifications, including MCSE, CNE and CCNA. She is presently a senior systems analyst for a major American university.
This was first published in February 2003