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.
Do Your Prep Work
After your testing, you must take a few important steps to ensure that you'll be able to recover from the renaming operation if anything goes wrong. The first thing you need to do is make sure you have very recent full backups of every server in the domain you're renaming. You also need to back up all PDCs and BDCs in domains that have trust relationships with the domain you're renaming.
Make an Emergency Repair Disk (ERD) for each server. Be sure to use the rdisk /s option when you run the utility to ensure that the ERD includes the domain's security information. In addition, I strongly recommend using regback, a utility in Microsoft Windows NT Server 4.0 Resource Kit and Microsoft Windows NT Workstation 4.0 Resource Kit, to make an uncompressed backup of the Registry. You can restore regback backups via the resource kit's regrest utility or by directly copying them while you're booted in a parallel installation of NT. (For more information about regback and regrest, see Bob Chronister, "Tricks and Traps," April 1998.)
Stopping all network traffic. You'll need to freeze all network activity for the duration of the domain renaming. Before beginning the procedure, you must take steps to stop network traffic. All client workstations must log off of the network, and I recommend that you pause the Server service so that no clients can make server connections after you begin the procedure. Make sure the Security Accounts Manager (SAM) database and Windows Internet Naming Service (WINS) are up to date. You can force SAM database synchronization via Server Manager and trigger WINS replication via WINS Manager.
Next, stop all services on computers in the domain you're renaming that use domain user accounts (rather than the System account or a local user account) as their logon account. Set all such services that have an Automatic startup type to Manual for the duration of the renaming process. This step is important because you will have to manually tweak these services' logon account settings after you rename the domain, and you won't want them to attempt to restart before you make the necessary changes. This step is especially important if you use Microsoft BackOffice applications including Exchange Server, Internet Information Server (IIS), Systems Management Server (SMS), and SQL Server. If you fail to set to Manual startup a service that uses a domain account to log on, the first time you reboot in the renamed domain, NT will greet you with the familiar message One or more services failed to load. In addition, leaving the startup type Automatic for a service that uses a domain logon account could result in corruption of the application or its databases during the first reboot of the renaming process. Although this type of problem is the exception rather than the rule, you need to be as thorough as you can when you scan through each server's list of services and set services with domain logon accounts to Manual.
Breaking up trusts is hard to do. Use Server Manager, Domain Monitor (in the resource kit—for more information, see Mark Minasi, "Browser Monitor and Domain Monitor," January 1999), or another tool to examine and document the trust relationships between the domain you're renaming and other domains. After you document your network's trust relationships and back up your systems, break all the trust relationships through which another domain trusts the domain you're renaming or through which the domain you're renaming trusts another domain. When you have successfully renamed the domain and verified the functionality of all the domain's services, you'll need to reestablish these trust relationships.
First Stop: The PDC
When you finish your prep work, you're ready to begin renaming. The procedure is similar to the procedure you use to implement an NT version upgrade. You start the renaming process on the PDC, then rename each BDC, and finally rename the domain's member servers and workstations.
On the PDC, change the domain name on the Identification tab of Control Panel's Network applet, as Screen 1 shows. NT will present you with the somewhat ominous warning that Screen 2 shows; the warning is a reminder that changing the domain name will temporarily break the PDC's connection with other domain members. After you click Yes to this message, NT will inform you that it requires a reboot to complete the procedure. Shut down the system immediately, and restart the machine. If you do anything else before this initial reboot, you risk causing data integrity problems on the system.
When the PDC comes back up, it will automatically be running as the PDC of the renamed domain. You need to change the now-incorrect service account information for all services that use domain user accounts to log on. Open Control Panel's Services applet. Select a service that logs on under a domain user account, and click Startup. In the Service dialog box that opens, the account will appear in the form DOMAIN\USER; DOMAIN is the domain's original name, and USER is the user account that the service used to log on before the name change. You need to change all these services to run under a user account with the new domain name. Ideally, NT would automatically update the service accounts when a domain name changes, but it doesn't. You must change the service accounts' domain manually.
Microsoft's meager documentation on domain renaming glosses over this step. This omission is unfortunate because you're likely to run into an undocumented bug when you attempt to change your services' logon accounts from their OLDDOMAIN\USER settings to their NEWDOMAIN\USER settings. When I experimented with this procedure, I discovered that NT almost always issues an error message after you choose the domain and account you want to configure the service to use and set the account's password. The message says that the domain account you entered doesn't exist. (I even got this message when I selected the new account from a live domain account list.) Screen 3 shows the error message.
Don't let this message make you nervous that something has gone terribly wrong; it seems to be a minor bug that you can easily circumvent. To get around the problem, temporarily set the problematic service's logon account to the System account and select OK to accept the change. Immediately click Startup to reopen the Service dialog box, and enter the correct user account in the renamed domain. This time, NT will accept the new domain name without presenting an error message. After you change the domain name for all the PDC's services that run under domain accounts and enter the appropriate passwords, test each service by starting it manually via the Services applet's Start button. If the service starts properly, you can safely set its startup type back to Automatic. (You'll want to make this change only for services that started automatically in the old domain, of course.) If you receive an error message during the service's startup, you'll need to research the problem and attempt to solve it. The best place to start researching service startup errors is Event Viewer; you'll probably find information about the service's problem in the System Log or Application Log. (For information about the effect on WINS of renaming a PDC's domain, see the sidebar "WINS and Domain Renaming," page 115.)
Next Up: BDCs
When your PDC and all its important services are running, you're ready for your BDCs to join the fray. Change each BDC's domain name via Control Panel's Network applet in the same way you changed the PDC's domain name, and immediately restart each server. The WINS database represents BDCs with a <1CH> rather than a <1BH> designation; these entries will automatically appear in WINS after the BDCs reboot.
Unlike PDCs, which accept new domain names unquestioningly, BDCs sometimes complain about changing their domain names. You might see an error message similar to the one Screen 4 shows. These error messages occur when the BDC has open connections to the PDC, which makes the BDC unable to change its domain name context. You can try to get around this problem using Server Manager's Users, Shares, and Resources buttons to close all open connections between the BDC and PDC, then trying the domain-renaming operation again. If the message persists (as it did on one of my BDCs), you might have to reboot the server and reattempt the renaming operation after the server comes back up. Reboot the server only as a last-ditch effort on a stubborn BDC that won't let you change the domain name any other way.
The rest of the BDC renaming process is identical to the PDC renaming process. You must change service logon accounts, reset passwords, and restart and test services. When you feel confident that all the BDCs and their services are working properly, use Server Manager's Synchronize Entire Domain function. Reestablish all your trust relationships between the renamed domain and other domains. You might also want to use a utility (such as Domain Monitor) to verify that all your trusts are working properly. Your final step in renaming your domain controllers is to make a new set of ERDs (or Registry backups); label them something like Post-Renaming. Creating this second set of ERDs will give you one set that predates the renaming and one that reflects the Registry after the process finishes. These ERDs will come in handy if unexpected problems force you to return quickly to your previous configuration.
Last Stop: Member Servers and Workstations
After you complete the renaming process on all your domain controllers and reestablish the domain's trust relationships, you're ready to begin configuring your member NT servers and client workstations in the renamed domain. (If you administer a large network and want to perform these tasks remotely, see the sidebar, "Utilities to the Rescue.") The process of renaming the domain on NT workstations and servers is similar to renaming BDCs. You might receive an error message when you attempt to rename the domain on member servers and workstations. If you get such an error message, solve this problem the same way you solved it on the BDCs—close all resources and reboot if necessary. Most NT workstations and member servers accept new domain names without incident, but you can remove a workstation or server from the domain and change the computer's domain name a second time if you need to. Like PDCs and BDCs, other NT machines warn you before they let you change their domain name.
For Win98, Win95, and other lower-level client OSs, you need to change the workgroup name and the Log on to Windows NT Domain setting on the General tab of the Client for Microsoft Networks Properties page, which you access through the Configuration tab of Control Panel's Network applet. These changes ignore the active state of the machine and its network connections (e.g., active or open resource connections) and usually pose no problems. However, I highly recommend that you exit all Win98 or Win95 applications before making these configuration changes. When you finish changing your clients' domain names, you'll be the proud owner of a fully renamed network.
Gotchas
If this process sounds less intimidating than you expected, then I suppose I'm doing my job. However, before you start renaming domains, you need to be aware of a few gotchas that sometimes arise during this process. I have one general tip relating to pure TCP/IP networks that use WINS: If you have trouble getting a server or workstation to join a domain after you rename the domain on the PDC (perhaps because of corruption or other WINS weirdness) and exhaust all other possibilities, you might try temporarily setting up an LMHOSTS file with the required <1BH> entry for the PDC. This file will act as a crutch to get you connected to the PDC and the renamed domain. After you fix your WINS problems, you won't need the LMHOSTS file.
You might also encounter one of several gotchas that are specific to Microsoft BackOffice applications. Exchange administrators need to change the default domain field in Exchange Administrator's Tools, Options menu to reflect the new domain name; Screen 5, page 116, shows this dialog box. Exchange administrators must also be aware during domain renaming that Exchange Server loses public folder permissions during the renaming process. To preserve public folder permissions so that you can later restore them, you can use the pfadmin.exe utility in the Microsoft Exchange Resource Kit and the Microsoft BackOffice Resource Kit.
SQL Server administrators need to change the default domain setting in SQL Security Manager. You also need to verify that all SQL Server users and groups are members of the default domain and add them to the renamed domain if they use the original domain name after the renaming.
IIS administrators need to check their anonymous authentication account and their virtual roots in Internet Service Manager (ISM) to verify that no error conditions exist. If your system has virtual roots that use domain user account security, you'll need to change them to reflect the new domain name.
SMS administrators need to be aware that SMS is more heavily tied to its NT domain name than are most of its BackOffice siblings. If you have primary or secondary SMS sites within the domain you're renaming, you need to plan on uninstalling SMS prior to the domain name change and then reinstalling SMS after the change is complete. However, if you have no primary or secondary sites, you can simply remove the domain from the site prior to the change, and add the domain back to the site after you rename the domain. (For more information about renaming a domain in SMS, see Chapter 3 of the SMS Installation and Configuration documentation.)
Finally, I have advice for Microsoft Proxy Server and IIS administrators: If you've ever manually specified a default logon domain in the Registry of your IIS and Proxy Server machine, you need to change the default logon domain after you rename the domain. The DefaultLogonDomain key of type REG_SZ in the Registry hive HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters specifies the logon domain that Proxy Server uses to authenticate users' clear-text logons to the IIS and Proxy Server machine when the user doesn't specify a domain name in the Username text box. This key doesn't exist by default, but if it exists on your Proxy Server machine, you need to change this value to the new domain name after you rename your domain.
Although the average domain rarely needs renaming, the process is necessary when your company faces major events such as organizational changes or network restructuring. Remember when you undertake the domain-renaming process to be careful and conservative and to follow all the preparatory steps I outlined. Proper preparation will help you avoid unnecessary network downtime and costs. I've highlighted the key concepts that changing a domain's name involves and the steps you can take to ensure that the process is as smooth as possible. If you follow these instructions closely, the transition to your new domain name will be fairly painless.
