Windows Server 2008 R2 Unleashed (104 page)

1. Launch Server Manager on a domain controller.

2. Expand the Roles node and then expand the DNS Server node.

3. Select the DNS snap-in.

4. Navigate to DNS\\Forward Lookup Zones and select the zone to be

moved.

5. Right-click the zone to be moved, and click Properties.

6. Click the Change button to the right of the Replication description.

7. Select either To All DNS Servers Running on Domain Controllers in This Forest or To

All DNS Servers Running on Domain Controllers in This Domain, depending on the

level of replication you want, as shown in Figure 16.7. Click OK when you are fin-

ished and click OK again to save the changes.

ptg

16

FIGURE 16.7

Moving AD-integrated zones.

Repeat the process for any other AD-integrated zones.

Multiple Domain Consolidation Migration

There are cases when it is better to migrate to a new forest and domain, rather than bring

along the baggage of a legacy Active Directory. This includes needing to consolidate

names, concerns with the legacy Active Directory schema, or simply to consolidate Active

Directory services. The consolidation migration allows an administrator to, in effect, start

fresh with a clean installation of Active Directory. Figure 16.8 shows an example of the

migration scenario used in this section, where the companyabc.com and asia.compa-

nyabc.com will be consolidated to a new forest with the domain companyxyz.com.

506

CHAPTER 16

Migrating from Windows Server 2003/2008 to Windows Server

2008 R2

companyabc.com

companyxyz.com

asia.companyabc.com

Old Forest

New Forest

FIGURE 16.8

CompanyXYZ forest.

However, this can be disruptive to the users and applications if not handled carefully.

Migrating to a new domain and forest results in changes to the security identifiers, which

can impact access. It can also result in password changes, making it difficult for users.

However, there are tools and techniques, which are explored in this section, to mitigate

ptg

the impact to the users and applications.

The introduction of Windows Server 2008 coincided with improvements in the Active

Directory Migration Tool, a fully functional domain migration utility. ADMT version 3.1

allows Active Directory users, computers, and groups to be consolidated, collapsed, or

restructured to fit the design needs of an organization. In regard to Windows Server

2003/2008 migrations, ADMT v3.1 provides for the flexibility to restructure existing

domain environments into new Windows Server 2008 R2 Active Directory environments,

keeping security settings, user passwords, and other settings.

Understanding ADMT v3.1 Functionality

ADMT is an effective way to migrate users, groups, and computers from one domain to

another. It is robust enough to migrate security permissions and Exchange mailbox

domain settings. ADMT is composed of the following components and functionality:

.
ADMT migration wizards—
ADMT includes a series of wizards, each designed to

migrate specific components. You can use different wizards to migrate users, groups,

computers, service accounts, and trusts.

.
Low client impact—
ADMT automatically installs a service on source clients negat-

ing the need to manually install client software for the migration. In addition, after

the migration is complete, these services are automatically uninstalled.

.
SID History and security migrated—
Users can continue to maintain network

access to file shares, applications, and other secured network services through migra-

tion of the SID History attributes to the new domain. This preserves the extensive

security structure of the source domain.

Multiple Domain Consolidation Migration

507

NOTE

One unfortunate change in ADMT v3.1 is the removal of the test migration and rollback

functionality that was present in ADMT v2. Microsoft had numerous difficulties with it

and chose to deprecate the feature rather than resolve the issues.

ADMT v3.1 installs very easily but requires a thorough knowledge of the various wizards

to be used properly. In addition, best-practice processes should be used when migrating

from one domain to another.

The migration example in the following sections describes the most common use of the

Active Directory Migration Tool: an interforest migration of domain users, groups, and

computers into another domain. This procedure is by no means exclusive, and many

other migration techniques can be used to achieve proper results. Subsequently, matching

the capabilities of ADMT with the migration needs of an organization is important.

Using ADMT in a Lab Environment

You can develop the most effective lab by creating new domain controllers in the source

and target domains and then physically segregating them into a lab network, where they

ptg

cannot contact the production domain environment. The Operations Master (OM) roles

16

for each domain can then be seized for each domain using the NTDSUTIL utility, which

effectively creates exact replicas of all user, group, and computer accounts that can be

tested with the ADMT.

ADMT v3.1 Installation Procedure

Install the ADMT component on a Windows Server 2008 domain controller in the target

domain, where the accounts will be migrated to. To install, follow these steps:

NOTE

As of the writing of this book, ADMT 3.1 does not support installation on Windows

Server 2008 R2. To utilize the tool, install it on a Windows Server 2008 server. After

migration, decommission the Windows Server 2008 server.

1. Download ADMT 3.1 from the Microsoft Download site.

2. Choose Start, Run. Then browse to the download location, select admtsetup31.exe,

and click Open. Click OK.

3. Click Run to launch the setup.

4. On the Welcome page, click Next to continue.

5. Accept the end-user license agreement (EULA), and click Next to continue.

6. On the Customer Improvement Program page, click Next

7. Accept the default database selection, and click Next to continue.

508

CHAPTER 16

Migrating from Windows Server 2003/2008 to Windows Server

2008 R2

8. Leave the default No, Do Not Import Data from an Existing Database (Default). Click

Next to continue.

9. After installation, click Finish to close the wizard.

ADMT Domain Migration Prerequisites

As previously mentioned, the most important prerequisite for migration with ADMT is lab

verification. Testing as many aspects of a migration as possible can help to establish the

procedures required and identify potential problems before they occur in the production

environment.

That said, several technical prerequisites must be met before the ADMT can function prop-

erly. These are as follows:

.
Create two-way trusts between source and target domains—
The source and

target domains must each be able to communicate with each other and share secu-

rity credentials. Consequently, it is important to establish trusts between the two

domains before running the ADMT.

.
Assign proper permissions on source domain and source domain worksta-

tions—
The account that will run the ADMT in the target domain must be added

ptg

into the Builtin\Administrators group in the source domain. In addition, each work-

station must include this user as a member of the local Administrators group for the

computer migration services to be able to function properly. Domain group changes

can be easily accomplished, but a large workstation group change must be scripted,

or manually accomplished, prior to migration.

.
Create the target OU structure—
The destination for user accounts from the

source domain must be designated at several points during the ADMT migration

process. Establishing an organizational unit (OU) for the source domain accounts

can help to simplify and logically organize the new objects. These objects can be

moved to other OUs after the migration and this OU collapsed, if you want.

Exporting Password Key Information

The Password Export Server (PES) service is used to migrate passwords during interforest

migrations. This service must be installed on the source domain and uses a password key

generated previously.

A 128-bit encrypted password key must be installed from the target domain on a server in

the source domain. This key allows for the migration of password and SID History infor-

mation from one domain to the next.

To create this key, follow these steps from the command prompt of the ADMT server in

the target domain:

1. Insert a USB drive to store the key. (The key can be directed to the network but, for

security reasons, directing to a USB drive is better.)

2. Open a command prompt.

Multiple Domain Consolidation Migration

509

3. Type admt key /option:create /sourcedomain:

/keyfile:f:\domain.pes /keypassword:*, where is the

NetBIOS or DNS name of the source domain, f: is the destination drive for the key,

and domain.pes is the password encryption filename. Then press Enter.

4. The utility prompts for the password and confirmation of the password. Then the

utility creates the password onto the destination drive.

5. Upon successful creation of the key, remove the USB drive and keep it in a safe place.

This needs to be repeated for each domain to be migrated.

Installing PES on the Source Domain

After exporting the password key from the target domain, the encrypted password key

needs to be installed on a domain controller in the source domain. The procedure uses the

key generated previously. The following procedure outlines this installation:

1. Insert the USB drive with the exported key from the target domain into the server’s

disk drive.

2. The installation source is a separate download from Microsoft with a version for 32-

bit servers and one for 64-bit servers. This should be downloaded to the source

domain controller.

ptg

3. Start the Password Migration Installer by browsing to find the downloaded file,

PwdMig.msi, and running it.

16

4. On the Welcome page, click Next.

5. Accept the license agreement, and then click Next.

6. Enter the location of the key that was created on the target domain; normally, this is

the USB drive that was used to transfer the key. Click Next to continue.

7. Enter and confirm the password that was set on the key file, and click Next.

8. On the Verification page, click Next to continue.

9. Select an administrator account in the target domain for the service in the form

domain\account and the password, and then click OK.

10. Click Finish after the installation is complete.

11. Open the Services console (Start, Administrative Tools, Services). Select the Password

Export Server service and change its startup type to Automatic.

12. The system must be restarted, so click Yes when prompted to automatically restart.

Upon restarting, the proper settings will be in place to make this server a Password

Export Server.

The account used for the service will be granted the Logon As a Service right. This needs

to be installed on at least one source domain controller in each domain to be migrated.

Setting Proper Registry Permissions

The installation of the proper components creates special Registry keys, but leaves them

disabled by default for security reasons. One of these is the AllowPasswordExport value.

You need to enable this Registry key on the source domain to allow passwords to be

510

CHAPTER 16

Migrating from Windows Server 2003/2008 to Windows Server

2008 R2

exported from the Password Export Server. The following procedure outlines the use of the

Registry Editor to perform this function:

1. On the PES domain controller in the source domain, open the Registry Editor

(Start, Regedit).

2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

3. Double-click the AllowPasswordExport DWORD value.

4. Change the properties from 0 to 1 (Hexadecimal).

5. Click OK and close the Registry Editor.

6. Reboot the machine for the Registry changes to be enacted.

This allows passwords to be exported from the source domain to the target domain.

Configuring Domains for SID Migration

Migration of the source security identifiers (SIDs) into the target domain SID History

allows the security assigned in access control lists (ACLs) to work transparently after the

migration. This gives the administrator time to reset ACLs on a gradual basis or even after

all objects are migrated.

ptg

There are several settings that need to be configured to allow for the SIDs to be trans-

ferred. These settings include creating a local group in the source domain for auditing,

enabling TCP/IP client support on the source PDC emulator, and, finally, enabling audit-

ing on both the source and target domains.

To create the local group on the source domain for auditing, execute the following steps: