CHAPTER 5
Designing a Windows Server 2016 Active Directory

Proper design of a Windows Server 2016 Active Directory Domain Services (AD DS) structure is a critical component in the successful deployment of the technology. Mistakes made in the design portion of AD DS can prove to be costly and difficult to correct. Many assumptions about basic AD DS domain and functional structure have been made, and many of them have been incorrect or based on erroneous information. Solid understanding of these components is vital, however, and anyone looking at Windows Server 2016 should keep this point in mind.

AD DS was specifically designed to be scalable. This means that, theoretically, organizations of every shape and size should be able to implement the technology. For obvious reasons, this means that the structure of the AD DS forest will vary from organization to organization.

This chapter focuses on best practices for AD DS design, including a discussion of the specific elements that compose AD DS, including feature upgrades added in this latest version, Windows Server 2016. Various domain design models for AD DS are presented and identified with specific real-world scenarios. The domain rename procedure is outlined, as well, to explain how the concept affects domain design decisions.

Chapter 15, “Migrating to Active Directory 2016,” also explores integrating your on-remise AD infrastructure with Azure Active Directory. This ability, debuted in the second quarter of 2016, replaced the first attempts to integrate premise AD with Azure AD in the Windows Server 2012 R2 release and Azure AD Sync.

The example in Figure 5.1 shows how a shortcut trust could theoretically be used to reduce the overhead involved in sharing resources between the two sales subdomains in the companyabc.com tree. You can find more information about these trusts in the individual design model sections later in this chapter.

The limitations to this type of namespace strategy are primarily security based. Publishing your AD DS namespace leaves potential hackers with the name of your domain system and part of what is needed to compromise user accounts. Administering your firewall to block internal DNS queries also becomes less intuitive when the namespace is the same as the published Internet namespace for the organization. If the namespaces were separate, for example, a simple rule could be written to block any traffic to the internal domain structure. Another limitation arises if an organization currently employs multiple namespaces to identify itself and all those namespaces need to be joined into the same forest; in this case, a common namespace design is not an option. Mergers and acquisitions or even multiple business units within the same corporate parent can present these types of problems.

Keep in mind that it is important to secure an internal namespace from registration anywhere on the Internet other than in your own network. In other words, if an organization registers internalnetwork.net, and another organization on the Internet registers the same domain name for its network, there could be naming conflicts with applications and other systems that perform DNS lookups against your forest. For example, if an application on a laptop usually attempts to access an internal namespace but then tries to access it remotely through an Internet service provider (ISP), the ISP’s DNS will forward you to the registered DNS name on the Internet. In a nutshell, if you are going to design your domain with an unpublished namespace but use a standard such as .net or .org that someone else could theoretically register, it is best to register and reserve that domain but not point it anywhere. Another common tactic is to name your domain something that will never be published, such as a root with your company’s stock ticker symbol (for example, network.msft), or by using the .internal suffix, which has been specifically reserved for internal use only.

Active Directory Recycle Bin—The ability to do a full-fidelity recovery of deleted objects in AD DS was introduced in Windows Server 2008 R2, but was greatly improved in the versions prior to Windows Server 2016. By adding this critical functionality, there is less worry that accidental deletion of user accounts, groups, or even entire organizational units (OUs) will cause major havoc, and there is subsequently less reason to create multiple domains in a forest simply to spread the risk of domain object deletion. Note that this capability is available only when the forest functional level is raised to Windows Server 2008 R2 or later functional level and when it is subsequently turned on in a domain. You can read more about this in Chapter 4, “Active Directory Domain Services Primer.”

Fine-grained password policies—The ability to have multiple password policies within a single domain was originally released in Windows Server 2008 and is still supported with Windows Server 2016 (and is becoming much easier to use, as well). The addition of this functionality means that many organizations that previously implemented additional domains because of the restriction of a single password policy per domain might be able to collapse those domains. Note that this functionality is available only in Windows Server 2008 and later. For more information about using fine-grained password policies, see Chapter 4.

Domain rename function—The capability to rename a domain opened up a new field of possibilities for the design and potential redesign of AD DS domain structures. Previously, stern caveats were issued about the inability to rename domains or change the overall structure of an AD DS forest. With the domain rename functionality present in AD DS implementation, these limitations are lifted, and designers can take heart in the fact that design changes can be made after implementation. Having this ability does not change the fact that it is still wise to plan out your domain design thoroughly, however. Not having to make changes to domain names or reposition domains in a forest is much easier than having to go through the domain rename process. Just knowing that such functionality exists, however, is a breath of fresh air for designers.

Cross-forest transitive trusts—Introduced in Windows Server 2003, the concept of cross-forest transitive trusts lessens domain designer connectivity worries. In the past, some administrators balked at the limitations of collaboration within Windows 2000 Active Directory structures. The cross-forest transitive trust capability of AD DS negates those concerns because multiple AD DS forests can now be joined via cross-forest trusts that are transitive, rather than explicit, in nature. The combination of these forests is known in the Microsoft world as federated forests.

Domain controller virtualization support—Microsoft has added the capability to create domain controllers (DCs) from virtual machine templates, greatly improving the time it takes to build a new DC. At the same time, they have made it possible to have virtual DCs recovered from snapshots without the worry of corruption or lingering object issues. All of these virtualization features are upgraded for AD DS in Windows Server 2016 and change the design options, allowing for much more advanced virtualization design options.

Server Core and PowerShell enhancements—Windows Server 2016 makes it preferable to deploy an AD DS DC running on Windows Server Core because all DC functionality can be performed using PowerShell, and Server Core greatly reduces the security footprint of the DCs.

Domain controller promotion from media—The capability to promote remote servers to DCs via a CD image of the global catalog helps to limit replication traffic and the time associated with establishing remote domain controllers. Windows Server 2016 also provides you with the ability to save the global catalog to media (like a CD-ROM), ship it to a remote site, and, finally, run domain controller promotion and insert the data disk with the directory on it for restoration. Only the deltas, or changes made since media creation, are then replicated, saving time and bandwidth. The effect of this on domain design creation is reflected in reduced setup times, less network bandwidth consumption, and increased flexibility of global catalog domain controller placement.

When you’re designing the AD DS, you must contemplate a common framework for diagrams. In AD DS, for example, domains are often pictorially represented by triangles, as shown in Figure 5.2. So, when beginning your design, start with a single triangle.

In this example, the fictional company named CompanyABC has begun the process of domain design. Depending on its unique needs, CompanyABC might decide to expand upon that model or keep it simple. These decisions should be made with a detailed knowledge of the different domain design models and the environments in which they work best.

Active Directory was designed to be a flexible, forgiving directory services implementation. Consequently, multiple design models are available to choose from, depending on the individual needs of organizations. The major design models are as follows:

Single-domain model

Multiple-domain model

Multiple trees in a single-forest model

Federated-forests model

Peer-root model

Placeholder domain model

Special-purpose domain model

In reality, not all AD structures fall within these categories; possibilities exist for numerous variations and mutations of AD structure. However, most domain structures either fit into these categories or are a hybrid model, possessing traits of two different models. Out of all these models, however, the single-domain model is the most common design model and also happens to be the easiest to deploy.

Another advantage realized by the creation of a single domain is the attainment of centralized administration. Many organizations with a strong central IT structure want the capability to consolidate control over the entire IT and user structure. AD DS and, specifically, the single-domain model allows for a high level of administrative control and the ability to delegate tasks to lower sets of administrators. This has proven to be a strong draw to AD DS.

Not all AD DS structures can be composed of a single domain, however, and some factors might limit an organization’s ability to adopt a single-domain structure. If these factors affect your organization, you might need to begin expanding your domain model to include other domains in the forest and a different domain design. For example, the single security boundary formed by a single domain might not be exactly what your organization needs. Organizational units (OUs) can be used to delegate administration of security elements, but members of the Domain Admins group can still override permissions within different OUs. If the security lines within your organization need to follow exact boundaries, a single domain might not be for you. For example, if your HR department requires that no users from IT have access to resources within its environment, you will need to expand your domain structure to accommodate the additional security concerns.

Another disadvantage of the single-domain model is that a single domain in a forest necessitates that the computer with the role of schema master is located in that domain. This places the schema master within the domain that contains all the user accounts. Although access to the schema master can be strictly controlled through proper administration, your risk of schema exposure is greater when the schema master role resides in a user domain. For example, members of the Domain Administrators group could override the security of the Schema Administrators group and add their account to that group. If this design model poses problems for you as an organization, design models that separate the schema master into a placeholder domain can do the trick. The placeholder domain model is described in more detail later in this chapter in the section “Understanding the Placeholder Domain Model.”

The IT team in Minneapolis is designing an AD DS structure and wants to centralize administration at corporate headquarters. Branch offices should have the capability to change passwords and clear print jobs locally, but should have no other form of administrative privilege on the network.

During the AD DS design process, CompanyA started with a single AD DS forest, domain, and namespace named companya.net. OUs for each branch office were added to delegate password-change control and print administration to those offices.

Current legacy Windows 2000 AD and Windows Server 2003 forests and domain were consolidated into the AD DS structure, as shown in Figure 5.3. CompanyA could not justify the existence of additional domains because their security model was centralized, and it did not have any far-flung geographic locations with slow link speeds to the main office or any other similar constraints that required additional domains.

Delegation of password-change control and other local administrative functions was granted to individuals in each specific geographic OU, which gave those administrators permissions specific to only resources within their own group but maintained central administrative control in Minneapolis. A detailed discussion of organizational unit design is covered in Chapter 6, “Designing Organizational Unit and Group Structure.”

Several AD DS sites were created to control the frequency of replication. A site was positioned to correspond with each separate geographic area, creating a site structure similar to the one shown in Figure 5.4.

Creating the separate sites helped to throttle replication traffic and reduce the load placed on the WAN links between the sites. For more details about site links and replication, see Chapter 7, “Active Directory Infrastructure.”

This type of single-domain design is ideal for the type of organization described in this section and actually can be used for many other types of organizations, large and small. Because delegation of administration is now accomplished through the use of OUs and Group Policy objects, and the throttling of replication is accomplished through AD sites, the number of reasons for organizations to use multiple domains has been reduced.

By default, two-way transitive trusts exist between subdomains and domains in AD DS. Bear in mind, however, that this does not mean that resource access is automatically granted to members of other domains. A user in subdomain B is not automatically granted any rights in domain A; the rights need to be explicitly defined through the use of groups. Understanding this concept will help to determine the logistics of domain addition.

Decentralized administration—If different branches of an organization generally manage their own IT structure and there are no future plans to consolidate them into a centralized model, multiple interconnected domains might be ideal. Each domain acts as a security boundary for most types of activity and can be set up to disallow administration from escaping the boundaries of domains. This approach, however, exposes many of the limitations associated with a multiple-domain environment. In other words, it is better to try to centralize administration before deploying AD DS because you will gain more of AD’s advantages. It is also much better to organize administration along OU boundaries than by domains, so consider this option first.

Geographic limitations—If extremely slow or unreliable links or great geographic distances separate different parts of your company, it might be wise to segment the user population into separate domains. This will help to limit replication activity between domains and also make it easier to provide support during business hours for distant time zones. Keep in mind that slow links by themselves do not necessitate the creation of multiple domains because Windows Server 2016 AD DS uses the concept of AD DS sites to throttle replication across slow links. The main reason that might exist for domain creation for geographic reasons is administrative flexibility. In other words, if there is a problem with the network in Japan, a Japanese administrator will have more power to administer the Asia domain and will not need to call the North American administrator in the middle of the night.

Unique DNS namespace considerations—If two organizational entities want to use their Internet-registered namespace for AD DS but use a common forest, such as hotmail.com or microsoft.com, those domains must be added as separate domains. This type of domain model is described more fully in the “Understanding the Multiple Trees in a Single-Forest Model” section later in this chapter.

Enhanced security concerns—Depending on the needs of your organization, separating the schema master role into a domain separate from your users might be applicable. In this case, the single-domain model would not be applicable, and a model such as the peer-root or placeholder domain would be more appropriate.

When contemplating additional domains, remember the mantra “Simplicity is best.” However, if during the design process, the specific need arises to add domains, proper design is still warranted, or your environment will run the risk of becoming more inefficient than it could be.

Because each acquired company possesses its own IT department and there was no agreement on the ownership of the Domain Admins accounts, CompanyB decided to deploy an AD DS structure with two subdomains for Subsidiary A and Subsidiary B, as shown in Figure 5.5.

This design model allowed for a certain degree of administrative freedom with the newly acquired subsidiaries but also allowed for a common forest and schema to be used and kept the domains within the same DNS namespace.

This design model has the Particular advantage of being politically easier to implement than consolidation of existing domains. Branch offices and subsidiary companies can keep their own domain structure and security boundaries, and their IT teams can retain a greater deal of administrative autonomy.

Be warned, however, that consolidation of a larger number of domains into fewer domains is a key feature of AD DS, so the addition of domains purely for political reasons adds complexity and potentially unnecessary infrastructure. It is, therefore, very important to consider the alternatives before deciding on this design model.

Only one domain in this design is the forest root, in this case microsoft.com, and only this domain controls access to the forest schema. All other domains, including subdomains of microsoft.com and the other domains that occupy different DNS structures, are members of the same forest. All trust relationships between the domains are transitive, and trusts flow from one domain to another.

If your organization makes extensive use of its separate namespaces, you might want to consider a design like this. Each domain tree in the forest can then maintain a certain degree of autonomy, both perceived and real. Often, this type of design will seek to satisfy even the most paranoid of branch office administrators who demand complete control over their entire IT structure.

citya.org

firedeptcitya.org

policeofcitya.org

cityalibrary.org

The decision was made to merge the existing network environments into a single AD DS forest that will accommodate the existing departmental namespaces but maintain a common schema and forest root. To accomplish this, AD DS was established with citya.gov as the namespace for the root domain. The additional domains were added to the forest as separate trees but with a shared schema, as shown in Figure 5.7.

The individual departments were able to maintain control over their individual security and are disallowed from making changes in domains outside their control. The common forest schema and global catalog helped to increase collaboration between the varying organizations and allow for a certain amount of central administration.

This type of domain design is logically a bit messier but technically carries the same functionality as any other single-forest design model. All the domains are set up with two-way transitive trusts to the root domain and share a common schema and global catalog. The difference lies in the fact that they all use separate DNS namespaces, a fact that must also be reflected in the zones that exist in DNS.

The capability to perform cross-forest trusts and synchronization is not automatic, however, because the forest functionality of each forest must be brought up to at least Windows Server 2008 (or later) functional levels (Windows Server 2003 is no longer supported).

The federated-forest design model is ideal for two different situations. One is to unite two disparate AD DS structures in situations that arise from corporate acquisitions, mergers, and other forms of organizational restructuring. In these cases, two AD forests need to be linked to exchange information. For example, a corporate merger between two large organizations with fully populated AD DS forests could take advantage of this capability and link their two environments, as shown in Figure 5.8, without the need for complex domain migration tools.

In this example, users in both forests now can access information in each other’s forests through the two-way cross-forest trust set up between each forest’s root.

The second type of scenario in which this form of forest design could be chosen is one in which absolute security and ownership of IT structure are required by different divisions or subsidiaries within an organization, but exchange of information is also required. For example, an aeronautics organization could set up two AD forests, one for the civilian branch of its operations and one for the military branch. This would effectively segregate the two environments, giving each department complete control over its environment. A one- or two-way cross-forest trust could then be set up to exchange and synchronize information between the two forests to facilitate communication exchange.

This type of design is sometimes precipitated by a need for the complete isolation of security between different branches of an organization. Since the release of Active Directory in Windows 2000, several interdomain security vulnerabilities have been uncovered that effectively set the true security boundary at the forest level. One in particular takes advantage of the SIDHistory attribute to allow a domain administrator in a trusted domain in the forest to mimic and effectively seize the Schema Admin or Enterprise Admin roles. With these vulnerabilities in mind, some organizations might choose separate forests, and simply set up trusts between the forests that are specifically designed to strip off the SIDHistory of a user.

In Figure 5.9, a one-way cross-forest transitive trust with SIDHistory-filtering enabled was set up between the civilian branch and the military branch of the sample aeronautics organization. In this example, this setup would allow only accounts from the military branch to be trusted in the civilian branch, in essence giving the military branch users the ability to access files in both forests. As with other types of trusts, cross-forest trusts are one-way by default. Unlike explicit trusts, however, cross-forest trusts are transitive. To set up two-way transitive trusts, you must establish two one-way trusts between the two forest roots.

ConglomerateA has recently entered into a joint venture with SupplierA and wants to facilitate the sharing of information between the two companies. SupplierA also currently operates in a Windows Server 2016 AD DS environment and keeps all user and computer accounts in an AD DS forest that is composed of two domains in the suppliera.com namespace and a separate tree with a DNS namespace of supplierabranch.org that reflects a certain function of one of its branches.

The decision was made to create a cross-forest trust between the two forests so that credentials from one forest are trusted by the other forest and information can be exchanged. The cross-forest trust was put into place between the root domains in each forest, as shown in Figure 5.10.

Remember, a trust does not automatically grant any permissions in other domains or forests; it simply allows for resources to be implicitly shared. Administrators from the trusting domain still need to manually grant access. In this example, administrators in both forests can decide what resources will be shared and can configure their environment as such.

In short, the peer-root domain model makes use of an unpopulated forest-root domain that exists solely to segregate the schema master function from the rest of the network.

In Figure 5.11, the companyabc.com domain is used for all user and computer accounts, whereas the abcschema.root domain is the peer-root domain that holds the schema master role for the company. Most users would not even be aware of the fact that this domain exists, which makes it even more secure.

The one major disadvantage to this design model lies in the hardware costs. Because a separate domain is necessary, at least one extra domain controller is needed as part of the design plan, and preferably two for redundancy issues. This domain controller for the empty-root domain will not need to be the speediest machine because it will not perform much work, but it should definitely be made redundant, because the forest-specific flexible single master operations (FSMO) roles will be handled by the machine.

An additional advantage that this type of environment gives you is the flexibility to rename domains, add domains, and essentially move in and out of subdomains without the need to rename the forest. Although the Domain Rename Tool exists in Windows Server 2016, undertaking this task is still complicated, and using the peer-root model can help to simplify changes. In a merger, for example, if your peer root is named root.network and all your resource domains are located in companyabc.com in the same forest, it becomes much easier to add companya.net into your forest by joining it to the root.network domain.

The beauty of the peer-root domain model is that it can be incorporated into any one of the previously defined domain models. For example, a large grouping of trees with published namespaces can have a forest root with any name desired.

The example shown in Figure 5.12 demonstrates how this type of environment could conceivably be configured. The flexibility of AD DS is not limited by this design model because the options available for multiple configurations still exist.

Of course, many organizations often cannot justify the increased hardware costs, and this type of design model can prove to be more costly. Realistically, at least two domain controllers need to be established in the root domain to handle authentication requests and to provide for redundancy within the domain. Keeping these costs in mind, it is important to align your organization’s security requirements with the cost-benefit ratio of this design model.

The administrators of CompanyD originally chose AD DS and Windows Server 2016 to provide for robust security for their environment and to take advantage of the increased functionality. However, management was concerned about limiting access to vital components of the directory service such as the schema. Further investigation into the varying domain design models for AD DS uncovered the peer-root domain model as a fully functional substitute to the single-domain model, but with the added schema security that they desired. This resulted in a forest structure similar to the one shown in Figure 5.13.

OUs were created for each department and placed in the companyd.com domain. The only user account in the rootd.peer domain is the administrator account for the forest. Access to this account was limited to a choice group of high-level administrators. This helped to control access to the schema root for the security-conscious organization and provided for the simplicity of a single-domain environment for its users.

There are two distinct advantages to this design. First, as with the peer-root model, the schema is separate from the user domains, thus limiting their exposure and helping to protect the schema. Second, the namespace for the user accounts is consistent in the namespace, thus mitigating any potential political issues. In other words, because all users in all locations are at the same logical level in the domain structure, no one group will feel superior or inferior to another. This issue might seem trite, but the psychological nature of humans is finicky, and you might find that this design offers advantages for certain organizations.

All users authenticate to geographically centric subdomains. In addition, the administrators in New York have segregated the schema master function into the placeholder domain, limiting its exposure and have limited access to this domain to a small group of high-level administrators. Each domain is logically oriented, as well, to give the impression of autonomy to each geographic unit.

Generally, there has to be a good reason before additional domains are deployed in AD DS. Overhead is increased with each domain that is added to an environment, and your logical network structure begins to look convoluted. However, in some unique cases, a special-purpose domain might become necessary.

Another possible use for a separate special-purpose domain structure is to house a directory service-capable application that requires itself, for security or other reasons, to have exclusive access to the schema. In other words, if your HR department runs an application that stores confidential employee information in an application that uses an LDAP-compliant directory, such as AD DS, a domain could be set up for that application alone. A cross-forest trust relationship can be established to allow for the sharing of information between the two environments. This type of situation is rare because most of these applications make use of their own directory, but it is possible. Because the AD DS schema must be unique across the forest, this would preclude the use of a single forest if these applications require exclusive access or utilize common schema attributes. This concept, known as Active Directory Lightweight Domain Services (AD LDS), is further elaborated in Chapter 8, “Creating Federated Forests and Lightweight Directories.”

Users in the contractor domain can access resources in the main companye.com domain, but only those to which they are specifically granted access. In addition, the exposure that the main companye.com domain receives from nonemployees is greatly reduced.

Domain rename supports renaming either the AD DS namespace (for example, companyabc.com) or the NetBIOS (legacy 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 Server 2016 is mainly a psychological factor because the prerequisites for deploying domain rename make it unlikely to be widely performed. Domain rename offers long-term answers to the previous barriers to AD DS 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 AD 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 AD DS adoption much more palatable to decision makers within an organization.

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.

The current root domain cannot be demoted—Although the Domain Rename Tool can splice and transplant domains from one portion of an AD DS 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.

The entire forest must be at least Windows Server 2008 functional level—All domain controllers in the domain must be first upgraded or replaced with Windows Server 2008 through 2016 functional level and the forest functional level raised to at least Windows Server 2008 functional level or above.

New DNS zones must be created—The DNS servers 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 Server 2016 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 might need to be created—Any domains that will be “spliced” into a new location in the AD DS forest will need to have a shortcut trust established between itself and the parent domain where it will be transplanted.

After the prerequisites have been satisfied, the domain rename process can proceed. 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.

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.

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. renaming of a domain controller:

1. Open a command prompt window (by choosing Start, Run, and then type cmd.exe).

2. Enter netdom computername OldServerName/add:NewServerName.

3. Enter netdom computername OldServerName/makeprimary:NewServerName.

4. Restart the server.

5. Enter 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.

Fully understand the structure of AD DS before designing.

Implement fine-grained password policies and the Active Directory Recycle Bin to reduce the need for additional domains.

Secure any external namespace chosen by registering it so that it cannot be used anywhere on the Internet.

Start a domain design by considering the single-domain model first.

Consider using multiple domains for specific reasons only.

Consider using the federated-forest design model when uniting two disparate AD DS structures.

Control and optimize replication traffic by using sites.

Upgrade any down-level clients to reduce administration and maintenance.

Use domain rename sparingly, and only when faced with no other alternative.