Chapter 10: Consolidation of Windows NT 4.0 Resource Domains

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 for the consolidation of Microsoft Windows NT 4.0 resource domains into organizational units (OU) in a native mode Microsoft Windows 2000 domain.

This walkthrough is the successor to chapter 9, entitled, "Migration of a Windows NT 4.0 Account Domain to Active Directory," in which an account domain in a single master model was migrated into a native Windows 2000 domain and the resource domain remained intact.

The process of consolidating a resource domain into an organizational unit consists of moving resources and local groups to the new environment. Resources can be workstation computer accounts and file/printer server computer accounts. Shared local groups on domain controllers are mainly used to grant access to these resources. In addition, local groups on member servers used to grant access to resources have to be translated to reflect the changed domain membership of their members. This chapter covers the following topics:

• Test environment details

• Steps for migrating a Windows NT 4.0 resource domain to a Windows 2000 domain

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

Migrating Windows NT 4.0 resource domains to a Windows 2000 domain allows Windows NT administrators to:

• Consolidate multiple Windows NT 4.0 resource domains into a single Windows 2000 domain.

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

• Reduce the need for and cost of administering complex trusts.

• Deploy applications that require Windows 2000 infrastructure or features.

• Transition a Windows 2000 forest to production by adding productive resources.

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

This chapter assumes your test environment already exists from the previous walkthrough. One important change is that you must create the second trust from HAY-BUV to HB-RESWC, which results in a two-way trust between these domains. This is shown in Figure 10.1. The next section reviews the test environment requirements so you are able to verify your setup.

Test Environment

Figure 10.1: Existing and desired domain structures

Figure 10.1 shows the situation before migration of any Windows NT 4.0 domains to the new structurethat is, before account domain migration. This walkthrough covers only the resource domain migration of domain HB-RESWC.

To use the Microsoft Active Directory Migration Tool (ADMT), the user account with which you log on when you run the ADMT must have the following permissions:

• Administrator rights in the source domain.

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

• Administrator rights on each computer you migrate.

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

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

By default, workstations and member servers in a resource domain have the resource domain administrators global group in their local administrators group. The resource domain administrator account is a member of this group. When using ADMT to migrate objects, you must have administrative access to the objects you intend to migrate. This can be accomplished in one of two ways:

1. Create a temporary two-way trust between the target domain (HAY-BUV) and the source domain (HB-RESWC). There should currently be a one-way trust from HB-RESWC to HAY-BUV. Creating a two-way trust allows you to run the ADMT in the target domain (HAY-BUV) while logged in as HB-RESWC\Administrator, an account that already has administrative rights to the objects you will migrate from the resource domain.

2. Add an account to the local administrators group of every workstation and member server you intend to migrate and use that account to log in while you run the ADMT. This procedure can be automated via scripting and the use of Active Directory Service Interfaces (ADSI).

This walkthrough will use the first approach. If you have previously completed the steps documented in chapter 9, "Migration of a Windows NT 4.0 Account Domain to Active Directory," then you already have the basic environment to support this walkthrough. Ensure the environment is set up according to the information in this section.

Before migration, you have a Windows 2000 Active Directory domain hay-buv.tld, a Windows NT 4.0 resource domain HB-RESWC, and a Windows NT 4.0 account domain HB-ACCT. User accounts and global groups from HB-ACCT have been migrated to the hay-buv.tld domain. Some accounts may remain in the Windows NT 4.0 account domain, HB-ACCT. However, service accounts, for example, used to run services on member servers in the resource domain. The resource domain, HB-RESWC, has shared local groups (used to organize access to resources on domain controllers) and local groups on the member server. After the migration, all resources from the HB-RESWC domain as well as migrated copies of the shared local groups from the HB-RESWC domain will reside in an organizational unit called OU=HB-RESWC in the hay-buv.tld domain. The diagram above is a simplified example of the consolidation that could be expanded to include multiple resource domains.

Figure 10.2: Hay-buv.tld administrators

Verify that the HAY-BUV\Domain Admins is a member of the local administrators group on the HB-ACCT domain.

Figure 10.3: Domain HB-ACCT group administrators

The following computers are present in the test environment (The Windows NT 4.0 primary domain controller, HB-ACCT-PDC, remains in the environment from the account domain walkthrough):

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 Office 2000 Admin Installation
HB-RESWC-WS1	HB-RESWC	User workstation Office 2000 installed (Word only)

Figure 10.4: Server manager in HB-RESWC domain

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.

The administrator installs Office 2000 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, the administrator installs only the Word component of the Office 2000 suite.

The following user accounts were previously migrated in the "Account Domain" walkthrough:

Domain/computer	Name	Type	Group members
Hay-buv.tld	RainierS	User	N/A
Hay-buv.tld	JoeD	User	N/A
Hay-buv.tld	Executives	Global group	Hay-buv\RainierS

Create the following service account, make it a member of the local group HB-RESWC-MEM\Administrators, and grant the "log on as a service right" to HB-RESWC-MEM\Administrators:

Domain/computer	Name	Type	Password
HB-RESWC	Service-Acc-Res	User (service)	service1

The above service account is used to operate services on the server HB-RESWC-MEM. The member server will be configured to use this account to operate the spooler. Ensure that the service is configured properly according to the following table:

Computer	Service	Account	Startup type
HB-RESWC-MEM	Spooler	Service-Acc-Res	Manual

Ensure that the following OUs exist in the HAY-BUV domain:

• HB-ACCT

• HB-RESWC

To create the organizational unit HB-RESWC:

1. Open the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in.

2. Select the domain hay-buv.tld.

3. Right-click on hay-buv.tld, select New, and then select Organizational Unit.

4. Enter HB-RESWC as a name for the OU.

Figure 10.5: The new organizational unit HB-RESWC

At the completion of the "Account Domain" technical walkthrough, the following shares and their respective access rights should be present:

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

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 target 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.

Windows NT 4.0 Server "Built-in" Accounts

Account name

Domain controller

Member server

Administrators

Yes

Yes

Backup operators

Yes

Yes

Guests

Yes

Yes

Replicators

Yes

Yes

Users

Yes

Yes

Print operators

Yes

No

Server operators

Yes

No

Account operators

Yes

No

Power users

No

Yes

Requirements

The following conditions must be met in order to use this technical walkthrough:

• The target is a Windows 2000 native mode domain.

• The source domain is Windows NT 4.0 or Windows 2000 mixed or native mode.

• The Windows NT 4.0 source domain PDC has Service Pack 4 or higher installed.

• The source domain must not be in the same forest as the target domain.

• 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.

• The ADMT must be executed from 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 troubleshooting when using the event log.

The following constraints have to be taken into account:

• 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 computer; thus, adding them to a sIDHistory attribute would violate the requirement that the SID of a Windows 2000 forest be unique.

• 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.

Note: ADMT will create this group if it is not present when needed.

Security Requirements

To use the ADMT to consolidate the resource domains into OUs:

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

• Auditing for account management must be enabled in both the source and target domains.

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

• Source domain PDC must have the following registry entry:

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

Create this key if necessary and restart the computer to establish the change. 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.

Note: ADMT will create this key if it is not present when needed and will ask you to restart the computer. If this key is not set properly, DsAddSidHistory will return an "invalid handle" error message during the migration process.

Figure 10.6: Registry changes to source domain controller

As stated previously, this walkthrough requires that you establish a two-way trust between the source domain and the target domain.

Walkthrough

In this walkthrough, you will learn how to migrate the Windows NT 4.0 shared local groups, service accounts, and computer accounts, test the migrated resources, and decommission the Windows NT 4.0 resource domain.

The walkthrough consists of the following scenario steps:

1. Establishing trusts

2. Identifying service accounts

3. Migrating member server

4. Migrating Windows NT 4.0 workstation

5. Migrating local profiles

6. Roaming Profile Migration

7. Migrating shared local groups

8. Migrating service accounts

9. Updating service account user rights

10. Moving domain controllers

11. Decommissioning the Windows NT 4.0 source domain

The following flowchart shows the steps to perform the account domain migration described in chapter 9, "Migration of a Windows NT 4.0 Account Domain to Active Directory," as well as in the resource domain migration walkthrough.

Figure 10.7

Scenario Steps

Establishing Trusts

Establish trusts as explained in Chapter 4 of this cookbook, "Restructuring Tools."

Identifying Service Accounts

Service accounts are user accounts used to operate services on Windows NT and Windows 2000 computers. For this walkthrough the spooler service on the member server HB-RESWC-MEM was configured not to run under Local System Account (LSA). A service account from the HB-RESWC domain is used for the spooler service.

This step in the walkthrough finds the services not running under LSA. These will be included in the list of service accounts identified as not running under LSA. Therefore, the accounts must be updated on the computer after migration of the accounts.

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

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

Figure 10.8

Click Next.

Figure 10.9

Select HB-RESWC as the source domain and HAY-BUV as the target domain.

Note: You can use either network basic input/output system (NetBIOS) name HAY-BUV or Domain Name System (DNS) name haybuv.tld for the target domain syntax.

Click Next.

Figure 10.10

Select Yes, update the information.

Click Next.

To specify the computer using the service account, click Add, select HB-RESWC-MEM from the list, click Add, and then click OK.

Figure 10.11

Click Next.

Now you are prompted for user credentials. Use credentials with sufficient rights on HB-RESWC-MEM, for example, HB-RESWC\administrator.

Figure 10.12

Enter credentials for the HB-RESWC\Administrator.

Click Next.

Figure 10.13

The ADMT dispatches an agent to the server that records the activity in a file called DCTLog.txt stored in the \temp directory of the system drive. Here are the contents of that file (note the lines in bold text):

1999-11-16 12:07:19- 
1999-11-16 12:07:19-Active Directory Migration Tool, Starting... 
1999-11-16 12:07:19-Service Account information gathering beginning. 
1999-11-16 12:07:19-Alerter is using account LocalSystem 
1999-11-16 12:07:19-Browser is using account LocalSystem 
1999-11-16 12:07:19-cisvc is using account LocalSystem 
1999-11-16 12:07:19-ClipSrv is using account LocalSystem 
1999-11-16 12:07:19-DHCP is using account LocalSystem 
1999-11-16 12:07:19-EventLog is using account LocalSystem 
1999-11-16 12:07:19-EventSystem is using account LocalSystem 
1999-11-16 12:07:19-IISADMIN is using account LocalSystem 
1999-11-16 12:07:19-LanmanServer is using account LocalSystem 
1999-11-16 12:07:19-LanmanWorkstation is using account LocalSystem 
1999-11-16 12:07:19-LicenseService is using account LocalSystem 
1999-11-16 12:07:19-LmHosts is using account LocalSystem 
1999-11-16 12:07:19-Messenger is using account LocalSystem 
1999-11-16 12:07:19-MSDTC is using account LocalSystem 
1999-11-16 12:07:19-MSFTPSVC is using account LocalSystem 
1999-11-16 12:07:19-MSIServer is using account LocalSystem 
1999-11-16 12:07:19-NetDDE is using account LocalSystem 
1999-11-16 12:07:19-NetDDEdsdm is using account LocalSystem 
1999-11-16 12:07:19-Netlogon is using account LocalSystem 
1999-11-16 12:07:19-NtLmSsp is using account LocalSystem 
1999-11-16 12:07:19-PlugPlay is using account LocalSystem 
1999-11-16 12:07:19-ProtectedStorage is using account LocalSystem 
1999-11-16 12:07:19-Replicator is using account LocalSystem 
1999-11-16 12:07:19-RPCLOCATOR is using account LocalSystem 
1999-11-16 12:07:19-RpcSs is using account LocalSystem 
1999-11-16 12:07:19-Schedule is using account LocalSystem 
1999-11-16 12:07:19-SENS is using account LocalSystem 
1999-11-16 12:07:19-Spooler is using account HB-RESWC\Service-Acc-Res 
1999-11-16 12:07:19-TapiSrv is using account LocalSystem 
1999-11-16 12:07:19-UPS is using account LocalSystem 
1999-11-16 12:07:19-W3SVC is using account LocalSystem 
1999-11-16 12:07:19-OnePointDomainAdminService is using account LocalSystem 
1999-11-16 12:07:19-Service Account information gathering completed. 
1999-11-16 12:07:20-A session to \\HAY-BUV-DC1 established,
                    to report the results of the migration. 
1999-11-16 12:07:20-Wrote result file 
                    \\HAY-BUV-DC1\OnePointDMR$\HB-RESWC-MEM420756435.result 
1999-11-16 12:07:20-Operation completed.

Note: On a Windows 2000 computer, this file can be found in the Profiles Temp folderfor example, \Documents and Settings\Administrator\Local Settings\Temp folder).

The spooler service was identified as being started by a special account while all services run by the LocalSystem authority are ignored.

Click Close.

The Results window lists all registered service accounts.

Figure 10.14

Click Next.

Figure 10.15

Click Finish.

At this point, there is information in the ADMT database about this service account. When the service account is migrated later using the User Migration Wizard, the tool will make the proper changes on the member server. (This is discussed later in the section "Migrating Service Accounts.") If the service account is granted its rights via its membership in a group, there is an additional step to update user rights and group membership for these accounts. This is accomplished by running the Security Translation Wizard; this is discussed later in the section "Update Service Account User Rights."

Migrating Member Server

Workstations and member servers have their own 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 NT 4.0 server HB-RESWC-MEM from the Windows NT 4.0 HB-RESWC domain to the HB-RESWC OU in the Windows 2000 hay-buv.tld domain.

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

Figure 10.16

Click Next.

Figure 10.17

Select Migrate now?

Click Next.

18:

Enter HB-RESWC as the source domain.

Enter hay-buv.tld (or HAY-BUV) as the target domain.

Click Next.

In the following dialog box, click Add, select the member server in the source domain HB-RESWC-MEM, click Add, and then click OK.

Figure 10.19

Click Next.

In the following dialog box, specify the target container. Click Browse, select the HB-RESWC OU, and then click OK.

Figure 10.20

Click Next.

Figure 10.21

Ensure that no items are selected in this dialog box.

Click Next.

Figure 10.22

Enter the source domain's administrative credentials.

Click Next.

Figure 10.23

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

Click Next.

Figure 10.24

Select Ignore conflicting accounts and don't migrate.

Click Next.

Figure 10.25

Click Finish.

Figure 10.26

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

Click Close.

Figure 10.27

The agents are then dispatched to the computers to be migrated. Once the agents are dispatched, the Agent Monitor dialog box 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.

Tip The dispatch log file and the migration log file are quite useful for troubleshooting the Computer Migration Wizard.

Here is the output of the dispatch log file for the computer migration:

1999-12-02 09:28:24-The dispatcher created a share for the result directory
                    F:\Program Files\Active  
Directory Migration Tool\Logs\Agents as: \\HAY-BUV-DC1\OnePointDMR$\ 
1999-12-02 09:28:24-Installing agent on 1 servers 
1999-12-02 09:28:24-The The Active Directory Migration Tool Agent will be 
                    installed on \\HB-RESWC-MEM 
1999-12-02 09:28:28-The agent is installed on \\HB-RESWC-MEM 
1999-12-02 09:28:28-Started job:  \\HB-RESWC-MEM HB-RESWC-MEM62832488 
                    {02716A22-A8DE-11D3-9460-00C04F37B8A0} 
1999-12-02 09:28:29-All agents are installed.  The dispatcher is finished.

After you restart the computer, HB-RESWC-MEM is a member of the HAY-BUV domain.

Figure 10.28: The member server HB-RESWC-MEM was moved to the HAY-BUV.tld domain

At this point you have migrated the member server to the HAY-BUV domain, but the spooler service account still specifies the account (Service-Acc-Res) that is in the HB-RESWC domain. The service should still be functional because of the two-way trust you set up to the resource domain. You should make sure the service is still functional. To verify that the service starts, open the Service Control Manager on HB-RESWC-MEM and choose Start.

Migrating Windows NT 4.0 Workstation

The workstation will now be migrated to the target domain. Move HB-RESWC-WS1 using the same steps outlined in the section "Migrating Member Server," substituting HB-RESWC-WS1 in the Computer Selection dialog box.

After you complete the workstation migration and restart the computer, verify that the workstation is now part of the HAY-BUV domain.

Figure 10.29: The workstation HB-RESWC-WS1 after migration

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

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

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

• The following events were logged in the target domain (for each computer migrated):

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 following events were logged on the migrated computers:

Application log: event ID 1, <computer-name>$ copied to HAY-BUV\<computer-name>$

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

Figure 10.30: HB-RESWC-MEM and HB-RESWC-WS1 in the HB-RESWC OU in hay-buv.tld

Migrating Local Profiles

After migrating the computer HB-RESWC-WS1 to the HAY-BUV Windows 2000 target domain, you now convert the existing local profile on the workstation. Prior to this procedure, you should have modified the local profile for the user JoeD in some noticeable way, for example by changing the background color or adding shortcuts to the desktop.

Note: This procedure assumes that you have already migrated the JoeD account from the master domain HB-ACCT to the target domain HAY-BUV.

Migration of user accounts is completed during the "Account Domain" walkthrough.

Check the local profiles on the Windows NT 4.0 workstation by logging on to HB-RESWC-WS1 as the local administrator and run the registry editor:

1. Start Registry Editor Regedit.exe.

2. Open HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList.

You should see three entries listed in ProfileList (note the SID for later comparison):

• The local administrator's SID

• HB-ACCT\JoeD's SID

• HB-ACCT\RainierS's SID

Figure 10.31: Local profiles that exist on HB-RESWC-WS1

Minimize the Registry Editor, but leave it runningyou will use it at the end of this procedure to verify the local profile migration.

On the target Windows 2000 domain controller, HAY-BUV-DC1, log on as HAY-BUV\administrator. 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 10.32

Click Next.

Figure 10.33

Select Migrate now?".

Click Next.

Figure 10.34

Select HB-ACCT as the source and hay-buv.tld as the target domains.

Click Next.

To specify the workstation, click Add in the next dialog box, choose HB-RESWC-WS1, and then click OK.

Figure 10.35

Note: If the domains of the computers for security translation are not in the list of domains in Object Picker (brought up with the Add button), you can add them to the list of additional trusting domains, one at a time, and then that domain will be available in Object Picker.

Figure 10.36

Specify User Profiles.

Click Next.

Figure 10.37

Select Add to add the new user profile entry with the updated SID, while leaving the old one in place.

Click Next.

Figure 10.38

Enter the HAY-BUV\Administrator credentials.

Click Next.

Figure 10.39

Click Finish.

Figure 10.40

The dialog box displays Running and then Completed.

The file Dctlog.txt in the Temp directory on the workstation will list the details of the security translation.

1999-12-02 10:33:08-The dispatcher created a share for the result directory 
                    F:\Program Files\Active  
Directory Migration Tool\Logs\Agents as:
                    \\HAY-BUV-DC1\OnePointDMR$\ 
1999-12-02 10:33:11-Created account input file for remote agents: DCTCache 
1999-12-02 10:33:11-Installing agent on 1 servers 
1999-12-02 10:33:11-The The Active Directory Migration Tool Agent will be installed on \\HB-RESWC-WS1 
1999-12-02 10:33:15-The agent is installed on \\HB-RESWC-WS1 
1999-12-02 10:33:16-Started job:  \\HB-RESWC-WS1 HB-RESWC-WS166719717 
                    {02AEE1D2-A8E7-11D3-8D5F-00A0C9EE4187} 
1999-12-02 10:33:16-All agents are installed.  The dispatcher is finished.

Switch to the Registry Editor on HB-RESWC-WS1 and refresh the registry view of the HB-RESWC-WS1 computer. You should see two new entries, one for the local profile user JoeD, one for the roaming profile user RainierS. Note that the new entries reflect the SID of the target domain:

Figure 10.41

ProfileList now has five entries:

• Local administrator

• HB-ACCT\JoeD

• HAY-BUV\JoeD

• HB-ACCT\RainierS

• HAY-BUV\RainierS

Verify the results using the following tests; the expected results are specified for each user:

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 contains the document placed there as 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 maintains the profile from HB-ACCT\JoeD with Maple desktop	Success
Recycle bin contains the document placed there earlier as HB-ACCT\JoeD	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 Office2000 component	Success
HAY-BUV\JoeD access to \\HB-RESWC-PDC\JoeD	Success

Roaming Profile Migration

Roaming profile migration is an option when running the ADMT User Migration Wizard. The profile of the roaming user in this scenario, RainierS, was migrated when you migrated his user account in the ADMT User Migration Wizard procedure in the "Account Domain" walkthrough. When you logged on to the workstation HB-RESWC-WS1 as user HAY-BUV\RainierS, you should have seen RainierS's roaming profile.

Note: Roaming profile migration is also an option when you are running the Group Account Migration Wizard and you choose to include users who are members of the groups. However, migrating roaming profiles using this procedure is not recommended at this time.

Migrating Shared Local Groups

If shared local groups on domain controllers are used to organize access rights, the administrator has to perform some additional steps in order to make sure that the users can access the resources after the server is moved. There are two different ways to achieve this:

• Leave the domain as a Windows NT 4.0 domain, and migrate all shared local groups to the target domain using the ADMT Group Migration Wizard. Then the domain controllers can be upgraded to Windows 2000 and moved to the same domain.

• Upgrade all domain controllers in the resource domain to Windows 2000, put the domain into native mode, and change the group type of the former shared local groups to universal groups. Now the domain controllers can be demoted one by one to member servers and moved to the target domain. The users will always have access to the resources because universal groups can exist anywhere in the forest and be used to grant permissions. Before the last domain controller is moved and the domain is decommissioned, the universal groups must be moved using the ADMT.

Note: Universal groups are stored in the global catalog, so there may be additional performance implications.

This walkthrough uses the first approach described above.

This wizard migrates the shared local group from the source domain controller to the target domain and places it in the HB-RESWC organizational unit, creating a domain local group in that OU.

On the target Windows 2000 domain controller, HAY-BUV-DC1, log on as HAY-BUV\administrator and launch the ADMT from within the MMC. Open the Active Directory Migration Tool and select Group Account Migration Wizard from the Action menu.

Figure 10.42

Click Next.

Figure 10.43:

Check Migrate now?

Click Next.

Figure 10.44

Enter HB-RESWC for the source domain and hay-buv.tld for the target domain.

Click Next.

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

Figure 10.45

Click Next.

To select the target container, you have the option of browsing the containers in the hay-buv.tld domain or typing the Lightweight Directory Access Protocol (LDAP) name of the target container.

Figure 10.46

Figure 10.47

Click Next.

Figure 10.48

Ensure that Migrate group SIDs to target domain and Do not rename accounts are the only items selected.

Click Next.

Figure 10.49

Enter the HB-RESWC\Administrator credentials.

Click Next.

Figure 10.50

Select Ignore conflicting accounts and don't migrate.

Click Next.

Figure 10.51

Click Finish.

Figure 10.52

The Migration Progress dialog box is displayed and updated.

When the operation completes, the Status property in the dialog box 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=Sales,OU=HB-RESWC ,DC=HAY-BUV,DC=tld.

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

• The following events were 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

• The following event was logged in the on the PDC of the source domain:

Application log: event ID 1, Source=EaDctAgent, Sales copied to HAY-BUV\Sales

The Active Directory Administration Tool that is available on the Windows 2000 CD through installation of the support tools from directory SUPPORT can be used to verify creation of the sIDHistory. To get the view as shown here, follow these steps:

1. Open Ldp.exe through Windows 2000 Support Tools/Tools/Active Directory Administration Tool.

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

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

4. On the View menu, select Tree.

5. Expand the tree to see the sales group with the added sIDHistory.

Figure 10.53

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

Figure 10.54: The shared local group Sales was migrated from the Windows NT 4.0 domain HB-RESWC to the OU HB-RESWC in the Active Directory domain hay-buv.tld

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

Figure 10.55: Group memberships are preserved when a group is migrated

The group type of the Sales group has changed from a local group (which exists in Windows NT 4.0 and in Active Directory as long as the domain is in mixed mode) to a domain local group. This change enables the group to be used in discretionary access control lists (DACLs) on Windows 2000 member servers and workstations.

Figure 10.56

The group type is now domain local.

Migrating Service Accounts

Service accounts are user accounts used to operate services on the servers. These accounts may exist both in a master account domain and in the same resource domain as the server. For this walkthrough, the member server is configured to use a service account from the resource domain. If the service account is in an account domain, this procedure would be completed by selecting the account domain as the source.

The member server was configured to use this account to operate the spooler service in the test environment section of this walkthrough and was verified in the test environment section above.

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

Figure 10.57

Click Next.

Figure 10.58

Check Migrate now?.

Click Next.

Figure 10.5:

Select HB-RESWC as the source and HAY-BUV as the target and click Next.

To select the account you want to migrate, click Add in the next dialog box, double-click HB-RESWC\Service-Acc-Res, and then click OK.

Figure 10.60

Figure 10.61

Click Next.

Figure 10.62

Click Next.

Figure 10.63

Select Complex passwords.

Enter a file name for the location in which to store the password file or accept the default.

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

Note: Independently of what you select here, the ADMT will always create complex passwords for service accounts to migrate.

Click Next.

Figure 10.64

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

Click Next.

Figure 10.65

Enter the password for the HB-RESWC\Administrator account.

Click Next.

Figure 10.66

Select Update user rights only.

Click Next.

Figure 10.67

Select the desired action to take when a conflict occurs with a user account name.

Click Next.

Figure 10.68

Click Next.

Figure 10.69

This message box is a warning that if the service account has any local rights inherited only from its membership to a local group (for example, "log on as a service" as a member of local administrators) then you must fix up these rights by running the Security Translation Wizard.

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. You can check that in the appropriate log file.

Click OK.

Figure 10.70

Click Finish.

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

Figure 10.71

Click Close.

This procedure migrated a service account from the same resource domain as the member server. In the case of the service account that resides in a different domain than the server (for example, an account domain), the above procedure would need to be repeated using the account domain as the source. The next step is to update the local rights on the member server using the Security Translation Wizard.

Update Service Account User Rights

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 now migrated the service account to the target domain. Next you must ensure that this new account has the same set of local rights to the member server that the original account did. This is accomplished with the Security Translation Wizard.

From the target Windows 2000 domain controller, HAY-BUV-DC1, log on as HAY-BUV\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 10.72

Click Next.

Figure 10.73

Select Migrate now?

Click Next.

Figure 10.74

Select HB-RESWC as the source and HAY-BUV as the target.

Click Next.

To select the computer on which the security translation will take place, click Add in the next dialog box, double-click HB-RESWC-MEM, and then click OK.

Figure 10.75

Click Next.

Figure 10.76

Select Local groups and User rights.

Click Next.

Figure 10.77

Select Add.

Click Next.

Figure 10.78

Enter the HAY-BUV\Administrator credentials.

Click Next.

Note: You enter the HAY-BUV credentials here because of the order of migration. You have already moved the server to the target domain and need to supply credentials that have local administrator authority on the member server after the migration. If you were completing this step prior to migrating the computer to the target domain, you would use the HB-RESWC\Administrator source domain credentials as the dialog box indicates.

Figure 10.79

Click Finish.

Figure 10.80

At this point you have updated local group security on the HB-RESWC-MEM server by adding the migrated service account to any local groups it may have been a member of, such as local administrators. In addition, the "log on as a service right" has been granted to the migrated service account (HAY-BUV\Service-Acc-Res). You can verify this on HB-RESWC-MEM with Local Users and Groups.

Figure 10.81

Note: It seems that HAY-BUV\Service-Acct-Res is twice a member of the administrators group in HAY-BUV. This is because you performed the security translation in "Add" mode. Now both the source domain and target domain account for Service-Acc-Res are added to this local group. The source domain account is resolved to the target domain user by Windows 2000 using sIDHistory and the global catalog, but the SID here is the source domain user's SID.

Moving Domain Controllers

Moving domain controllers is a three-step process:

• Upgrade the operating system to Windows 2000.

• Run Active Directory Installation Wizard to demote the domain to a member server.

• Join the target domain.

Once the computer is a Windows 2000 member server, it can be joined to the target domain via a manual process or the use of the ADMT Computer Migration Wizard. This walkthrough will use the manual process described below.

Migrating Backup Domain Controllers

When completing an in-place upgrade from Windows NT to Windows 2000, the first computer to be migrated must be the PDC. Setup will not continue if it detects that it is being run on a BDC. There are a number of reasons you might want to migrate the BDCs first, however. The process you use to migrate Windows NT BDCs prior to migrating the PDC is as follows:

1. Synchronize the BDC.

2. Take the BDC off the network and promote it to PDC (via Server Manager).

3. Perform an in-place upgrade to Windows 2000 (note: because this computer is a PDC, it causes Active Directory Installation Wizard to run automatically).

4. Run Active Directory Installation Wizard to demote the computer to a member server and join the target domain.

Upgrade HB-RESWC-BDC by following these steps:

1. Synchronize the Windows NT domain by selecting Synchronize entire domain in Server Manager. Unplug the BDC from the network, promote it to PDC, and upgrade using the Windows 2000 CD.

2. Complete the Active Directory wizard to promote the server to a domain controller in a new Active Directory domain. In the wizard, the options Create a new domain tree and Create a new forest of domain trees must be selected. A temporary name for the domain can be usedin this example, it is test.lab.tld. Complete the wizard by accepting the defaults. If you receive an error message regarding DNS, click OK to continue. The computer will restart.

3. Next, the Active Directory wizard must be executed again to demote the domain controller to a member server. Launching Active Directory Installation Wizard at a command prompt starts the wizard.

Figure 10.82: Active Directory Installation Wizard demoting the domain controller HB-RESWC-BDC

Continue to let the wizard accept the defaults. Enter the local administrative password specified during the first wizard. After you restart the computer, HB-RESWC-BDC is part of the workgroup WORKGROUP.

Figure 10.83: The network identification of the server HB-RESC-BDC, after demoting the domain controller

Join the hay-buv.tld domain by selecting Properties in the dialog box above and selecting Create computer account. After completing this operation, the server HB-RESWC-BDC is now moved to the Windows 2000 domain hay-buv.tld.

The HAY-BUV-BDC has been joined to the hay-buv.tld domain through the Network Identification tab in My Computer. The computer account is moved to the Computers container in HAY-BUV and must be manually moved to the HB-RESWC OU.

Figure 10.84: HB-RESWC-BDC in the HB-RESWC OU

After a successful move operation, the user access to the resources on HB-RESWC-BDC must be checked again. The permissions on the shared folder ExecDocuments do not reflect the shared local group from the HB-RESWC domain any more, but display a domain local group from hay-buv.tld on the member server HB-RESWC-BDC. Note: You should run the Security Translation Wizard on this computer now to fix up the local permissions.

Figure 10.85: The DACL editor in HB-RESWC-BDC resolves the SID of a shared local group from the source domain as a domain local group

The following user access tests must be performed:

Test	RainierS	JoeD
Log on to workstation HB-RESWC-WS1	Success	Success
Access \\HB-RESWC-BDC\ExecDocuments	Success	Fail
Access https://HB-RESWC-BDC/default.htm	Success	Fail

Migrating the Primary Domain Controller

The last task the administrator has to perform is to upgrade the PDC of the HB-RESWC domain to Windows 2000. You should use the same procedure to perform this operation as with the BDC, with the exception that you do not need to take the computer off the network.

The PDC HB-RESWC-PDC has to be upgraded to Windows 2000 first. After the operating system upgrade, the Active Directory wizard can be used to promote the server to a domain controller in a new Active Directory domain. In the wizard, the options Create a new domain tree and Create a new forest of domain trees must be selected. A temporary name for the domain can be used. For more information on how to set up Active Directory domains, see the Windows 2000 Deployment Guide.

In this example, the name of the new domain is temp.lab.tld. Note that the down-level name of the domain is still HB-RESWC.

Figure 10.86

After the upgrade of the PDC, a temporary Windows 2000 Active Directory domain temp.lab.tld was created. Figure 10.86 shows the properties of the domain in the Users and Computers MMC snap-in. The down-level domain name is still HB-RESWC.

Next, the Active Directory wizard can be executed again to demote the server to a stand-alone server, ensuring that you select that this is the last domain controller in the domain. Launching Active Directory Installation Wizard on a command prompt starts the wizard.

After you restart the computer, HB-RESWC-PDC is part of the workgroup WORKGROUP.

Figure 10.87

After demoting the only domain controller in the temp.lab.tld domain, the server is added to a workgroup.

Now the computer can be joined to the target domain in the same manner as the former BDC and should be moved to the HB-RESWC OU.

The following user access tests must be performed:

Test	RainierS	JoeD
Log on to workstation HB-RESWC-WS1	Success	Success
Access \\HB-RESWC-PDC\Finance	Success	Fail
Access \\HB-RESWC-PDC\JoeD	Fail	Success

Decommissioning the Windows NT 4.0 Source Domain

Now that all domain controllers are migrated to hay-buv.tld, the HB-RESWC domain no longer exists. The last task is to remove all trust relationships that existed between hay-buv.tld and the former Windows NT 4.0 domain HB-RESWC. To remove the trust:

• Start the Active Directory Trees and Trust MMC snap-in.

• Right-click the hay-buv.tld domain and select Properties.

• Click on the Trusts tab.

• Select the name of the former resource domain, HB-RESWC, and click Remove.

Figure 10.88

The figure above shows the trust relationships of the domain hay-buv.tld, shown in the Properties dialog box of the domain in the Active Directory Domains and Trusts MMC snap-in. The trusts are not removed automatically; the administrator should delete them.

This concludes the complete migration process. All Windows NT 4.0 domains have been redeployed in the Windows 2000 domain, and the only remaining domain is the new Windows 2000 domain hay-buv.tld.

Summary

The complete migration from a Windows NT 4.0 resource domain into one new Windows 2000 domain can be performed with the help of the ADMT. Through the use of the sIDHistory application programming interface (API), it is not necessary to change access control entries on any resources. The only drawback is that the DACL editor is not able to resolve SIDs that belong to users or groups created in the down-level domains. In the long term, the administrator might choose to change the DACLs so that they now use the primary SIDs of the users and groups. The ADMT Translate Security Wizard can perform this operation.

Once this process is completed, the sIDHistory attribute of the migrated users and groups can be cleared.