- Domain Design Overview
- Choosing Your Domain Namespace
- New Domain Design Features in Windows .NET Server 2003
- Choosing Your Domain Structure
- Single Domain Model
- Multiple Subdomain Model
- Multiple Trees in a Single Forest Model
- Federated Forests Design Model
- Peer-Root Domain Model
- Placeholder Domain Model
- Special-Purpose Domains
- Renaming an Active Directory Domain
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Renaming an Active Directory Domain
Active Directory in Windows .NET Server 2003 gives domain designers the flexibility to rename their domain namespace and/or splice domains in a forest to different locations within a forest. This capability gives Active Directory great new functionality because design changes can be made due to corporate mergers or organizational changes.
Domain rename supports renaming either the Active Directory namespace (for example, companyabc.com) or the NetBIOS (NT) domain name or both. The procedure is a rather brute-force process, however, and should not be considered to be a routine operation.
The domain rename functionality in Windows .NET Server 2003 is mainly a psychological factor because the prerequisites for deploying domain rename make it unlikely to be widely performed, at least in the initial stages of Windows .NET Server 2003 adoption. Domain re-name offers long-term answers to the previous barriers to Active Directory adoption, which revolved around the fact that organizations did not want to be locked in to any decisions that could not be changed. Because a Windows 2000 Active Directory namespace decision was irreversible, this effectively put many decision-makers on edge, as they did not want to "paint themselves into a corner," so to speak. Domain rename removes this stipulation and makes Active Directory adoption much more palatable to decision-makers within an organization.
Domain Rename Limitations
Domain rename has several limitations. It is important to understand the following restrictions before considering a domain rename operation:
Cannot reduce the number of domains in a forest—The domain rename tool cannot be used to drop additional domains from a forest. For example, if a forest is composed of four domains, there must be four domains remaining after the procedure is complete. This type of domain consolidation role can be performed only through the use of other tools, such as the Active Directory Migration Tool, which is covered in detail in Chapters 16, "Migrating from NT4 to Windows .NET Server 2003," and 17, "Migrating from Windows 2000 to Windows .NET Server 2003."
The current root domain cannot be demoted—While the domain rename tool can splice and transplant domains from one portion of an Active Directory namespace to another, it cannot fundamentally change the root domain in a tree. A root domain can be renamed, however.
Cannot transfer current domain names in one cycle—A production domain cannot be named the same as another production domain that exists in a forest. You need to run the domain rename procedure twice to achieve this type of desired functionality.
Cannot rename an Exchange 2000 forest—The domain rename tools do not support renaming domains that have Exchange 2000 integrated into the schema. This is currently one of the biggest stumbling blocks for the procedure. Future iterations of the product will be written to support Exchange 2000 forest renames.
Domain Rename Prerequisites
In addition to the limitations of the domain rename tool, specific prerequisites for domain rename must be met before a domain can be renamed. These prerequisites are as follows:
The entire forest must be in Windows .NET Server 2003 Functional mode—One of the largest hurdles to overcome before renaming a domain is the fact that all domain controllers in the domain must be first upgraded or replaced with Windows .NET Server 2003 and the forest functional level raised to Windows .NET Server 2003 functionality. This reason alone will most likely be the biggest limiting factor, at least in the initial adoption period of Windows .NET Server 2003.
New DNS zones must be created—The DNS server(s) for a domain must have a zone added for the new domain namespace to which the domain will be renamed. The exception is if the domain rename procedure will be renaming only the NetBIOS domain.
Domain rename must run from a console server—A member Windows .NET Server 2003 computer (not a domain controller) must serve as the console server for the domain rename procedure. All domain rename operations are run from this one box.
Shortcut trust relationships may need to be created—Any domains that will be "spliced" into a new location in the Active Directory forest will need to have a shortcut trust established between itself and the parent domain where it will be transplanted.
Renaming a Domain
The domain rename procedure, from the back end, is not extremely complex. Most of the barriers to domain renaming, aside from the limitations and prerequisites listed in the preceding section, come in the form of the disruption to the forest that is caused by the reboots applied to all the computers in the forest.
After the prerequisites have been satisfied, the domain rename process can procede. The entire domain rename process is accomplished through six basic steps. As previously mentioned, however, this routine is rather harsh on the network because it causes downtime to a network infrastructure and should not be considered to be a common operation.
Step 1: List Current Forest Description
The tool used for domain rename is known as Rendom (which, ironically, is automatically changed to Random in Microsoft spell checkers). Rendom has several flags that are used in import and export operations. The first procedure run from the console server is rendom /list, which locates the domain controllers for a domain and parses all domain-naming information into an XML document named Domainlist.xml, as illustrated in Figure 5.16.
)
Figure
5.16 Forest description XML document.
This XML document can easily be modified by any text editor such as Notepad and, as will become evident, is central to the domain rename procedure.
Step 2: Modify Forest Description with New Domain Name(s)
The XML file generated by the /list flag must be modified with the new domain-naming information. For example, if CompanyABC is changing its name to CompanyXYZ, all references to companyabc in the XML list illustrated in Figure 5.16 are changed to companyxyz. This includes the NetBIOS and DNS names.
Step 3: Upload Rename Script to DCs
After the XML document is updated with the new domain information, it can be uploaded to all domain controllers in a forest through the use of the rendom /upload command. This procedure copies the instructions and new domain information up to all domain controllers within a forest.
Step 4: Prepare DCs for Domain Rename
Domain rename is a thorough process because it is absolutely necessary that all domain controllers in a forest receive the update information. It is therefore necessary to run rendom /prepare to initiate a preparation process that checks to see if every single domain controller listed in Active Directory responds and signifies that it is ready for the migration. If every single domain controller does not respond, the prepare function fails and must be restarted. This precaution exists to keep domain controllers that are powered down, or not accessible across the network, from coming up at a later time and attempting to service clients on the old domain name.
Step 5: Execute Domain Rename Procedure
After all domain controllers respond positively to the prepare operation, you can initiate the actual domain rename by running the rendom /execute command from the console server. Before the execute command is run, there are actually no changes made to the production environment. However, as the command is run, all domain controllers execute the changes and automatically reboot. You then must establish a method of rebooting all member servers, workstations, and other client machines and then reboot them all twice to ensure that all services receive the domain-naming change.
NOTE
Any Windows NT clients need to be manually rejoined to the domain following any domain rename procedure because they do not support automatic rejoin functionality.
Step 6: Post-Rename Tasks
The final step in the Rendom task is to run the rendom /clean operation, which will remove temporary files created on the domain controller and return the domain to a normal operating state.
In addition to the cleanup tasks, you need to effectively rename each domain controller, to change its primary DNS suffix. Each domain controller needs to go through this operation, which you run via the netdom command-line utility. The following steps outline the renaming of a domain controller:
Open a Command Prompt window (choose Start, Run and then type cmd.exe).
Type netdom computername OldServerName /add:NewServerName.
Type netdom computername OldServerName /makeprimary:NewServerName.
Restart the server.
Type netdom computername NewServerName /remove:OldServerName.
You run all the preceding commands from the command line. Replace the generic designators OldServerName and NewServerName with the entire DNS name of the old server and the new server, such as server1.companyabc.com and server1.companyxyz.com.