microsoft domain migration cookbook

de 316

MICROSOFT

DOMAIN

MIGRATION

COOKBOOK

de 316

Tabla de contenido Domain Migration Cookbook – Introduction...............................................................8

About the Cookbook.......................................................................................................................8 Who Should Read This .....................................................................................................................8 Prerequisites ...................................................................................................................................9 Related Materials .............................................................................................................................9

Migration Goals ..............................................................................................................................9 Business-Related Goals.....................................................................................................................9 Migration-Related Goals .................................................................................................................11

Conclusion ....................................................................................................................................12 Domain Migration Cookbook - Chapter 1: Security .............................................14

Introduction...................................................................................................................................14 Authentication and Authorization.................................................................................................14

Security Identifiers .........................................................................................................................14 Authentication and Access Tokens ....................................................................................................14 Authorization and Security Descriptors ..............................................................................................15 Authorization and Upgrade ..............................................................................................................15 Authorization and Restructure ..........................................................................................................15

SIDHistory ....................................................................................................................................16 Security Implications of SIDHistory ..................................................................................................17

Domain Migration Cookbook - Chapter 2: Domain Upgrade...........................19 Introduction...................................................................................................................................19 Implications of Domain Upgrade..................................................................................................19

The Active Directory Installation Wizard (dcpromo.exe) .......................................................................20 Windows NT PDC .........................................................................................................................20 The Effect of Upgrade on Trusts .......................................................................................................21 Using NTLM Authentication............................................................................................................22 Using Kerberos Authentication.........................................................................................................23 Switching to Native Mode ...............................................................................................................25 Upgrade and Resource Domains .......................................................................................................25 Upgrade and Administration ............................................................................................................26 Mixed Mode and Native Mode .........................................................................................................26 Mixed Mode .................................................................................................................................27 Native Mode .................................................................................................................................28 Switching to Native Mode ...............................................................................................................29 Features Available in Mixed Mode ....................................................................................................30 Windows 2000 Groups....................................................................................................................31 Local Groups.............................................................................................................................31 Domain Local Groups.....................................................................................................................31 Global Groups...............................................................................................................................32 Universal Groups ...........................................................................................................................32 Use of Universal Groups .................................................................................................................32 Universal Groups and Access Tokens ................................................................................................33 Nesting Groups..............................................................................................................................33 Multimaster Replication and Group Administration ..............................................................................34 Effects of Upgrade on Groups ..........................................................................................................34 NetBIOS and WINS in Windows 2000...............................................................................................35 Availability of LAN Manager Replication Service................................................................................36 The LMRepl Process ......................................................................................................................36

de 316

The FRS Process............................................................................................................................37 Maintaining LMRepl Services in a Mixed Environment ........................................................................38 LMRepl and Upgrade .....................................................................................................................38 Using Remote Access Service in a Mixed Environment.........................................................................38 Supported Upgrade Paths ................................................................................................................39 Order for Upgrading Domains ..........................................................................................................40 Upgrading Account Domains ...........................................................................................................40 Order of Account Domains ..............................................................................................................40 Order of Resource Domains .............................................................................................................41 Upgrading Workstations and Servers .................................................................................................41

Domain Migration Cookbook - Chapter 3: Domain Restructure....................43 Introduction...................................................................................................................................43 Domain Restructure ......................................................................................................................43

When Should You Restructure? ........................................................................................................43 Why Would You Restructure? ..........................................................................................................45

Implications of Domain Restructure .............................................................................................46 The Effect of Moving Security Principals on SIDs................................................................................46 Moving Security Principals ..............................................................................................................47 Effects of the Move on Bob's Global Group Membership.......................................................................47 Effects of the Move on DACLs Directly Referencing Bob .....................................................................48 SIDHistory ...................................................................................................................................48 Taking Advantage of SIDHistory: Moving vs. Cloning .........................................................................49 Cloning Security Principals..............................................................................................................50 Cloning Constraints........................................................................................................................51 Moving Security Principals ..............................................................................................................51 Constraints on Moving Objects with SIDHistory..................................................................................51 Closed Sets and Moving Users and Global Groups ...............................................................................52 Closed Sets and Moving Computers ..................................................................................................52 Ways Around Closed Sets ...............................................................................................................52 SIDHistory Considerations ..............................................................................................................53 The Implications of Cloning on SID Resolution ...................................................................................53 Establishing Trusts .........................................................................................................................54 Moving Servers .............................................................................................................................54 Account Deletion and Cloning Local Groups.......................................................................................55 Windows NT 3.51 and SIDHistory ....................................................................................................55 Profiles and SIDHistory ..................................................................................................................56 Profile Migration ...........................................................................................................................57 Third-Party Applications and Profiles ................................................................................................58

Migration Scenarios ......................................................................................................................58 Domain Migration Scenarios ............................................................................................................58 Migrating Users Incrementally to Windows 2000 (Interforest) ................................................................59 Scenario Steps...............................................................................................................................59 Migrating Resources Incrementally to Windows 2000 (Interforest) ..........................................................60 Scenario Steps...............................................................................................................................60

Domain Migration Cookbook - Chapter 4: Restructuring Tools .....................64 Introduction...................................................................................................................................64 Microsoft Restructure Tools .........................................................................................................64 Which Tool Should You Use? ......................................................................................................65

Interforest Migration ......................................................................................................................65 Advantages of Interforest Migration ..................................................................................................65

de 316

Disadvantages of Interforest Migration...............................................................................................66 Interforest Migration Tools ..............................................................................................................66 Intraforest Migration ......................................................................................................................67 Advantages of Intraforest Migration ..................................................................................................67 Disadvantages of Intraforest Migration...............................................................................................67 Intraforest Migration Tools ..............................................................................................................68

Description of Restructuring Tools...............................................................................................69 Active Directory Migration Tool.......................................................................................................69 Requirements ................................................................................................................................69 ClonePrincipal...............................................................................................................................70 When to Use ClonePrincipal ............................................................................................................70 ClonePrincipal Files .......................................................................................................................71 Requirements ................................................................................................................................71 ClonePrincipal Syntax ....................................................................................................................72 Netdom........................................................................................................................................73 When to Use Netdom......................................................................................................................73 Requirements ................................................................................................................................73 Netdom Syntax..............................................................................................................................73 Command.....................................................................................................................................73 /d:domain .....................................................................................................................................74 Object..........................................................................................................................................75 [/options]......................................................................................................................................75 MoveTree.....................................................................................................................................77 When to Use MoveTree ..................................................................................................................77 Requirements ................................................................................................................................77 MoveTree Syntax...........................................................................................................................77

Domain Migration Cookbook - Chapter 5: Mature Windows 2000 Domains........................................................................................................................................79

Introduction...................................................................................................................................79 Protected Storage (PStore)............................................................................................................79

Secure Storage for Data...................................................................................................................79 Preserving PStore Contents ..............................................................................................................80

Encrypting File System.................................................................................................................80 A Secure Encryption Method ...........................................................................................................80 Protected Storage and Encrypting File System .....................................................................................81

Group Policy .................................................................................................................................81 Defining the Rules .........................................................................................................................81 Selecting Policies...........................................................................................................................82

Domain Migration Cookbook - Chapter 6: Welcome to Hay Buv Toys ......83 Introduction...................................................................................................................................83 About Hay Buv Toys ....................................................................................................................83

Overview .....................................................................................................................................83 Environment Background ................................................................................................................83

Current Windows NT 4.0 Domain Model ....................................................................................84 Geographic Structure ......................................................................................................................84

User Account Domains Description .............................................................................................85 Three Domains ..............................................................................................................................85 Domain Consolidation ....................................................................................................................86

Resource Domains Description.....................................................................................................87 Their Purpose................................................................................................................................87

de 316

Desktop Environment Description................................................................................................88 Windows NT Is Standard.................................................................................................................88

Environment Summary .................................................................................................................89 The Company's Goal ......................................................................................................................89

Domain Migration Cookbook - Chapter 7: The Desired Structure and Migration Goals.........................................................................................................................90

Introduction...................................................................................................................................90 DNS Architecture..........................................................................................................................90

The Domain Decision .....................................................................................................................90 Designing the Windows 2000 Domain Structure .........................................................................91

Deployment Without Disruption .......................................................................................................91 Single Domain ..............................................................................................................................91 Moving to a Single Domain .............................................................................................................91 Multiple Domains ..........................................................................................................................92 In-place Upgrade ...........................................................................................................................92 Advantages of In-place Upgrade .......................................................................................................92 Using a Placeholder Domain ............................................................................................................93 Consolidating the MANUFACTURING Domain .................................................................................93 Consolidating the Resource Domains into OUs ....................................................................................94 Post-Migration Cleanup ..................................................................................................................94 Proposed Structure .........................................................................................................................94 OU Structure.................................................................................................................................95 Setting Up a Hierarchy....................................................................................................................95

Steps to Get to the Desired Structure ............................................................................................96 Create the Target Environment .........................................................................................................96 Consolidate Resource Domains into OUs.................................................................................97 Post-Migration Cleanup ............................................................................................................97

Domain Migration Cookbook - Chapter 8: Domain Upgrade...........................99 Upgrade of the HB-ACCT-ROW Accounts Domain ...................................................................99

Overview...................................................................................................................................99 Checklist ....................................................................................................................................100 Pre-upgrade work....................................................................................................................101 Upgrade PDC (mixed mode domain) .....................................................................................101 Install additional domain controllers ......................................................................................102 Switch to native mode.............................................................................................................102 Checkpoints.............................................................................................................................102 Preupgrade Work ....................................................................................................................102 Determine Domain Controller Hardware................................................................................102 Create Computer Assignment Table.......................................................................................103 Install a New Member Server .................................................................................................104 Secure Domain Data ...............................................................................................................104 Create a Test Matrix................................................................................................................106 Upgrade PDC (Mixed Mode Domain)....................................................................................108 Configure LMRepl File Replication Service ..........................................................................109 Verify DNS Configuration......................................................................................................112 Synchronize File Replication Services ...................................................................................125 Standard Operations Validation..............................................................................................126 Install Additional Domain Controllers....................................................................................127 Promote Windows 2000 Member Server to Domain Controller ............................................127 Upgrade Remaining Windows NT 4.0 BDCs.........................................................................132

de 316

Switch to Native Mode ...........................................................................................................133 Domain Migration Cookbook - Chapter 9: Migration of a Windows NT 4.0 Account Domain to Active Directory ...........................................................................135

Introduction.................................................................................................................................135 Overview.................................................................................................................................135 Why Migrate a Windows NT 4.0 Account Domain to a Windows 2000 Domain? ...............135 Migration Environment...........................................................................................................136 Terminology............................................................................................................................141 Requirements ..........................................................................................................................142 Security Requirements ............................................................................................................143 Walkthrough ...........................................................................................................................144

Scenario Steps.............................................................................................................................145 Preparing the Windows 2000 Target Domain ........................................................................145 Enable Auditing.........................................................................................................................146 Change Windows 2000 Domain to Native Mode ...................................................................147 Establishing the Trusts Required Between Account, Resource, and Windows 2000 Domain147 Migrating All Global Groups from the Source to the Target Domain....................................149 Installation of the ADMT ..............................................................................................................149 Migrating Global Groups...............................................................................................................149 ADMT Group Migration Wizard.....................................................................................................150 Verify Migrated SID ...............................................................................................................158 Identifying and Migrating Sets of Users.................................................................................159 ADMT User Account Migration Wizard................................................................................160 Fallback Plan...........................................................................................................................170 Decommissioning the Windows NT 4.0 Source Domain.......................................................171 Migration Tests .......................................................................................................................171

Summary.....................................................................................................................................173 For More Information .............................................................................................................173 Before You Call for Support...................................................................................................173 Reporting Problems ................................................................................................................173

Domain Migration Cookbook - Chapter 10: Consolidation of Windows NT 4.0 Resource Domains .......................................................................................................175

Introduction.................................................................................................................................175 Overview.................................................................................................................................175 Why Migrate a Windows NT 4.0 Resource Domain to a Windows 2000 Domain? ..............175 Test Environment....................................................................................................................176 Terminology............................................................................................................................181 Requirements ..........................................................................................................................181 Security Requirements ............................................................................................................182 Walkthrough ...........................................................................................................................183

Scenario Steps.............................................................................................................................185 Establishing Trusts..................................................................................................................185 Identifying Service Accounts..................................................................................................186 Migrating Member Server.......................................................................................................191 Migrating Windows NT 4.0 Workstation ...............................................................................198 Migrating Local Profiles .........................................................................................................200 Roaming Profile Migration .....................................................................................................207 Migrating Shared Local Groups..............................................................................................207 Migrating Service Accounts ...................................................................................................216 Update Service Account User Rights .....................................................................................223

de 316

Moving Domain Controllers ...................................................................................................228 Decommissioning the Windows NT 4.0 Source Domain.......................................................235

Summary.....................................................................................................................................235 Domain Migration Cookbook - Chapter 11: Intraforest Migration .............237

Introduction.................................................................................................................................237 Overview.................................................................................................................................237 Why Migrate Domain Structure into a Single Windows 2000 Domain? ...............................237 Test environment ....................................................................................................................238 Preparing the Source and the Target Domain .........................................................................239 Terminology............................................................................................................................243 Requirements ..........................................................................................................................244 Security Requirements ............................................................................................................244 Walkthrough ...........................................................................................................................245

Scenario Steps.............................................................................................................................246 Preparing the Windows 2000 Domains ..................................................................................246 Enable Auditing ......................................................................................................................246 Change Domain to Native Mode ............................................................................................248 Install Windows 2000 Support Tools .....................................................................................248 Identifying Services from hb-res.hb-acc.hay-buv.tld not Running Under LSA.....................248 Migrating a Computer Running Windows 2000 Professional ................................................256 Migrating a Service Account ..................................................................................................265 Updating hb-res.hb-acc.hay-buv.tld Service Account User Rights and Group Membership.272 Migrating a Domain Local Group...........................................................................................278 Migrating a Windows 2000 Member Server ..........................................................................285 Migrating a Domain Controller and Decommissioning the Domain hb-res.hb-acc.hay-buv.tld287 Migrating a Global Group.......................................................................................................288 Identifying Services from hb-acc.hay-buv.tld not Running Under LSA................................296 Migrating a Service Account, User Account, and Roaming Profile.......................................301 Updating hb-acc.hay-buv.tld Service Account User Rights and Group Membership............312 Migrating Local Profiles on Computers Running Windows 2000 Professional.....................312 Migrating a Domain Controller and Decommissioning the Domain hb-acc.hay-buv.tld.......313 Performing Migration Tests....................................................................................................313

Summary.....................................................................................................................................314 For More Information .................................................................................................................315

Before You Call for Support...................................................................................................315 Reporting Problems ................................................................................................................315

de 316

Domain Migration Cookbook – Introduction

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.

About the Cookbook

Welcome to the Domain Migration Cookbook.

A cookbook typically is a collection of recipes, or instructions, that explain how to do something

and what you need to do it. This "cookbook" is a set of "recipes" for migration success. It is

designed to help you migrate from Microsoft® Windows NT® 4.0 to Microsoft® Windows® 2000

Active Directory™. It will help you understand the main domain migration concepts and guide you

through the main planning tasks.

The cookbook is divided into two sections:

• Section 1, Migration Concepts. The chapters in this section cover the main migration

concepts and give you an understanding of the underlying technologies that make migration

from Windows NT to Windows 2000 a straightforward task in most situations. At the end of

this section, you will be able to begin migration planning and answer questions such as:

• Should I upgrade or restructure?

• Should I restructure from outside the target Windows 2000 forest, or should I upgrade the

domains into the forest and then restructure?

• Section 2, Migration Scenarios. The chapters in this section contain a detailed

migration scenario involving a fictitious company, Hay Buv Toys. This section starts with a

description of the current Hay Buv domain structure and takes you through processes such as

upgrading domains, cloning groups and users between forests, and restructuring within a

forest.

Note Throughout this cookbook, the term Windows NT refers to Windows NT 3.51 and Windows NT

4.0. The cookbook differentiates between earlier versions only when there are explicit differences.

Who Should Read This

This cookbook addresses the concepts behind migration, the steps that are necessary to plan a

successful migration, and the tools that it requires. Therefore, it will be of use to:

• Network engineers

de 316

• System architects

• Consultants

Prerequisites

Because the focus of the cookbook is on planning an implementation of the Active Directory

namespace through a migration from Windows NT, most of the Active Directory namespace

planning already should have taken place. You might refine this plan in the wake of decisions you

make during the domain migration planning process.

Related Materials

The following documents provide additional information about migration:

• The Windows 2000 Deployment Planning Guide (available at http://www.microsoft.com )

• "Planning Migration from Microsoft Windows NT to Microsoft Windows 2000" white paper

(available at http://www.microsoft.com )

• Designing a Microsoft Windows 2000 Migration Strategy (Microsoft Official Curriculum

course #2010A)

Migration Goals

Your migration goals will affect your migration planning. Those goals might be business related or

migration related.

• Business-related goals in most cases will drive the initial migration decision. These types

of goals are involved when you make implementation choices. You can use them to evaluate

possible trade-offs. Usually you prepare a compliance table, which you will use later to identify

the technologies and product features that you will implement in the final platform.

• Migration-related goals focus on the results of the migration. Concerns about disruption to

production systems, final system performance, mean time between failures, and so on might

influence these goals. The goals can determine how you will formulate test plans and

acceptance criteria.

The primary goal of your migration plan should be to switch to Windows 2000 native mode as soon

as possible to receive the maximum benefit from Windows 2000 technologies.

Business-Related Goals

The following table lists typical business-related goals and the Windows 2000 features that will

support them:

de 316

Goal Feature Benefits

Better manageability Kerberos transitive trusts Transitive or implicit trusts provide trust paths through all domains in a Windows 2000 forest, reducing the need for complex explicit trusts, which are difficult to administer.

Active Directory resource location and administration

Active Directory provides a single, consistent set of interfaces for performing common administrative tasks and locating resources such as printers throughout the enterprise.

Active Directory organizational units (OUs)

OUs allow the domain namespace to be usefully divided to mirror an organization's departmental structure and administrative model. Administrative rights can be delegated at the OU level, removing many of the current drivers for separate resource domains. In addition, OUs can be nested to provide a greater level of granularity.

Active Directory security groups

Windows 2000 provides a richer security group model, with a greater variety of groups with wider scope. Groups can also be nested in Windows 2000. Greater scope of groups and the flexibility afforded by nesting of groups allows for easier administration throughout the enterprise.

Greater scalability 64-bit memory architecture

Windows 2000 Server allows access to up to 32 gigabytes (GB) of memory on 64-bit processors, allowing applications to keep more data in memory for greatly improved performance.

Active Directory scalability Active Directory provides greater levels of scalability, with its ability to store millions of objects. Using Active Directory instead of Security Accounts Manager (SAM) to store user accounts removes the current recommended 40 megabytes (MB) size limit for the account database. This allows larger and fewer domains to be created, reducing the number of

de 316

domains and trusts to manage.

Kerberos authentication This speeds performance by reducing server loads on connection setup.

Microsoft Management Console (MMC)

MMC standardizes the look and feel of the enterprise management tool set, reducing training time and increasing productivity for new administrators.

Improved security Group Policy Group Policy gives administrators fine-grain control over which users have access to specific workstations, data, and applications.

Security Configuration and Analysis

Security Configuration and Analysis is an MMC snap-in that allows object trees (such as registry hives and the file system), together with security policy (such as password policy) to be defined in security configuration templates. This "define once, apply many times" technology allows administrators to define, and then apply, these templates to selected computers in one operation.

Setup Windows 2000 is installed with stronger default security settings, reducing the security configuration overhead as compared to Windows NT systems.

Improved availability Active Directory multimaster replication

Unlike Windows NT, in which the master copy of the security database is kept on the primary domain controller (PDC) and only writable at the PDC, Active Directory uses multimaster replication between domain controllers so that any Windows 2000 domain controller can make changes. This provides for greater availability of the system if a domain controller fails.

All of the goals listed in the previous table require Windows 2000 Server to support them.

Migration-Related Goals

Migration-related goals are not specifically related to technical features of Windows 2000 Server.

de 316

They have implications for the migration process itself. Some migration-related goals are listed in

the following table:

Goal Implications for migration process

Minimum disruption to the production environment

User access to data and resources should be maintained during and after the migration.

User access to applications should be maintained during and after the migration.

The user's familiar environment should be maintained during and after the migration.

Minimum administrative overhead There should be seamless migration of user accounts

Users should maintain their passwords.

Administrators should have to make the minimum number of visits to the workstation.

There should be no requirement to set up new permissions for resources.

Maximize "quick wins" The enterprise should obtain earliest access to key features of the new platform.

System security There should be no impact on security policy, other than improving it.

Conclusion

Your own goals for migration might differ from those listed above, but this does not alter the fact

that you should start any project with goals. Understanding those goals will help you:

• Focus on what your migration needs to achieve.

• Plan your migration, based on which features you need to deploy first, or which migration-

related goals are most important to you.

• Understand the implications of trade-offs you might need to make during your migration if

circumstances change.

This page left blank intentionally.

© 2000 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on

the issues discussed as of the date of publication. Because Microsoft must respond to changing

market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and

de 316

Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,

EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, BackOffice, MS-DOS, Outlook, PivotTable, PowerPoint, Microsoft Press, Visual Basic,

Windows, Windows NT, and the Office logo are either registered trademarks or trademarks of

Microsoft in the United States and/or other countries.

de 316

Domain Migration Cookbook - Chapter 1: Security

Section 1:

Migration Concepts

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.

Introduction

Security is very relevant to domain migration.

Migration, when you use the term in its restructuring sense, involves copying or moving security

principals such as users or security groups from one domain to another. In-place upgrade does not

move users. In the Microsoft® Windows NT® security model, these security principals are identified

by security identifiers (SIDs). Access to resources in Windows NT is granted or denied on the basis of

these SIDs. Because SIDs are domain specific, they must be changed as a result of migration.

This chapter explains security as it relates to domain migration. It covers the following:

• Authentication and authorization. Taking a high-level look at the Windows NT

authentication and authorization model will help you understand the relevance of SIDs.

• SIDHistory. Microsoft® Windows® 2000 security principals in Active Directory™ have an

attribute that preserves old SIDs in cross-domain moves and makes migration much simpler.

Authentication and Authorization

Security Identifiers

The Windows NT security model identifies account objects such as users, groups, machines, and

domain trusts by SIDs. SIDs are domain-unique values, built when the user or group is created, or

when the machine or trust is registered with the domain.

The components of a SID follow a hierarchical convention: A SID contains parts that identify the

revision number, the authority—such as the domain—that issued the SID, and a variable number of

subauthority or relative identifier (RID) values that uniquely identify the security principal relative to

the issuing authority.

Although there are well-known SIDs that identify generic groups and users across all systems, the

majority of security principals that you will focus on are identified in the context of a domain, and thus

they cannot be moved between domains without their SIDs changing.

Authentication and Access Tokens

de 316

An essential component of the Windows NT security model is authentication, where a user is identified

to the domain by presentation of credentials, usually in the form of a user name and password.

Assuming these credentials are acceptable, the system creates an access token for the user containing

the SID of the user (the primary SID), and the SIDs of all the domain groups the user is a member of.

Every process the user creates, for example by running an application, carries the user's access token.

The system uses this access token to determine whether to grant the user access to system

resources.

Authorization and Security Descriptors

The counterpart of the user's access token is the security descriptor attached to resources such as

files or printers. A security descriptor contains a discretionary access control list (DACL), which

consists of a list of access control entries (ACEs). Each ACE consists of a SID, together with an

indicator that the security principal that the SID identifies is granted or denied some sort of access to

the resource.

As a result, the effect of upgrade or restructure on SIDs is of crucial importance.

Authorization and Upgrade

Domain upgrade is the process of upgrading the software on the primary domain controller (PDC) of a

domain, and upgrading some or all of the backup domain controllers (BDCs), from Windows NT to

Windows 2000 Server.

In an upgrade, security principals remain in the same domain they were created in, and so the SIDs

identifying them remain unchanged. As a result, upgrade does not affect resource access.

A subsequent chapter will explain upgrade in detail.

Authorization and Restructure

Domain restructure is a process that allows you to redesign your Windows 2000 forest according to

the needs of your organization. Although restructure can result in any number of different outcomes,

typically the result is some rationalization of the current structure, and perhaps a move to fewer

larger domains.

Changing structure implies copying or moving objects from one domain (the source domain) to

another (the target domain). Because of the domain relative nature of SIDs, copying or moving

objects implies that the new object in the target domain will have a new SID relative to that domain.

A number of third-party directory management tools have long provided domain-restructuring support

for Windows NT 4.0. These tools have handled the SID change issue by providing components to

search out all references to the security principal's former SID in ACLs all over the enterprise, and

de 316

either replace it with the new SID or add a reference to the new SID. This is one approach to the

problem, and in some instances it may still be necessary, but in many instances Windows 2000 makes

repermissioning unnecessary by virtue of an Active Directory attribute called sIDHistory.

SIDHistory

In Windows 2000, the domain restructuring is made considerably easier as a result of a new attribute

on Windows 2000 Active Directory security principles called sIDHistory.

SIDHistory is used to store the former SIDs of moved objects such as users and security groups.

When a user or group is moved using new Microsoft® Win32® application programming interfaces

(APIs), or tools and support utilities provided by Microsoft or independent software vendors and built

on top of them, the sIDHistory attribute of the object representing it in Active Directory is updated

with its former SID as part of the operation. When the user then logs on to the system, not only the

new SID but also the old SID retrieved from the sIDHistory attribute are added to the user's access

token and used to determine the user's group memberships. The SIDs of the groups in which the user

is a member through either the new SID or the old SID then also are added to the access token,

together with any sIDHistory those groups might have.

Because groups can be moved, they can also have sIDHistory, and the system also retrieves the

sIDHistory attributes of all the groups the user is a member of and adds these to the user's access

token.

These sIDHistory entries in the token look to the system like normal group memberships during

authorization checks, so they can grant appropriate access even on down-level systems that know

nothing about Windows 2000 or Active Directory.

Note The sIDHistory attribute can only be updated in native mode Windows 2000 domains, which has

the effect of requiring all migration operations relying on sIDHistory to have a native mode target for

restructure.

de 316

If your browser does not support inline frames, click here to view on a separate page.

Figure 1.1 Resource access granted through sIDHistory

Security Implications of SIDHistory

The ability to take a SID from one security principal and add it to the sIDHistory of another is

sensitive from a security perspective. As a result, the ability to manipulate sIDHistory is constrained in

a number of ways. The principal one requires the SID to be unique in a Windows 2000 forest—that is,

it can only exist once in the target forest whether that is as a primary SID or in the sIDHistory of any

object.

As a result, sIDHistory is available in two migration scenarios:

• Moving security principals between domains in the same forest. In this case, moving the

object, destroying the source object, and adding it to the sIDHistory of the target object ensures

de 316

SID uniqueness. This is referred to as an "intra-forest migration" because it occurs between

domains in the same forest.

• "Cloning" security principals between domains in different forests. In this instance, because

the source object still exists, the operation can only take place between separate forests. This is

referred to as an "inter-forest migration." Because Windows NT domains cannot be part of a

Windows 2000 forest, this type of migration is available to down-level source domains as well as

Windows 2000 ones.



the issues discussed as of the date of publication. Because Microsoft must respond to changing market

conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft

cannot guarantee the accuracy of any information presented after the date of publication.


EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, BackOffice, MS-DOS, Outlook, PivotTable, PowerPoint, Microsoft Press, Visual Basic,

Windows, Windows NT, and the Office logo are either registered trademarks or trademarks of

Microsoft in the United States and/or other countries.

de 316

Domain Migration Cookbook - Chapter 2: Domain Upgrade

Section 1:

Migration Concepts



be inferred.

Introduction

Upgrading to Microsoft® Windows® 2000 Server is the easiest, least-risky migration route from

Microsoft® Windows NT® 4.0 to Windows 2000 and Active Directory™ because it retains most of

the system settings, preferences, and program installations.

Domain upgrade is the process of upgrading the software on the primary domain controller (PDC) of

a domain, and upgrading some or all of the backup domain controllers (BDCs), from Windows NT to

Windows 2000 Server.

Because Windows 2000 is designed to support mixed networks containing Windows 9x, Windows NT,

and Windows 2000 with full interoperability, you do not need to upgrade all systems in the domain

to take advantage of the features in Windows 2000. Even so, you should consider an upgrade of the

PDC as only the first stage of the upgrade because you can obtain further incremental benefits by

subsequently upgrading BDCs and then member servers.

Because this is an upgrade of an operating system rather than a fresh installation, it maintains the

existing domain structure, users, or groups. In fact, the biggest distinction between an upgrade and

a restructure is that upgrading maintains the existing domain structure. In the process, however,

the upgrade will enable new Windows 2000 features.

After you complete the upgrade and have access to advanced Windows 2000 management tools and

features, you might want to restructure the domains. Be aware that restructuring is not a trivial task

and will require additional planning and implementation. (This is discussed in later chapters on

restructuring.)

If structural change is one of your main goals for migration, you might consider restructuring during

the migration.

Implications of Domain Upgrade

An upgrade is the easiest, least-risky migration. This section looks at the actual effects of the

de 316

upgrade on domain controllers and security principals, and explains the importance of these in

making your planning decisions.

The Active Directory Installation Wizard (dcpromo.exe)

It is good practice to sync all BDCs with the PDC before starting the upgrade.

After the installation of the core operating system on the PDC, the setup program detects the

upgrade of a domain controller and prompts the administrator to install Active Directory on the

server by automatically running the Active Directory Installation Wizard.

The Active Directory Installation Wizard gives the administrator the option of creating the first tree

in a new forest, creating a new tree in an existing forest, creating a replica of an existing domain, or

installing a child domain. The choice you make will depend on the outcome of the namespace

planning process.

Note This is not intended as a detailed description of the process. You also will need to consider

activities such as backing up the domain in case you encounter serious problems and need to fall

back. You might choose to add an additional BDC to the domain prior to the synchronization and

upgrade, and then to take this BDC offline for the duration of the upgrade. See section 2 of the

cookbook for a detailed walkthrough of a domain upgrade.

Windows NT PDC

The Active Directory installation process copies the contents of the Windows NT account database

and the Security Accounts Manager (SAM) into Active Directory. These objects are the security

principals (user accounts, local and global groups, and computer accounts).

As soon as the process upgrades the PDC and installs Active Directory, the domain is running in

Windows 2000 mixed mode. (For a fuller description, see the section "Mixed Mode and Native Mode"

below.) The former PDC now holds the role of the PDC operations master in the Active Directory

domain.

From this point on, the Windows 2000 Server PDC operations master uses Active Directory to store

objects. It is fully backward compatible because it exposes the data as a flat store to Windows NT

BDCs during replication. This manifests itself in a number of ways:

• The PDC operations master appears as a Windows 2000 domain controller to other

computers running Windows 2000 and as a Windows NT PDC to computers that are not yet

upgraded.

• You can still use the PDC operations master to create new security principals and to

de 316

replicate these changes to the Windows NT Server BDCs.

• Windows NT and Windows 9x workstations can use the PDC operations master as a possible

logon server.

• If the Windows 2000 Server PDC operations master goes offline or otherwise becomes

unavailable and no other Windows 2000 domain controllers exist in the domain, then you can

promote a Windows NT BDC to PDC.

The Effect of Upgrade on Trusts


Figure 2.1 The HAYBUV.TLD domain example

In Windows NT, scaling security beyond one domain is done via the mechanism of trust.

Interdomain trusts allow domains to authenticate users on behalf of domains that trust them. Prior

to the availability of Windows 2000, trusts were explicit and one way—if Domain A trusts Domain B,

which in turn trusts Domain C, there is no trust from Domain B to Domain A, or between Domain A

and Domain C unless explicitly created.

Active Directory Installation Wizard installs the Kerberos software. Once this process is complete, it

starts the authentication service and the ticket-granting service. If the administrator opted to join an

existing tree, this establishes a two-way transitive Kerberos trust relationship to the parent domain.

de 316

Any trust relationships created before the PDC upgrade will still exist, but these will take the form of

explicit, one-way Windows NT–style trusts.

Eventually, the domain controller from the parent domain copies all schema and configuration

information to the new child domain. Once this information has been replicated, the upgraded

domain is a fully functional member of the Active Directory domain tree, although it remains in

mixed mode until the administrator decides to switch the domain into Windows 2000 native mode.

Active Directory-aware clients such as workstations running Windows 2000 Professional or Windows

9x (running Active Directory client software) can now make use of Active Directory and perform

actions such as querying global catalogs to locate resources and people. Clients also will be able to

use the transitive trust relationships that exist within the forest to access resources throughout that

forest. The way they achieve this will depend on whether the client is running Windows 2000 or

earlier operating systems such as Windows NT or Windows 9x, and the upgrade state of the target

domain.

Resources will be accessible across the forest via transitive trusts where the resources reside in any

of the following:

• Native mode domains

• Mixed mode domains where all of the domain controllers have been upgraded

• Mixed mode domains where the domain controller servicing the Kerberos or Windows NT

LAN Manager (NTLM) authentication request has been upgraded

In all other cases, clients will have access only to those resources that are available through existing

Windows NT–style, one-way explicit trusts, which remain unchanged as a result of the upgrade.

Figure 2.1 (above) illustrates how NTLM and Kerberos authentication work.

Using NTLM Authentication

Imagine a user logging on to the domain haybuv-acct.haybuv.tld, which is a mixed mode domain,

from the Windows NT Workstation ntws, which is in the same domain. The user then tries to make a

network connection to a Windows NT Server computer, nts, in the domain haybuv-other.haybuv.tld,

which is a native mode Windows 2000 domain. Because ntws is a Windows NT client, it will use the

NTLM protocol.

Nts will receive credentials that specify the domain name haybuv-acct.haybuv.tld, and will determine

that the domain name does not refer to its own account database. Then it will send the logon

request to a domain controller in its own domain for authentication.

de 316

The domain controller checks the domain name, and because it doesn't match, the domain controller

checks to see whether the domain is a trusted one. The domains haybuv-acct.haybuv.tld and

haybuv-other.haybuv.tld are both children of the same root— haybuv.tld—so transitive trust exists

between the two domains, and the domain controller passes the logon request through to a domain

controller in the trusted domain.

That domain controller authenticates the username and password against its domain account

database, and assuming the credentials match, passes the account-identification information back to

the domain controller that contacted it, which in turn sends it back to the server.

Next, the server creates an impersonation token for the user, containing the user's security identifier

(SID) and the SIDs of any domain groups the user is a member of. It then creates an impersonation

thread in the user's security context, bearing the impersonation token, and attempts to access the

resource on the user's behalf.

From this you can see that an earlier version client in a mixed mode domain can access an earlier

version server in another domain in the tree using NTLM, as long as the domain controller in the

target domain is running Windows 2000 and thus understands transitive trusts. Because all trees in

the same forest are linked by transitive trusts, the same would be true even if the two domains were

in different trees.

By extension, it follows that if you are trying to access a resource on the Windows NT Server

computer nts in the mixed mode domain haybuv-res1.haybuv-other.haybuv.tld, the resource would

be accessible via transitive trust across the forest as long as Windows 2000 is running on the

domain controller to which the server passed the logon request.

Using Kerberos Authentication

Now imagine a user logging on to the domain haybuv-acct.haybuv.tld as before, but this time from

the computer w2kpro in the same domain, which is running Windows 2000. The user wants to make

a network connection to a Windows 2000 Server computer, w2ksrv, in the haybuv-other.haybuv.tld

domain. Because w2kpro is a Windows 2000 client, it will attempt to use the Kerberos protocol.

Kerberos is a ticket-based protocol, where users are issued ticket granting tickets (TGTs) by the

ticket-granting service on the Key Distribution Center (KDC) running on the Windows 2000 domain

controller, at initial logon to the domain.

TGTs contain authentication information about the user encrypted with the domain master key,

which then can be presented back to the domain controller as part of requests for additional session

tickets to connect to other servers in the domain. Once the user has been granted a TGT,

de 316

subsequent checks are quick and efficient, since the domain controller merely needs to decrypt the

TGT to check the user's credentials. Session tickets are similar to TGTs, but are encrypted using a

key shared between the server and the domain controller.

The Kerberos protocol, like NTLM, can operate across domain boundaries. A client in one domain can

authenticate to a server in another if the two domains have established a trust relationship. When

domains establish trust, they exchange interdomain keys. Each domain's authentication service uses

its interdomain key to encrypt tickets to the other domain's ticket-granting service.

When a client wants access to a server in a remote domain, it asks the domain controller in its home

domain for a referral ticket, a TGT that it can present to the ticket-granting service at the remote

domain's domain controller. The local domain controller replies by sending the client a TGT

encrypted with the remote domain controller's interdomain key.

The client presents the referral TGT to the remote domain controller's ticket-granting service, asking

for a ticket to a server in its domain. The remote domain controller decrypts the client's TGT with its

interdomain key. If decryption is successful, the remote domain controller can be certain that a

trusted authority issued the TGT, and so it grants the client a ticket to the requested server.

In Figure 2.1, because haybuv-acct.haybuv.tld and haybuv-other.haybuv.tld are children of the

same root, and transitive trust exists between the two domains, a trust path can be built between

the domains. On receiving the referral TGT, the domain controller in the target domain will check to

see if it has a shared key for the server in question, and if it does it will issue a session ticket to the

client. Because the computer w2ksrv runs Windows 2000, a shared key will exist, so a ticket can be

issued to w2kpro.

The important factors in this scenario are the existence of a domain controller in the target domain

running the Kerberos ticket-granting service, and the existence of a shared key between the domain

controller and the server. The Active Directory installation process installs the Kerberos service on

Windows 2000 domain controllers, and adding a member server to a Windows 2000 domain involves

the creation of a shared key. From this it follows that w2kpro would be able to access

w2ksrv.haybuv-res1.haybuv-other.haybuv.tld using the Kerberos protocol as long as a Windows

2000 domain controller is available to issue the session ticket.

If w2kpro was attempting to access a resource on a computer running Windows NT such as

nts.haybuv-res1.haybuv-other.haybuv.tld, Kerberos authentication would fail and the client would

fall back to attempting NTLM authentication as described in the previous section.

Switching to Native Mode

de 316

The previous discussion shows that in some circumstances trust paths might be unpredictable where

mixed mode domains are involved. Switching your domains to native mode removes this

unpredictability.

Upgrade and Resource Domains

A resource domain is a special type of domain created to hold the accounts of resources such as

servers and workstations. Resource domains were created in Windows NT typically to address two

main situations:

• SAM size limitation. In Windows NT, the maximum size recommended for the SAM

account database is 40 megabytes (MBs). In an organization with many deployed workstations

and servers and many security groups, this might equate to much less than the sometimes-

quoted figure of 40,000 accounts. In order to scale an organization beyond this number, you

should store user and machine accounts in separate domains, termed an account or master

domain for the user account and a resource domain for the machine account.

Resource domains normally would be created as second-tier domains, with one-way trusts—a

trusting relationship–—to either a single account domain (this topology is called the master

domain model), or a number of account domains (the multimaster domain model).

• Local administrative capability. In a decentralized organization with geographically

disparate facilities, it is often desirable to authorize local personnel to administer resources. In

order to devolve this kind of responsibility in Windows NT, you can create resource domains

with their own administrative structure. As in the above case, this would result in master or

multimaster domain structures with one-way trusts to the account domains in the organization.

The one-way nature of these trusts ensures that the resource domain administrators, by

default, only have administrative scope over the resource domain.

When considering the effects of an upgrade on a resource domain, try to ascertain which of the

previous two rationales was foremost in the designer's mind when the domain structure was

determined. If the designer created the domain to address the latter situation, you will want to

consider the implications of upgrading a resource domain on your administrative model because

simply upgrading the resource domain and joining a forest will result in the creation of a two-way

transitive trust between the child resource domain and the parent domain.

If the local administrators are less skilled, or you do not intend to grant them wider administrative

rights in the Windows 2000 forest, you will want to consider the following options:

de 316

• Upgrading the domain within the forest and using Windows 2000 delegation

features. Check the administrative groups in the resource domain and remove those who are

not administrators in the master domains. If you have only local resource domain

administrators, add one or more of your master domain administrators. They will be able to

administer the domain while it is being upgraded. As a further precaution you should ensure

that the resource domain administrators do not have administrative access to the domain

controllers through local computer accounts.

Once you upgrade the PDC, you could organize the resources you want to administer locally into

organizational units (OUs), and delegate administration of the OU to your former local

administrators.

• Upgrading the domain in a new forest. You could choose to upgrade your resource

domain as a new tree in a new forest and maintain the link to the account domain by way of the

preexisting explicit trust to the account domain, which like a Windows NT explicit trust is

unidirectional and not transitive. This would effectively mirror the preupgrade structure.

In general, you will want to minimize the number of forests you create, so you should consider

this option only as a temporary measure, prior to a restructure, or as a last resort.

• Restructuring into OUs. Another alternative might be to rethink your domain structure

and consider merging your resource domains into the upgraded master domain as OUs at a

later time. This would obviously influence your thinking on the order of domain upgrade.

Upgrade and Administration

Once you upgrade the PDC to Windows 2000 Server and install Active Directory, the administrator

can start using the new tools that come with Windows 2000 Server to create new objects such as

OUs that exist only in Active Directory.

If you create OUs, you can begin organizing your domain by placing objects into them. This

structure is visible only to computers with Active Directory client software. Without it, the domain

appears unchanged and the PDC still exposes objects as a flat store to earlier version clients.

An administrator working at a client without Active Directory can use only older administration tools.

Mixed Mode and Native Mode

de 316

Figure 2.2 Stages of Upgrade

Mixed Mode

From the moment you upgrade the PDC to the time the administrator decides to switch the domain

into Windows 2000 native mode, the domain is in mixed mode. Mixed mode provides maximum

backwards compatibility with earlier versions of the operating system.

Mixed mode relates only to the authentication infrastructure of a domain—in other words, the

domain controllers. Even when a domain has only Windows 2000 domain controllers and has been

switched to native mode, clients and servers running earlier versions of Windows NT, and clients

running Windows 9x, can exist within the domain. This environment is known as a mixed

environment.

You can leave the domain operating in mixed mode indefinitely, even if you have upgraded all the

BDCs in the domain as well as the PDC.

The table below summarizes the Windows 2000 features available in mixed mode and those

available only by switching to native mode. If you are hesitant to switch to native mode, determine

whether staying in mixed mode compromises your migration goals and whether there are acceptable

trade-offs.

In general, the only reasons to remain in mixed mode are:

• Inability to upgrade BDCs. In this scenario, you cannot upgrade or demote BDCs to

member servers for some reason. This might be because the hardware is limited and certain

BDCs are not physically capable of being upgraded or because you have applications that must

run on a BDC that will not run on Windows 2000.

• Inadequate physical security of BDCs. In any discussion of domain planning, security is

an important consideration. A fundamental aspect of security is the physical security of the

computer itself: Any computer that is physically easy to access is vulnerable to attack. A

consideration here could be the difference between single-master updating of the SAM by the

PDC alone, and Active Directory multimaster updating of the account database by all domain

de 316

controllers.

Because of the single-master nature of Windows NT directory updates, you might be

comfortable with comparatively relaxed security on your BDCs. If this is the case, you need to

reconsider this when upgrading them to Windows 2000 domain controllers. If you cannot

upgrade security of your BDC appropriately, you might consider demoting the BDC to a member

server during the upgrade, adding a new Windows 2000 domain controller in a different

location, or possibly even reconsidering your proposed domain structure.

• A need to fall back to Windows NT. One of the features of mixed mode is the degree of

backward compatibility. Mixed mode has the benefit of allowing you to add new Windows NT

BDCs to the domain if a problem arises. In this situation, once you add the BDC to the domain,

you could force a resynchronization of the account database. Then, as long as no Windows 2000

domain controllers are in the domain, you could promote the BDC to PDC. You should plan for

fallback or recovery, but at some point you will want to switch over completely to the new

environment.

Native Mode

Once you upgrade all domain controllers, you can switch the domain from mixed mode to native

mode. Several things happen during the switch:

• The domain uses only Active Directory multimaster replication between domain controllers,

so support for Netlogon replication ceases.

• Because Netlogon replication is now switched off, you can no longer add new Windows NT

BDCs to the domain.

• Because multimaster replication is enabled, the former PDC is no longer the master of the

domain, and all domain controllers can now perform directory updates. One point that

sometimes causes confusion is the continued existence of the PDC emulator role. Despite the

multimaster nature of Active Directory, Windows 2000 has a number of roles designated as

operations masters, and PDC emulator is an operations master role. Usually, the former PDC

will continue as PDC emulator operations master holder, which in a native mode environment

means that other domain controllers replicate password changes to it preferentially.

• Windows 2000 group types such as universal and domain local groups, and group nesting,

are enabled.

Running Active Directory Installation Wizard does not automatically perform the switch to native

mode; the administrator must initiate the change via the administrative interface.

de 316

Although you can get a great deal of benefit from upgrading your PDC and BDCs and remaining in

mixed mode, you should make the switch to native mode as soon as possible. Here are some of the

reasons:

• Richer security group model. Universal groups, domain local groups, and group nesting

are available only in native mode.

• Predictable trust paths in the forest. In native mode, all domain controllers must be

running Windows 2000 and are thus capable of understanding transitive trusts. See "The Effect

of Upgrade on Trusts" (above) for more detail.

• Removal of SAM size restrictions. Because all domain controllers must be running

Windows 2000 in a native mode domain, you can safely allow your directory to grow above the

size recommendations for Windows NT without the possibility of Windows NT BDCs being added

to the domain.

Switching to Native Mode

Changing the domain mode from mixed to native mode is easy to do but impossible to undo, so you

need to bear in mind all of the factors discussed above to determine when to make the change. Do

not change domain mode if you have or will have any Windows NT domain controllers.

Figure 2.3 Change domain mode dialog

de 316

To change the domain mode, do the following:

1. Open the Active Directory Domains and Trusts snap-in and right-click on the domain you want to administer in the left-hand tree view pane. A context menu will appear.

2. Choose Properties to show a tabbed dialog box, as shown in Figure 2.3.

3. On the General tab, click Change Mode.

Features Available in Mixed Mode

Availability of Windows 2000 Features in Mixed Mode

Goal Feature Available in mixed mode?

Better manageability Kerberos transitive trusts Yes, but see the section "The Effect of Upgrade on Trusts" (above).

Active Directory Yes

Active Directory organizational units (OUs)

Yes, but only visible using Windows 2000 administration tools. Cannot be administered from Windows NT BDCs or member servers

New Active Directory security groups

No, only global and local groups available

Windows installer through group policies

Yes

Greater scalability 64-bit memory architecture Yes

Active Directory scalability Yes, but only once all BDCs have been upgraded and are running the Active Directory. Be wary of taking advantage of this feature because you still can add new Windows NT BDCs while the domain is in mixed mode. This feature might be an important part of your fallback planning, so you should not compromise it.

Kerberos authentication Yes, for computers running Windows 2000

Microsoft Management Console (MMC)

Yes

Improved security Group policy Yes, for domain controllers and other computers running Windows 2000 in the domain

Security Configuration Manager (SCM)

Yes

Improved availability Active Directory multimaster replication

Yes, between PDC and BDCs that have been upgraded

de 316

Windows 2000 Groups

The previous section mentioned new and richer security group functionality in Windows 2000.

Windows 2000 supports four types of security groups:

• Local

• Domain local

• Global

• Universal

Local Groups

Local groups have always existed in Windows NT. They can have members from anywhere in the

forest, other trusted forests, and trusted earlier version domains. In terms of resource permission,

however, they have only computer-wide scope, in that you can only use them to grant permissions

on the computer on which they exist.

A special case for local groups in earlier versions of Windows NT is related to the local groups

created on a PDC, which by virtue of replication of the domain SAM amongst BDCs, resulted in the

PDC and BDCs sharing these groups. In mixed mode, local groups behave in the same way on

Windows NT and Windows 2000; in native mode, local groups on a domain controller become

domain local groups (described next).

Typically, local groups are used to grant ad-hoc access to resources on a local computer.

Domain Local Groups

Domain local groups are a new feature of Windows 2000, though similar in concept and use to the

local groups created on the PDC in a Windows NT domain (described above).

Domain local groups are available only in native mode domains. They can have members from

anywhere in the forest, other trusted forests, and even trusted earlier version domains. Domain

local groups have only domain-wide scope in terms of resource permission, so you can only use

them to grant permissions within the domain in which they exist. They differ from local groups in

that you can use them on any computer running Windows NT within the domain in which they were

created.

Typically, domain local groups are used to gather security principals from across the forest to control

access to resources in the domain.

de 316

Global Groups

Windows 2000 global groups are effectively the same as Windows NT global groups. In terms of

membership, they have domain-wide scope, but can be granted permissions in any domain, even in

other forests and earlier version domains as long as a trust relationship exists.

Universal Groups

Universal groups can contain members from any Windows 2000 domain in the forest, but cannot

contain members from outside the forest.

You can grant universal groups permissions in any domain, even in other forests, as long as a trust

relationship exists.

Although universal groups can have members from mixed mode domains in the same forest, the

universal group will not be added to the access token of these members because universal groups

are not available in mixed mode.

You can add users to a universal group, but it is recommended that you restrict universal group

membership to global groups.

Universal groups are available only in native mode domains.

Use of Universal Groups

Universal groups have a number of important characteristics. You can use universal groups to build

groups that perform a common function within an enterprise. One example might be virtual teams.

The membership of such teams in a large company would probably be nationwide or even

worldwide, and almost certainly forest-wide, with the team resources being similarly distributed.

Universal groups could be used as a container in these circumstances to hold global groups from

each subsidiary or department, with a single access control entry (ACE) for the universal group to

protect the team resources.

In using universal groups, an important factor to consider is that while global and domain local

groups are listed in the global catalog (GC), their members are not, whereas universal groups and

their members are listed, a fact that has implications for GC replication traffic. Exercise care in the

use of universal groups. As a guide, if your entire network has high-speed connectivity, you can

simply use universal groups for all of your groups and benefit from not having to bother with

managing global groups and domain local groups. If, however, your network spans wide area

networks (WANs), you can improve performance in several ways by using global groups and domain

local groups.

de 316

If you use global groups and domain local groups, you can also designate any widely used groups

that are seldom changed as universal groups.

Universal Groups and Access Tokens

The previous discussion of universal group membership touched on the fact that universal groups

can contain members from mixed mode domains, but that such members will not have the universal

group's SID in their access token. This is a consequence of the way access tokens are created in

Windows 2000.

When a user logs on to a Windows 2000 native mode domain and has been authenticated, the Local

Security Authority (LSA) on the domain controller where the user was authenticated retrieves the

user's global group memberships. The LSA then passes this information down to the workstation,

where it is used to build the user's access token. At the same time, the LSA queries the GC for the

user's universal group memberships, which it also passes to the workstation.

If a user is a member of a universal group, the SID of that group is included in the access token on

the workstation, and is added to the authorization data in the TGT issued by the KDC.

Universal groups are not added to access tokens at any other time—for example, when

impersonation tokens are created at member servers. As a consequence, if the universal group SID

is not available when the user logs on—for example, where the user is logging on to a mixed mode

domain—it will not be added subsequently.

Nesting Groups

It is recommended that you do not create groups with more than 5,000 members. This guideline is

based on the fact that updates to the Active Directory store have to be capable of being made in a

single transaction. Because group memberships are stored in a single multivalue attribute, a change

to the membership would result in the whole attribute—in other words, the whole membership list—

having to be updated in a single transaction. Microsoft has tested and supports group memberships

of up to 5,000 members.

You can get around this limitation by nesting groups to increase the effective number of members. A

further consequence is that you also reduce the replication traffic caused by replication of group

membership changes.

Your nesting options depend on whether the domain is in native mode or mixed mode. The following

list describes what can be contained in a group that exists in a native mode domain. These rules are

determined by the scope of the group.

de 316

• Universal groups can contain user accounts, computer accounts, other universal groups,

and global groups from any domain.

• Global groups can contain user accounts from the same domain and other global groups

from the same domain.

• Domain local groups can contain user accounts, universal groups, and global groups from

any domain. They also can contain other domain local groups from within the same domain.

This list describes what security groups in a mixed mode domain can contain:

• Local groups can contain global groups and user accounts from trusted domains.

• Global groups can contain only user accounts.

Multimaster Replication and Group Administration

Because group memberships are stored in a single attribute, you should exercise special care when

adding and removing members where you have a number of users with administrative rights in the

domain. The reason for this relates to replication latency and conflict resolution in Active Directory.

If you have two administrators making changes to the same group on different directory replicas at

the same time, you could have a situation where, for instance, administrator A makes changes to

group A, removing user A and adding user B, while administrator B is making changes to the same

group, this time adding user C. The outcome of these simultaneous operations would depend on

Active Directory conflict resolution, which takes the last update as authoritative.

To avoid this situation, you should consider delegating administration of specific groups to specific

administrators.

Effects of Upgrade on Groups

Upgrading a PDC to Windows 2000 has no immediate effect on groups. Windows NT local groups

become Windows 2000 local groups and Windows NT global groups become Windows 2000 global

groups. The real change occurs when the domain is switched to native mode, at which point local

groups on the PDC become domain local groups.

As stated earlier, when a user has been authenticated, an access token is created for the user

containing the user's primary SID, together with the SIDs of any groups the user belong to. Local

groups on the PDC are a special case in Windows NT. This is reflected in the way the access token

looks when it is created after interactive logon on the workstation of a user who is a member of such

a group, or when it is created at a domain controller for the purpose of impersonating that user to

grant access to resources. Because the PDC local groups have no scope beyond the domain's PDC

de 316

and BDCs, the user's access token on the workstation does not contain the SID for that group. When

the user attempts to access resources on a domain controller, however, the impersonation token

created for the user at the domain controller does contain the SIDs of any of the PDC local groups to

which the user belongs.

When the domain is switched to native mode, the SIDs of any domain local groups of which the user

is a member are added to the user's access token, even when the user is logging on interactively at

a workstation. This is because domain local groups have domain-wide scope.

Groups and Domain Mode

Group type Membership Scope Available in mixed mode?

Local Members from: Same forest Other trusted forests Trusted earlier version domains

Machinewide Yes

Global Members from the local domain

Any trusted domain Yes

Domain local Members from: Same forest Other trusted forests Trusted earlier version domains

The local domain No

Universal Members from the same forest

Any trusted native mode domain

No

NetBIOS and WINS in Windows 2000

Network basic input/output system (NetBIOS) is a high-level network-programming interface used in

Microsoft networking components from the late 1980s onwards. Network resources are identified in

the NetBIOS namespace by unique NetBIOS names. Windows Internet Name Service (WINS) is a

service supplied as part of Windows NT Server to support registration of dynamic mappings of

NetBIOS names to Internet Protocol (IP) addresses, and to provide NetBIOS name resolution.

With the release of Windows 2000, support for the NetBIOS naming interface is no longer required

for networking computers. This, along with the tight coupling of the Active Directory and Domain

Name System (DNS), will result in a decline in the use of NetBIOS over time. In the meantime,

upgrading your domain to Windows 2000 does not dispense with the need for NetBIOS support on

your network or affect the degree of support you currently have.

After upgrading, you can discontinue the use of NetBIOS and WINS if the following conditions are

de 316

met:

• No clients such as Windows for Workgroups, Windows 9x, or Windows NT 4.0, and no

servers running Windows NT 4.0 use NetBIOS. NetBIOS names can still be required on your

network to provide basic file and print services and support for many legacy applications used

on client computers running under earlier versions of Windows operating systems.

• You have assessed the impact of earlier applications and services in your testing plan.

• You have a pure Windows 2000 network and are sure that all computers and applications

on your network are able to function using another naming service such as DNS. Network

naming is a vital service for locating computers and resources throughout your network, even

where NetBIOS names are not required.

• You only have a single Windows 2000 forest or you do not need trust between multiple

forests. Trusts between multiple Windows 2000 forests can only be established as explicit LAN

Manager trusts. This type of trust still requires NetBIOS.

The Windows 2000 WINS client caches resolved names locally. It uses a component called the

Caching Resolver to look in this cache before submitting a query to DNS. The host file is cached as

soon as the client starts and any updates to the host file are reflected in the cache immediately. The

name resolution sequence is as follows:

1. Attempt name resolution from the client cache.

2. If resolution from the client cache fails, the client attempts name resolution through DNS.

3. If DNS name resolution fails, the client attempts resolution through WINS.

As a result, assuming that you have implemented sufficient change control over your new clients as

you have upgraded them, and once all earlier conditions have been removed, the switch away from

NetBIOS and WINS should be seamless.

Availability of LAN Manager Replication Service

Windows NT Server provided a replication facility known as LAN Manager Replication (LMRepl).

LMRepl often is used to replicate logon scripts from an exporting domain controller to a number of

importing domain controllers in the domain. The File Replication service (FRS) replaces this service

in Windows 2000 Server.

Windows 2000 Server does not support LMRepl in mixed or native mode, so if you have been using

LMRepl, you will need to include in your upgrade plan a strategy for using FRS to provide the same

functionality.

The LMRepl Process

de 316

LMRepl uses the concept of import directories and export directories. An administrator can configure

LMRepl by selecting a server on which to host an export directory and a number of servers to host

import directories. The servers hosting the directories do not need to be domain controllers; they

can be ordinary member servers.

Figure 2.4 The LMRepl process

The FRS Process

FRS in Windows 2000 Server is automatically configured so that every domain controller has a

replicated System Volume (SYSVOL). Any change you make to a logon script stored in the SYSVOL

of any domain controller is replicated in multimaster fashion to other domain controllers. Unlike

LMRepl and the hosting of import and export directories, in FRS only domain controllers can host the

SYSVOL.

de 316

Figure 2.5 The FRS process

Maintaining LMRepl Services in a Mixed Environment

As you now have learned, during an upgrade you can have a mixed environment of Windows NT 4.0

BDCs and servers operating with Windows 2000 domain controllers. Because Windows 2000 Server

does not support LMRepl, maintaining LMRepl services in a mixed environment could be an issue. To

provide this support, you will need to create a bridge between LMRepl and FRS so both services can

operate. You could do this by selecting a Windows 2000 domain controller whose SYSVOL would be

used to populate the export directory of the Windows NT BDC hosting LMRepl. A sample script,

which you can regularly schedule to perform the necessary file copying, is available from Microsoft.

LMRepl and Upgrade

In order to maintain availability of LMRepl during an upgrade, you should ensure that the server

hosting the export directory is upgraded only after all the other servers hosting import directories

have been upgraded. If the server hosting the export directory is the PDC, you should select a new

export server and reconfigure LMRepl.

Using Remote Access Service in a Mixed Environment

If you are using Remote Access Service (RAS) to provide your users with remote access to the

corporate network, you might want to consider upgrading your RAS server early on in the process of

upgrading member servers. This is because Windows NT checks RAS properties such as availability

of RAS access or dial-back for a user.

RAS is an example of a Windows NT service. A service is a type of background process, designed to

run continuously with no user interface, usually fulfilling some kind of server function such as a Web

server or a File Transfer Protocol (FTP) server. Because the service must run even when no users

are logged on to the system, it runs in the security context of a special service account, usually the

system account, also known as LocalSystem.

The system account is a special account known only to the local machine, and is granted all

privileges available on the operating system. When a service logs on as LocalSystem, it logs on with

NULL credentials. In other words, it does not provide a username or password. This means that this

account cannot be used to access network resources relying on NTLM authentication unless the

remote machine allows access with NULL credentials (often referred to as a NULL session). In

Windows NT, RAS uses the LocalSystem account.

By default, Active Directory will not accept querying of object attributes via NULL sessions, so in a

mixed environment a Windows NT RAS server will not be able to retrieve a user's RAS properties

de 316

unless the following conditions are met:

• The domain is in mixed mode and the Windows NT RAS server is also a BDC. In this case,

RAS will have local access to the SAM.

• The domain is in mixed mode and the Windows NT RAS server contacts a Windows NT BDC,

which would result in behavior identical to current Windows NT behavior. This might lead to

some inconsistencies.

• The domain is in mixed mode or native mode and the Active Directory security has been

loosened to grant the built-in personality Everyone permissions to read any property on any

user object. The Active Directory Installation Wizard (dcpromo) allows the user to select this

configuration by means of a weaken the permissions option on certain Active Directory objects.

You should use this last workaround only after careful study of its impact on the security of Active

Directory. If you think it conflicts with your security requirements, you should adopt the

recommended approach, which is to upgrade the Windows NT RAS server to Windows 2000 and

make it a member of a Windows 2000 mixed or native domain. This would also have the benefit of

avoiding inconsistent behavior while the domain is in mixed mode, as described in the second

condition.

Your upgrade plan should take these factors into consideration. One implication is that you should

consider upgrading your RAS server first in the server upgrade process.

Supported Upgrade Paths

An important consideration in planning your upgrade to Windows 2000 will be the operating systems

you already have deployed in your enterprise, and whether you can upgrade them directly to

Windows 2000.

The table below contains a list of supported upgrade paths at Windows 2000 beta 3. In the cases

where an upgrade is required but a direct upgrade is not supported, you will upgrade via another

operating system such as Windows 9x, Windows NT 3.51/4.0 for workstations, or Windows NT

3.51/4.0 for servers. You will need to reflect this in your upgrade plan.

Supported Upgrade Paths

Platform Upgrade to Windows Upgrade to Windows

Windows 3.x No No

Windows NT 3.1 No No

Windows NT 3.1 No No

de 316

Advanced Server

Windows NT 3.51 Workstation

Yes No

Windows NT 3.51 Server No Yes

Windows 9x Yes No

Windows NT 4.0 Workstation

Yes No

Windows NT 4.0 Server No Yes

Order for Upgrading Domains

So far, this chapter has covered the order of upgrade for domain controllers in a domain. There is

little room for variation on this point: You must upgrade the PDC first, and then the BDCs. The

question of which domain to upgrade first is more problematic, and the answer may vary depending

on your circumstances. For example, if you are planning to restructure certain domains out of

existence, there might be little point in upgrading them first.

Although your situation may change this, in general you should consider the following order for

upgrading your domains:

1. Account domains

2. Resource domains

Upgrading Account Domains

As a general rule, you will get the most benefit from upgrading your account domains earliest

because in most cases there will be more users to administer than computers. By upgrading your

account domains to Windows 2000, you will benefit from:

• Improved scalability of Active Directory. Many organizations are pushing the upper

bounds of the recommended SAM size with their existing numbers of users and groups.

• Delegated administration. The ability to delegate administrative capability at very fine

granularity, without the necessity to grant absolute power.

Order of Account Domains

If you have more than one account domain, the following guidelines should help you choose in which

order to upgrade them:

• Maintain control. Although you will have tested your upgrade strategy in a lab, or via a

pilot, the first live migration will be the riskiest. To mitigate risk, you should upgrade domains

where you have easiest access to the domain controllers.

de 316

• Mitigate risk and disruption. If there is more than one domain to choose from in any

situation, upgrade the smallest first so that you minimize disruption to the greatest number of

possible users, particularly while you are gaining experience at the process.

• Get the job done. Once you have gained experience and confidence in the process, move

onto the bigger account domains.

• Look for targets of account domain restructure. If you are planning to restructure your

domains, you should look to upgrade the likely targets of restructure early in the process. You

cannot consolidate domains into a target that does not exist.

Order of Resource Domains

If you have more than one resource domain, the following guidelines should help you choose in

which order to upgrade them:

• Provide the features that applications need. First you should upgrade domains where

you are deploying applications that demand Windows 2000 infrastructure or features, such as

the Active Directory required by Microsoft Exchange 2000 (the next major release of Microsoft

Exchange).

• Choose domains with many workstations. Next you should upgrade domains with

many workstations, so that you can take advantage of Windows 2000 infrastructure such as

Microsoft® IntelliMirror®.

• Look for targets of resource domain restructure. Just as with account domains, if you

are planning a restructure of your domains, you should look to upgrade the likely targets of

restructure early on.

Upgrading Workstations and Servers

Although the focus of this chapter is domain upgrade and consolidation, do not assume that you

should postpone deployment of Windows 2000 workstations and member servers until you upgrade

the domain infrastructure. Using Windows 2000 workstations and servers in an existing Windows NT

environment will still have a number of benefits. The following table lists some of the benefits

achieved by simply upgrading workstations and servers to Windows 2000.

Benefits of Simple Workstation or Server Upgrade

Benefit Features

Manageability Plug and Play

de 316

de 316

Domain Migration Cookbook - Chapter 3: Domain Restructure

Section 1:

Migration Concepts



be inferred.

Introduction

Domain restructure is a process that allows you to redesign the forest according to the needs of your

organization. Although restructure can result in any number of outcomes, the typical result is some

rationalization of the current structure and perhaps a move to fewer, larger domains.

This chapter will address:

• The concepts behind domain restructure.

• The supported domain migration scenarios that involve restructure.

Domain Restructure

In the past, a number of third-party directory management tools have provided domain-

restructuring support for Microsoft® Windows NT®. Now for the first time, Microsoft® Windows®

2000 provides native functionality to enable domain-restructuring scenarios, namely:

• Security principals that can be moved from one domain to another, either destructively or

nondestructively, while maintaining pre-move access to resources.

• Domain controllers that can be moved from one domain to another without complete

reinstallation of the operating system.

Microsoft provides a number of tools to aid restructuring: a free graphical tool to ease domain

restructuring, a scriptable Component Object Model (COM) component together with some sample

scripts to illustrate how to use the component, and various command line utilities.

These will be useful to many customers implementing the scenarios described below. For customers

requiring greater sophistication and graphical tools, Microsoft is working with a number of

independent software vendors (ISVs) to ensure that there is also a healthy market for more fully

featured third-party tools.

When Should You Restructure?

de 316

Restructuring is appropriate in three sets of circumstances:

• Postupgrade. The most common time for organizations to perform domain restructuring

will be as the second phase of migration to Windows 2000, following an earlier upgrade.

The upgrade will have covered the "easier" migration cases, such as groups of domains where

the trust structure is essentially correct, and where there are no administrative implications.

Under these circumstances, restructuring will probably be aimed at reworking other parts of the

domain structure to reduce complexity, or to bring resource domains with untrusted

administrators into the forest in a secure way.

• Instead of upgrade. Some organizations might decide that their current domain structure

is unsalvageable, or that they cannot afford to jeopardize the stability of the current production

environment during migration. In such cases, the easiest migration path might be to design and

build an ideal or pristine Windows 2000 environment separate from the current production

environment. Here, the new Windows 2000 forest is intended to become the production

environment over time.

Once the new forest has been built, restructuring will begin with a pilot, where a number of

users, groups, and resources are migrated to the new environment to act as an advance party,

ensuring that business can carry on as normal in the new structure.

On successful completion of this phase, the pilot will transition into a staged migration to the

new environment. At some point, Windows 2000 will become the production environment. The

old domain structure will be decommissioned, and the remaining resources will be redeployed.

• Postmigration. In this case, restructuring takes place as part of general domain redesign

in an environment operating only on Windows 2000. This might occur several years down the

line, when for some reason—such as organizational change or corporate acquisition—the current

structure becomes inappropriate.

The main focus of this chapter is on the initial migration from Windows NT 4.0 to Windows 2000,

namely the first two cases. Some of the approaches discussed below might prove useful in the third

case, although more complete tools and techniques probably will be developed for future releases of

Windows 2000.

de 316


Figure 3.1 When restructure can occur

Why Would You Restructure?

You might wish to carry out domain restructuring for a number of reasons, but the major driver is

likely to be to take advantage of features on Windows 2000 that allow you to better structure your

domains to reflect the requirements of your organization, such as:

• Greater scalability. You might have designed your previous Windows NT domain structure

around the size limitations of the Security Accounts Manager (SAM) accounts database, leading

you to implement a master or multimaster domain model. With the vastly improved scalability

of Microsoft® Active Directory™, scaling to literally millions of user accounts or groups, you

could restructure your current Windows NT domains into fewer, larger Windows 2000 domains.

• Finer granularity of administration. In your current model you might have implemented

resource domains to allow delegation of administrative responsibility. Windows 2000

organizational units (OUs) can contain any type of security principal, and administration can be

delegated as appropriate. In many instances, converting resource domains into OUs will be a

more appropriate method for delegating administration.

• Simpler administration. To allow delegation as described above, or perhaps as a result of

corporate acquisition, your domain structure might be connected by a complex mesh of trusts.

de 316

Some of these domains might be better implemented as OUs, thus simplifying administration.

Alternately, you could redesign your domain tree and benefit from fewer, bidirectional transitive

trusts.

The scenarios this chapter describes are not predicated on completion of an initial upgrade.

Implications of Domain Restructure

The fundamental enablers for restructuring scenarios are, as mentioned above, the ability to move

security principals and domain controllers between domains. This section will examine the

implications of these features and the impact they have on planning your restructure.

The Effect of Moving Security Principals on SIDs

Chapter 1 looked at the domain-relative nature of security identifiers (SIDs). A consequence of this

is that when you move a security principal such as a user or a group between domains it has to be

issued with a new SID for the new domain.

As the chapter on upgrade shows, access to resources in the Windows NT security model is carried

out by the operating system, which looks at the user's access token and evaluates the user's

primary SID, and the SIDs of any groups to which the user belongs, against the discretionary access

control list (DACL) on the resource's security descriptor. DACLs are made up of lists of SIDs

indicating approval or denial of access to the resource for the security principals that the SIDs

identify. Thus, changing the SID has far-reaching implications.

To illustrate these implications, here is an example based on Windows NT security. "Bob," an

employee of Hay Buv Toys, has an account in the Windows NT 4.0 master domain HAYBUV-ACCT.

Bob is a member of the global group Finance Analysts in the same domain.

Hay Buv Toys uses a financial application based on Microsoft® Win32® that runs on a number of

Windows NT Server machines in a resource domain HAYBUV-RES1. In order to make use of the fact

that local groups created on the primary domain controller (PDC) are shared among all domain

controllers in the domain, the servers on which the application runs are running as backup domain

controllers (BDCs) in the domain. A shared local group called Financial Resources has been created

on the PDC and is used on DACLs on the files that the application uses. The global group HAYBUV-

ACCT\Finance Analysts is a member of HAYBUV-RES1\Financial Resources.

Bob also has access to a file server, FIN_FILES1, in the resource domain. FIN_FILES1 is simply a

Windows NT Server computer running as a member server. FIN_FILES1 uses a local group called

Finance Files on the DACLs of files relating to Bob's group. HAYBUV-ACCT\Finance Analysts is a

member of FIN_FILES1\Finance Files. Bob works on some private projects and has a directory on

de 316

FIN_FILES1 that is protected so that only he can access the files in that directory. This directory has

a DACL that contains a single entry allowing Bob full control of the directory.


Figure 3.2 Resource access example

Moving Security Principals

As indicated earlier in this chapter, moving a security principal between domains changes the

security principal's SID.

You can appreciate the implications of moving security principals by tracing what would happen if

Bob's account were moved to another domain as part of a migration involving domain restructuring

of two Windows NT domains. Prior to the release of Windows 2000, the only way to "move" security

principals between domains was to create new objects in the target domain.

Effects of the Move on Bob's Global Group Membership

HAYBUV-ACCT \Bob is a member of the global group HAYBUV-ACCT\Finance Analysts. Because a

global group can only contain members from its own domain, Bob's move to the new domain would

result in his new account not being able to be a part of this group, which would mean he would lose

access to resources available to this group.

Assuming sufficient trust existed between the new domain and the resource domain, it would appear

de 316

that you could fix this in a number of ways:

• Adding Bob's new SID to resource DACLs. You could maintain access to resources by

adding Bob's new SID to the DACLs on all the resources he formerly had access to as a member

of the group. This would be time consuming and messy for a number of reasons:

• Many domain-restructuring operations will be carried out incrementally over a period of

time, and during this transitional period there is no guarantee that new resources would not be

created for the finance analysts group. Because of this, you would have to continue to regrant

permission during the migration periods while the two groups coexisted.

• Microsoft recommends that groups, rather than individuals, be used in DACLs. This is

because the memberships of groups carrying out specific job functions can change over time,

and it is easier to take a user out of a group than it is to change the DACLs of numerous

resources that reference the user. What would happen if Bob's job function changed and he no

longer needed to be a member of the finance analysts group?

• Moving the group. You could move the group itself to the new domain. You would have to

do an exercise similar to the first option, this time regranting permission to resources to refer to

the SID of the new group.

• Creating a parallel group in the target domain. If you were to move the group, a

problem would occur if the migration plan did not envisage moving all the group members in

one transaction. This would mean that you would have to maintain the group in the old domain

and create a new parallel group in the new domain. You would maintain resource access for the

original group and its members, but you would need to regrant permission to resources to grant

access to the new group. Again, you would have to continue to regrant permission while the

group existed in both domains.

Effects of the Move on DACLs Directly Referencing Bob

Our example employee Bob is also granted access to some resources on the member server

FIN_FILES directly. His SID appears on DACLs on that computer. It is acceptable to add users to

DACLs on resources, but one effect of Bob's move would be a requirement to regrant permission to

any resources on that server, adding his new domain SID.

Microsoft has always advised the use of groups rather than individuals in resource DACLs. Many

organizations might not have enforced this, resulting in a requirement to seek out and update all

references to a moved user in all DACLs on resources across the organization.

SIDHistory

de 316

In Windows 2000 the position is made considerably easier as a result of a new Windows 2000

directory attribute called sIDHistory.

SIDHistory is an attribute of Active Directory security principals and is used to store the former SIDs

of moved objects such as users and security groups.

When you move a user or group using new Win32 application programming interfaces (APIs) or tools

and support utilities provided by Microsoft and built on top of them, you update the sIDHistory

attribute of the object representing it in Active Directory with its former SID as part of the operation.

When the user then logs on to the system, the system retrieves the entries in the user's sIDHistory

as well as the user's group memberships and adds them to the user's access token.

Because groups can be moved, the system also retrieves the sIDHistory attributes of all the groups

the user is a member of and adds these to the user's access token.

These sIDHistory entries in the token look to the system like normal group memberships during

authorization checks, so they can grant appropriate access even on earlier version systems without

requirements for additional software.

Note You can update the sIDHistory attribute only in native mode Windows 2000 domains, which

has the effect of requiring all migration operations relying on sIDHistory to have a native mode

target for restructure.

Figure 3.3 Resource access granted through sIDHistory

Taking Advantage of SIDHistory: Moving vs. Cloning

Moving security principals can be regarded as a destructive operation because the source object no

de 316

longer exists as a result of its move.

Moving security principals is not desirable in these situations:

• You want minimum disruption to the production environment. While many

customers want to restructure their domains in the course of migrating to Windows 2000, they

have indicated that they want to do this without affecting their existing production environment.

In this case, the desired approach is to create the new "pristine" Windows 2000 forest separate

from the production environment, and then populate it with users and groups. In this scenario,

the users and groups continue to exist in production for the purposes of fallback.

• You plan an incremental migration. As you saw in the context of migrating users prior

to Windows 2000, restrictions on group memberships and the need to maintain resource access

make incremental migration difficult with move operations. Moving users without their global

groups "orphans" users from their resource access. To avoid the same situation while moving

global groups means you must move their memberships at the same time.

For the above reasons, Windows 2000 also allows a nondestructive or cloning approach to migrating

security principals while taking advantage of sIDHistory. In most instances cloning will be the

preferred approach to migration.

Note Cloning is possible only between domains in different forests ("interforest"), while moving

objects while updating sIDHistory is possible only between domains in the same Windows 2000

forest ("intraforest").

Cloning Security Principals

Microsoft provides support for cloning operations in three ways:

• For developers. Cloning is made possible by a Win32 API called DsAddSidHistory, which

takes the primary SID of a user or group in the source domain and adds it to the sIDHistory of

an object of the same type in the target domain.

• For administrators. Microsoft has licensed domain migration technology from Mission

Critical Software of Houston, Texas. This is provided in the form of a tool, the Active Directory

Migration Tool (ADMT), designed to support the migration scenarios described below. This

should be sufficient for most migration requirements.

• For administrators with complex requirements. In some complex environments, ADMT

will not cover the migration scenario—for example, where custom scripting is required. In these

circumstances, you can modify ClonePrincipal, a set of sample Microsoft® Visual Basic® scripts,

de 316

to provide a custom solution.

Cloning Constraints

Because cloning is a security-sensitive operation, the DsAddSidHistory API imposes a number of

constraints on the operation:

• The SID of the source account must not already exist in the target forest either as a

primary SID or in the sIDHistory of any security principal.

• The first constraint has the effect of requiring the source and target domains to be in

different forests.

• To execute ClonePrincipal, the user must have administrator privileges in both the source

and target domains. (For detailed instructions, please see chapters 9, 10, and 11.)

• Auditing must be switched on in both the source and target domains.

• User passwords are not preserved and must be re-created in the target domain.

Moving Security Principals

Microsoft provides two tools to support move operations using sIDHistory:

• Active Directory Migration Tool. As well as supporting cloning operations, ADMT's user

and group migration wizards support moving users and groups intraforest.

• MoveTree. MoveTree is a Windows 2000 support tool. MoveTree will move objects such as

OUs, groups, and user accounts.

Constraints on Moving Objects with SIDHistory

Some constraints on moving objects while maintaining sIDHistory are:

• The domain from which the object is being moved (source) must be a Windows 2000 mixed

or native mode domain.

• Source and target domains must be in the same forest.

• Populated global groups cannot be moved.

• Objects must be moved in closed sets. The meaning of the term depends on whether you

are referring to the movement of users and global groups, or the movement of computers,

which might use shared local groups in the case of Windows NT domain controllers, or domain

local groups in the case of Windows 2000 domain controllers, servers, and workstations in a

native mode domain.

de 316

• User passwords are preserved.

Closed Sets and Moving Users and Global Groups

As explained earlier, a global group can only contain members from its own domain. When a user

moves between domains, any global groups to which the user belongs must also be moved in order

to maintain access to resources protected by DACLs referring to global groups. A corollary of this is

that if a global group is moved, its members must also be moved.

In this instance, a closed set of users and global groups is a set where each user's global groups are

moved with the user, and each group's members are moved with the group.

If the source domain is a native mode domain, global groups can also contain other global groups, in

which case each nested group's members and all global groups to which its members belong must

be moved.

Closed Sets and Moving Computers

Shared local groups and domain local groups only have scope within the domain in which they were

created. If such a group moved, you would be unable to resolve any references to the group in

DACLs in the source domain.

In this instance, a closed set of computers and shared or domain local groups is a set in which each

such group's computers in the domain containing DACLs referencing the group are moved with the

group. Also, for each computer being moved, all shared or domain local groups referenced in DACLs

on its resources are also being moved.

Ways Around Closed Sets

The restrictions on the movement of populated global groups and closed sets are particularly

onerous. Depopulating and repopulating large global groups can be time consuming, and in some

cases the smallest closed set you can achieve will be the whole source domain.

In such cases, there are three possible approaches to solving the problem:

• Parallel groups. This approach creates parallel global groups in the target domain for each

group to be moved, then locates all resources in the enterprise containing DACLs referencing

the original group and regrants permission for them to include reference to the parallel group.

In the case of moving global groups, where the group could be referenced on resources in any

trusting domain, or domain local groups from native mode source domains where domain local

groups can be used on any computer in the domain, this is likely to be a large undertaking.

de 316

• Universal groups. This approach switches the source domain to native mode, then

changes the group type of the groups to be moved to universal. Because universal groups have

scope across the entire forest, changing the groups to universal groups means that they can

safely be moved while still maintaining access to resources left behind.

This approach requires some caution because, as explained earlier, the membership of universal

groups is stored in the global catalog (GC), which has implications for GC replication traffic.

Because of this, you might want to use this approach as a transitional strategy while you

migrate users and groups to the new domain. Then, once you complete the migration, you can

change the groups back to their original types.

• Cloning. This approach clones groups from the source domain into the target domain while

retaining sIDHistory. This technique has some constraints, which are examined in the section

"Cloning Constraints."

SIDHistory Considerations

SIDHistory provides a convenient mechanism for migrating users and groups while maintaining

resource access. Some factors that you must consider if you intend to use sIDHistory to migrate are:

• The implications of cloning on SID resolution.

• Establishing trusts.

• Moving servers.

• Account deletion and cloning local groups.

• Windows NT 3.51 and sIDHistory.

• Profiles and sIDHistory.

Note Special attention should be paid to the following section on "The Implications of Cloning on

SID Resolution." It could determine your strategy for SID cleanup and whether to use sIDHistory.

The Implications of Cloning on SID Resolution

Perhaps the most important considerations to keep in mind when formulating your domain

restructure plan relate to the way SIDs are resolved to usernames. In some circumstances when a

user tries to look at the security properties of a file or folder on a Windows NTFS file system (NTFS)

partition, the SIDs of users and groups that have been cloned may not be resolved and will be

labeled as Unknown User. This could cause management problems because administrators might

hesitate to edit DACLs for fear of preventing legitimate resource access.

de 316

To understand this problem, it helps to look at the way the API attempts to resolve SIDs. The API

attempts resolution in the following order:

1. It attempts to find a name for the SID by first checking a list of well-known SIDs.

2. If the SID does not correspond to a well-known SID, the function checks built-in and administratively defined local accounts.

3. Next, the function checks the primary domain.

4. Next, the function attempts to check the SID against the SIDs of all accounts in all domains in the Windows 2000 forest, including SIDs that appear only in the sIDHistory field of an account in the forest. To look these up, the function needs to be able to query the GC of the forest.

5. The function checks SIDs not recognized by the primary domain or GC search against the trusted domains corresponding to their SID prefixes.

This has a number of implications:

• To be able to resolve the name without querying the GC, the account that was cloned needs

to be in a trusted domain, and needs to still exist.

• To resolve the name as described in step 4 above, however, the computer from which the

function attempts the check must either be running Windows 2000 and be a member of the

target forest, or be in a Windows 2000 native mode domain that is a member of the target

forest.

To avoid this problem, you should consider:

• Migrating all workstations to the target forest as soon as possible after users have

migrated.

• Translating security on resources across the enterprise to remove references to old SIDs.

• Maintaining the source account in the old domain until security on resources has been

translated and all references to the old SIDs have been removed.

Establishing Trusts

In cloning scenarios, where the source and target domains are in separate forests, establishing the

trusts necessary to guarantee resource access will be one of the first steps.

ADMT provides a wizard for copying trusts to and from the source domain.

Netdom.exe is another support tool provided on the Windows 2000 Server CD to carry out such

tasks as enumerating domain trusts and establishing new trusts.

Moving Servers

de 316

In the previous example, Bob has access to some resources on the member server FIN_FILES1 via

DACLs referencing a computer local group FIN_FILES1\Finance Files and referencing his domain

account directly.

You now know that moving domain controllers requires you to maintain shared local groups and

domain local groups, but what about the implications of moving a member server such as

FIN_FILES1 or a workstation?

Assuming that the server was moved to a domain with trust to Bob's new account domain,

sIDHistory would ensure that Bob could access resources with DACLs referencing him directly.

DACLs referencing the machine local group would also continue to function because the group exists

in the local machine's account database. Thus, it is unaffected by the move, and its SID would not

need to be changed.

Account Deletion and Cloning Local Groups

Cloning local groups as part of domain migration may not always maintain resource access if you

have decommissioned some of your source domains or removed security principals from the source

domain. This arises from the way Windows NT handles local group membership cleanup—that is,

what Windows NT does to a security principal's group memberships when that principal is deleted.

As a result, you should bear in mind the order in which you delete accounts or decommission

account domains and clone local groups. This section will look at local group (hereafter referred to as

"group") membership cleanup and its implications.

Windows NT 3.51 and SIDHistory

When planning a domain restructure, you should be aware of a known problem related to the use of

Windows NT 3.51 in Windows 2000 domains.

The problem concerns authentication and authorization—specifically, the way access tokens are

constructed in Windows NT 3.51. When a user is authenticated, either interactively at a Windows NT

3.51 workstation, or over the network at a Windows NT 3.51 server, the token is built using only

SIDs relative to the user's account domain and local groups from the server or workstation where

authentication is taking place. The result is that Windows NT 3.51 access tokens cannot contain

universal groups from outside the account domain, or domain local groups from the resource

domain. Since by definition entries from the user's sIDHistory, or the sIDHistory of any groups to

which the user belongs, will be from domains other than the account domain, these will also be

excluded from the token.

de 316

The implication of this is that with Windows NT 3.51, SIDs from domains other than the account

domain of the user logging on are ignored when evaluated for access control.

In most cases, this results in denial of access, although this might not be the desired result.

Profiles and SIDHistory

When formulating your domain restructure plan, you should be aware of the implications of migrated

users having new SIDs on profile use.

When a user logs on to a Windows NT workstation, the system loads a profile for that user

containing user-specific configuration information. The system locates this profile by picking up the

user's SID and looking in the registry under the key HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft

\Windows NT\CurrentVersion\ProfileList for a key named after the string representation of the user's

SID.

An implication of this behavior is that users logging onto their workstations after migration might

lose access to their logon profiles, because their primary SIDs will have changed and their old

profiles will be stored under their old primary SID.

When a user has been moved between Windows 2000 domains in the same forest using a tool such

as MoveTree, this will not be a problem because MoveTree preserves the user's globally unique

identifier (GUID). A new feature of the profile handling code in the Windows 2000 client takes

advantage of this invariance of the GUID, so that on failure to find a user's SID in the ProfileList key,

the system will retrieve the user's GUID and look in the registry under the key

HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows NT\CurrentVersion\ProfileGuid for a key

named after the string representation of the user's GUID. If it finds such a key, it will search it for a

value called the SidString, which provides a fallback mapping of the user's GUID to the user's SID.

The system can then look under the ProfileList key for the SID contained in SidString, and if it finds

it, rename the key to the string representation of the user's new SID. The system will in this case

also change the SidString value.

From the above description, you can see that you could lose profiles in the following cases:

• A user has been cloned from a Windows NT 4.0 domain.

• A user has been cloned from a Windows 2000 domain.

• A user has been cloned from a Windows 2000 domain, but is logging on at a Windows NT

4.0 workstation.

de 316

The following section describes some options for handling these cases.

Profile Migration

There are two basic methods of making a profile available to the migrated user while at the same

time allowing a fallback route:

• Shared profiles. Make the same profile available to the user's original account and the

new account. One copy of the profile is accessed and updated by both accounts

• Copied profiles. Copy the original profile from its current location under the key named

after the user's original SID to a key named after the user's new SID. Each account is

associated with its own, separate copy of the profile. Updates to one are not reflected in the

other.

Both approaches have their advantages and disadvantages.

Advantages and Disadvantages of Sharing Profiles

Advantages Disadvantages

Updates to the profile (for instance, changes to My Documents, shortcuts, and so on) while logged onto one account are accessible when subsequently logged on to the other account

When moving between the old and new accounts, results are currently unpredictable. An example would be a new Windows 2000 account profile, perhaps containing group policy references, is used when falling back to a source account where different group policy (or no group policy) is deployed.

Conserves disk space because only one copy of the profile is stored

Makes a utility available to enable profile sharing

Advantages and Disadvantages of Copying Profiles

Advantages Disadvantages

Behavior is more predictable, and because data is not shared between the profiles, there is no

chance of "polluting" the profile of one account with data appropriate only for another account in a

different domain and forest.

There may be unpredictable "fallback" results with application deployment policy in the new domain. Even though the old account profile is not altered by destination account activity, applications deployed on the desktop by destination domain group policy may try, under certain circumstances, to uninstall themselves or do other unpredictable things. Storing two profiles consumes extra disk space.

de 316

ADMT will copy user profiles as a part of migration.

Third-Party Applications and Profiles

Whichever approach you use when migrating profiles, you should be aware that applications use

profiles in a number of ways to store user-specific application state. Core user customization

information such as desktop layout, Start menu contents, and so on should be easy to preserve, but

you should become familiar with the actions of any third-party applications you might have installed,

and how they use the profile.

Specific instances of profile-related actions you should look for are:

• SID persistence. Here the application itself stores a reference to the user's SID in the

profile. If the application is aware of sIDHistory, this might not be a problem. If it isn't,

however, this could cause issues such as the application losing state information since the

user's SID will have changed.

• Locations of server or share. Here the application stores pointers to specific servers or

shares where it might store data or retrieve data from. The viability of this approach will depend

on the location of the server or share and its accessibility, which in turn will be governed by

trust relationships.

Migration Scenarios

Microsoft provides a number of tools to help you restructure your domains during migration; this

section will look at the migration scenarios for which Microsoft has designed these tools.

Domain Migration Scenarios

Microsoft has documented three migration scenarios, which will meet most customers' restructuring

requirements. The scenarios are aimed at facilitating the movement of users and computers from

Windows NT source domains to Windows 2000 targets. The scenarios are:

• Migrating users incrementally to Windows 2000 (interforest). This scenario involves

migrating users incrementally from a Windows NT source domain or Windows 2000 source

forest to a Windows 2000 target forest.

• Migrating resources incrementally to Windows 2000 (interforest). This scenario

involves migrating resources incrementally from a Windows NT source domain or Windows 2000

source forest to a Windows 2000 target forest.

• Moving users between Windows 2000 domains (intraforest). This scenario involves

de 316

moving users between Windows 2000 domains in the same forest.

Migrating Users Incrementally to Windows 2000 (Interforest)

The aim of this scenario is to describe the steps and the basic utilities that an organization requires

to migrate its users incrementally to a pristine Windows 2000 target forest without impacting its

Windows NT production environment. This scenario is an interforest migration scenario using

cloning, but the source can be a different Windows 2000 forest.

The implication of not impacting the current production environment is that the environment must

remain untouched during the migration. A consequence of this is that during the migration the

customer can always fall back to the old production domain should the need arise.

Once the migration is complete, the organization can decommission the old account domain and

reassign the domain controllers.

Scenario Steps

The scenario steps are as follows:

1. Create the pristine Windows 2000 forest. Use standard procedure to create a new Windows 2000 destination forest that reflects the requirements and structure identified in the customer's namespace planning activities. Domains created in the new forest will be native mode Windows 2000 domains.

2. Establish trusts to maintain resource access. Use ADMT or Netdom to query what trusts currently exist from any resource domains to the Windows NT source domain, and then to establish any trusts that do not already exist.

3. Clone all source global groups in the target domain. As discussed earlier, most resources will be protected using DACLs that reference global groups, usually indirectly via shared or machine local groups. Once trusts have been established, the next task is to ensure that the relevant global groups are available in the target domain.

The simplest way to achieve this is to clone all global groups using ADMT or ClonePrincipal.

4. Identify and clone sets of users. Once the source global groups have been cloned to the target domain, the task of migrating users can begin.

Because in most instances the customer will want to move sets of users incrementally, this will

be an iterative task—identifying the sets of users to migrate and then using ADMT or

ClonePrincipal to clone the source users in the destination domain.

As part of this task, you will have to add each migrated user to the destination clone of any

global groups in which it was a member in the source domain.

5. Decommission the source domain. When all users and groups have moved permanently to the destination forest, the final task will be to decommission the source domain, which involves powering off and removing the source domain BDCs, and finally the source domain PDC.

de 316

If the intention is to reassign these domain controllers in the new forest, then they can be

upgraded to Windows 2000 and either promoted to domain controllers or left as member

servers as described earlier.

Each step in the scenario should be tested, particularly during the user migration phase. It might be

prudent to test logon for certain users during each migration. If an error occurs at any stage prior to

decommissioning, you can suspend the process and continue work in the source production domain.


Figure 3.4 Migrating users incrementally to Windows 2000 (interforest)

Migrating Resources Incrementally to Windows 2000 (Interforest)

The aim of this scenario is to describe the steps and the basic utilities that an organization requires

to consolidate a number of resource domains into an OU in a native mode Windows 2000 domain.

Typically, the impetus for this is to reduce the costs of administering complex trusts.

As part of this scenario, the application servers will become member servers in the target OU. It is

assumed that the application servers in each domain will be making use of shared local groups. It is

also assumed that the domains may contain some member servers and workstations.

Once the restructuring is complete, the organization can decommission the old domains.

Scenario Steps

de 316

The scenario steps are as follows:

1. Establish any trusts required from the target domain to account domains outside the forest. This scenario differs from the previous one in that it is the resource domains that are being brought into the target forest and the account domains remain outside the forest, for the time being at least. The principal remains the same, however, so trusts will have to be established from the target domain to the account domains to maintain resource access.

This activity involves using ADMT or Netdom to query what trusts currently exist from the

resource domains to the account domains, and then to establish any trusts that do not already

exist.

2. Clone all shared local groups. As discussed earlier, shared local groups only have scope within the domain in which they were created and are only shared between domain controllers in that domain. In this scenario it is not necessary to move all domain controllers to the target domain immediately, so it will be necessary to clone shared local groups to the target domain using ADMT or ClonePrincipal in order to ensure that resource access is maintained while domain controllers and resources are split between the source and target domains.

3. Demote application servers to member servers. Once all the shared local groups have been cloned, you can start the process of converting the application servers to member servers in the target OU.

There are currently some limitations on how BDCs can be upgraded. One of the effects of this is

that there is no easy way of upgrading a BDC and demoting it to a member server unless the

PDC has been previously upgraded. This might be investigated for future versions of Windows

2000.In the meantime, there are two approaches to upgrading and demoting BDCs:

o If possible, you should upgrade the PDC of the resource domain to Windows 2000

and run the domain in mixed mode during the transition period. You can now upgrade each

BDC to be demoted.

During each BDC upgrade, the Active Directory Installation wizard will be launched and you

will be given the option of making the BDC a replica in a Windows 2000 domain, or a

member server in the domain. You should select the latter option, so that the machine is

now a member server in the resource domain.

o If upgrading the PDC is not possible or desired, for each upgrade you will need to

take the BDC offline and promote it to PDC. Once you have promoted the BDC to PDC, you

can then upgrade to Windows 2000, effectively making the offline domain controller PDC in

a clone Windows 2000 mixed-mode domain. Once the PDC has been upgraded offline, you

can then run the Active Directory Installation wizard to demote the PDC to a member

server and join it to the target domain.

4. Move member servers (including former BDCs) and workstations. During this step, you can use ADMT or Netdom to create a computer account in a destination domain OU for the member server or workstation to be moved, and join the computer to the destination domain.

5. Decommission the source domain. When all groups and computers have moved

de 316

permanently to the destination forest, the final task will be to decommission the source domain, which involves powering off and removing the source domain BDCs and finally the source domain PDC.

If the intention is to reassign these domain controllers in the new forest, then you can upgrade

them to Windows 2000 and either promote them to domain controllers or leave them as

member servers as described earlier.

It should be noted that when demoting BDCs to member servers in this scenario, you should move

them over to the target domain as quickly as possible. Unless the domain is in native mode and

shared local groups have been converted to domain local groups, resources accessible through these

groups will not be available on the member servers.


Figure 3.5 Migrating resources incrementally to Windows 2000 (interforest)



the issues discussed as of the date of publication. Because Microsoft must respond to changing

market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and

Microsoft cannot guarantee the accuracy of any information presented after the date of publication.


de 316

de 316

Domain Migration Cookbook - Chapter 4: Restructuring Tools

Section 1:

Migration Concepts



be inferred.

Introduction

The task of restructuring domains can range from routine and straightforward to complex,

depending on the size and number of account domains and the number of resource domains

involved.

Microsoft provides a number of tools to assist with domain restructure. The Active Directory™

Migration Tool (ADMT) is a powerful graphical tool that can perform all tasks. Besides ADMT,

additional command line tools are available. This chapter will discuss:

• The different migration tools available.

• The ways in which you can use them.

• How to use the command line tools.

Microsoft Restructure Tools

Microsoft provides the following tools to assist in domain restructure:

Active Directory Migration Tool (ADMT)

ADMT is a Microsoft Management Console (MMC) snap-in that provides graphical support in the form of wizards to automate migration tasks such as moving users, groups, and computers (between or within forests), migrating trusts, and performing security translation.

ClonePrincipal Used to clone user and group accounts from a Microsoft® Windows NT® 4.0 source domain or a Microsoft® Windows® 2000 source domain in a separate forest to a native mode Windows 2000 target domain.

Netdom Often used in the same scenarios as ClonePrincipal to move computer accounts from a Windows NT 4.0 or Windows 2000 source domain to a Windows 2000 target domain. Netdom is also used to recreate trusts, typically in migration scenarios between the target domains and any domains trusted by or trusting the source domain.

MoveTree Used for moving users, groups, and organizational units (OUs) between Windows 2000 domains in the same forest.

While Microsoft provides a range of powerful tools to aid domain restructure as a part of domain

de 316

migration, in some instances customers will prefer to use third-party tools. Microsoft has worked

closely with the major third-party tool vendors in this area to ensure that they have been able to

capitalize on features such as sIDHistory, cloning, and moving objects within the same forest.

There are three major differences between ClonePrincipal or Active Directory Migration Tool for

cloning users and MoveTree:

• ClonePrincipal is nondestructive, meaning it leaves the original account intact, allowing

users to roll back in the event of a problem, whereas MoveTree is a one-way function with no

contingency options.

• ClonePrincipal only operates between domains in separate forests (interforest) and

MoveTree can be used only between domains in the same forest (intraforest).

• MoveTree migrates the user's password. ClonePrincipal requires the administrator to preset

a new initial password.

Which Tool Should You Use?

The tools described above have been designed to work in specific contexts, so the choice of tool

depends on the migration scenario you wish to use.

Broadly speaking, you can divide user and group migrations into two categories: interforest, and

intraforest.

Interforest Migration

A migration can be described as being interforest when it takes place between two separate

Windows 2000 forests. Since a Windows NT 4.0 domain cannot be part of a Windows 2000 forest,

migration from a Windows NT 4.0 domain to a Windows 2000 domain is considered an interforest

migration.

Advantages of Interforest Migration

Interforest migration is the primary migration scenario when migrating from Windows NT 4.0 to

Windows 2000 without upgrading the domain. It has a number of advantages over intraforest

migration, primarily that cloning is possible.

Cloning—the creation of new accounts in the target domain that mirror accounts in the source

domain but also maintain the source account primary security identifier (SID) in their sIDHistory—is

only possible interforest. Cloning is nondestructive in that it leaves the source accounts intact; this is

desirable in a number of cases:

de 316

• Staged migrations. In this case you want to migrate some or all users and groups from

the source domain to the target domain, but leave the accounts in a disabled state or merely

not have the users log on to their new accounts until some later date, that is, until the new

environment has been adequately tested, or until the users have been trained. The fact that

cloning is nondestructive means that the users can continue logging on to their existing

accounts until it is appropriate to switch over.

• Parallel environments. This case is similar to the previous case, except that you want the

migrated users to log on with both their new and old accounts. An example of this might be

where users have to continue logging on with their old accounts to access an application that

does not use sIDHistory and that does not allow access based on the new account. Again, the

nondestructive nature of cloning means that the user's old account can continue to be used as

long as required.

• Fallback. The fact that the user's old account remains available, if desired, even after

cloning means that as long as the old account remains in existence, it is always possible for

users to use their old accounts in case of some disaster.

Another advantage of cloning, and therefore of interforest migration, is that apart from the

requirements imposed by the configuration required to carry it out, it is a very straightforward, easy

operation with few constraints.

Disadvantages of Interforest Migration

For some customers, certain factors might make interforest migration undesirable:

• Resource access with sIDHistory. Even though the constraints on cloning require that

SIDs must be unique within a forest, some customers prefer not to rely on sIDHistory in a

cloning context. This is because until the source account is removed, it remains theoretically

possible for a dishonest administrator to take advantage of the fact that sIDHistory in this

context allows two accounts to gain access to resources using the same SID, that is, via the old

account's primary, and the sIDHistory of the new account.

• Change password. Microsoft-provided tools do not support copying passwords between

forests, thus in all interforest scenarios the migration requires the user's password to be reset.

• Globally unique identifier (GUID) not preserved. Objects in Microsoft Active Directory

are identified by GUIDs, and cloning does not preserve GUIDs. Because this is a limitation only

when dealing with Windows 2000 source domains, and the primary interforest scenario is

migrating from Windows NT 4.0 to Windows 2000, this is unlikely to affect many customers.

Interforest Migration Tools

de 316

The following tools can be used to migrate users, groups, and computer accounts in interforest

scenarios:

• ADMT. Clones users and groups, migrates computer accounts and trusts.

• ClonePrincipal. Clones users and groups.

• Netdom. Migrates computer accounts and trusts.

Intraforest Migration

A migration can be described as being intraforest when it takes place between two domains in the

same Windows 2000 forest. Because a Windows NT 4.0 domain cannot be part of a Windows 2000

forest, intraforest migration is not applicable when you are migrating from Windows NT 4.0 domains.

Advantages of Intraforest Migration

Intraforest migration as a migration scenario is primarily concerned with allowing customers to

restructure domains after they have been upgraded into the target Windows 2000 forest. Intraforest

migration, like interforest migration, makes use of sIDHistory to maintain resource access.

As mentioned earlier, cloning is only available in interforest scenarios. As a result, to make use of

sIDHistory in intraforest migrations, the object must be moved from source domain to target, that

is, the source object ceases to exist as a result of the migration.

Intraforest migration has a number of attractions:

• Password preservation required. Windows 2000 can copy user passwords from domain

to domain in the same forest as part of an object move operation. If password preservation is

absolutely required, then intraforest migration may be desirable.

• GUID preservation required. Windows 2000 preserves the object GUID in object moves

intraforest. If a customer is using applications that establish user identity via GUIDs, then

intraforest migration could be desirable.

• General user management scenarios. These are separate from, but related to,

migration scenarios. A common example would be a requirement to move a user from one

domain in the forest representing a foreign subsidiary, to a different domain in the forest

representing another country. Here it would be useful to be able to move the user while

preserving his or her personal resource access, password, and GUID.

Disadvantages of Intraforest Migration

Some disadvantages to intraforest migration are:

de 316

• Destructive operation. Because intraforest migration using sIDHistory requires the source

object to be destroyed, it is not possible to implement the staged and parallel migrations as

described in the same way.

• Closed sets. The closed set requirement with respect to intraforest migration is discussed

elsewhere, but the essence is that in order to maintain group membership rules, users and their

global groups must be moved together. Because this is a destructive operation, this is often

impossible without moving the entire domain.

Intraforest Migration Tools

The following tools can be used to migrate users, groups, and computer accounts in intraforest

scenarios:

• ADMT. Moves user, group, and computer accounts.

• MoveTree. Moves user and group accounts and OUs.

• Netdom. Migrates computer accounts.

Summary of Tool Functionality

Feature ADMT ClonePrincipal Netdom MoveTree Comments

Interforest X

Intraforest X

Enables N/A

Graphical X X X

Scriptable X

Preserves X N/A ADMT, like

Preserves X X ADMT, like

Migrate users X

Migrate X

Migrate X X

Migrate trusts X X

Migrate OUs X X X

de 316

Migrate OUs X X X

Migrate user profiles

X N/A X

Migrate service accounts (update SCM)

X X X

Updates access control lists (ACLs) on resources

X N/A X

: functionality supported, X = functionality not supported by the tool

Description of Restructuring Tools

This section looks at each of the tools in some detail. The chapters in section 2 of this guide cover

usage of the tools.

Active Directory Migration Tool

ADMT is designed to support Windows NT 4.0 or Windows 2000 to Windows 2000 domain migration

scenarios, interforest and intraforest. It is implemented as an MMC snap-in, providing easy-to-use

wizards to support the most-common migration tasks. Specifically, the tool supports tasks such as:

• Mirroring trusts as needed.

• Cloning local groups updating SIDHistory.

• Cloning local groups maintaining memberships.

• Cloning local groups in user-determined groupings.

• Moving computers in user-determined groupings.

• Translating SIDs on servers and workstations if appropriate, to remove/replace redundant

SIDs.

• Changing computer accounts to reflect the new domain/OU.

Requirements

If you are using ADMT to move machine accounts only, then no system modifications are required.

However, if you need to clone users or groups, you need to set up the environment as described in

the "Configuration Requirements" section of the description of ClonePrincipal.

ClonePrincipal

ClonePrincipal is a group of sample scripts for Microsoft® Visual Basic® illustrating the usage of a

de 316

Component Object Model (COM) object that supports the cloning of users and groups. The

ClonePrincipal files, located in the support tools directory on the Windows 2000 product CD, allow an

administrator to clone users and groups between domains in different forests.

The COM object (implemented in clonepr.dll) clones a security principal from a Windows NT 4.0 or

Windows 2000 source domain into a native mode Windows 2000 domain in a different forest.

A "clone" is an account in a native mode Windows 2000 domain for which Windows NT 4.0 account

properties and group memberships have been copied from a source account. Although the clone

necessarily has a different primary SID than the source account, the SID of the source account is

copied into the clone's sIDHistory attribute. Populating the sIDHistory attribute with the SID of a

source account allows the clone to access all network resources available to the source account,

providing trusts exist from the resource domains to the clone's account domain.

Network access is preserved via sIDHistory because in a native mode Windows 2000 domain, user

interactive logon creates an access token containing not only the user's primary SID and global

group SIDs, but also the user's sIDHistory and the sIDHistory of these groups.

When to Use ClonePrincipal

ClonePrincipal is used to clone users and groups between Windows NT 4.0 and Windows 2000 source

domains and native mode Windows 2000 domains in different forests. While ADMT supports the

same functionality, ClonePrincipal consists of a set of sample Visual Basic scripts and so it can be

customized to support nonstandard migration scenarios.

You should use ADMT if:

• You want to use a graphical user interface to perform the migration, and want to be able to

select the objects.

• You want to use a single tool for all migration operations, no matter if you migrate users or

computers, or if you migrate interforest or intraforest.

You should use ClonePrincipal if you want to customize specific migration steps, such as adding

users automatically to a new group during the migration.

It is good practice not to mix the use of ADMT and ClonePrincipal for migration operations. ADMT

and ClonePrincipal use different mechanisms to detect whether objects have been moved in the

past, and mixing the tools might lead to undesired results.

Since ADMT is the most versatile and powerful tool, it most likely will be the tool of choice.

de 316

ClonePrincipal Files

The following files make up ClonePrincipal:

• Clonepr.dll. A COM server implementing helper functions.

• Sidhist.vbs. A script that copies the SID of a source principal to the sIDHistory of an

existing target principal.

• Clonepr.vbs. A script that copies the properties of a source object, and the source SID to

the sIDHistory of a target object, creating the target object if necessary.

• Clonegg.vbs. A script that clones all global groups in a domain, including well-known

global groups such as Domain Administrators, Domain Users, and Domain Guests.

• Cloneggu.vbs. A script that clones all global groups and users in a domain, including well-

known global groups such as Domain Administrators, Domain Users, and Domain Guests.

• Clonelg.vbs. A script that clones all local groups in a domain that are not well-known

accounts.

• Adssecurity.dll, Adserror.dll. Helper COM objects.

Requirements

In order for ClonePrincipal to work properly, the following conditions must be met:

• The target domain must be running Windows 2000.

• The target domain must be running in Windows 2000 native mode.

• Source domain may be running:

• Windows NT 4.0 (Service Pack 4 or later).

• Windows 2000 mixed mode.

• Windows 2000 native mode.

• For Windows NT 4.0 source domains: The machine supplied to the scripts for the source

domain must be the source domain primary domain controller (PDC).

• The source domain must not be in the same forest as the destination domain (by definition

a Windows NT 4.0 domain is not in the same forest).

• The source object must be of one of the following types:

• User.

• Security enabled group, including:

de 316

• Global group.

• Local group.

• Shared local groups (local groups created on the PDC and shared with the backup domain

controllers (BDCs) in a Windows NT 4.0 domain.

• Domain local group.

• Universal group.

The source object may not have a well-known SID (for example, Administrators, Users, and

Power Users local groups). Well-known SIDs are identical in every domain; thus, adding them

to sIDHistory would achieve very little.

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

• For Windows NT 4.0 source domains: Modify the registry on the source PDC, adding the

DWORD value TcpipClientSupport to HKLM\SYSTEM\CurrentControlSet\Control\LSA. This

value must be set to 1 to enable the Security Accounts Manager (SAM) operations required for

cloning to take place over remote procedure call (RPC).

• A trust must be created from the source domain to the target domain.

• The user carrying out the migrations must have membership of the Domain Admins group

in the target domain to clone.

• The user carrying out the migrations must also have administrator privileges in the source

domain; this can be achieved by adding the Domain Admins group from the target domain to

the Administrators group in the source domain.

• A local group must be created in the source domain called srcDomainName$$$, where

srcDomainName is the name of the source domain, that is, if the domain is called Redmond, the

group would be called Redmond$$$.

• Auditing of success and failure of account management operations must be enable in both

the source and target domains.

ClonePrincipal Syntax

This section defines the command line usage of the sample scripts. These scripts must be run on the

console of the target domain controller. They cannot be run from a remote workstation, except via a

mechanism such as Terminal Server connected to the target domain controller.

cscript sidhist.vbs /srcdc:SrcDC /srcdom:SrcDomain

de 316

/srcsam:SrcSamName /dstdc:DstDC /dstdom:DstDomain /dstSam:DstSamName

cscript clonepr.vbs /srcdc:SrcDC /srcdom:SrcDomain

/srcsam:SrcSamName /dstdc:DstDC /dstdom:DstDomain /dstSam:DstSamName

/dstDN:DstDN

cscript cloneggu.vbs /srcdc:SrcDC /srcdom:SrcDomain /dstdc:DstDC

/dstdom:DstDomain /dstOU:DstOU

cscript clonelg.vbs /srcdc:SrcDC /srcdom:SrcDomain /dstdc:DstDC


cscript clonegg.vbs /srcdc:SrcDC /srcdom:SrcDomain /dstdc:DstDC


For detailed instructions on installing and using ClonePrincipal, please refer to the ClonePrincipal

User Guide (ClonePrincUserDoc.doc) that can be found with the program files on the Windows 2000

product CD.

Netdom

Netdom is a command line utility that allows administrators to move computers between domains

and query and recreate domain trusts.

When to Use Netdom

Generally, Netdom is used in conjunction with ClonePrincipal in interforest domain migration

scenarios to move computer accounts, because ClonePrincipal can only move user and group

accounts. It also can be used without ClonePrincipal for other domain management tasks.

Requirements

Netdom has no specific configuration requirements.

Netdom Syntax

Netdom command [/d:domain] object [/options]

Command

You can think of supported commands as applying to one of two general categories:

• Commands that apply to workstations and member servers.

de 316

ADD For adding computer accounts to domains

JOIN For joining a workstation or member server to a domain

MOVE For moving a workstation or member server to a new domain

REMOVE For removing a workstation or member server from a domain

RENAME To assist in Windows NT 4.0 domain rename efforts, applies to

Windows NT 4.0 backup domain controllers.

RESET For resetting secure channel passwords upon which memberships are

based.

VERIFY For verifying the secure channel passwords between a member and its

domain

• Commands that apply to domains.

QUERY For retrieving membership and trust information from a domain

TIME For synchronizing time within a domain

TRUST For establishing, verifying, or reestablishing a trust relationship

/d:domain

Regardless of the command, you must always provide a domain. The domain name can be specified

as a Windows NT 4.0 NetBIOS name, or a Windows 2000 Domain Name System (DNS) name. If the

option is not specified, then the domain to which the current computer belongs is assumed.

For workstation and member server commands, the /d:domain flag refers to the domain to which

de 316

the workstation or member server currently belongs, or should belong, after the operation is

completed.

For the TRUST command, /d:domain always refers to the trusted domain.

Object

An object is, or is the name of, one of the following:

• Workstation

• Server

• Domain controller

• Domain

[/options]

Options available for all commands:

/Ud:[DOMAIN\]USER User account used to make the connection with the domain specified by the /d argument. If this option is not specified, the current user account is used.

/Pd:[password | *] Password of the user account specified with /Ud. If *, then password is prompted for.

/Uo:[Domain\]User User account used to make the connection with the object on which the action is to be performed. If this option is not specified, the current user account is used.

/Po:[password | *] Password of the user account specified with /Uo. If *, then password is prompted for.

/S:server Specifies a specific domain controller that an operation should be performed against. This option is useful for commands that otherwise may be performed using any domain controller in /d:domain.

/Verbose By default, only the result of the operation is reported. If the verbose operation is specified, then the output lists the success or failure of each "atomic" transaction necessary to perform the operation.

/Help Netdom /help should give brief help on all commands. Netdom command /help should give verbose help.

de 316

/Reboot[:Time in seconds] Specifies that the computer being joined or moved should be shut down and automatically rebooted after the join or move has completed. The number of seconds before automatic shutdown can also be provided. Default is 20s.

When the time has expired, any open applications are automatically closed with no file-save dialog

exposed.

Options available for the domain commands QUERY, TIME, and TRUST:

/Verify When used in conjunction with the QUERY command, the /Verify option specifies that the secure channel secrets for all enumerated memberships or trusts should be verified in addition to being displayed. Unless the user is an enterprise admin, it may not be possible to verify all secure channel secrets.

When used in conjunction with the TIME command, the /Verify option displays the synchronization

status of all domain controllers within the domain.

When used in conjunction with the TRUST command, the /Verify option checks the secure channel

secrets upon which a specific trust is based.

/Reset When used in conjunction with the QUERY command, the /Reset option specifies that the secure channel secrets for all enumerated memberships or trusts (which are currently broken) be resynchronized. The /Reset switch implies the /Verify switch. Unless the user is an enterprise admin, it may not be possible to reset all enumerated trusts or memberships.

When used in conjunction with the TIME command, the /Reset option synchronizes the clocks of

those domain controllers that are not within the allowable skew range for the domain.

When used in conjunction with the TRUST command, the /Reset option verifies the secure channel

secrets upon which the specific trust is based and resynchronizes them if necessary.

Options available for the QUERY command:

/Direct Indicates that the query for trust relationships should only return direct trust relationships rather than direct and indirect relationships. Available only when DOMAIN is specified as the object in a QUERY command.

Options available for the TRUST command:

/Add Specifies that a trust should be created.

/Remove Specifies that a trust should be broken

/TwoWay Specifies that a bidirectional trust relationship should

de 316

be established rather than a one-way trust relationship.

/Kerberos In conjunction with the /Verify option, /Kerberos specifies that the Kerberos protocol should be exercised between a workstation and a target domain.

/Flush In conjunction with /Verify and /Kerberos, indicates that the workstation's ticket cache should be purged prior to verifying the functionality of the Kerberos protocol.

MoveTree

MoveTree is a resource kit utility available only for Windows 2000 that allows an administrator to

move Active Directory objects from one Windows 2000 domain to another in the same forest. It

works across child domains as well as two separate domain trees within a forest.

When to Use MoveTree

Use MoveTree when you want to move users, groups, and OUs between Windows 2000 domains in

the same forest.

Requirements

The following conditions must be met:

• The source domain can be either a mixed mode or native mode Windows 2000.

• The target domain must always be a native mode Windows 2000 domain.

MoveTree Syntax

Movetree [/start | /continue] [/s SrcDSA] [/d DstDSA] [/sdn SrcDN]

[/ddn DstDN] [/u Domain\Username] [/p Password] [/quiet]

/start Start a MoveTree operation with /check option by default.

You could use /startnocheck to start a MoveTree operation without any check.

/continue Continue a failed MoveTree operation.

/s <SrcDSA> Source server's fully qualified primary DNS name.

/d <DstDSA> Destination server's fully qualified primary DNS name.

/sdn <SrcDN> Source subtree's root distinguished name.

/ddn <DstDN> Destination subtree's root distinguished name. Relative distinguished name plus target parent distinguished name.

/u <Domain\UserName> Domain name and user account name.

/p <Password> Password.

de 316

de 316

Domain Migration Cookbook - Chapter 5: Mature Windows 2000 Domains

Section 1:

Migration Concepts



be inferred.

Introduction

Up to now, the focus of this guide has been on migration from Microsoft® Windows NT® 4.0; in

some scenarios, the source domain will be part of a mature Microsoft® Windows® 2000 forest.

While strictly speaking, this is not a migration scenario—the source environment has already

migrated—some enterprises will want to carry out such an operation to incorporate an extensive

pilot migration into the final production Windows 2000 forest.

In such scenarios, the source domain could have fully implemented new features such as Group

Policy and the Encrypting File System (EFS).

This chapter recognizes this possibility and addresses some of the issues involved when dealing with

mature Windows 2000 source domains.

The chapter will cover:

• Protected Storage (PStore). PStore was available in Windows NT 4.0 and is significant in

this context because of the effects of migration on security identifiers (SIDs) and the way in

which PStore protects its contents.

• EFS. EFS, which became available in Windows 2000, uses PStore to store the user's private

key. As the previous paragraph implies, migration has implications for PStore.

• Group Policy. Windows 2000 introduces many new policy-based administration features.

Many of these features are applied based on user and group SIDs, which raises issues during

migration.

Protected Storage (PStore)

Secure Storage for Data

PStore provides applications with a place to store per-user data such as private keys, which must be

kept secret or free from modification. Access to data in PStore is regulated by a user-defined

security style, which specifies what kind of interactive confirmation is required for the application to

de 316

access the data—for instance, whether a password is required.

PStore is actually implemented as an opaque portion of the user's profile. As previously seen,

Microsoft® Active Directory™ Migration Tool (ADMT) will migrate user profiles. It does this by

creating a new ProfileList entry using the string representation of the migrated user's new SID as

the key. ADMT then copies the contents of the key stored under the user's old SID, including the

pointer to the user's old profile data file. This results in the old and new users sharing the same

profile file. This is not a problem because the users are the same person, just represented by

different SIDs.

Since PStore is a part of the profile data, PStore is preserved in the profile. However, as seen earlier,

PStore is opaque and is protected by encryption. Unfortunately, the keys used to encrypt and

decrypt PStore are not available to the migrated user.

Preserving PStore Contents

Microsoft is looking at ways to migrate the contents of PStore for a future release of Windows 2000.

In the meantime, if you have made extensive use of PStore and need to preserve the contents and

make them available to the migrated user, you could write a simple utility and use it as part of your

migration to:

• Use CryptoAPI to export the contents of PStore prior to migration under the security

context of the user to be migrated.

• Store the exported keys securely during migration.

• Use CryptoAPI to reimport the exported keys into the migrated user's PStore under the

security context of the migrated user.

Because very few applications have made use of PStore in Windows NT 4.0, this aspect of migration

is unlikely to cause problems for many customers. However, as companies deploy Windows 2000

and more applications use PStore functionality, this will become more of a migration consideration.

Note The system preserves the old PStore data apart from any new data the migrated user might

add. Because of this, the old data will be recoverable at any time after migration either using the

proposed Microsoft functionality or using a utility such as described above. The only requirement is

that the original profile data file is preserved.

Encrypting File System

A Secure Encryption Method

Windows 2000 provides EFS to enable users to securely encrypt data in files. EFS is implemented on

de 316

top of NTFS file system and provides users with the ability to transparently use encryption

capabilities while storing their sensitive files in NTFS.

EFS enhances the ability of the underlying file system to enforce read-and-write access control. It

does not change the access control model, which is focused on restricting access to files to

authorized individuals, as checked via system logon.

Protected Storage and Encrypting File System

EFS has taken advantage of PStore to protect its core secrets, such as keys and key management

information.

As seen in the previous section, migration currently results in the migrated user losing access to

their premigration PStore unless steps are taken to export the keys prior to migration. Because EFS

uses PStore, migration also has implications from an EFS perspective, although this is unlikely to

have a major impact initially because it affects only Windows 2000.

If you have deployed Windows 2000 and made extensive use of EFS and need to migrate users, you

should take the following steps:

• Consider deploying a utility to export keys from PStore prior to migration and reimport

them after migration as described above.

• Recommend that users decrypt their EFS-encrypted files prior to migration, and reencrypt

them after migration.

Group Policy

Defining the Rules

Windows 2000 derives many benefits from its policy-based administration. Policies express business

rules. Commonly used policies in distributed systems define how resources in the network are

accessed, configured, and used. For example, when users log on, policies determine what

applications they see on their desktops.

Policy selection is the mechanism that determines what policies should be applied to a given

operation. Specifically, policy selection is the process used to choose the policies that must be

evaluated for a given subject, object, and operation.

Each of these policies applies to particular subjects and objects, in the context of particular

operations. Evaluating all policies for all operations is expensive in terms of time and is very

inefficient—a given policy usually applies to a fairly narrow set of circumstances and is meaningless

de 316

de 316

Domain Migration Cookbook - Chapter 6: Welcome to Hay Buv Toys

Section 2:

Migration Scenarios



be inferred.

Introduction

This section takes the migration concepts discussed in Section 1 and applies them in real-world

migration scenarios involving a fictitious company, Hay Buv Toys.

This chapter and the others in this section will describe:

• Hay Buv Toys' current infrastructure and why it has evolved to the current state.

• What Hay Buv Toys would like its Microsoft® Windows® 2000 environment to look like, and

why.

• How Hay Buv Toys migrated to the desired structure.

This section will take the scenario beyond migration and describe final architecture consolidation

change after the migration to Windows 2000 is near completion.

About Hay Buv Toys

Overview

Hay Buv Toys manufactures, distributes, and sells children's toys throughout the world. The major

engineering and manufacturing sites are located in Los Angeles, Mexico City, and Hong Kong, along

with major distribution centers in Los Angeles and Hong Kong.

Hay Buv Toys has very few retail shops, since it mainly engineers, manufactures, and distributes the

toys to major retail chains, but it is exploring the possibility of Web retailing in order to sell direct to

the consumer.

Its main administrative headquarters and information technology (IT) organizations are in Los

Angeles and Paris.

Environment Background

Until roughly two years ago, Hay Buv Toys' IT infrastructure mainly consisted of department and

de 316

business unit Novell file and print servers along with many Microsoft® Windows NT® domains that

were not centrally managed. The manufacturing and engineering sites used various UNIX operating

systems as the main platform for many of their line-of-business applications and CAD systems.

The IT organization was very decentralized with each site architecting and supporting its own

environment. As a result, there were several people with CIO-like decision power throughout the

organization. This resulted in a diverse environment that was costly to manage.

Within the past two years, the IT organization has been restructuring its management structure into

a centralized model with a single CIO located at the Los Angeles headquarters.

About one year ago, Hay Buv Toys chose Microsoft Exchange as its enterprise messaging system

and developed a centralized messaging team that is located in Los Angeles. As part of the central

messaging project, the team developed and implemented a new enterprise Windows NT domain

model in order to best manage the Exchange servers. Since then, the team has created many other

enterprise services that rely on a standard Windows NT logon, such as Web sites for company health

benefits and 401K plans.

Because of the Windows-based enterprise services, most of the engineering and manufacturing sites

that were primarily UNIX based now have both UNIX- and Windows-based computers and Windows

Terminal Services.

Over the past year, Hay Buv Toys has been working on consolidating more than 16 separate

Windows NT domains that contained user, group, and computer objects into its current Windows NT

4.0 domain model to ease domain administration and provide better services to the user community.

Current Windows NT 4.0 Domain Model

Geographic Structure

Hay Buv Toys uses a geographically based multimaster domain model with two master user domains

(MUDs): one for America (United States and Mexico), where the company was originally founded,

and one for other areas of the world (England, France, and Hong Kong). The domain names of the

account domains reflect the structure: The first account domain that was created is HB-ACCT. Early

on, this single account domain was sufficient. As the company grew, the need for a second account

domain became apparent. The main driving point was network traffic created by account replication

from the PDC in Los Angeles to all locations in the world. To streamline replication, the

administrators created a second account domain for the world outside of America, HB-ACCT-ROW.

Another reason for choosing a geographic-based domain model is the fact that geography changes

de 316

less frequently than corporate structure. In the past, naming schemes based on business units

quickly became invalid after reorganizations and name changes within the businesses. Hay Buv paid

great attention to the fact that renaming the fundamental building blocks of a system is typically

very difficult once it has been rolled out and has already encountered Domain Name System (DNS)

domain and Windows NT 4.0 domain naming schemes.

The following diagram shows Hay Buv Toys' current Windows NT 4.0 domain model.


Figure 6.1

User Account Domains Description

Three Domains

The current domain model has three MUDs. The HB-ACCT and HB-ACCT-ROW domains are the IT-

supported MUDs that were created as part of the Windows NT 4.0 domain consolidation project.

These domains hold about 85 percent of all of the user accounts for the company.

The team chose two large account domains because it wanted the largest possible domains for

administration purposes, but did not want to replicate domain traffic between the United States and

Europe.

de 316

There are nearly 500 global groups throughout these account domains. These are used mainly to

check membership during logon in order to process the appropriate logon scripts. Other global

groups are used for authentication purposes to file shares and allow access to some of the line-of-

business applications.

Hay Buv Toys still has one nonstandard domain, MANUFACTURING. It has been able to stay outside

the managed domain structure because it has had, up to this point, the political clout to remain

separate.

A summary chart of the account domains is as follows:

Account domain Number of accounts Number of groups

HB-ACCT 14,000 320

HB-ACCT-ROW 8,000 100

MANUFACTURING 3,000 50

Domain Consolidation

MANUFACTURING consists of both accounts and resources in the Los Angeles and Mexico City

engineering and manufacturing facilities.

Until recently, the MANUFACTURING management team has remained separate for a number of

reasons:

• It wants to maintain complete control of its resources because it runs a continually

operating facility that needs special attention. It does not believe that a centralized

administration model can meet the demands of its users.

• It believes a domain migration may cause downtime for its users and could bring the floor

production systems to a halt, which is an unacceptable risk to its management.

• It does not want to migrate because it already has good support and access to all the

resources it needs, and team members believe they can get the enterprise IT organization to

integrate their domain into the standard domain model.

Because Windows 2000 and Microsoft® Active Directory™ have introduced these two key new

features—organizational units (OUs) and sIDHistory—the MANUFACTURING management team has

agreed to consolidate its domain into the new corporate structure.

Given the ability of Windows 2000 to delegate administration through an OU structure, the team's

demand for complete local administration of its users and resources can be met. Also, the new

de 316

sIDHistory feature of Windows 2000 for domain migrations eliminates the immediate need to redo

the access control list (ACL) for resources and allows for fallback to the old user logon if problems

occur with the migration to the new domain.

After testing the new replication features in Active Directory including store and forward replication

and compression, Hay Buv Toys also decided that a single domain model is now doable. This model

allows all users and groups to be in one domain. After evaluating five different namespace plans, the

single domain model was chosen because the overall cost of ownership was the lowest. Although a

single domain model creates more replication traffic, the following benefits made up for the costs:

• Pervasive delegation models

• Company-wide group policy settings (for user settings and software deployment)

• Easy administration

Resource Domains Description

Their Purpose

The resource domains are based on geographic groups, such as HB-RES-WC for the western half of

the United States, HB-RES-EC for the eastern part, or HB-RES-EUR for resources located in Europe.

In some single cases, a dedicated resource domain was created for storing sensitive information that

should not be saved outside the country, such as the London and Mexico facilities.

These resource domains were created to delegate administration of the resources to local

administrators without giving them full rights to the user accounts and global groups. Another

benefit of creating the computer accounts in the resource domains instead of the two large user

account domains is that this would ensure that the size of the Security Accounts Manager (SAM)

database of the user account domains would not grow to reach the recommended limit.

An exception to the resource domain naming convention is the HB-MESSAGING resource domain,

which was created for the Exchange servers in order to give access to users in the nonstandard

domains that existed when Exchange was first being implemented, and before the new domain

model was fully in place. The messaging team also wanted centralized control over the messaging

resources, which made creating a separate messaging domain an ideal solution.

Each resource domain runs a variety of resources, which are outlined in the following chart.

Resource domain Services and applications deployed

HB-RES-WC WINS, DHCP, DNS, FILE, PRINT, SQL, IIS,

de 316

HB-RES-EC WINS, DHCP, FILE, PRINT, SQL, IIS, TERMINAL, RAS

HB-RES-MEX WINS, RAS

HB-MESSAGING EXCHANGE, IIS

HB-RES-LONDON WINS, DHCP, FILE, PRINT, SQL, IIS, TERMINAL, RAS

HB-RES-EUR WINS, RAS

HB-RES-HONGKONG WINS, DHCP, FILE, PRINT, SQL, IIS, TERMINAL,

MANUFACTURING FILE, PRINT, IIS, TERMINAL, SNA, EXCHANGE

Desktop Environment Description

Windows NT Is Standard

The Hay Buv Toys desktop standard is based upon Windows NT 4.0 Workstation with SP5 and Office

97 Professional edition with Service Release 2. Some computers throughout the company still run

Windows 95 and Windows 98, but these are not a supported platform and require business

justification in order to remain on the network.

Some departments have completely deployed Windows 2000 Professional either by upgrading the

current Windows NT 4.0 standard installation or reimaging the computer with the brand new

Windows 2000 Professional image. Most of the corporation is running on a corporate standard image

that was created using Microsoft System Preparation tool (Sysprep) and cloned using either

PowerQuest Drive Image or Symantec Ghost.

Some local divisions have taken the corporate image and added or removed some applications and

settings, but for the most part, the Windows NT 4.0 installations are pretty predictable in most

environments because of desktop refresh projects that have been going on throughout the company

for the past two years.

The majority of the users have local Windows NT profiles that have been customized, and some

users, mainly the manufacturing floor workers, make use of roaming user profiles.

The desktop hardware consists mainly of Dell and Compaq brands, and the laptop hardware consists

mainly of Dell, Compaq, and IBM brands. Each site is fairly consistent with their hardware brand of

choice, with fairly up-to-date hardware, for example, Pentium 200 megahertz (MHz) with 64

megabytes (MB) of RAM or more, and most of the corporation is on a three-year hardware lease

cycle.

de 316

de 316

Domain Migration Cookbook - Chapter 7: The Desired Structure and Migration Goals

Section 2:

Migration Scenarios



be inferred.

Introduction

This chapter describes the various decisions made by Hay Buv Toys about its desired Microsoft®

Windows® 2000 environment and how it plans to carry out its migration.

This chapter covers the following areas:

• The planned Domain Name System (DNS) architecture

• Designing the Windows 2000 domain structure

• The proposed organizational unit (OU) structure

• The high-level migration steps

DNS Architecture

The Domain Decision

Hay Buv Toys has a centralized DNS team that mainly administers the hay-buv.com domain that the

company already has registered as the public Internet name for Hay Buv's external Internet

services. A few internal servers use the hay-buv.com namespace, as well as a few private

subdomains for internal servers throughout the company. For example, the mfg.hay-buv.com

domain is the largest subdomain that holds many of the UNIX servers for the manufacturing

business unit located in Los Angeles and Mexico City.

Hay Buv Toys decided that hay-buv.com would not be the Microsoft® Active Directory™ forest root

for the following reasons:

• The hay-buv.com domain was running BIND version 4.9.7 of DNS, which does not support

dynamic updates.

• There were no plans for upgrading the current environment in the timeframe necessary for

Windows 2000.

de 316

• The hay-buv.com namespace has been based on business units rather than geography, and

DNS has been successfully running this way for years. The Active Directory implementation will

not follow the same rules.

• The configuration of the proxy service for Internet browsers requires more attention if the

internal and the external DNS namespaces are the same.

As a result, the Active Directory team decided to bring up its own private root and create the hay-

buv.tld domain as the Active Directory forest root.

Designing the Windows 2000 Domain Structure

Deployment Without Disruption

Hay Buv's first goal for the deployment is to deploy Active Directory as soon as possible without

disrupting the end-user population. This will allow the administrators to build an OU structure to

delegate authority and begin applying user-based group policy for those Windows 2000 Professional

workstations that have been deployed.

The ability to delegate administration is necessary to get buy-in from the MANUFACTURING

management to consolidate their domain, since they want to maintain complete control over all of

their resources.

During the discussions of the new Windows 2000 domain structure, two designs were considered: a

single domain for all of the enterprise or multiple domains.

Single Domain

The most positive features of a single domain design are as follows:

• Easily administered. This structure has only one domain to administer and no trusts to

manage, and it truly models a central point of authority and management. Security policies like

password strength and lifetime can be set in a single location, and then applied to the whole

company.

• Easily reorganized. No migrations are necessary when everyone is in one domain because

moving users between OUs and renaming OUs is trivial.

Moving to a Single Domain

The biggest drawback to the single domain model is that a very large population, if not everyone,

would need to be migrated to the new domain.

de 316

This could be done in the following ways:

• Upgrade the largest domain and migrate into it.

It would be possible to upgrade the largest domain as the forest root domain and migrate

everyone else to this domain, but the downlevel network basic input/output system (NetBIOS)

name and the DNS name would not match, for example, the HB-ACCT NetBIOS name versus

the hay-buv.tld DNS name. This, while not a technical showstopper, could cause confusion for

administrators and users.

• Create a new, "pristine" target domain and migrate into it.

This left the choice of migrating everyone in the enterprise to the new, pristine single domain,

which did not meet the team's first deployment goal: to deploy Active Directory as soon as

possible without disrupting the end users. However, starting with a pristine domain, upgrading

some domains to Active Directory, and restructuring those domains later provided a fast track

for the community that wanted to move to Active Directory as quickly as possible.

Multiple Domains

To avoid the effort involved in remigrating the entire organization to a new domain structure, this

design performs in-place upgrades of the existing account domains.

In-place Upgrade

In-place upgrade was a very attractive choice for the HB-ACCT and HB-ACCT-ROW domains because

these are the two master account domains to which the information technology (IT) group has been

moving users and groups in the past year, and they are relatively satisfied with this domain model.

Advantages of In-place Upgrade

In-place upgrades of the account domains have a big advantage over migrating users because there

is no change in security identifier (SID) for user and group objects. As a result, an in-place upgrade

alleviates the following migration issues:

• No change in security on positions (re-ACLing). In-place upgrades do not require the

re-ACLing of resources. When you change the SID of a user or group object, you will need to

update all of the security discretionary access control lists (DACLs) for the user and group

object on all of the resources to reflect the new SID, which can be a sizable task.

• Preservation of user profiles. Again because users' SIDs don't change, they will not get

new user profiles for Microsoft® Windows NT® when logging on after the migration. This is not

the case when moving user objects to a new domain because Windows NT 4.0 user profiles are

de 316

resolved by checking only the primary SID in the access token. So, even sIDHistory does not fix

the problem of the user getting a fresh, new user profile when logging on to a new domain for

the first time. In order to save the user's profile, the user's workstation must have a software

agent applied to the computer in order to re-ACL and save the local profile. Tools such as the

Active Directory Migration Tool (ADMT) allow translating the SID that is used for the profiles.

• Easy fallback. If problems do occur with the domain upgrade or when the upgraded

domain is running in mixed mode, fallback to the Windows NT 4.0 domain is possible by

removing all Windows 2000 domain controllers and promoting a Windows NT 4.0 backup

domain controller (BDC) to the primary domain controller (PDC).

Using a Placeholder Domain

The hay-buv.tld domain would be established as a placeholder domain, and the current HB-ACCT

domain and HB-ACCT-ROW domain will be upgraded in place as children of the hay-buv.tld domain.

The placeholder domain offers an extra security benefit over a single domain, since the Enterprise

Admins and Schema Admins group would exist only in the hay-buv.tld placeholder domain. Because

this domain would have very few accounts, and very few domain administrators to keep track of, it

would help alleviate the problem of domain administrators adding themselves into either of these

groups, which have a lot of power over modifying the Active Directory structure.

Consolidating the MANUFACTURING Domain

The second goal of the Active Directory deployment is to consolidate the MANUFACTURING domain

into the new domain structure. The team considered an in-place upgrade of the MANUFACTURING

domain into the hay-buv.tld domain tree. This approach would be used after the upgrade into the

forest. The MANUFACTURING user and group objects would be migrated into the HB-ACCT domain

later. Given the timeframe of consolidating the MANUFACTURING domain, the team determined that

an interforest migration would be an easier path. Intraforest migrations are more difficult for the

following reasons.

• Migrating user and group objects within the domain tree (intraforest migration) results in a

destructive move, rather than a nondestructive "clone" that occurs when migrating from

Windows NT 4.0 to Windows 2000 (interforest migration). This is because the user and group

sIDHistory attribute must be a unique SID forest-wide, which requires an object move, rather

than a copy or clone (SID would not be unique within the forest).

• Problems with intraforest migrations occur when global groups must be migrated in order to

maintain access to resources. Global groups in intraforest migrations must be moved (rather

than cloned), which means all of the members within that global group must be migrated at the

de 316

same time in order to maintain membership within that group. On top of that, all users within

each user's group memberships must be moved in order to preserve group membership.

Finding this "closed set" of users and groups could be as big as every user and group in the

whole domain, which would make incremental intraforest migrations very difficult.

Consolidating the Resource Domains into OUs

The third goal of the deployment is to consolidate all of the resource domains into OUs in order to

eliminate trust and domain management overhead, reduce the number of domain controllers, and

begin applying computer-based group policy for Windows 2000 computers and servers.

The Active Directory team determined that resource domains were no longer necessary in the Hay

Buv environment with Windows 2000. Resource domains were created in Windows NT 4.0 mainly as

a way to delegate authority and to avoid problems with the size of the Security Accounts Manager

(SAM) database. Placing the computer accounts in separate domains from the user and global group

left more room in the SAM database in the account domains for user accounts.

The Active Directory architecture does not have these issues since delegation of authority can occur

by creating OUs within the domain, and the Active Directory database can scale to millions of objects

without problems.

The question of keeping one resource domain still remains. The HB-MESSAGING domain may be the

only resource domain that continues to exist because a major impact to the messaging system

would cause too much disruption to the organization. The Active Directory team does not have

enough information on how difficult it would be to consolidate the whole HB-MESSAGING domain

into the new domain structure. This decision has been postponed until more information is available

on what it takes to migrate the existing messaging system to the new domain, and what the

Exchange 2000 migration strategy will be.

Post-Migration Cleanup

The final goal of the migration is to clean up any remnants of the old domains or retired servers

resulting from the migration. These are items such as irresolvable SIDs in any of the resource

DACLs, the sIDHistory attribute in all of the user and group objects that were migrated to the target

domain, any broken trusts that might still be part of the domain, or old WINS entries or DNS entries

that can be removed.

Proposed Structure

Eventually, the model that promised the lowest cost of ownership, the single domain model, made

the race. The following diagram depicts the structure of the desired Windows 2000 domain

de 316

structure.

Figure 7.1

OU Structure

Setting Up a Hierarchy

As discussed earlier, the current resource domains will be collapsed into OUs. The OU structure is

based upon the current administration of the Hay Buv network. The idea behind the OU hierarchy is

to provide structure so that the design does not get out of hand and become confusing. However,

the design should not be so rigid that it does not allow local administration to take advantage of and

make efficient use of the new delegation and group policy features.

The migration team creates a top-level OU for the location of the main group of administrators. For

example, the Los Angeles (LA) OU will be created for the administrators in Los Angeles. The LA

administrators also maintain and administer the Phoenix and Seattle sites. Therefore, the Phoenix

and Seattle OUs will exist below the LA OU in the hierarchy. Each OU will contain USERS,

COMPUTERS, SHARES, and PRINTERS containers by default, but the administrators of the site OU

can customize the structure below their OU as necessary, such as the FACTORY container in the

MEXICO CITY OU that contains the factory users and resources.

The following diagram is an initial view of how the OU structure will be created. This diagram is not

meant to be a full representation of the whole OU structure.

de 316


Figure 7.2

Steps to Get to the Desired Structure

Create the Target Environment

In order to get maximum buy-off from the end users and acceptance of the project, the design team

presented the desired environment and surveyed the users for their priorities: moving to Active

Directory as quickly as possible, or migrating slowly with fallback in mind.

The results were different. While most users in America opted for the slower migration with fallback,

the majority of the user community in Europe and Asia wanted the benefits of Active Directory as

de 316

soon as possible. Therefore, two different migration strategies were chosen for the two big account

domains:

• The users and groups from the HB-ACCT domain, where the American users live, will be

migrated to the new domain.

• The HB-ACCT-ROW domain will be in-place upgraded as soon as the root domain hay-

buv.tld exists, and then added to the forest. The users and groups from this domain can later

be restructured to the hay-buv.tld domain.

The third domain that holds user accounts, the MANUFACTURING domain, will also be migrated to

hay-buv.tld. However, because this domain is a hybrid that contains both accounts and resources,

special care has to be taken in order to make sure that users will always have access to their

resources. Therefore, this domain is chosen as the last restructure target. The more experience the

team has before this critical domain is touched, the higher are the chances of a successful migration.

Consolidate Resource Domains into OUs

Another goal of the deployment is to consolidate the resource domains into OUs in order to eliminate

trust and domain management overhead, reduce the number of domain controllers, and begin

applying computer-based group policy for Windows 2000 computers and servers. This will

accomplish the following:

1. Delete old machine accounts in the resource domains and eliminate unused/rarely used servers so that unnecessary migrations are reduced.

2. Use the ADMT to migrate computer accounts from the resource domains into OUs. These migrations consist of simple computer moves between domains.

3. Use the ADMT to migrate member servers into OUs and re-ACL the computers by replacing the old SIDs with the new SIDs.

4. Demote any resource domain BDCs that need to be moved to the hay-buv.tld domain by upgrading them to Windows 2000.

Post-Migration Cleanup

Although the use of sIDHistory will guarantee that users will have access to their resources at any

stages of the migration, sIDHistory is seen as a transitional tool. Once the environment is in a stable

state after the migration, the correct domain structure should be used for granting access control

rights. Therefore, at some point after the migration, the team will change all access control lists

applied to resources so that the access control entries now point to the primary SIDs of users and

groups in the hay-buv.tld domain.

Also, removing SIDs from the sIDHistory attribute will shrink the size of the users' access tokens.

de 316

de 316

Domain Migration Cookbook - Chapter 8: Domain Upgrade

Section 2:

Migration Scenarios



be inferred.

Upgrade of the HB-ACCT-ROW Accounts Domain

Overview

Managers of the fictitious Hay Buv Toys Company decided to migrate its two biggest account

domains, HB-ACCT and HB-ACCT-ROW, in two different ways. Because the users in Europe and Asia

voted for a fast track to Microsoft® Active Directory™, the managers decided that HB-ACCT-ROW

will serve as a proof of concept for the information technology (IT) department. The goal is to bring

this domain and all users and groups to Active Directory as quickly as possible. Therefore, an in-

place upgrade is the best solution. For the second big account domain, HB-ACCT, a secure migration

path with fallback is necessary. Managers decided not to upgrade this domain, but instead to

migrate all users and groups to a new domain.

Before a domain upgrade can start, IT administrators have to make one decision: Will this domain

be a root domain for a new forest, or will it be an additional domain in an existing forest? Hay Buv

Toys decided to implement a single domain model with a domain that will carry a new Domain Name

System (DNS) name, hay-buv.tld. The HB-ACCT-ROW Windows NT® 4.0 domain could be used as

the new domain, and the DNS name of the domain could be different from the NetBIOS name, which

cannot be changed as part of an upgrade.

In order to have a clean environment with regards to naming, the IT department decided to absorb

the higher costs first and create a new domain hay-buv.tld, in-place upgrade HB-ACCT-ROW, and

migrate all users and groups later. Therefore, the hay-buv.tld domain had to be installed first.

de 316


Figure 8.1

After the upgrade, the HB-ACCT-ROW domain will join the forest and become a child domain of hay-

buv.tld. All trust relationships with the pre-Active Directory resource domains will also be upgraded

in place.


Figure 8.2

In addition to the earlier version trusts to the resource domains, hb-acct-row will now have a

bidirectional, transitive trust to its parent domain, hay-buv.tld.

Checklist

Leveraging experiences from the test lab and a pilot deployment, the planning team assisted the

de 316

deployment team in creating checklists for the production deployment. The purpose of the list is to

make sure that steps happen in the right order and to prevent any oversights. Besides the order of

steps, the list defines specific checkpoints.

Here is a high-level summary of the checklists:

Pre-upgrade work

• Determine domain controller hardware

• Can the primary domain controller (PDC) be upgraded?

• Can all domain controllers be upgraded?

• Create machine assignment table

• Secure domain data

• Back up the PDC

• Take the backup domain controller (BDC) offline

• New or existing BDC

• If the PDC cannot be upgraded, purchase new machine, install as a BDC, promote to PDC,

and take old BDC offline (ensures full sync)

• Install Microsoft® Windows® 2000 member server in domain (second replica later)

• If the PDC cannot be upgraded, install new computer as Windows NT 4.0 BDC

• Promote new Windows NT 4.0 BDC to PDC (guarantees full synch)

• Take old PDC offline and secure

• Create test matrix

Upgrade PDC (mixed mode domain)

• Configure remaining Windows NT 4.0 BDC as LMRepl export server for logon scripts

• Upgrade PDC -> Microsoft® Windows® 2000

• Verify DNS configuration on Windows 2000 server

• Promote former Windows NT 4.0 PDC to domain controller (as child of root domain)

• Test environment (create user, create logon script, check access, check trusts)

• Synchronize file replication services

de 316

• Standard operations validation

Install additional domain controllers

• Promote Windows 2000 member server to domain controller

• Upgrade Windows NT 4.0 BDCs, decide whether to decommission, and keep as member

server or dcpromo

Switch to native mode

When all domain controllers are Windows 2000, switch to native mode.

Checkpoints

• Freeze environment

• Post-dcpromo validation

• Standard operations procedures in effect

• Standard operations procedures in effect after switch to native mode

Preupgrade Work

During the preupgrade phase, administrators determine what hardware is currently used as domain

controllers in the HB-ACCT-ROW domain and whether these domain controllers can be used as

Microsoft® Windows® 2000 Active Directory domain controllers. They also secure data before the

environment is frozen (checkpoint No. 1).

Determine Domain Controller Hardware

The hardware requirements on Windows 2000 Active Directory domain controllers are higher than

those of Windows NT 4.0. The minimum requirements for domain controllers are Pentium 200

servers with at least 64 megabytes (MB) of memory. If many users are logging on to this domain

controller, more powerful hardware should be chosen.

If administrators decide that new hardware is required, the new computers can be installed in the

preupgrade phase and added to the existing domain.

For the HB-ACCT-ROW domain, the following domain controllers exist:

Server name Server role Server Upgradable?

HB-ACCT-ROW-DC1 PDC Pentium 500 Yes

HB-ACCT-ROW-DC2 BDC Pentium 500 Yes

de 316

HB-ACCT-ROW-DC3 BDC Pentium 133 No

HB-ACCT-ROW-DC4 BDC Pentium 133 No

Create Computer Assignment Table

The inventory of the Windows NT 4.0 domain controllers shows that only two of the four domain

controllers can be upgraded to Windows 2000 Active Directory domain controllers. However, in order

to guarantee reliability and performance of logon operations, the IT department decided that it

needs at least three domain controllers. Another goal is to find new roles for the Windows NT 4.0

domain controllers that cannot be upgraded.

To ensure that the domain can be reverted completely to Windows NT 4.0 without the influence of

Windows 2000 and Active Directory, one computer will be separated from the network before the

upgrade begins and stored in a safe location. In case of any problems during or after the upgrade of

the domain, this computer can be brought back to the domain and promoted to the new PDC in the

domain. This will reset the state of the domain to where it was before the migration began.

Since HB-ACCT-ROW-DC3 cannot be upgraded to a Windows 2000 domain controller, this computer

is used as the backup computer.

HB-ACCT-ROW-DC4 is the second computer that cannot be used as a Windows 2000 domain

controller, but it can still work as a file and print server. There are two options to convert this

computer to a member server: Either reinstall Windows NT 4.0 and configure the computer as a

member server during setup, or upgrade the computer to Windows 2000 and keep it as a member

server. Because the computer will be used mostly for network access and not for intensive user-

interface operations, the computer will be upgraded. This provides the easiest migration path to a

member server. If the computer is reinstalled, all resources must be re-ACLed again on the

computer.

Lastly, another requirement is to have three domain controllers in the Active Directory domain. The

IT department decided to install a new server with the Windows 2000 operating system and add this

computer as a member server to the domain before starting the upgrade. This ensures that the

computer is immediately available to be promoted to a second replica after the PDC is upgraded.

However, the computer also can be installed after the PDC upgrade and then promoted to a domain

controller.

The following table shows the computers and role assignment before and after the upgrade:

Server name Role before upgrade Role after upgrade

de 316

HB-ACCT-ROW-DC1 PDC Domain controller (PDC operations master)

HB-ACCT-ROW-DC2 BDC Domain controller

HB-ACCT-ROW-DC3 BDC Decommissioned (member server)

HB-ACCT-ROW-DC4 BDC Decommissioned

HB-ACCT-ROW-DC5 Member Domain controller

Install a New Member Server

Windows 2000 member servers can be installed into Windows NT 4.0 domains at any time and

without any special considerations. As members in a Windows NT 4.0 domain, Windows 2000

member servers behave like Windows NT 4.0 member servers. They have their own Security

Accounts Manager (SAM) database that can be used to create local users and local groups. Domain

users and domain global groups from either this domain or any domain that is trusted by this

domain can be added as members to the local groups.

When the Windows 2000 server is installed, the domain membership can be set either during the

installation process or later by changing the network identification of the server.

To change the network identification, right-click on the My Computer icon on the desktop and

select Properties.

After you restart the computer, the Windows 2000 member server will appear in the Windows NT

4.0 Server Manager. Because the server manager is running on a Windows NT 4.0 machine, the

operating system version is read as Windows NT 5.0 Server.

Figure 8.3

Secure Domain Data

Before upgrading the first computer, administrators must save the domain database with all user

and group accounts as well as domain-specific security settings. They can do this in one of two

ways:

de 316

• Back up the PDC and at least one BDC.

• Synchronize one domain controller with the PDC, remove the computer from the network,

and store the computer.

Before administrators secure the domain database, they should make sure that the domain is stable

and apply all pending changes first. If, for example, new users have joined the company,

administrators should create the users now and add them to groups. It is important to realize that if

the domain has to be reset to Windows NT 4.0 and later backup tapes do not work, this will be the

state of the domain.

The IT department decided to back up the PDC plus at least one BDC. Therefore, administrators

create backup tapes of HB-ACCT-ROW-DC1 and HB-ACCT-ROW-DC2, label them as preupgrade

domain backups, and store them in a safe location.

After the upgrade, two domain controllers will be decommissioned: HB-ACCT-ROW-DC3 and HB-

ACCT-ROW-DC4. While one computer, HB-ACCT-ROW-DC3, will be substituted for a new Windows

2000 Active Directory domain controller and kept as a member server, the other computer will be

used as fallback domain controller. If anything goes wrong in the new Active Directory domain, all

Windows 2000 domain controllers can be removed and HB-ACCT-ROW-DC3 can be brought back into

the domain and promoted as a new PDC. As long as the domain has not been switched back into

native mode, all Windows NT 4.0 domain controllers will now accept the HB-ACCT-ROW-DC4 as PDC

again and will replicate changes. This will bring the domain back to the state where it was before the

upgrade was started.

To synchronize HB-ACCT-ROW-DC4 with the PDC:

1. Open the User Manager for Domains on any domain controller.

2. Select HB-ACCT-ROW-DC4.

3. In the Computer menu, select Synchronize with Primary Domain Controller.

4. You will see a dialog box displayed by the server manager that warns you that this action might take some minutes. Select Yes to perform the synchronization.

5. A new dialog box will appear that confirms the action. Select OK.

de 316


Figure 8.4

6. Verify that the following entry appears in the event viewer: system logon HB-ACCT-ROW-DC4:


Figure 8.5

Now that HB-ACCT-ROW-DC4 is in sync with the PDC, it should be removed from the network and

moved to a secure location, like a storage room. The administrators should label it as the replica of

the original HB-ACCT-ROW domain and warn that it must not be touched.

At this point, the administrators should make no further changes to the domain database until the

PDC is upgraded, and they should create no new users or groups.

Now you have reached checkpoint No. 1, freeze of the Windows NT 4.0 environment.

Create a Test Matrix

Hay Buv Toys strictly follows the master/resource domain model: Only user and group accounts are

located in the account domains; all workstations and resources such as file and print servers are in

the resource domains. Local groups are used to grant access to resources.

de 316

To test a successful migration, tests need to include logon operations in the resource domain using

accounts from the domain that was upgraded.

The hb-reswc domain was chosen as test field:

Four computers are in the hb-reswc domain:

Computer name Domain Role

HB-RESWC-PDC HB-RESWC PDC File server

HB-RESWC-MEM1 HB-RESWC Member server File server Internet Information Services (IIS) Server

HB-RESWC-WS1 HB-RESWC User workstation

Figure 8.6

Among others, the following accounts were created:

Domain/computer Name Account type Group members

HB-ACCT-ROW FrankK User N/A

HB-ACCT-ROW EvaL User N/A

HB-ACCT-ROW Development Global group HB-ACCT-ROW\FrankK

HB-RESWC Test Local group HB-ACCT-ROW\Development

HB-RESWC-MEM Marketing Local group HB-ACCT-ROW\Development

Additional properties have been assigned to user FrankK through User Manager for Domains. These

properties are:

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

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

3. Dial-in permission: granted.

The same attributes have been assigned to user EvaL. In addition, another property has been

de 316

assigned to user EvaL using the User Manager for Domains:

4. Profiles Path: \\HB-ACCT-ROW-DC1\Profiles

Only EvaL has access to the directory \\HB-ACCT-PDC\Profiles\EvaL. Ensure that the appropriate file

permissions are set to the directory and files.

These attributes will be verified after FrankK is migrated. In addition, for user EvaL, the roaming

profile attribute will be verified after this account is migrated.

For access checks after the various upgrade steps, the following access restrictions were created:

Resource Access rights

\\HB-RESWC-PDC\Sources HB-RESWC\Test: FC

\\HB-RESWC-PDC\RankK HB-ACCT\FrankK: FC

\\HB-RESWC-MEM\Specifications HB-RESWC-MEM\Marketing: FC

FC = Full control

After groups and users are migrated, the access to resources must be checked.

Test Success/fail

User HB-ACCT\FrankK can logon to workstation HB-RESWC-WS1

User HB-ACCT\FrankK can access \\HB-RESWC-PDC\Sources

User HB-ACCT\FrankK can access \\HB-RESWC-MEM\Specifications

User HB-ACCT\FrankK can NOT access \\HB-RESWC-PDC\EvaL

User HB-ACCT\EvaL can logon to workstation HB-RESWC-WS1

User HB-ACCT\EvaL can NOT access \\HB-RESWC-PDC\Sources

User HB-ACCT\EvaL can NOT access \\HB-RESWC-MEM\Specifications

User HB-ACCT\EvaL can access \\HB-RESWC-PDC\EvaL

Upgrade PDC (Mixed Mode Domain)

As soon as the PDC is upgraded to Windows 2000 and promoted to a domain controller again, the

domain will be a Windows 2000 Active Directory mixed mode domain. For earlier version clients, this

change will be transparent. For domain controllers, however, some restrictions require preparation

work:

• If the new Active Directory is not a forest root domain, the PDC must be able to locate

either a parent domain or the forest root using DNS.

de 316

• Windows 2000 domain controllers do not replicate files using the LMRepl file replication

service to Windows NT 4.0 domain controllers.

Configure LMRepl File Replication Service

Because the PDC won't be able to play the role as LMRepl export server after the operating system

upgrade, another computer must be configured to play this role until all Windows NT 4.0 domain

controllers have disappeared from the domain. Ideally, this should be the last Windows NT 4.0

domain controller that will be upgraded or decommissioned.

In the case of the HB-ACCT-ROW domain, the domain controller HB-ACCT-ROW-DC3 cannot be

upgraded to a Windows 2000 domain controller. Therefore, this domain controller is selected as the

computer that is kept as the last Windows NT 4.0 domain controller.

The following instructions assume that the directory replication service is used and correctly

configured in the HB-ACCT-ROW domain. The PDC, HB-ACCT-ROW-DC1, serves as the export

server, while all other domain controllers serve as import servers. For more information on how to

configure the Windows NT 4.0 directory replication service, please check the Windows NT 4.0 help

files.

To configure the LMRepl file replication service on HB-ACCT-ROW-DC3:

1. Open the Server manager on any domain controller (or workstation where the administration tools are installed).

2. Select HB-ACCT-ROW-DC1.

3. In the Computer menu, select Properties.

4. In the Properties dialog box, select the Replication button. The dialog should show that the PDC HB-ACCT-ROW-DC1 serves as both LMRepl export and import server.

de 316

Figure 8.7

5. Disable the export functionality by selecting Do Not Export.

6. Click OK, and then click OK again to close all dialogs. Now the PDC is only an import server.

7. To configure the new LMRepl export server, select HB-ACCT-ROW-DC3.

8. Open the Properties dialog box again, and then open the Replication dialog box. HB-ACCT-ROW-DC3 is configured as import server only.

Figure 8.8

9. Select Export Directories.

10. Click the Add button, and select the HB-ACCT-ROW domain as target domain.

Figure 8.9

11. Click OK. HB-ACCT-ROW-DC3 is now configured as the export server.

12. Click OK and then click OK again to close all dialog boxes.

13. Restart the directory replication service on all domain controllers.

de 316

To test the configuration, create an empty file called test2.bat in the

<system>\system32\repl\expor\scripts folder on HB-ACCT-ROW-DC3. Wait approximately 5

minutes and check whether the file has been copied to \\HB-ACCT-ROW-DC1\netlogon, \\HB-ACCT-

ROW-DC2\netlogon, and \\HB-ACCT-ROW-DC3\netlogon. If so, delete the file from HB-ACCT-ROW-

DC4 again. This will also remove the files from HB-ACCT-ROW-DC3 and HB-ACCT-ROW-DC2 again.

After the PDC is upgraded, a script will be added to synchronize the logon scripts created on the

Windows 2000 PDC operations master role owner and the Windows NT 4.0 LMRepl export server

(see below).

Upgrade PDC to Windows 2000

The next step is to upgrade the operation system on the Windows NT 4.0 PDC. This can easily be

done by inserting the Windows 2000 Server or Advanced Server domain controller and following the

instructions presented by the wizard, or by upgrading over a network share by executing

Winnt32.exe.

Note Before Active Directory is installed on the server, the TCP/IP needs to be configured so that

the machine points to a DNS server that fulfills the Active Directory requirements. This can be

achieved in one of two ways:

• DNS is installed on the server and a new zone is created in DNS that matches the name of

the Active Directory domain. In that case, a delegation entry has to be added to the DNS server

that is higher in the hierarchy.

• The server can point to a domain controller in the future parent domain hay-buv.tld that

runs the DNS server. Then the necessary DNS entries can be created on that DNS server.

Since the child domain will live only during a transition time and be restructured into the parent

domain later, the IT team selected the second choice.

1. To upgrade the PDC, insert the Windows 2000 Server or Advanced Server CD-ROM in the CD-ROM drive on HB-ACCT-ROW-DC1.

2. The Windows 2000 installation wizard will start automatically and present a dialog that asks whether you want to upgrade the system to Windows 2000.

3. Select Yes to upgrade the system.

4. The Windows 2000 installation wizard then will present a dialog box that allows you to either upgrade the system or create a new install. Select Next to upgrade to Windows 2000.

5. Accept the license agreement in the next dialog box, and click Next.

6. In the next dialog box, select Upgrade the file system (to NTFS5), and click Next.

7. The system now starts copying files and will restart after some necessary system files are on the boot partition.

de 316

8. The rest of the upgrade process runs automatically and requires no user input. After the server restarts, the Active Directory Installation Wizard starts automatically.


Figure 8.10

Make sure that the DNS entries are correct before you run the wizard.

Verify DNS Configuration

In order to find Active Directory domains, the TCP/IP configuration on the server must point to at

least one DNS server that is authoritative for the zone that stores the DNS domain for the new

parent domain or the forest root. Because the Net Logon service on Active Directory domain

controllers publishes SRV records in DNS, it is good practice to use a fixed IP address for the domain

controller and no Dynamic Host Configuration Protocol (DHCP) address.

To configure the DNS settings on the PDC:

1. On the desktop, right-click My Network Places and select Properties. The Network and Dial-up Connections window will appear.

de 316


Figure 8.11

2. Select the icon that is used for your network connection (typically, the Local Area Connection), right-click, and select Properties.

3. In the Local Area Connection Properties dialog box, select Internet Protocol (TCP/IP), and click Properties.

4. In the Internet Protocol (TCP/IP) dialog box, make sure there is at least one entry for a DNS server that holds the DNS domain of either the parent domain, and/or the root domain. If there is no entry, add the IP address of the DNS server(s).

de 316

Figure 8.12

5. Close all dialog boxes.

To test the configuration, open a command prompt, and use the ping utility on the domain name of

the future Active Directory domain (not a server name). In this example, the future parent domain is

hay-buv.tld.


Figure 8.13

de 316

If the search turns up a domain controller, the child domain can be installed.

To install the child domain, switch back to the wizard. Then follow these steps:

1. In the Active Directory Installation Wizard, select Next.

2. In the next dialog box, select To create a new child domain in an existing domain tree, and click Next.

3. In the next dialog box, provide credentials that have administrator rights in the new parent domain. This account must have Enterprise Admin rights to create a new child domain. Click Next.


Figure 8.14

4. The next dialog box asks for the name of the new parent domain. Click the Browse button and select the parent domain hay-buv.tld, then click OK to return to the domain name dialog box.

de 316

Figure 8.15

5. Enter the name of the new domain. In this case, this is hb-acct-row. Note that the DNS name of the domain can be identical to the network basic input/output system (NetBIOS) name, but it does not have to be.


Figure 8.16

6. In the next two dialog boxes, confirm that you want to use the proposed locations for the Active Directory database file, the log files, and the SYSVOL by clicking Next.

7. The next dialog box asks for a password for offline mode. This is used when the administrator needs to start the domain controller in a directory offline mode. In this mode, Active Directory is not running on the domain controller. Therefore, a special password must be

de 316

used to log on. Provide an offline defragment password and click Next.

8. The last dialog box presents a summary of the options. Confirm this by clicking Finish.

9. The installation wizard now starts the promotion process, during which it copies data from the domain controller in the parent domain. After the installation is finished, the server has to be restarted.

After restarting the computer, the administrator tests the Active Directory service. To do this,

perform the following steps:

1. Click the Start button and select Progams. Then select Administrative Tools, and then select Active Directory Domains and Trusts. There is a hierarchy of at least two Active Directory domains.


Figure 8.17

2. Right-click the hay-acct-row.hay-buv.tld domain, and select Manage. This opens the Active Directory Users and Computer MMC snap-in.

3. In the Active Directory Users and Computer manager, open the Domain Controllers organizational unit. You should see four domain controllers.


Figure 8.18

4. Open the Users container. You should see all users and groups that were created in the Windows NT 4.0 domain, including FrankK, EvaL, and the Development group:

de 316


Figure 8.19

5. On one Windows NT 4.0 BDC (such as HB-ACCT-ROW-DC2), open the Event Viewer, and then open the System Log.

6. When the PDC was promoted on Windows 2000 to a domain controller again, some new objects were created. These objects were replicated to the BDCs. Make sure that you find an event with the ID 5715 in the log that identifies a partial sync from a PDC to a BDC.

de 316

Figure 8.20

7. Open the Server Manager on one of the BDCs. The PDC now shows up as a Windows 2000 computer (Windows NT 5.0 Primary).

Figure 8.21

8. Open a command prompt and use the nltest.exe tool to test the domain status (you can find nltest.ext in the support tools folder on your Windows 2000 Server CD-ROM).

Type nltest.exe /parentdomain to test for the parent domain:

E:\tools>nltest /parentdomain

hay-buv.tld (1)

The command completed successfully

de 316

Type nltest /bdc_query:hb-acct-row to test the replication status of the BDCs. Note: Since

HB-ACCT-ROW-DC4 was removed from the network, it should not appear in this list:

E:\tools>nltest /bdc_query:hb-acct-row

Server : \\HB-ACCT-ROW-DC2

SyncState : IN_SYNC

ConnectionState : Status = 0 0x0 NERR_Success

Server : \\HB-ACCT-ROW-DC3

SyncState : IN_SYNC

ConnectionState : Status = 0 0x0 NERR_Success

The command completed successfully

Check that all trust relationships are in place:

On the PDC, in the Active Directory Domains and Trusts manager, right-click the hb-

acct-row.hay-buv.tld domain and select Properties. In the properties dialog box, select

the Trusts tab. You should see the following trusts:

a. A parent-child trust relationship to the parent domain hay-buv.tld

b. An external (Windows NT 4.0-style trust) to the resource domain HB-RES-WC.

Figure 8.22

de 316

b. To verify the trusts, select one entry (such as HB-RES-WC), and click Edit. The dialog box will present information about this trust relationship (here, that it is an incoming, nontransitive trust).

Figure 8.23

c. Click Verify and enter administrator credentials for the resource domain.

d. The next dialog box will tell you that the trust had been verified and is in place.

Figure 8.24

9. On all BDCs, open the Event Viewer and make sure there are no entries that say "Change log corrupt." Get an event number.

10. On all BDCs, make sure there are no full or partial sync errors.

11. On the PDC, create a new user, FredM.

de 316

Figure 8.25

12. On all BDCs, make sure that the new user appears in the User Manager (this does not mean that the user was replicated because the User Manager always connects to the PDC).

13. Wait 5 minutes and then check the BDCs. You should see a partial sync event 5715 that was created after the user was replicated from the PDC.

14. Disconnect the PDC from the network and log on to the workstation HB-RESWC-WS1 using the user account FredM. If the logon succeeds, the trust relationships are in place and replication to the BDCs works. Connect the PDC to the network again.

15. On the PDC, open a command prompt and execute repadmin.exe to check the replication status with the parent domain. You can find repadmin.exe in the support tools folder on the Windows 2000 Server CD-ROM. Repadmin will show you whether the last replication tries were successful or not:

E:\tools>repadmin /showreps

Default-First-Site-Name\HB-ACCT-ROW-DC1

DSA Options : (none)

objectGuid : 886a40f9-c627-4b82-a351-9505b2ea2149

invocationID: a4354106-b63c-4244-a3ba-ab6f61368c3a

==== INBOUND NEIGHBORS ======================================

CN=Schema,CN=Configuration,DC=hay-buv,DC=tld

Default-First-Site-Name\HAY-BUV-DC1 via RPC

objectGuid: ab24c9b4-a13c-487a-b7c4-9faf86368d33

Last attempt @ 2000-03-17 18:57.21 was successful.

CN=Configuration,DC=hay-buv,DC=tld

de 316




==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============

DC=hb-acct-row,DC=hay-buv,DC=tld









E:\tools>

16. Use the dcdiag tool to test the Active Directory. Open a command prompt and execute dcdiag.exe without any parameters. Dcdiag is also included in the support tools on the Windows 2000 Server CD-ROM. For an explanation of the tests, run dcdiag /?.

E:\tools>dcdiag

DC Diagnosis

Performing initial setup:

Done gathering initial info.

Doing initial non skippeable tests

Testing server: Default-First-Site-Name\HB-ACCT-ROW-DC1

Starting test: Connectivity

......................... HB-ACCT-ROW-DC1 passed test

Connectivity

Doing primary tests

de 316


Starting test: Replications


Replications

Starting test: NCSecDesc

......................... HB-ACCT-ROW-DC1 passed test NCSecDesc

Starting test: NetLogons

......................... HB-ACCT-ROW-DC1 passed test NetLogons

Starting test: Advertising


Advertising

Starting test: KnowsOfRoleHolders


KnowsOfRoleHolders

Starting test: RidManager

......................... HB-ACCT-ROW-DC1 passed test RidManager

Starting test: MachineAccount


MachineAccount

Starting test: Services

......................... HB-ACCT-ROW-DC1 passed test Services

Starting test: ObjectsReplicated


ObjectsReplicated

Starting test: frssysvol

......................... HB-ACCT-ROW-DC1 passed test frssysvol

Starting test: kccevent

......................... HB-ACCT-ROW-DC1 passed test kccevent

Starting test: systemlog

......................... HB-ACCT-ROW-DC1 passed test systemlog

Running enterprise tests on : hay-buv.tld

Starting test: Intersite

......................... hay-buv.tld passed test Intersite

Starting test: FsmoCheck

......................... hay-buv.tld passed test FsmoCheck

de 316

E:\tools>

17. After these preliminary tests, take the test matrix defined above and perform all tests. These should work as well as before the PDC upgrade.

If all checks are successful, the new domain controller is functioning properly.

This brings the process to checkpoint No. 2. The domain is now an Active Directory mixed mode

domain that can fully participate in the Active Directory forest and benefit from transitive Kerberos

trusts and so on. For Windows NT 4.0 clients, the transition is transparent; they can log on to either

a Windows NT 4.0 BDC to or the new Windows 2000 domain controller. Windows 2000 clients,

however, always log on to mixed or native mode domains using Kerberos trusts and therefore can

only log on to Windows 2000 domain controllers, not the Windows NT 4.0 BDCs. In order to balance

the load for Windows 2000 client logons and make the system robust, one or more additional

domain controllers should be provided soon.

Synchronize File Replication Services

The two file replication services, LMRepl for Windows NT 4.0 and NT File Replication service (NTFRS)

for the SYSVOL on Windows 2000, are not compatible, meaning they do not replicate files between

them. Therefore, administrators have to create a manual process that copies new scripts from the

logon folder in the SYSVOL to the LMRepl export folder on the Windows NT 4.0 domain controller.

The easiest way to perform this operation is as follows:

1. On the Windows NT 4.0 domain controller, which was configured as LMRepl export server, create a batch file that copies all files from the netlogon share on the PDC to the <repl\export\scripts> folder.

2. Add this batch file to the list of tasks that are executed once a day by the scheduling service.

3. Configure the scheduling service to use a user account that has the rights to access the netlogon share on the PDC. Simple user rights are sufficient.

Note The Windows 2000 Server Resource Kit has a more sophisticated script called lmbridge.cmd. It

allows use of either xcopy or robocopy.

To create the batch script:

1. On HB-ACCT-ROW-DC3 (the LMRepl export server), create the following batch file:

Net use o: /delete

Net use o: \\hb-acct-row-dc1\netlogon

Echo y| copy o:\*.* %systemroot%\system32\repl\export\scripts

de 316

Net use o: /delete

2. Save the batch file, for example, as c:\tools\brepl.bat.

3. Open a command prompt and type the following command to configure the schedule service:

at 12:00am /every:m,t,w,th,f,sa,su c:\tools\brepl.bat

4. Open the server manager, select HB-ACCT-ROW-DC3, and select Services from the Computer menu.

5. In the Services dialog box, select Schedule in the Service box, and click Startup.

6. In the Service dialog box for the Schedule service, select Automatic as startup type. In the Log On As: section, select This Account, and press the browse button (…). The object picker dialog opens. Select a user account in the object picker that has read access to the netlogon share on the PDC, like the repl service account that is used by the LMRepl directory synchronization service, and click OK.

7. Enter the password that is used by this account.


Figure 8.26

8. Press OK and then click Close to close all dialogs.

To test the synchronization, create a new empty logon script called test3.cmd in the logon scripts

folder on the Windows 2000 domain controller. Execute the script manually and check whether it

appears on all Windows NT 4.0 domain controllers in the repl\import folder.

Standard Operations Validation

At this point, all standard operations have to be validated. This includes tools as well as procedures.

de 316

If, for example, customized tools were used in the Windows NT 4.0 domain to push new users from

a human resources system to Windows NT, these have to be tested again in the production

environment. At this point, a full fallback is still possible without any data loss.

After the validation of the standard procedures, checkpoint No. 3 is reached and the normal daily

routine can begin again.

Install Additional Domain Controllers

As pointed out above, it is good practice to provide at least one more Windows 2000 domain

controller very quickly. This can be done in two different ways:

• A Windows 2000 member server can be promoted to domain controller.

• The existing Windows NT 4.0 BDCs can be upgraded to Windows 2000 and promoted to

domain controllers.

Promote Windows 2000 Member Server to Domain Controller

Hay Buv Toys wants to make sure that Windows NT 4.0 and Windows 2000 Professional clients can

always log on. The fastest way to ensure that not all Windows 2000 clients depend on a single

domain controller is to promote the Windows 2000 member server to a domain controller before

upgrading additional Windows NT 4.0 domain controllers.

To promote the member server HB-ACCT-ROW-DC5 to a domain controller, verify first that the

server is configured to query the right DNS server. Ensure this by searching the domain again:

F:\>ping hb-acct-row.hay-buv.tld

Pinging hb-acct-row.hay-buv.tld [12.1.1.2] with 32 bytes of data:

Reply from 12.1.1.2: bytes=32 time<10ms TTL=128




Ping statistics for 12.1.1.2:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

de 316

F:\>

The partition that will hold the SYSVOL must be an NTFS 5 partition. If it is not, it can be converted

using the convert command:

convert c: /fs:ntfs

This converts the c: partition to NTFS. If the converted partition is the partition where the system

files live, the computer has to be restarted for the conversion.

To promote the member server to a domain controller:

1. Open a command prompt.

2. Type dcpromo to start the Active Directory Installation Wizard.

3. In the Welcome dialog box, press Next.

4. This time, add a domain controller to an existing domain. Select Additional domain controller for an existing domain in the Domain Controller Type dialog box. Then click Next.


Figure 8.27

5. In the Network Credentials dialog box, enter the name for an account with administrative rights in the hb-acct-row.hay-buv.tld domain, enter the password, and then click Next.

6. The next dialog already presents the hb-acct-row.hay-buv.tld domain as domain name. You could specify a different domain here. For this example, confirm that this is the right domain by clicking Next.

7. The next two dialog boxes again ask for the location of the Active Directory database, the log files, and the SYSVOL. Accept the defaults and click Next.

de 316

8. In the next dialog box, you must specify a password for the offline mode. Note that this password is unique for this domain controller. Add a password and note it.

9. Confirm your settings by clicking Next in the Summary page.

10. Now the promotion process starts. Restart the computer after the wizard has finished.

After the computer restarts, the domain controller has to be tested. The following tests should be

performed:

1. Run dcdiag.exe as above. No errors should be reported.

F:\tools>dcdiag

DC Diagnosis

Performing initial setup:

Done gathering initial info.

Doing initial non skippeable tests


Starting test: Connectivity


Connectivity

Doing primary tests


Starting test: Replications


Replications

Starting test: NCSecDesc

......................... HB-ACCT-ROW-DC5 passed test NCSecDesc

Starting test: NetLogons

......................... HB-ACCT-ROW-DC5 passed test NetLogons

Starting test: Advertising


Advertising

Starting test: KnowsOfRoleHolders


de 316

KnowsOfRoleHolders

Starting test: RidManager

......................... HB-ACCT-ROW-DC5 passed test RidManager

Starting test: MachineAccount


MachineAccount

Starting test: Services

......................... HB-ACCT-ROW-DC5 passed test Services

Starting test: ObjectsReplicated


ObjectsReplicated

Starting test: frssysvol

......................... HB-ACCT-ROW-DC5 passed test frssysvol

Starting test: kccevent

......................... HB-ACCT-ROW-DC5 passed test kccevent

Starting test: systemlog

......................... HB-ACCT-ROW-DC5 passed test systemlog

Running enterprise tests on : hay-buv.tld

Starting test: Intersite

......................... hay-buv.tld passed test Intersite

Starting test: FsmoCheck

......................... hay-buv.tld passed test FsmoCheck

F:\tools>

2. Run nltest as above. No errors should be reported.

3. Run repadmin /showreps. You should see more replication partners as before. Both HAY-BUC-DC1 and HB-ACCT-ROW-DC1 should appear as replication partners. The last replication tries should be noted as successful.

F:\tools>repadmin /showreps

Default-First-Site-Name\HB-ACCT-ROW-DC5

DSA Options : (none)

objectGuid : 09b3c2f6-9475-48b6-805d-90ac4927baed

invocationID: d26abd96-e2f4-47d1-8c12-addace280c68

==== INBOUND NEIGHBORS ======================================

de 316


Default-First-Site-Name\HB-ACCT-ROW-DC1 via RPC

objectGuid: 886a40f9-c627-4b82-a351-9505b2ea2149
















==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============













de 316




F:\tools>

4. Create a user called MariaV on hb-acct-row-dc5. Wait approximately 10 minutes. Then disconnect both Windows 2000 domain controllers from the network. From the workstation hb-resws-ws1, log on as MariaV. If this succeeds, replication works between the Windows 2000 domain controllers as well as from the Windows 2000 PDC operations master role owner to the Windows NT 4.0 domain controllers.

5. Perform all other tests as defined in the test matrix.

Upgrade Remaining Windows NT 4.0 BDCs

The next step is to upgrade all Windows NT 4.0 BDCs to Windows 2000 and either promote them to

domain controllers again or leave them as member servers.

Hay Buv Toys has two Windows NT 4.0 domain controllers left, HB-ACCT-ROW-DC2 and HB-ACCT-

ROW-DC3. While HB-ACCT-ROW-DC2 can be used as Windows 2000 domain controller, HB-ACCT-

ROW-DC3 will be converted to a member server.

To upgrade the operating system on HB-ACCT-ROW-DC2, follow the same steps as for HAY-ACCT-

ROW-DC1. After Windows 2000 is installed and the computer is restarted, the Active Directory

Installation Wizard starts up automatically again. No matter whether you want to install Active

Directory on the server or not, always proceed with the wizard—never cancel it. The wizard detects

that this computer was not the PDC in its domain (which always has to be promoted to a domain

controller) and will give you a choice of whether to install the Active Directory or leave the computer

as a member server.

These are the steps:

1. The wizard starts automatically with the Welcome screen. Click Next.

2. A dialog box will ask you whether you want to leave the computer as a member server or promote it to a domain controller. Select Make a domain controller and click Next.

3. From here on, the steps are identical to those for the promotion of HB-ACCT-ROW-DC5.

For HAY-ACCT-ROW-DC3, the Windows NT 4.0 domain controller that is not powerful enough to

serve as Active Directory domain controller, the steps are slightly different.

The first step is again to upgrade the operating system to Windows 2000. After the upgrade, the

Active Directory Installation Wizard will automatically start up again.

Note Before you run the wizard, check the DNS configuration again and make sure the entries are

de 316

OK. Otherwise, the computer might not be able to resolve domain names correctly and supply

credentials to the right domain controllers. Never cancel the wizard—always go through the dialogs

even if you decide to use this computer as member server in the future.

When you run the wizard, select Leave machine as member server in the Additional Domain

Controller or Member Server dialog box.

In the next dialog box, provide the credentials for the administrator account in the domain, and then

supply an administrator password for the member server. The last dialog asks you to confirm your

options.

Now the computer will be configured as a member server and you will have to restart it. This will

reset the security context on the member server. The computer will also be removed from the

Domain Controllers organizational unit and moved to the Computers container. This ensures that

group policies that are configured only for domain controllers will not apply to the member server

anymore.

At this point, all domain controllers in the domain are running Windows 2000, but the domain is still

in mixed mode. Perform all tests defined in the test matrix to make sure that all operations work as

usual.

Switch to Native Mode

The switch from mixed mode to native mode does not affect clients per se, only domain controllers.

After the domain was switched, the PDC FSMO will stop replicating to Windows NT 4.0 domain

controllers.

After a period of extensive testing in an environment with Windows 2000 domain controllers only,

Hay Buv Toys decided that the time for the switch had come. After this, the saved data of the

Windows NT 4.0 domain on the backup tapes and the stored Windows NT 4.0 domain controller will

become worthless.

To perform the switch:

1. On any domain controller in the hb-acct-row domain, open the Active Directory Users and Computers manager.

2. Right-click the domain (hb-acct-row.hay-buv.tld) and select Properties.

3. In the Properties dialog box, press Change Mode.

4. A message box will warn that this is a one-way operation. Once the domain is switched into native mode, it can never be reversed to mixed mode again. Press Yes to confirm the switch and then close all dialogs.

5. Wait approximately 15 minutes until the switch has been replicated to all domain

de 316

de 316

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

Section 2:

Migration Scenarios



inferred.

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

de 316

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.

de 316

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:


HAY-BUV-DC1 HAY-BUV Domain controller

HB-ACCT-PDC HB-ACCT Primary domain controller (PDC)

HB-RESWC-PDC HB-RESWC PDC

HB-RESWC-BDC HB-RESWC Backup domain controller (BDC)

HB-RESWC-MEM HB-RESWC Member server

HB-RESWC-WS1 HB-RESWC User workstation

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:

de 316

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

de 316

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:


\\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\Office2000Inst Everyone: R

de 316

http://HB-RESWC-BDC/default.htm HB-RESWC\Sales: FC

http://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 http://HB-RESWC-BDC/default.htm Success

HB-ACCT\RainierS access to http://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:


HB-ACCT\JoeD access to http://HB-RESWC-BDC/default.htm Failure

HB-ACCT\JoeD access to http://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.

de 316

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 http://www.microsoft.com/windows2000 .

Terminology

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

Source domain—the Windows NT 4.0 domain containing the original security principal that will be

migrated.

Source object—the security principal object that will be migrated.

Target domain—the Windows 2000 native mode domain in which the migrated principal account is

created.

Target object—the 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 accounts—default 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

de 316

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:

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

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

de 316

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.

de 316

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.

de 316


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

de 316

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.

de 316

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

de 316

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.

de 316

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.

de 316

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

de 316

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.

de 316

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.


de 316

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

de 316

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.

de 316

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 select

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

de 316

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.

de 316

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.

de 316

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.

de 316

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:

de 316

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.

de 316

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.

de 316

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.

de 316

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.

de 316

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.

de 316

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


Click Next.

de 316

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.

de 316

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

de 316

dial-in permissions.

Figure 9.45 JoeD - home directory

Figure 9.46 JoeD - logon hours

de 316

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:

de 316

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.

de 316

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.


HAY-BUV\RainierS can log on to workstation HB-RESWC-WS1 Success

de 316

Recycle Bin does not contain the document placed there by HB-ACCT\RainierS

Success

HAY-BUV\RainierS access to http://HB-RESWC-BDC/default.htm Success

HAY-BUV\RainierS access to http://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 http://HB-RESWC-BDC/default.htm Failure

HAY-BUV\JoeD access to http://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.

de 316

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 http://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 http://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

de 316

de 316

Domain Migration Cookbook - Chapter 10: Consolidation of Windows NT 4.0 Resource Domains

Section 2:

Migration Scenarios



inferred.

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.

de 316

• 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

structure—that 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:

de 316

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

de 316

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):


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

HB-RESWC-MEM HB-RESWC Member server

de 316

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

de 316

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:


\\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\Office2000Inst Everyone: R

http://HB-RESWC-BDC/default.htm HB-RESWC\Sales: FC

http://HB-RESWC-MEM/default.htm HB-RESWC-MEM\Marketing: FC

de 316

FC = full control, R = read only

Terminology

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

Source domain—the Windows NT 4.0 domain containing the original security principal that will be

migrated.

Source object—the security principal object that will be migrated.


created.

Target object—the 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.



groups that you place into them. Their SIDs are identical in every domain.

Windows NT 4.0 Server "built-in" accounts




Guests Yes Yes

Replicators Yes Yes

Users Yes Yes




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.

de 316

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


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

de 316

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.


1. Establishing trusts

2. Identifying service accounts

3. Migrating member server

4. Migrating Windows NT 4.0 workstation

de 316

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.

de 316


Figure 10.7

Scenario Steps

Establishing Trusts

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

de 316

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.

de 316

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.

de 316

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.

de 316

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

de 316

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 folder—for 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.

de 316

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

de 316

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

de 316

Select Migrate now?

Click Next.

Figure 10.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.

de 316

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.

de 316

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.

de 316

Figure 10.24


Click Next.

Figure 10.25

Click Finish.

de 316

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.

de 316

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

de 316

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


Name: HAY-BUV-DC1

• The following events were logged on the migrated computers:

de 316

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

de 316


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

Minimize the Registry Editor, but leave it running—you 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.

de 316

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.

de 316

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.

de 316

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.

de 316

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.


directory F:\Program Files\Active Directory Migration


1999-12-02 10:33:11-Created account input file for remote agents:

de 316

DCTCache



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}


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

HAY-BUV\RainierS can log on to workstation HB-RESWC-WS1 Success

de 316

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 http://HB-RESWC-BDC/default.htm Success

HAY-BUV\RainierS access to http://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 http://HB-RESWC-BDC/default.htm Failure

HAY-BUV\JoeD access to http://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:

de 316

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

de 316

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.

de 316

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

de 316

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.

de 316

Figure 10.50


Click Next.

Figure 10.51

Click Finish.

de 316

Figure 10.52


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.

de 316

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

de 316

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.

de 316

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.

de 316

Figure 10.58

Check Migrate now?.

Click Next.

Figure 10.59

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.

de 316

Figure 10.60

Figure 10.61

Click Next.

de 316

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.

de 316

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.

de 316

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.

de 316

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.

de 316

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

de 316

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.


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?

de 316

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.

de 316

Figure 10.76

Select Local groups and User rights.

Click Next.

Figure 10.77

Select Add.

Click Next.

de 316

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.

de 316

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:

de 316

• 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 used—in 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.

de 316

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.

de 316


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.

de 316


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

de 316

Log on to workstation HB-RESWC-WS1 Success Success

Access \\HB-RESWC-BDC\ExecDocuments Success Fail

Access http://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

de 316

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

de 316

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.

de 316

de 316

Domain Migration Cookbook - Chapter 11: Intraforest Migration

Section 2:

Migration Scenarios



inferred.

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:

de 316

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

Figure 11.1

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


HAY-BUV-DC1 hay-buv.tld Domain controller

de 316

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.

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

de 316

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.

de 316

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-

de 316

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

MikeG access to http://HB-RES-DC2 Success

MikeG access to http://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- 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.

de 316

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 domain—the Windows 2000 domain containing the original security principal that is to be

migrated.

Source object—the security principal object to be migrated.


created.

Target object—the 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.



groups that you place into them. Their SIDs are identical in every domain/computer.

Windows 2000 Server "Built-in" Accounts




Guests Yes Yes

Replicator Yes Yes

Users Yes Yes


de 316



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.


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

de 316

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.


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.

de 316


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

de 316

object on the "Domain Controllers" OU has to be edited in all domains:


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.

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.


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

de 316

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

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.

de 316

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

Click Next.

Figure 11.7

Select hb-res.hb-acc.hay-buv.tld as the source domain and hay-buv.tld as the target domain. You

de 316

can also use the NetBIOS names of the domains, as the graphic shows.

Click Next.

Figure 11.8


Click Next.

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

Figure 11.9

Choose HB-RES-MEM.

Click Add.

de 316

Click OK.

Figure 11.10

Click Next. The User Account credentials dialog box opens.

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.

de 316

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

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-Service Account information gathering beginning.

de 316

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.

de 316

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


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

de 316

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

Figure 11.14

Note Any accounts listed in this information screen in user principal name format (that is, ACC-

[email protected]) 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

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

de 316

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.

de 316

Figure 11.16

Click Next.

Figure 11.17

Select Migrate now?

Click Next.

de 316

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.

Figure 11.19

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

de 316

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

Select HB-RES.

Click OK.

de 316

Figure 11.22

Click Next.

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.

de 316

Figure 11.24

Enter the source domain's administrative credentials.

Click Next.

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.

de 316

Figure 11.26


Click Next.

Figure 11.27

Click Finish.

de 316

Figure 11.28

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

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

de 316


To complete the Computer Migration Wizard, click Close.

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:


directory C:\Program Files\Active Directory Migration




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}


finished.

de 316

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

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.


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.

de 316

Figure 11.32

Click Next.

Figure 11.33

Select Migrate now?

Click Next.

de 316

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.

Figure 11.35

Click OK.

de 316

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

Click Next.

de 316

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

Select Update user rights and Do not rename accounts.

Click Next.

Figure 11.40

de 316

Click OK.

Figure 11.41


Click Next.

Figure 11.42

This windows indicates what service account information in the service control manager (SCM) is

updated during the migration.

Click Next.

de 316

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

Click Finish.


Status property indicates Completed.

Figure 11.45

de 316

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, [email protected]), 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

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.


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

de 316

Security Translation Wizard from the menu.

Figure 11.47

Click Next.

Figure 11.48

Select Migrate now?

Click Next.

de 316

Figure 11.49

Click Next.

Figure 11.50

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

de 316

Figure 11.51

Click Next.

Figure 11.52

Select Local groups and User rights.

Click Next.

de 316

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

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.

de 316

Figure 11.55

Click Finish.

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

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


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

de 316

see the properties.

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.

de 316

Figure 11.58

Click Next.

Figure 11.59

Select Migrate now?

Click Next.

de 316

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

Click Next.

de 316

Figure 11.62

Click Next.

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

Figure 11.63

Click Next.

de 316

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


Click Next.

de 316

Figure 11.66

Click Finish.

Figure 11.67


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:

de 316

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

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.

Figure 11.69

de 316

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

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.

de 316

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


Name: Administrator


Name: HAY-BUV-DC1

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

de 316

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

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

de 316

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

Click Next.

de 316

Figure 11.75

Select Migrate now?

Click Next.

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.

de 316

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

Click Next.

The Select a target container dialog box opens. Click Browse and navigate to the AB-ACCT OU).

Expand HAY-BUV, if necessary.

de 316

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

Click Next. The Group Options dialog box opens.

de 316

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

Enter HAY-BUV\Administrator credentials.

Click Next.

de 316

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

Click Finish.

de 316

Figure 11.85


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 642, User Account Changed

de 316

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:

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.

de 316

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.


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.

de 316

Figure 11.88

Click Next.

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.

de 316

Figure 11.90


Click Next.

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

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.

de 316

Figure 11.92

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

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.

de 316

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

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

Click Next.

de 316

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.

de 316

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

Click Next.

de 316

Figure 11.98

Select Migrate now?

Click Next.

Figure 11.99

Click Next.

In the next window, click Add.

de 316

Figure 11.100

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

Click Add.

Click OK.

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.

de 316

Figure 11.102

Click Next.

Figure 11.103

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

Click Next.

de 316

Figure 11.104

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

Click Next. A 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.

Figure 11.105

The Naming Conflicts dialog box opens.

Figure 11.106

de 316


Click Next.

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.

Figure 11.108

Click OK.

de 316

Figure 11.109

Click Finish.


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.

de 316

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

de 316

Figure 11.113 EricW logon hours

Figure 11.114 EricW dial-in permissions

de 316

Figure 11.115 MikeG home directory

In addition, the administrator should check that the sIDHistory attribute exists for EricW, MikeG, and

ACC-Service.

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 642, User Account Changed

de 316

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


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

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.

de 316

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

de 316

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.


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 http://HB-RES-DC2 Success

MikeG access to http://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 http://HB-RES-DC2 Failure

EricW access to http://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

de 316

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

For More Information

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

Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).

For the latest information on Windows 2000, see http://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.

de 316