microsoft domain migration cookbook
TRANSCRIPT
Página 1 de 316
MICROSOFT
DOMAIN
MIGRATION
COOKBOOK
Página 2 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
Página 3 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
Página 4 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
Página 5 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
Página 6 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
Página 7 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
Página 8 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
Página 9 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:
Página 10 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
Página 11 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.
Página 12 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
Página 13 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.
Página 14 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
Página 15 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
Página 16 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.
Página 17 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
Página 18 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.
© 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 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.
Página 19 de 316
Domain Migration Cookbook - Chapter 2: Domain Upgrade
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
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
Página 20 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
Página 21 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
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 22 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.
Página 23 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,
Página 24 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
Página 25 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:
Página 26 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
Página 27 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
Página 28 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.
Página 29 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
Página 30 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
Página 31 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.
Página 32 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.
Página 33 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.
Página 34 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
Página 35 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
Página 36 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
Página 37 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.
Página 38 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
Página 39 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
Página 40 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.
Página 41 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
Página 42 de 316
Página 43 de 316
Domain Migration Cookbook - Chapter 3: Domain Restructure
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
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?
Página 44 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.
Página 45 de 316
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 46 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
Página 47 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.
If your browser does not support inline frames, click here to view on a separate page.
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
Página 48 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
Página 49 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
Página 50 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,
Página 51 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.
Página 52 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.
Página 53 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.
Página 54 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
Página 55 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.
Página 56 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.
Página 57 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.
Página 58 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
Página 59 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.
Página 60 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.
If your browser does not support inline frames, click here to view on a separate page.
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
Página 61 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
Página 62 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.
If your browser does not support inline frames, click here to view on a separate page.
Figure 3.5 Migrating resources incrementally to Windows 2000 (interforest)
© 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
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,
Página 63 de 316
Página 64 de 316
Domain Migration Cookbook - Chapter 4: Restructuring Tools
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
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
Página 65 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:
Página 66 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
Página 67 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:
Página 68 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
Página 69 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
Página 70 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.
Página 71 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:
Página 72 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
Página 73 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
/dstdom:DstDomain /dstOU:DstOU
cscript clonegg.vbs /srcdc:SrcDC /srcdom:SrcDomain /dstdc:DstDC
/dstdom:DstDomain /dstOU:DstOU
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.
Página 74 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
Página 75 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.
Página 76 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
Página 77 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.
Página 78 de 316
Página 79 de 316
Domain Migration Cookbook - Chapter 5: Mature Windows 2000 Domains
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
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
Página 80 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
Página 81 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
Página 82 de 316
Página 83 de 316
Domain Migration Cookbook - Chapter 6: Welcome to Hay Buv Toys
Section 2:
Migration Scenarios
The example companies, organizations, products, people, and events depicted herein are fictitious.
No association with any real company, organization, product, person or event is intended or should
be inferred.
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
Página 84 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
Página 85 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.
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 86 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
Página 87 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,
Página 88 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.
Página 89 de 316
Página 90 de 316
Domain Migration Cookbook - Chapter 7: The Desired Structure and Migration Goals
Section 2:
Migration Scenarios
The example companies, organizations, products, people, and events depicted herein are fictitious.
No association with any real company, organization, product, person or event is intended or should
be inferred.
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.
Página 91 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.
Página 92 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
Página 93 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
Página 94 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
Página 95 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.
Página 96 de 316
If your browser does not support inline frames, click here to view on a separate page.
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
Página 97 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.
Página 98 de 316
Página 99 de 316
Domain Migration Cookbook - Chapter 8: Domain Upgrade
Section 2:
Migration Scenarios
The example companies, organizations, products, people, and events depicted herein are fictitious.
No association with any real company, organization, product, person or event is intended or should
be inferred.
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.
Página 100 de 316
If your browser does not support inline frames, click here to view on a separate page.
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.
If your browser does not support inline frames, click here to view on a separate page.
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
Página 101 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
Página 102 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
Página 103 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
Página 104 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:
Página 105 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.
Página 106 de 316
If your browser does not support inline frames, click here to view on a separate page.
Figure 8.4
6. Verify that the following entry appears in the event viewer: system logon HB-ACCT-ROW-DC4:
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 107 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
Página 108 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.
Página 109 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.
Página 110 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.
Página 111 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.
Página 112 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.
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 113 de 316
If your browser does not support inline frames, click here to view on a separate page.
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).
Página 114 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.
If your browser does not support inline frames, click here to view on a separate page.
Figure 8.13
Página 115 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.
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 116 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.
If your browser does not support inline frames, click here to view on a separate page.
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
Página 117 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.
If your browser does not support inline frames, click here to view on a separate page.
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.
If your browser does not support inline frames, click here to view on a separate page.
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:
Página 118 de 316
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 119 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
Página 120 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
Página 121 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.
Página 122 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
Página 123 de 316
Default-First-Site-Name\HAY-BUV-DC1 via RPC
objectGuid: ab24c9b4-a13c-487a-b7c4-9faf86368d33
Last attempt @ 2000-03-17 19:45.44 was successful.
==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============
DC=hb-acct-row,DC=hay-buv,DC=tld
Default-First-Site-Name\HAY-BUV-DC1 via RPC
objectGuid: ab24c9b4-a13c-487a-b7c4-9faf86368d33
CN=Schema,CN=Configuration,DC=hay-buv,DC=tld
Default-First-Site-Name\HAY-BUV-DC1 via RPC
objectGuid: ab24c9b4-a13c-487a-b7c4-9faf86368d33
CN=Configuration,DC=hay-buv,DC=tld
Default-First-Site-Name\HAY-BUV-DC1 via RPC
objectGuid: ab24c9b4-a13c-487a-b7c4-9faf86368d33
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
Página 124 de 316
Testing server: Default-First-Site-Name\HB-ACCT-ROW-DC1
Starting test: Replications
......................... HB-ACCT-ROW-DC1 passed test
Replications
Starting test: NCSecDesc
......................... HB-ACCT-ROW-DC1 passed test NCSecDesc
Starting test: NetLogons
......................... HB-ACCT-ROW-DC1 passed test NetLogons
Starting test: Advertising
......................... HB-ACCT-ROW-DC1 passed test
Advertising
Starting test: KnowsOfRoleHolders
......................... HB-ACCT-ROW-DC1 passed test
KnowsOfRoleHolders
Starting test: RidManager
......................... HB-ACCT-ROW-DC1 passed test RidManager
Starting test: MachineAccount
......................... HB-ACCT-ROW-DC1 passed test
MachineAccount
Starting test: Services
......................... HB-ACCT-ROW-DC1 passed test Services
Starting test: ObjectsReplicated
......................... HB-ACCT-ROW-DC1 passed test
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
Página 125 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
Página 126 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.
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 127 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
Reply from 12.1.1.2: bytes=32 time<10ms TTL=128
Reply from 12.1.1.2: bytes=32 time<10ms TTL=128
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
Página 128 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.
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 129 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
Testing server: Default-First-Site-Name\HB-ACCT-ROW-DC5
Starting test: Connectivity
......................... HB-ACCT-ROW-DC5 passed test
Connectivity
Doing primary tests
Testing server: Default-First-Site-Name\HB-ACCT-ROW-DC5
Starting test: Replications
......................... HB-ACCT-ROW-DC5 passed test
Replications
Starting test: NCSecDesc
......................... HB-ACCT-ROW-DC5 passed test NCSecDesc
Starting test: NetLogons
......................... HB-ACCT-ROW-DC5 passed test NetLogons
Starting test: Advertising
......................... HB-ACCT-ROW-DC5 passed test
Advertising
Starting test: KnowsOfRoleHolders
......................... HB-ACCT-ROW-DC5 passed test
Página 130 de 316
KnowsOfRoleHolders
Starting test: RidManager
......................... HB-ACCT-ROW-DC5 passed test RidManager
Starting test: MachineAccount
......................... HB-ACCT-ROW-DC5 passed test
MachineAccount
Starting test: Services
......................... HB-ACCT-ROW-DC5 passed test Services
Starting test: ObjectsReplicated
......................... HB-ACCT-ROW-DC5 passed test
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 ======================================
Página 131 de 316
DC=hb-acct-row,DC=hay-buv,DC=tld
Default-First-Site-Name\HB-ACCT-ROW-DC1 via RPC
objectGuid: 886a40f9-c627-4b82-a351-9505b2ea2149
Last attempt @ 2000-03-17 18:53.58 was successful.
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:53.57 was successful.
Default-First-Site-Name\HB-ACCT-ROW-DC1 via RPC
objectGuid: 886a40f9-c627-4b82-a351-9505b2ea2149
Last attempt @ 2000-03-17 18:53.57 was successful.
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:53.57 was successful.
Default-First-Site-Name\HB-ACCT-ROW-DC1 via RPC
objectGuid: 886a40f9-c627-4b82-a351-9505b2ea2149
Last attempt @ 2000-03-17 18:53.57 was successful.
==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============
DC=hb-acct-row,DC=hay-buv,DC=tld
Default-First-Site-Name\HAY-BUV-DC1 via RPC
objectGuid: ab24c9b4-a13c-487a-b7c4-9faf86368d33
Default-First-Site-Name\HB-ACCT-ROW-DC1 via RPC
objectGuid: 886a40f9-c627-4b82-a351-9505b2ea2149
CN=Schema,CN=Configuration,DC=hay-buv,DC=tld
Default-First-Site-Name\HAY-BUV-DC1 via RPC
objectGuid: ab24c9b4-a13c-487a-b7c4-9faf86368d33
Default-First-Site-Name\HB-ACCT-ROW-DC1 via RPC
objectGuid: 886a40f9-c627-4b82-a351-9505b2ea2149
CN=Configuration,DC=hay-buv,DC=tld
Default-First-Site-Name\HAY-BUV-DC1 via RPC
Página 132 de 316
objectGuid: ab24c9b4-a13c-487a-b7c4-9faf86368d33
Default-First-Site-Name\HB-ACCT-ROW-DC1 via RPC
objectGuid: 886a40f9-c627-4b82-a351-9505b2ea2149
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
Página 133 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
Página 134 de 316
Página 135 de 316
Domain Migration Cookbook - Chapter 9: Migration of a Windows NT 4.0 Account Domain to Active Directory
Section 2:
Migration Scenarios
The example companies, organizations, products, people, and events depicted herein are fictitious. No
association with any real company, organization, product, person or event is intended or should be
inferred.
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
Página 136 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.
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 137 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:
Computer name Domain Role
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:
Página 138 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
Página 139 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:
Resource Access rights
\\HB-RESWC-PDC\Finance HB-RESWC\Sales: FC
\\HB-RESWC-PDC\JoeD HB-ACCT\JoeD: FC
\\HB-RESWC-BDC\ExecDocuments HB-RESWC\Sales: FC
\\HB-RESWC-MEM\Specifications HB-RESWC-MEM\Marketing: FC
\\HB-RESWC-MEM\Office2000Inst Everyone: R
Página 140 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:
Test Expected result
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.
Página 141 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
Página 142 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
Página 143 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.
Página 144 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.
Página 145 de 316
If your browser does not support inline frames, click here to view on a separate page.
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
Página 146 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.
Página 147 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
Página 148 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.
Página 149 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.
Página 150 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
Página 151 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.
Página 152 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.
If your browser does not support inline frames, click here to view on a separate page.
Página 153 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
Página 154 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.
Página 155 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.
Página 156 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.
Página 157 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.
Página 158 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.
Página 159 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:
Página 160 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.
Página 161 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.
Página 162 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.
Página 163 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.
Página 164 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.
Página 165 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
Select Ignore conflicting accounts and don't migrate.
Click Next.
Página 166 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.
Página 167 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
Página 168 de 316
dial-in permissions.
Figure 9.45 JoeD - home directory
Figure 9.46 JoeD - logon hours
Página 169 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:
Página 170 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.
Página 171 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.
Test Expected result
HAY-BUV\RainierS can log on to workstation HB-RESWC-WS1 Success
Página 172 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.
Página 173 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
Página 174 de 316
Página 175 de 316
Domain Migration Cookbook - Chapter 10: Consolidation of Windows NT 4.0 Resource Domains
Section 2:
Migration Scenarios
The example companies, organizations, products, people, and events depicted herein are fictitious. No
association with any real company, organization, product, person or event is intended or should be
inferred.
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.
Página 176 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
If your browser does not support inline frames, click here to view on a separate page.
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:
Página 177 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.
Página 178 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):
Computer name Domain Role
HAY-BUV-DC1 HAY-BUV Domain controller
HB-ACCT-PDC HB-ACCT Primary domain controller (PDC) File server
HB-RESWC-PDC HB-RESWC PDC File server
HB-RESWC-BDC HB-RESWC Backup domain controller (BDC) File server
HB-RESWC-MEM HB-RESWC Member server
Página 179 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
Página 180 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.
If your browser does not support inline frames, click here to view on a separate page.
Figure 10.5 The new organizational unit HB-RESWC
At the completion of the "Account Domain" technical walkthrough, the following shares and their
respective access rights should be present:
Resource Access rights
\\HB-RESWC-PDC\Finance HB-RESWC\Sales: FC
\\HB-RESWC-PDC\JoeD HB-ACCT\JoeD: FC
\\HB-RESWC-BDC\ExecDocuments HB-RESWC\Sales: FC
\\HB-RESWC-MEM\Specifications HB-RESWC-MEM\Marketing: FC
\\HB-RESWC-MEM\Office2000Inst Everyone: R
http://HB-RESWC-BDC/default.htm HB-RESWC\Sales: FC
http://HB-RESWC-MEM/default.htm HB-RESWC-MEM\Marketing: FC
Página 181 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.
Target domain—the Windows 2000 native mode domain in which the migrated principal account is
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.
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
groups that you place into them. Their SIDs are identical in every domain.
Windows NT 4.0 Server "built-in" accounts
Account name Domain controller Member server
Administrators Yes Yes
Backup operators Yes Yes
Guests Yes Yes
Replicators Yes Yes
Users Yes Yes
Print operators Yes No
Server operators Yes No
Account operators Yes No
Power users No Yes
Requirements
The following conditions must be met in order to use this technical walkthrough:
• The target is a Windows 2000 native mode domain.
• The source domain is Windows NT 4.0 or Windows 2000 mixed or native mode.
Página 182 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.
Security Requirements
To use the ADMT to consolidate the resource domains into OUs:
• ADMT must be run with administrator rights in the source and target domains.
• Auditing for account management must be enabled in both the source and target domains.
• Administrative shares must exist on the computer where the ADMT is executing and any
computer where the ADMT must install an agent.
• Source domain PDC must have the following registry entry:
HKEY_LOCAL_MACHINE | System | CurrentControlSet | Control | Lsa
TcpipClientSupport:REG_DWORD:0X1
Create this key if necessary and restart the computer to establish the change. Setting this value
enables remote procedure calls (RPCs) over the TCP transport. This is required because, by
default, Security Accounts Manager (SAM) RPC interfaces are capable of being called remotely
only on the named pipes transport. Using named pipes results in a credential management
Página 183 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.
If your browser does not support inline frames, click here to view on a separate page.
Figure 10.6 Registry changes to source domain controller
As stated previously, this walkthrough requires that you establish a two-way trust between the source
domain and the target domain.
Walkthrough
In this walkthrough, you will learn how to migrate the Windows NT 4.0 shared local groups, service
accounts, and computer accounts, test the migrated resources, and decommission the Windows NT
4.0 resource domain.
The walkthrough consists of the following scenario steps:
1. Establishing trusts
2. Identifying service accounts
3. Migrating member server
4. Migrating Windows NT 4.0 workstation
Página 184 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.
Página 185 de 316
If your browser does not support inline frames, click here to view on a separate page.
Figure 10.7
Scenario Steps
Establishing Trusts
Establish trusts as explained in Chapter 4 of this cookbook, "Restructuring Tools."
Página 186 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.
Página 187 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.
Página 188 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.
Página 189 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
Página 190 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.
Página 191 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
Página 192 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
Página 193 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.
Página 194 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.
Página 195 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.
Página 196 de 316
Figure 10.24
Select Ignore conflicting accounts and don't migrate.
Click Next.
Figure 10.25
Click Finish.
Página 197 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.
Página 198 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
Página 199 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
Security log: event ID 646, Computer Account Changed – Called User
Name: HAY-BUV-DC1
• The following events were logged on the migrated computers:
Página 200 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:
If your browser does not support inline frames, click here to view on a separate page.
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
Página 201 de 316
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 202 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.
Página 203 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.
Página 204 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.
Página 205 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.
1999-12-02 10:33:08-The dispatcher created a share for the result
directory F:\Program Files\Active Directory Migration
Tool\Logs\Agents as: \\HAY-BUV-DC1\OnePointDMR$\
1999-12-02 10:33:11-Created account input file for remote agents:
Página 206 de 316
DCTCache
1999-12-02 10:33:11-Installing agent on 1 servers
1999-12-02 10:33:11-The The Active Directory Migration Tool Agent
will be installed on \\HB-RESWC-WS1
1999-12-02 10:33:15-The agent is installed on \\HB-RESWC-WS1
1999-12-02 10:33:16-Started job: \\HB-RESWC-WS1 HB-RESWC-WS166719717
{02AEE1D2-A8E7-11D3-8D5F-00A0C9EE4187}
1999-12-02 10:33:16-All agents are installed. The dispatcher is
finished.
Switch to the Registry Editor on HB-RESWC-WS1 and refresh the registry view of the HB-RESWC-WS1
computer. You should see two new entries, one for the local profile user JoeD, one for the roaming
profile user RainierS. Note that the new entries reflect the SID of the target domain:
If your browser does not support inline frames, click here to view on a separate page.
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
Página 207 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:
Página 208 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.
Página 209 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.
Página 210 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
Página 211 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.
Página 212 de 316
Figure 10.50
Select Ignore conflicting accounts and don't migrate.
Click Next.
Figure 10.51
Click Finish.
Página 213 de 316
Figure 10.52
The Migration Progress dialog box is displayed and updated.
When the operation completes, the Status property in the dialog box indicates Completed.
View the log file if you wish, then click Close.
The status message confirms that the migration process was successful. As a result of the migration,
the following actions were performed:
• A new group was created with a new primary SID called CN=Sales,OU=HB-RESWC ,DC=HAY-
BUV,DC=tld.
• The SID of the source group HB-ACCT\Sales was added to the sIDHistory attribute of the new
group CN=Sales,OU=HB-RESWC,DC=HAY-BUV,DC=tld.
• The following events were logged in the target domain:
Security log: event ID 635, Security Enabled Local Group Created
Security log: event ID 636, Security Enabled Local Group Added
• The following event was logged in the on the PDC of the source domain:
Application log: event ID 1, Source=EaDctAgent, Sales copied to
HAY-BUV\Sales
The Active Directory Administration Tool that is available on the Windows 2000 CD through installation
of the support tools from directory SUPPORT can be used to verify creation of the sIDHistory. To get
the view as shown here, follow these steps:
1. Open Ldp.exe through Windows 2000 Support Tools/Tools/Active Directory Administration Tool.
Página 214 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.
If your browser does not support inline frames, click here to view on a separate page.
Figure 10.53
The new group can be viewed in the Active Directory Users and Computers MMC console on HAY-
BUV-DC1.
If your browser does not support inline frames, click here to view on a separate page.
Figure 10.54 The shared local group Sales was migrated from the Windows NT 4.0 domain
Página 215 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.
Página 216 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.
Página 217 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.
Página 218 de 316
Figure 10.60
Figure 10.61
Click Next.
Página 219 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.
Página 220 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.
Página 221 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.
Página 222 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.
Página 223 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
Página 224 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.
From the target Windows 2000 domain controller, HAY-BUV-DC1, log on as HAY-BUV\administrator
and launch the ADMT from within the MMC. To begin the Security Translation Wizard, select Active
Directory Migration Tool in the left pane, right-click, and then select Security Translation Wizard
from the menu.
Figure 10.72
Click Next.
Figure 10.73
Select Migrate now?
Página 225 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.
Página 226 de 316
Figure 10.76
Select Local groups and User rights.
Click Next.
Figure 10.77
Select Add.
Click Next.
Página 227 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.
Página 228 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:
Página 229 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.
Página 230 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.
Página 231 de 316
If your browser does not support inline frames, click here to view on a separate page.
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.
Página 232 de 316
If your browser does not support inline frames, click here to view on a separate page.
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
Página 233 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
Página 234 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
Página 235 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.
Página 236 de 316
Página 237 de 316
Domain Migration Cookbook - Chapter 11: Intraforest Migration
Section 2:
Migration Scenarios
The example companies, organizations, products, people, and events depicted herein are fictitious. No
association with any real company, organization, product, person or event is intended or should be
inferred.
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:
Página 238 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):
Computer name Domain Role
HAY-BUV-DC1 hay-buv.tld Domain controller
Página 239 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
Página 240 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.
Página 241 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-
Página 242 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.
Página 243 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.
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
groups that you place into them. Their SIDs are identical in every domain/computer.
Windows 2000 Server "Built-in" Accounts
Account name Domain controller Member server
Administrators Yes Yes
Backup operators Yes Yes
Guests Yes Yes
Replicator Yes Yes
Users Yes Yes
Print operators Yes No
Página 244 de 316
Server operators Yes No
Account operators Yes No
Pre-Windows 2000 compatible access
Yes No
Power users No Yes
Requirements
In order to use this technical walkthrough, the following requirements must be met:
• Target Windows 2000 domain hay-buv.tld set to native mode.
• Source domain is Windows 2000.
• Source domain hb-res.hb-acc.hay-buv.tld set to native mode.
• Source domain must be in same forest as target domain.
Source object must be of one of the following types:
• User
• Security-enabled group, including:
• Local group on domain controllers
• Domain local group (only available in native mode Windows 2000 domains)
• Global group
• Computer
• The SID of the source object must not already exist in the forest, either as a primary account
SID or in the sIDHistory of an account.
• ADMT must be executed from a computer running Windows 2000.
The following requirement is specific to the migration of groups and users: The source object cannot
be a built-in account (for example, local administrators, users, and power users). Built-in account
SIDs are identical in every domain; thus, adding them to a sIDHistory would violate the requirement
that the SID of a domain be unique.
Security Requirements
In order to use this technical walkthrough, the following security requirements must be met:
• A user must run the ADMT with administrator rights in source and target domains.
• Auditing must be enabled in both the source and target domains. The procedure to set this is
Página 245 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.
The walkthrough consists of the following scenario steps:
1. Preparing the Windows 2000 domains.
2. Identifying services from hb-res.hb-acc.hay-buv.tld not running under Local System Account (LSA).
3. Migrating a computer running Windows 2000 Professional.
4. Migrating a service account.
5. Updating hb-res.hb-acc.hay-buv.tld service account user rights and group membership.
6. Migrating a domain local group.
7. Migrating a Windows 2000 member server.
8. Migrating a domain controller and decommissioning the domain hb-res.hb-acc.hay-buv.tld.
9. Migrating a global group.
10. Identifying services from hb-acc.hay-buv.tld not running under LSA.
11. Migrating a service account, user account, and roaming profile.
12. Updating hb-acc.hay-buv.tld service account user rights and group membership.
13. Migrating local profiles on computers running Windows 2000 Professional.
14. Migrating a domain controller and decommissioning the domain hb-acc.hay-buv.tld.
15. Performing migration tests.
The following flowchart shows the steps to perform the intraforest migration.
Página 246 de 316
If your browser does not support inline frames, click here to view on a separate page.
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
Página 247 de 316
object on the "Domain Controllers" OU has to be edited in all domains:
1. Log on to the domain with administrative rights.
2. In the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, select the domain and double-click to open it.
3. In the left MMC pane, select the OU Domain Controllers. Right-click Domain Controllers and select Properties in the drop-down menu.
4. In the Properties window, select the Group Policy tab.
5. Highlight Default Domain Controllers Policy and click Edit. The group policy snap-in will launch.
6. At Default Domain Controllers Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy, double-click Audit account management. Select Success and Failure and then click OK. Close all previously opened windows.
7. Replicate the changed group policy object to all domain controllers in the domain through Active Directory Sites and Services or wait five minutes for automatic update.
8. Apply the new group policy through the command SECEDIT /REFRESHPOLICY MACHINE_POLICY on every domain controller.
Figure 11.4 Account management auditing must be enabled in the target domain
Additionally, a new policy for the "Servers and Workstations" OU must be implemented.
1. Log on to the domain with administrative rights.
2. In the Active Directory Users and Computers MMC snap-in, select the domain and double-click to open it.
3. In the left MMC pane, select the OU Servers and Workstations. Right-click Servers and Workstations and select Properties in the drop-down menu.
4. In the Properties dialog, select the Group Policy tab.
5. Click New and type Domain-Servers-Workstations as for the policy.
6. Highlight Domain-Servers-Workstations and click Edit. The group policy editor will launch.
7. At Domain-Servers-Workstations\Computer Configuration\Windows Settings\Security
Página 248 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.
Página 249 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
Página 250 de 316
can also use the NetBIOS names of the domains, as the graphic shows.
Click Next.
Figure 11.8
Select Yes, update the information.
Click Next.
On the next window, click Add to choose the computers that are used as information resources.
Figure 11.9
Choose HB-RES-MEM.
Click Add.
Página 251 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.
Página 252 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-Active Directory Migration Tool, Starting...
2000-01-31 18:50:45-Service Account information gathering beginning.
Página 253 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.
Página 254 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
2000-01-31 18:50:45-Operation completed.
Click Close to get back to the Agent Monitor dialog box.
Página 255 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
Página 256 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.
Página 257 de 316
Figure 11.16
Click Next.
Figure 11.17
Select Migrate now?
Click Next.
Página 258 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.
Página 259 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.
Página 260 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.
Página 261 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.
Página 262 de 316
Figure 11.26
Select Ignore conflicting accounts and don't migrate.
Click Next.
Figure 11.27
Click Finish.
Página 263 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-Active Directory Migration Tool, Starting...
2000-01-31 19:16:03-Starting Account Replicator.
2000-01-31 19:16:03-Account Migration HB-RES HAY-BUV CopyUsers:No
CopyGlobalGroups:No CopyLocalGroups:No CopyComputers:Yes
2000-01-31 19:16:04-CN=HB-RES-WS1 - Created
2000-01-31 19:16:11- - Set password for HB-RES-WS1.
Página 264 de 316
2000-01-31 19:16:11-Operation completed.
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:
2000-01-31 19:17:17-The dispatcher created a share for the result
directory C:\Program Files\Active Directory Migration
Tool\Logs\Agents as: \\HAY-BUV-DC1\OnePointDMR$\
2000-01-31 19:17:17-Installing agent on 1 servers
2000-01-31 19:17:17-The The Active Directory Migration Tool Agent
will be installed on \\HB-RES-WS1
2000-01-31 19:17:21-The agent is installed on \\HB-RES-WS1
2000-01-31 19:17:21-Started job: \\HB-RES-WS1 HB-RES-WS1374569125
{1CD7F8BF-BB0F-4C3C-A20B-4DB90F6A288C}
2000-01-31 19:17:22-All agents are installed. The dispatcher is
finished.
Página 265 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.
From the target Windows 2000 domain controller, HAY-BUV-DC1, log on as hb-res.hb-acc.hay-
buv.tld\administrator and launch the ADMT from within the MMC. To begin the User Migration Wizard,
select Active Directory Migration Tool in the left pane, right-click, and select User Migration
Wizard from the menu.
Página 266 de 316
Figure 11.32
Click Next.
Figure 11.33
Select Migrate now?
Click Next.
Página 267 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.
Página 268 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.
Página 269 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
Página 270 de 316
Click OK.
Figure 11.41
Select Ignore conflicting accounts and don't migrate.
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.
Página 271 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.
The Migration Progress dialog box is displayed and updated. When the operation completes, the
Status property indicates Completed.
Figure 11.45
Página 272 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.
From the target Windows 2000 domain controller, HAY-BUV-DC1, log on as hb-res.hb-acc.hay-
buv.tld\administrator and launch the ADMT from within the MMC. To begin the Security Translation
Wizard, select Active Directory Migration Tool in the left pane, right-click, and then select
Página 273 de 316
Security Translation Wizard from the menu.
Figure 11.47
Click Next.
Figure 11.48
Select Migrate now?
Click Next.
Página 274 de 316
Figure 11.49
Click Next.
Figure 11.50
Click Add, select HB-RES-MEM, click Add, and then click OK.
Página 275 de 316
Figure 11.51
Click Next.
Figure 11.52
Select Local groups and User rights.
Click Next.
Página 276 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.
Página 277 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
migrated service account to any local groups it may have been a member of, such as local
administrators.
You can verify this on HB-RES-MEM with Settings/Users and Passwords/Advanced/Advanced User
Management/Advanced/Groups. Then select the group on the right MMC screen and double-click to
Página 278 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.
Página 279 de 316
Figure 11.58
Click Next.
Figure 11.59
Select Migrate now?
Click Next.
Página 280 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.
Página 281 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.
Página 282 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
Select Ignore conflicting accounts and don't migrate.
Click Next.
Página 283 de 316
Figure 11.66
Click Finish.
Figure 11.67
The Migration Progress dialog box is displayed and updated. When the operation completes, the
dialog box Status property indicates Completed. View the log file if you wish, then click Close.
The Status message confirms that the migration process was successful. As a result of the migration,
the following actions were performed:
• A new group was created with a new primary SID called CN=Research,OU=HB-RES,DC=HAY-
BUV,DC=tld.
• The SID of the source group hb-res.hb-acc.hay-buv.tld\Research was added to the
sIDHistory attribute of the new group CN=Research,OU=HB-RES,DC=HAY-BUV,DC=tld.
The following events are logged in the target domain:
Página 284 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
Página 285 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.
Página 286 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
Security log: event ID 646, Computer Account Changed – Called User
Name: Administrator
Security log: event ID 646, Computer Account Changed – Called User
Name: HAY-BUV-DC1
The computer accounts appear in the Users and Computers snap-in:
Página 287 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
Página 288 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.
Página 289 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.
Página 290 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.
Página 291 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.
Página 292 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.
Página 293 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.
Página 294 de 316
Figure 11.85
The Migration Progress dialog box is displayed and updated.
When the operation completes, the dialog box Status property indicates Completed.
View the log file if you wish, then click Close.
This completes the Group Account Migration Wizard. As a result of the migration, the following actions
were performed:
• A new group was created with a new primary SID:
CN=Accounting,OU=HB-ACCT,DC=HAY-BUV,DC=tld
• The SID of the source group hb-acc.hay-buv.tld\Accounting was added to the sIDHistory
attribute of the new group:
CN=Accounting, OU=HB-ACCT,DC=HAY-BUV,DC=tld
• A new account was created with a new primary SID:
CN=MikeG,OU=HB-ACCT,DC=HAY-BUV,DC=tld
• The SID of the source account hb-acc.hay-buv.tld\MikeG was added to the sIDHistory
attribute of the new account:
CN=MikeG, OU=HB-ACCT,DC=HAY-BUV,DC=tld
• The following events were logged in the target domain:
Security log: event ID 624, User Account Created
Security log: event ID 642, User Account Changed
Página 295 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.
Página 296 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.
From the target Windows 2000 domain controller, HAY-BUV-DC1, log on as HAY-BUV\administrator
and launch the ADMT. To begin the Service Account Migration Wizard, select Active Directory
Migration Tool in the left pane, right-click, and select Service Account Migration Wizard from the
menu.
Página 297 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.
Página 298 de 316
Figure 11.90
Select Yes, update the information.
Click Next.
In the next window, click Add to choose the computers that are used as information resources.
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.
Página 299 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.
Página 300 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.
Página 301 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.
Página 302 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.
Página 303 de 316
Figure 11.98
Select Migrate now?
Click Next.
Figure 11.99
Click Next.
In the next window, click Add.
Página 304 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.
Página 305 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.
Página 306 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
Página 307 de 316
Select Ignore conflicting accounts and don't migrate.
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.
Página 308 de 316
Figure 11.109
Click Finish.
The Migration Progress dialog box is displayed and updated.
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.
Página 309 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
Página 310 de 316
Figure 11.113 EricW logon hours
Figure 11.114 EricW dial-in permissions
Página 311 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 624, User Account Created
Security log: event ID 642, User Account Changed
Página 312 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
migrated service account to any local groups it may have been a member of, such as local
administrators.
You can verify this on HB-RES-MEM with Settings/Users and Passwords/Advanced/Advanced User
Management/Advanced/Groups. Then select the group on the right MMC screen and double-click to
see the properties.
Figure 11.117
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.
Página 313 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
Página 314 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.
Test Expected result
HAY-BUV\MikeG can log on to workstation HB-RES-WS1 Success
Local profile for user MikeG on workstation HB-RES-WS1 is migrated Success
MikeG access to 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
Página 315 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.
Página 316 de 316