Although it is possible to
add a member server running Windows Server 2008 to an existing Microsoft
Windows Server 2003 domain, at some point in your organization’s
migration to Windows Server 2008, you are going to want to upgrade your
organization’s domain controllers (DCs).
Migration Paths
You can take one of three
general paths to move from an existing Active Directory environment to
an AD DS environment. An AD DS environment is another way of indicating a
domain that has Windows Server 2008 DCs. These paths are known as the domain upgrade, the domain restructure, and the upgrade-then-restructure.
When planning which method to use, consider factors such as the amount
of time the migration should take and the availability of new server
hardware.
Domain Upgrade Migration Path
The domain
upgrade migration path involves upgrading the operating system of a
Windows Server 2003 DC to Windows Server 2008 or installing Windows
Server 2008 DCs into a Windows 2000 Server or Windows Server 2003
domain. Unlike Windows Server 2003, which you can configure to support
domains that use both Microsoft Windows NT 4.0 and Windows Server 2003
DCs, Windows Server 2008 DCs cannot coexist in the same domain as
Windows NT 4.0 primary and backup DCs. Therefore, if you are planning to
add Windows Server 2008 DCs to a domain, you need to ensure that
domains in your organization are at the Windows 2000 Native functional
level or higher. Domains at the Windows 2000 mixed or Windows Server
2003 interim functional level do not support Windows Server 2008 DCs.
There is no direct upgrade path between Windows NT 4.0 and Windows
Server 2008. Plan to use the domain upgrade migration path when you will
not have access to a significant amount of new server hardware on which
to install new deployments of Windows Server 2008.
Domain Restructure Migration Path
The
domain restructure migration path involves copying Active Directory
objects from the original domain or forest to the new Windows Server
2008 domain or forest, using tools such as the Active Directory
Migration Tool, covered later in this lesson. After all objects are
migrated, the DCs in the original domain or forest are decommissioned or
redeployed. The domain restructure migration path includes the
following advantages:
The original
environment remains the same until the migration is completed. Users are
not forced to the new environment until it is tested and ready.
It
enables the selective migration of objects. When you perform a domain
upgrade, all objects are upgraded, including those that are redundant,
inactive, and no longer necessary. Domain restructure migrations enable
organizations to clean up their environments as they transition to the
new technology.
The domain restructure
migration requires you to have enough new server hardware to support
both the original and destination environments concurrently. If the
budget does not allow for new server hardware, the domain upgrade
migration path is a more feasible alternative. Although it is possible
to perform a domain restructure migration using virtualization, you
should avoid this approach unless you are planning an AD DS deployment
that primarily involves virtualized DCs.
Upgrade-Then-Restructure Migration Path
The
upgrade-then-restructure migration path, also known as a two-phase
migration, involves upgrading the original domain or forest and then
migrating Active Directory objects to a new Windows Server 2008 domain
or forest. This process essentially combines the domain upgrade and
domain restructure approaches, enabling an organization to benefit
immediately from a Windows Server 2008 upgrade and then to transition to
new Windows Server 2008 DC hardware at some point in the future, with
the added benefit of removing unnecessary Active Directory objects
through the selective migration process.
Active Directory Migration Tool
You can use the Active
Directory Migration Tool v3.1 (ADMT v3) to migrate Active Directory
objects within a forest for domain consolidation or to migrate objects
to another forest for interforest migration. You can use the ADMT to
migrate users, groups, service accounts, computers, and trusts. The ADMT
has a simulation mode that enables administrators to evaluate the
results of planned migrations prior to performing the actual migration.
Upgrading an Existing Domain to Windows Server 2008
There
are two basic strategies for transitioning from an existing domain to a
Windows Server 2008 AD DS domain. The first strategy is to introduce
new Windows Server 2008 DCs into the forest and then either to retire or
upgrade existing Windows 2000 Server or Windows Server 2003 DCs. The
second strategy is simply to perform an in-place upgrade of all existing
Windows Server 2003 DCs. Both of these strategies are useful when
pursuing the domain upgrade migration path.
Preparing the Environment
You need to perform
several steps prior to adding a Windows Server 2008 DC to an existing
Active Directory environment, even if you do not intend to change the
current domain or forest functional level. These steps include ensuring
that existing DCs in the environment have appropriate patches and
service packs installed and that the Active Directory schema has been
appropriately prepared for the introduction of Windows Server 2008 DCs.
If you are planning to
add a Windows Server 2008 DC to a domain that has active Windows 2000
Server DCs, which is possible when using the Windows 2000 Native domain
and forest functional level, you must ensure that all Windows 2000
Server DCs have Service Pack 4 and hotfix 265089 installed.
To prepare a forest for the installation of a read-only DC (RODC), run the adprep /rodcprep
command on the schema master. This command needs to be run only once on
the schema master and does not need to be run in each domain in the
forest in which you intend to install Windows Server 2008 RODCs. As is
the case with adprep /forestprep,
to execute this command successfully, the user account must be a member
of the Enterprise Admins, Schema Admins, and Domain Admins groups. From
a planning perspective, consider running adprep /rodcprep immediately after running the adprep /forestprep
command even if you have no immediate plans to deploy RODCs in your
environment. If, in the future, it becomes necessary to deploy RODCs in
the enterprise, the deployment will be able to proceed without problems
that might occur if future administrators do not check whether the
forest has been prepared for the deployment of RODCs prior to attempting
deployment.
More Info: Microsoft Exchange 2000 Server and Windows Services for UNIX 2.0
Known compatibility problems exist between adprep.exe
and Exchange 2000 Server and Windows Services for UNIX 2.0 where these
products have been deployed in Windows 2000 Server domains. Consult KB
article 314649 to resolve the Exchange 2000 Server issue and either
install the Q293783_sfu_2_x86_en.exe hotfix for Windows Services for UNIX 2.0 or upgrade to Windows Services for UNIX 3.0.
After you have
completed the forest-level preparation tasks, you must still perform
preparation on a per-domain basis before you can install Windows Server
2008 DCs. A user who is a member of that domain’s Domain Admins group must run the adprep /domainprep /gpprep
domain preparation command on the DC that holds the infrastructure
master role. After this command has been run, Windows Server 2008 DCs
can be introduced to that domain.
In-Place Domain Controller Upgrade
Upgrading each DC in the
domain from Windows Server 2003 to Windows Server 2008 works well within
the limitations of the types of upgrades you can perform. For example,
you cannot upgrade a computer that has Windows Server 2003 Enterprise to
Windows Server 2008 Standard, and you cannot upgrade any Windows Server
2003 DC to a Windows Server 2008 DC that is running the Server Core
installation. Before performing an in-place upgrade of a Windows Server
2003 DC, ensure that Service Pack 1 (SP1) or later has been applied.
This does not apply to Windows Server 2003 R2 DCs, which are effectively
updated to SP1 when initially deployed.
| 1. | On which DC should you perform the first forest preparation task? | | 2. | Which of the Windows Server 2003 domain functional levels do not support the introduction of Windows Server 2008 DCs? |
Quick Check Answers
| 1. | You must run adprep /forestprep on the DC hosting the schema master role. | | 2. | Windows
2000 Mixed and Windows Server 2003 interim domain functional levels
support Windows NT 4.0 DCs. There must be no Windows NT 4.0 DCs in a
domain if a Windows Server 2008 DC is to be introduced. |
|
Cross-Forest Authentication
Enterprise-scale
organizations often deploy multiple forests. Although these forests are
usually designed for separate divisions within the enterprise, a level
of integration between these separate network environments is often
required. The most common way of allowing users in one forest to access
the resources located in another is to configure an interforest trust so
that any user in any domain in the trusted forest can access any
resource in any domain in the trusting forest. An alternative is an
external trust that exists between specific domains in different forests
rather
than in any domain in each forest.
When planning a trust, you must consider the following factors:
Should the trust be bidirectional or one-way?
Is it necessary to use selective authentication?
Is it necessary to implement Security Identifier (SID) filtering?
When planning trust
direction, ensure that you grant only the minimum required access needed
to meet business requirements. This might mean using external trusts
rather than forest trusts. Remember that two-way trusts are required
only when users in each forest or domain need access to resources
located in the other forest or domain. If an organization uses a
resource forest scenario, it is necessary to configure only a one-way
trust from the forest that hosts accounts to the forest that hosts
resources.
You can limit trusts by
using selective authentication, which restricts the number of users in
the trusted forest who are able to access shared resources in the
trusting forest. If you deploy forest-wide authentication rather than
selective authentication, any user authenticated over an interforest
trust will be assigned the Authenticated Users SID for the trusting
forest, essentially granting users from a trusted forest almost all the
default rights that users in the trusting forest have. The benefit of
selective authentication is that it limits the groups of users who are
able to access resources across the trust and enables you to limit which
computers in the trusting forest can be accessed across the trust. You
can configure selective authentication when you first create the trust
or alter the properties of an existing trust as shown in Figure 1.
If you choose not to implement selective authentication, plan to remove
the Authenticated Users group from all sensitive resources in the
trusting domain.
