In the not-so-good old days of Windows NT, renaming a domain was a tortuous process. With the advent of Windows 2000 and Active Directory, the process became nearly impossible. So it’s only natural you would cringe at the prospect of having to rename a Windows .NET domain.

Fortunately, Microsoft felt your pain in advance and created the RenDom utility. Using RenDom, you can rename your Windows .NET domain. In this Daily Drill Down, I’ll show you how to obtain and use RenDom.

Look before you leap

Renaming your domain isn’t a task to take lightly. Even though Microsoft created the RenDom utility to help, you still need to do some advance preparation. Before you attempt anything in this article, be sure to make a full backup of all servers in the domain that you’re renaming. You should also cease all Active Directory-related activities on a forest-wide basis. Such activities include adding and removing servers or editing attributes. In order to complete this process, you must have already established Windows .NET forest functionality. Read the Daily Drill Down “Preparation is key when renaming a Windows .NET domain” for more preparatory steps you must take.

Downloading the RenDom tools
Unfortunately, the RenDom tool isn’t included with Windows .NET, so you’ll have to download it from the Microsoft Web site. As of this writing, Windows .NET is still in beta, and I’ve heard that Microsoft plans to include the RenDom tool in the final version of Windows .NET. For now though, you can download the tool from the RenDom page.

If you’ve previously downloaded a copy of the RenDom tool, I recommend checking the version you have by running the executable file with the /? switch. You should then visit the Web site listed above to make sure that you have the latest version. Because Windows .NET is still in beta, the RenDom tool changes from time to time as well. Renaming a domain is a complex and risky task, and you don’t want to be using old and potentially buggy software for the job.

Setting up a control computer
After you’ve obtained RenDom and backed up your servers, set up a computer that you can use to control the domain renaming process. The computer must be a member server, not a domain controller, in the domain that you’re renaming. In addition, the member server must be running Windows .NET. Unless otherwise indicated, you’ll perform the entire operation from this server.

Once you’ve configured a server to act as the control station, create a folder named Domain Rename on the server’s hard disk. Next, download the RenDom utility and extract the included files into the folder you just created.

Next, you must install the Windows .NET Support Tools. Insert your Windows .NET CD and navigate to the CD’s \SUPPORT\TOOLS folder. Double click on the SUPTOOLS.MSI icon to launch the Windows Support Tools Installation Wizard. Follow the wizard’s instructions for installing the support tools. When prompted, select the option to install the complete set of support tools.

Generate forest level descriptions
After you’ve configured the control station, you’re ready to get down to business. In this part of the procedure, you’ll be generating a forest-level description file. A forest-level description file is an XML file that lists all of the domain directory partitions and application directory partitions in the entire forest.

Log into the control station using an Administrator account that’s a member of the domain’s Administrative group and also a member of the forest’s Enterprise Admins group. Open a Command Prompt window and navigate to the Domain Rename directory you created earlier. At the prompt, type RENDOM /LIST and press [Enter]. If you haven’t upgraded Windows .NET to use forest functionality, you’ll see the error displayed in Figure A.

Figure A
You’ll get this error message if you haven’t upgraded the forest to use Windows .NET forest functionality.

After the RenDom command completes, a file named DOMAINLIST.XML will be added to the Domain Rename folder. Create a backup copy of this file by typing COPY DOMAINLIST.XML DOMAINLISTBACKUP.XML and pressing [Enter].

The XML file contains information regarding every domain in the entire forest. As you can see in Listing A, two domains are referenced: NET.COM and TEST.NET.COM. In the code sample, the forest-wide data is contained within the <Forest> and </Forest> markers. Likewise, code that applies to an individual domain is enclosed between the <Domain> and </Domain> markers. You might also notice that each individual section in the XML code starts with a comment, which explains what that portion of the code relates to.

Editing the XML file
Now that you’ve exported a forest-level description XML file, it’s time to edit the file. As you might have guessed, renaming a domain in Windows .NET isn’t a point and click operation. Instead, you must actually modify XML code and then later import the changes you’ve made.

The process of changing the domain name is actually as simple as replacing the existing domain names with the new domain names. However, as you modify the file, there are some things that you must keep in mind. Earlier I showed you how components of code are designated by markers like <Domain> and </Domain>. As you edit the code, you can make changes to anything inside of the <DNSName> </DNSName> markers or inside of the <NetBiosName> </NetBiosName> markers. However, you must leave code inside of the <Guid> </Guid> markers alone. As you probably know, the GUID is a globally unique identifier—a number that’s used to identify an object. If you make changes to the GUID, then Windows will no longer recognize the domain, no matter what it’s called.

I should also point out that if you have parent/child domains, you must remember to rename the child domain if you rename the parent domain (or vice versa). Failure to rename both the parent and the child will actually cause the unchanged domain to shift positions within the domain hierarchy. For example, in my code sample, I’ve got a domain named NET.COM and a child domain called .TEST.NET.COM. If I rename .NET.COM but don’t rename the child domain, the child domain will be completely cut off from the rest of the domain tree because its name references a parent that no longer exists. If, on the other hand, you rename the child domain from .TEST.NET.COM to simply .TEST.COM, then the child domain is no longer a child but rather a top tier domain.

In Listing B below I’ve changed the domain names from .NET.COM and .TEST.NET.COM to .WINDOWSNET.COM and .TEST.WINDOWSNET.COM, so that you can see the correct way to edit the code.

Cleaning house
After you finish editing your XML file, there are still a few chores you must take care of. First, you may have noticed the <!– PartitionType:Application –> comments above some sections of code. Application partitions are created automatically by some Microsoft telephony software and by some third-party applications. Technically, it’s possible for an application partition to occur anywhere within the Active Directory that a directory partition can exist, except at the root level.

If during the course of modifying the XML file you encounter application partitions, you must check to see if the reference to the application partition is within the <Domain> </Domain> markers of a domain that you’re renaming. If it is, then you’ll have to enter new domain information for the application partition. Failure to do so will cause problems since the application partition will exist within a domain that no longer exists.

After you’ve finished your edits, save your changes to the XML file. Type RENDOM /SHOWFOREST and press [Enter]. When you enter this command, the RenDom utility will display what the forest structure will look like after you import the XML file. Review this information carefully to see if anything needs to be changed. If you’ve made a mistake, you’ll have to start the entire process over again to rectify the error.

If you’re satisfied with the output, go to your DNS server and create the necessary zones for the new domains. Before proceeding with the rename, you must make sure that your authoritative DNS servers are ready. This is one of the most critical steps in the entire process. All of the necessary DNS entries are made automatically, so you don’t have to do anything except to verify that ALL authoritative DNS servers contain ALL of the records listed below.

First, there must be a Canonical Name (CNAME) record associated with every domain controller; otherwise replication will fail. There must also be a Service Location (SRV) record referencing the Primary Domain Controller (PDC) emulator. Next, you must verify that each authoritative DNS server contains at least one SRV record pointing to a global catalog server. Finally, each authoritative DNS server must contain at least one SRV record pointing to a domain controller.

Generating the domain renaming instructions
When you’re satisfied with the new forest structure, it’s time to begin implementing it. The first step is to generate a set of domain renaming instructions. This basically involves creating a script based on the XML file you edited earlier. When the script is executed, each domain controller will be updated as the script is processed.

To generate the domain renaming script, open a Command Prompt window and go to your Domain Rename directory. Type RENDOM /UPLOAD and press [Enter]. This will create the domain renaming instructions and upload them to the domain controller holding the Domain Naming Master role. The command will also create a file named DCLIST.XML in the Domain Rename folder.

DCLIST.XML contains a list of every domain controller in the entire forest. Go through this file to verify that all domains are accounted for. Later, when you initiate the domain renaming process, Windows will use this fill to track the operation’s progress. As you can see in Listing C, I have four domain controllers listed. These include HOMER and TITUS in the .NET.COM domain and HERSHEY and INDIA in the .TEST.NET.COM domain. You might also notice that it’s normal for this file to use the old domain names rather than the new ones.

Replicating the domain renaming instructions
After you’ve uploaded the domain renaming instructions to the Domain Naming Master, you must replicate the instructions to every domain controller in the forest. First, determine which domain controller the instructions have been uploaded to. To do so, open a Command Prompt window, type DSQUERY SERVER –HASFSMO NAME, and press [Enter].

Once you know the name of the domain naming master, enter the following command where DName is the DNS name of the domain naming master: Repadmin /syncall /d /e /P /q /dname. Be careful entering the command because it’s case sensitive.

Verify domain controller readiness
The last essential check before you actually execute the renaming instructions is to verify the domain controller’s readiness. To do so, open a Command Prompt window, type RENDOM /PREPARE,  and press [Enter]. When the command completes, open the DCLIST.XML with any text editor and look at the listing for each domain controller. In each domain controller’s listing, you should see the following line:
<State>Prepared</State>

As long as this line exists for each domain controller, you’re ready to rename the domain. Don’t even think about trying to execute the renaming procedure unless all domain controllers are in the Prepared state. If any domain controllers aren’t prepared, check out the RENDOM.LOG file in the Domain Rename directory for information about what went wrong.

Execute the domain rename
You’re finally ready to execute the renaming instructions you created earlier. To execute the instructions, open a Command Prompt window, type RENDOM /EXECUTE, and press [Enter].

When the command completes, open the DCLIST.XML file and check the status of each domain controller. In each domain controller’s section in the file, there will be a <State> </State> section. Between these two flags should be the word Done. If any domain controller is listed in the Prepared state, repeat the RENDOM /EXECUTE command as many times as is necessary to force the renaming operation to complete.

There’s a chance that one or more domain controllers could be listed as being in the Error state. If this happens, look in either the <LastError> section or in the <FatalErrorMsg> section for details about what went wrong.

Fix Dfs links
After you’ve renamed a domain, Windows .NET’s Distributed File System (Dfs) will likely malfunction. This happens because Dfs contains embedded references to disk resources in the old domain. You can correct this problem by using the DFSUTIL tool from the Windows Support Tools.

Begin the process by selecting the Distributed File System command from the Administrative Tools menu. When the Dfs console opens, look through the console for any Dfs roots that rely on resources within the changed domain. As you work through the list of Dfs resources, pay close attention to whether a Dfs resource is referenced by DNS name or NetBIOS name. Remember that if you changed the domain’s DNS name but not its NetBIOS name, and the Dfs resource references the NetBIOS name, the Dfs file structure doesn’t need to be changed.

Once you determine which Dfs roots contain resources that need to be updated, open a Command Prompt window, type DFSUTIL /RenameFtRoot /Root:DfsRootPath /OldDomain:OldName /NewDomain:NewName /Verbose, and press [Enter]. In this command, the DfsRootPath refers to the Dfs root. For example, this might be \\net.com\software. OldName and NewName refer to the old name in the Dfs topology and the new name that it should be replaced with. Once you’ve completed the command, run the command again as many times as is necessary to fix each Dfs naming problem.

Fix group policy objects
After you rename a domain, all group policy objects within the domain will continue to reference the old domain name. Therefore, to make your group policies work, you must update their name information as well. You can update the group policy objects by opening a Command Prompt window on the control station, typing gpfixup /olddns:OldDomainDnsName /newdns:NewDomainDNSName /oldnb:OldDomainNetBIOSName /newnb:NewDomainNetBIOSName /dc:DcDnsName, and pressing [Enter]. In this command, OldDomainDnsName references the DNS name of the old domain. NewDomainDnsName is the DNS name of the new domain name. Likewise, OldDomainNetBIOSName and NewDomainNetBIOSName refer to the domain’s old and new NetBIOS names. DcDnsName refers to the domain controller that actually did the renaming. Usually, this is the domain’s PDC emulator.

Now that the group policies are fixed on the PDC emulator, you must replicate the changes to every other domain controller in the domain. Open a Command Prompt window, type Repadmin /syncall /d /e /P /q DcDnsName NewDomainDnsName, and press [Enter]. In this command, the DcDnsName is the DNS name of the domain controller referenced in your original GPFIXUP command. NewDomainDnsName is the domain’s new DNS name. This command is case sensitive, so enter it carefully.

Reconfigure servers and workstations for the new domain
After you’ve renamed the domain and changed network components affected by the renaming process, you must verify that member servers and workstations are able to access the renamed domain. For Windows NT 4.0 servers and workstations, this means manually unjoining the old domain and joining the new domain. Windows 9x and Windows ME machines simply require you to specify the name of the new domain in the login prompt.

Windows 2000 servers and workstations, Windows .NET servers, and Windows XP workstations must be simply rebooted. The only catch is that in order for the change to work properly, each of these machines must be rebooted twice. It isn’t necessary to reboot domain controllers as they have already been updated.

When you’re done
After you’ve completed the domain renaming, it’s time to begin testing to make sure that everything works correctly. It’s a good idea to check to make sure that services that depend on domain controlled service accounts are functional. You may also have to verify that certificate services are functioning and that all necessary shortcut trusts exist. Of course, these are only suggestions. The actual tests that need to be performed will depend on your individual network.