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.