Networking

Get IT Done: Change the name of your domain with minimal complications

Tips for changing an enterprise domain name


When you think of a Windows 2000 or a Windows NT domain in a production environment, you tend to think of a fairly permanent structure. However, I’ve seen too many situations over the years in which a company hires a new IT director or is bought by another company, and the new person in charge wants to start making changes to the network.

Some of the most common of these changes are naming conventions. Changing things like user names or printer names can be time consuming on a large network, but from a logistical standpoint it isn't a complex task. But changing domain names represents a serious challenge. In this Daily Drill Down, I’ll explain how to go about properly changing a Windows 2000 and a Windows NT domain name.

Renaming successfully requires careful prep work
Renaming a domain is no small undertaking. Unfortunately, there’s also no specific set of instructions that’s valid for all domain renames. The key to a successful domain renaming is to take the time to do all of the necessary prep work and to fully understand what areas will be affected when you rename the domain.

Perhaps the best way that you can plan for renaming your domain is to use some spare hardware to build a test lab. The lab environment should be completely isolated from the production network so as to avoid damaging production servers. I recommend loading backups of key servers onto the test hardware. Some of the machines that you might include in the tests include domain controllers, DNS and WINS servers, mail servers, database servers, and a couple of workstations. You might even simulate domain controllers from another domain, just so you can see how trust relationships are affected by the domain renaming.

Although setting up a large-scale test environment may sound like a lot of work, I believe that it’s well worth the effort. Having a test environment gives you the chance to see what types of problems that you’ll run into and to figure out how to fix those problems without all of the stress associated with working with production machines. Likewise, if something goes horribly wrong in the test environment and the domain is beyond repair, you’ve just avoided a major disaster with a production domain.

The next thing that you should do is to create a full system backup of every server involved in the domain renaming process. By doing so, you have a way of undoing any damage that might occur if the domain renaming process should go wrong.

Create a spare Backup Domain Controller (BDC)
When preparing for the actual domain renaming, you should create a Windows NT BDC, and then physically unplug it from the network. You’ll use this domain controller as a backup in case something goes wrong. If there’s a big problem with the renaming process and you need to revert back to your original domain name, the domain controller that you’ve taken offline will contain all of the SAM information necessary for reconstructing the domain.

Before you remove this server from your network, be sure that all SAM information has synchronized between the other domain controllers and your spare domain controller. You can force a SAM synchronization by entering the NET ACCOUNTS /SYNC command at a command prompt on your BDC. When the synchronization completes, there will be a message in the event log indicating that a successful synchronization occurred.

Later in this article, I talk about creating another Windows NT BDC. These are two different servers with two different purposes, and you must not confuse the two. Once you remove your backup BDC from the network, you won’t be using it again except in an emergency.

Prepare DNS lookup zones
As you probably know, Windows 2000 domain controllers use the Active Directory, and Active Directory is completely dependent on DNS. So before you rename a Windows 2000 domain, you must create the necessary DNS lookup zones that will support the new domain. There are also situations in which you'll need to create DNS zones or records within a Windows NT domain, such as when you’re creating an intranet for your organization. Whatever DNS action is required in your organization, it’s important to remember that after the renaming is complete, you must delete any invalid DNS entries.

Dealing with child domains
One issue that can really complicate the process of renaming domains is the existence of one or more child domains beneath the domain that you’re renaming. A child domain must be renamed prior to renaming its parent. Unfortunately, you can’t initially assign the child domain its permanent name. Because, by definition, a child domain exists within a parent domain, you can’t give it a final name unless the new parent domain exists. And you can’t rename the parent domain because it still contains child domains. So you must first empty the parent domain by giving all child domains temporary names. After you rename the parent domain to its new name, you can then rename the child domains and place them back inside the parent domain.

For example, imagine that you had a domain named A.COM that you wanted to rename to B.COM. Now imagine that A.COM had a child domain named C.A.COM. You couldn’t just rename C.A.COM to C.B.COM because B.COM doesn’t exist yet. So you’d have to rename C.A.COM to something like D.COM until you renamed A.COM to B.COM. Only then could you rename D.COM to C.B.COM.

As if keeping track of all of the various domain names weren’t complex enough, you must make DNS modifications every step of the way. There also may be more than one child beneath a parent or there could be grandchildren or great-grandchildren. Having child domains can cause some confusion, and so the process of renaming a domain when children are involved must be planned carefully.

Trust relationship considerations
Another step that you must take prior to renaming a domain is to consider the existing trust relationships within the domain and how the renaming operation will affect these relationships. Keep in mind that a domain’s name affects its position in the domain hierarchy. When it comes to renaming and repositioning domain names, you must remember that the root domain is a special situation. Although you can change the name of the root domain, you can’t change it in a way that would place it at a different location within the domain structure. The root domain must always remain the root domain.

In Windows 2000, every domain within a forest has a transitive trust relationship with the domain above it and the domain below it. However, if you change the domain structure by renaming a domain, all of the trust relationships will be thrown out of whack because trusts will point to domains that no longer exist. For example, if you have a root domain called A, a child domain called B, and a grandchild domain called C, there’s a transitive trust relationship between A and B and between B and C. A and C trust each other, but do so indirectly. There’s no direct trust relationship between A and C. Instead, the trusts with B make A trust C. If you happen to move B to another place in the organization, then B and C will both be completely cut off. A will no longer trust B because B’s name has changed and A is unaware of the change. Likewise, C won’t know B’s new name and therefore will no longer trust B. A and C won’t trust each other because their trust relationship was based on B, which no longer exists.

Shortcut trusts
This is where shortcut trusts come into play. Shortcut trusts are manually implemented trust relationships. Under normal circumstances, there is little reason for using shortcut trusts because all of the domains already trust each other through the various transitive trust relationships. However, if you will be moving domains, you must implement some shortcut trusts prior to moving or renaming domains to prevent any domains from being cut off.

When you implement shortcut trusts, you must create them where trust relationships would ordinarily be broken. In my previous example, I discussed moving domain B to another location in the organization, which would leave A and C both looking for B. In this situation, you must create a shortcut trust between A and C prior to the move to bridge the gap left by moving B. You must also create a transitive trust between B and its new parent. Otherwise, the parent won’t know that B even exists beneath it.

If you ever rename a domain in a way that causes it to become the start of a new domain tree, you must create a shortcut trust between the new domain name and the forest root domain. Although the concept of shortcut trusts is simple, it’s absolutely critical that you create the necessary shortcut trusts before moving a domain. I recommend sketching the domain structure before and after the planned renaming operation to see exactly which trusts will need to be created.

Although it doesn't use shortcut trusts, the same concept applies to Windows NT. In Windows NT, all trusts between domains are assigned manually. So before renaming a Windows NT domain, you must look at which domains are trusted by the domain you’re renaming and which machines trust the domain. After making a list of the trusts associated with the domain that you’re about to rename, you must break each trust and reestablish it with the new domain name.

Application and services considerations
Most of the core Windows services won’t be any big deal. However, many application-related services rely on a service account. Like any other account, the service account is based on a user name and a password. After renaming a domain, the service account will no longer exist within the domain in which the service is looking. So you’ll have to update the service control manager to have the service look for the service account in its new location. There’s also a possibility that you'll need to reset the service account passwords before they'll work properly.

Applications are an even bigger deal. Some applications, such as the various Microsoft BackOfffice Server products, are closely tied to the domain name. With such products, you can be assured that the product won’t work after the domain has been renamed. So you'll need to identify such products and determine the provisions for switching to a different domain name.

Some third-party products may instantly recognize the new domain name or may require a simple patch or procedure to be applied. Products like Exchange 2000 Server and SQL Server aren’t so simple. Although you can move such products to a new domain, the process is long and tedious.

For example, Exchange Server requires you to export all of the databases prior to renaming the domain. Once the domain has been renamed, you must reinstall Exchange from scratch. Only then can the mailboxes be imported into the new copy of Exchange. What further complicates things is that the procedure works differently depending on whether you’re using Exchange 5.5 or Exchange 2000.

Renaming a Windows NT domain
The procedure you’ll use for renaming a Windows NT domain differs depending on how many domain controllers you have. If you have only a single domain controller, the easiest method is to upgrade the domain controller to Windows 2000 and rename the domain during the upgrade process. If you decide to use the Windows 2000 upgrade method, just upgrade the server to Windows 2000 in the usual manner. When the upgrade is complete, the server will reboot and prompt you to begin the Active Directory installation. At this time, you can specify the new domain name.

If you have multiple Windows NT domain controllers or have some aversion to upgrading to Windows 2000, there’s another method that you can use for renaming the domain. Go to the Primary Domain Controller (PDC) and double click on Control Panel’s Network icon to display the Network Properties sheet. Click the Change button on the Properties sheet’s Identification tab to reveal the Identification Changes dialog box. Rename the domain in the space provided and click OK. Windows NT will display a warning message telling you of terrible things that can happen. Clear the warning and reboot the server. If you do anything else before rebooting, you risk corrupting the server.

Once the domain name has been changed on the PDC, it’s time to change the BDCs so that they are servicing the correct domain. The method of changing the BDC’s domain names is identical to that of changing the PDC’s domain. However, sometimes the BDCs tend to put up a fight. You may see a message indicating that a connection to the domain already exists and that you must break the connection before joining the new domain. There are a couple of ways to do this. I’ve sometimes been able to sever the connection by simply rebooting. If rebooting doesn’t work, you’ll have to use Server Manager to break any links to the domain by using the Users, Shares, and Resources buttons.

Renaming a Windows 2000 domain
The procedure for renaming a Windows 2000 domain actually builds on the process for renaming a Windows NT domain. The biggest issue that you’ll encounter when renaming a Windows 2000 domain is that it’s impossible to rename a domain that has been converted to native mode. Your domain must be running in mixed mode.

Unfortunately, Windows 2000 has no mechanism for renaming a domain. So you must rely on Windows NT to do the work. The actual procedure that you’ll use depends on how many Windows NT domain controllers exist within the domain. If there are presently no Windows NT domain controllers in your domain (not counting the spare that you made previously), you must use a spare PC to create a Windows NT BDC running Service Pack 6A. This machine must have sufficient resources to be upgraded later to Windows 2000. If you already have a single Windows NT BDC in your domain, you must decide whether it’s feasible to later upgrade the domain controller to Windows 2000.

Next, synchronize the domain information so that the Windows NT BDC has a full copy of the SAM by opening a command prompt on the Windows NT machine and entering the command NET ACCOUNTS /SYNC. When the process completes, you’ll see an event appear in the event log indicating that a successful, full replication occurred.

Then, run the DCPROMO command on all but one of your Windows 2000 domain controllers. In doing so, you must demote the domain controllers to member servers. When the process completes, verify that there is only one Windows 2000 domain controller remaining in the domain. When you’re absolutely sure there is only one, run DCPROMO on the last Windows 2000 domain controller. This time, you’re demoting the domain controller to a member server, and you’re selecting the Last Domain Controller In The Domain option. Make sure to select this option, because if you neglect to do so, you can really mess up your domain, and you’ll have no way to promote servers later.

Next, go to one of your Windows NT BDCs and open the Server Manager. Promote the BDC to the role of PDC. When you do, you’ll see a message stating that the PDC can’t be contacted and asking if you’re sure you want to promote the domain controller. Click Yes to complete the process.

There should be only Windows NT domain controllers in your domain. You can complete the renaming process just as if you were working in a purely Windows NT environment. The only difference is that after you’ve renamed the domain, you’ll join your Windows 2000 member servers—the ones that used to be domain controllers—to the new domain and then use the DCPROMO command to promote those servers back to their original domain controller status.

Cleaning up
As you saw from the section on preparation work at the beginning of the article, the physical act of renaming the domain is probably the simplest part of the entire process. Once the domain has been renamed, you'll need to do a lot of clean up work. It’s impossible for me to cover every situation that you may encounter, but some typical clean up chores that you may need to do include:
  • Going through the list of services to see which services rely on domain-dependent service accounts and making the necessary changes.
  • Resetting passwords.
  • Updating DNS and WINS entries.
  • Moving child domains.
  • Testing trust relationships.

Editor's Picks

Free Newsletters, In your Inbox