Whitepaper Single Label Domain V132

Single-Label-Domain - Considerations,
migration and co-existencein Active

Directory Domain Services (AD DS)
Considerations, migration and co-existence
Prepared for
Microsoft Corporation
4/23/15
Version 1 / Final
Prepared by
Holger Reiners
Principal Consultant
Holger.Reiners@microsoft.com
Jrg Finkeisen
Architect
joergf@microsoft.com
Contributors:
Michael Wirth
mwirth@microsoft.com
Single-Label-Domain - Considerations, migration and co-existence, Considerations, migration and coexistence, Version 1.32, Final
267673279 / 01.09.2011, Rev. 5
Copyright
Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real
company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or
should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting
the rights under copyright, no part of this document may be reproduced, stored in, or introduced into a
retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording,
or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property.
2011 Microsoft Corporation. All rights reserved.
Active Directory, Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.
Single-Label-Domain - Considerations, migration and co-existence, Considerations, migration and co-existence, Version 1.32, Final
267673279 / 1.09.2011, Rev. 5
page 1
Table of Contents
1
Management Summary............................................................................................................................. 5
Technical Background............................................................................................................................... 6
Single-label domain scenarios.................................................................................................................. 8
Options to move away from a SLD configuration......................................................................................9

4.1
Domain Migration.............................................................................................................................. 9
4.2
Domain Rename............................................................................................................................... 9
4.3
Pros and cons of migration vs. domain rename..............................................................................11
4.3.1
Domain Migration........................................................................................................................ 11
4.3.2
Domain Rename......................................................................................................................... 12
4.4
Transition option decision............................................................................................................... 12
4.4.1
Domain Migration........................................................................................................................ 12
4.4.2
Domain Rename......................................................................................................................... 13
Plan the transition................................................................................................................................... 15
Analysis of your SLD environment.......................................................................................................... 19
Forest name selection............................................................................................................................. 20
7.1
General considerations................................................................................................................... 20
7.2
Disjoint Namespaces...................................................................................................................... 20
7.3
Discontinuous Namespaces........................................................................................................... 22
7.4
General recommendation............................................................................................................... 22
Execute a Domain Migration................................................................................................................... 23

8.1
Building the new FQDN Active Directory forest...............................................................................23
8.1.1
Number of domains - empty forest root domain..........................................................................23
8.1.2
Physical structure (sites and subnets)........................................................................................ 23
8.1.3
OU structure................................................................................................................................ 23
8.1.4
Domain controller operation system version...............................................................................23
8.1.5
Functional levels......................................................................................................................... 24
8.1.6
Schema extensions..................................................................................................................... 24
8.2
Co-existence solution...................................................................................................................... 24
8.3
Application Migration....................................................................................................................... 25
8.3.1
Application usage of Active Directory.......................................................................................... 25
8.3.2
Application categories................................................................................................................. 27
8.3.2.1
Application Questionnaire................................................................................................... 27
8.3.2.2
Modeling Guidelines............................................................................................................ 28
8.3.2.3
Service Migration and Active Directory Object Migration.....................................................29
8.3.2.4
Integration Depth................................................................................................................. 29
8.3.2.5
Resulting Application Categories......................................................................................... 30
8.3.3
General application migration recommendations........................................................................32

267673279 / 1.09.2011, Rev. 5
page 2
8.3.4
Customer experiences................................................................................................................ 32
8.3.5
Application Migration Center for application owners...................................................................33
8.4
Application migration strategies...................................................................................................... 33
8.4.1
Migration Preparation.................................................................................................................. 34
8.4.2
Category 1 - Complex integration............................................................................................... 35
8.4.2.1
C1 - Initial configuration...................................................................................................... 35
8.4.2.2
C1 - migration ready............................................................................................................ 36
8.4.2.3
C1 - application migration................................................................................................... 37
8.4.2.4
C1 - final state..................................................................................................................... 37
8.4.2.5
C1 - Exchange co-existence states for all categories..........................................................38
8.4.2.6
C1 - in trusting domains...................................................................................................... 38
8.4.3
8.4.3.1
C2 - initial configuration....................................................................................................... 39
8.4.3.2
C2 - Case 1 - application can work with migrated objects, even if disabled........................40
8.4.3.3
C2 - Case 1 - application is migrated to new forest, users still in migration........................41
8.4.3.4
C2 - Case 2 - application cant work with migrated objects, sync to meta store..................42
8.4.3.5
C2 - Case 2 - application migration.....................................................................................43
8.4.3.6
C2 - final state - application and objects are migrated to new forest...................................44
8.4.3.7
C2 - effort drivers for the configuration change...................................................................44
8.4.3.8
8.4.3.9
C2 - experiences................................................................................................................. 45
8.4.4
Category 3 - LOW AD integration depth, HIGH service integration depth...................................46
8.4.4.1
C3 - Initial configuration...................................................................................................... 46
8.4.4.2
SID based........................................................................................................................... 47
8.4.4.3
Name mapping.................................................................................................................... 53
8.4.4.4
C3 - Effort drivers................................................................................................................ 56
8.4.5
Category 4 - LOW AD integration depth, LOW service integration depth....................................57
8.4.5.1
8.4.5.2
C4 - Migration...................................................................................................................... 58
8.4.5.3
C4 - final.............................................................................................................................. 59
8.4.5.4
8.4.6
Category 5 - Create new service in new environment.................................................................60
8.4.6.1
8.4.6.2
C5 - final.............................................................................................................................. 61
8.4.6.3
8.4.7
9
Category 2 - HIGH AD integration depth, LOW service integration depth...................................39
Summary..................................................................................................................................... 61
Appendix................................................................................................................................................. 62
9.1
Internet references.......................................................................................................................... 62
9.1.1
Domain name information........................................................................................................... 62

267673279 / 1.09.2011, Rev. 5
page 3
9.1.2
Migration information.................................................................................................................. 62
9.1.3
Rename information.................................................................................................................... 62
9.1.4
Product support statements........................................................................................................ 63
267673279 / 1.09.2011, Rev. 5
page 4
Figure index
Figure 1 - forest root domain rename............................................................................................................. 10
Figure 2 Transition phases and activities........................................................................................................ 16
Figure 3 Application categories according to integration depths.....................................................................30
Figure 4 Migration preparation........................................................................................................................ 34
Figure 5 C1 - initial configuration.................................................................................................................... 35
Figure 6 C1 - migration ready......................................................................................................................... 36
Figure 7 C1 - application migration................................................................................................................. 37
Figure 8 C1 - final state.................................................................................................................................. 37
Figure 9 C1 - Exchange co-existance states for all categories.......................................................................38
Figure 10 C2 - initial configuration.................................................................................................................. 39
Figure 11 C2 - application can work with migrated objects, even if disabled..................................................40
Figure 12 C2 - case 1 - application migration to the new forest, users still in migration..................................41
Figure 13 C2 - application cant work with migrated objects, sync to meta store............................................42
Figure 14 C2 - case 2 - application migration................................................................................................. 43
Figure 15 C2 - final state................................................................................................................................ 44
Figure 17 C3 - SID based - some security principals are migrated and active...............................................47
Figure 18 C3 - SID based - option 1 - all security principals are migrated and active.....................................48
Figure 19 C3 - SID based - option 1 - server migration..................................................................................49
Figure 20 C3 - SID based - Opt.2 - some objects are migrated and active.....................................................50
Figure 21 C3 - SID based - option 2 - reACL the resources...........................................................................51
Figure 22 C3 -SID based - final...................................................................................................................... 52
Figure 23 C3 - name mapping - some security principals are migrated and active........................................53
Figure 24 C3 - name mapping - name remapping.......................................................................................... 54
Figure 25 C3 - name mapping - resource server migration............................................................................55
Figure 26 C3 - name mapping - final.............................................................................................................. 56
Figure 28 C4 - migration................................................................................................................................. 58
Figure 29 C4 - final......................................................................................................................................... 59
Figure 31 C5 - final configuration.................................................................................................................... 61
267673279 / 1.09.2011, Rev. 5
page 5
Table index
Table 1 C2 - effort driver details...................................................................................................................... 45
267673279 / 1.09.2011, Rev. 5
page 6
Appendix
1 Management Summary
An Active Directory domain name that contains one or more labels separated by a dot is referred to as a fully
qualified domain name with two or more names and it will be referred as FQDN in this document. In contrast
there is the concept of single-label domain (SLD), which refers to Active Directory domain names with only
one label.
Given that SLD is not a commonly deployed configuration and that many Microsoft and third-party
applications have not been tested under an SLD configuration, Microsoft recommends FQDN Active
Directory deployments. For companies who have deployed SLD, they should transition to an FQDN Active
Directory deployment. This will ensure that they get the most value out of their deployed applications.
For companies that will be evaluating transition to FQDN from SLD configurations, this document describes
the options and considerations that they will need to take into account. In particular it describes Domain
Migration and Domain Rename operations and explains the different considerations of these two options, so
that companies can build a transition plan that makes sense to them.
Long-term, the goal of Microsoft is to have customer infrastructures using common, tested configurations to
minimize costs and effort to administrate the Active Directory (AD) and DNS environment. The use of multilabel names is Microsofts recommended naming configuration.
Organizations that have SLD configurations should begin by analyzing their current environment to find out
the best mitigation option.
Domain rename operations might be feasible in certain scenarios, mainly for smaller organizations or those
that can tolerate some outage while removing and reinstalling applications that are incompatible with domain
rename.
The migration into a non-SLD forest and domain structure should be well aligned with the product lifecycle
and the future IT infrastructure roadmap of the organization.
The transition from a single label to a fully qualified Active Directory domain namespace puts your clients,
servers, domain controllers, the operating systems and applications in a namespace configuration that can
deliver the following benefits:
Provides the broadest application support, including the ability to deploy applications on day 1 after
release without fear that support will be deprecated in a future release, will be deferred until a future
release, or will never support forests configured with SLDs, possibly even blocking installation in
SLDs.
Receives the highest number of test passes by Microsoft and third-party application developers
Requires the least additional configuration to register and resolve DNS names of interest
Delivers the lowest total cost of ownership (TCO) by reducing complex configurations and by
consolidating forest and domain structures
Enables enhanced security capabilities of new versions of AD DS
Aligns the namespace assigned to your forest with same type of namespace assigned to the top
thousands of domains deployed and operated by other customers over the last decade or more
Receive Microsoft cloud support, because only domains with fully qualified DNS names are
supported by Microsoft cloud services such as BPOS and Office 365
267673279 / 1.09.2011, Rev. 5
page 7
Appendix
2 Technical Background
The Domain Name System (DNS) defines a hierarchical namespace forming a tree of domain names. The
domain name syntax definitions are specified in several RFCs (mainly, 1035, 1123 and 2181).
Active Directory Domain Services (AD DS) uses a DNS namespace format for domains in an Active Directory
forest. The distinguished name (DN) paths of naming contexts and objects are derived from the DNS name
assigned to the forest root domain as well as from the domain that owns the object. The recommended DNS
name assigned to an Active Directory domain consists of two or more name parts or labels separated by a .
(dot), such as, contoso.com. The AD DNS domain can be subordinate to a top-level domain, such as .com,
or subordinate to your internal DNS namespace (that is, domain corp.contoso.com can be subordinate to the
internal namespace of contoso.com). It is recommended that your AD domain names be part of an officially
registered DNS namespace that is owned by your company or organization.
Single-label DNS names are DNS names that consist of only one domain label and do not contain a dot
(except the trailing dot representing the DNS root domain, that is omitted in most use cases). For example
contoso, com, net, or local are single-label domain (SLD) names while contoso.com, contoso.net, or
contoso.internal are fully qualified DNS names. SLD configurations in Active Directory are created when an
administrator decides to assign an SLD name to one or more domains in an Active Directory forest. The most
common SLD configuration is that the forest root domain (FRD) has been assigned a single label DNS
name.
For the purpose of this whitepaper, we will distinguish between single-label domain (SLD) names and fully
qualified domain names (FQDN), that is, domain names with more than one label.
SLD names are not strictly prohibited by the DNS RFCs, but the RFCs are typically referring to the non-SLD
configurations that are seen as a worldwide common DNS configuration.
As Active Directory provides infrastructure services like authentication, authorization and directory data
storage on a network, the namespace that your organization chooses for Active Directory forests and
domains directly affects applications that use Active Directory. When we refer to Single Label Domain names
in this whitepaper, we implicitly mean the DNS name assigned to a domain in an Active Directory forest.
Microsoft published the following detailed information, advisory, and recommendations for Active Directory in
SLD configurations:
Information about configuring Active Directory domains by using single-label DNS names
Warnings installing Active Directory Domain Services on Windows Server 2008 and Windows Server 2008
R2 in domains with single-label DNS names
Unable to select DNS Server role when adding a domain controller into an existing Active Directory domain
Some Microsoft products can be installed in a SLD name configuration. When the installation is using an
SLD, certain considerations might apply, as noted by Microsoft Product Groups. Though existing Microsoft
products can continue to function using SLD, it is not a recommended configuration for future deployments,
and might not work with some products or versions. Other Microsoft or third-party applications that end-users
might want to run in an environment might not be compatible with a SLD. Microsoft recommends deploying
an infrastructure using common, tested configurations to minimize extra deployment and testing costs.
Some existing applications that support SLD today have announced their intent to drop SLD support in future
versions.
New, more advanced applications typically dont support SLD and will not be adding such support going
forward.
267673279 / 1.09.2011, Rev. 5
page 8
Appendix
For application development teams, the additional test overhead required to validate application compatibility
in SLD configuration so they can be supported for production deployment represents an effective doubling in
test cost across major and minor version releases, service pack updates and QFE updates; this cost is not
justified by the small number of forests configured to use SLD. The overhead prevents application
developers from pursuing new and more interesting features that improve product relevance and
competitiveness in the market.
Therefore, there might be incompatibilities when products are implemented in an SLD environment.
Sometimes there are known issues and workarounds to mitigate the SLD configurations. Some products are
known to be blocked by SLD configuration.
Organizations with various namespace configurations (including SLD) can obtain support subject to the
terms of the Microsoft Support Lifecycle policy and their Microsoft support agreement. This means that
Microsoft Premier Support customers will receive equivalent support for current Microsoft products running in
either an SLD or a FQDN environment. In either case, Microsoft will evaluate the need for a hotfix in
response to a support incident on a case-by-case basis.
In order to protect customers from accidentally deploying a new SLD, the Active Directory Installation Wizard
(DCPromo.exe) in Windows Server 2008 warns against creating a new SLD and in Windows Server 2008 R2
explicitly blocks creating a new SLD.
For detailed information on supported products and configurations, refer to the following information on the
Microsoft website:
Microsoft support for Single Label Domains
DNS Namespace Planning Support
Namespace Planning and Product Compatibility
267673279 / 1.09.2011, Rev. 5
page 9
Appendix
3 SLD scenarios
In many organizations, Active Directory Domain Service (AD DS) is the major infrastructure component that
uses the DNS system, and it is tightly bound to the DNS structure. An Active Directory SLD configuration is
defined when one of the Active Directory domains in a forest uses a SLD name as the Active Directory
domain name.
Some typical SLD domain configurations are:
SLD single-domain forest

The forest consists of one domain. The domain name is an SLD name, for example, company. All
users and resources are located in this domain.
Empty SLD root and one or more domains

The forest root domain has a SLD name that forms the top of a domain hierarchy. In most cases, the
root domain (such as company.) has been created only for administrative or political purposes and
does not contain any objects except the standard objects. It is therefore referred to as an empty
root domain. The users and resources are contained in one or more subdomains. (e.g.
emea.company., division.company., and so on.)
Trust relationship with a SLD domain or forest

There might be trust relationships between a non-SLD Active Directory configuration and a SLD
Active Directory forest or domain. Trusts can be one-way or two-way.
Acquisition and merger of a SLD Active Directory

During an acquisition and merger scenario, the SLD configuration can be introduced into an existing
environment. In this scenario, a trust with the SLD forest can be established or the SLD forest can be
the source or the target of a migration operation. Microsoft strongly recommends against using a
forest with one or more SLD named domains as the target of a migration operation.
267673279 / 1.09.2011, Rev. 5
page 10
Appendix
4 Options to move away from an SLD configuration

Active Directory Domain Service is the foundation for many other services in an organizations IT
environment. These services determine the possible options to move away from a SLD configuration.
Basically, there are two options for transitioning from a single-label DNS domain name to a fully qualified
DNS name, which are both non-trivial.
The following sections are an overview of the possible mitigation paths.
267673279 / 1.09.2011, Rev. 5
page 11
Appendix
4.1
Domain Migration
The preferred approach to move from an SLD Active Directory configuration to a FQDN Active Directory
configuration is the forest and domain migration. This is the same operation as seen in many merger and
acquisition scenarios or in forest consolidation operations.
The migration approach requires building and operating a new FQDN forest in parallel to the existing SLD
Active Directory forest. The design of the new FQDN forest and domain structure is the opportunity to
enhance and optimize the configuration to adapt the Active Directory to new and future requirements. When
the FQDN forest is fully operational, migration tools will have to be used to move objects to the new forest.
Careful planning is required to avoid breaking application functionality. During parallel operations of the
Active Directory forests, the coexistence requires ongoing synchronization of certain data between forests.
Additionally, the provisioning of a consistent data store might be required to provide application data
independently of both forests to mitigate effects of object DN name changes due to migration.
The sequence and speed of Active Directory object migration and migration of member servers and
workstations should be well aligned to the application lifecycle in the organization. It also depends on the IT
organizations staff capacity and general change capabilities.
The migration of security principal objects requires the usage of migration tools, which are available from
several vendors. Microsoft offers the Active Directory Migration Tool (ADMT) that can be downloaded free of
charge from the Internet.
For further information about Active Directory migration, please refer to the ADMT Guide: Migrating and
Restructuring Active Directory Domains (http://technet.microsoft.com/en-us/library/cc974332(WS.10).aspx ).
267673279 / 1.09.2011, Rev. 5
page 12
Appendix
4.2
Domain Rename
The domain rename option was introduced with Windows Server 2003 Active Directory and enables the
rename of the NetBIOS and DNS domain name of any domain of an Active Directory forest in a single
operation. You can also use the domain rename operation to restructure domains i.e., child domains can
be restructured to grandchild or tree domains and tree domains can be restructured to child or grandchild
domains. Changing the NetBIOS of domains with a rename operation is optional. Certain target
configurations can require two or more subsequent rename operations.
The following restrictions are related to a domain rename operation:
The new domain name cannot be the same as an existing domain name in the forest.
It is not possible to change which domain is the forest root domain.
It is not possible to add domains to the forest or to drop domains from the forest via the domain
rename operation. Domains can be added or removed by using the Active Directory installation
wizard after the rename operation is complete.
NetBIOS and DNS names assigned as new names to domains in the forest must be unique.
The target of the rename operation has to be a well-formed forest.

If you want to preserve a certain domain hierarchy you will have to rename all domains in a tree. This can be
done in a single rename operation.
You can also rename a single domain, such as the root domain, in a tree. This transforms the former
subordinate domains into a new tree in the forest while preserving the names of these subordinate domains.
In this operation, only the root domain of the tree changes its name. In most SLD configurations, the SLD
domain is also the forest root domain.
Figure 1 - Forest root domain rename
Renaming the forest root domain changes the distinguished name (DN) path for the schema and the
configuration partition, while the DNS and NetBIOS names of all other domains remain unchanged.
In a first step, the domain rename operation prepares the domain controllers in the forest that should be used
for the rename operation. The new DNS namespace will be manifested as XML statements in a forest
description file. The domain naming master FSMO holder transforms this file into a domain rename script
and stores that script to an attribute that is replicated to all domain controllers in the forest.
After the preparation is done, the administrator initiates the rename execution. With the start of the rename
execution, all domain controllers in the forest will reconfigure themselves to reflect the new forest
configuration and then restart with the new configuration. During this time, the Active Directory service is not
available for client users, services, or applications.
267673279 / 1.09.2011, Rev. 5
page 13
Appendix
For further details regarding the planning and execution of a domain rename operation, refer to the following
information on Microsoft TechNet:
What Is Domain Rename?

How Domain Rename Works
Renaming a Domain: Process and Side Effects
To make the rename operation effective, after the operation it is necessary to:
restart all application servers and workstations in the renamed domains twice
re-create trusts with external domains
(If the root domain is renamed, recreate the forests and Kerberos realms trusts)
rejoin computers with NT 4.0 operating system to the renamed domain
The risk and complexity of a domain rename operation depend on many factors.
The top challenge of domain rename is application compatibility. This has to be investigated and tested for
applications on all servers and workstations in your Active Directory forest. The most important question is:
Does the application have hard-coded references to the old DNS (or NetBIOS) domain name or its hierarchy
within the forest?
If you cant answer this question or your vendor doesnt know, you must assume that the application is not
compatible with domain rename. At this point, youre now faced with having to remove all applications that
are incompatible or whose compatibility is unknown, perform the domain rename, and then reinstall the
applications; otherwise, the rename operation is effectively blocked.
The application compatibility issue is critical since the rename operation will be effective for all services and
applications at one single point in time, the instant after the domain controllers have rebooted. Thats why the
domain rename operation requires an intense organizational effort to coordinate several infrastructure and
application dependencies due to the single point in time of the domain rename operation.
Clients joined to renamed domains have to be rebooted twice to reflect the rename operation. This task is
easier for desktop computers but is more challenging to enforce for roaming laptops.
Not all applications and server-based applications are compatible with the domain rename feature that is
supported on domain controllers running Windows Server 2003 or later. These incompatibilities will either
block the domain rename feature or make the use of the domain rename feature more difficult when you try
to rename an SLD name to a fully qualified domain name configuration.
Examples of applications that are incompatible with domain rename include, but are not limited to, the
following products:
Microsoft Exchange 2000 Server

Microsoft Exchange Server 2007
Microsoft Exchange Server 2010
Microsoft Internet Security and Acceleration (ISA) Server 2004
Microsoft Live Communications Server 2005
Microsoft Operations Manager 2005
Microsoft SharePoint Portal Server 2003
Microsoft Systems Management Server (SMS) 2003
Microsoft Office Communications Server 2007
For the most updated list of applications that are incompatible with domain rename, see Information
about configuring Active Directory domains by using single-label DNS names
(http://support.microsoft.com/kb/300684).
267673279 / 1.09.2011, Rev. 5
page 14
Appendix
4.3
Pros and cons of migration versus domain rename
267673279 / 1.09.2011, Rev. 5
page 15
Appendix
4.3.1
Domain Migration
Pro
Con
Can create optimal forest based on experience

from last decade.
Requires duplicate hardware for testing and

production.
No application compatibility issues.
Requires twice as many software licenses for

testing and production.
Fully supported with no ambiguity
Requires guaranteed install of all Microsoft and

third-party party applications.
Can prepare the destination forest out-of-band for

near-to-immediate cutover from old to new
environment
Contributes to access token bloat; careful planning

is required.
Tools and processes for domain migration are well

understood.
Migration tools do not exist to migrate application

state and some AD object classes, including
delegation model security descriptors defined in
configuration and domain naming contexts.
Destination domain can be prepared out-of-band

(unlike a SLD-to-FQDN transition using domain
rename with domain rename-incompatible
applications).
Custom schema changes not modified by

application need to be recreated in destination
forest.
Not all applications support the use of SID history
Retiring SID history at the end of the migration can
be challenging.
267673279 / 1.09.2011, Rev. 5
page 16
Appendix
4.3.2
Domain Rename
Pro
Con
Actual domain rename can be performed in a short

time frame, compared to a migration time frame.
Application compatibility can be a major blocker if

you have domain rename incompatible applications
or applications for which the compatibility status is
unknown
Child domains can be restructured so that they

maintain the same DNS FQDN or NetBIOS domain
name as when the domain was created and the
application was installed, which means that users log
into the same domain.
There is less experience among support

professionals around the use of domain rename
compared to migration
User accounts, computer accounts, groups, group

memberships and user profiles dont have to be
migrated.
The toolset around bulk operations for the renamed

domains needs improvement. (twice reboot of
clients, delete and recreate and validate external
trusts)
No increase in the access token size, because there

is no use of SID history (no token bloat).
Requires an intense organizational effort to

coordinate several infrastructure and application
dependencies due to the single point in time of the
domain rename operation
User remains in same domain; there is no SID

history to manage or retire; the domain retains policy,
policy links, OU structure, sites, site links, site-to-site
link mappings, schema revisions, the rich delegation
model defined in configuration and domain partitions,
267673279 / 1.09.2011, Rev. 5
page 17
Appendix
4.4
Transition option decision
The decision for the right transition option for the organization is a complex and individual decision process.
The following paragraphs will discuss aspects that should be considered.
267673279 / 1.09.2011, Rev. 5
page 18
Appendix
4.4.1
Domain Migration
If the domain rename is blocked by unsupported applications or is of high risk to the organization, the Active
Directory forest and domain migration is the preferred option. The migration approach requires more in terms
of time, budget, and personnel resources than the domain rename. But advantages are the lower risk,
because the migration happens in smaller sets of objects, and the ability to rollback to the source
environment if there are issues. In a migration process, you can do a large part of the work out-of-band,
without affecting the availability of applications and services in your production environment.
During the migration, you need expertise for all your applications and services. You will need a clear
understanding of their integration with Active Directory, but you will also need to put attention on seemingly
simple questions like: Do I have access to the installation media?
There are two main options for the general migration approach and shaded variants in between.
Fast migration approach
With the fast migration approach, all Active Directory objects and applications will be migrated in a very short
timeframe. Normally this will require additional and timely extra effort to do all the migration activities within
the time frame.
The advantage of this approach is that the co-existence phase is very limited and, in some cases, wont be
as complex as would be required for a longer time period. The organization will be earlier in a FQDN
environment that may enable new applications or services.
Application lifecycle integrated migration
The application lifecycle integrated migration will enable a smooth transition of the applications and services
to the FQDN environment. The applications and services will be migrated when the hardware or software
lifecycle require a system operation. This approach will be at least one application lifecycle long and
stretches across several years.
The advantage of this approach is that it can be combined with other IT initiatives to reduce the application
migration costs, in comparison to the costs of the fast migration approach. On the other hand, the coexistence solution must be managed during the complete timeframe and it may become more complex, as a
result of changing requirements during the operation time line.
For both migration options, the organization should align the migration decision with other planned IT
initiatives and should define a migration end date for the completion of the move to the FQDN environment.
267673279 / 1.09.2011, Rev. 5
page 19
Appendix
4.4.2
Domain Rename
The Active Directory domain rename operation is attractive, because it offers the ability to get rid of the SLD
configuration in a straight forward process.
The first and foremost potential blocker is application compatibility. All applications in the environment must
support the Active Directory domain rename operation. If an application doesnt support rename AND you
cant take the outage caused by removing the application from the source domain and reinstalling it in the
destination domain AND re-associating application and configuration data, then the rename should be seen
as blocked.
In most customer environments, the only domain with an SLD name is the forest root domain. And in most
scenarios, this domain is empty; that is, there are no applications and services installed on servers in this
domain. The only servers in this domain are domain controllers. Subordinate domains in the tree have
FQDNs, and servers and workstations are more commonly members in these subordinate domains with
FQDNs than in the forest root domain with the SLD. In this scenario, you could rename the forest root
domain and assign a fully qualified name that puts this domain into a separate name tree and changes the
subordinate domains to form another separate tree of domains. This reduces the impact of domain rename
operation, since only all domain controllers in the forest have to be rebooted but no member servers or
workstations. The most compelling benefit of this approach is that the names of the application domains do
not change. This might drastically reduce the application compatibility impact. In this scenario, the focus for
application compatibility is on applications that have deep and hard coded integration with the Active
Directory schema and configuration naming contexts, such as Microsoft Exchange and Active Directory
Certificate Services.
If the organization environment supports the Active Directory domain rename operation, the operation must
be well planned and thoroughly tested, and all risks have to be assessed. The domain rename operation will
reconfigure the environment at one specific point in time. Any potential issues will arise directly after the
rename operation. The organization will either have to prioritize application repairs and may overload the
operation teams or have to accept application service degradation for a longer time period.
267673279 / 1.09.2011, Rev. 5
page 20
Appendix
5 Plan the transition

The best way to mitigate the SLD-related risks in the long-term is to move to an Active Directory environment
configured to use a fully qualified DNS name. There is no general golden way for transitioning from a
single-label DNS domain name to a fully qualified DNS name. The transition strategy to move to a common
FQDN configuration depends on the individual situation of the organization.
In the following chapters, the paper will provide guidance for affected organizations for the necessary
planning tasks to transition to a FQDN Active Directory. For all SLD situations, there should be the three
phases: analysis, decision, and execution.
The following flowchart describes the steps of the transition phases and activities.
267673279 / 1.09.2011, Rev. 5
page 21
Appendix
Figure 2 Transition phases and activities
Analysis
Analyze your environment
A deep analysis of the environment and a planning phase should be considered to gather the necessary
information to evaluate and decide for the best suitable mitigation approach for the organization. Chapter 6:
Analysis of your SLD environment provides an overview of things to consider during the analysis activity.
267673279 / 1.09.2011, Rev. 5
page 22
Appendix
Decision
Transition option decision
After the analysis phase, the organization must decide a transition option. Aspects an organization should
consider for the decision are covered in Section: 4.4 Transition option decision.
Execution - Migration
If the organization chooses migration as the transition option, the following activities should be completed.
Forest name selection
Chapter 7 Forest name selection will summarize the key considerations for selecting a new FQDN Active
Directory forest DNS namespace.
Provide hardware and procure licenses
For the new Active Directory infrastructure, additional hardware and software is necessary. Initiate the
procurement of the resources early to avoid delays in the procurement process.
Plan and build the new FQDN Active Directory forest
Section 8.1: Execute a Domain Migration outlines the major steps of the build process of the Active Directory
for the new FQDN environment.
Plan and build co-existence strategy
During the migration the existing and new environment must be managed and operated in an integrated way.
The processes will influence both environments. Therefore a co-existence strategy must be developed and
the necessary information synchronization established.
Section 8.2: Co-existence solution provides insights into the co-existing planning, approaches, and possible
solutions.
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
arent 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.
Execution - Domain Rename
If the organization chooses domain rename as a transition option, the following activities should be
conducted.
Forest name selection
Chapter 7: Forest name selection summarizes the key considerations for selecting a new FQDN Active
Directory forest DNS namespace.
Inventory the applications
Inventory your applications and try to get feedback about the domain rename impact and support from the
manufacturer of the application.
267673279 / 1.09.2011, Rev. 5
page 23
Appendix
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/dede/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.
267673279 / 1.09.2011, Rev. 5
page 24
Appendix
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 organizations 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 dont have a trust relationship with the organizations 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.
267673279 / 1.09.2011, Rev. 5
page 25
Appendix
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.
267673279 / 1.09.2011, Rev. 5
page 26
Appendix
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. Thats 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.
267673279 / 1.09.2011, Rev. 5
page 27
Appendix
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 computers 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:
267673279 / 1.09.2011, Rev. 5
page 28
Appendix
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.
267673279 / 1.09.2011, Rev. 5
page 29
Appendix
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.
267673279 / 1.09.2011, Rev. 5
page 30
Appendix
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.
267673279 / 1.09.2011, Rev. 5
page 31
Appendix
8 Execute a Domain Migration
267673279 / 1.09.2011, Rev. 5
page 32
Appendix
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-ofbusiness applications.
267673279 / 1.09.2011, Rev. 5
page 33
Appendix
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.
267673279 / 1.09.2011, Rev. 5
page 34
Appendix
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).
267673279 / 1.09.2011, Rev. 5
page 35
Appendix
8.1.3
OU structure
Two main criteriadelegation 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.
267673279 / 1.09.2011, Rev. 5
page 36
Appendix
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.
267673279 / 1.09.2011, Rev. 5
page 37
Appendix
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
Password Policies (FGPP) which allow having more than one password policy setting within a single domain
(the lack of this feature in the past sometimes motivated organizations to deploy more than one domain).
267673279 / 1.09.2011, Rev. 5
page 38
Appendix
8.1.6
Schema extensions
Another great opportunity for an efficient deployment approach lies in the possibility of introducing all the
schema extensions which are anticipated for all the AD-integrated applications that the organization is
planning to deploy. All these extensions can be installed before any user is migrated or any application is
actually installed in the new environment; this will largely reduce testing efforts and associated risk.
267673279 / 1.09.2011, Rev. 5
page 39
Appendix
8.2
Co-existence solution
All migration scenarios require the source and target environments co-exist during the migration process.
This co-existence implicates technical requirements and creates demands for co-existence processes and
people to execute them.
The co-existence period starts as soon as the setup of the new Active Directory forest and related
management solutions is finished. The co-existence period ends when the last server in the SLD Active
Directory forest is decommissioned.
By definition, co-existence includes all supporting processes and additional efforts that are required purely
because two separate enterprise Active Directory forests exist.
The implications of co-existence include:
Maintenance of two enterprise Active Directory forests, including related management tools and
solutions (that is, provisioning, monitoring, server maintenance, etc.).
Maintenance of trust relationships from external domains to both the existing and the new forests
and the name resolution configuration to support such trusts.
An LDAP application directory as an abstraction layer for LDAP-dependent applications to provide a
single point of LDAP access to the data of the two Active Directory forests in the background.
A solution for object synchronization between the two forests and the LDAP application directory.
The solution should provide automated synchronization of a defined set objects and a selection of their
attributes.
As a synchronization solution, organizations might implement Microsoft Forefront Identity Manager 2010
(FIM). Synchronization solutions are also available from other vendors. An organization can also choose to
extend an existing identity management system to provide the required co-existence functionality.
The synchronization solution connects, at minimum, the following directories:
The existing Active Directory forest

The new Active Directory forest
The LDAP application directory
The synchronization solution should also support the synchronization of passwords from the SLD forest to
the FQDN forest. This allows users to use their current password after their accounts have been migrated
and activated in the new forest.
The LDAP Application directory can be implemented as an Active Directory Lightweight Directory Services
(AD LDS) directory solution. AD LDS is an integrated server role on Windows Server 2008 R2.
During the co-existence phase, the LDAP application directory provides the old namespace for
applications, so that the migration of application server configurations will be de-coupled from the migration
of objects from the SLD forest to the FQDN forest. That means that objects that have been migrated to the
new forest can still be retrieved using the old search DNS. This solution follows the assumption that it is
easier to change a target server in an application than to change the complete namespace configuration.
Another important reason to establish this LDAP directory is that the set of objects that an application
retrieves might be distributed between the SLD and non-SLD forests due to migration states.
267673279 / 1.09.2011, Rev. 5
page 40
Appendix
8.3
Application Migration
267673279 / 1.09.2011, Rev. 5
page 41
Appendix
8.3.1
Application usage of Active Directory
While analyzing existing applications, it makes sense to distinguish the applications in terms of technical
aspects of the integration with Active Directory. This is important in order to understand the different technical
elements that have to be factored in when talking about application migration in conjunction with the Active
Directory forest migration.
It is important to note that application can have different scopes of integration. Some applications depend on
the forest and forest configuration, while others access information in specific domain naming contexts in the
forest.
In the following classification, we use the acronym FTM (Forest To be Migrated) for the SLD forest as the
source of the migration operation. The acronym DTM stands for Domain To be Migrated, that is, one
domain in the SLD forest as the source of migration operation.
We found the following typical application scenarios in customer environments.
Active Directory integrated configuration - strict
First and foremost, this category is characterized by the fact that the application can only live in either one or
the other Active Directory forest. The application boundary is the Active Directory forest. The application
configuration is stored in Active Directory. Application specific schema extensions are required.
Parallel instances of the application in an organization are possible. This application can live in both forests
with dependencies to the other (e.g. mail routing of a mail domain for Exchange). The migration of the data
between the instances is necessary. A user can be served only by one instance at a time.
Examples: Microsoft Exchange, Microsoft Lync
Active Directory integrated configuration - flexible
The application boundary is typically the Active Directory forest. The application configuration is stored in
Active Directory. Application specific schema extensions might be required.
This application can live in both forests without any dependencies. The two deployments won't significantly
influence each other. A user can be served by more than one instance.
Examples: Active Directory Certificate Services (PKI)
Windows integrated applications - on servers in the domain to migrate (DTM)
These are applications that use the Windows integrated authentication and authorization. The main factor
here is that these applications use the user's NT Token from the DTM to extract user and group SIDs and
use these SIDs to compare against SIDs in Access Control Lists (ACLs) on protected resources like files and
folders.
Examples: File servers in the domain to migrate
As an alternative to the usage of the SID the application can use the users token provided domain and
sAMAccountName for a name mapping inside the application.
Examples: Microsoft SQL Server
Windows integrated applications - on servers in trusting domains
These applications also use the Windows integrated authentication and authorization. The difference is that
these applications use the user's NT Token from the DTM to extract user and group SIDs and use these
SIDs to compare against SIDs in Access Control Lists (ACLs) on protected resources like files and folders on
servers in a domain that trusts the DTM (trusting domain).
Examples: File servers in a trusting domain
As an alternative to the usage of the SID the application can use the users token provided domain and
sAMAccountName for a name mapping inside the application.
Examples: SQL Server
267673279 / 1.09.2011, Rev. 5
page 42
Appendix
Windows Platform only - in the domain to migrate (DTM)

These applications do not use the Windows NT token. Instead, they leverage the user name to query
Active Directory via LDAP. In most cases, they check a user's group memberships (user to group or group to
user) or other attribute lookup to determine whether or not the user is allowed to perform a certain activity.
The application servers may run the Microsoft Windows operating system or another operating system. The
servers have machine accounts in the DTM domain. Servers not running a Windows operating system may
use a service account in the DTM domain. The accessibility of these services is affected by the domain
name change because the DNS domain suffix changes.
Examples: Typical Enterprise Portal systems or other services on Windows or non-Windows platforms
Windows Platform only - in trusting domain
These applications do not use the Windows NT token. Instead, they leverage the user name to query the
Active Directory via LDAP. In most cases, they check a user's group memberships (user to group or group to
user) or other attribute lookup to determine whether or not the user is allowed to perform a certain activity.
servers have machine accounts in a domain that trusts the DTM domain. Servers not running a Windows
operating system may use a service account in a domain that trusts the DTM domain or in the DTM domain.
The accessibility of these services is affected by the domain name change because the DNS domain suffix
changes.
Examples: Typical Enterprise Portal systems or other services on Windows or non-Windows platforms
Windows Platform only - standalone
These applications do not use the Windows NT token. Instead, they leverage the user name or other
attribute to query the Active Directory via LDAP. In most cases, they check a user's group memberships (user
to group or group to user) or other attribute lookup to determine whether or not the user is allowed to perform
a certain activity.
servers do not have a machine account in any of the FTM or DTM domains. The application uses a DTM
domain service account to query the DTM domain.
The accessibility of these services might be affected by the domain name change because the DNS domain
suffix changes.
Examples: Network Proxy appliances and proxy servers (for example: Squid)
267673279 / 1.09.2011, Rev. 5
page 43
Appendix
8.3.2
Application categories
The definition of different types of Active Directory integration is one very important input for the migration
planning process. But there are more parameters to consider for the application migration. The integration
type defines what has to be migrated, but it needs more parameters to be able to determine the expected
effort and possible timeframe of an application migration. Therefore, the application questionnaire should
also contain questions about object numbers and integration depth. Additionally, information about the
operation procedures as well as business criticality and business impact per application will influence the
application migration planning, possible timeframe, and effort.
In most cases, the information about the operation procedures as well as business criticality and business
impact per application cannot be credibly and comprehensively collected through a simple questionnaire. In
addition, it could be a good move to combine other application changes, like upgrades, to be combined with
an application migration.
This is the main reason why this document limits the consideration to the technical aspects of the migration.
The document will provide some non-technical information to consider, but the migration dependencies are
not limited to this non-technical information and must be adapted to each migration situation.
267673279 / 1.09.2011, Rev. 5
page 44
Appendix
8.3.2.1 Application Questionnaire

The following is a list of questions that can be used to compile an application questionnaire for a migration.
The questions are a base line and should be adapted to the organizations requirements for the particular
application migration situation. Based on these questions and typical results we will define application
categories in the next document section.
Which and how many security principals in DTM domain are related to an application?
Machine accounts
Service accounts
Administrative user accounts
End user accounts
Group accounts
Where else can security principals for an application live?
Trusted application domains (so called AD DS external trusts)

AD DS forest trusts
Kerberos realm trusts
Which different ways of using Active Directory security principals must be distinguished?
Authentication (Windows AuthN, LDAP bind)

LDAP query (such as for group memberships of a given user or groups)
Access Control List (ACL) with SID (native Windows authorization model)
Other permission mapping by name or SID from Active Directory
Claim generation for federated scenarios
Is there complete knowledge about how and where Active Directoryrelated data is configured?
What is the toolset for the application configuration?
Which other application data can be stored in Active Directory?
Configuration
Service connection point
Application meta data
Organizational data
User state data (directly in AD DS or as a link from a user account to an external store like AD LDS)
How flexible is an application in terms of the forest it lives in?
Do we have to rip and move the application in one step

or
can we deploy, operate in parallel, and eventually decommission the old installation?
Is the service required in both environments and does it need a separate instance in both forests?
How are clients affected by the change of the FQDN of their application servers?
Which are the main factors that influence time and effort for the migration of an application?
General complexity of integration

(number of integration points: data, configuration, ACLs, servers, clients)
Number of application related objects in Active Directory
Dependencies on other applications
Provisioning and synchronization requirements and dependencies on other systems during the
transition phase
267673279 / 1.09.2011, Rev. 5
page 45
Appendix
Downtime restrictions and other constraints as a result of SLAs and the business impact of the
application
Time restrictions for the transition period. (for example, frozen environment time during holiday
season)
Additional operational processes during the transition time
Additional helpdesk costs caused by the migration and transition.
Do we have to migrate the application at all?
Application lifecycle may end in the near future

There is a planned hardware or software upgrade in the near future
When is the best point in time to migrate the application and the service?
The application or service may be required in both the old and new forest during the migration and
transition timeframe
How does the lifecycle of an application influence migration effort?
Migrate with upgrade

Migrate and then upgrade later
Deploy new version in new forest, run in parallel with old version in old forest
Upgrade to new version may also force a change in AuthN, AuthZ, or both
Upgrade to new version may also offer the chance for a change in AuthN, AuthZ, or both
267673279 / 1.09.2011, Rev. 5
page 46
Appendix
8.3.2.2 Modeling Guidelines

For the definition of application categories, we defined guidelines that helped us to focus on the purpose of
this exercise:
The model must be simple enough to allow for easy assignment of a given application.
It is a model and thus has limitations.
Assignment to categories must be feasible with existing data about applications.
The categories must be related to migration specifics, especially to migration methodology and
costs.
Each category should be aligned to a certain migration strategy and path.
Each category should have a good percentage of applications that fall into it.
267673279 / 1.09.2011, Rev. 5
page 47
Appendix
8.3.2.3 Service Migration and Active Directory Object Migration

In a typical Active Directory migration scenario, we distinguish between service migration and Active
Directory object migration. Usually, these two run separately due to their different dependencies. An
application migration requires both the service and the Active Directory object migration to be successfully
executed.
Service migration is the process of establishing the service in the new environment. This can be executed as
a service move or with setting up a new instance of the service in the new environment. Service migration
includes but is not limited to the following migration actions:
Migrate server accounts (change domain membership) or set up new servers in the new
environment
Migrate technical accounts (service accounts, admin accounts) or re-create accounts
Move services data to servers in the new environment (configuration in Active Directory, data on file
servers, data in databases) or re-create this data
Re-ACL services data or adjust name mappings (the reference to the Active Directory object, if
required)
Change service configuration to point to new Active Directory forest (if Active Directory objects are
already there)
Change client-side application settings to point to the new service location
Decommission the service in the old environment
Active Directory object migration is the process of creating a copy of an object in the existing forest with the
same syntax and semantics in the target forest. This process is determined by parameters such as the
following:
Security principal: keep SID History or not

Security principal: migration sets like groups, and users as members of these groups
Enabling the account: only in one of the environment or in both environments
Object synchronization after migration
Copy object attributes or re-create according to new forest context
Decommission Active Directory data from the old forest
267673279 / 1.09.2011, Rev. 5
page 48
Appendix
8.3.2.4 Integration Depth

The integration depth in both the Active Directory and the application or service itself determines the
complexity and thus the effort for migration. The integration depth can be estimated by examining the results
of the application questionnaires that are defined in by the questions in Section 8.3.2.1: Application
Questionnaire. Furthermore, a direct discussion with application owners and a direct inspection of application
configuration are required to get a clear picture of the integration depth and thus the migration specifics of
each single application in existing landscape.
There are two indicators that should be readable from the results of questionnaires:
(1) Numbers: servers, Active Directory objects, configuration points
(2) Complexity: dependencies between objects (e.g., users and groups), distribution of application data
that uses Active Directory references (especially ACLs), integration with client workstation (e.g.,
GPO)
267673279 / 1.09.2011, Rev. 5
page 49
Appendix
8.3.2.5 Resulting Application Categories

In the model we use two main criteria to determine the application category:
(1) Integration depth in Active Directory
Examples for "High": The application depends on many different Active Directory objects to be migrated,
especially security principals like users and groups, or the objects have to be migrated and cannot be simply
re-created or the objects require synchronization after migration.
Example: Exchange must be rebuilt in the new environment; mailbox related Active Directory data must be
migrated.
(2) Integration depth in the application or service
Examples for "High": The application contains many references to Active Directory or there is only little
knowledge about where these references are hidden or changing the references requires code changes or
when migrating application related data, many ACLs or name mappings have to be renewed. The service
relocation (name change) requires changes in client-side applications.
Figure 3 Application categories according to integration depths
A main parameter that highly influences the effort and cost is whether the service or application has to be
moved or can be re-created in the new environment.
Business applications will have to be moved in most cases, while management services such as System
Center Configuration Manager (SCCM) or System Center Operation Manager (SCOM) have to be created in
the new environment. Since this might be the case for a number of applications, we created a separate
category for these.
The resulting application categories are described in the following paragraphs.
267673279 / 1.09.2011, Rev. 5
page 50
Appendix
8.3.2.5.1
C1: HIGH AD integration depth, HIGH service integration depth Complex integration
The application uses a large number of objects in Active Directory. These objects are of different object types
and are highly distributed in the Active Directory environment. This application category requires the greatest
effort and cost to migrate servers, clients, data, and Active Directory objects. The migration of these
applications requires the migration of application data (inside and outside of the Active Directory
environment) as well as the reconfiguration of client-side applications.
These applications often have special requirements on the sequence of user and group migrations and on
the state of associated users in both forests (active/passive, passive/active). Therefore, these applications
are the drivers for user and application migration. They determine when a certain user and group can be
migrated and all other applications have to follow and adapt to the approach.
These applications also create the need to keep associated objects in both forests in sync.
Example: Microsoft Exchange migration from the existing Exchange organization to the new Exchange
organization in the new forest.
267673279 / 1.09.2011, Rev. 5
page 51
Appendix
8.3.2.5.2
C2: HIGH AD integration depth, LOW service integration depth
The service uses many Active Directory objects of different types. The application does not use Windows
security principals from AD DS directly, except for a few service and administrative accounts. Instead, it uses
LDAP queries and mappings based on user or group names to make access decisions. The application
usually reads from the Active Directory database, but writing to the Active Directory database is not excluded.
Thus, we also include Active Directory provisioning solutions like Identity Management solutions here.
The service configuration, though, is very simple to change (for example, change the base DN) and the
number of affected application configuration items and servers is also low, that is, fewer than 10 servers, less
than 25 configuration items, or other factors that are easily changed and required little effort.
Although the service can be reconfigured quite easily, the service-related objects are mostly security
principals. With the migration progress, these security principals may be distributed between the FTM and
new forest during the migration and transition phase. This fact must be taken into account specifically.
Synchronization and provisioning tools are often required to support the migration of these applications. In
some cases, a virtual directory intermediate directory solution might be required to support the applications
during the migration.
If SID mapping is used and there are many configuration objects to change since the SID principals change
during migration, the application will rather fall into category C1 or C3.
267673279 / 1.09.2011, Rev. 5
page 52
Appendix
8.3.2.5.3
C3: LOW AD integration depth, HIGH service integration depth
The service uses a small number of Active Directory objects, in most cases this will be groups. The service
configuration, though, is very complex to change and the number of affected servers is also high, that is,
more than 10 servers, more than 25 configuration items, or other factors that are more complex to change
and require a great deal of effort. Examples are applications that use many folders and files on many NTFS
volumes and shares that are protected by ACLs. These ACLs contain the SIDs of groups from the DTM
domain.
For this category, the migration of the related Active Directory objects is not the most costly part of the
migration. Instead it is the cost of reconfiguring the applications, depending on the available knowledge
about where the configuration has to be executed, the number of required changes, and what toolset is
available for this task.
267673279 / 1.09.2011, Rev. 5
page 53
Appendix
8.3.2.5.4
C4: LOW AD integration depth, LOW service integration depth
The service uses a small number of Active Directory objects; in most cases, these will be configuration items.
The application does not use Windows security principals from the Active Directory database, except for a
small number of service and administrative accounts. There are no or only a few dependencies on other
applications or services.
267673279 / 1.09.2011, Rev. 5
page 54
Appendix
8.3.2.5.5
C5: Create new service instance in new environment
Special cases are applications that cant be migrated or when it is a better option to reinstall them without a
migration. In principal, these applications can fall in one of the before-mentioned application categories; but
from an application, operation, or other perspective, the preferred option is to create a new service instance
in the new environment. In most cases, these will be applications that support IT management and
operations tasks and processes.
In this case, migration means to set up a new instance of the service in the new forest. There might be the
requirement to integrate or sync both instances to get consolidated views. This is not feasible for all such
type of services.
267673279 / 1.09.2011, Rev. 5
page 55
Appendix
8.3.3
General application migration recommendations
The following list provides guidelines from our experiences with past migrations to better support the
operation of both environments during the migration and transition phase. These recommendations are not
strict rules, but should be considered in the overall migration planning process.
To keep the environments in a better manageable state, avoid cross-forest ACLs where possible.
(Using a principal from one forest in a ACL of a system in the other forest)
To keep the environments in a better manageable state, avoid cross-forest group memberships
where possible. (Adding a principal from one forest as a member in a group of the other forest)
Accounts have to be in both forests for Exchange, but to access the service only one account can be
enabled at a time.
In an environment that has user GPO application, the account activation follows the workstation
migration due to GPO application. This will avoid having an old workstation with new group policies
in a cross-forest scenario, which is complex to handle in terms of operations.
In an environment that only has workstation GPO applications, the account activation isnt
dependent on the workstation, as long as the GPOs between the environments are compatible with
the user environment.
267673279 / 1.09.2011, Rev. 5
page 56
Appendix
8.3.4
Customer experiences
In the migrations that have been carried out by Microsoft Services together with customer teams, we
validated the application categories and application migration approaches. It was found that the categories
and approaches are generally valid for most customer environments.
Further, it was recognized that any questionnaire cannot be completely sufficient to estimate the migration
effort and process for a given application, whether it is a Microsoft application, a custom application, or a
third-party application. The application owners must be educated to better understand how Active Directory
integration affects their application now, during transition, and in the new Active Directory environment so
they can estimate the related effort and to create a solid plan for their specific application.
The experience across the customers is that this education cannot be done with a questionnaire alone. The
questionnaire would be too complex if it were to cover every possibility. The conclusion was that it is more
practicable to gather specific information in an interview mode. The interview enabled a better understanding
of the application and revealed more dependencies and aspects of the application than the questionnaire
could.
267673279 / 1.09.2011, Rev. 5
page 57
Appendix
8.3.5
Application Migration Center for application owners
An application migration center (AMC) could offer the application owner various services to support the
migration process.
The application migration center could compile a customer specific application questionnaire to gather the
required application migration information.
Before working directly with the application migration center, the application owner could be offered a classroom or web-based training to understand the aspects of Active Directory integration, the purpose of the
application migration questionnaire, and the specific information that is required to prepare for the migration
of the applications.
In a next step, the application owner, with the support of team members or co-workers, should fill out the
application questionnaire. This could be done in a form that is made available on the organizations intranet.
The form can contain sample answers and guiding hints to collect the best possible answers.
After the filled-out questionnaire is submitted, the AMC specialists analyze the answers, categorize the
application, and prepare the application-specific migration activities. A decision will be made whether a
detailed interview or an on-site workshop will be required to further work out the migration plan for the
specific application migration. The individual interview or workshop with the application owner is the first step
in the estimation and planning process. It will further detail the findings from the questionnaire as well as
gather detailed, migration-related dependency information and clarify individual questions for the application.
The information collected will include technical, process, and business dependencies.
The AMC team should then develop of a detailed plan for the application migration, including work packages
and a basic timeline. At this point, the joint team of the application owner and the migration center will be
able to establish a cost and effort estimation for the end-to-end migration of the application.
During the application migration, the AMC team will support the application owner with migration patterns,
collected experiences from other application migrations. The specialist working with the AMC can provide
technical assistance for application migration.
The AMC should have a good communication plan. Typically, the AMC will communicate via a known
telephone number, functional mailbox, and an internal web site.
Based on successfully executed migrations, the AMC could publish case studies, best practices, and
blueprints to support applications owners with the planning and execution of do-it-yourself-migrations without
involving the on-site services of the AMC.
Overall, the AMC should catalyze the knowledge and experience about the Active Directory migration and
the typical application dependencies to enhance the migration speed, quality and reduce the application
migration risk.
267673279 / 1.09.2011, Rev. 5
page 58
Appendix
8.4
Application migration strategies
Each application category has its own integration depth in AD DS and integration depth in the application or
service. Each defined application category needs a different approach to be migrated to the new
environment. The next chapters will provide the principal steps, dependencies, caveats, and effort drivers for
the application migration of the categories.
267673279 / 1.09.2011, Rev. 5
page 59
Appendix
8.4.1
Migration Preparation
Figure 4 Migration preparation
Description:
The core scenario is the same for all application migrations:
The existing environment (source) consists of the domain to migrate that contains the user and group
principals to migrate. Optionally, the domain to migrate can have one or more trusting domains.
The new environment (destination) is a new forest or domain to migrate too.
The new forest or domain is operational.
The coexistence solution is in place and can be configured to synchronize required objects and attributes.
An Active Directory migration tool is in place that provides at least the following functionalities:
Migration of Active Directory users and groups

Support the migration of user passwords
Support SID History to maintain access to resources
Define closed sets of users and groups
Transfer and maintain group memberships
Modify user profiles to reflect a migrated users SID change
Modify ACLs on resources like file servers to reflect the SID change of users and groups
Remove SID History attributes when they are no longer required
Plan and test migration steps
Activities to achieve the step:

1
2
3
Build new forest (including OU, admin structure, and operations)

Migrate all user and group objects to the new forest; dont activate user accounts
Establish a synchronization for co-existence
Effort drivers:
Setup of the new environment

267673279 / 1.09.2011, Rev. 5
page 60
Appendix
Complexity of the synchronization process during the migration and transition phase
267673279 / 1.09.2011, Rev. 5
page 61
Appendix
8.4.2
Category 1 - Complex integration
267673279 / 1.09.2011, Rev. 5
page 62
Appendix
8.4.2.1 C1 - Initial configuration
Figure 5 C1 - initial configuration
Description:
The application uses a high number of objects in Active Directory. These objects are of different object types
and are highly distributed in the Active Directory. The migration of these applications requires the migration of
application data (inside and outside of the Active Directory) as well as the reconfiguration of client-side
applications.
The Active Directory stored data (such as mailbox information on a user object for Exchange) is labeled APP
CONFIG DATA. The application data outside of AD (such as mailbox data on an Exchange server) is labeled
APP DATA.
These applications have to keep associated objects in both forests in sync during the migration. The
necessary synchronization is covered by the migration and co-existence solution.
1
Preparation of the synchronization settings in the migration and co-existence solutions.
Effort drivers:
267673279 / 1.09.2011, Rev. 5
page 63
Appendix
8.4.2.2 C1 - migration ready
Figure 6 C1 - migration ready
Description:
A new instance of the application is installed in the target environment, and the new instance is up and
running. The migration and synchronization solution has prepared the objects in the new forest with the
necessary information for the co-existence phase.
1
2
Install new application instance in the new forest

a Install the application
b Configure the application configuration data
Establish application operation
Effort drivers:
Installation of the new application instance.
267673279 / 1.09.2011, Rev. 5
page 64
Appendix
8.4.2.3 C1 - application migration
Figure 7 C1 - application migration
Description:
This step will migrate the application data to the new application instance and re-ACL the application data
resources to the new AD object references. This step has dependencies on the application and on the
migration tool.
1
Migrate the application data

a Link the new AD object to the application data (for example, ACL, mailbox store information,
etc.)
b Migrate the application data (for example, Mailbox sync)
Effort drivers:
The migration process for the application.
267673279 / 1.09.2011, Rev. 5
page 65
Appendix
8.4.2.4 C1 - final state
Figure 8 C1 - final state
Description:
After all required Active Directory application configuration data is synchronized and all application data is
migrated, the final state of the application migration is reached. The old application instance can be
decommissioned.
1
2
The application data is migrated

a Users from both environments can access the application.
b Users are primarily in the new environment
Decommission of the old application instance
Effort drivers:
Application decommission without affecting the new application instance
267673279 / 1.09.2011, Rev. 5
page 66
Appendix
8.4.2.5 C1 - Exchange co-existence states for all categories

Microsoft Exchange is a common application in many customer environments and has some special
considerations that influence all other applications during the interforest migration. Normally the Exchange
migration works with the use of msMasterAccountSID attribute. This requires during the co-existence phase
of the interforest migration defined account states in the synchronized forests. The successful use of
msMasterAccountSID requires that the account with the mailbox is disabled. This will lead to the following
Exchange co-existence states, which will influence all other application migration categories, if Exchange is
co-migrated.
Figure 9 C1 - Exchange co-existance states for all categories
All other applications must obey that the possible account states during the transition and parallel phase are
limited and thereby limit the possible application migration solutions.
267673279 / 1.09.2011, Rev. 5
page 67
Appendix
8.4.2.6 C1 - in trusting domains

In most cases, the C1 scenario in trusting domains is not relevant.
If a customer uses a category 1 application, such as Exchange, in a resource forest that trusts the domain to
be migrated, then access to objects like mailboxes in the resource forest must be reassigned (sometimes
known as re-ACLing) to maintain the users access rights.
The option to use the SID History attribute in this case depends on the application and must be evaluated.
267673279 / 1.09.2011, Rev. 5
page 68
Appendix
8.4.3
Category 2 - HIGH AD integration depth, LOW service integration depth
267673279 / 1.09.2011, Rev. 5
page 69
Appendix
8.4.3.1 C2 - initial configuration
Description:
The service uses lots of Active Directory objects of different types (APP DATA in Figure 10). The application
does not use Windows security principals from AD DS directly, except for a few service or administrative
accounts. Instead, it uses LDAP queries and mappings based on user or group names to make access
decisions.
The application configuration (labeled APP CONFIG) is not overly complex and typically is very simple to
change (for example, change the base DN) and the number of affected application configuration items and
servers is also low.
Although the service can be reconfigured quite easily, the service-related objects are mostly security
principals. With the migration progress, these security principals may be distributed between the DTM/FTM
and new forest during the migration and transition phase. The synchronization and provisioning tools must
take the two environments into account.
In some cases, an intermediate LDAP store or virtual directory solution might be required to support the
applications during the migration. The need for an intermediate directory store boils down to the following
questions:
Can the application work with disabled user accounts?

o Yes - Case 1
o No - Case 2
Is the application able to query more than one base DN to find all required objects?
o Yes - Case 1
o No - Case 2
If one of these questions can be answered No, case 2 is usually the application migration approach. The
other application can use the case 1 approach.
o
Yes - case 1 approach is suitable for the application (see Sections 8.4.3.2, 8.4.3.3, and
8.4.3.6 for more information)
267673279 / 1.09.2011, Rev. 5
page 70
Appendix
No - case 2 approach is suitable for the application (see Sections 8.4.3.4, 8.4.3.5, and
8.4.3.6 for more information)
During the migration timeframe, the synchronization solution synchronizes user and group accounts between
the two environments. A C2 application might use nonstandard attributes and other objects as well.
If this is the case, the synchronization solution must be adapted accordingly.
1. Preparation of the synchronization settings in the migration and co-existence solutions.
Effort drivers:
267673279 / 1.09.2011, Rev. 5
page 71
Appendix
8.4.3.2 C2 - Case 1 - application can work with migrated objects, even if disabled
Figure 11 C2 - application can work with migrated objects, even if disabled
Description:
In this case the application can work with disabled user accounts in either environment. This means that only
one account of the associated accounts is active and the application still queries one (the existing or the
new) Active Directory base DN.
1
Change query base DN of the application

a n configuration items in the application
b n application servers to configure
Effort drivers:
The number of configuration items multiplied with the application servers.

The business dependency of the application and the necessary time to change the application
configuration.
267673279 / 1.09.2011, Rev. 5
page 72
Appendix
8.4.3.3 C2 - Case 1 - application is migrated to new forest, users still in migration
Figure 12 C2 - case 1 - application migration to the new forest, users still in migration
Description:
Because the application is independent of the user account state, the application server systems can be
independent from the user migration migrated to the new environment.
1
Migrate the application system and its configuration to the new forest
Effort drivers:
Number of application servers

Complexity of reconfiguration or new installation of the application system
267673279 / 1.09.2011, Rev. 5
page 73
Appendix
8.4.3.4 C2 - Case 2 - application cant work with migrated objects, sync to meta store
Figure 13 C2 - application cant work with migrated objects, sync to meta store
Description:
In this case, the application will check the account state and will only work with enabled user accounts in the
response of the query. This requirement can be fulfilled during the transition phase by an intermediate
directory. The intermediate directory can be a separate LDAP store or a virtual directory. In the following
figures, an LDAP store is used, but can be replaced by a virtual directory.
The data of the intermediate directory is maintained by a synchronization of the relevant information from the
both environments. The important fact is that the synchronization must obey the user account status in the
intermediate directory if one associated account is enabled.
The application must be reconfigured to the intermediate directory to work during the transition phase.
1
2
Create the LDAP intermediate directory store for the application as a mirror of the AD objects
Establish a synchronization of the relevant app data to the LDAP intermediate directory store.
The synchronization must implement the proper account state logic between the both ADs and the
intermediate directory store.
Change query base DN of the application
Effort drivers:
Installation and maintenance of the intermediate directory store.

Configuration and operation of the additional synchronization to the intermediate directory store.
The number of configuration items multiplied with the application servers.
The business dependency of the application and the necessary time to change the application
configuration.
267673279 / 1.09.2011, Rev. 5
page 74
Appendix
8.4.3.5 C2 - Case 2 - application migration
Figure 14 C2 - case 2 - application migration
Description:
The application systems can be migrated independent of the Active Directory object migration, as long as the
synchronization to the intermediate directory store maintains the necessary attributes.
1
Migrate the application system and configuration to the new forest; still query the intermediate store.
Effort drivers:
Number of application servers

Complexity of reconfiguration or new installation of the application system
267673279 / 1.09.2011, Rev. 5
page 75
Appendix
8.4.3.6 C2 - final state - application and objects are migrated to new forest
Figure 15 C2 - final state
Description:
After all application-related Active Directory Objects are migrated to the new environment, the intermediate
store and the existing instance can be deleted from the environment.
1
2
For Case 2 - Change query base DN of the application

Finally, every object is migrated and the application queries the new forest
Effort drivers:
For Case 2, see Section 8.4.3.4: C2 - Case 2 - application cant work with migrated objects, sync to
meta store.
267673279 / 1.09.2011, Rev. 5
page 76
Appendix
8.4.3.7 C2 - effort drivers for the configuration change

The following table lists some more details about common necessary configuration tasks for C2 applications
during the reconfiguration.
Step
Effort drivers
1. Create LDAP directory, with

appropriate rules for the
queries.
Number of required instances

Create the synchronization
Create the synchronization logic rules
2. Change query base DN

(server name or DN)
n configuration items
n servers
Knowledge about configuration items

Number of configuration items
Configuration files
Line of code changes
number of servers
Farm configuration/replicated configuration?
Individual changes
3. Migrate the application

system and configuration to
the new forest
Still query the virtual directory
Number of server accounts, service accounts, other

Active Directory related objects, etc.
Migration/reconfiguration/reinstallation of the server
system
Kerberos integration into Active Directory
4. For Case 2, an additional

configuration change is
necessary
n configuration items
n servers
Double the effort of step 2
Table 1 C2 - effort driver details
267673279 / 1.09.2011, Rev. 5
page 77
Appendix

The existence of C2 applications in trusting domains is possible, but there is no difference in the migration
approach of the application.
If the application uses Windows security principals from the DTM, then most likely the application service
account is migrated to the new environment. This can require a trust between the trusting domain and the
new forest. This should be considered for the application setup.
267673279 / 1.09.2011, Rev. 5
page 78
Appendix
8.4.3.9 C2 - experiences
The C2case 1 is good in theory, but there is the risk that such an application will break during the transition.
Additionally, most likely there will be applications that fall into the C2case 2 category and require the
intermediate directory store anyway. To reduce these risks, all case 1 applications should use the case 2
steps.
The implementation of the intermediate store should be considered as an LDAP store and not as a virtual
directory. The experience with virtual directories is that the performance can be a major concern with many
queries and that complex query logic might be required in a migration scenario.
267673279 / 1.09.2011, Rev. 5
page 79
Appendix
8.4.4
Category 3 - LOW AD integration depth, HIGH service integration depth
267673279 / 1.09.2011, Rev. 5
page 80
Appendix
8.4.4.1 C3 - Initial configuration
Description:
The service uses a number of Active Directory objects; in most cases, this will be groups. The service
configuration and the application data, though, is very complex to change and the number of affected servers
is also high. Examples are applications that use many folders and files on many NTFS volumes and shares
that are protected by ACLs. These ACLs contain the SIDs of groups from the DTM domain.
Another method of security principal association of this category is name mapping. The application uses the
<NetBIOS Domain>\<sAMAccountName> as the identifier for the application. This identifier will change
during the migration to the new forest.
For this category, the migration of the related Active Directory objects is not the most costly part of the
migration. Instead it is the effort of reconfiguring the applications, depending on the available knowledge
about where the configuration has to be executed, the number of required changes, and what toolsets are
available for this task.
The C3 application approach is divided into the two cases (Section 8.4.4.2: SID based and Section 8.4.4.3:
Name mapping).
1
2
Preparation of the synchronization settings in the migration and co-existence solutions.

For SID-based mapping, the migration with SID History is necessary.
A domain or forest trust from the existing to the new forest is necessary, because Windows
authentication is used. (This is most likely already in place due to the migration preparation.)
Effort drivers:
267673279 / 1.09.2011, Rev. 5
page 81
Appendix
8.4.4.2 SID based
267673279 / 1.09.2011, Rev. 5
page 82
Appendix
8.4.4.2.1
C3 - some security principals are migrated and active
Figure 17 C3 - SID based - some security principals are migrated and active
Description:
Some of the migrated user accounts with SID History are active in the new environment. They will access the
resources in the existing environment. The access control check is passed by using the SIDs from the SID
History attribute of the user or group account of the new environment.
1
Some user objects are active in new forest.

a The users can access the existing app data by the use of SID History in the access token.
Effort drivers:
No additional effort than the migration itself.
267673279 / 1.09.2011, Rev. 5
page 83
Appendix
8.4.4.2.2
C3 - SID based migration options
The SID based migration offers two options for the reACLing process.
option 1 - sequential migration
Steps
Advantages
option 2 - Migrate users / groups in parallel with the ACL

based resources
All users and groups are

migrated first to the new
environment.
Finish the complete migration
with all users active in new
forest.
Migrate the resource servers to
the new forest
ReACL all the resources during
the system migration
reduced complexity of operation
Convert all DLGs to universal groups

to enable
o Global groups as members
o Group availability in a trusted
domain / forest
Migrate the users / groups in parallel
with the resources
Migrate the resource servers to the
new forest
ReACL the resources after all users /
groups are migrated
o Requires analysis of the used
users / groups in the ACLs
shorter time frame
Disadvantag
longer time frame
higher complexity of operation
es
The following chapters will describe both SID-based migration approaches.
267673279 / 1.09.2011, Rev. 5
page 84
Appendix
8.4.4.2.3
C3 - option 1 - all security principals are migrated and active
Figure 18 C3 - SID based - option 1 - all security principals are migrated and active
Description:
All users and groups are migrated with SID History to the new environment. They will access the resources
in the existing environment. The access control check is passed by using the SIDs from the SID History
attribute of the user or group account of the new environment.
The existing user accounts are disabled and cant access the resources.
1
2
All users and groups are migrated to the new environment

a The users can access the existing App Data by the use of SID History.
Ready to migrate and reACL resources
Effort drivers:
The challenge is that all users and groups must be migrated and active in the new forest. This
process can take considerably longer than planned.
267673279 / 1.09.2011, Rev. 5
page 85
Appendix
8.4.4.2.4
C3 - option 1 - server migration
Figure 19 C3 - SID based - option 1 - server migration
Description:
The existing application server systems or only the app data is migrated without ACL change to the new
forest. The app data is reACLed in the new forest environment.
1
2
Migrate the server object or the app data to the new domain
a Keep the ACLs on the resources
b During the migration users can access the app data by the use of SID History.
reACL the resources
a New SIDs will be used for further data access.
Effort drivers:
The reACLing process can be very time consuming. The reACLing performance depends on the
number of objects that have to be reACLed.
267673279 / 1.09.2011, Rev. 5
page 86
Appendix
8.4.4.2.5
C3 - option 2 - some objects are migrated and active
Figure 20 C3 - SID based - Option2 - some objects are migrated and active
Description:
Option 2 requires that all security principals in the ACLs are available across domain boundaries. The user
accounts, global and universal groups are available across the domain by default. Domain local groups are
bound to the domain and can have users, global, and universal groups as members. To fulfill the
requirements available across the domain boundary and can have users, global and universal groups as
members, all domain local groups of the existing environment must be converted to universal groups. Then
these groups can be used across the domain and forest boundary.
Some of the existing user accounts are active in the existing environment. They will access the resources
with the existing ACLs in both the existing and new environment. The access control check is passed by
using the original SIDs of the user or group account of the existing environment.
Some of the migrated user accounts with SID History are active in the new environment. They will access the
resources with the existing ACLs in the existing and new environment. The access control check is passed
by using the SIDs from the SID History attribute of the user or group account of the new environment.
1
2
Change all existing domain local groups to universal groups in the existing forest.
Migrate the server object or the app data to the new forest
a Keep the ACLs on the resources
Important: Only ACLs for users, global groups, or universal groups can be used across the
domain boundary.
Effort drivers:
If trusted foreign security principals are nested into the existing domain local groups, resolve the
dependencies in the domain local group.
267673279 / 1.09.2011, Rev. 5
page 87
Appendix
8.4.4.2.6
C3 - option 2 - reACL the resources
Figure 21 C3 - SID based - option 2 - reACL the resources
Description:
In this step, the existing (old) SID in the ACL will be replaced by the new forest (new) SID. This will break
user access from the existing environment.
The challenge is the management of closed migration sets of security principals and data.
1
Replace existing (old) SID with new forest SIDs in the ACLs.
a This cuts off access for users/groups from existing forest.
Effort drivers:
The definition and organization of closed migration sets of security principals and data.
The reACLing process can be very time consuming. The reACLing performance depends on the
number of objects that have to be reACLed.
Depending on the migration situation and closed user groups, the reACLing process must be run
multiple times on a server or app data set.
267673279 / 1.09.2011, Rev. 5
page 88
Appendix
8.4.4.2.7
C3 - SID based - final
Figure 22 C3 -SID based - final
Description:
All users and groups are migrated with SID history to the new environment. They will access the resources in
the existing environment. The access control check is passed by using the new SIDs from new forest.
The SID history information of all user and groups in the new forest can be removed to reduce the access
token and Kerberos token size.
1
Remove all SID History information of the existing domain from the migrated objects.
Effort drivers:
Remove of SID history information based on filters.
267673279 / 1.09.2011, Rev. 5
page 89
Appendix
8.4.4.2.8
C3 - SID based - in trusting domains
Application in trusting domains can also use SID based mappings. For these applications to work, a domain
or forest trust from the existing to the new forest is necessary, because Windows authentication is used.
The application server migration in the trusted domain isnt necessary.
ReACLing is only required if direct permission assignments from the existing domain (DTM) security
principals have been used.
Most likely DTM principals are nested into the trusted Active Directory domain local groups. These
memberships must be replaced by the corresponding groups from the new forest.
267673279 / 1.09.2011, Rev. 5
page 90
Appendix
8.4.4.3 Name mapping
267673279 / 1.09.2011, Rev. 5
page 91
Appendix
8.4.4.3.1
C3 - some security principals are migrated and active
Figure 23 C3 - name mapping - some security principals are migrated and active
Description:
Some of the migrated user accounts are active in the new environment, and the existing DTM account is
deactivated. They will access the resources in the existing environment. The access control check fails,
because the application cant map the new <NetBIOS Domain>\<sAMAccountName> to an application
principal or role.
1
Some user objects are active in new forest.

a The users cant access the existing app data because no name match can be done by the
application.
Effort drivers:
267673279 / 1.09.2011, Rev. 5
page 92
Appendix
8.4.4.3.2
C3 - name remapping
Figure 24 C3 - name mapping - name remapping
Description:
Changes to the name mapping entries have to be applied so that they now include security principals users
and groups - from the new forest. This is required in order to allow application data access for migrated
users. Adding new group name mappings without removing old name mappings enables access from both
environments for group members during the transition phase.
1
Reconfigure the application access control to the new name of the security principal
Two options:
a Add - both names are mapped (for groups)
b Replace - only the new name is mapped (for users)
Effort drivers:
The challenge is to be able to apply the required changes to all applications in this category at the
exact time when the user migrates to the new environment.
The remapping process can be very time consuming. The remapping performance depends on the
number of objects to be remapped and the number of stores.
Depending on the migration situation, the remapping process must be run multiple times on a server
or app data set.
267673279 / 1.09.2011, Rev. 5
page 93
Appendix
8.4.4.3.3
C3 - server migration
Figure 25 C3 - name mapping - resource server migration
Description:
The application server or the app data migration can be done during the user and group migration process.
The name mapping isnt influenced by the migration. The name remapping process, as described in Section
8.4.4.3.2: C3 - name remapping, must take place.
1
Migrate the server object or the app data to the new domain
a The name mapping isnt changed,
b The system migration and the name mapping changes dont depend on each other,
Effort drivers:
267673279 / 1.09.2011, Rev. 5
page 94
Appendix
8.4.4.3.4
C3 - final
Figure 26 C3 - name mapping - final
Description:
After all application-related Active Director Objects have been migrated to the new environment, the existing
(DTM) group mapping can be removed from the app data.
1
Clean up old DTM group name mappings
Effort drivers:
The remapping process can be very time consuming. The remapping performance depends on the
number of objects to be remapped and the number of stores.
267673279 / 1.09.2011, Rev. 5
page 95
Appendix
8.4.4.3.5
C3 - name mapping - in trusting domains
Application in trusting domains can also use name mappings. For those applications to work, a domain or
forest trust from the existing to the new forest is necessary because Windows authentication is used.
No application server migration in the trusted domain is required.
Remapping is only required if direct mapping from the existing domain (DTM) security principals has been
used.
267673279 / 1.09.2011, Rev. 5
page 96
Appendix
8.4.4.4 C3 - Effort drivers
The number of ACLs (process run-time) or the number of mappings will influence the migration effort
of the application.
Depending on the migration coordination and other dependencies, the reACL or remapping process
must run multiple times on the system to ensure that all ACLs and mappings are found. A good
configuration management that has a management database containing the ACLs and mapping
assignments can reduce the effort by running specified reACL and remapping cycles.
267673279 / 1.09.2011, Rev. 5
page 97
Appendix
8.4.5
Category 4 - LOW AD integration depth, LOW service integration depth
267673279 / 1.09.2011, Rev. 5
page 98
Appendix
Description:
The service uses a small number of Active Directory objects: in most cases, these are configuration items.
The application does not use Windows security principals from Active Directory, except for a few service or
administrative accounts. There are no or only a few dependencies on other applications or services.
Usually, no special synchronization requirements exist for this application category.
None
Effort drivers:
None
267673279 / 1.09.2011, Rev. 5
page 99
Appendix
8.4.5.2 C4 - Migration
Figure 28 C4 - migration
Description:
The application server or application data can be migrated to the new forest environment according to the
required application steps.
If the application uses Active Directory to store application configuration data, this data has to be transferred
to the new forest. Computer, service, admin, etc., accounts must be re-created or migrated to the new forest.
1
Migrate the server object to the new domain

a No or minor reACLing is required
b Change service accounts and admin accounts to use accounts from new forest
c If required, change application references to new base DN
Effort drivers:
267673279 / 1.09.2011, Rev. 5
page 100
Appendix
8.4.5.3 C4 - final
Figure 29 C4 - final
Description:
After the migration of the application server or application configuration data, the old DTM application servers
and accounts can be decommissioned.
1
Decommission of DTM application servers and accounts.
Effort drivers:
None
267673279 / 1.09.2011, Rev. 5
page 101
Appendix

It is possible to have a category C4 application running in a trusted domain that uses application
configuration data from the DTM, but this would be an unusual configuration.
In order to deal with this configuration, a slightly different migration approach is required. The application
might need a trusted account for service access. If a service account or admin account is required, then a
domain trust from the DTM trusting domain to the new forest is necessary.
267673279 / 1.09.2011, Rev. 5
page 102
Appendix
8.4.6
Category 5 - Create new service in new environment
267673279 / 1.09.2011, Rev. 5
page 103
Appendix
Description:
This type of application cant be migrated because it is required in the existing forest and in the new forest. In
most cases, this type of application will be applications that support IT management and operations tasks
and processes.
In this case, migration means setting up a new instance of the service in the new forest. There might be the
requirement to integrate or sync both instances to get consolidated views. This is not feasible for all such
services.
In general this application category has no requirements with regards to the co-existence synchronization.
1
None
Effort drivers:
None
267673279 / 1.09.2011, Rev. 5
page 104
Appendix
8.4.6.2 C5 - final
Figure 31 C5 - final configuration
Description:
The new instance of the application is built in the new forest. The new application instance is configured and
the application data transferred if necessary.
The new application instance will use new computer, service, and administrative accounts from new forest.
1
2
Deploy new application infrastructure

Use security principals from new forest
Effort drivers:
Installation and configuration of the new application instance.

If needed, an application data transfer between the existing and the new application instance.
267673279 / 1.09.2011, Rev. 5
page 105
Appendix

Not relevant; only services in domain to migrate are considered in this category.
267673279 / 1.09.2011, Rev. 5
page 106
Appendix
8.4.7
Summary
The migration of a category 1 application will drive all other application migrations. In most cases, the
Exchange migration of the mailboxes is the leading migration and defines the rules of the application
migration. All other application migrations will be done after the Exchange migration.
The complex part is the user activation in the new environment, because it has to consider all the
applications a user must use and the application restrictions a user may experience when his or her
workgroup is distributed between the SLD and FQDN environments. The formation of closed user sets
should be planed based on business requirements. This task must be considered in the overall migration
process detail planning.
267673279 / 1.09.2011, Rev. 5
page 107
Appendix
9 Appendix
267673279 / 1.09.2011, Rev. 5
page 108
Appendix
9.1
Internet references
267673279 / 1.09.2011, Rev. 5
page 109
Appendix
9.1.1
Domain name information

DNS Namespace Planning Support
http://support.microsoft.com/gp/gp_namespace_master
DNS Namespace Planning
http://support.microsoft.com/kb/254680/en-us
Namespace planning for DNS
http://technet.microsoft.com/en-us/library/cc759036(WS.10).aspx
Disjoint Namespace
Information about configuring Active Directory domains by using single-label DNS names
Routing name suffixes across forests
Exchange - A Single-labeled DNS Domain was Detected
http://technet.microsoft.com/en-us/library/cc431355(EXCHG.80).aspx
Single-Labeled Domain Names and Exchange 2007 SP1
http://technet.microsoft.com/en-us/library/cc788134(EXCHG.80).aspx
Warnings installing Active Directory Domain Services on Windows Server 2008 and Windows Server
2008 R2 in domains with single-label DNS names
Windows Server 2008 (R2) - DNS Server Operations Guide - Providing Single-Label DNS Name
Resolution
Post-installation behavior on client computers after you install the DNS update
http://support.microsoft.com/kb/957579
267673279 / 1.09.2011, Rev. 5
page 110
Appendix
9.1.2
Migration information
ADMT Guide: Migrating and Restructuring Active Directory Domains
How to associate an external account with an existing Exchange 2000 mailbox
http://support.microsoft.com/kb/322890/
You cannot move or log on to an Exchange resource mailbox
267673279 / 1.09.2011, Rev. 5
page 111
Appendix
9.1.3
Rename information
What Is Domain Rename?
http://technet.microsoft.com/de-de/library/cc781575(WS.10).aspx
How Domain Rename Works
http://technet.microsoft.com/de-de/library/cc738208(WS.10).aspx
267673279 / 1.09.2011, Rev. 5
page 112
Appendix
9.1.4
Product support statements

Microsoft Biztalk Server compatibility with Single Label Domains, Disjointed Namespaces, and
Discontiguous Namespaces
Microsoft Exchange compatibility with Single Label Domains, Disjointed Namespaces, and
Microsoft Forefront compatibility with Single Label Domains, Disjointed Namespaces, and
Microsoft Lync and Microsoft Office Communications Server compatibility with Single Label
Domains, Disjointed Namespaces, and Discontiguous Namespaces
Microsoft Office Outlook compatibility with Single Label Domains, Disjointed Namespaces, and
Microsoft Office SharePoint compatibility with Single Label Domains, Disjointed Namespaces, and
Microsoft Online Services compatibility with single-label domains, with disjoint namespaces, and with
discontiguous namespaces
Microsoft SQL Server compatibility with Single Label Domains, Disjointed Namespaces, and
Microsoft System Center product compatibility with Single Label Domains, Disjointed Namespaces,
and Discontiguous Namespaces
267673279 / 1.09.2011, Rev. 5
page 113

Whitepaper Single Label Domain V132

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Whitepaper Single Label Domain V132

Încărcat de

Drepturi de autor:

Formate disponibile

Single-Label-Domain - Considerations,

migration and co-existencein Active

Single-label domain scenarios.................................................................................................................. 8

Options to move away from a SLD configuration......................................................................................9

Pros and cons of migration vs. domain rename..............................................................................11

Transition option decision............................................................................................................... 12

Plan the transition................................................................................................................................... 15

Analysis of your SLD environment.......................................................................................................... 19

Forest name selection............................................................................................................................. 20

Execute a Domain Migration................................................................................................................... 23

Building the new FQDN Active Directory forest...............................................................................23

Number of domains - empty forest root domain..........................................................................23

Physical structure (sites and subnets)........................................................................................ 23

Domain controller operation system version...............................................................................23

Application usage of Active Directory.......................................................................................... 25

Service Migration and Active Directory Object Migration.....................................................29

Resulting Application Categories......................................................................................... 30

General application migration recommendations........................................................................32

Application Migration Center for application owners...................................................................33

Application migration strategies...................................................................................................... 33

Category 1 - Complex integration............................................................................................... 35

C1 - Exchange co-existence states for all categories..........................................................38

C2 - Case 1 - application can work with migrated objects, even if disabled........................40

C2 - Case 1 - application is migrated to new forest, users still in migration........................41

C2 - Case 2 - application migration.....................................................................................43

C2 - final state - application and objects are migrated to new forest...................................44

C2 - effort drivers for the configuration change...................................................................44

Category 3 - LOW AD integration depth, HIGH service integration depth...................................46

Category 4 - LOW AD integration depth, LOW service integration depth....................................57

Category 5 - Create new service in new environment.................................................................60

Category 2 - HIGH AD integration depth, LOW service integration depth...................................39

Domain name information........................................................................................................... 62

Product support statements........................................................................................................ 63

Enables enhanced security capabilities of new versions of AD DS

SLD single-domain forest

Empty SLD root and one or more domains

Trust relationship with a SLD domain or forest

Acquisition and merger of a SLD Active Directory

4 Options to move away from an SLD configuration

The target of the rename operation has to be a well-formed forest.

Figure 1 - Forest root domain rename

What Is Domain Rename?

Microsoft Exchange 2000 Server

Pros and cons of migration versus domain rename

Can create optimal forest based on experience

Requires duplicate hardware for testing and

No application compatibility issues.

Requires twice as many software licenses for

Fully supported with no ambiguity

Requires guaranteed install of all Microsoft and

Can prepare the destination forest out-of-band for

Contributes to access token bloat; careful planning

Tools and processes for domain migration are well

Migration tools do not exist to migrate application

Destination domain can be prepared out-of-band

Custom schema changes not modified by

Actual domain rename can be performed in a short

Application compatibility can be a major blocker if

Child domains can be restructured so that they

There is less experience among support

User accounts, computer accounts, groups, group

The toolset around bulk operations for the renamed

No increase in the access token size, because there

Requires an intense organizational effort to