Introduction

  • Article

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.

On This Page

About the Cookbook
Migration Goals
Conclusion

About the Cookbook

Welcome to the Domain Migration Cookbook.

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

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

The following documents provide additional information about migration:

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

  • "Planning Migration from Microsoft Windows NT to Microsoft Windows 2000" white paper (available at https://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.

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

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 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 are not specifically related to technical features of Windows 2000 Server. 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.