Same Domain, New Name

The plan to rename CHQ_COD_PROD reached a crucial juncture when, 5 weeks before the planned date for the change, we tested the basic procedure. We were fortunate to have a server lab for Year 2000 (Y2K) compatibility testing that simulates our NT domain and workstation environment. The Y2K lab includes only 14 NT servers, but those servers duplicate key domains, infrastructure, and NT-based applications, including the Microsoft products SNA Server, SQL Server, Internet Information Server (IIS), and Proxy Server; Lotus Notes; Windows Internet Naming Service (WINS); Domain Name System (DNS); and Dynamic Host Configuration Protocol (DHCP). The number of servers in the lab is far fewer than the number of machines in our production environment, but the lab includes all our active user accounts and groups—more than 10,000 objects. We followed Microsoft's procedures to change the name of the lab network's version of CHQ_COD_PROD to SFM. This initial test worked without a hitch, and it took only about 20 minutes. Many of the test network's CHQ_COD_PROD accounts and groups had permissions within resource domains, and all those permissions remained intact after the renaming. The test boosted our confidence tremendously.

Another key to feeling comfortable about renaming the domain was holding regular conferences, not only among the network administrators who performed the renaming procedure but also among Help desk and client/server application support staff. We also used our intranet and email to notify all our NT users that the renaming was approaching. Our final step to ensure the support staff's peace of mind was arranging a schedule for testing workstations and applications after we completed the name change but before most users came to work.

We considered several options for altering the logon box's default domain name on Windows 95 and Windows 3.1 workstations, including using logon scripts and system policies. We even considered an intricate scheme that would use our software distribution system to pass out a time-activated batch file, but we recoiled at the thought of how difficult removing that change might be. Eventually, we settled on an almost laughably simple method. We gave users instructions that explained that when they reached their system's network logon box the day after our name change, they needed to fill in their username and password as usual, but then tab to the next field, Login From, and replace CHQ_COD_PROD with SFM. Our Help desk, which had to deal with user confusion, chose this method and suggested that we perform the domain renaming on a weeknight to keep these instructions fresh in users' minds.

Finding a way to reverse the procedure if unexpected problems occurred was another technical challenge. After quickly rejecting the idea that we could simply change the domain's name back to CHQ_COD_PROD, we set up a new BDC for CHQ_COD_PROD. Just before the renaming, we synchronized this BDC with the domain, then shut it down and set it aside. If we needed to reverse the domain renaming process, we had the option of shutting down the corrupt SFM servers, restarting this BDC as the PDC for CHQ_COD_PROD, and rebuilding the original master domain from it. With these pieces in place, we set the date of the domain renaming to Tuesday, July 14, 1998.

D-Day
After months of preparation, renaming the master domain was almost anticlimactic. During the day of July 14, we coordinated the people who were taking part in the procedure, but we didn't begin renaming the domain until 7:00 p.m. We finished our changes to the server around 11:15 p.m., and we finished testing the renamed domain by 1:45 a.m.

We followed Microsoft's prescribed process carefully, maintaining open telephone connections between the two sites that contained CHQ_COD_PROD domain controllers. At Microsoft's suggestion, we frequently forced WINS replication to ensure that NT propagated our new server entries throughout the network. This cautious attitude paid off. During the 2 days that followed the domain renaming, our Help desk recorded fewer than 150 support calls regarding the name change, almost all of which related to user errors entering the new domain name. When the dust settled, our new SFM master domain was ready to merge with USF&G's domain.

The process of renaming a master domain gives experienced NT administrators pause, with good reason. Don't alter domains without considering the change carefully and using caution. The process of renaming St. Paul Fire and Marine's master domain involved a lot of planning and hands-on support, but we justified that effort by eliminating slow, manual tasks that might have delayed our domain merger.

End of Article

   Previous  1  2  3  [4]  Next