Convincing Everyone
If you suggest to your colleagues that your company rename a domain, expect the response "No way." When I first raised the idea to my manager, an experienced NT engineer, I heard those words. Members of our IS group, other managers, and some of our more savvy users echoed the reaction. However, when those doubters compared the renaming procedure's advantages with the alternative of creating a new domain and moving all user accounts to the domain, they found good reason to take a second, open-minded look at the proposal. I used Table 1 to compare our IS department's choices. The factors that Table 1 lists justified renaming the domain to our data security department, which performed much of the migration's groundwork.
Another advantage of renaming the master domain was the process' seamless effect on NT workstations. About 200 workstations ran NT in our resource domains; those machines didn't require manual intervention because the mechanism that links NT workstations to a domain and through the domain to other trusted domains uses SIDs, not names. After we renamed the master domain, NT automatically updated the drop-down list of logon domains on our resource domains' NT workstations.
Despite the advantages of renaming a domain, you must perform a few of the process' tasks manually. You must re-create the domain's trust relationships, change the default domain in users' logon boxes, and edit your service accounts. My department discovered that service accounts are a notable exception to NT's standard use of SIDs. NT stores accounts that services use to log on to the system as text entries in each server's Registry. As a result, service accounts don't automatically change to reflect a domain's new name. Fortunately, most NT services use the server's System account, so we had to change service accounts' text files on only a handful of systems. Before renaming CHQ_COD_PROD, we ran Server Manager on all our production NT servers, looking for services that used an account in CHQ_COD_PROD, and noted those that needed attention during the name-change process.
Staff Concerns
Because of the preponderance of reasons for renaming St. Paul Fire and Marine's master domain, our technical planning team quickly geared up for the name change. We acknowledged, however, that the domain renaming process had drawbacks.
One common concern was that the process might fail insidiously. For example, if the master domain's SAM database became corrupt, the problem might not be fully apparent until users had worked in the renamed domain for a day or two. In addition, if NT security became corrupt after we renamed the master domain, we would have trouble undoing the name change. Changing the domain's name back to CHQ_COD_PROD might not repair whatever damage the initial name change caused in the SAM database.
The aspect of the renaming procedure that generated the most concern was that the process involves a sudden, networkwide change. As Brad TerEick, manager of our ENS department, observed, St. Paul Fire and Marine had never implemented a procedure that affected all 8000 of our users in 1 day. Unlike migrating to a new domain, renaming a domain doesn't permit the tried-and-true practice of operating new and old systems simultaneously. Renaming a master domain is an all-or-nothing process, not a project for the timid.
Finally, our research revealed that renaming a domain isn't always formulaic in environments that use Microsoft's BackOffice products. We discovered several problems during the CHQ_COD_PROD renaming. For more information about the problems BackOffice causes and the methods for resolving them, see Sean Daily, "How to Rename Your NT Domain," page 113.
Testing, Planning, and Preparing
After we determined that we wanted to rename the company's master domain, we set three primary goals that we wanted to accomplish before the renaming. We wanted to verify that the process worked, determine a way to change nearly 8000 Windows workstations' logon prompts to reflect the new master domain name, and devise a means for undoing the change in case a rollback became necessary. In addition, assuming we wouldn't encounter any roadblocks, we needed to notify affected users and construct a full conversion plan.
Register
