Chapter 11: Intraforest Migration

Section 2:
Migration Scenarios

The example companies, organizations, products, people, and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.

On This Page

Introduction
Scenario Steps
Summary
For More Information

Introduction

Overview

Before Hay Buv Toys made the decision to migrate the Microsoft Windows NT 4.0 domains HB-ACCT and HB-RES into the Microsoft Active Directory domain hay-buv.tld, one part of the evaluation process was to test all possible migration strategies in a lab environment. Chapter 9 shows how to upgrade a Windows NT 4.0 domain, and chapter 10 demonstrates how to restructure from Windows NT 4.0 domains directly to an Active Directory domain. This chapter focuses on the scenario where Windows NT 4.0 domains are upgraded and join the forest, and the resources are moved later. This results in intraforest restructuring.

In order to create a single target environment that looks exactly like the target domain used for the restructuring from Windows NT 4.0, the test team decided to choose the same names for the target domain and the organizational unit (OU) structure. Because the name of the OU will be HB-ACCT, a different name had to be chosen for the test Microsoft Windows 2000 domain. Active Directory does not support an organizational unit to have the same name as a child domain. The name of the account domain is therefore hb.acc.hay-buv.tld.

This technical walkthrough guides you through the steps necessary to migrate several Windows 2000 domains into a single Windows 2000 domain using the Active Directory Migration Tool (ADMT) within the same Windows 2000 forest. Intraforest migration allows you to restructure the Windows 2000 domain hierarchy. This document covers the following topics:

  • Test environment details

  • Scenario steps to migrate Windows 2000 child domains to a single Windows 2000 domain

Why Migrate Domain Structure into a Single Windows 2000 Domain?

Migrating Windows 2000 child domains into a single Windows 2000 domain allows administrators of Windows NT to:

  • Consolidate the number of domains.

  • Simplify the user and group administration.

  • Simplify group policy administration.

Test environment

A sample test environment consisting of the domain structure shown in the following graphic has been defined to provide a better understanding of the process. Multiple shares and resources are set up in the hb-res.hb-acc.hay-buv.tld domain with varying levels of access. Two users with accounts in the hb-acc.hay-buv.tld account domain access these shares and resources. Additionally, two service accounts show the procedures for migrating application servers to the new domain structure.

Bb727124.ckc11001(en-us,TechNet.10).gif

Figure 11.1

The computer roles are as follows (operating system is Windows 2000):

Computer name

Domain

Role

HAY-BUV-DC1

hay-buv.tld

Domain controller

HB-ACC-DC1

Hb-acc.hay-buv.tld

Domain controller
Fileserver for Profiles

HB-RES-DC1

hb-res.hb-acc.hay-buv.tld

Domain controller
Fileserver

HB-RES-DC2

hb-res.hb-acc.hay-buv.tld

Domain controller
Fileserver
IIS Server

HB-RES-MEM

hb-res.hb-acc.hay-buv.tld

Member Server
Fileserver
IIS Server

HB-RES-WS1

hb-res.hb-acc.hay-buv.tld

User Workstation
Office 2000 installed (Word only)

Preparing the Source and the Target Domain

The structure of domain hay-buv.tld is shown and described below.

First, create an organizational unit "Servers and Workstations" in domain hb-res.hb-acc.hay-buv.tld. The member server HB-RES-MEM and the workstation HB-RES-WS1 are assigned to this OU.

Create OUs HB-ACCT and HB-RES in domain hay-buv.tld. These OUs will contain the objects migrated from the corresponding domains. HB-ACCT was chosen as the OU name for hb-acc.hay-buv.tld because an OU is not allowed to have the same name as a direct child domain.

Bb727124.ckc11002(en-us,TechNet.10).gif

Figure 11.2: Active Directory Users and Computers of domain hay-buv.tld

The IT administrator created or modified the following accounts and groups. The administrator also created the domain users and groups in the OU users of the corresponding domain.

Domain/computer

Logon name

Account Type

Group members

hb-acc.hay-buv.tld

MikeG

User

N/A

hb-acc.hay-buv.tld

EricW

User

N/A

hb-acc.hay-buv.tld

ACC-Service

User

N/A

hb-res.hb-acc.hay-buv.tld

RES-Service

User

N/A

hb-acc.hay-buv.tld

Accounting

Global Group

hb-acc.hay-buv.tld\MikeG

hb-res.hb-acc.hay-buv.tld

Research

Domain Local Group

hb-acc.hay-buv.tld\Accounting

HB-RES-MEM

Marketing

Local Group

hb-acc.hay-buv.tld\Accounting

HB-RES-MEM

Administrators

Local Group

New members:
hb-acc.hay-buv.tld\ACC-Service, hb-res.hb-acc.hay-buv.tld\RES-Service

HAY-BUV

Administrators

Built-in Local Group

New member:
hb-res.hb-acc.hay-buv.tld\administrator

The user principal name for all the above users is <logonname>@hay-buv.tld. The password is empty and the only password attribute set is "Password never expires."

Additional properties have been assigned to the user EricW using User Manager Snap-in for Domains. These properties are:

  • A roaming profile, \\HB-ACC-DC1\Profiles\EricW, which points to the directory <drive>:\Shares\Profiles\EricW on HB-ACC-DC1.

  • Account/Logon Hours: Allowed any day except Saturday and Sunday.

  • Dial-in/Access granted.

For user MikeG, the following properties are defined:

Home Directory: mapped to X:\ is share \\HB-RES-DC1\MikeG.

This share points to the directory <drive>:\Shares\MikeG on HB-RES-DC1.

These attributes will be verified after EricW and MikeG are migrated.

The Internet Information Services (IIS) servers HB-RES-DC2 and HB-RES-MEM use the default local sample Web page, iisstart.asp, that is installed during the Windows 2000 server setup as a startup page. The path to the Web site is <drive>:\InetPub\wwwroot. Through Administrative Tools/Internet Information Services set "Integrated Windows authentication" as authentication mechanism and disable anonymous access.

HB-RES-MEM has two services running under user accounts from the domains hb-acc.hay-buv.tld and hb-res.hb-acc.hay-buv.tld. The Telnet Service is running with hb-acc.hay-buv.tld\ACC-Service and the ClipBook Service is running with hb-res.hb-acc.hay-buv.tld\RES-Service. These service properties can be set with Administrative Tools/Services.

The administrator installs Office 2000 on HB-RES-MEM as an Admin Installation in the file share \\HB-RES-MEM\Office2000Inst. All users have read-only access to this share. On the workstation HB-RES-WS1, the administrator installs only the Word component of the Office 2000 suite.

This creates the following shared folders. All shares point to corresponding directories on the servers under <drive>:\Shares.

Note: The member server, HB-RES-MEM, cannot use the hb-res.hb-acc.hay-buv.tld\Research domain local group for access to the ResearchDocs share unless hb-res.hb-acc.hay-buv.tld is in native mode.

Resource

Share name

Access rights

\\HB-RES-DC1\Research

Research

hb-res.hb-acc.hay-buv.tld\Research: FC

\\HB-RES-DC1\MikeG

MikeG

hb-acc.hay-buv.tld\MikeG: FC

\\HB-RES-DC2\Execdocuments

Execdocuments

hb-res.hb-acc.hay-buv.tld\Research: FC

\\HB-RES-MEM\Specifications

Specifications

HB-RES-MEM\Marketing: FC

\\HB-RES-MEM\Office2000Inst

Office2000Inst

Everyone: R

\\HB-RES-MEM\ResearchDocs

ResearchDocs

hb-res.hb-acc.hay-buv.tld\Research: FC

\\HB-ACC-DC1\Profiles

Profiles

Everyone: FC

FC = Full Control, R = Read Only

In addition, the administrator sets the following discretionary access control list (DACL) permissions:

Resource

DACL permission

\\HB-ACC-DC1\Profiles\EricW

hb-acc.hay-buv.tld\EricW: FC

HB-RES-DC2, <drive>:\InetPub\wwwroot

hb-res.hb-acc.hay-buv.tld\Research: FC

HB-RES-MEM, <drive>:\InetPub\wwwroot

HB-RES-MEM\Marketing: FC

FC = Full Control, R = Read Only

The migration steps involve migrating the Windows 2000 hb-res.hb-acc.hay-buv.tld domain including all groups and resources into the Windows 2000 domain, hay-buv.tld. When the migration of groups and resources is complete, the administrator can reassign or decommission the Windows 2000 hb-res.hb-acc.hay-buv.tld domain.

After migrating the hb-res.hb-acc.hay-buv.tld domain, the hb-acc.hay-buv.tld domain will be migrated. This includes the migration of all users and groups into the Windows 2000 domain, hay-buv.tld. When the migration of groups and users is complete, the administrator can reassign or decommission the Windows 2000 hb-acc.hay-buv.tld domain.

After the test scenario has been implemented, do the following:

  • Log on to workstation HB-RES-WS1 as user hb-acc.hay-buv.tld\MikeG.

  • Change the desktop color scheme to brick.

  • Add a text document called "Letter" to the desktop.

  • Put a bitmap called "MikeG's Bitmap" into the recycle bin.

Test

Expected result

MikeG access to https://HB-RES-DC2

Success

MikeG access to https://HB-RES-MEM

Success

MikeG access to \\HB-RES-DC1\Research

Success

MikeG access to \\HB-RES-DC1\MikeG

Success

MikeG access to \\HB-RES-DC2\ExecDocuments

Success

MikeG access to \\HB-RES-MEM\Specifications

Success

MikeG access to \\HB-RES-MEM\ResearchDocs

Success

MikeG install of an additional Office2000 component from \\HB-RES-MEM\Office2000Inst

Success

MikeG access to \\HB-ACC-DC1\Profiles

Success

MikeG access to \\HB-ACC-DC1\Profiles\EricW

Failure

Next:

  • Log on to workstation HB-RES-WS1 as user hb-acc.hay-buv.tld\EricW.

  • Change the desktop color scheme to maple.

  • Add a folder called "Documents" to the desktop.

  • Put a bitmap called "EricW's Bitmap" into the recycle bin.

Test

Expected result

EricW access to https://HB-RES-DC2

Failure

EricW access to https://HB-RES-MEM

Failure

EricW access to \\HB-RES-DC1\Research

Failure

EricW access to \\HB-RES-DC1\MikeG

Failure

EricW access to \\HB-RES-DC2\ExecDocuments

Failure

EricW access to \\HB-RES-MEM\Specifications

Failure

EricW access to \\HB-RES-MEM\ResearchDocs

Failure

EricW install of an additional Office2000 component from \\HB-RES-MEM\Office2000Inst

Success

EricW access to \\HB-ACC-DC1\Profiles

Success

EricW access to \\HB-ACC-DC1\Profiles\EricW

Success

ClipBook Service on HB-RES-MEM runs under account hb-res.hb-acc.hay-buv.tld\RES-Service

Success

Telnet Service on HB-RES-MEM runs under account hb-acc.hay-buv.tld\ACC-Service

Success

Terminology

You should be familiar with the following terms and their meanings in order to migrate resources between Windows 2000 domains:

Source domainthe Windows 2000 domain containing the original security principal that is to be migrated.

Source objectthe security principal object to be migrated.

Target domainthe Windows 2000 native mode domain in which the migrated principal account is created.

Target objectthe security principal, in the destination domain, whose attributes have been migrated from a source object and whose sIDHistory contains the security identifier (SID) of the source object.

Built-in accountsdefault groups that are security groups and represent common sets of rights and permissions that you can use to grant certain roles, rights, and permissions to the accounts and groups that you place into them. Their SIDs are identical in every domain/computer.

Windows 2000 Server "Built-in" Accounts

Account name

Domain controller

Member server

Administrators

Yes

Yes

Backup operators

Yes

Yes

Guests

Yes

Yes

Replicator

Yes

Yes

Users

Yes

Yes

Print operators

Yes

No

Server operators

Yes

No

Account operators

Yes

No

Pre-Windows 2000 compatible access

Yes

No

Power users

No

Yes

Requirements

In order to use this technical walkthrough, the following requirements must be met:

  • Target Windows 2000 domain hay-buv.tld set to native mode.

  • Source domain is Windows 2000.

  • Source domain hb-res.hb-acc.hay-buv.tld set to native mode.

  • Source domain must be in same forest as target domain.

    Source object must be of one of the following types:

    • User

    • Security-enabled group, including:

    • Local group on domain controllers

    • Domain local group (only available in native mode Windows 2000 domains)

    • Global group

    • Computer

  • The SID of the source object must not already exist in the forest, either as a primary account SID or in the sIDHistory of an account.

  • ADMT must be executed from a computer running Windows 2000.

The following requirement is specific to the migration of groups and users: The source object cannot be a built-in account (for example, local administrators, users, and power users). Built-in account SIDs are identical in every domain; thus, adding them to a sIDHistory would violate the requirement that the SID of a domain be unique.

Security Requirements

In order to use this technical walkthrough, the following security requirements must be met:

  • A user must run the ADMT with administrator rights in source and target domains.

  • Auditing must be enabled in both the source and target domains. The procedure to set this is described in the section "Preparing the Windows 2000 Domains"

  • Administrative shares must exist on the computer where the ADMT is executing and any computer where the ADMT must install an agent.

Walkthrough

In this walkthrough, you will learn how to prepare the Windows 2000 target domain for migration, migrate the Windows 2000 groups and user accounts, and test the migrated users.

The walkthrough consists of the following scenario steps:

  1. Preparing the Windows 2000 domains.

  2. Identifying services from hb-res.hb-acc.hay-buv.tld not running under Local System Account (LSA).

  3. Migrating a computer running Windows 2000 Professional.

  4. Migrating a service account.

  5. Updating hb-res.hb-acc.hay-buv.tld service account user rights and group membership.

  6. Migrating a domain local group.

  7. Migrating a Windows 2000 member server.

  8. Migrating a domain controller and decommissioning the domain hb-res.hb-acc.hay-buv.tld.

  9. Migrating a global group.

  10. Identifying services from hb-acc.hay-buv.tld not running under LSA.

  11. Migrating a service account, user account, and roaming profile.

  12. Updating hb-acc.hay-buv.tld service account user rights and group membership.

  13. Migrating local profiles on computers running Windows 2000 Professional.

  14. Migrating a domain controller and decommissioning the domain hb-acc.hay-buv.tld.

  15. Performing migration tests.

The following flowchart shows the steps to perform the intraforest migration.

Bb727124.ckc11003(en-us,TechNet.10).gif

Figure 11.3: Flowchart showing the migration steps

Scenario Steps

Preparing the Windows 2000 Domains

Enable Auditing

To enable the auditing policy for account changes in the Windows 2000 domains, the group policy object on the "Domain Controllers" OU has to be edited in all domains:

  1. Log on to the domain with administrative rights.

  2. In the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, select the domain and double-click to open it.

  3. In the left MMC pane, select the OU Domain Controllers. Right-click Domain Controllers and select Properties in the drop-down menu.

  4. In the Properties window, select the Group Policy tab.

  5. Highlight Default Domain Controllers Policy and click Edit. The group policy snap-in will launch.

  6. At Default Domain Controllers Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy, double-click Audit account management. Select Success and Failure and then click OK. Close all previously opened windows.

  7. Replicate the changed group policy object to all domain controllers in the domain through Active Directory Sites and Services or wait five minutes for automatic update.

  8. Apply the new group policy through the command SECEDIT /REFRESHPOLICY MACHINE_POLICY on every domain controller.

Bb727124.ckc11004(en-us,TechNet.10).gif

Figure 11.4: Account management auditing must be enabled in the target domain

Additionally, a new policy for the "Servers and Workstations" OU must be implemented.

  1. Log on to the domain with administrative rights.

  2. In the Active Directory Users and Computers MMC snap-in, select the domain and double-click to open it.

  3. In the left MMC pane, select the OU Servers and Workstations. Right-click Servers and Workstations and select Properties in the drop-down menu.

  4. In the Properties dialog, select the Group Policy tab.

  5. Click New and type Domain-Servers-Workstations as for the policy.

  6. Highlight Domain-Servers-Workstations and click Edit. The group policy editor will launch.

  7. At Domain-Servers-Workstations\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy, double-click Audit account management. Select Success and Failure and then click OK.

  8. Replicate the changed group policy object to all domain controllers in the domain through Active Directory Sites and Services or wait five minutes for automatic update.

  9. Apply the new group policy through the command SECEDIT /REFRESHPOLICY MACHINE_POLICY on all members of the OU, that is, HB-RES-MEM and HB-RES-WS1.

Change Domain to Native Mode

The migration target Windows 2000 domain hay-buv.tld and the source domain hb-res.hb-acc.hay-buv.tld must be running in native mode in order for the migration process to function correctly.

  1. Run the Active Directory Users and Computers MMC snap-in.

  2. Highlight the Windows 2000 domain to be changed and right-click.

  3. Choose Properties.

  4. Click Change Mode on the General tab.

Figure 11.5: Domain hay-buv.tld running in native mode

Figure 11.5: Domain hay-buv.tld running in native mode

Install Windows 2000 Support Tools

The Active Directory Administration Tool is installed as part of the support tools installation. This tool will be used during the walkthrough to verify the migration results.

Identifying Services from hb-res.hb-acc.hay-buv.tld not Running Under LSA

Service accounts are user accounts used to operate services on Windows NT and Windows 2000 computers. For this walkthrough, two services on member server HB-RES-MEM were configured not to run under LSA. A service account from the hb-res.hb-acc.hay-buv.tld domain is used for the ClipBook Service and a service account from the hb-acc.hay-buv.tld domain for the Telnet Service.

This step in the walkthrough finds the services not running under LSA. These will be included into the list of service account identified as not running under LSA. Therefore, the accounts must be migrated.

Note: This step does not migrate the accounts. It only identifies them for later migration.

From the target Windows 2000 domain controller, HAY-BUV-DC1, log on as hb-res.hb-acc.hay-buv.tld\administrator and launch the ADMT. (If the logon fails, make sure that "logon locally" is enabled for everybody in the domain controller's security group policies.) To begin the Service Account Migration Wizard, select Active Directory Migration Tool in the left pane, right-click, and select Service Account Migration Wizard from the menu.

Figure 11.6:

Figure 11.6

Click Next.

Figure 11.7:

Figure 11.7

Select hb-res.hb-acc.hay-buv.tld as the source domain and hay-buv.tld as the target domain. You can also use the NetBIOS names of the domains, as the graphic shows.

Click Next.

Figure 11.8:

Figure 11.8

Select Yes, update the information.

Click Next.

On the next window, click Add to choose the computers that are used as information resources.

Bb727124.ckc11009(en-us,TechNet.10).gif

Figure 11.9

Choose HB-RES-MEM.

Click Add.

Click OK.

Figure 11.10:

Figure 11.10

Click Next. The User Account credentials dialog box opens**.**

Figure 11.11:

Figure 11.11

Enter credentials for the hb-res.hb-acc.hay-buv.tld\Administrator account.

Click Next. The Agent Monitor dialog box opens. This dialog box shows the status of the operation.

Figure 11.12:

Figure 11.12

After the operation is complete, check the Dispatch Log file. Click View Dispatch Log.

The Agent Detail Log file, DCTLog.txt, contains detailed information about the operations performed on the chosen computers and is quite useful for troubleshooting.

To view the Agent Detail Log, click on the computer's name, as above, after the agent is complete.

Figure 11.13:

Figure 11.13

This brings up the Agent Progress dialog box. Click View Log to see the DCTLog file created by the agent and located on that selected computer. Below is the output of the Agent Detail Log file:

2000-01-31 18:50:45- 
2000-01-31 18:50:45-Active Directory Migration Tool, Starting... 
2000-01-31 18:50:45-Service Account information gathering beginning. 
2000-01-31 18:50:45-Alerter uses account LocalSystem. 
2000-01-31 18:50:45-AppMgmt uses account LocalSystem. 
2000-01-31 18:50:45-Browser uses account LocalSystem. 
2000-01-31 18:50:45-cisvc uses account LocalSystem. 
2000-01-31 18:50:45-ClipSrv uses account HB-RES\RES-Service. 
2000-01-31 18:50:45-Dfs uses account LocalSystem. 
2000-01-31 18:50:45-Dhcp uses account LocalSystem. 
2000-01-31 18:50:45-dmadmin uses account LocalSystem. 
2000-01-31 18:50:45-dmserver uses account LocalSystem. 
2000-01-31 18:50:45-Dnscache uses account LocalSystem. 
2000-01-31 18:50:45-Eventlog uses account LocalSystem. 
2000-01-31 18:50:45-EventSystem uses account LocalSystem. 
2000-01-31 18:50:45-Fax uses account LocalSystem. 
2000-01-31 18:50:45-IISADMIN uses account LocalSystem. 
2000-01-31 18:50:45-IsmServ uses account LocalSystem. 
2000-01-31 18:50:45-kdc uses account LocalSystem. 
2000-01-31 18:50:45-lanmanserver uses account LocalSystem. 
2000-01-31 18:50:45-lanmanworkstation uses account LocalSystem. 
2000-01-31 18:50:45-LicenseService uses account LocalSystem. 
2000-01-31 18:50:45-LmHosts uses account LocalSystem. 
2000-01-31 18:50:45-Messenger uses account LocalSystem. 
2000-01-31 18:50:45-mnmsrvc uses account LocalSystem. 
2000-01-31 18:50:45-MSDTC uses account LocalSystem. 
2000-01-31 18:50:45-MSIServer uses account LocalSystem. 
2000-01-31 18:50:45-NetDDE uses account LocalSystem. 
2000-01-31 18:50:45-NetDDEdsdm uses account LocalSystem. 
2000-01-31 18:50:45-Netlogon uses account LocalSystem. 
2000-01-31 18:50:45-Netman uses account LocalSystem. 
2000-01-31 18:50:45-NtFrs uses account LocalSystem. 
2000-01-31 18:50:45-NtLmSsp uses account LocalSystem. 
2000-01-31 18:50:45-NtmsSvc uses account LocalSystem. 
2000-01-31 18:50:45-PlugPlay uses account LocalSystem. 
2000-01-31 18:50:45-PolicyAgent uses account LocalSystem. 
2000-01-31 18:50:45-ProtectedStorage uses account LocalSystem. 
2000-01-31 18:50:45-RasAuto uses account LocalSystem. 
2000-01-31 18:50:45-RasMan uses account LocalSystem. 
2000-01-31 18:50:45-RemoteAccess uses account LocalSystem. 
2000-01-31 18:50:45-RemoteRegistry uses account LocalSystem. 
2000-01-31 18:50:45-RpcLocator uses account LocalSystem. 
2000-01-31 18:50:45-RpcSs uses account LocalSystem. 
2000-01-31 18:50:45-RSVP uses account LocalSystem. 
2000-01-31 18:50:45-SamSs uses account LocalSystem. 
2000-01-31 18:50:45-SCardDrv uses account LocalSystem. 
2000-01-31 18:50:45-SCardSvr uses account LocalSystem. 
2000-01-31 18:50:45-Schedule uses account LocalSystem. 
2000-01-31 18:50:45-seclogon uses account LocalSystem. 
2000-01-31 18:50:45-SENS uses account LocalSystem. 
2000-01-31 18:50:45-SharedAccess uses account LocalSystem. 
2000-01-31 18:50:45-SMTPSVC uses account LocalSystem. 
2000-01-31 18:50:45-Spooler uses account LocalSystem. 
2000-01-31 18:50:45-SysmonLog uses account LocalSystem. 
2000-01-31 18:50:45-TapiSrv uses account LocalSystem. 
2000-01-31 18:50:45-TermService uses account LocalSystem. 
2000-01-31 18:50:45-TlntSvr uses account HB-ACC\ACC-Service. 
2000-01-31 18:50:45-TrkSvr uses account LocalSystem. 
2000-01-31 18:50:45-TrkWks uses account LocalSystem. 
2000-01-31 18:50:45-UPS uses account LocalSystem. 
2000-01-31 18:50:45-UtilMan uses account LocalSystem. 
2000-01-31 18:50:45-W32Time uses account LocalSystem. 
2000-01-31 18:50:45-W3SVC uses account LocalSystem. 
2000-01-31 18:50:45-WinMgmt uses account LocalSystem. 
2000-01-31 18:50:45-Wmi uses account LocalSystem. 
2000-01-31 18:50:45-MSFTPSVC uses account LocalSystem. 
2000-01-31 18:50:45-NNTPSVC uses account LocalSystem. 
2000-01-31 18:50:45-OnePointDomainAdminService uses account LocalSystem. 
2000-01-31 18:50:45-Service Account information gathering completed. 
2000-01-31 18:50:45-A session to \\HAY-BUV-DC1 established,
                    to report the results of the migration. 
2000-01-31 18:50:45-Wrote result file \\HAY-BUV-DC1\OnePointDMR$\HB-RES-MEM372972593.result 
2000-01-31 18:50:45-Operation completed.

Click Close to get back to the Agent Monitor dialog box.

Click Close again to view the discovered services that do not run under an LSA account.

Figure 11.14:

Figure 11.14

Note: Any accounts listed in this information screen in user principal name format (that is, ACC-Service@hay-buv.tld) will not be recognized by the User Migration Wizard as a valid service account. Prior to migrating any such service accounts, you will have to rerun this Service Account Migration Wizard specifying that service account's domain as the source domain. You will do this later in this walkthrough.

Click Next.

Figure 11.15:

Figure 11.15

Click Finish.

After the Service Account Migration Wizard has finished, there is information in the ADMT database about these service accounts. When the service accounts, other than those in user principal name format, are migrated using the User Migration Wizard, the tool will make the proper changes on the member server. This is discussed later in the section "Migrating a Service Account." If the service accounts are not in the same domain as the member server, you will have to rerun the Service Account Migration Wizard after you have successfully migrated the service accounts from this member server's domain.

If the service account is granted its rights to start a service via the groups in which it is a member, there is an additional step to update user rights and group membership for these accounts. This is accomplished by running the Security Translation Wizard, which is discussed later in the section "Update hb-res.hb-acc.hay-buv.tld Service Account User Rights and Group Membership."

Migrating a Computer Running Windows 2000 Professional

Now you migrate the workstation to the root domain hay-buv.tld.

Workstations have their own Security Accounts Manager (SAM) account database. If they are moved between domains, they always take this database with them. If accounts that live in the local SAM database (like Local Groups) were used to grant access to resources, they will always move with the computer. Therefore, migrating these accounts is not necessary.

The objective is to move the Windows 2000 workstation HB-RES-WS1 from the Windows 2000 hb-res.hb-acc.hay-buv.tld domain to the HB-RES OU in the Windows 2000 hay-buv.tld domain.

From the target Windows 2000 domain controller, HAY-BUV-DC1, log on as hb-res.hb-acc.hay-buv.tld \administrator and launch the ADMT.

Note: If the domain has more than one domain controllers, the ADMT should be installed and run from the relative identifier (RID) pool master of that domain for performance reasons. By default, this is the first installed domain controller. Check the domain Operations Master roles through Active Directory Users and Computers or Ntdsutil.exe.

To begin the Computer Migration Wizard, select Active Directory Migration Tool in the left pane, right-click, and select Computer Migration Wizard from the menu.

Figure 11.16:

Figure 11.16

Click Next.

Figure 11.17:

Figure 11.17

Select Migrate now?

Click Next.

Figure 11.18:

Figure 11.18

Select hb-res.hb-acc.hay-buv.tld in the Source domain list (or use the downlevel NetBIOS name HB-RES) .

Select hay-buv (or hay-buv.tld) in the Target domain list.

Click Next.

Bb727124.ckc11019(en-us,TechNet.10).gif

Figure 11.19

Click Add, select the workstation in the source domain HB-RES-WS1, click Add, and then click OK.

Figure 11.20:

Figure 11.20

Click Next.

Click Browse in the following window to select the OU you want to migrate the users to.

Figure 11.21:

Figure 11.21

Select HB-RES.

Click OK.

Figure 11.22:

Figure 11.22

Click Next.

Figure 11.23:

Figure 11.23

Ensure that no items are selected in this dialog box and click Next.

Note: Security translation during computer migration works only for accounts from the migrated computer's domain itself. The objects above have to be adjusted later by using the Security Translation Wizard because you have not migrated any users yet and the DACLs contain SIDs from other domains.

Figure 11.24:

Figure 11.24

Enter the source domain's administrative credentials.

Click Next.

Figure 11.25:

Figure 11.25

Enter the time you want the agent to wait before restarting the workstation. Because the computer is restarted remotely, you have to make sure that the default startup option will restart the desired Windows 2000 installation. Five minutes is the default time but 1 minute should be sufficient in most cases.

Click Next.

Figure 11.26:

Figure 11.26

Select Ignore conflicting accounts and don't migrate.

Click Next.

Figure 11.27:

Figure 11.27

Click Finish.

Figure 11.28:

Figure 11.28

When the operation completes, the dialog box Status indicates Completed.

Figure 11.29:

Figure 11.29

To view the Migration Log file, click View Log.

Tip The Migration Log file and Dispatch Log file are quite useful for troubleshooting the Computer Migration Wizard.

Below is the output of the Migration Log file for the computer migration:

2000-01-31 19:16:03- 
2000-01-31 19:16:03-Active Directory Migration Tool, Starting... 
2000-01-31 19:16:03-Starting Account Replicator. 
2000-01-31 19:16:03-Account Migration HB-RES HAY-BUV CopyUsers:No CopyGlobalGroups: 
No CopyLocalGroups:No CopyComputers:Yes  
2000-01-31 19:16:04-CN=HB-RES-WS1        - Created 
2000-01-31 19:16:11- - Set password for HB-RES-WS1. 
2000-01-31 19:16:11-Operation completed.

To complete the Computer Migration Wizard, click Close.

Figure 11.30:

Figure 11.30

The agents are then dispatched to the computers to be migrated. Once the agents are dispatched, the Agent Monitor shows the status of each agent. When the status changes to Completed, you should see the System Shutdown box on the server counting the time you specified above.

Click View Dispatch Log.

Below is the output of the Dispatch Log file for the computer migration:

2000-01-31 19:17:17-The dispatcher created a share for the result directory C:\Program Files\Active  
Directory Migration Tool\Logs\Agents as: \\HAY-BUV-DC1\OnePointDMR$\ 
2000-01-31 19:17:17-Installing agent on 1 servers 
2000-01-31 19:17:17-The The Active Directory Migration Tool Agent will be installed on \\HB-RES-WS1 
2000-01-31 19:17:21-The agent is installed on \\HB-RES-WS1 
2000-01-31 19:17:21-Started job:  \\HB-RES-WS1 HB-RES-WS1374569125  
{1CD7F8BF-BB0F-4C3C-A20B-4DB90F6A288C} 
2000-01-31 19:17:22-All agents are installed.  The dispatcher is finished.

After restarting, HB-RES-WS1 is a member of the HAY-BUV domain.

To verify this, log on to HB-RES-WS1, right-click My Computer, select Properties, and click on the Network Identification tab.

Figure 11.31: The workstation HB-RES-WS1 was moved to the hay-buv.tld domain

Figure 11.31 The workstation HB-RES-WS1 was moved to the hay-buv.tld domain

Migrating a Service Account

This step migrates the service account hb-res.hb-acc.hay-buv.tld\RES-Service identified earlier (see "Identifying Services not Running Under LSA") to the target domain. The other service account hb-acc.hay-buv.tld\ACC-Service will be migrated later.

From the target Windows 2000 domain controller, HAY-BUV-DC1, log on as hb-res.hb-acc.hay-buv.tld\administrator and launch the ADMT from within the MMC. To begin the User Migration Wizard, select Active Directory Migration Tool in the left pane, right-click, and select User Migration Wizard from the menu.

Figure 11.32:

Figure 11.32

Click Next.

Figure 11.33:

Figure 11.33

Select Migrate now?

Click Next.

Figure 11.34:

Figure 11.34

Click Next.

To select the account you want to migrate, click Add in the next dialog box, select hb-res.hb-acc.hay-buv.tld\RES-Service, and click Add.

Bb727124.ckc11035(en-us,TechNet.10).gif

Figure 11.35

Click OK.

Figure 11.36:

Figure 11.36

Click Next.

In the next window, click Browse to choose the OU you want to migrate the service account to, select hb-res.hb-acc.hay-buv.tld, and then click OK.

Figure 11.37:

Figure 11.37

Click Next.

Figure 11.38:

Figure 11.38

Enter credentials for the hay-buv.tld\Administrator account (or use the short NetBIOS domain name HAY-BUV).

Click Next.

Figure 11.39:

Figure 11.39

Select Update user rights and Do not rename accounts.

Click Next.

Bb727124.ckc11040(en-us,TechNet.10).gif

Figure 11.40

Click OK.

Figure 11.41:

Figure 11.41

Select Ignore conflicting accounts and don't migrate.

Click Next.

Figure 11.42:

Figure 11.42

This windows indicates what service account information in the service control manager (SCM) is updated during the migration.

Click Next.

Bb727124.ckc11043(en-us,TechNet.10).gif

Figure 11.43

This dialog box is a warning that if the service account has any local rights inherited only from its membership to a local group (such as "increase quotas" as a member of local administrators), then you must update these rights by running the Security Translation Wizard (see the section titled "Update hb-res.hb-acc.hay-buv.tld Service Account User Rights and Group Membership").

In either case, the ADMT recognizes that it is migrating a service account and thus grants it the right to log on as a service and generates a complex password. The complex password is written to the file passwords.txt in the ADMT log directory. You can check that in the appropriate log file.

Figure 11.44:

Figure 11.44

Click Finish.

The Migration Progress dialog box is displayed and updated. When the operation completes, the Status property indicates Completed.

Figure 11.45:

Figure 11.45

Click Close.

This procedure migrated a single service account from the same domain as the member server. In case the service account resides in a different domain than the server (such as, an account domain), the above procedure would need to be repeated for the service account with that domain as the migration source, as long as that service account is not listed in the Service Account Migration Wizard by its user principal name. For those service accounts that are listed by their user principal name (that is, Acc-Service@hay-buv.tld), you will migrate them later in this walkthrough.

The window below shows the updated account information for the ClipBook service on HB-RES-MEM

Figure 11.46:

Figure 11.46

Updating hb-res.hb-acc.hay-buv.tld Service Account User Rights and Group Membership

The next step is to update the local rights inherited from membership in local groups on the member server using the Security Translation Wizard.

You have migrated the service account to the target domain. Now you must ensure that this new account has the same set of local rights to the member server that the old account did. This is accomplished with the ADMT Security Translation Wizard. The wizard updates these rights for the moved service accounts only, since no other users have been migrated. The information on these accounts is still in the internal ADMT database.

From the target Windows 2000 domain controller, HAY-BUV-DC1, log on as hb-res.hb-acc.hay-buv.tld\administrator and launch the ADMT from within the MMC. To begin the Security Translation Wizard, select Active Directory Migration Tool in the left pane, right-click, and then select Security Translation Wizard from the menu.

Figure 11.47:

Figure 11.47

Click Next.

Figure 11.48:

Figure 11.48

Select Migrate now?

Click Next.

Figure 11.49:

Figure 11.49

Click Next.

Bb727124.ckc11050(en-us,TechNet.10).gif

Figure 11.50

Click Add, select HB-RES-MEM, click Add, and then click OK.

Figure 11.51:

Figure 11.51

Click Next.

Figure 11.52:

Figure 11.52

Select Local groups and User rights.

Click Next.

Figure 11.53:

Figure 11.53

Click Next.

Note: Replace is the only option enabled since accounts are moved during an intraforest migration and the source accounts no longer exist.

Figure 11.54:

Figure 11.54

Enter the hb-res.hb-acc.hay-buv.tld\Administrator credentials.

Click Next.

Note: You enter the hb-res.hb-acc.hay-buv.tld credentials here because you have to supply credentials that have local administrator authority on the member server. If you were completing this step after the migration of the computer to the target domain, you would have to use the HAY-BUV source domain credentials.

Figure 11.55:

Figure 11.55

Click Finish.

After the agents are dispatched, the Agent Monitor dialog box is displayed.

Figure 11.56:

Figure 11.56

When the agent's status changes from Running to Completed, click Close to complete the wizard.

At this point you have updated local group security on the HB-RES-MEM server by adding the migrated service account to any local groups it may have been a member of, such as local administrators.

You can verify this on HB-RES-MEM with Settings/Users and Passwords/Advanced/Advanced User Management/Advanced/Groups. Then select the group on the right MMC screen and double-click to see the properties.

Figure 11.57:

Figure 11.57

Notice hb-res.hb-acc.hay-buv.tld\RES-Service has been replaced with HAY-BUV\RES-Service. This will happen on a computer running Windows 2000 in a native mode domain even without running the Security Translation Wizard, but running the wizard not only changed the visible name but also the actual SID in this group's ACL.

Migrating a Domain Local Group

This wizard migrates the shared local group defined on the hb-res.hb-acc.hay-buv.tld domain controllers to the target domain and places it in the HB-RES organizational unit converting it to a domain local group.

On the target Windows 2000 domain controller, HAY-BUV-DC1, log on as hb-res.hb-acc.hay-buv.tld\administrator and launch the ADMT from within the MMC. Open the ADMT and select the Group Migration Wizard from the Action menu.

Figure 11.58:

Figure 11.58

Click Next.

Figure 11.59:

Figure 11.59

Select Migrate now?

Click Next.

Figure 11.60:

Figure 11.60

Click Next.

To select the sales shared local group, click Add in the next dialog box, select Research, click Add, and then click OK.

Figure 11.61:

Figure 11.61

Click Next.

Figure 11.62:

Figure 11.62

Click Next.

In the Group Options dialog box, ensure that only Do not rename accounts is selected.

Figure 11.63:

Figure 11.63

Click Next.

Figure 11.64:

Figure 11.64

Enter the HAY-BUV\Administrator credentials. You can again either use the DNS naming convention for the domain, hay-buv.tld, or the short NetBIOS form, HAY-BUV.

Click Next.

Figure 11.65:

Figure 11.65

Select Ignore conflicting accounts and don't migrate.

Click Next.

Figure 11.66:

Figure 11.66

Click Finish.

Figure 11.67:

Figure 11.67

The Migration Progress dialog box is displayed and updated. When the operation completes, the dialog box Status property indicates Completed. View the log file if you wish, then click Close.

The Status message confirms that the migration process was successful. As a result of the migration, the following actions were performed:

  • A new group was created with a new primary SID called CN=Research,OU=HB-RES,DC=HAY-BUV,DC=tld.

  • The SID of the source group hb-res.hb-acc.hay-buv.tld\Research was added to the sIDHistory attribute of the new group CN=Research,OU=HB-RES,DC=HAY-BUV,DC=tld.

    The following events are logged in the target domain:

    • Security log: event ID 635, Security Enabled Local Group Created.

    • Security log: event ID 636, Security Enabled Local Group Added.

To verify that the group is migrated with its old SID, start Active Directory Administration Tool and check the sIDHistory entry:

  1. Open Active Directory Administration Tool (ldp.exe) through Windows 2000 Support Tools/Tools/Active Directory Administration Tool.

  2. Open the Connection menu, select Connect, and click OK.

  3. Open the Connection menu, select Bind, and click OK.

  4. Open the View menu and select Tree.

  5. Expand the tree to see the Research group.

Bb727124.ckc11068(en-us,TechNet.10).gif

Figure 11.68

Alternatively, you could use Windows 2000 Support Tools/Tools/ADSI Edit to see the sIDHistory attribute.

The new group can be viewed in the Active Directory Users and Computers MMC console on HAY-BUV-DC1.

Bb727124.ckc11069(en-us,TechNet.10).gif

Figure 11.69

The shared local group Research was migrated from the Windows 2000 domain hb-res.hb-acc.hay-buv.tld to the OU HB-RES in the Active Directory domain hay-buv.tld. Since the target domain hay-buv.tld is a native mode domain, the group is now a domain local group, meaning that it can also be used in DACLs on member servers. This is especially important if domain controllers from a source domain will be migrated to member servers in the target domain, and shared local groups were used in a mixed mode source domain.

The ADMT also preserved the group memberships of the migrated group:

Figure 11.70:

Figure 11.70

Group memberships are preserved when a group is migrated.

Note: If any resources on a domain controller or a Member Server receive permission from domain local groups, you have to migrate the computers before users can access the resources again. This is because a domain local group can only be used within the same domain.

Migrating a Windows 2000 Member Server

The Windows 2000 Member Server HB-RES-MEM will now be migrated to the target domain with ADMT Computer Migration Wizard. Move HB-RES-MEM using the same steps outlined in the section "Migrating a Computer Running Windows 2000 Professional," substituting HB-RES-WS1 in the Select Computers dialog box with HB-RES-MEM.

At the completion of the server migration and a restart, verify that the server is now part of the HAY-BUV domain.

Figure 11.71: The server HB-RES-MEM after the migration

Figure 11.71: The server HB-RES-MEM after the migration

As a result of the two preceding migrations, the ADMT tool performed the following actions:

  • Two new computer accounts were created in the target domain hay-buv.tld. The Distinguished Names are:

CN=HB-RES-MEM,OU=HB-RES,DC=HAY-BUV,DC=tld CN=HB-RES-WS1,OU=HB-RES,DC=HAY-BUV,DC=tld

  • Events were logged in the target domain. This list shows some of them:

Security log: event ID 624, User Account Created New Account Name Security log: event ID 646, Computer Account Changed Account Enabled Security log: event ID 646, Computer Account Changed Called User Name: Administrator
Security log: event ID 646, Computer Account Changed Called User Name: HAY-BUV-DC1

The computer accounts appear in the Users and Computers snap-in:

Bb727124.ckc11072(en-us,TechNet.10).gif

Figure 11.72

Migrating a Domain Controller and Decommissioning the Domain hb-res.hb-acc.hay-buv.tld

The last tasks the administrator of the hb-res.hb-acc.hay-buv.tld domain has to perform is to downgrade the two domain controllers of the domain hb-res.hb-acc.hay-buv.tld to Windows 2000 member servers. This is done by running Active Directory Installation Wizard from the command prompt of each of the domain controllers. For the last domain controller, the administrator has to select This server is the last domain controller in the domain.

Figure 11.73:

Figure 11.73

The administrator can then decide to move the servers to the HAY-BUV domain and keep them there as member servers by changing their domain membership or upgrade them to domain controllers of the new domain by running Active Directory Installation Wizard again and choosing to join an existing domain as additional domain controller.

Due to sIDHistory, the existing resources on these computers are still accessible by the users of the HAY-BUV domain. To not depend on sIDHistory, the administrator could choose to run the Security Translation Wizard to change the access control entries (ACEs) on this computer to contain the new SID of the migrated users.

Migrating a Global Group

The next step will be the migration of the hb-acc.hay-buv.tld domain global groups to HAY-BUV to prepare the consolidation of the hb-acc.hay-buv.tld into the HAY-BUV domain. hb-acc.hay-buv.tld\Accounting is the only global group to migrate. The only member of hb-acc.hay-buv.tld\Accounting is user MikeG. You have to move MikeG too because otherwise the closed set (Accounting,MikeG) would break. Then the access rights MikeG has through the membership in Accounting would not work anymore. ADMT analyzes this before migration and would copy Accounting if you decide to let MikeG in hb-acc.hay-buv.tld. After migration, MikeG is added to the new Accounting group automatically by ADMT. All previously migrated groups that refer to Accounting or MikeG will be updated, too.

Log on as HAY-BUV\Administrator to run the remaining ADMT tasks.

On a computer running Windows 2000 in the destination domain HAY-BUV, launch the ADMT. To start the Group Account Migration Wizard, select Active Directory Migration Tool in the left pane and select Group Migration Wizard from the Action menu, or right-click Active Directory Migration Tool in the left pane and select Group Migration Wizard.

During the execution of this wizard, the global group Accounting will be migrated from the hb-acc.hay-buv.tld domain to the HAY-BUV domain. It will be placed in the HB-ACCT organizational unit.

Figure 11.74:

Figure 11.74

Click Next.

Figure 11.75:

Figure 11.75

Select Migrate now?

Click Next.

Figure 11.76:

Figure 11.76

Enter HB-ACC (or hb-acc.hay-buv.tld) in the Source domain list.

Enter HAY-BUV (or hay-buv.tld) in the Target domain list.

Click Next.

In the group selection dialog box, click Add to open the object picker that allows for group selection.

Bb727124.ckc11077(en-us,TechNet.10).gif

Figure 11.77

Select the Accounting group and click Add.

Click OK. The Accounting group now appears in the Group Selection dialog box.

Figure 11.78:

Figure 11.78

Click Next.

The Select a target container dialog box opens. Click Browse and navigate to the AB-ACCT OU). Expand HAY-BUV, if necessary.

Figure 11.79:

Figure 11.79

Select HB-ACCT.

Click OK. The OU now shows up with its full LDAP name in the Organizational Unit Selection dialog box.

Figure 11.80:

Figure 11.80

Click Next. The Group Options dialog box opens.

Figure 11.81:

Figure 11.81

Select Copy group members. This tells the ADMT to also copy MikeG to HAY-BUV.

Click Next. The User Account dialog box opens and prompts for your credentials in the target domain:

Figure 11.82:

Figure 11.82

Enter HAY-BUV\Administrator credentials.

Click Next.

Figure 11.83:

Figure 11.83

In the Naming Conflicts dialog box, select Ignore conflicting accounts and don't migrate.

Click Next. This opens the summary dialog box, which allows you to review your selections.

Figure 11.84:

Figure 11.84

Click Finish.

Figure 11.85:

Figure 11.85

The Migration Progress dialog box is displayed and updated.

When the operation completes, the dialog box Status property indicates Completed.

View the log file if you wish, then click Close.

This completes the Group Account Migration Wizard. As a result of the migration, the following actions were performed:

  • A new group was created with a new primary SID:

CN=Accounting,OU=HB-ACCT,DC=HAY-BUV,DC=tld

  • The SID of the source group hb-acc.hay-buv.tld\Accounting was added to the sIDHistory attribute of the new group:

CN=Accounting, OU=HB-ACCT,DC=HAY-BUV,DC=tld

  • A new account was created with a new primary SID:

CN=MikeG,OU=HB-ACCT,DC=HAY-BUV,DC=tld

  • The SID of the source account hb-acc.hay-buv.tld\MikeG was added to the sIDHistory attribute of the new account:

CN=MikeG, OU=HB-ACCT,DC=HAY-BUV,DC=tld

  • The following events were logged in the target domain:

Security log: event ID 624, User Account Created Security log: event ID 642, User Account Changed Security log: event ID 631, Security Enabled Global Group Created Security log: event ID 632, Security Enabled Global Group Member Added

  • The following events were logged in the source domain:

Security log: event ID 633, Security Enabled Global Group Member Removed

The new group and account can be viewed in the Active Directory Users and Computers snap-in on HAY-BUV-DC1:

Bb727124.ckc11086(en-us,TechNet.10).gif

Figure 11.86: The migrated group Accounting and account MikeG in the HB-ACCT organizational unit

Tip If the organizational unit still appears to be empty, select the HB-ACCT OU and press F5 to refresh.

Because Copy group members was selected, ADMT migrated all members of the Global Group to the target domain and the group membership remains.

In this scenario, the Global Group Accounting was migrated from hb-acc.hay-buv.tld to hay-buv.tld first. Therefore, the ADMT automatically added the user MikeG to the Global Group hay-buv.tld \Accounting. Also, because the group Research (from hb-res.hb-acc.hay-buv.tld) was a domain local group, its membership list (which included hb-acc.hay-buv.tld\Accounting) was not broken (see figure 11.87) and hay-buv.tld \Research is listed in hay-buv.tld \Accounting's Member Of tab.

Figure 11.87: Group memberships of the migrated user MikeG

Figure 11.87: Group memberships of the migrated user MikeG

Identifying Services from hb-acc.hay-buv.tld not Running Under LSA

If you will remember from the earlier section "Identifying Services from hb-res.hb-acc.hay-buv.tld not Running Under LSA," you have a service account from the hb-res.hb-acc.hay-buv.tld domain (RES-Service) that is used for the ClipBook service and a service account from the hb-acc.hay-buv.tld domain (ACC-Service) for the Telnet Service on the member server HB-RES-MEM.

In that earlier section you identified, and later migrated, the RES-Service account, but you still can't successfully migrate ACC-Service due to the fact that the Service Account Migration Wizard retrieved it by its user principal name and therefore will not be recognized by the User Migration Wizard as a valid service account.

This step in the walkthrough will rerun the Service Account Migration Wizard with hb-acc.hay-buv.tld as the source domain, so that the service account, ACC-Service, is retrieved in the proper format and can be successfully migrated in the next section.

Note: This step does not migrate the accounts. It only identifies them for later migration.

From the target Windows 2000 domain controller, HAY-BUV-DC1, log on as HAY-BUV\administrator and launch the ADMT. To begin the Service Account Migration Wizard, select Active Directory Migration Tool in the left pane, right-click, and select Service Account Migration Wizard from the menu.

Figure 11.88:

Figure 11.88

Click Next.

Figure 11.89:

Figure 11.89

Select HB-ACC from the Source domain list.

Note: You are selecting the source domain of the service account even though the member server (HB-RES-MEM), which uses the service account to start a service, resides in hay-buv.tld.

Select HAY-BUV (or hay-buv.tld) from the Target domain list.

Click Next.

Figure 11.90:

Figure 11.90

Select Yes, update the information.

Click Next.

In the next window, click Add to choose the computers that are used as information resources.

Bb727124.ckc11091(en-us,TechNet.10).gif

Figure 11.91

Select hay-buv.tld from the Look in drop-down list at the top of the Select Computers dialog box.

Choose HB-RES-MEM.

Click Add.

Click OK. HB-RES-MEM is now added to the computer list in the Service Account Selection dialog.

Figure 11.92:

Figure 11.92

Click Next. The User Account dialog box opens and prompts for credentials in the target domain.

Figure 11.93:

Figure 11.93

Even though the dialog text asks you for source domain credentials, enter credentials for the HAY-BUV\Administrator because it had administrative rights on both domains.

Click Next.

Figure 11.94:

Figure 11.94

You can view the dispatch or agent logs as described in the earlier section "Identifying Services from hb-res.hb-acc.hay-buv.tld not Running Under LSA."

Click Close.

Figure 11.95:

Figure 11.95

Notice ACC-Service is no longer listed in its user principal name format.

Click Next.

Figure 11.96:

Figure 11.96

Click Finish.

Migrating a Service Account, User Account, and Roaming Profile

Now that the service account, ACC-Service, has been recognized and stored in network basic input/output system (NetBIOS) format (rather than user principal name format), you can migrate it, along with other users from the hb-acc.hay-buv.tld domain, to the target domain and have it treated as a valid service account.

The objective of this wizard is to migrate the remaining users from the Windows 2000 source domain, hb-acc.hay-buv.tld, to the target Windows 2000 domain, hay-buv.tld.

Prior to migrating users, in this intraforest case, you should have migrated any groups in which these users are members. This will ensure that access is maintained at all times and that global group memberships are not broken.

Note: There are generally two ways to migrate users and groups: Either migrate users and groups at the same time, or migrate groups first and users second. Although you can migrate groups and users together with both the Group and User Migration Wizards, you probably should use the Group Migration Wizard because, unlike the User Migration Wizard, it will recursively migrate group members and members of groups that are members. ADMT does not calculate a complete closed set, however, so you must be very careful when migrating users who are members of global groups. If you migrate a group that contains a user who is a member of another global group, and that global group is not recursively a member of any groups being migrated at this time, it will break the membership between that user and the global group that is not included. Other group types do not have this same issue because they can contain members outside of their domains.

This example will migrate two user accounts, the service account ACC-Service and the user EricW. You can migrate them without migrating groups prior or at the same time, because:

  • EricW is not a member of any groups in the source domain.

  • ACC-Service as a service account is only a member of the Domain Admins global group. Domain Admins is a special built-in group and therefore cannot be migrated by ADMT. The group membership of ACC-Service in the Domain Admins group will be broken regardless of whether you try to migrate the group or not. ADMT does not migrate, or fix group memberships for, built-in groups because it is not always desired that users be members of those same built-in groups and have the same rights as a result on the target domain.

To begin the User Account Migration Wizard, log on as administrator of the HAY-BUV domain, select Active Directory Migration Tool in the left pane, and select User Migration Wizard from the Action menu. The wizard retains some entries made from the group migration.

Figure 11.97:

Figure 11.97

Click Next.

Figure 11.98:

Figure 11.98

Select Migrate now?

Click Next.

Figure 11.99:

Figure 11.99

Click Next.

In the next window, click Add.

Bb727124.ckc11100(en-us,TechNet.10).gif

Figure 11.100

In the select users dialog box, select EricW and ACC-Service.

Click Add.

Click OK.

Figure 11.101:

Figure 11.101

Click Next. In the Organizational Unit Selection dialog box, make sure that the right target OU, HB-ACCT, appears. If that is not the case, either enter the LDAP name of the target OU, or use the browse dialog to navigate to the OU.

Figure 11.102:

Figure 11.102

Click Next.

Figure 11.103:

Figure 11.103

In the User Account dialog box, enter the target domain administrator's credentials.

Click Next.

Figure 11.104:

Figure 11.104

Select Translate roaming profiles because EricW has a roaming profile, and Update user rights.

Warning dialog box appears, telling you that you have not selected to migrate groups at the same time. Because this was a conscious decision as explained above, you can close the dialog box and click OK.

Bb727124.ckc11105(en-us,TechNet.10).gif

Figure 11.105

The Naming Conflicts dialog box opens.

Figure 11.106:

Figure 11.106

Select Ignore conflicting accounts and don't migrate.

Click Next.

Figure 11.107:

Figure 11.107

The Service Account Information dialog box opens. ADMT knows that one of the accounts you want to migrate is a service account, and asks for more information on how to migrate the service. Make sure that Migrate all service accounts is selected. This will update the Service Control Manager (SCM) on all machines that use this service account. Click Next.

Bb727124.ckc11108(en-us,TechNet.10).gif

Figure 11.108

Click OK.

Figure 11.109:

Figure 11.109

Click Finish.

The Migration Progress dialog box is displayed and updated.

Figure 11.110:

Figure 11.110

When the Status property reads Completed, click Close.

The users have been migrated to the OU HB-ACCT in the target domain. Use the Active Directory Users and Computers console to view the results.

Bb727124.ckc11111(en-us,TechNet.10).gif

Figure 11.111: The migrated accounts EricW and ACC-Service in the HB-ACCT OU

The ADMT migrated EricW's and MikeG's account properties: home directory, logon hours, and dial-in permissions. This is displayed in the following four screen captures.

Figure 11.112: EricW profile path

Figure 11.112: EricW profile path

Figure 11.113: EricW logon hours

Figure 11.113: EricW logon hours

Figure 11.114: EricW dial-in permissions

Figure 11.114: EricW dial-in permissions

Figure 11.115: MikeG home directory

Figure 11.115: MikeG home directory

In addition, the administrator should check that the sIDHistory attribute exists for EricW, MikeG, and ACC-Service.

Bb727124.ckc11116(en-us,TechNet.10).gif

Figure 11.116

As a result of the migration, the following actions were performed:

  • The user's old SID from the source domain was added to the sIDHistory attribute of the new users.

  • The following events were logged in the target domain for each user migrated:

Security log:  event ID 624, User Account Created 
Security log:  event ID 642, User Account Changed

Updating hb-acc.hay-buv.tld Service Account User Rights and Group Membership

You now have to make sure that the service account, ACC-Service, has the same rights and group memberships on the member server, HB-RES-MEM. Translate the security on HB-RES-MEM using the same steps outlined in the section "Updating hb-res.hb-acc.hay-buv.tld Service Account User Rights and Group Membership," substituting hb-acc.hay-buv.tld for the source domain in the Domain selection dialog box instead of hb-res.hb-acc.hay-buv.tld.

At this point you have updated local group security on the HB-RES-MEM server by adding the migrated service account to any local groups it may have been a member of, such as local administrators.

You can verify this on HB-RES-MEM with Settings/Users and Passwords/Advanced/Advanced User Management/Advanced/Groups. Then select the group on the right MMC screen and double-click to see the properties.

Figure 11.117:

Figure 11.117

Notice HB-ACC\ACC-Service has been replaced with HAY-BUV\ACC-Service. This will happen on a computer running Windows 2000 in a native mode domain even without running the Security Translation Wizard, but running the wizard not only changed the visible name but also the actual SID in this group's DACL.

Migrating Local Profiles on Computers Running Windows 2000 Professional

After migrating the users, access to the local profiles on HB-RES-WS1 is to be configured. The user MikeG has a local profile on this workstation. EricW's profile does not need to be migrated because this user has a roaming profile.

Intraforest migration of computers running Windows 2000 Professional does not require modifications to a local profile. Windows NT 4.0 clients' local profiles would need to be migrated with ADMT. Windows 2000 automatically executes the required changes at first logon. The following steps lead to the correct profile structure:

  • User HAYBUV\MikeG logs on at the workstation HB-RES-WS1. The client notices there is no profile for HAYBUV\MikeG SID in the registry key HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows NT\CurrentVersion\ProfileList, so it fetches the globally unique identifier (GUID) of MikeG.

  • There is an entry for this GUID in ProfileGuid that points to the SID of HB_ACC\ MikeG. The client fixes up the Profilelist key so that the entry is now under the SID of HAYBUV\ MikeG. The key HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows NT\CurrentVersion\ProfileGuid is updated also.

After migration, the User Profile window shows profiles for:

  • HAY-BUV\EricW

  • HAY-BUV\MikeG

EricW has a roaming profile that was already migrated.

Migrating a Domain Controller and Decommissioning the Domain hb-acc.hay-buv.tld

The last task the administrator of the hb-acc.hay-buv.tld domain has to perform is to downgrade the last domain controller of the domain to a Windows 2000 member server. This is done by running Active Directory Installation Wizard from the command prompt of the domain controller. During this procedure the administrator has to select that this computer is the last domain controller of the domain.

The administrator can then decide to move the server to the hay-buv.tld domain and keep it there as a member server by just changing its domain membership or to upgrade it to a domain controller of the new domain by running Active Directory Installation Wizard again and choosing to join an existing domain as an additional domain controller.

Because of sIDHistory, the existing resources on this computer are still accessible by the users of the hay-buv.tld domain. To not depend on sIDHistory, the administrator could choose to run the Security Translation Wizard to change the ACEs on this computer to contain the new SID of the migrated users.

Performing Migration Tests

Finally, perform the following tests to verify the correct user environment for the new domain.

To check access to available resources, perform the following tests using HB-RES-WS1.

Test

Expected result

HAY-BUV\MikeG can log on to workstation HB-RES-WS1

Success

Local profile for user MikeG on workstation HB-RES-WS1 is migrated

Success

MikeG access to https://HB-RES-DC2

Success

MikeG access to https://HB-RES-MEM

Success

MikeG access to \\HB-RES-DC1\Research

Success

MikeG access to \\HB-RES-DC1\MikeG

Success

MikeG access to \\HB-RES-DC2\ExecDocuments

Success

MikeG access to \\HB-RES-MEM\Specifications

Success

MikeG access to \\HB-RES-MEM\ReasearchDocs

Success

MikeG install of an additional Office2000 component from \\HB-RES-MEM\Office2000Inst

Success

MikeG access to \\HB-ACC-DC1\Profiles

Success

MikeG access to \\HB-ACC-DC1\Profiles\EricW

Failure

HAY-BUV\EricW can log on to workstation HB-RES-WS1

Success

Roaming profile for user EricW is migrated

Success

EricW access to https://HB-RES-DC2

Failure

EricW access to https://HB-RES-MEM

Failure

EricW access to \\HB-RES-DC1\Research

Failure

EricW access to \\HB-RES-DC1\MikeG

Failure

EricW access to \\HB-RES-DC2\ExecDocuments

Failure

EricW access to \\HB-RES-MEM\Specifications

Failure

EricW access to \\HB-RES-MEM\ReasearchDocs

Failure

EricW install of an additional Office2000 component from \\HB-RES-MEM\Office2000Inst

Success

EricW access to \\HB-ACC-DC1\Profiles

Success

EricW access to \\HB-ACC-DC1\Profiles\EricW

Success

ClipBook Service on HB-RES-MEM under migrated account RES-Service runs

Success

Telnet Service on HB-RES-MEM under migrated account ACC-Service runs

Success

Summary

Now you have consolidated three domains into one single domain. All relevant group and user accounts have been migrated to the domain HAY-BUV. SIDHistory provides the necessary access rights on the various shares, files, and Web sites without having to "re-ACL" these items, that is, define new ACEs after migration. The next graph shows the new configuration.

Figure 11.118: : Domain model after migration

Figure 11.118: Domain model after migration

For More Information

For the latest information on Windows NT Server, see https://www.microsoft.com/ntserver.

For the latest information on Windows 2000, see https://www.microsoft.com/windows/server/.

Before You Call for Support

Please keep in mind that Microsoft does not support these walkthroughs. The purpose of the walkthrough is to facilitate your initial evaluation of the Microsoft Windows 2000 features. For this reason, Microsoft cannot respond to questions you might have regarding specific steps and instructions.

Reporting Problems

Problems with Microsoft Windows 2000 should be reported via the appropriate bug-reporting channel and alias. Please make sure to adequately describe the problem so that the testers and developers can reproduce it and fix it. Refer to the Release Notes included on the Windows 2000 distribution media for some of the known issues.