Chapter 9: Migration of a Windows NT 4.0 Account Domain to Active Directory

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

Introduction

Overview

This technical walkthrough guides you through the steps necessary to migrate one or more Microsoft Windows NT 4.0 account domains into a single Microsoft Windows 2000 domain using the Microsoft Active Directory Migration Tool (ADMT).

This approach allows a company to incrementally migrate groups and users in a Windows NT 4.0 account domain to a Windows 2000 domain without impacting its Windows NT 4.0 production environment.

The document covers the following topics:

1. Test environment details.

2. Scenario steps to migrate a Windows NT 4.0 account domain to a Windows 2000 domain.

Why Migrate a Windows NT 4.0 Account Domain to a Windows 2000 Domain?

Migrating Windows NT 4.0 account domains to a parallel Windows 2000 domain allows administrators of Windows NT to:

1. Consolidate multiple Windows NT 4.0 account domains into a single Windows 2000 domain.

2. Reflect desired Windows 2000 domain structure rather than inheriting the existing Windows NT 4.0 structure.

3. Create minimal impact and risk to existing Windows NT 4.0 production environment.

4. Allow fallback to Windows NT 4.0 account domains without consequence.

5. Migrate a subset of users to a Windows 2000 forest as a "pilot."

6. Move users in small sets, for example, 100 users at a time.

7. Transition a Windows 2000 forest to production.

Chapter 9, "Migration of a Windows NT 4.0 Account Domain to Active Directory" (referred to below as the "Account Domain" walkthrough) and chapter 10, "Consolidation of Windows NT 4.0 Resource Domains" (referred to below as the "Resource Domain" walkthrough) are separate and distinct operations. However, the chapters have been written to be completed in sequence, with the "Account Domain" walkthrough first and the "Resource Domain" walkthrough second.

Migration Environment

Before migrating the production environment, Hay Buv Toys wanted to test the sequence of the necessary steps in a test environment. Hay Buv created an independent network in the test lab and installed machines that have the same names, resources, and access control rights. For that purpose, a sample test environment has been defined to provide a better understanding of the process involved. Multiple shares and resources are set up in the HB-RESWC domain with varying levels of access. Two users with accounts in the HB-ACCT account domain access these shares and resources. The following diagram shows the example environment. Because the concepts remain the same, it is possible to extend the procedures to larger environments with more master account domains.

Figure 9.1: Domain structure before migration

The incremental migration process of a Windows NT 4.0 account domain to a single Windows 2000 domain involves the creation of a parallel Windows 2000 domain/forest, hay-buv.tld. Note that two additional trust relationships have been established to support this migration. One trust is from the HB-RESWC resource domain to the hay-buv.tld domain to allow migrated users to access the resources in HB-RESWC as they originally did. The second is a two-way trust between the HB-ACCT domain and the hay-buv.tld domain. It provides the security context necessary to execute the ADMT. Building the Windows 2000 domain and Active Directory hierarchy should be carefully planned prior to installation. See The Windows 2000 Deployment Guide available at www.microsoft.com/windows2000 for additional resources.

The computer roles are as follows:

Computer name	Domain	Role
HAY-BUV-DC1	HAY-BUV	Domain controller
HB-ACCT-PDC	HB-ACCT	Primary domain controller (PDC) File server
HB-RESWC-PDC	HB-RESWC	PDC File server
HB-RESWC-BDC	HB-RESWC	Backup domain controller (BDC) File server Internet Information Services (IIS) server
HB-RESWC-MEM	HB-RESWC	Member server File server IIS server
HB-RESWC-WS1	HB-RESWC	User workstation Office 2000 installed (Word only)

Figure 9.2: Server manager in resource domain HB-RESWC

The IIS servers HB-RESWC-BDC and HB-RESWC-MEM use the sample Web site Volcano Caf that is installed during the Windows NT 4.0 setup as a startup page. The path to the Web site is <drive>:\InetPub\wwwroot\samples\sampsite\default.htm. The Web administrator enables NTLM as authentication mechanism and disables anonymous access.

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

The following accounts were created:

Domain/computer	Name	Account type	Group members
HB-ACCT	RainierS	User	N/A
HB-ACCT	JoeD	User	N/A
HB-ACCT	Executives	Global Group	HB-ACCT\RainierS
HB-RESWC	Sales	Local Group	HB-ACCT\Executives
HB-RESWC-MEM	Marketing	Local Group	HB-ACCT\Executives

Additional properties have been assigned to the user JoeD through User Manager for Domains. These properties are:

1. Home Directory: mapped to X:\ is share \\HB-RESWC-PDC\JoeD

2. Logon Hours: Allowed any day except Saturday and Sunday

3. Dial-in permission: granted

An additional property has been assigned to user RainierS using the User Manager for Domains.

1. Profiles Path: \\HB-ACCT-PDC\Profiles\RainierS

Only RainierS has access to the directory \\HB-ACCT-PDC\Profiles\RainierS. Ensure that the appropriated file permissions are set to the directory, files, and all subdirectories.

These attributes will be verified after JoeD is migrated. In addition, for user RainierS, the roaming profile attribute will be verified after this account is migrated.

Figure 9.3: User manager in the account domain HB-ACCT

Figure 9.4: User manager in the resource domain HB-RESWC, with the shared local group HB-RESWC\Sales

Figure 9.5: User manager on the member server \\HB-RESWC-MEM with the local group HBRESWC-MEM\Marketing

In order to fully test the migration, the following access restrictions were created:

Resource	Access rights
\\HB-RESWC-PDC\Finance	HB-RESWC\Sales: FC
\\HB-RESWC-PDC\JoeD	HB-ACCT\JoeD: FC
\\HB-RESWC-BDC\ExecDocuments	HB-RESWC\Sales: FC
\\HB-RESWC-MEM\Specifications	HB-RESWC-MEM\Marketing: FC
\\HB-RESWC-MEM\Office2000Inst	Everyone: R
https://HB-RESWC-BDC/default.htm	HB-RESWC\Sales: FC
https://HB-RESWC-MEM/default.htm	HB-RESWC-MEM\Marketing: FC

FC = full control, R = read only

Before the migration is started, log on as RainerS on HB-RESWC-WS1. Change the desktop color scheme to brick. Also, create a new text document and place it in the Recycle Bin. Note the filename for later recall.

Test	Expected result
HB-ACCT\RainierS access to https://HB-RESWC-BDC/default.htm	Success
HB-ACCT\RainierS access to https://HB-RESWC-MEM/default.htm	Success
HB-ACCT\RainierS access to \\HB-RESWC-PDC\Finance	Success
HB-ACCT\RainierS access to \\HB-RESWC-BDC \ExecDocuments	Success
HB-ACCT\RainierS access to \\HB-RESWC-MEM\Specifications	Success
HB-ACCT\RainierS can install an additional Office2000 component	Success
HB-ACCT\RainierS access to \\HB-RESWC-PDC\JoeD	Failure

Now, log on as JoeD on HB-RESWC-WS1. Change the desktop color scheme to maple. Create a folder on JoeD's desktop and place it in the Recycle Bin. Note the name of the folder.

Perform the following tasks:

Test	Expected result
HB-ACCT\JoeD access to https://HB-RESWC-BDC/default.htm	Failure
HB-ACCT\JoeD access to https://HB-RESWC-MEM/default.htm	Failure
HB-ACCT\JoeD access to \\HB-RESWC-PDC\Finance	Success
HB-ACCT\JoeD access to \\HB-RESWC-BDC\ExecDocuments	Failure
HB-ACCT\JoeD access to \\HB-RESWC-MEM\Specifications	Failure
HB-ACCT\ JoeD can install an additional Office2000 component	Success
HB-ACCT\JoeD access to \\HB-RESWC-PDC\JoeD	Success

The migration steps involve migrating the Windows NT 4.0 HB-ACCT account domain, including all global groups and users, into the Windows 2000 domain, hay-buv.tld. When group and user migration is complete, the Windows NT 4.0 HB-ACCT account domain can be reassigned, decommissioned, or migrated into the hay-buv.tld domain. The migration of computers into the resource domain is covered in the "Resource Domain" walkthrough. The desired end state is reflected in Figure 9.6.

Figure 9.6: The final state. All accounts were migrated to the Windows 2000 domain, and the Windows NT 4.0 account domain was decommissioned.

Because accounts will be migrated, a user logging on to the hay-buv.tld domain from Windows NT 4.0 workstation HB-RESWC-WS1 can continue to access resources on HB-RESWC-MEM, HB-RESWC-BDC, and HB-RESWC-PDC. These resources were originally assigned permissions to the user's account in the HB-ACCT domain.

For more information on ADMT and the migration process, see the white paper "Planning Migration from Microsoft Windows NT to Microsoft Windows 2000" at https://www.microsoft.com/windows2000.

Terminology

You should be familiar with the following terms and their meanings:

Source domainthe Windows NT 4.0 domain containing the original security principal that will be migrated.

Source objectthe security principal object that will 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 NT 4.0 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
Power users	No	Yes

Requirements

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

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

2. Source domain is Windows NT 4.0 or Windows 2000. PDC of a Windows NT 4.0 source domain has Service Pack 4 or higher installed.

3. Source domain must be in a different forest than the target domain.

   Source object must be one of the following types:

   1. User

      Security-enabled group, including:

      1. Local group (for Windows NT 4.0, only a domain controller's shared local groups may be migrated)

      2. Domain local group (Windows 2000 native mode domain only)

      3. Global Group

   2. Computer (covered in the "Resource Domain" walkthrough)

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

5. ADMT console must be executed on a computer running Windows 2000.

Although not a requirement, it is highly recommended that you synchronize the time among all computers participating in this test. This will assist in troubleshooting when using the event log.

The following requirement is specific to the migration of groups and users: 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/computer; thus, adding them to a sIDHistory would violate the requirement that the SID of a Windows 2000 forest be unique.

Security Requirements

To use the Active Directory Migration Tool to clone groups and users, the user account must have the following permissions:

1. Administrator rights in the source domain.

2. Domain Admin rights in the target domain for the use of sIDHistory, or administrator rights.

3. Administrator rights on each computer you migrate.

4. Administrator rights on each computer on which you translate security.

5. Administrator rights on any computer where the ADMT must install an agent to perform the migration. These agents allow the ADMT resolve the security-related issues and to gather information for impact analysis.

6. Auditing for account management (success and failure events) must be enabled in the source and target domains. In Windows NT, account management is referred to as user and group management.

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

The following modifications have to be made on the source domain:

1. A trust between the source and target domains is required (source trusts target) to provide the security context necessary for the ADMT. To support resource access for migrated users, trusts from existing resource domains to the target account domain are also required.

2. A new local group <sourcedomainname>$$$ (for example, HB-RESWC$$$) is to be created on the source domain for ADMT internal auditing purposes. There must be no members in this group.

3. Source domain PDC must have the following registry entry:

HKEY_LOCAL_MACHINE | System | CurrentControlSet | Control | Lsa TcpipClientSupport:REG_DWORD:0X1

4. If not already set, the ADMT sets this value and asks for a restart on the PDC. Setting this value enables remote procedure calls (RPCs) over the TCP transport. This is required because, by default, Security Accounts Manager (SAM) RPC interfaces are capable of being called remotely only on the named pipes transport. Using named pipes results in a credential management system that is suitable for interactively logged-on users making networked calls, but is not flexible for a system process making network calls with user-supplied credentials. RPC over TCP is more suitable for that purpose. Setting this value does not diminish the security of the system in any way.

Figure 9.7: Registry changes to source domain controller

Walkthrough

In this walkthrough, you will learn how to prepare the Windows 2000 target domain for migration, migrate the Windows NT 4.0 global groups and user accounts, test the migrated users, execute a fallback plan if necessary, and decommission the Windows NT 4.0 account domain.

The walkthrough consists of the following scenario steps:

1. Preparing the Windows 2000 target domain.

2. Establishing the trusts required between account, resource, and Windows 2000 domain.

3. Migrating all global groups from the source to the target domain.

4. Identifying and migrating sets of users.

5. Decommissioning the Windows NT 4.0 source domain.

The following flowchart shows the steps to perform the account domain migration as well as the resource domain migration described in the "Resource Domain" walkthrough.

Figure 9.8

Scenario Steps

Preparing the Windows 2000 Target Domain

A new parallel Windows 2000 domain/forest is created in order to migrate Windows NT 4.0 account domains to the new environment. For instructions on how to set up a Windows 2000 domain/forest, consult the product documentation.

The product CD contains support tools such as Active Directory Service Interfaces (ADSI) Edit or the Active Directory Administration Tool. You should install these from the Support\Tools directory on the CD. You will use them for testing and verification later in this walkthrough.

Enable Auditing

To enable the auditing policy for account management in the Windows 2000 domain, edit the group policy object on the Domain Controllers organizational unit (OU) by following these steps:

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 organizational unit 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 the Default Domain Controllers Policy and click Edit. The group policy snap-in will launch.

6. Under 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 the automatic update.

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

   

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

In the Windows NT 4.0 domain, User and Group Management auditing must also be enabled.

1. In the User Manager for Domains, select Policies and then select Audit.

2. Verify that Audit These Events is selected and that Success and Failure are both selected. Click OK.

   

   Figure 9.10: User and Group Management auditing in the source domain HB-ACCT

Change Windows 2000 Domain to Native Mode

The new Windows 2000 domain 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.

5. Click Yes.

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

Establishing the Trusts Required Between Account, Resource, and Windows 2000 Domain

The new parallel Windows 2000 domain must have trusts established to support the access rights of the accounts during migration. There is also an additional trust established from the account domain to the Windows 2000 target domain to enable access for ADMT.

1. Open the Active Directory Domains and Trusts MMC snap-in.

2. Highlight the domain (such as, hay-buv.tld).

3. Right-click on the domain object and select Properties.

4. Select the Trusts tab.

   

   Figure 9.12: Windows 2000 trust relationship properties

5. Add the Windows NT 4.0 resource domain under Domains that trust this domain. Type HB-RESWC (resource domain) and a password. Record the password for future use. Add the Windows NT 4.0 account domain under Domains that trust this domain. Type HB-ACCT (account domain) and the same password as above.

6. Click OK.

7. Open the Windows NT 4.0 User Manager for Domains on the resource domain PDC for HB-RESWC.

8. Select Policies | Trust Relationships.

9. Add the Windows 2000 network basic input/output system (NetBIOS) domain name HAY-BUV under the Trusted Domains section.

10. Provide the password from step 5.

11. Click OK. You then should receive a status message indicating success.

12. Open the Windows NT 4.0 User Manager for Domains on the account domain PDC for HB-ACCT.

13. Select Policies | Trust Relationships.

14. Add the Windows 2000 NetBIOS domain name HAY-BUV under the Trusted Domains section.

15. Provide the password from step 5.

16. Click OK. You then should receive a status message indicating success.

Migrating All Global Groups from the Source to the Target Domain

Installation of the ADMT

The ADMT installation utilizes the Windows Installer technology. The installation rules, directory locations, and constraints are imbedded in an installation script (.msi file) that is launched to install the ADMT. The ADMT is available at www.microsoft.com.

Migrating Global Groups

Global groups can have users only from their own domain as members. If user accounts are migrated from one domain to another, the new accounts created by the ADMT in the target domain cannot be members of the global groups in the source domain.

In order to preserve global group memberships of users, the global groups must be migrated first. This creates a corresponding global group in the target domain for all global groups that exist in the source domain. The newly created global group in the target domain receives a new primary SID that contains the domain identifier of the target domain as part of the SID. The primary SID of the global group in the source domain is added to the sIDHistory attribute of the newly created group.

The migration of a global group involves the following steps:

1. ADMT reads the global group objects in the source domain.

2. A new global group object is created in the target domain. A new primary SID is created for the object in the new domain.

3. The SID of the global group in the source domain is added to the sIDHistory attribute of the new global group in the target domain.

4. Events are logged in the source and the target domain.

In this walkthrough, the user HB-ACCT\RainierS is member of the global group HB-ACCT\Executives. To preserve the group membership, the global groups of the HB-ACCT domain are first migrated to the new domain HAY-BUV.tld.

It is appropriate to create a new container for users and groups that are migrated. Therefore, the organizational unit HB-ACCT is created in the hay-buv.tld domain. The OU HB-RESWC is created, too, to prepare the resource domain migration covered in the "Resource Domain" walkthrough.

To create the organizational units HB-ACCT and HB-RESWC:

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

2. Right-click the domain hay-buv.tld.

3. In the drop-down box, select New and then select Organizational Unit.

4. In the New Object Organizational Unit dialog box, enter the name of the new OU, HB-ACCT.

5. Right-click the domain hay-buv.tld.

6. In the drop-down box, select New and then select Organizational Unit.

7. In the New Object Organizational Unit dialog box, enter the name of the new OU, HB-RESWC.

Figure 9.13: The organizational unit HB-ACCT and HB-RESWC in the hay-buv.tld domain

ADMT Group Migration Wizard

Use the HAY-BUV\Administrator account on HAY-BUV-DC1 to run the ADMT tool.

1. Launch ADMT by clicking Start, selecting Programs, selecting Administrator Tools, and then selecting Active Directory Migration Tool.

2. To begin the Group Migration Wizard, select Active Directory Migration Tool in the left pane and right-click to open the pop-up menu.

3. In the menu, select Group Migration Wizard.

This wizard migrates the global group Executives from the HB-ACCT domain to the hay-buv domain. It will be placed in the HB-ACCT organizational unit.

Figure 9.14

Click Next.

Figure 9.15

You can either run a trial migration, which simulates the migration without creating the objects in the target domain to test whether all requirements are met, or perform the migration immediately. In this case, you want to migrate immediately.

Select Migrate Now? and click Next.

The wizard now opens the Domain Selection dialog box.

Figure 9.16

Enter HB-ACCT for the source domain.

Enter hay-buv for the target domain.

Click Next.

The Group Selection dialog box opens. This allows you to select the groups that should be migrated. The dialog box is initially empty.

Figure 9.17

To select groups, click Add. This opens the object picker.

Figure 9.18

Select the Executives group and click Add.

Click OK.

Figure 9.19

Now the Executives group appears in the selection list.

Click Next.

The Organizational Unit Selection dialog box opens. This dialog box allows you to select the OU in the target domain.

Figure 9.20

You can either enter the name of the organizational unit or browse for it.

Select the Browse button.

Figure 9.21

Expand HAY-BUV, if necessary.

Select HB-ACCT.

Click OK.

Figure 9.22

Click Next.

Figure 9.23

The Group Options dialog box allows you to set specific options on the migrated object, such as whether you want to migrate domain rights, migrate group members with the group, migrate the group's SID, and how to handle group names. In order to make group names unique, the administrator could specify a prefix or a suffix that is added to the group name.

Note: A large migration may take place over an extended period of time. This may necessitate the periodic recloning of global groups from the source to the target domain to reflect changes made in the source domain. Options in the dialog boxes in figure 9.23 and 9.25 would be chosen for this case. For instance, to update global group membership, you would choose (figure 9.23) to Copy group members but not to Update previously migrated objects. This would prevent previously migrated user accounts from being overwritten. In the naming conflicts dialog box (figure 9.25), you would choose to Replace conflicting accounts to ensure that the group is appended to, but not selectRemove existing user rights or Remove existing members of groups being replaced. Of course, there are numerous options available and you are encouraged to thoroughly test your particular situation prior to committing changes.

Select only Migrate group SIDs to target domain and Do not rename accounts, and then click Next.

If migrating the SID was specified, the administrator has to enter source domain credentials in the User Account dialog box.

Figure 9.24

Enter administrator as the user name.

Enter the password of the administrator in the HB-ACCT domain.

Enter HB-ACCT as the domain.

Click Next.

The Naming Conflicts dialog box opens. In this dialog box, the administrator can specify rules for naming collisions. If, for example, the Executives group already exists in the target domain, the administrator could choose to ignore the conflict and not migrate, replace, or append to the existing group, or add a prefix or suffix to the source group name to create a new group in the target.

Figure 9.25

Select Ignore conflicting accounts and don't migrate.

Click Next. The summary dialog box appears.

Figure 9.26

Click Finish.

When the operation finishes, the Status property in the dialog box indicates Completed.

Figure 9.27

Click Close.

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

Figure 9.28: The migrated group Executives in the HB-ACCT organizational unit

Tip If the organizational unit still appears to be empty, right-click the HB-ACCT OU and select Refresh.

Verify Migrated SID

The lpd (ldp.exe) tool, which you can find in the \support folder on your Windows 2000 server CD, is a Lightweight Directory Access Protocol (LDAP) testing tool. It can show all properties of an object. Note that the primary SID and the sIDHistory for this object are different. The primary SID contains the identifier of the new domain, while the SID in the sIDHistory has the SID of HB-ACCT\Executives as the only attribute.

To view the object in the LDAP utility:

1. Locate the Active Directory Administration Tool at Start\Programs\Windows 2000 Support Tools\Tools and then open it.

2. From the Connection menu, select Connect.

3. Click OK.

4. From the Connection menu, select Bind.

5. Click OK.

6. From the View menu, select Tree.

7. Click OK.

8. Now the domain tree appears in the left pane.

9. You can navigate to the object by double-clicking the domain first, then the OU HB-ACCT, and then the group Executives. Every time you double-click an entry, you will see detailed information about this object in the right pane.

Figure 9.29

In figure 9.29, the LDAP client tool Ldp.exe shows objects in the Active Directory. The Executives group was added to the HB-ACCT organizational unit. The group has a new primary SID (=objectSID). The primary SID from the Windows NT 4.0 source domain is now part of the sIDHistory (=sIDHistory).

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

1. A new group was created with a new primary SID called CN=Executives,OU=HB-ACCT,DC=HAY-BUV,DC=tld.

2. The SID of the source group HB-ACCT\Executives was added to the sIDHistory attribute of the new group CN=Executives,OU=HB-ACCT,DC=HAY-BUV,DC=tld.

3. The following events were logged in the target domain:

Security log: event ID 631, Security Enabled Global Group Created Security log: event ID 641, Security Enabled Global Group Changed Security log: event ID 641, Security Enabled Global Group Changed Security log: event ID 669, Add SID History

4. The following events were logged in the source domain:

Security log: event ID 636, Local Group Member Added Security log: event ID 637, Local Group Member Removed

Identifying and Migrating Sets of Users

The next step in the migration process is to migrate all users from the Windows NT 4.0 environment to the new Windows 2000 Active Directory domain. This can be done gradually: The administrator can start with a handful of users as a pilot to test whether the new environment and all resource access work sufficiently, and then migrate more and more users in multiple steps.

The migration of a user involves the following steps:

1. ADMT reads the source user objects including all attributes.

2. A new user object is created in the target domain. A new primary SID is created for the object in the new domain. All attributes from the source object are copied to the new user.

3. The user's old SID from the source domain is added to the sIDHistory attribute of the new user.

4. Events are logged in the source and the target domain.

ADMT User Account Migration Wizard

The objective of this wizard is to migrate users from the Windows NT 4.0 source accounts domain, HB-ACCT, to the target Windows 2000 domain, hay-buv.tld.

To begin the User Account Migration Wizard, select Active Directory Migration Tool in the left pane and select User Account Migration Wizard from the Action menu.

Figure 9.30

Click Next.

Figure 9.31

Select Migrate now?.

Click Next.

Figure 9.32

This time, the domain names should already be filled in. Click Next.

In the Select Users dialog box, click Add. When the object picker appears, add JoeD and RainierS.

Figure 9.33

Click OK.

Figure 9.34

Click Next.

In the Organizational Unit Selection dialog box, the name of the target OU should already be filled in. If not, use the Browse button to select the OU.

Figure 9.35

Click Next.

The Password Options dialog box opens. ADMT does not migrate the users' passwords. Therefore, the migration tool has to generate new passwords. The administrator has the option to either set the password to the user's name or generate a complex password. In either case, the password is added to a log file whose path and name you can specify. Since this password log file could create a security hole, the "User must change password at next logon" attribute is set for all migrated user accounts in the target domain.

Figure 9.36

Select Complex passwords.

Enter a filename in the Location to store password file text box.

The ADMT User Account Migration Wizard offers two password options for the migrated user account:

1. The password is set to the account name.

2. The password is set to a random password, and a comma-separated value file (.csv) is created. Treat this file with high security because it contains the account names and user passwords. A sample of this password file follows:

JoeD,aab2vrnd RainierS,rssyn6kw

Tip It can be quite efficient to create a script to send in e-mail to users to notify them of their new password.

Note: If the file already exists, then the new information is appended to it.

Click Next.

In the Account Transition Options dialog box, the administrator can determine whether both or only one account should be activated. This is a very important security consideration, but also important for user management. Once the user is migrated, changes are not synchronized between the domains. If you activate the target account, you can force the user to use that new account by expiring the source account.

Figure 9.37

Select Leave both accounts open and Migrate user SIDs to target domain.

Make certain that you select Migrate user SIDs to target domain. This option is easy to miss and must be selected to enable the user's sIDHistory to be migrated to the new user object in the target domain.

Click Next.

Figure 9.38

Enter the source domain's administrator credentials.

Click Next.

Figure 9.39

The User Options dialog box allows for some degree of control over the user migration process. Besides name collisions, roaming profiles can be translated and a user's groups can be migrated at the same time. If the Migrate associated user groups option is selected, it will migrate the user's group but not members of those groups.

Select Translate roaming profiles and Update user rights.

Clear Migrate associated user groups, if selected.

Click Next. The Naming Conflicts dialog box opens.

Figure 9.40

Select Ignore conflicting accounts and don't migrate.

Click Next.

Figure 9.41

Click Finish.

The Migration Progress dialog box is displayed and updated.

Figure 9.42

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.

Figure 9.43: The migrated accounts RainierS and JoeD in the HB-ACCT OU

Tip To assist in troubleshooting the ADMT, examine the migration log file, migration.log, found in %ProgramFiles%\Active Directory Migration Tool\Logs.

As part of the migration process, the ADMT checks global groups to which the user account in the source domain belongs. The ADMT then checks its migrated objects table to see if any of those global groups have previously been migrated. If a match is found, the group was previously migrated from the source domain. The user is then added to this corresponding group.

In this scenario, the global group Executives was migrated from HB-ACCT to hay-buv.tld first. Therefore, the ADMT automatically added the user RainierS to the global group HAY-BUV\Executives.

Figure 9.44: Group memberships of the migrated user RainierS

The ADMT migrated the account properties of JoeD and RainierS: home directory, logon hours, and dial-in permissions.

Figure 9.45: JoeD - home directory

Figure 9.46: JoeD - logon hours

Figure 9.47: JoeD - dial-in permissions

Figure 9.48: RainierS - profile path

In addition, the administrator can view the sIDHistory attribute for JoeD and RainierS:

Figure 9.49: Active Directory Administration Tool showing sIDHistory entry

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

The following events are 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 (Caller logon ID modified) 
Security log:  event ID 669, Add SID History 
Security log:  event ID 642, User Account Changed (Account Enabled) 
Security log:  event ID 632, Security Enabled. Global Member added

The following events are logged in the source domain for each user migrated:

Security log:  event ID 636, Local Group Member Added 
Security log:  event ID 637, Local Group Member Removed

Fallback Plan

It is important to have a fallback plan in case the migrated accounts in the Windows 2000 domain do not meet the user acceptance criteria. The Windows NT 4.0 account domain account remains intact and enabled after the migrating process and allows for a simple return to the existing environment.

To reinstate the Windows NT 4.0 account domain, follow these steps:

1. Log the user off of the target Windows 2000 domain.

2. Enable account on original Windows NT 4.0 account domain, if accounts were disabled during migration.

3. Log the user into source/original Windows NT 4.0 account domain.

4. Verify that access to resources is maintained.

5. Verify that profile path and login script are maintained.

6. Replicate in the source domain any changes made to the target domain global groups and domain local groups.

Decommissioning the Windows NT 4.0 Source Domain

This is the final step in migrating from the Windows NT 4.0 account domain. However, if you plan to complete the "Resource Domain" walkthrough, then you should delay this step to ensure that the account domain is available for some steps in the resource domain migration that depend on an account domain controller, such as service account migration, migration of shared local groups, and local workstation profile migration.

When all users and groups have moved permanently to the target domain, the final task will be to decommission the source domain.

Note: The roaming profile of HB-ACCT\JoeD and HAY-BUV\JoeD is still being hosted on \\HB-ACCT-PDC. If the HB-ACCT domain is to be decommissioned, be sure to move the profile directory and update the profile setting for the HAY-BUV\JoeD account.

Note: If the HB-ACCT domain is decommissioned, shared local groups and local groups in the resource domain will display group members as "account unknown" because member names from HB-ACCT will not be resolved. However, membership still exists and users are not impacted. It is important that administrators do not clean up by deleting the "account unknown" entries because this will break the access facilitated by using sIDHistory. When you run the Security Translation Wizard at a later point and select Remove, the Active Directory Migration Tool will clean up these entries.

If these domain controllers are to be reassigned to the Windows 2000 domain, they can be upgraded to Windows 2000 and promoted to domain controllers or left as member servers.

Migration Tests

Log on to the Windows NT 4.0 workstation using the new user accounts, HAY-BUV\RainierS and HAY-BUV\JoeD, and verify access to the resources. Since these are new user accounts, a new profile will be created for JoeD on the workstation. RainierS will still access the roaming profile. It is recommended that user accounts in the source domain (HB-ACCT) be disabled once they are migrated to the target domain.

Test	Expected result
HAY-BUV\RainierS can log on to workstation HB-RESWC-WS1	Success
HAY-BUV\RainierS maintains the roaming profile	Success
Recycle Bin does not contain the document placed there by HB-ACCT\RainierS	Success
HAY-BUV\RainierS access to https://HB-RESWC-BDC/default.htm	Success
HAY-BUV\RainierS access to https://HB-RESWC-MEM/default.htm	Success
HAY-BUV\RainierS access to \\HB-RESWC-PDC\Finance	Success
HAY-BUV\RainierS access to \\HB-RESWC-BDC\ExecDocuments	Success
HAY-BUV\RainierS access to \\HB-RESWC-MEM\Specifications	Success
HAY-BUV\RainierS can install an additional Office 2000 component	Success
HAY-BUV\RainierS access to \\HB-RESWC-PDC\JoeD	Failure
HAY-BUV\JoeD can log on to workstation HB-RESWC-WS1	Success
HAY-BUV\JoeD gets a new local profile	Success
HAY-BUV\JoeD access to https://HB-RESWC-BDC/default.htm	Failure
HAY-BUV\JoeD access to https://HB-RESWC-MEM/default.htm	Failure
HAY-BUV\JoeD access to \\HB-RESWC-PDC\Finance	Failure
HAY-BUV\JoeD access to \\HB-RESWC-BDC\ExecDocuments	Failure
HAY-BUV\JoeD access to \\HB-RESWC-MEM\Specifications	Failure
HAY-BUV\ JoeD can install an additional Office 2000 component	Success
HAY-BUV\JoeD access to \\HB-RESWC-PDC\JoeD	Success

After you have logged on as HAY-BUV\RainierS and HAY-BUV\JoeD, you have to delete the local profiles that are generated for these users. This will allow the Security Translation Wizard to properly restore permission to the profile for HB-RESWC\JoeD during the resource domain walkthrough.

To delete the local profiles:

1. Log on to the workstation as local administrator.

2. Open Control Panel and double-click System.

3. Select the User Profiles tab.

4. Select the user HAY-BUV\RainierS and click Delete.

5. Select the user HAY-BUV\JoeD and click Delete.

Figure 9.50

Click OK and close the Control Panel.

Summary

In this walkthrough, you moved the users and groups from the Windows NT 4.0 account domain to the new Windows 2000 domain. Because the Windows NT 4.0 account domain controller is still needed for some steps in the "Resource Domain" walkthrough, it has not been demoted and migrated to the Windows 2000 domain.

For More Information

For the latest information on Windows NT Server, go to https://www.microsoft.com/ntserver and the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).

For the latest information on Windows 2000, go to https://www.microsoft.com/windows2000.

Before You Call for Support

Please keep in mind that Microsoft does not provide support for these walkthroughs. The purpose of the walkthroughs 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

You can report any problems with Microsoft Windows 2000 via the appropriate 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 installation files for some of the known issues.