If you’ve ever tried to rename a Windows 2000 domain, you know that the process is complicated in mixed mode and impossible in native mode. Microsoft has resolved this issue in Windows.NET, the next Windows server operating system, by creating a utility called RenDom.

While this tool is a big step in the right direction, it does require a substantial amount of preparation before use. Renaming a domain is a very messy procedure, and you can destroy your network if the procedure is performed incorrectly. I’ll discuss all of the preparation that is required prior to renaming a domain with the RenDom tool.

Raising the forest functionality level
If you’ve ever worked with Windows 2000, you probably know the difference between a mixed mode and a native mode domain. Windows.NET carries this concept a bit further with something called the forest functionality level. The forest functionality level is sort of like running an entire Active Directory forest in native mode. Microsoft refers to running .NET Server in forest functionality mode as ”raising the forest functionality level” of .NET Server. You can’t raise the forest functionality level unless every domain controller in the entire forest is running Windows.NET Standard Server, Windows.NET Enterprise Server, or Windows.NET Datacenter Server.

Raising the forest functionality level is a prerequisite to renaming a domain. To raise the forest functionality level, open Active Directory Domains And Trusts. Next, right-click on Active Directory Domains And Trusts and then select Raise Forest Functional Level from the resulting context menu. Now, click OK twice to initiate the operation. As with moving Windows 2000 Server to Native Mode, raising .NET’s forest functionality is a one-way street. You can’t go back.

Organizing the trust relationships
Next, you need to get a handle on the existing trust relationships within the domain and how the renaming operation will affect these trust relationships. As with Windows 2000, Windows.NET uses the concept of root, parent, and child domains. Keep in mind that renaming these types of domains can alter the domain’s place within the organizational hierarchy.

For example, let’s assume that in your organization tpgtpg.com is the root domain. Test.tpgtpg.com and production.tpgtpg.com are child domains of the parent (and in this case root), domain tpgtpg.com. If I were to rename the domain test.tpgtpg.com to test.production.tpgtpg.com, the test domain would become a child domain of production.tpgtpg.com rather than being a child of the root domain. Obviously, such a move wouldn’t make sense in this case, but there are situations in which you might want to make a domain a parent or a child of another domain.

As you may recall from 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, it will throw all of the trust relationships 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 even though 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 somewhere else in the organization, B and C will both completely be 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.

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’ll be moving domains, you must implement some shortcut trusts prior to 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 in order 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 renaming a domain. I recommend sketching the domain structure before and after the planned renaming operation to see exactly which trusts will have to be created.

DNS server preparation
As you may recall from Windows 2000, Active Directory is highly dependant on a DNS Server. Although there are several different ways of configuring a DNS server to work with Active Directory, a DNS server is usually configured so that there is a separate look-up zone for each domain. Within each of these zones are SRV resource records for each domain controller within the domain. Without these DNS records, it’s impossible to access the domain controllers with a fully qualified domain name or by any other method other than an IP address (assuming that the network is pure TCP/IP).

Because Active Directory can’t function without DNS access, Microsoft recommends that you manually create DNS zones for the new domain names prior to renaming the domains. Once you’ve created the new DNS zones, be sure to configure the new zones to allow dynamic updates. You can accomplish this within the DNS console by right-clicking on the new zone and selecting the Properties command from the resulting context menu to reveal the zone’s properties sheet. The properties sheet’s General tab contains an Allow Dynamic Update drop-down list. Select either Yes or Only Secure Updates from this list and click OK.

When discussing DNS updates as they relate to renaming domains, it’s easy to only think of domain controllers and to forget about member servers and workstations. However, both member servers and workstations are affected by a domain name change, because member servers and workstations have fully qualified domain names that are based on the domain name. When the domain name changes, the fully qualified domain name must also change to reflect these changes.

Normally, the change should be automatic. However, it is possible to block a domain suffix change on a workstation or member server via the Control Panel, the registry, or a group policy. Therefore, you should spot-check your member servers and some of your workstations to verify that a suffix change is permitted.

To see if a suffix change is allowed, begin by opening the Control Panel and double-clicking on the System icon. You’ll see the System Properties sheet appear. Select the Computer Name tab, click the Change button, and click the More button. You’ll see the DNS Suffix and NetBIOS Computer Name dialog box. Verify that the Change Primary DNS Suffix When Domain Membership Changes check box is selected.

Now, it’s time to check the registry. To do so, open the Registry Editor and navigate to:

Now, check for the existence of a registry key called SyncDomainWithMembership. If this registry key exists, its value should be set to 0x1.

Finally, you must see if a group policy prevents a DNS suffix change. Open a Command Prompt window. Next, enter the command GPRESULT. The command will display lots of information relating to the way that group policies have been applied.

Look under the Applied Group Policy Objects heading for the words Primary DNS Suffix. If Primary DNS Suffix isn’t on the list, you’re in good shape. Otherwise, your group policy is blocking a suffix change, and that portion of the group policy needs to be disabled. Check the Daily Drill Down “Working with Windows 2000 group policies” for more information on making changes to group policies.

Preparing your certificate authorities
Renaming a domain can cause problems for certificate servers if you don’t prepare them before the renaming. First, you must make sure that your certificate services are running on a Windows.NET-based server and that the certificate server is not a domain controller. Until your certificate server meets these two conditions, don’t even think about trying to rename a domain.

Once you’ve verified that your certificate server meets the requirements outlined above, you must verify that the certificate authority isn’t configured to use only LDAP-based URLs for its authority information access (AIA) or CRL distribution point (CDP). Remember that the old LDAP extensions will be invalid after a domain has been renamed, which means that any previously issued certificates will also be invalid. You must also verify that your certificate authority isn’t configured to use RFC 822-type e-mail names. If these e-mail names are used, they will be incorrect after the domain name change, and therefore previously issued certificates will be invalid. Finally, you must make sure that your certificate server isn’t configured to rely on other certificate servers in a manner that will be affected by a domain name change.

Once you’ve verified that your certificate authorities are in good shape for the domain name change, a couple of housekeeping chores need to be performed. First, update any URLs with the new certificate authority locations. Rather than removing the original locations, simply append the new location. This won’t have any effect initially, but it will allow the certificate authority to be accessed by the URL after the domain name change. Of course, you’ll only have to do this if the certificate server exists within the domain that’s being renamed.

Finally, just prior to the domain renaming, go through your certificates that have been issued to verify that none of them expire any time soon. If any of the certificates are going to expire soon, you should renew the certificates. Likewise, you should set an appropriate validity period for the certificate revocation list. Once you’ve done so, be sure to give your changes time to propagate throughout the network before proceeding with the domain rename.

Dealing with redirected folders
Windows 2000 and Windows.NET both support folder redirection. Typically, folder redirection consists of pointing the My Documents folder to a network share point rather than to the local hard disk. The idea is that by doing so, user’s documents can be backed up regularly, and often the user is none the wiser as to the actual location. The only problem with folder redirections is that they are often distributed file system (DFS)-based.

A DFS is a logical structure that combines various physical hard disk partitions (usually on different servers) into a single logical partition. The idea is that users don’t have to figure out what partition their files are on because they only see a single partition. When users access a DFS path, they do so by using \\domain_name\DFS.

Because the DFS location is domain name-based, changing the domain name makes the DFS location invalid and, consequently, the users lose access to their files. The same concept also applies to home directories and roaming profiles that exist on a DFS. If the domain name of the underlying system changes, users will lose access to their home directories and their roaming profiles.

The easiest way to fix this problem is to bring a spare server online in a different domain. The DFS services are designed to be scalable and fault tolerant. This means that you can have multiple copies of your data residing on different DFS servers throughout the organization.

Once you’ve replicated the soon-to-be inaccessible data to another server, you can point the users to the spare server while the domain is being renamed. Once the change has occurred, you can point the users back to the original DFS location, using the location’s new name. Any changes that have occurred with the users’ data during the time that they were using the spare server will then be replicated to the data’s permanent location.

The DFS root server is the server through which users access all of the DFS links. Therefore, if the DFS root server were to be inaccessible, users wouldn’t be able to access any of the DFS links through the usual method. The best way of avoiding such a problem is to replicate the DFS root.

To do so, open the Distributed File System console from the Administrative Tools menu. When the console opens, right-click on the existing DFS root and select the New Root Replica command from the resulting context menu. When you do, Windows will launch the New DFS Root Wizard. Enter the DNS name of the server that should host the new replica. If you don’t know the exact DNS name, you can use the Browse function to find the desired server; just be sure to pick a server in a domain other than the one that you’re renaming.

After you’ve selected the server, click Next and you’ll see a screen that will ask you which share point you want to use to store the replica. You can either use an existing share point or create a new share. Once you’ve made your selection, click Finish to complete the process.

After you’ve created a replica of the DFS root, you’ll have to configure the way that replication occurs. Right-click on the DFS root and select the Replication Policy command from the resulting context menu. Select the DFS root that you want to make the original and click the Set Master button. You should designate the DFS root in the domain that you’re going to be renaming as the master. You’ll see the replication status for that root change from No to Yes (Primary). You must enable replication with the replica by selecting the replica and clicking the Enable button. Doing so will enable automatic replication, which will occur every 15 minutes. Once the data has replicated, you can set the replica as the master, and then remove the original DFS root until after the domain name change has been completed.

Ready? Set? Go!
Renaming Windows.NET domains isn’t a chore to be taken lightly. There’s a massive amount of planning and preparation work that must be done prior to renaming a domain. After you make sure that all of your domain servers and network resources are configured properly, you can confidently use the RenDom utility to change the name of your Windows .NET Server domain.