Same Domain, New Name

When I was new to Windows NT, I learned that all server changes fall on a hierarchy of difficulty. My teachers drummed into my mind that any change that challenges the order of NT domains is on the most difficult end of the spectrum. They told me that domain controllers can change roles or move to a different domain through either an act of God or a reinstallation of the OS—and that the former solution was usually easier to justify than the latter. As I worked with the OS and eventually taught NT classes, I passed this commandment on to other systems administrators: After you set up a Primary Domain Controller (PDC) or a Backup Domain Controller (BDC), don't try to change its role or its domain. If you try to change a domain controller, I explained, you'll suffer through countless network conflicts and corrupt Security Accounts Manager (SAM) databases.

Considering domain configuration immutable isn't always comfortable. I've seen many NT servers that administrators installed as BDCs then wanted to change to be standalone members of the domain. I've seen other cases in which administrators wanted to remove a BDC from one domain and establish a new domain on the server. And frequently, I've wanted to change the name of an existing domain.

I always assumed that the three tasks were equally difficult, and I know a number of experienced NT administrators who agreed with me. I recently discovered, however, that I was wrong about one of these situations. You can't easily change domain controllers into standalone servers or split domains in two, but you can rename a domain, even a master domain that contains thousands of user accounts and that multiple resource domains trust.

Why Bother?
My employer, St. Paul Fire and Marine Insurance, is the eighth-largest property and casualty insurance company in the world; corporate headquarters are in St. Paul, Minnesota. A year ago, St. Paul Fire and Marine was the world's fourteenth-largest property and casualty insurer, but in April 1998, the company purchased Baltimore, Maryland-based USF&G. The corporations' merger nearly doubled the number of employees and IS resources that my department is responsible for. Each company maintained more than 100 production NT servers before the merger.

Among the many tasks my department performed to integrate the two organizations was reconciling the companies' NT domain structures, which held accounts for all the companies' PC users. The companies agreed to consolidate systems administration and data security functions in St. Paul, so the IS department decided to create a single master domain structure to serve the new organization's 12,000 users.

Of the two companies' domains, St. Paul Fire and Marine's master domain contained the most user accounts. All of St. Paul Fire and Marine's more than 8000 user accounts resided within the company's master domain. Most of the company's NT servers were members of one of 21 resource domains that trusted the master domain. Six standalone servers were members of the master domain, and three BDCs served as the master domain's Remote Access Service (RAS) servers. Of the five domain controllers in the master domain, two (including the PDC) ran NT Server 4.0 with Service Pack 3 (SP3), and three ran NT Server 3.51 with Service Pack 5 (SP5).

For reasons my colleagues and I forgot long ago, the master domain had the name CHQ_COD_PROD. Needless to say, this name didn't reflect the master domain's role in the merged company's NT structure, and it was a bit ugly. In addition, the name CHQ_COD_PROD was a time bomb waiting until the company converts to Windows 2000 (Win2K—formerly NT 5.0) to explode. The Win2K naming structure complies with the X.400 standard, which does not permit use of the underscore character (_).

   Previous  [1]  2  3  4  Next