Rechristen your network without wrecking it
What's in a name? Humans place a lot of importance on names we give the people, pets, and possessions in our lives, including our Windows NT networks. But sometimes—at least in the case of an NT domain—we might outgrow the label that seemed appropriate years ago. Why might you want to rename one of your company's Windows NT domains? Perhaps the administrator who installed NT on the domain's Primary Domain Controller (PDC) answered the domain name question hastily. Maybe your organization merged with another company or simply changed its name. Or perhaps you want to rename your domain in preparation for Windows 2000 (Win2K—formerly NT 5.0). For example, you might want to unify your network's Domain Name System (DNS) and Win2K domain names.
Another possibility is that the person who originally installed the OS (perhaps someone who has long since left the company) chose a name that was just plain silly. An NT 4.0 domain named BARNEY or NT3.1_DOMAIN will drive anyone buggy after a while. But you don't have to live with domain names you don't like. I've met many NT administrators who mistakenly believe that their NT domain name is written in stone. (For one such administrator's domain-renaming story, see Joe Rudich, "Same Domain, New Name," page 107.) Other administrators are convinced that trying to rename a domain would break every service on their network. But you can rename a domain without damaging your network.
Research Your Applications and Services
Successfully renaming a domain requires that you research, plan, and test your procedure before you change your production network. You can rename most NT domains without breaking services or reinstalling software. A few applications and services (such as certain versions of Microsoft Exchange Server and other BackOffice products) tie themselves directly to the NT domain name that they install under and might lose functionality if you rename their domain. To prepare for the possibility that some of the applications you're running won't easily accept a new domain name, you must research the topic of domain renaming with the vendor of every critical application running on your network. This step is crucial because the vendor might be able to provide tips based on prior experience that will save you time and effort and prevent headaches.
For many applications, this research will require you to call the application vendor's technical support department and ask, "Can this application survive a renaming of its NT domain?" In some cases, you might get immediate positive or negative responses. In other cases, you'll get answers along the lines of "We haven't tested that" or "I don't know, but I wouldn't try it." Don't get too discouraged if a vendor seems less than enthusiastic about the prospect of changing your domain name. The process might work even if the vendor tells you it flat-out won't work. I don't mean to suggest that you ignore what the vendor tells you, but take the company's advice with a grain of salt. I have found that many vendors that cast doubt on the success of renaming a domain are simply being conservative. Most haven't actually tested their applications for this change. The thought of being a guinea pig might not thrill you, but you have an excellent chance of success with most applications. For additional information about whether your procedure will work, search newsgroups and Web forums that relate to the application for FAQs on the subject.
Perform a Trial Run
After you complete your fact-finding mission, you're ready for the next
step—testing in a lab environment. The most important preparation for renaming your domain is performing the renaming procedure on a test network that emulates your production environment as closely as possible. Lab networks that emulate one-domain environments need at least one PDC and one Backup Domain Controller (BDC), and they need to run all the network's important applications. For multiple-domain environments, I recommend a lab network that contains at least one PDC and one BDC for each of the network's domains and re-creates all trust relationships exactly as they exist on the production network. After you set up your test network's domain controllers, set up a test workstation for each client desktop platform that your network supports (e.g., NT Workstation, Windows 98, Win95, Windows 3.x, MS-DOS). Install on each lab workstation all the important applications that your network runs on the workstation's OS. To quickly implement this kind of lab environment, restore backups of production machines to test machines or use drive-imaging software to directly copy drive information from production systems to lab machines. You can create the environment with fresh installations, but this method doesn't emulate your production environment as closely as copying production machines' drives does.
After you construct your lab, run a test of the domain-renaming procedure to see what, if anything, breaks. This test will give you practice following the renaming procedure's steps in the correct order and in the correct manner, which is essential to the success of the renaming operation. Although changing the domain name on your network involves few steps, you must perform those steps in a definite order and follow a set of rules to avoid problems along the way.