Plan and do application migration
The “real” challenge of the environment migration is the application migration. The applications must serve users from both the existing and the new forest while the application instances with all configurations and the application data are being moved from one environment to the other. Clients must be reconfigured to consume the new application and service instances in the FQDN environment. Application and service instances in the SLD instance have to be decommissioned. Section 8.3: Application Migration provides insight to the applications’ Active Directory dependencies. Categorize the applications and develop migration strategies for each application category.
Plan and decommission the SLD environment
After the migration is finished, the SLD Active Directory and perhaps some services and applications that aren’t migrated must be decommissioned. This task is organization and situation specific. It should be planned as a “switch off the light operation,” but with the ability to start up the environment again if there are unexpected dependencies. This task should be considered for every application during the application migration activities.
Plan the domain rename and impact
After the FQDN forest and domain target structure is defined, the domain rename operation must be planed.
The technical details are described in the TechNet article How Domain Rename Works (http://technet.microsoft.com/de-de/library/cc738208(WS.10).aspx).
Test the domain rename and validate the application support
The domain rename operation should be thoroughly tested and validated in a lab environment. The complete domain rename procedure, including fallback procedures, should be performed multiple times as a “fire drill”
to train administrators to rename the production forest. The detailed steps of the domain rename operations are described in the TechNet article How Domain Rename Works
(http://technet.microsoft.com/de-de/library/cc738208(WS.10).aspx).
During the domain rename test, you must verify the application compatibility of your applications.
Prepare the domain rename execution
After the successful domain rename and procedure refinement in the lab, the production environment can be prepared for the domain rename operation.
Perform the domain rename
The domain rename operation itself should be executed in an appropriate extended maintenance window.
The organization should consider that this time window has to be long enough to fix potential issues.
Fix potential issues
After executing the domain rename, a test of all critical applications and services has to be performed in order to exclude instant issues. The organization should plan for the possibility that some of the applications and services might not be available immediately after the rename operation. All tests, the decision for a fallback, and the execution of a fallback operation have to executable in the support window that is assigned for the rename operation.
There are two fallback options if the rename operation breaks an application or a service:
Execute another rename operation to re-establish the old naming configuration
Execute a forest recovery operation to re-establish the old naming configuration
If the rename operation itself fails, either you can repeat the operation after you have fixed issues that are reported in log and trace files or you have to execute a forest recovery operation to re-establish the old forest configuration.
6 Analysis of your SLD environment
In order to understand how an organization might be affected by SLD name issues, you must have a thorough understanding of all aspects of the organization’s Active Directory Domain Services configuration and usage, including the following:
Active Directory names and names of other Kerberos realms
This includes all AD forests and domains, in and outside of trust relationships, as well as names of other Kerberos realms that have or don’t have a trust relationship with the organization’s AD DS. You must also understand the naming configurations of clients, servers, and services in the environment, including special naming configurations like disjoint namespaces.
Applications that use Active Directory services
Because moving away from a SLD configuration changes distinguished names and might change security contexts in your Active Directory environment, many applications will be directly affected. It is therefore critical to have a complete understanding of the applications that access the Active Directory environment for authentication, for authorization, or to retrieve data.
Applications that use Active Directory related names
Because moving away from a SLD configuration – either by domain rename or by domain migration—
changes the domain name suffix and thus the fully qualified host names in your Active Directory
environment, applications that use these names will be directly affected. If you rename the root domain, then the DN path for schema and configuration and domain partitions also change. It is therefore essential to understand which applications will be affected by a possible change of the names of Active Directory partitions, member servers, and workstations.
The logical internal AD structure and where objects are stored
Migrating away from a SLD configuration might include a coexistence phase where both the SLD and the FQDN configurations are operational and in productive use. In order to synchronize data between both environments and to avoid conflicts in data storage and access, you must have a clear understanding of the inner semantics of the Active Directory.
Your IT roadmap and how a SLD configuration limits your options
Moving away from a SLD configuration mitigates risks that are related to the future advancement of IT services in an organization. When planning for mitigation, you should have a clear picture of the timeline for future product introductions and the support lifecycle of current products in your infrastructure.
The analysis is the foundation for the planning and for the decision on the SLD mitigation strategy.
7 Forest name selection
The resolution of host and service names provided by the Domain Name System (DNS) servers is essential for the operation of Windows operating systems, AD DS, and most applications. Without proper name resolution, clients cannot locate resources on the network. It is critical that the design of the DNS namespace be created with AD DS in mind and that the namespace that exists on the Internet does not conflict with the organization's internal namespace.
7.1 General considerations
Microsoft recommends using an officially registered DNS namespace for new forest environments. The namespace should be as static as possible and not prone to future change, e.g., through mergers or organizational change. That’s why you should use generic name components and avoiding using organization or department names.
It is a best practice to use the namespace to distinguish between internal and external services. This distinction can be made by using different parts of the same namespace hierarchy or by using a completely different namespace hierarchy. When choosing internal DNS names to use for your Active Directory domains, start with the registered DNS domain name suffix that your organization has reserved for use on the Internet (such as company.com) and combine this name with either a place holder (e.g., “corp”, “ds”, “int”, etc.), or geographical or other static names used in your organization to form full names for your Active Directory domains.
Migration considerations
For the name of a new FQDN forest, it is technically possible and supported to use a name that is
subordinate to the existing SLD forest namespace. For example, if your existing forest uses the names aa for the forest root domain and dom.aa for the second domain, you could use new.dom.aa as the name of the forest root in the FQDN forest. This configuration will require some additional configuration in the trust to enable the correct routing of name suffixes across the forests for authentication and resource ticket requests.
7.2 Disjoint Namespaces
A disjoint namespace in AD DS occurs when one or more domain member computers or domain controllers have a primary Domain Name Service (DNS) suffix that does not match the DNS name of the Active Directory domain of which the computers are members. For example, a member computer that uses a primary DNS suffix of corp.company.com in an Active Directory domain named na.corp.company.com is using a disjoint namespace.
A disjoint namespace is more complex to administer, maintain, and troubleshoot than a contiguous namespace. In a contiguous namespace, the primary DNS suffix matches the DNS name assigned to an Active Directory domain. Network applications that are written to assume that the Active Directory
namespace is identical to the primary DNS suffix for all domain member computers do not function properly in a disjoint namespace.
A disjoint namespace should work (and is supported) in the following situations:
When a forest with multiple Active Directory domains uses a single DNS namespace, which is also known as a DNS zone
An example of this is a company that created regional domains in Active Directory with names such as na.corp.company.com, sa.corp.company.com, and asia.corp.company.com and uses a single DNS namespace, such as corp.company.com.
When a single Active Directory domain is split into separate DNS namespaces
One example of this is a company that has an Active Directory domain of corp.contoso.com that uses DNS zones such as hr.corp.contoso.com, production.corp.contoso.com, and
it.corp.contoso.com.
A disjoint namespace does not work properly (and is not supported) in the following situations:
A disjoint suffix used by domain members matches an Active Directory domain name in this or another forest. This will break Kerberos name-suffix routing.
The same disjoint suffix is used in another forest. This prevents routing these suffixes uniquely between forests.
When a domain member certification authority (CA) server changes its fully qualified domain name (FQDN) so that it no longer use the same primary DNS suffix that is used by the domain controllers of the domain to which the CA server is a member. In this case, you may have problems validating certificates the CA server issued, depending on what DNS names are used in the CRL Distribution Points. But if you place a CA server in a stable disjoint namespace, it works properly and is supported.
Considerations for disjoint namespaces
In general, there needs to be a compelling advantage to running a disjoint namespace to justify the additional configuration overhead, scenario complexity, and TCO that you will experience as a result of this
configuration.
The following considerations might help you decide if you should use a disjoint namespace.
Application compatibility
As previously mentioned, a disjoint namespace can cause problems for any applications and services that are written to assume that a computer’s primary DNS suffix is identical to the name of the domain of which it is a member. Before you deploy a disjoint namespace, you must check applications for compatibility issues.
Also, be sure to check the compatibility of all applications that you use when you perform your analysis. This includes applications from Microsoft and from other software developers.
Advantages of disjoint namespaces
Using a disjoint namespace can have the following advantages:
Because the primary DNS suffix of a computer can indicate different information, you can manage the DNS namespace separately from the Active Directory domain name.
You can separate the DNS namespace based on business structure or geographical location. For example, you can separate the namespace based on business unit names or physical location such as continent, country/region, or building (subject to the supported and unsupported constraints listed above).
Further splitting of the namespace of a large single Active Directory domain environment may help avoid storing and administering hundreds of thousands of records in a single DNS zone.
Disadvantages of disjoint namespaces
Using a disjoint namespace can have the following disadvantages:
You must create and manage separate DNS zones for each Active Directory domain in the forest that has member computers that use a disjoint namespace. (That is, it requires an additional and more complex configuration.)
You must perform manual steps to modify and manage the Active Directory attribute that allows domain members to use alternate primary DNS suffixes.
To optimize name resolution, you must perform manual steps to modify and maintain Group Policy to configure member computers with alternate primary DNS suffixes.
When your environment requires multiple primary DNS suffixes, you must configure the DNS suffix search order for all of the Active Directory domains in the forest appropriately. To set the DNS suffix search order, you can use Group Policy objects or Dynamic Host Configuration Protocol (DHCP) Server service parameters. You can also modify the registry.
You must carefully test all applications for compatibility issues.
Migration considerations
During the migration, the intention is to support NTLM and Kerberos for authentication across forest
boundaries. Kerberos uses service principal names (SPNs), which contain FQDN host names of services. If the current SLD environment uses a disjoint namespace and the new forest will also be operated with a disjoint namespace, then the namespace planning has to make sure that SPNs are unique across forests and that overlapping Kerberos SPN suffixes are avoided.
If the disjoint namespace reflects location, a “per-location” migration of this namespace might be feasible.
However this would require that an entire location be migrated over in a relatively short time span with Kerberos authentication interruption. This adds additional complexity and risk to the application migration.
A completely new disjoint namespace without overlap (such as, hostname.site.corp.company.com) with regards to the existing disjoint namespace names (such as, hostname.site.company.com) is technically possible as it would avoid overlapping Kerberos SPN suffixes.
Microsoft recommends against introducing another disjoint namespace in the environment, if the DNS infrastructure and processes supports a joint namespace for the environment.
7.3 Discontinuous Namespaces
A discontinuous namespace, also referred to as non-contiguous namespace, is one in which the domains in a forest are not lined up in one hierarchical DNS tree. If the domains in a forest have discontinuous DNS names, they form separate trees of hierarchical domains within the forest. An Active Directory forest can contain one or more domain trees. An example of a multi-tree forest would be a forest containing the domains contoso.com and fabrikam.net.
Active Directory forests with multiple domain trees are considered well-formed forests and are fully supported by Microsoft.
The first domain created in a forest always has the role of the forest root domain, independent of other DNS trees in the forest.
A discontinuous namespace is more complex to administer, maintain, and troubleshoot than a contiguous namespace. For example, special DNS suffix configuration on clients is required to enable cross-domain use of short host names.
7.4 General recommendation
Start your Active Directory with a simple and clear design. For most organizations, a single forest, single domain design, also known as a single domain forest, will fit.
For the DNS namespace selection, there are three main recommendations:
For your trees of domains, use DNS namespaces that are officially registered for your organization
Use separate internal and external DNS namespaces
If possible, avoid the use of a disjoint namespace, because it is more complex to introduce, maintain, and operate.
8 Execute a Domain Migration
8.1 Building the new FQDN Active Directory forest
The DNS namespace design is one important aspect in an Active Directory design; however, it only follows the decisions on the number of forests and domains. The number of domains, Organizational Unit (OU) structure within these domains, physical design (sites and subnets), and forest or domain functional levels are other fundamental aspects that need to be decided before the first domain controller in the new forest can be promoted.
The following chapters are not intended to replace any of the existing documentation about Active Directory design. We still do strongly recommend studying this documentation or, in even more complex organizations, seeking consulting services support during this design phase. However, we want to stress a couple of aspects an organization might want to consider during the design of the new AD infrastructure in the light of an SLD to FQDN migration.
Another great source of input for the new design should be your own experience gathered from operating your existing systems. You should take some time to document these lessons learned from your networking and AD teams as well as your security staff, Helpdesk, and business units responsible for your line-of-business applications.
8.1.1 Number of domains - empty forest root domain
In the past, organizations sometimes deployed a so-called “placeholder” or “empty root” domain. However, experience shows that the most efficient approach for most organizations is to strictly minimize the number of domains, that is, to start with a single-forest/single-domain design, and add domains only when concrete reasons (such as, geopolitical or network replication considerations) dictate creating another domain instance. Also note that security and isolation considerations do not motivate an empty root domain, as domains cannot be considered a security boundary in AD DS.
8.1.2 Physical structure (sites and subnets)
Another potential optimization could be achieved by reevaluating the number and distribution of domain controllers, that is, by considering a stronger consolidation of domain controllers if your network infrastructure permits. Start your deployment from the central hub locations of your network and expand from there if decentralized domain controller installation is needed. Also, consider the use of read-only domain controllers.
Another consideration should be the fact that Windows Server® 2008 and Windows Server® 2008 R2 (as well as their client counterparts, Windows Vista® and Windows® 7) have the IPv6 protocol enabled by default. A recommended best practice is to leave IPv6 enabled and bound whenever possible. Even if you decide to disable IPv6 on your systems, you should be prepared to define at least one IPv6 subnet and assign it to one of your Active Directory sites (for example, the Default-First-Site-Name site).
8.1.3 OU structure
Two main criteria—delegation of administration and application of Group Policy settings to user and computer objects —will influence your organizational unit structure. Again, creating a new Active Directory forest will present a great opportunity to assess your existing system and identify areas of improvement or consolidation. On the other hand, changing an OU structure is relatively easy to achieve post-deployment, compared with changing forest structure.
8.1.4 Domain controller operation system version
Microsoft recommends that you install the latest version and service pack of the Windows Server operating system on the new domain controller computers. This enables you to leverage the most advanced server features, best hardware support, and the latest security patch and hotfix level.
Another trend which can be seen both in data centers as well as branch office scenarios is, of course, server virtualization as well as the fact that the newer server operation systems are built as 64-bit platforms only.
8.1.5 Functional levels
A new forest infrastructure brings the opportunity to build a completely legacy free environment. Given that all new domain controllers are built using the latest version of the Windows Server operating system, there is a unique opportunity to switch to the highest domain and forest functional level right from the beginning and by doing so immediately enable the most advanced Active Directory features. Examples are the Active Directory Recycle Bin, which allows for quick recovery of deleted Active Directory objects, and Fine-Grained
A new forest infrastructure brings the opportunity to build a completely legacy free environment. Given that all new domain controllers are built using the latest version of the Windows Server operating system, there is a unique opportunity to switch to the highest domain and forest functional level right from the beginning and by doing so immediately enable the most advanced Active Directory features. Examples are the Active Directory Recycle Bin, which allows for quick recovery of deleted Active Directory objects, and Fine-Grained