MCSE: Windows 2000 Migration Exam Notes

MCSE:Windows® 2000

MigrationExam Notes™

Todd PhillipsQuentin Docter

SYBEX®

MCSE:

Windows 2000 Migration

Exam Notes

This page intentionally left blank

San Francisco

•

Paris

•

Düsseldorf

•

Soest

•

London

MCSE:

Windows

®

2000 Migration

Exam Notes

™

Todd Phillips Quentin Docter

Associate Publisher: Neil EddeContracts and Licensing Manager: Kristine O’CallaghanAcquisitions and Developmental Editor: Elizabeth HurleyEditor: Suzanne GorajProduction Editor: Mae LumTechnical Editor: Donald FullerElectronic Publishing Specialists: Jangshi Wang, Judy FungBook Designer: Bill GibsonGraphic Illustrator: Tony JonickProofreaders: Andrea Fox, Mae LumIndexer: Ted LauxCover Designer: Archer DesignCover Photographer: Natural Selection

Copyright © 2001 SYBEX Inc., 1151 Marina Village Parkway, Alameda, CA 94501. World rights reserved. No part of this publication may be stored in a retrieval system, transmitted, or reproduced in any way, including but not limited to photocopy, photograph, magnetic, or other record, without the prior agreement and written permission of the publisher.

Library of Congress Card Number: 2001086973ISBN: 0-7821-2769-X

SYBEX and the SYBEX logo are either registered trademarks or trademarks of SYBEX Inc. in the United States and/or other countries.Exam Notes is a trademark of SYBEX Inc.

Screen reproductions produced with FullShot 99. FullShot 99 © 1991-1999 Inbit Incorpor-ated. All rights reserved.

Microsoft, the Microsoft Internet Explorer logo, Windows, Windows NT, and the Windows logo are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

SYBEX is an independent entity from Microsoft Corporation, and not affiliated with Microsoft Corporation in any manner. This publication may be used in assisting students to prepare for a Microsoft Certified Professional Exam. Neither Microsoft Corporation, its designated review company, nor SYBEX warrants that use of this publication will ensure passing the relevant exam.

TRADEMARKS: SYBEX has attempted throughout this book to distinguish proprietary trade-marks from descriptive terms by following the capitalization style used by the manufacturer.

The author and publisher have made their best efforts to prepare this book, and the content is based upon final release software whenever possible. Portions of the manuscript may be based upon pre-release versions supplied by software manufacturer(s). The author and the publisher make no representation or warranties of any kind with regard to the completeness or accuracy of the contents herein and accept no liability of any kind including but not lim-ited to performance, merchantability, fitness for any particular purpose, or any losses or damages of any kind caused or alleged to be caused directly or indirectly from this book.Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

To Abbie

Acknowledgments

W

riting a book like this is not a solitary process. Many people have contributed in one form or another to make this book what it is. Even though the editors and other people at Sybex did more “work” for this book, the first person I need to thank is my wife Kara. She has endured many things during the course of this project, including giv-ing birth to our first child. Thank you for putting up with my long hours and being there for me. I still can’t believe how lucky I am.

On to the crew. At Sybex, I owe a lot of people thanks, and I am not sure I’ll get everyone. If I don’t, it’s not personal. From the top, there’s Associate Publisher Neil Edde, Developmental Editor Elizabeth Hurley (yes,

the

Elizabeth Hurley), Production Editor Mae Lum, Editor Suzanne Goraj, Technical Editor Don Fuller, Proofreader Andrea Fox, Electronic Publishing Specialists Jangshi Wang and Judy Fung, and Indexer Ted Laux.

And Scott, thanks for going to Palm Springs to go golfing without me—no, really. Rob and Amy, thanks for being there as always. David Byrne, thanks for making great music for us less talented folk. If I missed anyone, I’ll get you next time.

—Quentin Docter

Contents

Introduction x

Chapter 1 Developing the Migration Strategy 1

�

Select the migration type. Types consist of domain upgrade and restructure, domain upgrade only, and domain restructure only.

3

�

Plan migration.

15

�

Evaluate the current environment.

26

�

Evaluate current hardware.

29

Chapter 2 Preparing the Environment for Migration 65

�

Create and configure a pristine environment.

66

�

Install the Windows 2000 DNS service or configure the existing DNS implementation as appropriate.

69

�

Develop and deploy a recovery plan. Consider implications for Security Accounts Manager (SAM), WINS, DHCP, Windows 2000 DNS Server service, and existing DNS service.

77

Chapter 3 Planning and Deploying a Domain Upgrade 83

�

Develop a domain upgrade strategy.

84

�

Develop an operating system upgrade path. Considerations may include operating system version and service packs.

90

�

Upgrade the PDC, BDCs, application servers, DNS servers, and RRAS servers.

93

Contents

viii

�

Configure networking protocols, DHCP, LAN Manager Replication, WINS, NetBIOS, Windows 2000 DNS Server service, and existing DNS service.

99

�

Implement group policies.

102

�

Implement file replication bridges.

115

�

Convert domains to native mode.

119

�

Perform test deployments of domain upgrades.

124

�

Implement disaster recovery plans.

126

�

Perform post-migration tasks.

137

Chapter 4 Planning and Deploying an

Intra-Forest Domain Restructure and

an Inter-Forest Domain Restructure 141

�

Develop a domain restructure strategy.

143

�

Create or configure the Windows 2000 target domain or domains.

147

�

Select and configure tools, including ADMT, ClonePrincipal, MoveTree, NETDOM, and the Windows 2000 Resource Kit tools.

167

�

Migrate global groups and user accounts.

198

�

Migrate local groups and computer accounts.

208

�

Perform test deployments of intra-forest migrations and inter-forest migrations.

213

�


214

�


224

Contents

ix

Chapter 5 Troubleshooting 253

�

Troubleshoot a failed domain upgrade.

255

�

Troubleshoot account issues for all types of migrations.

272

�

Troubleshoot access issues for all types of migrations.

291

�

Troubleshoot network services problems for all types of migrations.

309

�

Troubleshoot application failures for all types of migrations.

337

�

Troubleshoot tool issues for domain restructures. Considerations include ADMT, ClonePrincipal, NETDOM, MoveTree, and Windows 2000 Resource Kit tools.

345

Index 349

Introduction

M

icrosoft’s new Microsoft Certified Systems Engineer (MCSE) track for Windows 2000 is the premier certification for computer industry professionals. Covering the core technologies around which Microsoft’s future will be built, the new MCSE certification is a powerful credential for career advancement.

This book has been developed, in cooperation with Microsoft Cor-poration, to give you the critical skills and knowledge you need to prepare for one of the elective requirements of the new MCSE certi-fication program for Windows 2000. You will find the information you need to acquire a solid understanding of Windows 2000 Server migrations, to prepare for Exam 70-222: Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 and to progress toward MCSE certification.

Is This Book for You?

The MCSE Exam Notes books were designed to be succinct, portable exam review guides that can be used either in conjunction with a more complete study program (book, CBT courseware, classroom/lab environment) or as an exam review for those who don’t feel the need for more extensive test preparation. It isn’t our goal to give the answers away, but rather to identify those topics on which you can expect to be tested and to provide sufficient coverage of these topics.

Perhaps you’re already familiar with the features and functionality of Windows 2000. The thought of paying lots of money for a specialized MCSE exam preparation course probably doesn’t sound too appeal-ing. What can they teach you that you don’t already know, right? Be careful, though. Many experienced network administrators have walked confidently into test centers only to walk sheepishly out of them after failing an MCSE exam. As they discovered, there’s the Microsoft of the real world and the Microsoft of the MCSE exams. It’s our goal with these Exam Notes books to show you where the two converge and where they diverge. After you’ve finished reading

Introduction

xi

through this book, you should have a clear idea of how your under-standing of the technologies involved matches up with the expecta-tions of the MCSE test makers in Redmond.

Or, perhaps you’re relatively new to the world of Microsoft net-working, drawn to it by the promise of challenging work and higher salaries. You’ve just waded through an 800-page MCSE Win-dows 2000 study guide or taken a class at a local training center. Lots of information to keep track of, isn’t it? Well, by organizing the Exam Notes books according to the Microsoft exam objectives, and by breaking up the information into concise manageable pieces, we’ve created what we think is the handiest exam review guide avail-able. Throw it in your briefcase and carry it to work with you. As you read through the book, you’ll be able to identify quickly those areas you know best and those that require more in-depth review.

NOTE

The goal of the Exam Notes series is to help MCSE candi-dates familiarize themselves with the subjects on which they can expect to be tested in the MCSE exams. For complete, in-depth cov-erage of the technologies and topics involved, we recommend the

MCSE Windows 2000 Study Guide series from Sybex.

How Is This Book Organized?

This book is organized according to the official exam objectives list prepared by Microsoft for the 70-222 exam. The chapters coincide with the broad objectives groupings, such as Planning, Installation and Configuration, Monitoring and Optimization, and Trouble-shooting. These groupings are also reflected in the organization of the MCSE exams themselves.

Within each chapter, the individual exam objectives are addressed in turn. And, in turn, the objectives sections are further divided accord-ing to the type of information presented.

Introduction

xii

Critical Information

This section presents the greatest level of detail on information that is relevant to the objective. This is the place to start if you’re unfamiliar with or uncertain about the technical issues related to the objective.

Necessary Procedures

Here you’ll find instructions for procedures that require a lab com-puter to be completed. From installing operating systems to modify-ing configuration defaults, the information in these sections addresses the hands-on requirements for the MCSE exams.

NOTE

Not every objective has procedures associated with it. For

such objectives, the Necessary Procedures section has been left out.

Exam Essentials

In this section, we’ve put together a concise list of the most crucial subject area topics that you’ll need to comprehend fully prior to taking the MCSE exam. This section can help you identify those topics that might require more study on your part.

Key Terms and Concepts

Here we’ve compiled a mini-glossary of the most important terms and concepts related to the specific objective. You’ll understand what all those technical words mean within the context of the related subject matter.

How Do You Become an MCSE?

Attaining MCSE certification has always been a challenge. However, in the past, individuals could acquire detailed exam information—even most of the exam questions—from online “brain dumps” and third-party “cram” books or software products. For the new MCSE exams, this simply will not be the case.

Introduction

xiii

To avoid the “paper-MCSE syndrome” (a devaluation of the MCSE certification because unqualified individuals manage to pass the exams), Microsoft has taken strong steps to protect the security and integrity of the new MCSE track. Prospective MSCEs will need to complete a course of study that provides not only detailed knowledge of a wide range of topics, but true skills derived from working with Windows 2000 and related software products.

In the new MCSE program, Microsoft is heavily emphasizing hands-on skills. Microsoft has stated, “Nearly half of the core required exams’ content demands that the candidate have troubleshooting skills acquired through hands-on experience and working knowledge.”

Fortunately, if you are willing to dedicate time and effort to Win-dows 2000, you can prepare for the exams by using the proper tools. If you work through this book and the other books in this series, you should successfully meet the exam requirements.

TIP

This book is a part of a series of MCSE Study Guides, published by Sybex, that covers the five core requirements, as well as the elec-

tives you need to complete your MCSE track.

Exam Requirements

Successful candidates must pass a minimum set of exams that mea-sure technical proficiency and expertise:

�

Candidates for MCSE certification must pass seven exams, includ-ing four core operating system exams, one design exam, and two electives.

�

Candidates who have already passed three Windows NT 4 exams (70-067, 70-068, and 70-073) may opt to take an accelerated exam (70-240) plus one core design exam and two electives.

Introduction

xiv

NOTE

If you do not pass the accelerated exam after one attempt,

you must pass the five core requirements and two electives.

The following tables show the exams a new certification candidate must pass.

All

of these exams are required:

One

of these exams is required:

Exam # Title Requirement Met

70-216 Implementing and Administering a Microsoft® Windows® 2000 Network Infrastructure

Core (Operating System)

70-210 Installing, Configuring, and Administering Microsoft® Windows® 2000 Professional


70-215 Installing, Configuring, and Administering Microsoft® Windows® 2000 Server


70-217 Implementing and Administering a Microsoft® Windows® 2000 Directory Services Infrastructure



70-219 Designing a Microsoft® Windows® 2000 Directory Services Infrastructure

Core (Design)

70-220 Designing Security for a Microsoft® Windows® 2000 Network

Core (Design)

Introduction

xv

Two

of these exams are required:

NOTE

For a more detailed description of the Microsoft certification programs, including a list of current MCSE electives, check Microsoft’s Training and Certification Web site at

www.microsoft.com/

train_cert

.


70-221 Designing a Microsoft® Windows® 2000 Network Infrastructure

Core (Design)


70-219 Designing a Microsoft® Windows® 2000 Directory Services Infrastructure

Elective

70-220 Designing Security for a Microsoft® Windows® 2000 Network

Elective

70-221 Designing a Microsoft® Windows® 2000 Network Infrastructure

Elective

70-222 Migrating from Microsoft® Windows NT® 4.0 to Microsoft® Windows® 2000

Elective

Any current MCSE elective

Exams cover topics such as Exchange Server, SQL Server, Systems Management Server, Internet Explorer Administrators Kit, and Proxy Server (new exams are added regularly)

Elective

Introduction

xvi

Exam Registration

You may take the exams at any of more than 1,000 Authorized Pro-metric Testing Centers (APTCs) and VUE Testing Centers around the world. For the location of a testing center near you, call Sylvan Pro-metric at 800-755-EXAM (755-3926), or call VUE at 888-837-8616. Outside the United States and Canada, contact your local Sylvan Pro-metric or VUE registration center.

You should determine the number of the exam you want to take, and then register with the Sylvan Prometric or VUE registration center nearest to you. At this point, you will be asked for advance payment for the exam. The exams are $100 each. Exams must be taken within one year of payment. You can schedule exams up to six weeks in advance or as late as one working day prior to the date of the exam. You can cancel or reschedule your exam if you contact the center at least two working days prior to the exam. Same-day registration is available in some locations, subject to space availability. Where same-day registration is available, you must register a minimum of two hours before test time.

TIP

You may also register for your exams online at

www.sylvanprometric.com

or

www.vue.com

.

When you schedule the exam, you will be provided with instructions regarding appointment and cancellation procedures, ID require-ments, and information about the testing center location. In addition, you will receive a registration and payment confirmation letter from Sylvan Prometric or VUE.

Microsoft requires certification candidates to accept the terms of a Non-Disclosure Agreement before taking certification exams.

Introduction

xvii

What the 70-222 Exam Measures

The 70-222 exam focuses on migrating Windows NT 4 networks to Windows 2000 networks. This test assumes you have a good working knowledge of the Windows 2000 and Windows NT operating sys-tems, and of common networking services.

Topics likely to be covered are domain upgrades, domain restructures, procedures for upgrading or restructuring, and the tools involved in a restructure process. Also covered in some depth will be Windows 2000 features, differences between the Windows 2000 and Windows NT operating systems, and network services such as DNS, WINS, DHCP, and replication.

Tips for Taking Your Exam

Here are some general tips for taking your exam successfully:

�

Arrive at the exam center early so that you can relax and review your study materials, particularly tables and lists of exam-related information.

�

Read the questions carefully. Don’t be tempted to jump to an early conclusion. Make sure that you know

exactly

what the question is asking.

�

Don’t leave any unanswered questions; they count against you.

�

When answering multiple-choice questions you’re not sure about, use a process of elimination to get rid of the obviously incorrect questions first. This technique will improve your odds if you need to make an educated guess.

�

This test has many exhibits (pictures). It can be difficult, if not impossible, to view both the questions and the exhibit simulation on the 14- and 15-inch screens commonly used at the testing cen-ters. Call around to the centers and see whether 17-inch monitors are available. If not, perhaps you can arrange to bring in your own. Failing this, some people have found it useful to draw the diagram

Introduction

xviii

on the scratch paper provided by the testing center and use the monitor to view just the question.

�

Many participants run out of time before they are able to complete the test. If you are unsure of the answer to a question, you may want to choose one of the answers, mark the question, and go on—an unanswered question does not help you. Once your time is up, you cannot go on to another question. You can, however, remain indefinitely on the question you are on when the time runs out. Therefore, when you are almost out of time, go to a question that you feel you can figure out—given enough time—and work until you feel you have the answer (or the night security guard boots you out!).

�

You are allowed to use the Windows calculator during your test. It may be better, however, to memorize a table of the subnet addresses and to write it down on the scratch paper supplied by the testing center before you start the test.

Once you have completed an exam, you will be given immediate, online notification of your pass or fail status. You will also receive a printed Examination Score Report indicating your pass or fail status and your exam results by section. (The test administrator gives you the printed score report.) Test scores are automatically forwarded to Microsoft within five working days after you take the test. You do not need to send your score to Microsoft. If you pass the exam, you receive confirmation from Microsoft, typically within two to four weeks.

Contact Information

To find out more about Microsoft Education and Certification mate-rials and programs, to register with Sylvan Prometric, or to get other useful information, check the following resources. Outside the United States or Canada, contact your local Microsoft office or Sylvan Pro-metric testing center.

Introduction

xix

Microsoft Certified Professional Program—(800) 636-7544

Call the MCPP number for information about the Microsoft Certified Professional Program and exams, and to order the latest Microsoft Roadmap to Education and Certification.

Sylvan Prometric Testing Centers—(800) 755-EXAM

Contact Sylvan to register to take a Microsoft Certified Professional exam at any of more than 800 Sylvan Prometric testing centers around the world.

Microsoft Certification Development Team—Web:

www.microsoft.com/Train_Cert/mcp/examinfo/certsd.htm

Contact the Microsoft Certification Development Team through their Web site to volunteer for participation in one or more exam develop-ment phases or to report a problem with an exam. Address written correspondence to: Certification Development Team, Microsoft Edu-cation and Certification, One Microsoft Way, Redmond, WA 98052.

Microsoft TechNet Technical Information Network—(800) 344-2121

This is an excellent resource for support professionals and system administrators. Outside the United States and Canada, call your local Microsoft subsidiary for information.

How to Contact the Publisher

Sybex welcomes reader feedback on all of their titles. Visit the Sybex Web site at

www.sybex.com

for book updates and additional certifi-cation information. You’ll also find online forms to submit comments or suggestions regarding this or any other Sybex book.

Chapter

1

Developing the Migration Strategy

MICROSOFT EXAM OBJECTIVES COVERED IN THIS CHAPTER:

�

Select the migration type. Types consist of domain

upgrade and restructure, domain upgrade only,

and domain restructure only.

(pages 3 – 14)

�

Plan migration.

(pages 15 – 26)�

Select domains and establish proper order for migrating them.

�

Select destination of migrated objects. �

Plan for incremental object migrations as appropriate.

�

Develop a pilot migration strategy.

�

Evaluate the current environment.

(pages 26 – 29)

�

Evaluate current hardware.

(pages 29 – 63)�

Evaluate security implications. Considerations include physical security, delegating control to groups, certificate services, SIDHistory, and evaluating post-migration security risks.

�

Evaluate application compatibility. Considerations include Web server, Microsoft BackOffice products, and line of business (LOB) applications.

�

Evaluate network services, including remote access functionality, networking protocols, DHCP, LAN Manager Replication, WINS, NetBIOS, Windows 2000 DNS Server service, and existing DNS service.

T

he objectives covered in this chapter serve as both an entry point to the text and a foundation for the rest of the material. Planning is perhaps the most important step in any project, and when that project involves migrating your entire domain structure from Windows NT to Windows 2000, its importance becomes especially relevant.

Arm yourself with knowledge about both operating systems. Know what features of NT you want to keep, what features you don’t need, and what features Windows 2000 will provide that NT could not. You will be greatly helped by becoming thoroughly familiar with both operating systems and by understanding what options you will have during the migration.

Be able to properly evaluate the existing environment, and from that information decide what needs to stay, what needs to go, and what options you can be flexible with.

Since this exam is an advanced elective, this book is going to assume that you know Windows 2000 Server and Active Directory fairly well. If you do not have any background in Active Directory Services, you may want to study that material before proceeding with this exam. This test will ask questions that involve knowledge from both prerequisites, and throw in some Network Infrastructure material as well.

Chapter 1 �


3

�

Select the migration type. Types consist of domain upgrade and restructure, domain upgrade only, and domain restructure only.

T

he type of migration you choose will largely depend on what your current network looks like. If you are running Windows NT, then a domain restructure will not work. However, an upgrade or upgrade and restructure would work. On the test, you can be expected to take an existing network and determine the best course of action needed to get the network configured as desired.


There are three major courses of change when entering a migration scenario. You can upgrade the domain, upgrade and restructure the domain, or restructure the domain. Two questions you should ask yourself: What machines will be upgraded, and what type of restruc-turing is going to be involved?

Upgrade

Upgrading from Windows NT to Windows 2000 is a fairly common migration scenario. It involves the least amount of risk, and it is easy in the sense that most of your NT system settings and preferences will be retained.

Even though you are upgrading the network, you do not need to upgrade all machines on your network. Windows 2000 supports mixed clients (Windows 9

x

and NT) without problems. However, you should consider upgrading all machines to Windows 2000, as a pure Windows 2000 network allows you to use all features of the Windows 2000 operating system.

Microsoft strongly recommends implementing all new network struc-tures in a test environment that parallels your existing network. This

MCSE: Windows 2000 Migration Exam Notes

4

allows you to check functionality and work out any issues you might encounter before implementing a production environment.

Beginning the Upgrade

To upgrade your existing domain, upgrade the Primary Domain Con-troller (PDC) in the current Windows NT domain to Windows 2000 first, followed by any desired Backup Domain Controllers (BDCs) and member servers. Before upgrading domain controllers, make sure they are all synchronized.

When you install Windows 2000 onto your NT PDC, the Windows Setup program will detect the server’s role and automatically prompt you to begin the installation of Active Directory. This will give you the option of creating the first tree in a new forest, installing a new tree in an existing forest, creating a replica in an existing domain, or installing a child domain. If this is the first Windows 2000 network for your company, then you will want to create a new tree in a new forest.

A couple of questions come to mind. First, do you need to keep the current PDC as a domain controller for your Windows 2000 network? Second, do you need to run the Active Directory Installation Wizard? To answer the first one, no, you don’t need to keep the current PDC as a domain controller. As for the second, yes, you do need to run the Active Directory Installation Wizard. Remember, that’s how Windows 2000 promotes domain controllers. You need to have domain controllers to have a domain.

Upgrading the PDC

As mentioned in the last section, installing Windows 2000 on an NT PDC will cause the Active Directory Installation Wizard to begin. The Active Directory installation process will automatically copy the entire contents of the Windows NT Security Accounts Manager (SAM) database into Active Directory. Windows 2000 refers to these objects (users, groups, computers) as securityprincipals.

When the Active Directory installation is complete, the domain is running in mixed mode. This means all features of Windows 2000 are

Chapter 1 �


5

not yet available. However, you must continue to run in mixed mode until all domain controllers for your domain are running Windows 2000. After the initial upgrade, the former PDC is play-ing the Operations Master role of PDC Emulator Master. It will use Active Directory to store objects but will remain backward-compatible with the Windows NT BDCs. This provides you with a couple of additional features:

�

The PDC Emulator Master looks like a Windows 2000 domain controller to Windows 2000 computers and like an NT PDC to downlevel computers.

�

New objects can be created on the Windows 2000 domain controller and replicated to Windows NT BDCs.

�

Windows NT and 9

x

client machines can use the PDC Emulator Master as a logon server.

Continuing the Upgrade

Once your PDC is upgraded to Windows 2000, it’s time to start migrating other computers in the domain to 2000 as well. Logically, the Backup Domain Controllers would be next. One of your imme-diate goals in migrating from Windows NT to Windows 2000 should be to get the domain running in native mode as quickly as possible. Only native mode allows the full functionality of Windows 2000. In order to switch to native mode, you cannot have or plan to have any Windows NT BDCs as part of the domain.

NOTE

Changing from mixed mode to native mode is a one-way

process. You cannot switch from native mode to mixed mode.

Switching to native mode causes several things to happen:

�

All domain controllers begin using multimaster replication.

�

You can no longer add Windows NT BDCs to the domain.

�

New features, such as universal groups, domain local groups, and advanced group nesting, are enabled.


6

In some cases, you may want to stay running in mixed mode. Mixed mode provides the best in backward compatibility with older net-work operating systems. There are generally only a few specific rea-sons to remain running in mixed mode. First, if the BDC does not have the hardware to support Windows 2000, an upgrade of that machine is not possible. Second, if the BDC is running applications that are not supported by Windows 2000, an upgrade of that machine is not possible. Third, if there is a need to be able to fall back on Windows NT for any reason, mixed mode is the only way. The first two situations above assume you want to keep those particular machines as domain controllers. It’s not required that you do so.

When referring to mixed mode, the term really only applies to the authentication infrastructure in the domain. A domain that runs Windows 2000 domain controllers in native mode and has down-level clients is referred to as a mixed environment. Native-mode mixed environments allow full functionality of Windows 2000 domain controllers.

After upgrading your Windows NT domains, you may want to restructure your network. Restructuring requires more planning than a simple upgrade does. If a structural change is one of your main reasons for migrating, you may want to consider planning a restructure during the migration.

Upgrade and Restructure

This type of migration is typically available only if you currently have more than one domain. While it is possible to take one existing domain and migrate and restructure to multiple domains, it’s probably not a good idea. The reasons for needing multiple domains in Windows NT have been addressed in Windows 2000. There is no longer the limitation of size on the SAM database, and delegation of administrative controls can be applied to Organizational Units (OUs) within a domain.

When considering an upgrade and restructure, there are a few different options:

�

Restructure NT to Windows 2000

�

Restructure Windows 2000 to Windows 2000

Chapter 1 �


7

�

Inter-forest migrations

�

Intra-forest migrations

The first thing to consider is the existing structure of your network. If it’s not a Windows NT network, then some of these decisions will be much easier. You should be building a parallel network structure and then converting your computers to Windows 2000, as shown in Figure 1.1. But most scenarios will involve upgrading an existing NT 4 network to use Active Directory.

F I G U R E 1 . 1 :

Migrating to Windows 2000 often requires building a

parallel domain structure.

In order to plan the kind of domain restructure that your network needs, you must consider the requirements of the organization, its physical structure, and any projected growth. Is there an existing domain structure that will be maintained? Or will you be performing a complete restructure as part of your migration? If you are planning to restructure, where are the administrative units? And where is the administrative staff for the network? All of these factors will weigh in your decision process for restructuring.

Restructure NT to Windows 2000

If you have an NT network, then this type is for you. Restructuring can mean taking multiple NT domains and consolidating them into one Windows 2000 domain, or it can mean restructuring your exist-ing NT domain controllers when performing your migration.

Existing Network Parallel Network


8

Take the case of restructuring domain controllers. The easiest way to upgrade your NT domain to a Windows 2000 Active Directory domain is to upgrade the PDC, followed by the BDCs and member servers as desired. But what if your PDC cannot be upgraded?

If that’s the case, install a new BDC in your existing NT domain. This machine will become the new domain controller for your Windows 2000 domain. Once it’s installed on the NT domain, promote it to the PDC. This process will take the existing PDC and automatically demote it to a BDC. Once this promotion/demotion takes place, install Windows 2000 onto your new PDC.

Restructuring of domains usually takes place in one of three situa-tions: post-upgrade, instead of upgrade, or post-migration. Post-upgrade restructuring is used to eliminate network complexity once the initial Windows 2000 domain has been established. If your cur-rent Windows NT network is considered unsalvageable, you may just want to scrap the whole thing and install a new Windows 2000 net-work. Restructuring may also take place many years down the road, after the migration is ancient history.

RESTRUCTURING MULTIPLE NT DOMAINS

If you are running a Master Domain model, Multiple Master Domain model, Complete Chaos model, or any other model, you will want to consider upgrading all existing domains on your net-work to one Windows 2000 domain. The two main reasons these domain models were used for Windows NT were the limit on the SAM database size (40MB) and the need for local administration of resources. Windows 2000 does not have a limit on its security data-base size. Also, administrative responsibilities for OUs can now be delegated to users. There are few reasons to need multiple domains.

Consider a few advantages of migrating multiple NT domains into one Windows 2000 domain. First, all administration is centralized. Even though you may think this is a disadvantage (after all, there’s more work for the central administrators), it’s nice that the central IT group can administer all resources if necessary. Second, no trust rela-tionships are needed. Third, departmental control over resources can still be granted to administrators in individual departments through

Chapter 1 �


9

delegation of control. Lastly, if users are trying to locate resources, they are all in one domain and easier to find.

The first step in consolidating domains is to migrate your accounts (master) domain. If you have multiple masters, pick the one with the most users first. That new domain will become the root of your Windows 2000 forest. Then, migrate the other accounts domains, followed by the resource domains. Within all domains, move the domain controllers first, then member servers, then client computers.

When choosing which resource domains to upgrade into the new restructured domain, migrate domains that have mission-critical applications first. Second, migrate the domains with the largest num-bers of computers.

Restructure Windows 2000 to Windows 2000

Windows 2000 restructuring could take place in a variety of settings. Maybe you completed the migration and forgot some things. Maybe you completed the migration and now want to restructure your domains. There could be a number of reasons why you would want to restructure within Windows 2000, and there are two major types of restructuring: inter-forest and intra-forest. Since Windows NT can-not be considered a Windows 2000 domain, and since inter-forest migrations literally refer to “between different forests,” you should consider a migration from NT to 2000 an inter-forest migration.

INTER-FOREST MIGRATIONS

Microsoft has identified two major inter-forest migration scenarios that should meet most businesses’ requirements. These scenarios will work with either a Windows NT domain or an existing Windows 2000 domain as a source domain and a Windows 2000 domain as a tar-get domain. This is the primary migration scenario when migrat-ing a Windows NT domain to a Windows 2000 domain without simply upgrading.

One of your major goals during a migration should be to minimize interruptions to resource access on the network. An implication of


10

maintaining resource access during the migration is that the production environment cannot be too drastically changed until the migration is complete. To ensure this, you will create a second network, or parallel network, to facilitate proper migration.

There are advantages and disadvantages to using inter-forest migra-tions. Advantages include staged migrations, parallel environments, and fallback security. You can migrate groups of users at a time, test the migration in the old and new environments, and, if anything goes wrong, abandon the operation with the old structure still in place.

Some disadvantages to using inter-forest migrations include:

�

Cloned users will retain their security identifiers (SIDs) from the previous domain, as an attribute called SIDHistory, which could theoretically cause security breaches.

�

Microsoft cloning tools like ClonePrincipal do not provide for the copying of passwords between forests.

�

Cloned objects do not have their original Globally Unique Identi-fiers (GUIDs) preserved. This is an issue only when the source domain is Windows 2000.

When migrating from one forest to another, there are two main classes of objects you need to move: users and resources. The steps to migrate users are as follows:

1.

Create the pristine Windows 2000 forest. Create a new Windows 2000 forest using standard procedures. Make sure the new domain meets all current network requirements and future plans for function-ality and expansion. You will create all domains needed and run all domains in native mode.

2.

Establish trusts to maintain resource access. Using either the Active Directory Migration Tool (ADMT) or NETDOM, find out what trusts currently exist between the target and source domains. Cre-ate trusts as necessary. The target and source domains should have a two-way trust established.

3.

Clone all source global groups in the target domain. Once the trusts have been established, clone all global groups. Global

Chapter 1 �


11

groups typically contain users, who need access. This will ensure that you can assign permissions in the new domain while maintain-ing access in the old domain. You can clone groups using ADMT or ClonePrincipal.

4.

Identify and clone sets of users. Once the global groups have been cloned, you can start cloning users. Once again, you can use ADMT or ClonePrincipal for this process. Most of the time you will want to clone users incrementally and test resource access in the new domain before migrating more users. This will eliminate resource access problems once the migration is complete.

5.

Decommission the source domain. After all users and groups have been cloned, the final task is to decommission the source domain. This means powering off all BDCs, followed by the PDC.

At this point, you can no longer go back to Windows NT.

If these machines are to be Windows 2000 servers, install Windows 2000 now and run the Active Directory Installation Wizard as needed.

Each step in the migration process should be tested. Both user logon and resource access should be tested in the new domain before the old domain is decommissioned. If errors occur at any stage, the old domain still exists and production work can continue.

Migrating users is not the only process in migrating domains; you must also consider a process for migrating resources. In a domain model where resources are spread among multiple domains, trust relationships are required, and it can be difficult to locate the resource you’re looking for. As part of the resource migration scenario, appli-cation servers will become member servers in the target domain. It is assumed that the application servers will be using shared local groups for resource access, and the domain may already contain member servers and workstations. The scenario is as follows:

1.

Establish required trusts from the target domain to account domains outside the forest. This step assumes that the resource domains are migrating and that the accounts domain is not—at least not now. The point of this step is to ensure that the accounts have access to the resource after it is moved. When dealing with multiple domains, the only way to accomplish this is through trusts.


12

2.

Clone all shared local groups. This will ensure that resource access is maintained while domain controllers and resources may be split.

3.

Demote application servers to member servers. Windows NT does not support the demotion of BDCs to member servers. The easiest way to accomplish this is to have previously upgraded the PDC of the resource domain. There are two approaches:

�

Upgrade the PDC of the resource domain to Windows 2000, and run the domain in mixed mode. Upgrade the desired BDC. During the Active Directory Installation Wizard, you will be given the choice of making the BDC a domain controller or a member server in the Windows 2000 domain. Choose member server, and your mission is accomplished.

�

Take the BDC offline in the old domain. Promote it to a PDC. Upgrade the machine to Windows 2000, which will effectively make the offline domain controller a clone to the new mixed-mode Windows 2000 domain. Once the original PDC is upgraded or taken offline, you can run the Active Directory Installation Wizard, make the new Windows 2000 machine a member server, and join the target domain.

4.

Move member servers and workstations. Simple enough—move member servers (including former BDCs) from the source domain to the target domain.

5.

Decommission the source domain. Remove all remaining BDCs first, then the PDC for the original domain. If desired, upgrade the machines to Windows 2000 as either member servers or domain controllers.

INTRA-FOREST MIGRATION

If a migration takes place between domains in the same Windows 2000 forest, it is an intra-forest migration. Since Windows NT domains can-not be members of a Windows 2000 forest, this migration type involves only Windows 2000.

This migration scenario is typically used after customers have upgraded their domains to Windows 2000 and now want to ease administration by combining the network location of resources.

Chapter 1 �


13

Advantages of intra-forest migrations include the following:

�

Windows 2000 can copy user passwords from one domain to another domain within the same forest. If this security configura-tion is required, then you must perform an intra-forest migration.

�

If the object is moved intra-forest, the object’s GUID will be retained. This is useful if you have applications that establish user identity with GUIDs.

This type of migration is not for everyone. Disadvantages of intra-forest migrations include the following:

�

When moving objects via intra-forest migrations, the source object is destroyed. Therefore, it is not possible to attempt staged or parallel migrations as you could with inter-forest migrations.

�

In order to maintain group membership rules, users and their global groups must be moved together. Since intra-forest migrations are destructive operations, this often means you must move an entire domain.

The most important reason to use intra-forest migrations is if pass-words need to be maintained for users, so as to avoid security breaches. In this case, you may want to upgrade your Windows NT domains to Windows 2000 domains in the same forest, then perform an intra-forest migration to consolidate domains. While this may be more work, security concerns are quite relevant.

Exam Essentials

Know when to use each migration type.

If given an existing net-work, be able to choose which migration type is most appropriate. Choices are domain upgrade, domain upgrade and restructure, and domain restructure.

Understand what advantages restructuring has.

Windows 2000 has unlimited SAM size and allows administration to be delegated. These improvements over Windows NT reduce the need for multiple domains.


14

Know advantages and disadvantages of inter-forest migrations.

Advantages include staged migrations, parallel environments, and fallback security. Disadvantages include passwords not being copied, SIDHistory, and GUIDs needing to be redefined.

Know advantages and disadvantages of intra-forest migrations.

Advantages are GUID and password preservation. Disadvantages are copying of closed sets and the fact that intra-forest migrations are destructive operations.


Backup Domain Controller (BDC)

Windows NT Server role used to authenticate users, and provide fault tolerance in the Windows NT domain.

Globally Unique Identifier (GUID)

Randomly generated hexadeci-mal number used to uniquely identify objects in a domain.

mixed environment

A primarily Windows 2000 network that has downlevel clients, such as Windows NT Workstation or Windows 9

x

.

mixed mode A Windows 2000 network that contains Windows NT Server domain controllers.

Primary Domain Controller (PDC) Windows NT Server desig-nated as the authoritative server for a domain. This role is obsolete in Windows 2000.

Primary Domain Controller (PDC) Emulator Master Windows 2000 Server machine that provides the functionality of a PDC to clients or applications that would otherwise require a PDC.

Security Accounts Manager (SAM) Database that resides in a Windows NT or Windows 2000 domain. It contains all security set-tings including user account names, passwords, and access permissions.

security principals Term used to identify objects in a Windows 2000 domain that can be assigned security permissions.

Chapter 1 � Developing the Migration Strategy 15

�Plan migration.

Planning is the most critical stage of any successful project. Per-forming a migration without proper planning has about as much chance of success as crossing an ocean in a washtub.

To prepare for the test, you need to know how to develop a full migra-tion strategy. This includes knowing what to migrate, when to migrate it, and where to migrate it.


Once you’ve decided what type of migration you will perform on your network, you must decide where to start. It is critical that you establish which domains you plan to restructure and the order in which they will be converted. If your current network is implemented as a single domain, then you have an easy job ahead of you. But con-sider a network that has more than one domain and three different locations, each maintaining its own domain under NT 4. In this case, you will have to decide which domain will be the first to migrate.

Selecting domains and establishing proper order for

migrating them

The selection of the first domain has some far-reaching implications for your Active Directory environment. Most important, this first domain will be the root of your forest. All other domains will take their names relative to this root domain. For example, if the root domain will be pinkeel.local, then the Boston location of pinkeel.local would likely be called boston.pinkeel.local. Active Directory bases its naming on the Domain Name System’s namespace.

� Select domains and establish proper order for migrating them.� Select destination of migrated objects.� Plan for incremental object migrations as appropriate.� Develop a pilot migration strategy.

MCSE: Windows 2000 Migration Exam Notes16

A major consideration when choosing the new root domain name is whether or not the resources will be available on the Internet. Choos-ing a name like pinkeel.local may reflect the company’s name and image, but the resources in that domain will not be available on the Internet. If you want network resources to be available on the Inter-net, you must choose a root domain name that is supported by the Internet’s root name servers, like .com, .net, .org, or others. If you want to ensure that resources are not available on the Internet, then choosing a .local (or .whateveryouwant) extension is appropriate.

Along with choosing a name, remember that Internet names must be unique and registered. It is also possible to host both internal and external names for the same network. An example would be having the domain be both pinkeel.local (internal) and pinkeel.com (external). This causes some additional headaches, like requiring multiple instances of DNS (internal vs. external) and multiple e-mail addresses for users (once again, internal vs. external). Sticking with one name is good practice.

As mentioned above, the first domain in your Active Directory net-work will be the root domain of your organization, and all child domains and objects will take their names from it. If there is already a domain in your organization that would be a logical choice for this root domain, use it. In most companies, this would be the domain at the company’s headquarters.

In a case where there are several equally valid choices for the root domain, it may be politically safer (and wiser) to create a new empty domain for the sole purpose of hosting the root of the forest. Clues on the test will help you determine which strategy is appropriate. Figure 1.2 shows a possible migration path for the Pinkeel Company in a scenario like this. In this scenario, the network designer has chosen to create a new root domain and make the Seattle, Dallas, and Boston domains child domains of that new root. This way the domains are all equal in their roles, and no feelings get bruised.


F I G U R E 1 . 2 : Migrating Pinkeel Company to a forest with a new root domain

In more traditional NT domain models, the migration is more clear-cut. The easiest by far is the single domain model, as you would sim-ply upgrade your domain controllers to Windows 2000 in mixed mode. Once everything is running smoothly on Windows 2000, con-vert the domain over to native mode and enjoy the full benefits of Active Directory.

To migrate a Single Master Domain model to Active Directory, you typically want to use the master domain as the root domain for the tree and use the resource domains as the child domains. Figure 1.3 shows how this might be accomplished. An alternative is to migrate the master domain first as the root domain and consolidate the resource domains into the new root. If resources still need to be con-trolled by local administrators, migrate the resource domains as their own OUs within the new domain, and delegate control to the appro-priate people.

Existing Network Parallel Network

Pinkeel.com

DallasDallas

Seattle

Seattle

BostonBoston


F I G U R E 1 . 3 : Migrating a Single Master Domain model to Active Directory

Migrating a Multiple Master Domain model can be somewhat more complicated. In this model, there are two or more master account domains and multiple resource domains. You have some alternatives here. First, you could use the master domains as roots of their own trees and combine them into a single forest, as shown in Figure 1.4.

F I G U R E 1 . 4 : Migrating a Multiple Master Domain model to a single forest with multiple trees

Another option is to create a new domain to be the root and add the master domains and their resource domains as child domains beneath the new root. Figure 1.5 shows this option.

MasterDomain

ResourceDomain 1

ResourceDomain 2

RootDomain

ChildDomain

ChildDomain

ForestMAD1 MAD2

R1 R3R2

MAD1

MAD2

R1 R2

R3


F I G U R E 1 . 5 : Creating a new root domain to migrate a Multiple Master Domain model

The other options involve combining domains. One such choice would be to combine the master domains into one root domain contain-ing the users and upgrade the resource domains as child domains. Another choice would be to upgrade all domains into one domain, with the old resource domains as OUs in the domain. As you can see, with the Multiple Master Domain model, the choices are almost limitless. The best decision will be based on the needs (political and technological) of the company.

On the exam, the case study questions will often present you with choices for which domain should be upgraded first and which domains can have a partial or incremental upgrade. When there is a clear choice for the root domain of the new structure, the choice is easy. But many of the questions aren’t so clear. For these other ques-tions, you must consider the information you have been given as part of the case study. What are the company’s priorities for the migra-tion? Pay particular attention to the information about which com-puters and/or domains cannot tolerate any disruption. This will guide you in your decisions.

Last tip: When designing a new domain structure, keep the number of parent and child domains to a minimum, if possible. You could create a root domain, a child for the physical location, a child for the build-ing, a child for the department, and so on. However, object names start getting ridiculous. Imagine locating an object with the unique

MAD1 MAD2

R1 R3R2

MAD1

Root

MAD2

R1 R2 R3


name of jsmith.marketing.bldg25.boston.pinkeel.local. Keep things simpler than that.

Selecting destination of migrated objects

In many migrations, you will be migrating all users and computers into one domain. If this is the case, then choosing destinations for migrated objects is fairly straightforward. If you are migrating a more complex domain structure, such as a Windows NT Multiple Master Domain model, then you need to figure out where to put migrated objects.

If you are migrating to multiple domains, there are a couple of rules to follow. First, if management does not want the structure to change, so be it. Migrate the domains, and leave the structure intact. This is another easy answer. However, if migration goals dictate a more log-ical structure, now you have work to do. You can group computers and users a variety of ways, but two major grouping types usually make the most sense: geography or job function.

No matter how you decide to migrate user and computer accounts, structure is important. Structure can be looked at in two different ways: domain structure and structure within a domain. Your domain structure will likely depend on your old network model and the needs of your new network. Often this includes making sure management’s desires are met. However, structure within the domain is frequently overlooked, even though it can make future management of a net-work much simpler.

Implementing Organizational Units

OUs allow you to create structure within a domain and map your company’s logical network to mirror its physical structure. This enables you to delegate control over smaller sections of your network, such as departments, and distribute the administrative burden. One of the buzzwords you’ll come to recognize for Windows 2000 is gran-ularity, which basically means that you can break down a process into as many segments as needed or review something in the most minute detail to ensure clarity and understanding on the user’s part. Windows 2000 enables you to get as granular as you want with


permissions and rights. You can also designate a user to be a local administrator for their department, giving them full control of their OU, but control of nothing beyond that OU.

This brings up an interesting point in domain planning. Remember that example earlier of the company with three physical locations and three separate domains? Using OUs, you could consolidate the entire network into one single domain with Active Directory, then imple-ment an OU for each physical location. Delegate administrative rights and permissions to the local administrator team at each location, and you have the best of all worlds! These local administrators can now administer everything in their location, but you still retain central-ized administration over the entire network using the Enterprise Admins group at the domain level.

OUs can be used to divide up a domain in a variety of ways—for instance, by department or by physical location. The right way will be different for every network you plan. A solid approach to this process is to decide whether the administration will be centralized or distrib-uted, and design the network accordingly.

If you decide to centralize your administration, you will have very little left to do because the default provides centralized adminis-tration. But if you decide that you want to distribute all or part of the administrative load, you may need to configure some OUs or child domains to block inheritance from the root. Of course, the built-in administrators group for the domain can override the authority of an OU’s administrator, and an enterprise administra-tor can override the authority of any down-level administrator.

For the test, pay careful attention to what any case studies tell you. If management insists on completely autonomous control for all departments, then multiple domains is the way to go. However, if all departments need control of resources, yet there is to be a cen-tralized IT department with overriding control, then one domain divided into logical OUs makes more sense. In either case, group your users and computers in a way that makes sense, typically either geographically or by job function, or however management mandates.


Planning for incremental object migrations

If a domain can be upgraded incrementally, this will give you a more structured approach to the migration. You can begin with the domain controllers and immediately switch the domain to Active Directory and native-mode operations. Then you can follow by upgrading the member servers and finally the clients. Incremental domain upgrades are more useful in situations where the servers cannot tolerate very much time offline. This approach gives you the ability to upgrade the domain controllers and the clients without touching the member serv-ers providing line of business (LOB) applications. Your priority for the specific order of machines to upgrade will depend on the business goals of the migration. The only real requirement for upgrading a domain is that the domain controllers be upgraded. The other computers can easily be a mixture of Windows 2000 and Windows 9x or NT.

Developing a pilot migration strategy

You need to plan for getting your network ready for the actual rollout of Windows 2000 by performing a series of pre-migration steps. These steps range from setting up a test lab to see if your setup pro-cedures will really work, to planning for restoring your current net-work services if the migration needs to be rolled back for any reason, to running a pilot migration.

Creating a Test Environment

If you don’t currently have a test lab, you should set one up if at all possible. This doesn’t have to be elaborate; three to five computers that are capable of running the versions of software you plan to deploy should do it in most cases.

Even though you can get by with just a few computers for testing, there are some guidelines to keep in mind:

� Complexity of the planned deployment

� Your available budget

� What kind of physical space is available for the test lab

� Structure of your team, number of testers, and their locations


� Services and components that you will be testing

� Whether the test lab will be used after the deployment is complete

Other points to consider will reflect the nature of the testing, such as network cabling to be used, routers, and similarity of the test equip-ment to the planned production equipment. It is a good idea to use the new production servers for the test phase if it is practical. In many cases, you will be purchasing new servers for the migration, and a small number of them can be purchased early to use for the testing.

Using a test lab to proactively identify the sources of potential issues means that you can also experiment with different solutions and test their effectiveness before the time becomes too short during the deployment. The lab is the proper place to design your recovery pro-cess and to test that recovery plan to verify that it will work before you actually need it.

NOTE Microsoft recommends setting up a test environment for every migration you are going to perform. If this is an option on the exam, strongly consider whether doing so is necessary and feasible. If it is, it’s probably a correct answer.

Remember that one of your primary goals is to cause the least amount of disruption to the existing network environment while migrating to Windows 2000. If your testing reveals weaknesses in the migration plan, you should reexamine the plan, taking the new information into account. For example, you may find that your plan fails to consider resource access. This would be a good time to develop some alternative ideas to correct the situation.

The testing itself is another area where you can spend a lot of time planning how things will work. Create test plans for each phase of your migration separately, then in combination. As the plans gain in complexity, they should approach the reality of the migration. That is, when you are at the end of your testing phase, you should be run-ning a full simulation of the deployment in the test lab.


TEST LAB CONSIDERATIONS

The absolute best place to put your lab is in a mirrored environment with the existing network. This way, all issues can be worked out with a practice run of the migration before the real thing. Ideally, this means purchasing systems comparable to the ones currently running on the network and installing identical services on those machines. Attempt to simulate the production environment as closely as possible.

Preparing Your Environment for the Rollout

The last step you’ll take before the real full-scale deployment is to conduct a pilot deployment. A pilot deployment presents the oppor-tunity to test your understanding of the migration process by moving a small number of computers and users over to the new system.

In your pilot program, you will want to select a number of users in your organization who are fairly competent to move to Windows 2000. You will be upgrading at least some of your servers to provide network ser-vices for them and upgrading their workstations to Windows 2000. The pilot gives these users a chance to learn the new features of Win-dows 2000 and to give you feedback on how these features work for them in their daily environment. This feedback will either confirm your decision to proceed with the full deployment or warn you to back off until you have resolved any conflicts that have been found.

Pilots are a great idea for one reason: The real environment is never completely simulated in the test lab. It seems that no matter how hard you try, you can never quite get the feel of the production environ-ment. One of the major causes for this is the mixture of software on the users’ computers. Even in companies that tightly control what software can be installed on a workstation, people still manage to slip in some shareware that they’ve downloaded from the Internet or some personal software that they’ve brought in from home.

The users you select for the pilot should be enthusiastic about the Windows 2000 deployment. Such users will help your project’s success in the long term because they will share their experiences with others in the organization who are not yet using Windows 2000. If the pilot is going well (or even if not, if you are on top of the issues), these people will be your greatest advocates. These pilot users should also be


representative of the typical end users in your organization, if possible. They should be performing tasks that will normally be performed with Windows 2000 in the future. Yet there is also a balance to be struck here: They should be able to absorb some downtime if things go wrong. It’s probably not a good idea to roll over your LOB servers as part of the pilot program.

NOTE As with a test environment, if you can deploy a pilot program, it will be helpful in both real-world and exam-based situations.

Pilots are a great way to prepare for a migration, but they’re not the only step you need to take to prepare your network for migration. Network services, such as DHCP and DNS, also need to be in place to support the migration.

Exam Essentials

Know the implications of having an internal versus external DNS naming structure. Depending on your domain name extension (.com vs. .local, for example) resources will be available on the Inter-net. Is this a desired effect?

Know proper order for migrating domains. If you have one domain, this is easy. If you have multiple domains, the rule of thumb is accounts domains first, then resource domains. If there are multiple accounts or resource domains, migrate them based on the number of users (larger first) or importance of the resources.

Understand different methods of structuring networks. You may have the choice of migrating everything into one domain and using OUs for structure. Or you may have to migrate into multiple domains. Each has advantages and disadvantages.

Know reasons for having a test lab and performing a pilot migra-tion. Both test labs and pilot migrations are great for ironing out issues that may occur during the actual migration.



granularity Being able to set options (such as security) at a very con-fined level to affect specific users and groups in Active Directory.

inheritance The process of rights and permissions flowing from a parent object in Active Directory to a child object.

line of business (LOB) applications Applications that are specific to the jobs of workers at the company. Often LOB refers to applica-tions that have been specifically written for the company.

Organizational Units (OUs) Containers in Active Directory that allow you to model the company’s network structure after the com-pany’s political structure.

�Evaluate the current environment.

Windows 2000 provides many benefits over Windows NT and other network operating systems. However, migrating to Windows 2000 can be a futile process if you do not understand the original environment that you will be working with. Before beginning any migration, make sure to evaluate all aspects of the current network. What operating systems are they running? What applications will need to be upgraded? Can they be upgraded without additional hardware? Where does the company want to go with their new network structure? Answering these questions will make your migration much easier. This objective is closely tied with the next objective, “Evaluate current hardware,” in terms of testing and real-life situations.


Whether you are planning an upgrade for a department server or roll-ing out Windows 2000 to a world-class data center, the basic plan-ning elements are the same. When working with any complex system,


such as an operating system, things can (and usually do) go wrong. Proper planning helps to minimize the consequences of those problems.

Upgrade planning for an operating system normally falls into three basic areas: hardware, software (application compatibility), and infrastructure (including security). Add network services to that list and you should have all the elements of a well-planned rollout. One of the very first questions you’ll ask in your planning phase is “Can the current hardware run the new operating system?” Then you’ll need to determine the effects of the deployment on your existing secu-rity structures. And, of course, you’ll need to know whether your applications will run on the new operating system.

NOTE On the test, you may encounter case studies that present you with an existing network and instructions on migrating it to a Windows 2000 structure. Carefully examine factors such as appli-cation compatibility and existing hardware. Also, pay attention to migration goals, and the wishes of management.

There are four versions of Windows 2000 to consider: Professional, Server, Advanced Server, and Datacenter Server. Windows 2000 introduces some new security features for networking. Windows 2000 uses Kerberos security, an industry-standard security service that uses encrypted keys for validation, for all logon validations within a domain. Another new feature is the inclusion of IP Security (IPSec) standards, which allow for various encryption schemes for data transmissions of TCP/IP.

Windows 2000 has even addressed application compatibility. With the addition of DirectX 7.0A in the operating system, Windows 2000 will support more of today’s user applications, such as games. The new network features and security options will support network applications even better than on NT 4.


Restructuring Domains

Many organizations will decide to keep their existing domain struc-ture and just convert it to Active Directory. Others will view the migration to Active Directory as an opportunity to correct issues with their structure, or perhaps just to make the structure more efficient.

A domain restructure is not a requirement for transitioning to Active Directory. It is possible to simply upgrade your existing structure. But if you feel that your network would benefit from a new structure, then restructuring is for you. Restructuring can be accomplished over a long period of time, unlike the original migration, which takes a rel-atively short period of time. You can decide to restructure at any pace you choose, making it easier to avoid unnecessary downtime.

There are three basic types of restructure to consider: the post-upgrade restructure, the restructure instead of upgrade, and the post-migration restructure.

Post-upgrade restructure This is a very common time to perform a restructure. The first phase of the migration, upgrading the domains to Windows 2000, has been completed, and now the second phase of the migration, performing a domain restructure, is to begin. The upgrade takes care of moving the groups and users into Active Directory so that the restructure can be accomplished in a pure Windows 2000 environment. If you decide to restructure after the upgrade, your goals most likely are to either rework the current domain structure into some-thing more efficient or to bring resource domains that have limited-rights administrators into your Windows 2000 domains in a secure way.

Restructure instead of upgrade There are two fundamental reasons to select this method: First, you cannot salvage your current domain structure; second, your environment cannot tolerate any disruption during the migration process. Either way, this method determines that you will create a pristine forest to be the target for the restruc-tured domains. This means that you are creating an ideal forest struc-ture for your organization that is isolated from the production environment. Over time, as more accounts are moved to the pilot net-work, the pilot network becomes the production environment.


Post-migration restructure This type of restructure happens after the migration to Windows 2000 is complete, sometimes months or even years later. Usually this method will be selected because of a significant change in the network structure, such as a merger or acquisition.

The basic decision between an upgrade or a restructure (or both) depends on your network situation. If you feel that your existing structure is ideal, then simply upgrade. Upgrades are possibly the safest scenario. Restructuring offers advantages if you are unhappy with the way your current network works. Both situations allow for back-out plans in case something goes wrong. Generally, restructur-ing also requires additional hardware.

Exam Essentials

Evaluate the existing network before migrating. You can’t know where you’re going if you don’t know where you’ve been. The three main areas to evaluate are hardware, software, and infrastructure.

Know the three methods for restructuring a network, and when to employ each one. They are post-upgrade restructure, restructure instead of upgrade, and post-migration restructure.

Key Term and Concept

Kerberos Industry-standard encrypted and secure user authentica-tion system used by Windows 2000.

�Evaluate current hardware.� Evaluate security implications. Considerations include

physical security, delegating control to groups, certificate

services, SIDHistory, and evaluating post-migration secu-

rity risks.


This objective has width and breadth. In the case studies on the test, you will be required to examine a network, properly evaluate its current status, and make appropriate decisions regarding upgrading the network to Windows 2000. These case studies will involve a vari-ety of issues, including security, applications, and network services.

Possibly the most important topics in this section are migration-specific features, such as how to properly migrate users and groups, and what happens to the security identifiers of these objects. Information about network services, such as DNS, DHCP, WINS, and LAN Manager Rep-lication will also be especially helpful.


When determining the suitability of your current computer hardware for Windows 2000, the best place to start is with the minimum hard-ware requirements. If you’ve used earlier versions of Windows NT, you’ll notice that the hardware requirements for Windows 2000 are significantly higher. This may mean that part of your deployment plan will encompass either the purchase of new computers or the upgrade of the existing systems. Something you will notice on nearly every Microsoft operating system exam is the section on hardware require-ments. With Windows 2000, it will also be important to remember the recommended hardware.

With NT 4, offices could still use 80386 computers. With Win-dows 2000, you must have a Pentium system, and these are now very common in most offices. The server versions differ mostly in the level of hardware support, as shown in Tables 1.1 through 1.4.

� Evaluate application compatibility. Considerations include

Web server, Microsoft BackOffice products, and line of busi-

ness (LOB) applications.� Evaluate network services, including remote access func-

tionality, networking protocols, DHCP, LAN Manager

Replication, WINS, NetBIOS, Windows 2000 DNS Server

service, and existing DNS service.


T A B L E 1 . 1 : Hardware Requirements for Windows 2000 Professional

Hardware Resource

Minimum

Requirement Recommended

CPU (central process-ing unit)

133MHz Pentium—up to two processors supported

Memory 32MB 64MB

Hard disk 2GB with at least 650MB free space

T A B L E 1 . 2 : Hardware Requirements for Windows 2000 Server

Hardware Resource

Minimum


CPU 133MHz Pentium—up to four processors supported

Memory 128MB—up to 4GB supported

256MB

Hard disk 2GB with at least 1GB free space

Requires more free space if installing over a network.

T A B L E 1 . 3 : Hardware Requirements for Windows 2000 Advanced Server

Hardware Resource

Minimum


CPU 133MHz Pentium—up to eight processors supported


256MB


NOTE With these requirements in mind, you should carefully assess your current hardware on any computer that will be upgraded to Win-dows 2000. In some cases, you will find systems that need to have one or more resources upgraded before the operating system can be up-graded. Please note that the hardware listed in the tables above shows the minimum requirements or minimum recommended levels. You will achieve significantly better performance if you add higher levels of hardware.


Requires more free space if installing over a network.

T A B L E 1 . 4 : Hardware Requirements for Windows 2000 Datacenter Server

Hardware Resource

Minimum


CPU Pentium III Xeon Pro-cessors or higher—up to 32 processors sup-ported


256MB


Requires more free space if installing over a network

T A B L E 1 . 3 : Hardware Requirements for Windows 2000 Advanced Server (continued)

Hardware Resource

Minimum



Another resource to help you evaluate your current hardware’s suit-ability to run Windows 2000 is the Hardware Compatibility List (HCL) available from Microsoft’s Web site at www.microsoft.com/windows2000/upgrade/compat/default.asp.

Evaluating other hardware needs

Windows 2000 does support many different types of network hard-ware, and some types of hardware work better than others. Perhaps this would be the perfect opportunity to upgrade your network to 100Mb or create a new subnet to reduce the load on a segment. These issues could seriously affect the overall performance of your network—and thus your satisfaction with the deployment of Windows 2000.

Network Cabling

An important element to consider when upgrading your network infrastructure is whether to upgrade your cabling at the same time. Obviously, the quality of this cabling will be important to the out-come of your network’s performance.

If your business network is likely to grow over the next five years, you should plan to incorporate the fastest network hardware that is prac-tical for your budget. On the other hand, you might want to practice a little restraint. Will you really need gigabit networking anytime soon? For most small networks, 10Mb is just fine, though even a small network would appreciate 100Mb. Larger networks should be quite happy with 100Mb, and the cost versus the speed makes 10Mb or 100Mb fine for widespread application. Gigabit networking hard-ware is still pretty expensive.

NOTE Add networking infrastructure to the list of things to look for when evaluating a migration scenario. If it is not mentioned as a prior-ity, don’t bother with it.

Most existing networks are using some form of Ethernet for their physical network. If your network is one of these, determine whether


the cable being used is category 3 or category 5. If you are using cat-egory 5 cable, your network can easily make the transition to 100Mb.

Network Routers and Subnets

If you are looking for ways to improve network performance on an existing network, you may want to consider breaking up your net-work using a router.

NOTE Once again, look to see if this is a priority on the exam.

By using a router and breaking your network in half, you can effec-tively cut the broadcast traffic in half, too. Routers are normally con-figured to block broadcast traffic as a means to reduce the impact of broadcasts upon the entire network. Windows 2000 will help with this somewhat by eliminating many of the broadcasts that NT used, but breaking the network up into subnets with routers is still a good way to improve performance.

Evaluating security implications

Planning for network security is extremely important when consider-ing a move to Windows 2000 because so many of the security features have changed from NT 4. Since so many networks today are con-nected to the Internet, detecting and preventing intrusion is a vital concern for the network administrator.

It is easy to overlook security when planning an upgrade. When upgrading a single computer, security is only a matter of who can run the setup program. But upgrading a network may have serious impli-cations for the entire network’s security, such as domain trusts, folder permissions, and lost access. Maybe even worse than someone losing access is the idea that a user may suddenly have access to resources they shouldn’t be able to see on the network.


Evaluating network security needs can be a very time-consuming pro-cess. Consider the following points:

� Current domain structures

� High-security resources such as employee files, research, and accounting information

� Access to applications with limited licensing

� Access to or from the Internet

� Domain namespaces

� Future growth of the network

When installing Windows 2000 on a single computer, only a member of the local administrators group can run the setup program (winnt32.exe). Limiting access to just local administrators can be bypassed during unattended installations, but only administrators can perform a local upgrade.

Current Domain Structures

When evaluating security concerns, domains are something you’ll want to plan carefully because they form the basis of all of your secu-rity in Windows 2000. You’ll also want to consider where your net-work is today, as well as where it is projected to go in the next few years. Microsoft recommends that your domain planning take into consideration any planned growth for the next three to five years.

The domain functionality in Windows 2000 may change the network a great deal. This really depends on whether you will be implementing Active Directory immediately and/or running your Windows 2000 servers in mixed mode. You can run Active Directory and maintain mixed mode, but you will not be allowed to use all of the features of Active Directory until you switch to native mode.

In NT 4, the domain directory database had a performance limitation of approximately 40,000 objects (groups, users, and computers). In Active Directory, you can easily have millions of objects in a domain,


so you need to consider where the security boundaries of your orga-nization need to be. It is possible to collapse almost any multiple-domain structure into a single domain using Active Directory. It may or may not be desirable to do this, based on your network needs. There are a few main reasons for splitting domains in Windows 2000. One, if you want to ensure completely isolated administrative con-trols, multiple domains may be necessary. Two, if different locations represented in your network have different geographical settings, dif-ferent domains are the way to go. An example of this second point is an international network. The portion of the network in the United States would use English, whereas the network portion in France would use French. This is a good time to use multiple domains.

It’s easy to create a multiple-domain structure using Active Directory in a single security context. But even though the process is relatively easy, the planning takes serious consideration. For instance, if your organization currently has a complete trust model in place, which domain will you pick to become the root of the tree? There may be serious political consequences to consider. It may be better to create a new domain whose sole purpose will be to become the root of the tree.

High-Security Resources

If you work in an industry where the security of your research is a high priority, consider these needs carefully while designing your deployment strategy. How you design your domain structure and how you delegate the administrative load may create gaps in your security. One example would be if you intended to delegate adminis-trative control to an OU but instead gave control to the whole domain. Another would be if that OU contained resources that were inappropriate for the administrator of the OU to have control of, such as employee records.

If the high-security resources are contained within a physical loca-tion, things will be somewhat easier. In this case, simply create a separate tree to contain all of the resources in this location and administer it as a separate entity.


Another consideration that nearly every network will encounter is the need to protect employee files. In this situation, there are people on the network who definitely need access to the files, such as the human resources personnel, and others who definitely should not have access to the files. Identify where these needs exist by talking with people in every department of the organization. Find out which resources they use and which resources they need to protect.

Securing Access to Applications with Limited Licensing

Software can be very expensive, and you will want to optimize your expenses by limiting your purchases to what is needed. Licenses are often expensive, too. You won’t want to allow just anyone to use up those licenses you have purchased for a specific need.

Identify where these applications are installed and who has a legiti-mate need to use them. Keep entries for each of these in your inven-tory lists. One approach would be to prevent normal users from hav-ing access to the files and use Group Policies to install the applications where they are needed. This way, only your IT staff would have direct access to the install files, and only the appropriate users would have the programs installed.

Accessing the Internet

Internet access, and how it is used, is a hot topic in network security. Many large networks provide access to the Internet for their users through proxy servers. A proxy server translates network requests from a secure internal network to one real IP address on the Internet. They often provide caching services for content downloaded from the Internet and can even act as a firewall to protect the network from intrusion.

Consider this type of access in your deployment plan. Does the proxy software you are using run on Windows 2000? Will all segments of the network require access to the Internet through these proxies? Will all of your users be granted permission to access the Internet from the internal network?


Consider as well a plan to monitor what software is in use on the net-work to prevent users from downloading and running software from the Internet. This can be a source of viruses, licensing violations, and lost productivity.

Planning Security for Future Growth

Planning for the future growth of your network is mostly about pol-icies and procedures. As you build an inventory of security needs for your deployment of Windows 2000, think about how the current size of the network affects your decisions. Then try to predict what those decisions would have to be if the network were 5 percent larger or 10 percent larger, and so on.

Security is one area that will be greatly affected by a restructure. Because Windows 2000 makes it possible to move security principals from one domain to another, you need to assess how the restructure will impact your users, groups, and domain controllers.

You need to examine the impact on the following areas of security:

� Moving security principals, including domain controllers, users and global groups, member servers, and client computers

� Establishing trust relationships

� Cloning security principals

Moving Security Principals

A security principal is a Windows 2000 entity—a computer, a user, or a group—that is assigned a security identifier (SID). One of the great-est benefits implemented as a result of Active Directory is the ability to move security principals from one domain to another or even from one forest to another. You must consider several areas when assessing the security implications of moving security principals:

� Effect on SIDs

� Effect on global group membership

� Effect on Access Control Lists (ACLs) referencing the user


EFFECT ON SIDS

The security identifier for a user, group, or computer is highly specific to the domain in which it is created. When you move an account to a new domain, a new SID must be assigned to that account. This presents some problems for maintaining resource access during a restructure.

In NT’s security model, access to a resource is controlled by the entries in the ACL. The SID of the account trying to access the resource is compared to the list of SIDs stored in the ACL. If the SID matches an entry in the ACL, then the appropriate access is granted.

Under this model, if you move an account to a new domain, you would be creating a new account in the new domain with the same name and properties as the old account. Then you would have to assign permissions for the new account on every resource so that the account would have the same access as before the move.

Say there is a user named BobR who uses a database application located on a server in the Resource Domain 2. Typically, you would create a global group in the Acct_Dom domain called DB_Users and add BobR’s account to that group. Then you would create a local group on the server that hosts the database (call it DB_Local). To give BobR the proper access to the database, you would add his account to the global DB_Users account, then add the DB_Users account to the local DB_Local account and assign permissions to DB_Local.

Now consider the issues surrounding moving BobR’s account to a new Active Directory location. If you move the account to the new location using any of the migration tools for Windows 2000, a new SID will have to be created for the account to identify it uniquely in the new domain. So when you move BobR to the new domain, Win-dows 2000 creates and assigns a new SID to his account. At this point, BobR cannot access the database using the new account, because the new SID isn’t in the ACL for the database. BobR is just out of luck until you find a solution for him. This won’t be much of an issue for Windows 2000 because it implements a new security fea-ture called SIDHistory. Briefly, the SIDHistory field preserves the account’s old SID alongside the new SID.


EFFECT ON GLOBAL GROUPS

Global groups have much the same problem as was described above. When you move BobR’s account to the new domain, you’ll be remov-ing him from any global group he belongs to in the Acct_Dom domain. Global groups can contain only user accounts from the group’s domain, so when you move BobR’s account, his new account cannot be a member of any global group in Acct_Dom.

To solve this problem, you might create a new global group in the tar-get domain to parallel the old global group, but you would have to assign permissions again for all of the resources to which the old glo-bal group had access. Another possible solution would be to use Win-dows 2000’s ability to move security principals to relocate the exist-ing global group to the target domain. This would require that you move everyone who belongs to the group to the new target domain, but this solution still has a problem. This time, the SID for the global group would have changed when you moved it to the new domain, requiring you to reassign permissions at all of the resources for the global group.

EFFECT ON ACLS REFERENCING THE USER

If you had assigned any permissions directly to BobR’s account in the past, you will now have the same problem again. When you move his account to the target domain, the account will receive a new SID. Since the ACLs list the user account by its SID, BobR will no longer be able to access the resource using his relocated user account unless you reassign permissions at each resource for the new account.

SIDHISTORY

The above scenarios all have similar issues with a change in the SID assigned to an account. Windows 2000 introduces the concept of the SIDHistory. The SIDHistory is a method to store the previous SID for a security principal that has been moved from one location to another. This new feature could solve each of the above scenarios by tracking the previous SID.

When using the SIDHistory feature, it is important to always use Windows 2000 utilities to move the security principals. The manage-ment utilities that Microsoft provided for Active Directory under-


stand how to update the SIDHistory when you move a security prin-cipal and thus avoid the issues of reassigning permissions.

During the logon process, Windows NT creates a security token containing the user’s SID and the SIDs for any groups the user belongs to. Windows 2000 takes this one step further by also add-ing the SIDHistory to the access token. This has the effect of authenticating the user for resource access based on his or her cur-rent SID, the SIDs of any groups the user belongs to, and the pre-vious SIDs of both user and groups. The SIDHistory feature makes it possible to easily move a security principal from one location to another in Active Directory without losing any resource access.

Windows NT 4 systems should use the security token generated by the Windows 2000 domain controllers without any problems. There is a problem, however, with the way that NT 3.51 systems use this feature. When NT 3.51 builds the security token, it uses only SIDs that are relative to the user’s account domain and the local computer. The upshot of this is that NT 3.51 computers won’t recognize any group SIDs for universal groups or global groups from another domain in your Active Directory structure. Any users attempting access from another domain will receive an access-denied message even if they should have access.

Establishing Trust Relationships

During your restructure, you may have sets of users in both the source domain and the target domain requiring access to existing resources on your network. To accomplish this access, you will need to establish trust relationships between the existing resource domains and the tar-get domain so that user and group accounts that have been moved to the new target domain can still access the resources they need in the resource domains.

You can use the NETDOM tool to enumerate the trust relationships in your current network and establish new trusts where needed. Win-dows 2000 automatically creates two-way transitive trust relation-ships between all domains in a forest. However, during your migration, you will have a hodgepodge of domains, both Windows 2000 and NT. Before migrating any users or resources to Windows 2000 domains, it is


necessary to make sure that trust relationships are in place for resource access. A good rule to remember is that the resource needs to trust the user.

NOTE NETDOM is covered in depth in Chapter 4.

Once the migration is complete, and all users and resources are migrated to Windows 2000, you can remove the trust relationships you created. It’s not a good idea to remove the trusts between Win-dows 2000 domains in the same forest: Active Directory has created those for a reason.

Cloning Security Principals

Restructuring is often described mostly in terms of moving security principals from one domain to another. But there is another alterna-tive that should be considered: cloning security principals. Cloning offers some great benefits, such as greater reliability during the restructure. Because you are copying the accounts to the target domain, you are leaving the original production environment intact. This gives you a better recovery path, since the original domain is still there with all accounts and permissions intact.

To clone security principals, you need to use the ClonePrincipal tool, which is made up of a number of Microsoft Visual Basic scripts for cloning accounts. Included in the set are scripts that will migrate user accounts, local group accounts, and global group accounts. Clone-Principal doesn’t do anything to the source domain, which is a good thing. It simply copies information out of the SAM database and imports it into the Active Directory in the target domain.

NOTE ClonePrincipal is discussed in detail in Chapter 4.


Evaluating application compatibility

Application compatibility is one of the greatest concerns in any oper-ating system upgrade and one that should be tested thoroughly before the upgrade process. When considering application compatibility, you should be focusing on your servers, all of your LOB applications, and Microsoft Exchange.

A variety of methods can be used during this phase of planning:

� Consult the manufacturer’s Web site for Windows 2000 support information.

� Use the Windows 2000 Setup program to detect many compatibility issues.

� Test the applications in a limited environment before rolling out Windows 2000.

Consider all types of applications in use in your environment, from user applications such as Office 2000 to server applications such as SQL Server or Exchange. Shareware or third-party applications installed on users’ computers will complicate your evaluation of compatibility issues. Custom-written LOB applications can also cause difficulties.

Microsoft is committed to application compatibility in Windows 2000. On the Microsoft Web site at www.microsoft.com/windows2000/downloads, you can check for periodic updates to the operating system for greater application support. The network administrator should make a point of monitoring this Web page from time to time to see if there are updates that affect applications in their environment. Win-dows will also check for updates for you, and Windows Update is included in Windows 2000.

A testing environment offers you the chance to fully test these applications before the changes will affect either your network or your users. It will be very helpful if your organization has created standard software configurations for the various computers in use on your network.


Web Services

Web services have become very important to most businesses, and they should be a critical component of your assessment. Whether you are serving Web pages to the Internet as a means of selling your prod-uct or simply hosting an internal Web site to share information with co-workers, having a stable Web server is probably important to you.

Windows 2000 comes with Internet Information Services (IIS) ver-sion 5 right out of the box. Notice that the name has changed slightly—it’s Services instead of Server. IIS 5 does provide backward compatibility for Web services running on earlier versions of IIS, including full support for common Internet standards, as well as Microsoft extensions. This means that there shouldn’t be any com-patibility issues, but you should still install a test server to fully eval-uate the compatibility with your own Web content.

The administration console for IIS has changed, at least in its loca-tion. You can find the Internet Services Manager in the Administra-tive Tools group on the Start menu. This is a standard Microsoft Management Console (MMC) interface, and it supports all of the functionality of IIS 4 while adding features that reflect the increased security of Windows 2000.

IIS 5 installs support for the FrontPage 2000 Server Extensions, which may or may not be a good thing, depending on your views of FrontPage. You can specify which of the webs hosted on your server will support the FrontPage extensions. This feature will enable you to turn off the extensions for customers who don’t want anything to do with FrontPage.

With any Web server installed, it is a good idea to check with the manufacturer to see if there are any program updates or known issues with the installation of Windows 2000. If you are running a third-party Web server, you will want to deselect IIS during the installation of Windows 2000 to avoid breaking the Web service already installed. Also, be aware that the default options for installing IIS dur-ing setup include the Simple Mail Transfer Protocol (SMTP) mail ser-vice, in addition to World Wide Web (WWW) and File Transfer


Protocol (FTP). You may want to disable the SMTP mail service if your server won’t be handling SMTP mail directly.

IIS 5 includes support for various Web-related network services, such as:

File Transfer Protocol IIS 5 provides a full FTP server for serving files over the Internet or the local intranet.

Network News Transfer Protocol NNTP support is included if your Windows 2000 server will participate in routing Internet News messages.

Simple Mail Transfer Protocol This service provides support for an Internet e-mail server under Windows 2000.

Visual Interdev RAD Remote Deployment Support This service enables you to use your IIS server to distribute applications through a Web interface.

Exchange Server

Exchange Server 5.5 will run on Windows 2000 and is very com-mon in NT 4 or Windows 2000 networks. Microsoft has inte-grated the Exchange Directory with Windows 2000’s Active Directory in Exchange 2000. This simplifies the administration of Directory objects such as users and distribution lists by enabling the administrator to manage all objects from a single MMC interface.

To fully integrate the Exchange Directory with Windows 2000’s Active Directory, Microsoft has provided the Active Directory Con-nector (ADC). The ADC integrates the two directory services for user and group administration, which enables you to administer both Active Directory and your Exchange Directory from the same admin-istrative tool. This means that if you are an experienced Exchange administrator, but are not very comfortable with the Active Directory tools, you can set up the ADC to let you administer the Active Direc-tory from the Exchange Administrator console. Conversely, if you are more comfortable with the Active Directory tools, you can also use them to manage your Exchange Directory.

The ADC is installed from the Windows 2000 Server CD-ROM in the ValueAdd\MSFT\Mgmt\ADC folder. The ADC Setup Wizard will walk


you through the necessary steps to add the service to your server. The connector itself seems to work best when installed on the first domain controller in the domain. It’s true (mostly) that all domain controllers in an Active Directory domain are equal, but by default the first domain controller installed has some special duties. One of those extra duties is to manage the schema for the entire domain as the Schema Master. A schema is a description of the containers and objects within a directory. Because the ADC will need to modify the schema for the domain, it works best from the Schema Master. The management tool can be installed on any Windows 2000 computer in the domain. The Active Directory Connector Management console is shown in Figure 1.6.

F I G U R E 1 . 6 : The Active Directory Connector Management console lets you create and configure connector agreements between Active Direc-tory and Exchange 5.5.

The ADC can synchronize data from Windows 2000 to Exchange, from Exchange to Windows 2000, or in both directions. If you are


synchronizing in both directions or from Windows 2000 to Exchange, you will have the option to create a mailbox when you create a new user account.

If your network is using a messaging server besides Exchange that uses a directory service similar to Active Directory, you can expect to see a connector that will link your messaging server into Active Direc-tory like the ADC does for Exchange. Until you choose to migrate to Exchange 2000, you will need to maintain full functionality in your current Exchange structure.

To support Exchange Server on Windows 2000, there are some restrictions to keep in mind. Only Exchange Server versions 5.5 and 2000 are supported on Windows 2000 at the moment. Older versions of Exchange will need to be upgraded prior to installing Windows 2000. In addition, Exchange Server 5.5 requires Service Pack 3 in order to run on Windows 2000.

Exchange Server requires the use of a dedicated service account in order for its various services to start and communicate with the other Exchange Servers in your enterprise. Service accounts will have many of the same issues with SIDs changing when the account is moved to another domain, and they will have the same solutions to the problem.

SERVICE ACCOUNTS

A service account is a user account that has been created for the sole purpose of supporting a service running on NT or Windows 2000. Many server applications designed for Windows NT/2000 use service accounts to log on to the local server or to communicate with other servers across the network. Special care must be taken to ensure that your service accounts are migrated correctly to the new environment.

The Active Directory Migration Tool has a wizard designed to migrate service accounts from your source domain to the target domain. The Service Account Migration Wizard, shown in Fig-ure 1.7, will help you to identify and migrate your service accounts to the target domain.


F I G U R E 1 . 7 : The opening page of the Service Account Migration Wizard

This wizard looks very much like other wizards except that it must collect information regarding your specific service accounts. The wiz-ard prompts you to enter the names of the computers that will pro-vide the service account information and then dispatches an agent to each computer to gather the information. It can take some time to perform an analysis, but it’s worth the wait. Be careful not to cancel the agent process before it has completed, or you won’t be able to complete the migration successfully. When the information has been collected from the source domain, the wizard will then perform the migration.

Line of Business Applications

LOB applications are typically problematic during upgrades because they are usually highly customized, sometimes for a particular indus-try or even one business, and often poorly documented. They include


databases, incident tracking, monitoring, and other applications essen-tial to a business. Proper testing of these programs on Windows 2000 is imperative prior to performing the upgrade.

Check with the ISV to see if there are any known issues with running the application on Windows 2000. Be prepared to hear that the pro-gram isn’t supported at all on Windows 2000, and have a contin-gency plan for this situation. Check Microsoft’s Windows 2000 com-patibility Web site to see if there are any necessary updates for the program.

NOTE Many LOB applications are designed to run on a specific op-erating system. If the application is not supported by Windows 2000, then it may be necessary to maintain a Windows NT or 9x machine for that application’s support. Consider the implications of maintaining downlevel machines on your Windows 2000 network.

Most compatibility issues for LOB applications center on service accounts and resource access for users. In a restructure, you must maintain access to the resources used on a daily basis by your users. If your LOB application is not supported by Windows 2000, Microsoft recommends contacting the vendor to see if an upgrade or workaround is available. If one is, go with it. If not, the worst-case scenario is that you will need an older server running in your mixed Windows 2000 environment.

Deploying Software in Windows 2000

Windows 2000 uses the new Windows Installer program to install application software. Windows Installer not only installs programs, but also maintains applications by automatically replacing damaged or missing files. Finally, the Windows Installer helps to ensure the clean removal of applications that are no longer being used. The main interface to the Windows Installer is the Add/Remove Programs applet in Control Panel, as shown in Figure 1.8.


F I G U R E 1 . 8 : The Add/Remove Programs applet in Control Panel helps you manage applications in Windows 2000.

Software installation and maintenance uses a new file type for instal-lation packages, the Windows Installer package (a file with an .MSI extension). This file contains the information needed to tell the Win-dows Installer which files are needed and where to locate them. The .MSI file actually replaces the functionality of the setup.exe program for an application.

Using this .MSI file, or package, you can deploy the application using Group Policy Objects (GPOs). GPOs allow the administrator the flexibility to assign or publish applications to an entire domain or for-est or just a single department. Properly planning the domain and OU structure allows administrators to control which users get which applications on a very granular level.

Using Windows Installer packages, administrators can deploy soft-ware through the use of GPOs in two common ways:

Publishing If an application is published, it is advertised to affected users on the network through Add/Remove Programs in Control


Panel. If users want to install the application, they simply find the application they want and double-click it. Published applications can also be organized into functional categories to make administration easier. Applications can be published only to users, not to computers.

Assigning You can also deploy applications by assigning them to users or computers. If an application is assigned to a user, an icon for the application will appear in the user’s Start menu. When the user clicks the icon to launch the application, Windows Installer will begin the installation. Once the installation is complete, the application will function.

If the application is assigned to the computer, it will automatically install the first time the computer is booted after the GPO is applied. The application will be available for all users of that computer. If you are going to deploy applications for a large number of users (as in everyone), assign the apps to computers, not the users.

Evaluating network services

The networking in Windows 2000 is significantly improved from NT 4, which is a good thing. However, one of the big problems that you may face in upgrading your network to Windows 2000 is struggling with a mixture of administrative tools. Many of the Windows 2000 tools won’t administer NT 4 servers, and vice versa. Therefore, you need to spend a considerable amount of time evaluating how an upgrade will change your existing network services.

The best approach to evaluating the impact on your network services is to break them down one by one. Examine the configurations of your servers to discover what services they are running. Make an inventory list of these services and determine how they are being used in your net-work. You may find that some services can be disabled because no one is actually using them. Or you may find that you could benefit from installing a new service to handle a particular need.


Network Protocols

Windows 2000 supports all of the network protocols that NT does, and in fact includes newer versions with enhanced functionality. But the main concern in terms of network protocols is that you must use TCP/IP if you want to use Active Directory.

Native Windows 2000 networks require TCP/IP for many of the new features in the operating system. But perhaps the greatest reason most companies will have for migrating to Windows 2000 is to use Active Directory to streamline their domains. This whole discussion of restructuring domains in Windows 2000 depends on having TCP/IP.

If you have applications or other network clients or servers that require other protocols, you may need to keep a mixed-protocol envi-ronment. But since most if not all network operating systems support TCP/IP today, this shouldn’t be too much of an issue.

Domain Name System

DNS is required for Active Directory installation. Domain functions and naming are built upon DNS. One of the new additions with DNS in Win-dows 2000 is the ability to make dynamic updates to the DNS servers. Because of this, DNS can be used to resolve the names of every client on the network with little administrative overhead. Windows 2000 client computers can automatically provide the DNS server with their hostname such as IP address when they become active on the net-work. Downlevel clients, such as Windows NT and 98, do not sup-port dynamic DNS updates in their client-side TCP/IP stack. In their case, the DHCP server notifies the Windows 2000 DNS server when it gives out an address lease and updates the DNS server’s tables with the new hostname and address information.

DNS resolves hostnames to IP addresses. In the past with NT, this helped only when you were using commands that used sockets to communicate. Windows NT name resolution and resource location was based on NetBIOS naming standards instead of sockets. With Windows 2000, however, DNS is the primary method of resolving names to connect to other Windows 2000 computers. Windows 2000


doesn’t require NetBIOS support to communicate, and the NetBIOS interface can be disabled on Windows 2000 computers.

Although Active Directory requires the use of DNS, it doesn’t require the use of Microsoft’s DNS server to operate. However, it is recom-mended. Active Directory does require support for Dynamic DNS (DDNS) updates using RFC 2136–compliant methods and the use of Service (SRV) records. You can successfully use Berkeley Internet Name Domain (BIND) version 8.1.2 or higher on a Unix system to provide DDNS support.

Microsoft recommends the use of BIND 8.2.2 if you decide to maintain Unix-based DNS solutions, as 8.2.2 supports all of the necessary features for Active Directory. For the exam, you may face questions in which the version of BIND is important informa-tion. Use the following information to assist with your planning decisions:

� BIND 4.9.6 added support for the SRV record type. SRV records are required by Windows 2000 to locate LDAP and Kerberos ser-vices used during logon to a domain.

� BIND 8.1.2 added support for dynamic zone updates. Active Directory does not require this feature, but it does help your Win-dows 2000 domains to work more smoothly.

� BIND 8.2.1 added support for incremental zone transfers (IXFR). This means that instead of replicating the entire zone database to a secondary server, only the changed records are transferred. This lowers the impact on network traffic due to zone transfers.

The DNS service in Windows 2000 includes support for all of these features. While it is true that you can integrate Windows 2000 domains with existing non-Microsoft DNS solutions, Microsoft does seem to prefer that you implement their version of DNS instead. BIND is a product of the Internet Software Consortium (ISC), and more information about integrating BIND and Windows 2000 can be found at their Web site at www.isc.org/products/BIND/.


Even though Windows NT implementations of DNS most closely resemble BIND version 4.9.6, they do not support the use of SRV records. They also do not support DDNS. This is not to say that you cannot use Windows NT DNS servers in your Windows 2000 Active Directory domain. You can, but the authoritative DNS server for the Windows 2000 Active Directory domain must support both dynamic updates and the use of SRV records.

NOTE Windows NT DNS servers can be used in a Windows 2000 do-main. However, they cannot be the authoritative server for the DNS zone.

You have a couple of options for your old DNS servers. First, you can leave the DNS service installed on them and just make them second-ary servers to your Windows 2000 or BIND 8.1.2 DNS server. You could also reinstall or upgrade the operating system and continue to run DNS.

In a restructure, you may need to redefine your network’s DNS struc-ture. This is especially true if the restructure is due to a merger or acquisition of another company with its own namespace. This is also true if you plan to use a different namespace within your organiza-tion—that is, if your Internet presence has a different namespace than your internal organization.

Windows Internet Naming Service

The Windows Internet Naming Service (WINS) provides NetBIOS name resolution in a dynamically assigned IP environment. This can be a very important function in a network that assigns client IP addresses through the use of the Dynamic Host Configuration Protocol (DHCP).

During the restructure of your network, you will likely still be using WINS to resolve NetBIOS names for your network clients. During the restructure, the WINS database will contain entries for all of the existing domains. If you configure the domain controllers of the tar-get domain to use the WINS servers, then the new domains will begin


to appear in the database as well, making it easier for users to find the new domain.

After the migration, WINS may not be necessary on your network anymore. WINS provides the ability to resolve NetBIOS names to IP addresses, but in a Windows 2000 network everything is based on DNS names. If you will be running a mixed environment of Win-dows 2000 and NT or Windows 9x clients, consider running the WINS server service on one or more of your Windows 2000 servers. How-ever, if the network will consist of only Windows 2000 servers and clients, leave out WINS and reduce the associated NetBIOS traffic on your network. On a network running only Windows 2000, Microsoft recommends disabling the NetBIOS interface on all computers to fur-ther reduce network traffic.

WINS is useful for supporting legacy clients or applications that require NetBIOS naming. This is something you should determine during your design and testing phase when planning for a deploy-ment. If at all possible, try to eliminate the need for NetBIOS-based services.

NETBIOS

NetBIOS is not required in a native-mode Windows 2000 net-work, though you may still need its services if you have applica-tions that require it. Possibly you will have older network computers that still require NetBIOS, especially if any NT or Windows 9x computers are left on the network after the migration to Windows 2000.

Client computers that are still using NetBIOS must have WINS present to provide NetBIOS-name-to-IP-address resolution, or they will have to be configured with an LMHosts file to provide that resolution.

Dynamic Host Configuration Protocol

DHCP is based on the Bootstrap Protocol (BootP) and can be used to deliver the entire TCP/IP configuration that a host will need in order to access the network.


DHCP in Windows 2000 becomes more important as it works closely with the DDNS service. When the DHCP service in Windows 2000 has issued a lease to a client computer, it then notifies the DNS server of the lease and updates the database. Now any client using that DNS server can obtain the name resolution for that dynamically addressed client.

One significant change with DHCP in Windows 2000 is the require-ment to authorize a server before it can begin to assign addresses. This may help to prevent the appearance of rogue DHCP servers in a large network. The DHCP server must be authorized before it will actually issue any addresses.

Your server must be either a member server or a domain controller before it can be authorized to act as a DHCP server in an Active Directory domain. Stand-alone servers will not be recognized for the DHCP service, as they have no status in the Directory.

NOTE The DHCP server can be configured to update both A and PTR records on the DNS server, which can be beneficial to networks having Windows computers that do not support dynamic updates, such as Win-dows NT and Windows 9x.

Remote Access Service

Your Windows NT Server may be installed to provide dial-up access for users working from home, and upgrading to Windows 2000 may impact the type and scope of services you can provide. Remote Access Service (RAS) has been replaced with Routing and Remote Access Ser-vice (RRAS) in Windows 2000. It offers improved performance for dial-up clients and superior routing capabilities when compared to NT 4.

RRAS provides some new protocols to add security to the network:

Extensible Authentication Protocol (EAP) Enables the client and server to negotiate the best way to process authentication. Possibili-ties include generic token cards, Message Digest 5 Challenge Hand-


shake Authentication Protocol (MD5-CHAP), and Transport Layer Security (TLS).

Remote Authentication Dial-in User Service (RADIUS) RADIUS is typically used in an environment where many users are dialing into the network and security is required, such as an Internet Service Pro-vider. The dial-up server would act as a RADIUS client to query another server (the RADIUS server) to provide secure authentication for the client. The Internet Authentication Service (IAS) in Windows 2000 can act as a RADIUS server.

Internet Protocol Security (IPSec) IPSec provides protection against internal and external IP attacks and is fairly easy to set up and con-figure. IPSec can be implemented in Windows 2000 as IPSec Policies, which can then be applied to users, groups, or computers.

Layer 2 Tunneling Protocol (L2TP) The Point to Point Tunneling Protocol (PPTP) gained a lot of use in NT 4 but had some serious security limitations, such as non-secure authentication to establish the tunnel. L2TP provides some advancements that go a long way toward plugging these holes. L2TP is used with IPSec to provide a very secure tunnel across an IP internetwork, or it can use ATM, X.25, or Frame Relay to provide the IP network.

Bandwidth Allocation Protocol (BAP) BAP provides some very nice capabilities for enhancing the use of PPP Multilink. Multilink enables clients to dial up to a server using multiple phone lines to cre-ate a single network connection. BAP will sense when some of the phone lines are relatively idle and drop the session on them in order to re-allocate them for other clients. This protocol can dynamically add or remove lines according to where the greatest need currently is. BAP can even trigger a callback to establish an additional line for an existing session.

Windows 2000 RRAS can provide extensible dial-up services for your network and enhanced security. It also supports the use of PPTP or L2TP to create and manage Virtual Private Networks (VPNs) natively. All of the RRAS functions are managed through the Routing and Remote Access console shown in Figure 1.9.


F I G U R E 1 . 9 : The Routing and Remote Access console lets you man-age all of your dial-up and routing configurations.

Some of the concerns with RAS in a Windows 2000 restructure are the default permissions. In mixed mode, the default permission is to allow all authenticated users to access the RAS server; in native mode, the default is to deny that access. When you move users from an NT domain over to the native-mode Windows 2000 domain, you will need to reset the permissions for their accounts to permit dial-up access.

You may also run into some SID issues as the accounts are transferred from the source domain into the target domain, but here again the SIDHistory feature should come to the rescue with the previous SID in hand.

LAN Manager Replication

This area will be a concern during the restructure, since Windows 2000 doesn’t use the LAN Manager replication (LMRepl) service. This was called “Directory Replication” in NT 4. Windows 2000 uses the File


Replication Service (FRS) to move logon scripts and policy files between domain controllers and also to assist in the Active Directory replication.

You will very likely have to set up parallel replication systems between the domain controllers of the source domain and the domain controllers of the target domain to ensure that your users will have their scripts.

Windows 2000 does not support LMRepl in native or mixed mode. Therefore, you need to set up a strategy for replication between the new FRS and LMRepl.

The major difference between LMRepl and FRS is how they initiate replication. LMRepl uses one computer as an export server, with oth-ers acting as import computers. FRS uses the same replication mech-anism as Active Directory, which allows for the use of multimaster replication.

In order to continue replication in a mixed environment, designate one Windows 2000 server as an export computer and import its rep-lication information (scripts and policies) to the export NT computer. This is known as a replication bridge. Then the NT computer will export the desired information to other NT domain controllers. To achieve this 2000-to-NT replication, create a batch file that schedules the necessary copying. Microsoft has a sample batch file available for this purpose.


There are two necessary procedures for this objective. First, you will install the Active Directory Connector for Exchange Server interoperability. Second, you will authorize a DHCP server in Active Directory.


Installing the Active Directory Connector

This procedure has you install the Active Directory Connector. The ADC is provided on the Windows 2000 Server CD-ROM, in the folder \ValueAdd\MSFT\MGMT\ADC.

1. Browse to the ADC folder on your Windows 2000 Server CD-ROM and double-click Setup.exe. This will start the Active Directory Connector Setup Wizard. Click Next.

2. The Component Selection page prompts you to decide which ADC components you will be installing on the local computer. ADC can be installed on a domain controller or a member server, but it should be on a Windows 2000 server. You can then install the ser-vice, the management tools, or both. Click Next once you make your choice.

3. The Install Location page asks you to select a location in which to install ADC. The full space requirement for ADC is approximately 9MB. Click Next.

4. The wizard then asks you to specify which service account the ADC will use to log on to the servers. Enter the name of the service account you have chosen, then click Next.

5. Now the Setup Wizard begins copying files and configuring the system to run the ADC. Once the file copy is complete, you will be prompted to click Finish to exit the Setup Wizard.

Authorizing the DHCP Service

The DHCP server must be authorized in Active Directory before it can give out IP addresses to client computers.

1. Log on to the server (it’s usually best to log on at the server to be authorized) using an account with sufficient permissions to autho-rize the service—i.e., an Enterprise Administrator, unless the per-mission has been delegated.

2. After installing DHCP on your Windows 2000 server, open the DHCP console by clicking Start � Programs � Administrative Tools � DHCP.


3. Expand the console tree to view the server name. Highlight the server to be authorized and select Authorize from the Action menu.

Exam Essentials

Know what SIDHistory is, and how it affects accounts. When you migrate a user or group from an NT domain to a Windows 2000 domain, it will retain the previous SID for the object. This has the side benefit of not requiring you to reassign permissions to resources that were migrated as well.

Be familiar with Exchange Server migration issues. The most com-mon migration issue is dealing with the service account. After migrat-ing it, permissions may need to be reassigned.

Understand common line of business (LOB) application issues.Some LOB applications will not properly migrate to Windows 2000, requiring you to run in mixed mode, or in a mixed environment.

Know the difference between assigning and publishing applica-tions. Applications that are assigned to a computer will be installed when the computer is first booted. If they are assigned to a user, the user will be able to install the application by clicking on a Start menu icon for the application. Published applications are installed using the Add/Remove Programs icon in Control Panel.

Know the different versions of DNS, and what they will and will not support. Windows 2000 DNS is the safest way to go for Active Directory. However, BIND versions 4.9.6 and newer support SRV records, and BIND versions 8.1.2 and newer support dynamic updates.

Understand what WINS is for. WINS servers resolve NetBIOS names to IP addresses. While they were commonly used in NT envi-ronments, they are not necessary in a homogenous Windows 2000 environment. If you have a mixed environment, they may be required for NetBIOS-based applications.

Know how DHCP works. DHCP automatically assigns IP addresses to client machines.


Know how DHCP and DNS can integrate. For clients that do not support dynamic updates (Windows NT and 9x, for example), the DHCP server can provide the DNS server with the client’s IP address and hostname for inclusion into the DNS database.

Understand Windows 2000 enhancements to RAS. Among other things, Windows 2000 RAS supports more protocols and the use of RADIUS server authentication.

Know what L2TP is and what it is used for. L2TP is an enhance-ment on the PPTP RAS protocol. It is most commonly used in con-junction with IPSec to provide secure communications over VPN connections. It is not supported by Windows NT.

Know when PPTP is appropriate instead of L2TP over IPSec. If you are in a mixed environment, you may need PPTP. Windows NT and Windows 95/98 do not currently support L2TP over IPSec.

Know how to configure replication between Windows NT domain controllers and Windows 2000 domain controllers. Windows NT domain controllers use LMRepl, and have one server designated as an export server. Windows 2000 uses FRS, and multimaster replication. In order to get them to work together, you must create a replication bridge, where one Windows 2000 domain controller replicates to a Windows NT domain controller, and the Windows NT domain con-troller replicates to the other NT domain controllers.


Access Control List (ACL) List associated with a resource that defines what objects may access it, and what actions those objects (users) may perform.

Active Directory Connector (ADC) Installed with Exchange Server to make the administration between Active Directory and Exchange Server seamless.

Berkeley Internet Name Domain (BIND) An implementation of DNS protocols. Typically referring to Unix-based machines, it is the most common form of DNS implemented on the Internet.


schema The collection of object attributes in the Active Directory database.

Security Identifier (SID) Randomly generated number that uniquely identifies a user or group in a Windows 2000 domain.

service account User account used by various services (Exchange, SQL) to perform specific service-related tasks.

SIDHistory When an object is migrated from an NT domain, the object is given a new SID, but the old SID is retained as part of the object’s properties as SIDHistory.

Chapter

2

Preparing the Environment for Migration


�

Create and configure a pristine

environment.

(pages 66 – 68)

�

Install the Windows 2000 DNS service or configure

the existing DNS implementation as

appropriate.

(pages 69 – 77)

�

Develop and deploy a recovery plan. Consider

implications for Security Accounts Manager

(SAM), WINS, DHCP, Windows 2000 DNS Server

service, and existing DNS service.

(pages 77 – 82)

W

hen preparing for a migration, you have two main choices for destinations. One is to simply upgrade your existing network in place. However, if your network is a jumbled mess, this may seem a crazy choice. Your alternative is to implement a pristine environment—literally, a new domain that is perfect in every way.

No matter how you decide to proceed in your migration, you will need to implement a solid Domain Name System (DNS) structure. DNS is one of the most critical components in a Windows 2000 struc-ture, as it is required for the installation of Active Directory. Active Directory is the single biggest upgrade in the operating system from Windows NT 4.

And even though you may have excellent plans, and have tested everything thoroughly, problems can still happen. Always have a backup plan—where do you want to go today if everything comes crashing down?

Although these objectives may not garner a significant amount of test time (or material) on their own, they are tightly integrated with other critical sections. Understand when to use a pristine environment, how to set up DNS properly, and how to back out of the migration if you need to.

�

Create and configure a pristine environment.

T

he pristine environment should be your ideal domain or domains. Install it and configure it the right way the first time, and your problems should be reduced in the future.

Chapter 2 �


67


The idea behind creating a pristine environment is simple: create a network that is ideal in every way for what you want to accomplish. If your current network structure is a mess of domains and trust rela-tionships, this is your chance to make it all right. But how realistic is this fantasy?

First, take a look at the disadvantages. There are two main ones. The biggest one is that you may need additional hardware. The other is that it’s not always the quickest method of migrating your network. If speed is vital in this project, and you need to ensure 100% access to resources, pristine environments can pose challenges.

NOTE

Even though in real life a pristine network could be difficult to justify financially to the boss, Microsoft likes the idea of using them. If it seems like a feasible option in an exam scenario, go with it as part of

the solution.

Some of the advantages are fairly obvious. First, the network is ideally configured from the beginning. Second, it is a very clean start to a newly migrated network. Some other advantages may not be as evident, though. When the pristine environment is cre-ated, it is intended to be ideal and isolated at the beginning. This isolation will allow you to test new features, and migrate users, groups, and resources at your convenience. If you encounter any problems, the old infrastructure is still in place. Another major advantage is that the new domain(s) can be running in native mode from the start. This gives you the full functionality of Windows 2000 and Active Directory.

NOTE

The opposite strategy to using a pristine environment would

be to do an in-place upgrade of your current network.


68

You have a few options when going from a pristine environment to a production network. One option is to create the pristine domain(s), and migrate pilot groups and users to the new network. If all goes well, you can finish the incremental migration, and your network is done.

The other option, if speed and continued resource access are primary concerns, is to create a pristine domain and upgrade your existing domains to child domains of the pristine parent. Once it is completed, you can move users, groups, and resources around (or consolidate them into the new domain) as quickly as necessary. Since all security principals and resources will be in the same tree, resource access should be easy to maintain.

NOTE

On the exam, you may be asked what is required for the given company’s pristine environment. Look at their concerns, and design the new network appropriately. In other cases, the pristine network may just be offered as part of a solution, and it’s implied that whoever

would set it up would do so correctly.

Exam Essentials

Know what a pristine environment is.

It is a clean, ideal, and iso-lated network. In its pristine state, it will not contain any users (other than Administrator and Guest), but is ready for a migration.


pristine domain

A domain that has been set up ideally for the needs of a network.

Chapter 2 �


69

�

Install the Windows 2000 DNS service or configure the existing DNS implementa-tion as appropriate.

D

NS has long been the name resolution method of choice on the Internet. Now with the addition of Active Directory in Win-dows 2000, it becomes the primary method for resolving names on local area networks as well. Microsoft has not changed the basic functionality of its DNS services—to do so would be networking suicide. However, they have implemented and included a lot of new features to make DNS more flexible and easier to administrate.

Regarding the test, you can expect questions on DNS implementa-tions. You may be expected to take an existing network’s DNS struc-ture and analyze it for use with Windows 2000. You may also be required to suggest alternate methods of name resolution if the exist-ing structure is not sufficient for the migration. For a detailed discus-sion on evaluating DNS services, see Chapter 1, “Developing the Migration Strategy.”

The installation of DNS has not changed greatly from Windows NT. The major difference is that it’s required for Active Directory. DNS may be installed when Active Directory is installed, or from the DNS installation wizard beforehand.


DNS is a server-based method of resolving hostnames to IP addresses and is required for Active Directory. A hostname is a human-friendly name assigned to an IP host. A host can be virtually anything that can be assigned an IP address, but hosts are usually thought of as being computers. Windows 2000 offers a very good DNS server service. In fact, the service is so useful in a Windows 2000 environment that you


70

might as well consider it required for normal operations. Although you can use BIND 8.1.2 or higher, the benefits of Microsoft’s DNS server justify using it.

The DNS server in Windows 2000 supports all of the Internet stan-dards for DNS and implements a few new features as well, such as dynamic updates and Service (SRV) records. These features in partic-ular are useful to the Windows 2000 network. The dynamic update capability means that as a client receives its IP address lease from the DHCP server, the DNS server will be notified of the IP address and hostname of the client. The DHCP server can also notify the DNS server of the reverse lookup record and forward lookup information. The information is added to the DNS tables, and then any computer in the network can resolve that client’s address using DNS. The new features of DNS in Windows 2000 include the following:

Support for Active Directory

The Windows 2000 DNS service can integrate its records with Active Directory to provide greater fault tol-erance and security. All zones that are integrated with Active Direc-tory are automatically replicated to all domain controllers in the forest. The new DNS service also acts as a locator service for Win-dows 2000 domain controllers, so that Windows 2000 clients can locate the domain controllers for logon or other services.

Support for dynamic updates

With this feature enabled, Win-dows 2000 clients can notify the DNS server of their hostname and IP address. Dynamic updates eliminate the need for a Windows Internet Naming Service (WINS) server to provide name resolution for dynamically addressed clients.

Record aging and scavenging

This feature prevents the presence of outdated records in the tables. It is especially useful in the case of dynamic updates, when the client computer is unable to un-register its name and address, such as when it is improperly shut down.

Secure updates in Active Directory-integrated zones

If the DNS zone is integrated into Active Directory, then the zone can be config-ured to accept updates only from an authorized user account.

Chapter 2 �


71

Administration through the Management Console

The DNS ser-vice in Windows 2000 is fully integrated into the Microsoft Manage-ment Console (MMC) for easier administration.

Command-line administration

Windows 2000 provides a command-line interface to the DNS server,

dnscmd.exe

, which can be used to administer to the DNS server directly or be included in batch files for automated administration.

Incremental zone transfers

In addition to the traditional full zone transfers, the Windows 2000 DNS server can execute partial zone trans-fers that contain only the changed records. This can help to reduce net-work traffic generated by DNS zone transfers.

Support for third-party DNS servers

Microsoft has designed the Windows 2000 DNS service to more closely resemble industry standards. Therefore, Windows 2000 DNS servers do a good job when interoperating with other DNS implementations. In order for a third-party DNS server to function as an authoritative DNS server in a Windows 2000 environment, it must support dynamic updates, the use of SRV records, and underscore characters in the name. BIND versions 4.9.6 and newer support SRV records, and BIND versions 8.1.2 and newer support dynamic updates. The newest BIND versions support underscore characters as options, but this is not yet a standard.

In NT 4 and earlier Microsoft network operating systems, all computers were identified by their NetBIOS computer name. In Windows 2000, this has changed. Now all computers in a Windows 2000 network will use DNS by default to resolve computer names to IP addresses. In fact, the Windows 2000 domain names are usually DNS domain names that describe the exact location of the domain within the DNS namespace. When designing your Active Directory structure, take care to implement your naming correctly, and then you can use DNS to resolve network names throughout your forest. Windows 2000 creates a NetBIOS name based on the hostname to support legacy applications. However, this should not deter you from using DNS as the primary name-resolution method.


72

Windows 2000 computers use fully qualified domain names (FQDNs) to communicate. An FQDN is the combination of the host-name with the full domain name. And there is one other thing you need to know about FQDNs: Always put a dot (.) at the end of the name. That trailing dot represents the root of the Internet.

Installing DNS

If you did not install DNS during Windows 2000 installation, you can install it through Control Panel �

Add/Remove Programs �

Add/Remove Windows Components (or install it as part of the Active Directory installation). Double-click Networking Services and select Domain Name System (DNS) from the list, as shown in Figure 2.1. Click OK, and then click Next to install the DNS service.

F I G U R E 2 . 1 :

Select Domain Name System from the Networking Ser-

vices dialog to install DNS.

Chapter 2 �


73

When you first install DNS, no zone files will be configured. That’s the first thing you need to complete before your DNS server will do anyone any good. When you open the DNS console for the first time and expand the entry for your server, you will receive a message instructing you to configure the server, as shown in Figure 2.2.

F I G U R E 2 . 2 :

The DNS console warns you to configure the server

before proceeding.

Configuring the server in this case means using a wizard to create a new zone for the server. Click the Action menu for the console and select Con-figure The Server. The Configure DNS Server Wizard opens and walks you through the necessary steps to configure a new zone.

This wizard will provide you with the basic zone files, but it’s up to you to populate them with resource records for your various servers. You can do this in a couple of ways. First, you could use the traditional manual entry of each host record. Second, you could enable dynamic updates for the new zone.


74

If you already have DNS installed on your NT servers when the upgrade is performed, that information will be carried forward and the DNS service upgraded. You will want to enable the dynamic updates, though, and set the aging rules for scavenging the database for outdated records.


There are two necessary procedures for this objective: setting up a DNS server and enabling the DNS server for dynamic updates.

Configuring a DNS Server

DNS is a critical part of Active Directory operation. Without it, Active Directory will not install. Even if it were to install, you would not be able to resolve computer names on your Windows 2000 net-work without its services. Use the following procedure to configure your DNS server.

1.

Open the DNS installation wizard. Click Next on the opening page of the wizard.

2.

The next page asks whether you want to configure a forward lookup zone. Click Yes, Create A Forward Lookup Zone, and then click Next to proceed. A forward lookup zone is the file that will resolve FQDNs to IP addresses.

3.

The Zone Type page asks what type of zone to create. Your avail-able choices will be determined by what role your computer plays in the network. If it is a domain controller, you have the option to create an Active Directory–integrated zone, which means that the zone files will be stored in Active Directory. If your computer is anything other than a domain controller, you will have only the options to create a Standard Primary or Standard Secondary zone. The Standard Primary zone will contain the resource records in a file stored on this computer. The Standard Secondary zone means that this DNS server will receive its information from a DNS mas-ter server. Click Next to continue.

Chapter 2 �


75

4.

The Zone Name page asks you to enter your DNS domain name. There may be more than one domain managed by this DNS server, so just enter the DNS domain name you are trying to configure and leave the rest for later. When you have typed in the name, click Next to continue.

5.

The Zone File page asks where the zone information should be stored. This will be shown if you are creating a Standard Primary zone; the other types will already know where to obtain the zone information. A default entry will already be filled in, composed of your DNS domain name with a

.dns

file extension. Accept this default—it just seems to work more reliably that way. Click Next to proceed.

6.

Next, the wizard wants to know if you would like to create a reverse lookup zone. A reverse lookup zone enables your DNS server to provide resolutions from IP address to hostname. Select Yes, and click Next to continue.

7.

You’ll now see the Zone Type page again, this time for the reverse lookup zone. The same guidelines apply here as in step 3 above.

8.

The next page is the Reverse Lookup Zone page, which asks you to provide the network identification for the zone. The easiest way to determine your network address is to look at your subnet mask. If the subnet mask blocks out the first two octets (making your mask 255.255.0.0), then the first two octets of your IP address are your network identification and the rest of your IP address is the host identification. Enter your network address, and fill the other remaining spaces with zeros. Click Next.

9.

The Zone File page will ask you to confirm the name of the zone information file. Confirm the default name provided and click Next.

10.

The Completing The Configure DNS Server Wizard page sum-marizes your selections. Click the Finish button when you are satisfied with your choices, and the wizard will complete the creation of the zones.


76

Enabling Dynamic Updates

Dynamic updates of DNS zones are a relatively new concept in the DNS world. They can greatly ease administration, because when they are enabled, the administrator does not have to manually enter all resource records for the zone.

1.

Open the DNS console and expand the console tree for your DNS server. Open the branch for Forward Lookup Zones.

2.

Right-click the zone that you want to switch over to dynamic updates and choose Properties.

3.

On the General tab, under Allow Dynamic Updates, select Yes from the drop-down list box.

4.

Click the Aging button to open the next dialog.

5.

Check the box beside Scavenge Stale Resource Records to enable record scavenging. This will help to ensure that the records in your DNS server will always be accurate.

6.

Click OK, and OK again to save the settings.

Exam Essentials

Know what new features Windows 2000 DNS provides.

The Windows 2000 implementation of DNS supports secure dynamic updates, underscore characters, the use of SRV records, record scav-enging, and incremental zone transfers.

Know how to install the DNS service.

Windows 2000 DNS can be installed when Active Directory is installed, or by using the DNS installation wizard.


dynamic updates

A feature of DNS that reduces administration by having the client automatically notify the DNS server of its IP address and hostname.

Chapter 2 �


77

FQDN

A fully qualified domain name is a complete computer name that is unique on the network on which it exists.

host

Term referring to any object on a network with an IP address. Typically refers to computers.

hostname

The name given to a host on the network.

Service (SRV) record

Record in the DNS database that Windows 2000 computers use to locate domain controllers.

zone

Area of authoritative control within a DNS installation.

zone transfer

The process of getting zone information from an authoritative DNS server to another DNS server.

�

Develop and deploy a recovery plan. Consider implications for Security Accounts Manager (SAM), WINS, DHCP, Windows 2000 DNS Server service, and existing DNS service.

T

his isn’t something you like to think about. What happens if the unpredicted happens, and the migration fails? What will you do to recover from a failed migration? Contingency planning, which cer-tainly covers recovery planning, is another critical step in the migra-tion process. This way, if anything goes wrong, you have something to fall back on besides your resume.


Recovery planning should enable you to restore the original environ-ment as quickly as possible with no lost data. This is why a pilot migration to test the planning in the real production environment is so critical. Nearly every deployment has some problems, because the production environment always seems to be just a little different than you thought.


78

With a migration from NT to Windows 2000, there are some preven-tive measures that can be taken that will ensure that you have a safe recovery path. One of the key measures is to update a Backup Domain Controller (BDC) with current copies of all the major net-work services, then take it offline until the migration is complete. Once everything has migrated successfully, you can then decide what to do with the BDC.

Recovering the Security Accounts Manager

Database

The easiest way to recover the Security Accounts Manager (SAM) database is to never lose it in the first place. It sounds trite, but there really is a good way to do this. Just before you upgrade the domain controllers, select one BDC to be your recovery path. Synchronize it with the Primary Domain Controller (PDC) to make certain it has the most recent account information. Once this is complete, shut down the BDC and take it offline. This will become your safety hatch if you need to recover the SAM.

If the worst does happen, and you need to quickly move back to your previous network configuration, bring the BDC back online and pro-mote it to PDC. This new PDC will have account information that is current as of the last synchronization prior to the migration. The next step will be to reinstall Windows NT on your other domain control-lers and install them as BDCs to the new (old) domain. It will take some time to perform all of the reinstallations, but no account infor-mation will be lost.

The exam covers this technique in many of the case study questions. You will have to decide which BDC would be best to synchronize and take offline in order to prepare for disaster recovery during the migra-tion. Select a BDC in a site or location where the absence of a domain controller will have the least impact on the migration. For instance, if you have BDCs in several sites that will be part of a migration, use the BDC in the smallest site for recovery. That way, the other sites with more users will have access to a domain controller for migrating users and processing logons.

Chapter 2 �


79

NOTE Synchronize a BDC with the PDC and take it offline before per-forming your migration. This offline BDC will be your safety valve.

Recovering DNS

If the BDC that forms the core of your recovery plan is also a DNS server with current zone information on it, you can use the same approach to disaster recovery. DNS service information is easy to recover, since the zones are stored in simple text files. The DNS server would actually be easy to recover just by copying these files to the BDC before taking it offline.

The recovery path would then be used to restore the BDC, promote it, and then install the DNS server on it. Instead of re-creating the zone files, simply create new zones with exactly the same names as the old zones and point them to the existing zone files. The DNS server will come up with the old information intact.

Recovering DHCP

This one takes a little more effort to protect the information. You most likely won’t want to back up the actual DHCP database with all of its current leases, but you definitely should create copies of the scopes.

One method you could use would be to install the DHCP service on the BDC that will be held offline as a backup and create scopes that are exactly like the current scopes prior to the migration. Do not acti-vate these scopes! You really don’t want to be handing out duplicate leases on your network.

In a recovery situation, bring the BDC online and start the DHCP ser-vice if it hasn’t already started automatically. Activate the scopes, and verify that the service is running correctly. Make certain that the other DHCP servers are offline and their scopes are deactivated. Every client will need to release and renew their IP lease to prevent conflicts.


NOTE On the exam, Microsoft seems to like the approach of having the DHCP database backed up on tape.

The Windows 2000 version of DHCP has a new feature that Win-dows NT did not possess. After restoration of a DHCP backup, the DHCP scope information will be out-of-date. Therefore, the server goes into “safe mode of operations” for a period of one-half the IP lease duration set in the scope. In this mode, DHCP broadcasts on the network to verify that the address it is about to assign is not currently being used. Although this reduces the chance of having address con-flicts, it severely reduces network and server performance and should be halted immediately after the one-half lease duration period has expired.

WARNING DHCP will go into safe mode only when it is recovered from a backup. If you have the service installed on another machine with overlapping scopes, there is no way to ensure that address con-flicts will not happen.

Recovering WINS

You could approach this in a couple of different ways. Entries in the WINS database are made dynamically when WINS-enabled clients boot onto the network and enter their registrations in the database. Even though it may seem silly to back up and recover WINS, it is a potential test topic.

Perhaps the greater issue is reenabling WINS on the client computers so that they can once again make use of the service. As they reboot, they will make new registrations in the database, and the information will be reconstructed.

Recovering the ability to use WINS will be very important when returning to the native NT 4 environment, since this is the primary method clients use to locate the domain controllers for their services.

Chapter 2 � Preparing the Environment for Migration 81

If your current network uses WINS extensively, you may have to recover the WINS replication partnerships to fully restore the service at an enterprise level. You would complete this process by adding the WINS server IP addresses to the WINS Manager utility and then using these addresses to establish replication partnerships. If you are using WINS replication, immediately initiate a replication between servers after restoring the WINS database.

Microsoft again seems to like the approach of restoring the WINS database from tape when restoring a domain after a failed migration. This is a wise course of action if there are a number of static entries in the database. Bear in mind, though, that the WINS database will regenerate when the client computers make new registrations as they reboot. Restoring the previous database from tape may help to reduce confusion for the client computers when they reboot, but more likely it will just cause additional work.

Protecting Data

Back up your data early and often. Please ensure that your backups are current and that the data can be recovered safely from those tapes. Remember that a backup is not considered good until you have suc-cessfully recovered data from the tapes.

Back up the data on every server that will be migrated. This does not express any lack of faith in Windows 2000, but is simple prudence. The same recovery planning you did for a migration will work for a restructure. Having a BDC held offline during the process gives you a way out if things go wrong.

Exam Essentials

Know the best thing you can do to plan for disaster. If you had to choose one thing, it would be installing the services you are running on your network on an NT BDC, synchronizing it with the PDC for your domain, and taking it offline before beginning the migration.


Know how to recover DNS, WINS, and DHCP services. There are two good courses of action. One, place them on the BDC you are going to take offline. Two, back up the services to tape or other backup media.


disaster recovery Being able to restore the network to a previous configuration if errors happen during the migration.

Chapter

3

Planning and Deploying a Domain Upgrade


�


(pages 84 – 90)

�

Develop an operating system upgrade path.

Considerations may include operating system

version and service packs.

(pages 90 – 92)

�

Upgrade the PDC, BDCs, application servers, DNS

servers, and RRAS servers.

(pages 93 – 98)

�

Configure networking protocols, DHCP, LAN

Manager Replication, WINS, NetBIOS,

Windows 2000 DNS Server service, and existing

DNS service.

(pages 99 – 102)

�

Implement group policies.

(pages 102 – 115)

�

Implement file replication bridges.

(pages 115 – 119)

�

Convert domains to native mode.

(pages 119 – 124)

�

Perform test deployments of domain

upgrades.

(pages 124 – 126)

�


(pages 126 – 137)�

Restore pre-migration environment.�

Roll back implementation to a specific point.

�


(pages 137 – 139)�

Back up domains.�

Verify functionality of network services.

T

his is the meat and potatoes of your entire migra-tion. From planning, to actually doing it, to cleaning up afterward, there are a lot of important steps to hit.

Planning, of course, is critical to any successful migration job. Deploying a new Windows 2000 domain is no different. Planning in this case will involve how to migrate your domain or domains, in which order to migrate them, and in which order to migrate your servers. You can expect more than a few questions on the test involv-ing proper order for these migrations.

Once you have started the migration, there are new issues to face. How do you deal with Group Policies, file replication, and this thing called native mode? What does it all mean, and what is the best way to implement new Windows 2000 features?

Finally, you get to do a trial run, and then the real thing. Figure out what it’s going to take, how to back out if something goes wrong, and what to do once everything turns out okay.

The concepts in this section are heavily tested, but are also important if you are looking for tips on planning and performing a real-life migration. Migrating from Windows NT to Windows 2000 is not incredibly difficult, nor should it cause serious problems and loss of sleep. Being aware of all the points along the way will help ensure that the process is a smooth and rewarding experience.

�


Y

ou’ve been looking at all of the points that you will need to consider in your deployment plan, but now you need to consider the

Chapter 3 �


85

actual procedure that should be followed during the deployment. This procedure is also an item that must be planned for and tested before performing the real rollout. While it may be difficult for Microsoft to directly test your thought process when planning a domain upgrade, you can expect questions involving the order of migration, and how to proceed in a given situation.


Before you begin planning, take a moment to remember your upgrade goals. Most of the time, goals center on either business needs or tech-nology needs. You likely decided to upgrade for a specific reason, not just because it sounded like fun. In this planning, always focus on the goals and how to most easily achieve them.

Here are some business-related goals that you might want to consider during migration planning, along with the features of Windows 2000 that support your goals:

Better manageability

Windows 2000 provides many enhanced fea-tures to ensure that manageability is not an issue. In Windows NT, you had to maintain trust relationships among multiple domains. Windows 2000 provides these trusts automatically among all domains in a forest.

Windows 2000 allows you to structure your domain to reflect the physical organization of your company. This, along with the extended ability to nest different groups, allows you more granular control of all resources on your network.

The Microsoft Management Console (MMC) provides one interface for administration. This will save you the time that would otherwise be spent learning multiple interfaces for administration.

Greater scalability

Windows 2000 Server allows access to up to 4GB of physical memory. Also, Windows 2000 no longer lives by the NT limitation of a 40MB Security Accounts Manager (SAM) data-base. Active Directory can store literally millions of objects without trouble.


86

Improved security

Through the use of Group Policy, administra-tors can assign very specific restrictions to users, groups, and com-puters. Windows 2000 also comes with a Security Configuration and Analysis tool to analyze the security policy on a computer and reapply settings if necessary. Microsoft refers to this as a “define once, apply many times” approach to security.

Upgrading your network to Windows 2000 is supposed to increase productivity and decrease administrative overhead in the long run. While planning to perform this migration, keep in mind some impli-cations for the migration itself:

Minimize disruption to the production environment

User access to applications and resources should not be sacrificed. Ideally, there will be no downtime during the migration when users will be unable to access resources they need to perform their jobs. You should also be able to maintain users’ environments during and after migration.

Minimize administrative overhead

Migrating user accounts, user account settings (passwords), and permissions should not require dis-ruption of resource access.

New features

When migrating to Windows 2000, try to activate the new features as quickly as possible. Also, don’t compromise any secu-rity settings or policies during the migration.

Order of Migration

In order to make the migration as smooth as possible, it is advisable to perform the following steps in the proper order. You will also want to be sure to carry out the upgrade in a test environment before performing the actual procedure.

Pre-upgrade

Financially, the ideal situation may be for you to be able to use your current domain controllers as domain controllers for the Windows 2000 domain. This may not be possible due to insuffi-cient hardware. The first step, assuming that you want to continue to use the current domain controllers, is to verify that the current

Chapter 3 �


87

hardware is capable of supporting Windows 2000 as a domain con-troller. Take an inventory of all current domain controllers, and make a computer assignment table. List which computers can be upgraded and which cannot. If needed, purchase additional hardware that meets the requirements of Windows 2000.

Once you have validated the existing hardware, you need to secure the domain data. Do this by backing up the primary domain con-troller (PDC) as well as at least one backup domain controller (BDC). Make sure before you back up the BDC that it has been synchronized with the PDC. You will also want to remove a syn-chronized BDC from the network and store it. If the migration fails for any reason, you now have a back-out machine with which to restore the old NT domain.

Finally, install a Windows 2000 server into the existing Windows NT domain, and install the DNS service. This DNS service is required for Active Directory. Windows 2000 DNS is sufficient, as is any BIND 8.1.2 version or newer.

Upgrade Procedures

Once you have completed all pre-upgrade procedures, you can start the actual migration:

1.

Configure a remaining BDC as an LMRepl export server for logon scripts (if needed). This is because the PDC will no longer be able to play the role of export server if you are using replication in the domain. Ideally, the machine you make the export server will be the last domain controller promoted to Windows 2000.

2.

Upgrade the PDC to Windows 2000.

3.

Verify the DNS configuration on the Windows 2000 member server you installed in the NT domain.

4.

Promote the former PDC to a Windows 2000 domain controller as a new domain controller in the root domain.

5.

Test the new Windows 2000 environment by creating a user and logging on.


88

6.

Promote a Windows 2000 member server to a domain controller. You want to ensure that there is not one point of failure for your new domain. The quickest way to accomplish this is to promote your existing Windows 2000 member server to a domain control-ler in the existing domain.

7.

Upgrade the Windows NT BDCs to Windows 2000. Just because you upgrade them does not mean they have to be domain control-lers in the new domain. That is a decision you need to make here.

8.

Switch to native mode once all the domain controllers are migrated.

9.

Upgrade the member servers.

10.

Upgrade the client computers.

11.

Migrate the global groups, local groups, and users.

Once again, it is strongly recommended to attempt the migration in a test environment before performing the actual upgrade.

Upgrading Complex Windows NT Domain Structures

When upgrading more complex domain models, the process as out-lined above generally stays the same. First determine in what order you want to migrate your domains. Once you have determined that, figure out what type of Windows 2000 domain structure you are going to want to have.

First, the best choice is to migrate the accounts domain as a parent domain in a new forest. Administration will be easier, and it provides for more control of the new Windows 2000 domain structure than if you migrate resource domains first.

Once your accounts domain has been migrated, you can then migrate your resource domains. When migrating resource domains, you have a few choices. One choice is to create child domains of the existing parent domain. The other is to restructure and consolidate all domains into one. The main reason Windows NT used resource domains was to allow local administrators the ability to control their own resources. In Windows 2000, you can delegate control of resources to specific user accounts on specific containers, providing

Chapter 3 �


89

for desired administrative control. As part of your upgrade plan, you may want to consider restructuring your resource domains as Organizational Units (OUs) within your new Windows 2000 domain.

And since Windows 2000 no longer has a limit on the SAM database size, you will want to strongly consider migrating all user accounts to one domain if you were previously running a master or multimaster domain model.

When upgrading resource domains, it may be difficult to decide which domain to upgrade first. Use these guidelines to assist in your decision:

�

Choose domains in which mission-critical applications will require Active Directory features. Applications like Microsoft Exchange Server 2000 require Active Directory.

�

Choose domains with more clients over domains with fewer clients.

�

Choose domains that are targets for restructuring.

No matter what order you migrate your domains in, always keep in mind your original goals and priorities for the upgrade.

Exam Essentials

Know the proper order for upgrading computers in a domain.

The first machine that must be upgraded is the PDC, followed by any desired BDCs, and then the member servers.

Know the proper order for migrating domains.

Accounts domains should be migrated before resource domains. If you have multiple domains of the same type, prioritize the domains and upgrade the most important ones first. Preferences should be given to larger domains, or domains that supply mission-critical resources.

Know critical pre-upgrade steps.

Make sure to back up the existing PDC and any BDCs before the upgrade. Synchronize one BDC with the PDC, and take it offline. This computer will become your security blanket.


90


trust relationship

Relationship established among multiple domains in order to facilitate the granting of access permissions for resources in one domain to users in another domain.

�

Develop an operating system upgrade path. Considerations may include operating system version and service packs.

Y

ou’ve now developed a procedure for upgrading your domains, and have plans in place. Now, will the machines in the existing network support Windows 2000? And if they will, are they running operating systems that can be directly upgraded to Windows 2000? Knowing what you can upgrade to, given what you have, is crucial to the migration.


While performing clean installations of Windows 2000 would be the preferred method of upgrading your network, there will be times when you want or need to upgrade an earlier version of NT and keep all of your user settings. For those times, keep in mind the available upgrade paths for Windows 2000. Table 3.1 shows the possible com-binations of NT and Windows 2000.

T A B L E 3 . 1 :

Upgrade Options from NT to Windows 2000

Operating System Can Upgrade to Can Become

Windows NT Workstation 3.51 or 4

Windows 2000 Professional

User workstation

Chapter 3 �


91

The ability to upgrade from Windows 9

x

is new to Windows 2000. With NT you could install a dual boot, or you could format and start over on a computer. Windows 2000 supports FAT32, which makes dual booting easy with either version of Windows, and the Windows 2000 Setup program knows how to upgrade the Win-dows 9

x

Registry.

Notice in Table 3.1 that versions of NT earlier than 3.51 are not supported for direct upgrades. The following operating systems may require a fresh install of Windows 2000:

�

Windows NT Server 3.1 and Advanced Server 3.1

�

Windows NT Workstation 3.5 and Server 3.5

�

Windows NT Small Business Server

�

Windows NT Server with Citrix WinFrame installed

�

Windows 3.1

Even though the above operating systems cannot be directly upgraded to Windows 2000, they can be upgraded in a roundabout way. First, upgrade the operating system to one it can be upgraded to. Exam-ples would be upgrading Windows 3.1 to Windows 98 or upgrad-ing NT 3.1 to NT 3.51 or NT 4. Once that upgrade is completed, upgrade the new operating system to Windows 2000.

Windows NT Server 3.51 or 4

Windows 2000 Server

Stand-alone server, member server, domain controller

Windows NT 4 Enterprise Edition

Windows 2000 Advanced Server, Windows 2000 Data-center Server

Stand-alone server, member server, domain controller

Windows 95 or 98 Windows 2000 Professional

T A B L E 3 . 1 :

Upgrade Options from NT to Windows 2000

(continued)

Operating System Can Upgrade to Can Become


92

This upgrade path may seem to be a bit of a reach. However, the major advantage of doing it this way is that all user account informa-tion and security information is maintained. This will save you the headache of having to re-create all users and groups, as well as reas-signing permissions to all resources.

Since you should have been running the latest service pack for Win-dows NT, service packs should not be an issue when migrating to Windows 2000. If by chance you have not upgraded to the latest ser-vice pack, Microsoft recommends at least going to NT SP4 before making the jump to Windows 2000.

Exam Essentials

Know what operating systems can be directly upgraded to Win-dows 2000.

Windows 95, 98, and NT machines can be directly upgraded to Windows 2000.

Know how to upgrade an “incompatible” operating system to Win-dows 2000.

There are two choices. One choice is to upgrade the OS to one that is able to be directly upgraded to Windows 2000. The sec-ond choice is to completely reinstall the machine.


dual boot

Installing two or more operating systems on a computer, and having the ability to choose between them at system startup.

member server

Windows NT Server or Windows 2000 Server com-puter that is part of a domain, but is not a domain controller. Mem-ber servers do not authenticate users in the domain.

service pack

Collection of patches and upgrades to critical operat-ing system files.

stand-alone server

Windows NT Server or Windows 2000 Server computer that is not part of a domain.

Chapter 3 �


93

�

Upgrade the PDC, BDCs, application servers, DNS servers, and RRAS servers.

Now it’s time to upgrade the primary and backup domain con-trollers to begin the migration to Windows 2000. Most of your serv-ers will be easy to upgrade, with little or no preparation required. Application servers, DNS servers, and Remote Access Servers (RAS) will be covered in the following sections.


Before you get started, you will need to consider some of the basic points of an operating system upgrade, such as the possible upgrade paths and the required hardware, just to be sure that your domain controllers can be upgraded. Table 3.2 shows the possible upgrade paths from NT to Windows 2000 for domain controllers.

T A B L E 3 . 2 : Upgrade Paths for Domain Controllers

Upgrade From Upgrade To

PDC or BDC running NT Server 3.51 or 4

Domain controller running Win-dows 2000 Server or Advanced Server.

Member server running NT Server 3.51 or 4

Member server running Win-dows 2000. After the upgrade, the member server can be changed to a domain controller using dcpromo.exe if you choose.

Any computer running Windows NT Server 3.1 or NT Server 3.5

Must be upgraded to Windows NT Server 3.51 or 4 first, then can be upgraded to either Windows 2000 Server or Advanced Server. Then use dcpromo.exe to promote the server to a domain controller.


All domain controllers in a Windows 2000 environment are equal in their roles and responsibilities. There won’t be any distinction between primary and backup domain controllers after you’ve per-formed the upgrade. This really has no impact on how your network functions, but it may cause some confusion for administrators who are learning Windows 2000.

Having an accurate inventory of computer hardware is especially important when upgrading older domain controllers from NT 3.51 or 4 because the hardware requirements were significantly lower for both of those operating systems. You may find that the first step in upgrading your domain controllers is actually to upgrade the hard-ware installed in them. Table 3.3 shows the required hardware for Windows 2000 domain controllers.

T A B L E 3 . 3 : Hardware Requirements for Windows 2000 Domain Controllers

Hardware Type Requirements

Processor Intel (or compatible) Pentium 133MHz or higher

Memory 128MB minimum256MB or more recommended

Hard disk 1.2GB of free space on the boot partition6MB of free space on the system partition

Display VGA or better

Optional components CD-ROM or DVD-ROM drive for local installation

Network Network interface card (NIC) and necessary cables

Other components KeyboardMouse or other pointing device

Chapter 3 � Planning and Deploying a Domain Upgrade 95

Upgrading Your Domains and Servers

Now that you’ve considered these two basic points regarding paths and hardware, you’re ready to begin the upgrade. Focus on upgrading your primary and backup domain controllers as well as your appli-cation, DNS, and RAS servers.

Create Fault Tolerance

One of the most critical elements in the upgrade process is recovery. In order to be certain of recovery, you must create fault tolerance. Fault tolerance means the ability to continue normal operation in spite of minor failures. In the case of upgrading your domain control-lers to Windows 2000, this means having a path to recover your domain information in case the upgrade fails. This is fairly easy to do simply by reserving one of the BDCs.

Pick one of your BDCs to be the reserve computer and ensure that it is fully synchronized with the PDC. Take this fully synchronized BDC off the network until the upgrade has been completed for all of the other domain controllers. Once everything is operating normally under Windows 2000, you can upgrade this last domain controller. This strategy also works for preserving other network services.

Preparing the Domain Controllers

Before you initiate the Setup program for Windows 2000 on your domain controller, do the following:

1. Disable virus protection. Anti-virus programs can wreak havoc on operating system installations. Some of these programs are sophis-ticated enough to recognize that you’re installing an operating sys-tem and they won’t interfere, but don’t take any chances.

2. Disable third-party services. Any system or network services run-ning on the computer that are not part of NT should be tempo-rarily disabled to prevent conflicts during setup. A good example of this would be if you had Client32 from Novell installed on the server to enable it to communicate with NetWare servers.


3. Disconnect the serial cable from either the uninterruptible power supply (UPS) or the computer, whichever is easier to reach. UPSs can become confused by the hardware detection that Win-dows 2000 will perform during installation. Play it safe and disconnect the serial interface during setup, then configure the UPS support later when the installation is complete.

4. Reserve hardware resources for ISA cards. If your domain control-lers have any ISA adapters installed, it’s best if you use the com-puter’s BIOS to reserve the IRQ and DMA resources prior to installing Windows 2000. Consult the BIOS manufacturer’s instructions for help. This step will help to avoid any problems during hardware detection.

Performing the Domain Controller Upgrade

Now that you’ve taken steps to prepare for upgrading your domain controllers, it’s time to put the CD-ROM into the drive and start the setup. Of course, you can also perform the upgrade across the net-work from an installation share on another server using the winnt32.exe program. The primary domain controller will be the first domain controller to be upgraded in a domain.

When you run the setup program, the current domain information will be maintained along with any local computer settings. When setup completes, the computer will restart automatically and log on as Administrator so that the Active Directory Installation Wizard can run. After Active Directory has been completely installed, you have two options: further configure the domain or upgrade some of the BDCs. Although it may be tempting to keep the migration flowing, it’s good advice to test what you have already accomplished before going on. Try logging on as a user and accessing a resource first.

Upgrading Application Servers

Application servers will be upgraded using almost the same process as the domain controllers but with a few differences. Prepare the server in the same way by disabling any anti-virus programs and third-party services, disconnecting the UPS interface, and reserving hardware


resources for ISA cards. After you’ve completed all of the necessary preparations, it’s time to begin the upgrade.

WARNING App servers can cause the most problems during up-grades, especially when dealing with third-party apps. Research the application, and make sure it is fully compatible with Windows 2000.

When you insert the Windows 2000 CD-ROM, you will be presented with the same options as when you upgraded the domain controllers. If you choose to upgrade your server to Windows 2000, the upgrade will proceed without any input from you and will maintain the server’s entire configuration.

The main difference between upgrading member servers and upgrad-ing domain controllers is the function that they will have when the upgrade is complete. It’s possible that you may decide that you need more domain controllers in your Windows 2000 domain. Base your decision mostly on the efficiency of logons and authentication for clients. If you need faster logon access in a particular subnet, you might decide to promote a member server to be a domain controller. If this is the case, you can run dcpromo.exe to promote the member server to become a domain controller.

If the member server is running the Dynamic Host Configuration Protocol (DHCP), the service must be authorized in Active Direc-tory immediately after the upgrade. If the DHCP server is not autho-rized in Active Directory, it will not be allowed to offer leases to cli-ent computers. If the member server is running the DNS service, the zones will be available immediately after the upgrade with no fur-ther action from you.

RAS servers will also upgrade with little or no input from you, although there may be some configuration that must be completed after the upgrade. The default RAS permissions should remain the same as before the upgrade, but you will want to confirm security after the upgrade is completed.


Exam Essentials

Know the upgrade paths for domain controllers in Windows 2000.Generally speaking, any Windows NT 3.51 or 4 domain controller can be directly upgraded to a Windows 2000 domain controller. Other computers may be upgraded to domain controllers as well, provided the Active Directory Installation wizard is run.

Know hardware requirements for Windows 2000 domain controllers.The general requirements are a Pentium 133 or higher, 128MB RAM, 8GB (4GB for server, 8GB for Advanced server) hard disk space, a CD-ROM, a mouse, and a NIC. Just as important, know whether or not your current systems have enough hardware to realistically sup-port Windows 2000.

Know how to make a server into a domain controller. Domain controllers are promoted and demoted in Windows 2000 through the use of the Active Directory Installation wizard, or the command-line dcpromo.exe.

Know how to make DHCP work in Windows 2000. To allow the DHCP server to give out addresses in a Windows 2000 domain, the DHCP server must first be authorized in Active Directory.


Active Directory–integrated zone Windows 2000–specific DNS zone that is tied in with Active Directory. This allows for replication of DNS data to be secured as it crosses the network, and provides for secure dynamic updates.

fault tolerance Being able to survive a hardware failure with no downtime.

UPS An uninterruptible power supply is an online battery backup for your servers. If the power fails, a UPS can provide enough power to run the server for a period of time, and/or give you enough time to properly shut down the server.


�Configure networking protocols, DHCP, LAN Manager Replication, WINS, NetBIOS, Windows 2000 DNS Server service, and existing DNS service.

Most of these are services you used pre-Windows 2000. Now that you are upgrading, or have already upgraded, to Windows 2000, it’s important to reconfigure the services you need to provide proper functionality. This objective is very closely tied with a sub-objective in Chapter 1, “Evaluate network services.”


For the most part, these services have not changed greatly from Windows NT to Windows 2000. This is a good thing, because it saves you from having to learn a whole new set of protocols, ser-vices, or networking rules.

When configuring protocols, know that Windows 2000 supports all major networking protocols, including TCP/IP, IPX/SPX, NetBEUI, AppleTalk, and DLC. However, for Active Directory to function properly, you must run TCP/IP. IPX/SPX would be required for connectivity to older NetWare-based networks. AppleTalk should be installed only if your network is supporting Macintosh clients. For testing purposes, DLC is still used for connectivity to HP printers.

DHCP

There are a few major changes for DHCP in Windows 2000. First, you must authorize the DHCP server in Active Directory before it can give out IP addresses to client machines. Second, DHCP has the abil-ity to provide the DNS server with the client’s computer name and IP address, on behalf of clients that are not capable of doing it them-selves. Other than that, the major DHCP rules still apply: Use more than


one server for fault tolerance, use DHCP Relay Agents or BootP-enabled routers for multiple subnets, and never have scopes with overlapping addresses.

LAN Manager Replication

Windows 2000 does not support Windows NT’s replication mecha-nism, LAN Manager replication (LMRepl). LMRepl controlled repli-cation of files by having one computer designated as an export server, and other computers would be designated as import computers. Even though you could set up multiple export servers, maintaining replica-tion infrastructure was tedious at best. There were also numerous issues with replication functioning properly.

Replacing LMRepl in Windows 2000 is FRS, or File Replication Services. FRS integrates closely with Active Directory, which allows it to make use of multimaster replication technology. The two systems are incompatible.

During the migration, you need to create a file replication bridge to handle replication between the incompatible replication systems. This bridge will export information from a Windows 2000 domain controller to the Windows NT export server. From there, LMRepl will take over, and the Windows NT export computer will replicate with all its replication partners. Once the migration is complete, LMRepl is no longer an issue. If you had created a file replication bridge, you may now delete it.

WINS and NetBIOS

Windows Internet Naming Service (WINS) was used in Windows NT to provide NetBIOS name to IP address name resolution. This func-tion has been greatly downplayed in a Windows 2000 environment, as DNS is now handling the primary name-resolution duties.

If you are going to run a pure Windows 2000 environment, then WINS is completely unnecessary. If this is the case, you can disable the NetBIOS interface on your Windows 2000 computers and reduce your network traffic.


However, if any applications require NetBIOS services, or you have any computers that are running Windows NT or 9x, you may need WINS services. Only keep WINS around if you have large numbers of these downlevel clients; otherwise, they can use other methods for name resolution instead. If you have downlevel clients and disable the NetBIOS interface on your Windows 2000 machines, those comput-ers with the disabled interface may not be able to communicate with the NetBIOS-based machines.

DNS

There are a couple of points to keep in mind when dealing with DNS in Windows 2000. If you have the option to use Microsoft’s imple-mentation of DNS, do it. It’s designed to provide everything Active Directory needs. It’s also least likely to cause you problems on a Win-dows 2000 network.

If you want to use third-party DNS servers, there are versions that perform admirably. BIND versions 4.9.6 and newer support SRV records, which Windows 2000 uses to locate domain controllers. BIND 8.1.2 supports dynamic updates. While dynamic updates are not necessary in Windows 2000, they greatly reduce your administra-tive burden. The current BIND DNS version (at the time of this book’s writing) is 8.2.2. BIND 8.2.2 has added, among other things, the support for Incremental Zone Transfers (IXFRs), which reduce zone replication traffic. Windows 2000 DNS also supports the use of underscore (_) characters, as do the current BIND renderings.

Exam Essentials

Know what protocols Windows 2000 supports. Windows 2000 supports all major networking protocols. However, TCP/IP is required to run Active Directory.

Know how to get LMRepl and FRS working together. During the migration, in order to get the dissimilar replication schemes cooper-ating, you need to create a file replication bridge.


Know when to use WINS. You only need WINS if you have down-level clients on your network.

Know what BIND versions of DNS provide necessary features. At the very least, BIND version 4.9.6, which supports SRV records, is required. BIND 8.1.2 supports dynamic updates, and BIND 8.2.2 supports IXFRs and underscore characters.


downlevel clients Client machines that are running a pre-Windows 2000 operating system.

�Implement group policies.

Administrators of Windows NT domains frequently used Sys-tem Policy to control the actions of users. System Policy worked by applying templates to the Registry of a computer to enforce user, group, or computer settings. In the past, these settings were effective for most NT administrators but often led to additional issues because they could not be reliably removed from the Registry.

Another footnote to consider is that while Group Policy on Win-dows 2000 is great, older Windows clients cannot use it. The old System Policy can still be used in Windows 2000 for legacy clients by placing the config.pol or ntconfig.pol file in the netlogon share of a Windows 2000 domain controller.


Windows 2000 has introduced Group Policy to replace the old Win-dows NT System Policy. Group Policy is much more extensive than System Policy. It combines the use of Registry templates with scripts


for various events and has an automatic refresh capability. Group Policy is implemented in the following ways:

Administrative Templates These templates are essentially the System Policies from NT 4, but with more granularity. They can be defined by an administrator and then applied to any user, group, computer, or OU. Administrative Templates can be modified to more closely coincide with your past System Policy settings by using your old .adm policy templates to provide the definitions for the Windows 2000 Administrative Templates.

Security Similar to the file security available in the NT file system (NTFS), these security settings can be applied to local resources just as they could in NT 4, but also to network, computer, and domain security objects.

Software Installation The software installation capabilities in Win-dows 2000 are quite good. This function of Group Policy lets you define the software installation parameters for a program and then assign those parameters to a Group Policy Object (GPO).

Scripts The scripts in Windows 2000 go beyond the traditional logon scripts. There are now separate scripts for startup, logon, logoff, and shutdown events.

Folder Redirection This feature of Group Policy enables adminis-trators to redirect a group of user folders to a network share. Certain folders can be stored on a network share point and can then be accessed from anywhere on the network.

In Windows 2000, when you create a new GPO you are creating a vir-tual storage container for all of the settings that make up that Group Policy. The GPO has a Group Policy Container, which is an Active Directory object that stores the GPO’s attributes and has sub-containers that describe the individual policies that apply to com-puters, users, or groups. The Group Policy Container holds the following:

� Version Information: Helps to synchronize the current GPO with the Group Policy Template.


� Status Information: Indicates whether the GPO is activated or deactivated.

� List of Components: Contains extensions to the GPO, such as scripts or Registry templates that make up the GPO.

The other component of a GPO is the Group Policy Template (GPT), which is actually a folder hierarchy in the Sysvol folder on every domain controller. The GPT is the container for all of the Group Pol-icy information. The GPTs are stored by the Globally Unique Identi-fier (GUID) that was assigned to them when they were created.

Group Policy Inheritance

GPOs are assigned at various levels in Active Directory. They can be assigned at the local computer, site, domain, or OU level. When you assign Group Policy, be aware that by default the GPO’s settings will be inherited by the containers below it in Active Directory. This means that when you assign Group Policy at the domain level, the GPO applies to the domain, but also to any OU within that domain, any OUs within those OUs, and so on.

If your Group Policy is simple and will be applied to everyone equally across the domain, then assign the GPO at the domain level and allow it to be inherited by all OUs within the domain. More commonly, Group Policy will be defined for several different levels. But then, how do you prevent a change made at the domain level from over-writing your GPO at the OU level? You can force inheritance and also block inheritance at any level in Active Directory.

If you decide that you need to prevent GPO settings from flowing down through inheritance to your OU, you can set the OU to Block Policy Inheritance. This setting will prevent the OU from accepting any GPO that’s higher in the Active Directory tree. As an administra-tor, you might feel that this is a bad thing and so decide to use a No Override setting on your GPO so that administrators lower in the Active Directory hierarchy cannot block the inheritance of your GPO. If Block Policy Inheritance and No Override are both set, No Override has precedence.


There is a problem with inheritance at the site level. If you set a GPO for a site that contains more than one domain, the GPO applies to all of the domains within that site. The GPO, however, is stored in only one domain. This means that all computers in all of the domains within that site must contact one of the domain controllers where the GPO is stored.

You want to be careful not to apply excessive Group Policies on the network. The more Group Policies linked to the domains and OUs, the longer it will take users to log on. Try to apply Group Policies somewhat sparingly without compromising network security.

Processing Group Policy

Because Group Policy is composed of so many different parts in Windows 2000, you’ll need to understand which part is applied first. A GPO may contain scripts, Registry settings, and security settings, or any combination of these. If you ever find yourself hav-ing to troubleshoot these combinations, you’ll want to be familiar with the order of precedence among the components of a GPO.

Group Policy is processed in this order:

1. When the computer starts, the following occurs:

A. Settings for computers are processed first. These are performed synchronously by default. You can speed the execution of the policy by changing it to asynchronous processing.

B. Startup scripts are processed. These too are processed synchro-nously by default. Each script must complete or fail before the next script can process. Here again, your performance may benefit from asynchronous processing.

C. All GPOs that affect the computer must be processed before the logon screen can be displayed.

2. When the user logs on, the following occurs:

A. Group Policy settings for the user are processed. This too is done synchronously by default.


B. Logon scripts are run. The logon script associated with that particular user is run after all other user-level scripts have com-pleted. This time, the processing is asynchronous by default.

3. When the user logs off, the logoff scripts are processed. These are processed synchronously by default.

4. As the computer shuts down, the shutdown scripts are run.

With Group Policy in Windows 2000, you don’t have to wait for a user to log off and log on again to see the effects of a policy change. Windows 2000 can automatically refresh the Group Policy on every client computer every 90 minutes (with a 30-minute random offset) and refresh the policies on domain controllers every 5 minutes. If 90 minutes is too long for you, you can adjust the refresh time through a Group Policy setting. You can also force a refresh of Group Policy at any time. Setting the refresh rate too high can cause superfluous network traffic.

Creating Group Policy

Before you can do anything with Group Policy, you’ll want to load the Group Policy snap-in in an MMC.

After creating a GPO, the next step is to link the GPO to an Active Directory container. When you link a GPO to a container, you are creating an association between the two objects, basically telling Windows 2000 to use this GPO for that container. The steps to link an existing GPO with a container are the same as those for creating a new GPO, except that on the Group Policy tab of the container’s Properties sheet, you would browse for the existing GPO and click it to highlight it. When you click the Add button, a link is created.

If you want to create or link a GPO for a site object, the process is the same except that you would use the Active Directory Sites and Ser-vices console to create it. By default, a GPO defined for a site is stored in the root domain of the forest, but you can define another location when you create the GPO.


Setting Permissions for Group Policy Objects

In order for users to be affected by Group Policy settings, they must be granted Read and Apply Group Policy permissions. You can also delegate administrative control of GPOs with proper permissions. When you create a new GPO, the default permissions are as follows:

Authenticated Users By default, this group has the Read and Apply Group Policy permissions.

System This account has the Read, Write, Create All Child Objects, and Delete All Child Objects permissions.

Domain Admins This account has the Read, Write, Create All Child Objects, and Delete All Child Objects permissions.

Enterprise Admins This account has the Read, Write, Create All Child Objects, and Delete All Child Objects permissions.

The individual permissions are set just as they would be for files or other objects in Windows 2000. However, it’s best to use the Allow setting for each permission you grant, instead of the Deny setting. If you set the Deny option for a group, the person you want to admin-ister that GPO may be a member of that group. If so, they will be unable to access that GPO.

When you decide to delegate control of a GPO to a user or group of users in an OU, they must be given at least Read and Write permis-sions to the GPO. Anyone with both Read and Write permissions for a GPO can control every aspect of managing the GPO, except to give permissions to someone else.

Different permissions can be assigned to different groups on the same GPO. When setting permissions, remember that a specific Deny over-rides a specific Allow.

Managing Group Policy Flow

Group Policy flows down through Active Directory by default, but it may not give you the control you need if you let it do that. You can decide whether or not to allow the flow of policy through inheritance.


There are three basic ways to control the flow of inheritance for Group Policy:

No Override This setting, when applied to a Group Policy Object, tells other GPOs not to override the settings within this policy. It is set on the GPO.

Block Policy Inheritance This setting prevents a container from accepting the policies of its parent container. That is, if you set the Block Policy Inheritance option for an OU within a domain, the pol-icies of the domain will not be applied to the OU.

Processing Order This isn’t a setting like the previous options. Instead, this describes the situation where there is more than one GPO linked to a Container object. When you view the Group Policy tab of the container’s Properties sheet, the GPOs will be listed. The processing order is top-down in that list. The first GPO on the list is the first to be applied. You can rearrange the order of the GPOs in the list to change the order in which they are applied.

In addition to changing the inheritance and processing order, you have yet another way to control the use of Group Policy. You may find over time that there are parts of your Group Policy that you no longer need. In this case, you can select a portion of a GPO that you want to disable. You can disable the computer settings, the user set-tings, or the entire GPO. You can also choose to delete a GPO from a container to either unlink it or permanently remove it. Disabling parts of the GPO allows logons to process faster, because the security manager does not need to read the disabled portions.

If you are applying Group Policies at multiple levels, they process in the following order: local GPO, site GPOs, domain GPOs, and OU GPOs. This effectively applies the GPO “closest” to the level of the object, while giving administrators blanket control over computers without worrying about local settings.

Configuring Group Policy

You can open a GPO in two ways. The first method was described in the “Creating Group Policy” section earlier in this chapter. The sec-ond is to open the Properties sheet for a container in Active Directory,


select the GPO on the Group Policy tab, and click the Edit button. Either of these methods will open a console similar to Figure 3.1.

F I G U R E 3 . 1 : Configuring a Group Policy Object

Group Policy is always focused on the PDC Operations Master, or PDC Emulator in a domain. The PDC Emulator provides the same functions as the PDC in a Windows NT network, though mostly for backward compatibility, since Windows 2000 doesn’t really need a PDC. The Group Policy is focused on this computer so that the same domain controller is always used to set policy. If the PDC Emulator is unavailable for any reason when you are modifying Group Policy, you will receive an error that gives you the option of saving the Group Policy on another domain controller.

Administrative Templates

Administrative Templates are the new and improved version of System Policy that were in earlier versions of NT. The templates are groups of Registry settings that can be applied to either users or computers.


Another cool new feature of Windows 2000 is the introduction of the Explain tab on the Properties sheet for any Administrative Template. This tab will provide an explanation of what the setting is and how it should be used.

Scripts

Scripts are an important part of Group Policy. There are some new script types for Windows 2000:

Startup This script executes when the computer starts up. It will execute whether or not a user logs on. It can be used to set machine-specific options.

Logon The logon script can be used to set user-specific options. This script executes when the user logs on to Windows 2000.

Logoff This script contains items to “clean up” after a user session. It executes when the user selects an option that ends the session, such as Shut Down The Computer.

Shutdown This last script executes after the logoff script and during the shutdown process for the computer. It gives you a chance to clean up after a user session and before rebooting the computer.

To define the options for scripts, open the GPO in the Group Policy console and expand the Scripts console tree. Right-click the type of script you want to modify (startup, logon, logoff, shutdown) and select Properties from the context menu. The Scripts settings for logon and logoff are found under the User Configuration branch, shown previously in Figure 3.1. The Scripts settings for startup and shutdown are found under the Computer Configuration branch.

Security Settings

The Security settings in Group Policy can help to secure your network against unauthorized use. Group Policy in Windows 2000 includes the following Security options:

Account Policies These are the settings governing things like pass-word length, age, uniqueness, and other options that affect user accounts.


Local Policies These include items such as the local user rights, the granting of user permissions, and the local audit policy.

Event Log This option controls the size, access permissions, and retention period for each of the event logs. Since the audit informa-tion is reported through the Security log, this is a fairly important part of your security settings.

Restricted Group This option enables you to audit the membership of the built-in group accounts such as Administrators and Power Users.

System Services Many services run under a user context, and many of those services have the ability to access restricted portions of the operating system. The settings here control the startup options for the service and the user context under which the service will run.

Registry This setting enables you to control access to the Registry and configure the security on individual keys.

Public Key Policies This option enables you to configure the set-tings for public key encryption. The Encrypted File System in Win-dows 2000 makes use of public key encryption. These settings determine where the certificate that is used to establish the public key comes from and, most important, who can act as a recovery agent to recover files that have been encrypted.

IP Security (IPSec) This setting controls the various aspects of net-work security in Windows 2000.

Folder Redirection

Folder Redirection enables your users to store some of their data on a network share transparently. That is, they don’t need to know where their share is or even be aware that their data is being redi-rected. This also serves to make their data available from any com-puter on the network. The data is not downloaded to the computer they are logging on to, so it doesn’t create any additional logon net-work traffic. Folder Redirection in Windows 2000 can be used to redirect these folders to a network share:

� Application Data

� Desktop


� My Documents

� My Pictures

� Start Menu

Converting System Policy

To get your Windows NT System Policy settings into Group Policies, Windows 2000 allows you to use the migpol.exe tool. However, it is strongly recommended that you start over and apply desired settings within Group Policy without trying to migrate old System Policies. This is because some settings in NT’s System Policy do not have equivalent settings in Windows 2000, and migrating these policies can cause unexpected results. Microsoft does not provide specific procedures for migrating System Policy settings.


This objective has four necessary procedures. Even though the test does not concentrate solely on Group Policies, being familiar with them will enhance your ability to correctly answer questions about them.

Loading the Group Policy Snap-in

To create a Group Policy object, you need to use the Group Policy snap-in. To load the Group Policy snap-in, follow this procedure:

1. Click the Start button and select Run from the Start menu.

2. Type mmc /a to open the MMC in Author mode.

3. Select Add/Remove Snap-in from the Console menu to open the Add/Remove Snap-in dialog.

4. Press the Add button to open the Add Standalone Snap-in dialog.

5. Browse the list for the Group Policy snap-in. Highlight Group Pol-icy and click the Add button. Click Close.

6. The Select Group Policy Object Wizard opens. This wizard asks you to define which Group Policy Object you want to focus on. By


default, the wizard will be set to focus on the local computer. This will be fine if you are managing the policy for the local computer. However, if you are setting Group Policy for a domain or a site, select the appropriate object by clicking the Browse button.

7. Click Finish to close the wizard and return to the Add Standalone Snap-in dialog. Click Close to close the dialog.

8. Click the Close button to close the Add/Remove Snap-in dialog and return to your console window.

Creating a New Group Policy Object

Once you have loaded the Group Policy snap-in to the MMC, it’s time to create a new Group Policy object. You can also use the Active Directory Users and Computers console to create a new Group Policy object. To create a new Group Policy using the Active Directory Users and Computers console, follow this procedure:

1. Open Active Directory Users and Computers and expand the con-sole tree to the container you want to apply a GPO to.

2. Right-click the container you want to apply the policy to, and select Properties from the context menu.

3. On the Group Policy tab of the Properties dialog, click the New button to create a new GPO.

4. Give the new GPO a name to distinguish it from the others.

Modifying Administrative Templates

Administrative Templates are used to define specific Group Policy set-tings and restrictions. Most of the time, the standard settings will be sufficient. However, Administrative Templates can be modified using this procedure:

1. Open the desired GPO in the MMC. Use either of the methods described earlier to open the GPO for editing.

2. Expand the trees for either User Configuration or Computer Con-figuration and then expand Administrative Templates.


3. Expand the option that you want to set. An example would be Administrative Templates � Network � Offline Files � Enabled.

4. Double-click the option that you want to set to open a dialog. Notice that you can enable, disable, or choose to not configure the option.

Redirecting Folders

One of the cool features of GPOs is the ability to redirect users’ fold-ers. This way, their documents may be stored on a server for easier backups and convenience, and the users do not need to know the files’ true location. To apply Folder Redirection, follow this procedure:

1. Open the Group Policy console and expand User Configuration � Windows Settings � Folder Redirection.

2. Right-click the folder you want to redirect and select Properties from the context menu.

3. Select the setting for the folder redirection. Possible settings include No Administrative Policy Specified, Basic, and Advanced. Basic enables redirection for all users to the same server location. Advanced enables you to set the target path according to the GPO.

4. Specify the target path. Notice that you can use the system variable %username%, which will replace the variable with the individual user’s name and create a specific folder for that user. This option is recommended because in addition to creating the folder auto-matically, Windows 2000 will also set the appropriate permissions to enable only that user to access the folder.

5. Use the Settings tab to specify the behavior of the redirected folder when it is created and when the policy is removed.

Exam Essentials

Know the default order for processing GPOs. GPOs will be pro-cessed in the following order: Local GPO, Site GPOs, Domain GPOs, and OU GPOs.


Know what Group Policies are used for. Group Policies have many functions in Windows 2000, including enforcing security settings, con-trolling users’ environments, running scripts, and deploying software.

Know how to convert System Policies into Group Policies.Windows 2000 provides the migpol.exe tool for conversion of Win-dows NT System Policies into Windows 2000 Group Policies. How-ever, Microsoft does not provide documentation on how to complete this process. It’s best to use trial-and-error for your new Group Policies.


System Policy Windows NT’s method for applying security settings to large groups of users, including desktop, network connections, and restriction settings.

�Implement file replication bridges.

During your migration, you may have to make sure all informa-tion is replicated among all domain controllers. If you have both Win-dows NT and Windows 2000 domain controllers, this can be a problem. Windows NT used LMRepl, which is replaced in Win-dows 2000 by FRS. In order to make the two communicate, you need a replication bridge.


Windows 2000 Server uses the File Replication Service (FRS) to rep-licate System Policies and logon scripts stored in the server’s System Volume (Sysvol) share. This Sysvol share is used by clients to locate and process policies and scripts. Because these policy and script set-tings are necessary to ensure security, it’s critical that all domain con-trollers have the same information. FRS can also be used to replicate Distributed File System (Dfs) data.


FRS is a multithreaded replication engine that replaces the LMRepl service used by Windows NT. Being multithreaded allows FRS to rep-licate files to different computers simultaneously. Note that FRS is a replication service, not a synchronization service.

FRS replicates only whole files and does not guarantee the order in which files will arrive. Because it replicates only whole files, it will replicate an entire file even if only one character is changed.

FRS is installed automatically on Windows 2000 domain controllers and is configured to start automatically. On Windows 2000 member servers, it is installed but must be manually started. There is no administrative console for FRS, as Sysvol replication happens auto-matically. Some features of FRS are

� Multimaster replication of files and folders. This allows for servers to independently update files as necessary.

� Automatic replication of file and folder attributes, including ACL information.

� Configurable replication schedules for Sysvol and Dfs replication between sites.

Sysvol

The Windows 2000 System Volume is built during promotion of the domain controller using the Active Directory Installation Wizard or Dcpromo. It is a tree of files and folders that need to be synchronized between domain controllers, including

� Sysvol share

� Netlogon share

� Windows 95, 98, and NT System Policies

� Windows 2000 Group Policies

� User logon and logoff scripts

Even though FRS acts independently of other Active Directory repli-cation, it uses the same replication mechanisms. Therefore, it uses the


same replication schedule for inter-site replication as ADS. However, unlike Active Directory, replication content between sites is not com-pressed. FRS works with Windows 2000 only because it counts on NTFS 5 to maintain a persistent logged record of file changes on member computers. When performing replication, it will always use the most current file.

Upgrading LMRepl to FRS

FRS is not supported by any operating system except Windows 2000. When dealing with migrating, mixed environments could run into problems with the idea of needing FRS. If you upgrade a Windows NT machine to Windows 2000, the LMRepl service will be replaced with FRS. But what about the domain controllers that are still running NT?

One major fundamental difference between the two replication mech-anisms is how they decide what should be replicated. LMRepl used an export folder and import folder mechanism. This means that the administrator had to designate which computers would be export computers and which would import. All changes to files that needed to be replicated had to be made on the export computer, or they would be overwritten when replication occurred.

FRS, on the other hand, uses multimaster replication, much like Active Directory–integrated DNS zones. Changes can be made to any member computer (member of FRS, that is—it is not necessary to be a member server) and replicated to any other member computer.

Maintaining a Mixed Environment

To provide support while upgrading your domain, you need to create a replication bridge between LMRepl and FRS so that both services can operate autonomously. Select one Windows 2000 domain con-troller, and have it copy files to the Windows NT export server’s export directory. The easiest way to accomplish this is by running a regularly scheduled script.

To maintain availability of LMRepl during an upgrade, make sure 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 server to host the export directory and then reconfigure LMRepl.

Once the migration is complete, replication is no longer an issue.

Exam Essentials

Know what LMRepl is. LMRepl, or LAN Manager replication, is the file replication mechanism used by Windows NT. It is not com-patible with Windows 2000.

Know what FRS is. FRS, or File Replication Service, is the engine used for file replication by Windows 2000. It is not currently sup-ported by any other operating systems.

Know how to get LMRepl and FRS working together. In order to make the two function together, but operate autonomously, you must create a file replication bridge. Once your migration is complete, you may delete the bridge as necessary.

Know what the Sysvol contains. The Windows 2000 System Vol-ume, or Sysvol, contains the Sysvol shared directory, the Netlogon shared directory, all system policies, group policies, and logon and logoff scripts.


Distributed File System (Dfs) System of sharing files in a Win-dows 2000 environment that creates a hierarchical share structure. In Dfs, the files that are part of the share do not necessarily need to be on the computer hosting the share.

multimaster replication Replication scheme used by Windows 2000, in which no single computer is responsible for initiating replication. Replication may be initiated by any number of peer computers.


Sysvol Shared folder system that is a collection of directories, files, and policies that need to be synchronized between domain controllers.

�Convert domains to native mode.

When performing your migration to Windows 2000, you will be running in mixed mode. This means, among other things, that you will not be able to take advantage of all available Windows 2000 fea-tures. This isn’t necessarily a handicap, but you need to be able to make an informed decision on when or if you want to convert your domains from mixed mode to native mode. Note that there are advantages to staying in mixed mode, and other advantages to con-verting to native mode.


During the migration of your network from NT to Windows 2000, there will be a time when you have a mixture of domain control-lers. In Windows 2000 terms, this is a mixed mode network. Mixed mode refers to having a mixture of NT and Windows 2000 domain controllers. You can easily have NT 3.51 or 4 member servers in a Windows 2000 domain and still be set to what Microsoft calls native mode. At the time of migration, you will have to decide when the most appropriate time to switch to native mode would be.

NOTE Microsoft recommends switching to native mode “as soon as possible,” meaning once all your domain controllers are upgraded to Windows 2000.

Native mode occurs when you no longer have any NT domain con-trollers and Active Directory has been set to function as the exclusive security model. When you have determined that all domain control-lers are running Windows 2000 and that none of your network


applications require the presence of an NT domain controller, it would be appropriate to switch the network to native mode.

NOTE Switching to native mode is a one-way process. You cannot switch back to mixed mode later.

Windows 2000 is quite able to function in mixed mode, but there are some considerations to keep in mind if you choose to keep your net-work in mixed mode. Basically, you need to consider these four areas if you decide to stay in mixed mode:

� Logon services

� Replication

� Remote Access Service

� Security

The first area concerns the different logon services provided by NT and Windows 2000. A Windows 2000 client computer will first attempt to use DNS to locate a Windows 2000 domain controller. If it is unsuccessful, it will fall back to the NT-LAN Manager (NTLM) logon protocol and try to contact an NT domain controller. If this is the case, your client computer will not use the Group Policy defined for the network or have the benefit of Windows 2000 scripts.

Another consideration is that FRS, the file replication service used in Windows 2000, is incompatible with the directory replication used in NT 4. Directory replication was used primarily for logon scripts and policy files. FRS handles these tasks, among others, in Windows 2000. As a result, you will need to migrate this service to FRS as soon as possible after the migration, or set up parallel rep-lication folders under the two different services.

The third consideration in mixed mode is the Remote Access Service (RAS). In NT, RAS logs users on as a special system account called LocalSystem. When a user would log on to the RAS server during a dial-up session, he would use LocalSystem with null credentials to


establish the session and then log on using NT credentials. Win-dows 2000 won’t allow anyone with null credentials to query the Active Directory properties, so this won’t work. It can work, how-ever, if one of the following happens:

The RAS server is an NT BDC. If the RAS server is an NT BDC, it will have local access to the Security Accounts Manager (SAM) data-base. In this case, authentication is possible.

The RAS server contacts an NT BDC. This scenario is very unpre-dictable but possible. If the RAS server just happens to find an NT BDC for the authentication, then this scenario will work.

Security is weakened. An option during the installation of Active Directory is to weaken the security on certain objects in Active Direc-tory in order for them to be compatible with NT. What happens is that the Everyone group is granted Read permission to any user object. This permits the null credentials logon to read the user’s infor-mation in Active Directory.

Security in a mixed-mode environment is the fourth concern. The trust relationships between NT domains were nontransitive. Trust relationships in Windows 2000 are transitive. This means that you must carefully define explicit one-way trust relationships between mixed-mode domains to mimic the transitive relationships of Win-dows 2000. Failure to do so means that users won’t be able to log on to another domain from a local computer if they are validated by an NT BDC.

Choosing between Mixed and Native Modes

Native mode requires that all domain controllers be running Win-dows 2000. There can be no NT domain controllers added now or later if you choose native mode. But running in native mode is the only way to take advantage of some of Windows 2000’s best features. Table 3.4 should help you decide when the time is right to move your domain to native mode.

It’s possible that you would want to keep your domain running in mixed mode if you have an application that must be run on an NT


domain controller and it absolutely won’t run on Windows 2000. But that’s kind of a long shot. Most networks should move over to native mode as soon as possible to take advantage of all of the new features and enhanced security.

T A B L E 3 . 4 : Mixed Mode versus Native Mode

Windows 2000

Feature Mixed Mode Native Mode

Multimaster replication Yes, among the Win-dows 2000 domain controllers. PDC Emu-lator provides single-master replication for NT domain controllers.

Yes

Group types supported

Global, Local Universal, Global, Domain Local, Local

Nested groups No Yes

Cross-domain administration

Limited Full

Queries of Active Directory using Desktop (My Network Places)

Only on Win-dows 2000 clients.

Yes

Transitive trust relationships

No Yes

Change/configuration management

Only on Win-dows 2000 computers.

Yes

Password filters Only if installed on each domain control-ler individually.

Yes, installed auto-matically on all domain controllers.


NOTE The only time you should stay in mixed mode is if you have an application that needs to run on a Windows NT BDC.

Most often, an application that is running on an NT domain control-ler requires a specific version of NT, not the presence of an NT domain controller. If this is true of an application in your network, then you have a couple of options to choose from. You could, of course, leave the network in mixed mode and keep that NT domain controller to support your application. Or you could off-load the application to a member server running NT. This would keep the appli-cation on a computer that provides the necessary software support and still permit you to switch your domain to native mode.

Exam Essentials

Know when you can switch to native mode. Microsoft recom-mends switching to native mode as soon as possible during an upgrade or migration. Once all of the domain controllers for the domain are running Windows 2000, you can safely switch modes.

Know the limitations of running in native mode. The single biggest limitation of running in native mode is that you can no longer install Windows NT BDCs into the domain. However, if the migration is proceeding properly, you shouldn’t need to anyway.

Know when not to switch to native mode. The only reason to keep the domain in mixed mode is if you have an application that requires the use of an NT BDC, and the application will not run on Windows 2000. Fortunately, there are not too many of these appli-cations out there.



NTLM Windows NT-LAN Manager authentication protocol. Used by downlevel clients to locate a Windows NT domain controller.

native mode Windows 2000 security mode in which all domain controllers are running Windows 2000, and the full functionality of the Windows 2000 operating system is enabled.

nesting Placing groups within other groups. With the exception of putting global groups into local groups, nesting is only allowed in native mode.

�Perform test deployments of domain upgrades.

You have your plan. You have the approval. You have every-thing you need to proceed. Before you do, take the time for one last task: test the deployment. In real-world scenarios, not testing the deployment before actually doing it can be catastrophic. Often, this is when you’ll find out what you forgot to plan for. Testing the deploy-ment gives you the opportunity to safely find out what things you have forgotten.


You can use a number of tools to test and verify a migration to Windows 2000.

To fully test the implications of your deployment, you must simu-late your production environment as closely as possible in your testing. Decide which elements of your deployment to test first, and set up that configuration to begin your testing. Focusing on the highest-priority portions of the deployment first is a good way


to begin. This may vary according to the project goals, but that usu-ally means testing the domain migration first.

The Domain Level

You should begin your deployment testing at the domain level. It is important to start here because this is the basic structure of your new network. Testing this area is critical because it will tell you if there are domain-wide issues that must be resolved before they affect your users.

As the migration progresses, pay attention to any difficulties reported by the pilot users who have already been moved to the new environ-ment. They are the ones who will most likely experience problems.

At each step of the migration, you should perform tests to determine whether the security principals that are being moved to the target environment still have resource access. If these accounts can access everything they need without problems, then you’re probably doing all right. On the other hand, if they run into access-denied messages when trying to access the resources they need to do their jobs, then you must reexamine the trust relationships from the old resource domains to the new accounts domain.

NETDOM will be a valuable tool during this phase of testing since it can be used within scripts to automate the process. NETDOM can examine the status of the trust relationships and help you to map them out to ensure that they meet the needs of your organization dur-ing the restructure. NETDOM is covered in more depth in Chapter 4.

Exam Essentials

Know where to begin when testing a deployment. As a rule of thumb, start at the domain level and work your way down. Make sure to test every service you are migrating, and periodically test users to make sure their resource access is not interrupted. Pilot groups are great for testing a deployment. It makes them feel powerful, and gives you the chance to fix any problems.



Domain Level The domain level is the first entry in Active Directory Users and Computers. You can set a GPO at this level and check or change most Operations Master roles.

NETDOM A program that examines the status of or reestablishes trust relationships between domains. NETDOM is also a migration tool and is discussed in detail in Chapter 4.

�Implement disaster recovery plans.

It’s never much fun thinking about all of the things that can go wrong with a project. But in the case of an operating system migration, you need to have a contingency plan just in case the unthinkable happens.

This objective covers some of the methods you can use in Win-dows 2000 to prepare for disaster recovery. You will learn about the Recovery Console, and how to recover from various problems with your Windows 2000 servers. You’ll also learn how to prepare a recovery plan for your Windows 2000 migration, including how to give yourself a way to return safely to the original configuration of your network.


When you are planning for disaster recovery, you are trying to plan for the unknown. You are attempting to think of any possibility for failure in your systems and to find a way to handle the problem just in case it really happens.

This is merely a nutshell description of disaster recovery, since you could easily write whole books devoted to the topic, but it will serve as a starting point to discuss the features in Windows 2000 that can


help you recover your network from a failed migration. First, take a look at some areas that will affect your overall migration planning.

Reviewing Your Plans

You’ve heard it before: Plan things out. When referring to disasters, it’s impossible to plan when or what they will be. However, it is possible—and suggested—to plan as much prevention and recovery as possible. There are two ways to deal with disasters: disaster pre-vention and disaster recovery. Most of the time, they are very much interrelated. Even the best-laid disaster-prevention plans can’t pre-vent crashes—they are prepared in the hopes of minimizing damage.

When reviewing migration plans for disaster prevention and recovery, break the plan down into three categories: hardware, software, and infrastructure. Whether this system works for you or not will be a matter of experience.

Hardware

There are numerous ways to protect your systems with hardware, from redundant hardware devices (such as hard disks, fans, and even CPUs), to RAID, to clustering. This is an area that will quickly go beyond the scope of this book, but a few topics should be introduced here. Most such devices will be highly dependent upon the server hardware you have chosen and will be supplied by the computer ven-dor. Important here is a discussion of redundant arrays of indepen-dent (formerly inexpensive) disks (RAID). RAID is often more proactive (used for prevention) than reactive (used for recovery), but it is a valuable part of any network and needs to be considered during migration.

RAID has several levels of protection and can be implemented in either hardware or software. The Windows 2000 Server family (Server, Advanced Server, and Datacenter Server) supports software RAID. All versions of Windows 2000 support hardware-based RAID, since the operating system would see the disks only as described by the RAID


controller. For the exam, you will need to understand the software implementation of RAID as provided by Windows 2000.

Windows 2000 provides RAID levels 0, 1, and 5. Table 3.5 describes some of the properties of the different levels.

RAID 0 is called disk striping. Striping provides very high perfor-mance for both reading and writing since the data is layered across multiple physical disks at the same time. Because the layers, or stripes, are distributed across multiple physical disks, Windows 2000 can retrieve multiple pieces of data, one from each physical disk, without having to wait for each request to be fulfilled. Striping gives you the fastest performance of any volume type available in Windows 2000, but it is not fault tolerant. If you are using RAID 0 and one disk fails, you will lose all of the data on the RAID 0 set.

RAID 1 is called mirroring because it uses two physical disks to create mirror images of the data. Mirroring is a good form of fault tolerance because if a single disk fails, the other disk in the mirror set still has the exact same data. Mirroring is the only form of software-based fault tolerance available to Windows 2000 system and boot files.

You might also see the term disk duplexing. Disk duplexing is the same as mirroring, but instead of the drives being on the same

T A B L E 3 . 5 : Properties of RAID Levels Supported by Windows 2000

Property RAID 0 RAID 1 RAID 5

Fault tolerance No Yes Yes

Minimum num-ber of disks

2 2 3

Maximum num-ber of disks

32 2 32

File systems supported

FAT, FAT32, NTFS

FAT, FAT32, NTFS

FAT, FAT32, NTFS


physical controller, they are on different controllers. Windows 2000 does not differentiate between mirroring and duplexing.

Many people consider RAID 5 the king of fault tolerance because it combines high performance for disk reads with superior fault toler-ance. RAID 5 is called striping with parity because the data is layered across multiple physical disks, just like striping, but each stripe also has a block of error-correction data called parity that can be used to reconstruct the data in the event of a single disk failure. Writing tends to be slower than for other volumes because Windows 2000 must compute the parity information for each stripe that it writes. Read performance is outstanding because RAID 5 reads just like a stripe set and the parity doesn’t matter. If a single disk fails in a stripe set with parity, the remaining data and the parity information combine to re-create the missing data on the fly. If multiple disks fail in a stripe set with parity, you must restore from a backup.

RAID can also be implemented in hardware, which is by far the better solution. A RAID controller typically has a dedicated processor and memory to handle the fault-tolerance operations of reading and writ-ing to the disk sets. The operating system on a computer with hard-ware RAID sees only the volumes that the hardware controller has already created and treats each of those sets as a single volume. Hardware RAID is much better, but it is expensive while the soft-ware version is free.

Windows 2000 also incorporates new types of partitions. Win-dows 2000 still supports the original partitioning that you’ve used for years but calls those partitions basic disks. On a basic disk, you can have a maximum of four partitions. These partitions can be a mixture of primary and extended partitions, though there can be only one extended partition per disk.

The new types of partitions in Windows 2000 are called dynamic disks. A dynamic disk can support an unlimited number of volumes. A volume is a logical division of a dynamic disk similar to a partition. Dynamic disks can have a larger number of divisions because the par-titioning information is stored in a space at the end of the drive. When you convert a basic disk to a dynamic disk, you must leave 1MB of


free space at the end of the drive to contain the partition information for the dynamic disk. Another way that Windows 2000 supports unlimited volumes on a dynamic disk is that you are no longer required to use a drive letter for a volume.

Windows 2000 supports mirror sets and stripe sets with parity on computers that have been upgraded from NT 4. There are some lim-itations, however. You can repair, break, or delete mirror sets on a basic disk, but you cannot create a mirror set on a basic disk. The same is true of stripe sets with parity. To create either a mirrored vol-ume or a RAID 5 volume, you must create them on a dynamic disk in Windows 2000. If you have upgraded your server from NT 4 to Win-dows 2000, you can convert your basic disk RAID sets to dynamic disks without losing data.

Software

Even when implementing fault-tolerant solutions such as RAID, you must still take other preventative measures. When discussing disaster recovery in terms of software, people are usually talking about backup programs. Windows 2000 contains an improved Backup pro-gram. You can start the program by clicking Start � Programs � Accessories � System Tools � Backup. Backup gives you immediate access to the Backup Wizard, the Restore Wizard, and the Emergency Repair Disk.

The edition of the Backup program in Windows 2000 is actually quite good, with many improvements over the old NT Backup. For instance, you can now back up to any available drive, even network drives and removable media. You can schedule backup operations using the integrated graphical schedule utility. The ability to back up to removable media means that your rewritable CD is now a valid backup device without additional third-party software.

The information that you really need for the exam involves the backup and restore of the system using the Windows Backup pro-gram. Backing up data works pretty much the same way that it did in the old NT Backup utility. If you want to perform a manual backup job (as in not using the wizard to set up the job), click the Backup tab,


as shown in Figure 3.2. Here you can check the boxes beside any drive you want to back up, or you can expand drives to back up individual files and folders.

F I G U R E 3 . 2 : The Backup tab of the Windows Backup utility

The check boxes have three states. A white background with no check mark means that nothing is selected. A white background with a check mark means that everything within that drive or folder will be backed up. And a check mark on a gray background means that some of the contents of the drive or folder are selected, but not all of them.

You can back up and restore any drive that can be accessed by Windows 2000, including network drives. The most important aspect of backup and restore for servers is a new option to back up or restore the System State. The System State is the current config-uration of the server, including the following:

Active Directory This is the heart of the domain information for a domain controller—or maybe even the entire forest. This database


contains all of the objects in the Active Directory: all users, com-puters, groups, and policies.

Boot files These are the files required to boot Windows 2000, typ-ically located in the C:\ folder. Specifically, they include NTLDR, NTDETECT.COM, and the BOOT.INI files.

COM+ Class Registration Database This database contains the registration information for program components that follow the Component Object Model programming specifications.

Registry This database holds configuration information for the local computer and users. It contains all of the information needed to run Windows 2000 on the local computer.

Sysvol This shared system folder exists on all Windows 2000 domain controllers. It contains scripts and some of the GPOs for the domain.

The system information must be backed up as a single unit; you can-not back up a single component of the System State. With the Sys-tem State information safely backed up, you can recover your domain controller from a complete failure. You would have to rein-stall Windows 2000 Server on your computer after repairing what-ever hardware caused the failure and then use the Backup program to restore the System State information. This will bring the domain controller back to the state it was in when the System State infor-mation was backed up. Any system information that was changed after that time will be lost.

NOTE Microsoft references show only the items in the previous list as parts of the System State backup. However, running a backup of the System State on a domain controller can easily back up nearly 300MB of system data! It appears to also back up all of the contents of the Winnt folder and subfolders. This is good in that it will provide a more complete restore, but it isn’t described in the reference materials. Be aware of this discrepancy when you take the exam.


Restoring data is just as easy as backing up. There is a wizard that will walk you through all of the necessary steps, or you can perform the restore manually. The Restore tab of Windows Backup is shown in Figure 3.3. To select data to be restored, simply check the boxes for the drives or folders that you want to restore. These check boxes have the same three state functions that the check boxes on the Backup tab have.

F I G U R E 3 . 3 : The Restore tab of the Windows Backup utility

The other main feature of the Windows Backup program is the inte-grated graphical scheduling program. This feature enables you to create a backup job and schedule it to occur once or at recurring intervals. To schedule a job, double-click the date you want the job to run, and the Backup Wizard will open to help you create the backup job. You will have to specify a set of user credentials to use for the backup job in order to schedule it. The Schedule Jobs tab of the Backup utility is shown in Figure 3.4.


F I G U R E 3 . 4 : The Schedule Jobs tab lets you create backup jobs that will run at a later date and time.

Infrastructure

Planning for disaster recovery should always include plans for the infrastructure of your server room. Even if you don’t have a real server room, just a couple of servers stuck under someone’s desk, you still should think about the infrastructure support for these machines. Things like power, dust, and most of all, heat can affect server performance.

For any computer that you want to depend on, you should install some sort of power protection. The more important the computer, the more protection you should provide. An uninterruptible power supply (UPS) is a great idea. A UPS contains enough battery power to help the computer continue operating until either the main power is restored or the computer can be shut down safely.

If you do have a server room, then you’re probably aware that tem-perature is one of your main concerns. Computers generate a great deal of heat, and they don’t respond well to rises in temperature. In a


data center, one of the greatest concerns is how to apply air condi-tioning to prevent heat buildup. And as for dust, the big reason for eliminating dust is that it acts like a blanket inside the computer, caus-ing an ever-greater increase in temperature.

Restoring the pre-migration environment

This goes back to the idea of backups. Before you began your migra-tion, you should have taken one Windows NT BDC, synchronized it with the PDC, and taken it offline. Ideally, you also should have installed critical services such as DNS, WINS, and DHCP for backup purposes.

Make sure you have current backups of all critical data and any nec-essary services. While it may not make sense to back up a dynamically built WINS database, Microsoft recommends doing so. The same goes for all services.

If you do have a failure during the migration, and you need to com-pletely revert to the previous environment, bring the offline BDC back online, and promote it to PDC. Then reinstall additional BDCs into your NT domain as necessary. Figure out what went wrong, and start planning all over again. With luck, it was some-thing minor that will require only a little tweaking.

Rolling back the implementation to a specific point

Rolling back the migration to a specific point takes a bit more work than returning the network to an original state. The idea behind returning to a specific point is still the same: backups. Now, the dif-ference is backing up data and services at those specific points instead of just at the beginning.

Suggesting that you take the time to back up your new Windows 2000 server after installing every single service or migrating a few groups and users is ludicrous. However, if you want to be able to restore to any given point, that’s pretty much what it would take.

Try a slightly different plan. After the initial upgrade of the first domain controller, back up the server. Install any services you will want on the domain controller, and run another quick backup. Then


set up certain checkpoints for additional backups. If you are doing an incremental migration, you may want to back up the server after a certain number of users or groups have been migrated. This process will extend the time frame for the migration, but it gives you addi-tional flexibility for rolling back the network.

One major thing to keep in mind when doing these backups is: What is happening to the source? If during the course of migration the orig-inal objects (users, groups, data) are being destroyed, then backing them up becomes more critical. If you are simply cloning objects, or copying data, then these incremental backups may not be as crucial to your migration success.

Exam Essentials

Know how to restore your pre-migration environment. You should have a twofold plan in place for this need. First, perform all necessary backups of data and services. Second, synchronize a BDC with the PDC, and take the BDC offline. If the migration fails, this BDC is your backup plan.

Know how to roll back the implementation to a specific point.Unfortunately, this involves a lot of backups. Back up the new Windows 2000 domain controller at critical stages, and then you can use those backup tapes to restore to the specific point.


disk duplexing Fault-tolerant strategy similar to disk mirroring, except that the drives are on separate hard-drive controllers.

disk mirroring Fault-tolerant disk-storage scheme where one drive has an exact copy of another drive’s data. Both drives are on the same hard-drive controller. Also known as RAID 1.

disk striping Also known as RAID 0, striping is not fault tolerant, but is implemented for an increase in read and write speed.


disk striping with parity Striping with parity is like a stripe set, but it also stores parity information, which can be used to rebuild the set in case of a single drive failure. This is also known as RAID 5.

�Perform post-migration tasks.

Now that you are done with the migration, you need to make sure everything is working properly. Once you have verified function-ality, make sure to back up all critical data and services, just in case one fails.


The next area of your network where you need to test your deploy-ment plan is your user and group accounts. It is critical to be certain that they will be upgraded successfully because no migration is con-sidered successful if the process adversely affects the users.

Log on as a user, and attempt to access resources that they would need. It’s not advisable to log on as someone else’s account, so create a copy and use the copy for resource-access validation.

Once the migration has been completed, the best test of all is to mon-itor the user calls to the help desk. If the trouble tickets being cut indi-cate issues with the upgrade, you will need to take steps immediately to correct the problems.

Back up domains

Now that your migration is complete, it’s back to the regular grind of network administration. This includes, but is not limited to, backing up your domains.

When backing up your domains, consider domain controllers, critical data, and services. You just went through a lot of work to get the net-work to a better state. It would be a shame to see all of that work go to waste.


Verify functionality of network services

The most important services to consider after migration are DHCP, WINS, and DNS.

If network connectivity is a problem, you may want to re-check con-nections and cabling. If you did not change the physical backbone of your network, it’s less likely a cabling problem and more likely a net-work configuration problem. Check your protocol configuration. TCP/IP has a lot of options to configure, and they all need to be correct.

In the realm of DHCP, make sure all clients are getting proper IP addresses, subnet masks, and addresses for other things like the default gateway, WINS server, and DNS server. If not, check your scope. If the clients are not getting addresses at all, make sure the DHCP server is authorized in Active Directory.

WINS may or may not be necessary after your migration. If you are no longer running any downlevel client or server machines, then you don’t even need the service. If you are supporting an application that requires WINS, make sure users are still able to access the application.

The most important of these services to Windows 2000 is DNS. Clients need to access the DNS server in order to resolve computer names and find resources. If DNS was not properly installed, chances are Active Directory would not have installed either. Even if DNS was properly installed, there are a few issues to keep an eye out for.

If you are expecting names to be registered dynamically, make sure that DNS is configured properly and registration is taking place. Also check record-scavenging options, and verify that clients can ping servers (or each other) by their fully qualified domain name.

Cleaning Up

If your upgrade went well, there shouldn’t be much left to do after-wards. But there will be some additional tasks, such as reallocating hardware. You might have discovered in your planning that you will have too many domain controllers after the migration. These servers can be reused elsewhere in your network as file or applications servers.


After you have successfully completed the upgrade of a single domain, you may be finished, or you may be just beginning a longer migration plan. In the latter case, you will need to repeat this upgrade process in other domains and perhaps then restructure your domains into a more efficient Active Directory model. You can expect to spend a fair amount of time performing post-migration tasks.

If your upgrade was not successful, then you will need to trouble-shoot the individual issues. The resolutions will depend upon the issues encountered, but if you prepared for the migration by taking one or more BDCs offline, you could always recover the environment by bringing these servers back online and promoting them to primary domain controllers for their respective domain. You’ll know that the upgrade wasn’t successful if accounts are lost, users cannot log on to the domain, or there are reports of other similar catastrophic issues. Most often, the reported issues will be minor and easily resolved without rolling back the migration.

Exam Essentials

Know what to do after the migration. After the migration is com-plete, make sure users can access all required resources. Also test services such as DHCP, WINS, and DNS.


DHCP Service used to automatically assign a TCP/IP configuration to a client computer. The configuration consists of an IP address and a subnet mask, and can include the addresses of the default gateway, WINS server, and DNS server.

WINS Service used to convert a computer name (NetBIOS name) to an IP address.

DNS Service used to convert a host or friendly name to an IP address.

Chapter

4

Planning and Deploying an Intra-Forest Domain Restructure and an Inter-Forest Domain Restructure


�

Develop a domain restructure

strategy.

(pages 143 – 147)

�

Create or configure the Windows 2000 target

domain or domains.

(pages 147 – 167)�

Create appropriate trusts.�

Create organizational units (OUs).�

Implement a given site design.�

Implement group policies.�

Configure remote access functionality, networking protocols, DHCP, LAN Manager Replication, WINS, NetBIOS, Windows 2000 DNS Server service, and existing DNS service.

�

Select and configure tools, including ADMT,

ClonePrincipal, MoveTree, NETDOM, and the

Windows 2000 Resource Kit tools.

(pages 167 – 198)

�

Migrate global groups and user accounts.

(pages 198 – 208)

�

Migrate local groups and computer accounts.

(pages 208 – 212)

�

Perform test deployments of intra-forest

migrations and inter-forest migrations.

(pages 213 – 214)

�


(pages 214 – 224)�

Restore pre-migration environment.�

Roll back implementation to a specific point.

�


(pages 224 – 251)�

Redefine DACLs.�

Back up source domains.�

Decommission source domains and redeploy domain controllers.

�

Verify success of object migrations.�

Verify functionality of network services.�

Remove SIDHistory from objects.

C

ompleting domain restructures, whether it be intra-forest or inter-forest, is really no different than an upgrade in many ways. Planning is still the first critical step. After planning, you test. After testing comes the actual deployment. Finally, you get to clean up.

Even though the processes are similar, there are specific differences you will want to pay attention to. Different preparations need to happen. Other tools are used, and the order of actions taken may be slightly off.

This chapter examines domain restructures from many different angles. Developing strategies and configuring target domains are covered first, including reviews of topics such as trust relationships, OUs, sites, group policies, and network services. Tools for migrations are also covered in detail. These tools are critical for performing real world migrations, and are also tested quite extensively.

After learning about how to migrate users, groups, and computers, you’ll establish a recovery plan, perform the migration, and clean up afterwards. All in all, this is a large section, with critical information on specific procedures for migrations, and essentials for using the tools that Microsoft provides for performing migrations.

�

Develop a domain restructure strategy.

T

his objective includes examining some planning issues for Active Directory, and looking at how the restructure will affect your network. These topics will be important because there’s more to restructuring than just moving things around in Active Directory. You must carefully plan for the movement of network services or


144

your network may lose functionality. You also need to be aware of the potential security risks involved with a domain restructure.


There are two basic scenarios for restructuring domains. Thefirst involves migrating users from an NT environment to a new Windows 2000 structure. The second involves consolidating Win-dows 2000 domains into OUs. If you are using the first scenario, your network may be Windows NT 3.51 or 4, or it may have already been migrated to Windows 2000. Either situation will work. If the network is NT, this method will solve your migration needs as well as your restructuring needs.

It’s important to devise a procedure for restructuring because this will be some of the most common work done with Windows 2000 in existing networks. Many companies will purchase Windows 2000 just for this purpose, to condense or restructure their old domains into something more efficient.

As a rule of thumb, when migrating domains to Windows 2000, use the following steps:

1.

Perform preliminary tasks. (These specific tasks are covered in Chapter 3, “Planning and Deploying a Domain Upgrade.”)

2.

Perform a dry run of the migration.

3.

Migrate accounts domains.

4.

Migrate resource domains.

Migrating to a New Domain

When you decide to restructure your domains, you are choosing to move users, groups, and computers from an existing domain to a new Windows 2000 domain. A number of new configurations for the old

Chapter 4 �

Planning and Deploying Domain Restructures

145

network are possible, but here are some general guidelines for how to proceed with the restructure:

1.

Establish the trust relationships needed to maintain access to your network resources. You will need trusts from the target domain to any external accounts domains in order to preserve resource access for your network users during the restructure. You can use NETDOM to query the existing domains to determine their trusts. NETDOM is discussed later in this chapter.

2.

Clone shared local groups. These are the local groups created on the domain controllers for the old domain. Use ClonePrincipal to clone the local groups to ensure that resource access is maintained during the restructure. ClonePrincipal is also discussed later in this chapter.

3.

Demote old domain controllers to member servers. In this step, you would first upgrade the Primary Domain Controller (PDC) to Windows 2000 and then upgrade each Backup Domain Controller (BDC) that will be moved to the new domain. Leave the domain running in mixed mode for the time being. After you’ve upgraded the BDCs, demote them to member servers and move them to the new domain and/or OU. Essentially, this will leave you with a parallel domain running in mixed mode with only a single domain controller.

4.

Move member servers and client computers to the new domain or OU. During the transition, use NETDOM to create computer accounts for the computers in the destination domain.

5.

Decommission the old domain and reallocate the servers. By now, the only computer that should be left in the old domain would be the former PDC. You can demote this computer and move it to a new location in the new domain structure.

The above plan would accomplish a move from a resource domain to an Active Directory domain. Use the following strategy instead for moving accounts domains:

1.

Create a new Windows 2000 environment. This may be a single domain or a new forest. Either way, the new environment should


146

be completely new, not created by upgrading the existing domains. This will be your pristine domain.

2.

Establish the trust relationships needed to maintain access to your network resources. You will need trusts from the source domain to any resource domains to preserve resource access for your network users during the restructure. You can use NETDOM to query the existing domains to determine their trusts.

3.

Clone all global groups in the source domain. Since typical adminis-trative practice is to access resources through global groups that are added to local groups, make certain that these groups get moved to the target domain. The easiest way is to use ClonePrincipal to move the global groups to the new domain.

4.

Select and clone sets of users. In most cases, you will want to move users to the new domain in batches, so you must identify the sets of users you will move and use ClonePrincipal to copy them to the new domain.

5.

Decommission the source domain. When all of the accounts and resources have been moved to the new domain, you’ll need to demote all of the domain controllers and reassign them to new roles elsewhere in the network.

Exam Essentials

Know the proper procedure for moving users and global groups to a new domain.

Create your Windows 2000 environment, establish necessary trusts with NETDOM, clone global groups, clone users, and decommission the source domain.

Know the proper procedure for moving resources and local groups to a new domain.

Establish necessary trusts between the source and target domains, clone local groups that provide access to the resources, demote domain controllers or bring them offline, move mem-ber servers and workstations to the new domain, and decommission the original source domain.

Chapter 4 �


147


restructure

Taking multiple Windows NT or Windows 2000 domains and consolidating them into a more logical Windows 2000 domain structure.

�

Create or configure the Windows 2000 target domain or domains.

Y

ou’ve done the planning, and developed a proper restructure strategy. Now it’s time to either create or configure the Windows 2000 target domain.

To do this, you need to think about a variety of issues, such as establish-ing trust relationships to maintain current resource-access patterns for your users. Other items to consider are appropriate structures within the target domain to hold migrated objects, how the design of the new site will affect network traffic and resource access, and how to apply security policies. These are items you should plan for during the initial migration stages. This is also an area that can be heavily tested.


Target domains

are useful for migrations because they give you a chance to create a sensible domain structure. Essentially, a target domain is simply a place to move your security principals to when migrating or restructuring.

To create a target domain, you will need at least one computer to become a domain controller. When you decide to use a target domain, make certain you have planned your namespace and migration strategy carefully. Make sure you know what the namespace should be for the


148

target domain. You can either create a new root domain or add it to an existing forest.

It is a good idea to make sure that the first domain controller has lots of memory and processing power, as it will be handling all of the Operations Masters roles. Windows 2000 in native mode uses Multiple Master replication, but for some functions to work there must be a single authority. This functionality is provided by the Operations Masters roles. The Operations Masters are server roles that help an Active Directory network function. For example, the PDC Emulator (one of the roles) provides the services of a Primary Domain Controller to Windows NT domain controllers or appli-cations that require communication with an NT PDC. Placing all roles upon the first domain controller in the forest can be a bur-den, so if possible install a couple more domain controllers and distribute the roles among them.

NOTE

When creating the target domain, you want to create it to serve as the perfect new home for your users, groups, and resources.

This will be your “pristine environment,” as discussed in Chapter 2.

Migration is the perfect time to add additional servers to your network or to upgrade the type of servers being used. If this is your plan, then you will most likely have some extra servers to work with.

Creating a full target environment just involves creating multiple domains, though instead of creating a new forest or tree when installing Active Directory, you will be joining the existing target environment.

Creating appropriate trusts

With Windows 2000, trusts are changing slightly from what they were in Windows NT. Fortunately, Windows 2000 handles trusts within a forest automatically. For trusts between your existing net-work and the target domain, you will need to manually establish trust relationships with Windows 2000.

Chapter 4 �


149

If your existing network is using either a Single Master or Multiple Master Domain model, your users are most likely using resources located on servers in the resource domains. During your migration or restructure, you will need to ensure that the users still have this access. The solution is to create trust relationships from the existing resource domains to the new root domain (assuming that the user accounts will be moving to the root domain). If the accounts will be moving to a domain other than the root, create the trusts from the resource domains to that new domain (where the accounts will be located). Figure 4.1 describes this process.

F I G U R E 4 . 1 :

Establishing new trusts

To create trusts in Windows 2000, you have a couple of options. You can use the NETDOM utility from a command prompt, or you can use the Active Directory Domains and Trusts console. NETDOM and ADMT are explored more fully later in this chapter.

NOTE

When creating trusts between NT and Windows 2000, the NT domain must have a method of resolving the NetBIOS name of the tar-get domain. Use either an LMHosts file or a static entry in the Win-

dows Internet Naming Service (WINS) server’s database.

Target Domain

Sprockets.local

Resource1

Acct_Dom

Resource2


150

Creating organizational units (OUs)

Your target domain may already be used in the restructuring process. If this is the case, then you might be planning to collapse a large domain model into a single target domain with multiple organiza-tional units (OUs). OUs enable you to apply a logical structure within your target domain to receive users, groups, and computers.

As an example, the fictitious company Coolcompany Inc. is restruc-turing from a Master Domain model to a single Windows 2000 domain. The company wants to maintain the current administration units within the new network. To accomplish this, you have already established the target domain, which is the root and only domain in the coolcompany.local namespace, and now you need to create OUs to map the existing domains to. Figure 4.2 shows your plan.

F I G U R E 4 . 2 :

Planning to restructure into a single Windows 2000

domain

When you perform your restructure, you will be moving security principals from their existing locations to the appropriate OU in the target domain. Alternatively, you could simply move all of the secu-rity principals to the default containers in the target domain, and then after the move divide them into OUs.

Target DomainOriginal Domain

Accounting

ITITOU

AccountingOU

SalesOUSales

Chapter 4 �


151

NOTE

On the exam, OUs are a perfect alternative to having a multi-ple domain structure. There are few cases where multiple domains are better. They are: if the targets need completely autonomous control, if the targets have different regional (language, time) requirements, if parts of the company require different account policies, or if manage-

ment says they want it that way.

You can create single OUs off the root of your domain, or you can nest them within other OUs, whichever seems most appropriate for your network’s needs. You can create OUs only inside a valid con-tainer, which can be a domain or another OU. If you plan on nesting OUs, Microsoft recommends going no more than four layers deep. You will want to create your OUs off the root of the domain and not within the built-in containers.

As an illustration of these points, look again at the fictitious com-pany, Coolcompany Inc. For this example, say the company has three physical locations—Boston, Seattle, and Dallas—with a domain in each. Seattle is the headquarters, and Boston and Dallas are each semi-autonomous operations. Where the physical locations are roughly equal in importance, it might be unwise to pick one of them to be the root domain and the others to be child domains. With this in mind, create a single Windows 2000 domain and separate OUs for each of the physical locations.

Using this plan, you create a single domain, coolcompany.local, and create a Seattle OU to contain the Seattle accounts, a Boston OU for the Boston accounts, and a Dallas OU for the Dallas accounts. You could then use either ClonePrincipal or the Active Directory Migra-tion Tools to move the user accounts to the appropriate OU.

Implementing a given site design

For companies that operate across multiple physical locations with wide area network (WAN) links, it might be useful to create Active Directory sites to help optimize the traffic across those WAN links. In


152

Active Directory terms, a site is one or more well-connected TCP/IP subnets organized for security and replication topology. In this defini-tion, well-connected means fast and reliable connections.

NOTE

For the test, a dial-up modem link would

not

be considered

well-connected, but a T-1 would.

Sites are often used to assist in building a more efficient replication topology. Remember that all domain controllers must replicate with each other, and if the replication would have to go across WAN links, that could cause problems. Within sites, the replication will occur locally, and then you can schedule when replication will happen across the WAN link.

The transport protocols available for inter-site replication include remote procedure calls (RPCs) over TCP/IP and the Simple Mail Transfer Protocol

(SMTP). RPCs over TCP/IP enable fast, synchronous replication, while SMTP provides asynchronous replication that is often more efficient across slow or unreliable connections. Replication links can be scheduled, and the interval at which replication occurs between sites can be configured. But in order to use SMTP for the replication transport, you must have certificates enabled. SMTP is an inherently unsecure protocol.

NOTE

On the exam, Microsoft typically refers to RPCs over TCP/IP

as simply “IP replication.”

Active Directory enables you to assign specific IP subnets to your sites. If you do this, any new computers installed in Active Directory will automatically become members of a site based on their IP address. For example, if SiteA has the assigned subnet of 10.5.0.0/16, and you create a new server with the IP address of 10.5.0.36, that server will automatically be made a member of SiteA.

Chapter 4 �


153

NOTE

Windows 2000 uses a different format for describing IP addresses. Instead of the IP address and the explicit subnet mask, you will now see the IP address followed by the number of bits to be used for the mask. For example, instead of writing 10.1.0.0 with a mask of 255.255.0.0, you would write this subnet address as 10.1.0.0/16. This is a format used by most Unix systems, including Linux, and it marks Microsoft’s effort to become more standardized

in its IP networking.

Going back to the earlier example of coolcompany.local and the three locations in Seattle, Boston, and Dallas, you could take the solution a little further by creating sites for each of the physical locations. You could then assign the IP subnets for the sites so that any com-puters installed will automatically be assigned to the correct site based on the IP address they are configured with. The user accounts are organized into OUs and are still available at any one of the sites.

Implementing group policies

If your NT network has been using System Policy and logon scripts for assigning security to your users, you will need to maintain this functionality during and after the migration to Windows 2000. This includes creating the same effect in your target domain. To maintain your network security during a migration or restructure, you will need to properly assign Group Policies to the target domain or OUs.

Group Policy is assigned through the use of a Group Policy object (GPO), which contains all of the policy settings that you define. The GPO is then linked to a container. GPOs can be used for dis-tributing software and assigning user rights, and they take the place of the System Policy from NT. Group Policy is an improve-ment over System Policy in that System Policy could be difficult (or impossible) to undo when you wanted to change the settings. Group Policy can be easily assigned, changed, or even removed from the Registry. In Windows 2000, when you remove or change an existing


154

policy, the settings are actually removed from the Registry correctly, as opposed to the method that NT used. NT was notorious for leaving System Policy settings in the Registry after they had been removed.

Configuring network services

When using a target domain, you need to maintain users’ access abilities during the migration and/or restructure. To accomplish this, you must configure some of your network services to provide access for users who are being transitioned from their old domain to the target environment.

The network services affected by a migration or restructure will vary from network to network, but these sections cover the principal issues that will be covered on the exam.

Configuring RAS

In Windows NT, the only permissions you could set on the Remote Access Service (RAS) were to grant or deny dial-up permission through User Manager for Domains or the RAS Administration Tool. Windows 2000 has this ability but also adds Remote Access Policies for additional security control. RAS gives you the ability to provide dial-up service to your remote clients and provides only basic security. RAS depends on the operating system to provide secu-rity. That’s where the Remote Access Policies come in. Windows 2000 provides sophisticated security for RAS through the use of Remote Access Policies, which can define a person’s ability to access the RAS server and the network beyond. RAS policies are available only when the domain is running in native mode.

Both the Routing and Remote Access Service (RRAS) and the Internet Authentication Service use Remote Access Policies to determine whether they should accept connection attempts. Remote Access Pol-icies are used to authenticate connections on a per-call basis. In order for a user to be granted dial-up access to a Windows 2000 Server, they must first have the dial-up permission granted in their user account, and then they must meet at least one of the Remote Access Policies defined for that RRAS server. If these conditions are met, the user will be granted access.

Chapter 4 � Planning and Deploying Domain Restructures 155

NOTE Windows NT gave users dial-in permissions once their ac-count was granted access. Windows 2000 provides an additional step as an increased security measure.

Remote Access Policies are always stored locally on the RRAS server and not elsewhere in the domain or in Active Directory.

Remote Access Policies can be set to control individual user access through RRAS, control the time of day that they can log on, and even set the amount of time that they can be connected. During the migra-tion or restructure, the most important aspect of RAS is to continue to provide the same level of access that users currently have.

Configuring Protocols

If you are going to use Windows 2000 Active Directory, you need to install and configure TCP/IP, as all of the services supporting Active Directory require TCP/IP to communicate. Of course, you can still use other protocols on your servers and client computers if you wish, but the servers will require TCP/IP for Active Directory.

When configuring TCP/IP, consider things like subnetting, rout-ing, and Internet access. Windows 2000 also provides new TCP/IP networking features such as Internet Protocol Security (IPSec). Become familiar with the new technologies.

Configuring DHCP

The Dynamic Host Configuration Protocol (DHCP) is an impor-tant part of your network services in most networks. DHCP can be implemented on an NT Server, a Windows 2000 Server, other oper-ating system servers such as Linux or Unix, or even a router. When implementing a DHCP server, choose one that supports the Dynamic DNS Update functions.

The Domain Name System (DNS) resolves Internet host and domain names to IP addresses. Windows 2000 uses DNS almost exclusively for name resolution. DHCP plays a part in supporting the Dynamic DNS service found on Windows 2000 by reporting the inverse lookup


(PTR) record for a client computer to the DNS server when the client obtains its address lease. The client will then notify the DNS server (if the client understands Dynamic DNS Update) of its forward lookup information. If the client operating system doesn’t support Dynamic DNS Update, then the DHCP server should be configured to inform the DNS server of both the forward and reverse lookup information.

The other major consideration for Microsoft DHCP servers is that they must be authorized in Active Directory before they can issue any client address leases. Windows 2000 uses the DHCP INFORM packet to query DHCP servers for information. If the server is not listed in Active Directory, the local Windows 2000 Server will tell that DHCP service to stop. What this means is that if you fail to authorize your DHCP servers, no one will get addresses from it.

Configuring Directory Replication

Windows 2000 does not support the Directory Replication Service in NT, also known as LAN Manager replication (LMRepl). Win-dows 2000 uses a service called the File Replication Service (FRS) to accomplish all replication.

Every Windows 2000 domain controller has a folder called Sysvol, for System Volume. Sysvol contains replicated information that is shared among all domain controllers. Unlike NT’s LMRepl, in which any NT computer could act as an import computer, only domain con-trollers can participate in FRS. Because the two services are incom-patible, you will need to plan a way to support both during the move to the target environment.

Your target domain is most likely going to be a native-mode Win-dows 2000 environment, and if so you will be using the FRS exclu-sively. In this case, you need to use the appropriate scripts to con-vert your logon scripts from NT to Windows 2000 capabilities through the use of Group Policy. But if your replication is being used to move data files from one location to another, or if you need to maintain a mixed environment of Windows 2000 and NT computers participating in replication, then you need to form a replication bridge.


To assist with this process, Microsoft recommends that you create a batch file called L-bridge.cmd to copy the contents of one folder to another, and that you schedule the file to run at regular intervals. First of all, determine which NT server is the export server and which Win-dows 2000 domain controller will push files to that server. You would then run xcopy.exe from a batch file to carry out the replication.

NOTE As an alternative to Xcopy, Microsoft has provided a utility called ROBOCOPY. ROBOCOPY’s biggest asset is its ability to syn-chronize folders automatically.

Microsoft recommends that you disable the Directory Replication Service prior to upgrading a server to Windows 2000, so that there won’t be any legacy services once the upgrade is complete.

Configuring WINS and NetBIOS

NetBIOS isn’t needed for a pure Windows 2000 environment, though you should carefully check to see if you are using any net-work applications that require the presence of NetBIOS. Also be aware that if you wish to restrict users to specific workstations, you will be required to keep the NetBIOS service.

The Windows Internet Naming Service (WINS) provides a method of NetBIOS-name-to-IP-address resolution for client computers that have been dynamically addressed through DHCP. WINS also helps clients to browse a multiple-segment network by storing browse information for different domains. These services are most likely in use on your current NT network, especially if you have Windows 9x clients. WINS also serves one more purpose that Dynamic DNS doesn’t—WINS prevents duplicate computer names on the network. DDNS doesn’t care if two computers with the same name are on the same network.

When configuring your target environment, you should still be using NetBIOS and WINS to support client computers and users who are being moved to the new domain. WINS in particular will assist


network clients to access existing resources in NT domains, since NT networks use NetBIOS names to communicate with each other.

When everyone has been migrated to the target environment, and all services and applications are running fine, you can consider disabling NetBIOS and WINS in your network. There is also another possibil-ity for reducing the use of NetBIOS over your Windows 2000 net-work: The DHCP server in Windows 2000 provides the advanced option to disable NetBIOS services for all Windows 2000 computers that receive an IP address from that DHCP server. You would find this option under the properties for the Server Options in the DHCP console.

Configuring DNS

There are definite benefits to using the DNS server in Windows 2000, but there is absolutely nothing wrong with using a third-party DNS server. Keep in mind that Active Directory really wants to have the dynamic update capability in DNS and requires support for the new Service (SRV) record type for services.

The latest versions of BIND (versions 8.1.2 and higher) are capable of supporting dynamic updates and the SRV record type. This means that you can successfully integrate Unix computers running BIND into your Windows 2000 environment.

NOTE For test purposes, BIND version 8.1.2 is sufficient to support a Windows 2000 domain. However, you should strongly consider using the most current BIND version available.

The only difficulty typically encountered with this plan is supporting the special sub-domains that Windows 2000 uses for Active Directory. The problem arises from the use of the underscore (_) character in the name of the sub-domain. The sub-domains are named as follows:

_msdcs Contains information to assist Active Directory servers in locating other domain controllers.


_sites Contains sub-domains for each site in Active Directory.

_tcp Maintains SRV records for TCP-specific services.

_udp Contains SRV records for UDP-specific services.

Together these sub-domains support the DNS functions of Active Directory and are crucial to its successful operation. The Internet Software Consortium (ISC) recommends that these sub-domains that are required by Active Directory be created as separate zones and that the default name-checking value be set to ignore the name of the zone. To accomplish this, you can place code similar to the following in your /etc/named.conf file:

zone "_msdcs.sprockets.local" { type master; file "_msdcs.sprockets.db"; check-names ignore; allow-update { localnets; }; };

This code identifies the name of the new zone as _msdcs.sprockets.local and that it is a master (primary) zone. The file statement iden-tifies the actual file containing the zone information as _msdcs.sprockets.db. check-names ignore turns off the default name-checking behavior for this zone, and allow-update tells the server to accept dynamic updates for this zone. For more information, consult ISC’s Web site at www.isc.org/products/BIND/.

To migrate your third-party DNS servers to Windows 2000 DNS servers, install Windows 2000 and configure the DNS server service with a secondary zone. Once the zone has been transferred, you can reconfigure the secondary zone as a primary zone and redistribute DNS replication as needed.

MICROSOFT DNS

Microsoft prefers that you use Windows 2000’s DNS service to support Active Directory. It supports all necessary features, including dynamic updates, SRV record types, and underscore characters. It also supports incremental zone transfers, which reduces network traffic.


When implementing Microsoft’s DNS service for Windows 2000, your biggest decisions are typically what options to choose. Those options include dynamic updates, zone transfer replication partners, and record scavenging.

You cannot use Windows NT 4’s version of DNS to support Active Directory. It can be a server participating in the zone, but it cannot be the authoritative server. If you want to keep your existing Win-dows NT DNS server, install a Windows 2000 DNS server as the primary server and configure the NT server as a secondary server to your Windows 2000 primary server.


There are seven necessary procedures for this objective. Every one of them differs in function, but all relate to different aspects of the proper creation of your new Windows 2000 environment.

Creating a Target Domain

To have a domain that is considered a target, you must install Win-dows 2000 Server and configure a domain as appropriate. Once the first critical step of creating a domain is complete, you can begin to customize the domain to your liking, or to meet your company’s needs. To create a target domain, use the following procedure:

1. Install Windows 2000 Server on a suitable computer.

2. Use the Active Directory Wizard to install Active Directory and make the server the first domain controller in a new domain. Your migration plan will determine whether this domain is a new forest, new tree, or new domain in an existing forest.

3. Switch the target domain to native mode.

4. Install additional servers if possible.

5. Create an appropriate Active Directory structure within the target domain. If you will need more than one target domain to establish


your new network (such as when restructuring), you may need to duplicate these steps to create the full target environment.

6. Install the WINS in the target domain to assist computers in resolving NetBIOS names during the migration.

7. Establish trust relationships between the new domain and the existing resource domains so that as client computers are migrated to the target domain, they will continue to have proper resource access.

8. Reestablish your System Policies using GPOs to maintain security after the move.

Creating a Trust Using the Active Directory Domains

and Trusts Console

After your target domain is created, you will need to create trust relationships with the source domain to ensure that all users have access to resources during the migration. When creating trusts, always start from the domain that will be the trusted domain. Use the following steps to create trust relationships:

1. Open the Active Directory Domains and Trusts console by clicking Start � Run and typing mmc /a. Click the Console menu and use the Add/Remove Snap-in command to add Active Directory Domains and Trusts.

2. Expand the console tree for Active Directory Domains and Trusts to display the domains in your Active Directory structure.

3. Right-click the target domain and select Properties from the con-text menu.

4. Click the Trusts tab.

5. Click the Add button beside the Domains That Trust This Domain list, and type in the domain name of the resource domain. You can also specify a password for additional security.

6. Click OK to apply this change. You can add more than one trust at a time using the same steps.


7. In the NT resource domain, open User Manager for Domains and click the Policies menu.

8. Click Trust Relationships.

9. Click the Add button beside Trusted Domains and type in the name of the target domain. If you provided a password in step 5, enter it again. Click OK to complete the trust.

Creating an Organizational Unit in a Target Domain

OUs give you flexibility of network design within a domain. They are a wonderful alternative to creating multiple domains, and to the management issues associated with those multiple domains. Remember to create no more than four levels of OU hierarchy for the sake of management.

1. Open Active Directory Users and Computers by clicking Start � Programs � Administrative Tools � Active Directory Users And Computers.

2. Expand the console tree for your target domain.

3. Right-click your target domain and select New � Organizational Unit from the context menu.

4. Type in the name of the new OU, and click OK to save it and return to the Active Directory Users and Computers console.

5. Repeat as necessary.

Creating a Site

Sites are useful for controlling replication between poorly connected physical locations within a Windows 2000 network. Generally, sites should be created for locations that have slow WAN connections. Sites can be associated with subnets. To create a site, use the following procedure:

1. Open Active Directory Sites and Services by clicking Start � Programs � Administrative Tools � Active Directory Sites And Services.


2. Expand the console tree to display the Sites container. Right-click the Sites container and select New Site from the context menu.

3. Type in the name of the new site, and click OK to apply the new site.

Implementing Group Policies

Group Policies are very versatile, and can enhance network security and functionality while lowering administrative burden. To create a Group Policy, use the following procedure:

1. Open Active Directory Users and Computers by clicking Start � Programs � Administrative Tools � Active Directory Users And Computers.

2. Right-click the container for which you want to create a GPO. This can be a domain, a site, or an OU. Select Properties from the context menu.

3. Click the Group Policy tab.

4. Click the New button to create a new GPO. Type in the name for the new GPO and press Enter.

5. Highlight the new GPO and click the Edit button. This will open a new Group Policy console.

6. To edit the computer security policies, expand Computer Config-uration � Windows Settings � Security Settings � Local Policies � Security Options.

7. Double-click a security option in the right pane to open the Security Policy Setting dialog, and place a check mark in the Define This Policy Setting check box. Click the Enabled radio button, and then click OK to return to the Group Policy console.

8. Double-click another setting to open the Security Policy Setting dialog for this setting. Check the Define This Policy Setting check box, and enter any additional data if it is appropriate. Click OK when you are satisfied with the message.


9. Close the Group Policy console to return to the Group Policy tab of the container Properties dialog. Highlight the new GPO and click the Add button.

10. Click the Links tab. Use the drop-down list box to display the name of the target domain, and then click Find Now. This will display the list of containers to which you can link this GPO.

11. Highlight the container that you want to link this GPO to, and then click OK.

12. Click Close on the container’s Properties dialog.

Creating or Modifying Remote Access Policies

Windows 2000 allows administrators to set additional Remote Access permissions through the use of Remote Access Policies. This is a huge advantage over Windows NT, which had a very limited dial-in permission structure.

1. Open Routing and Remote Access by clicking Start � Programs � Administrative Tools � Routing And Remote Access.

2. If this is the first time you’ve opened this console, you will need to activate RRAS. To do this, right-click your server name in the left pane of Routing and Remote Access, and select Configure And Enable Routing And Remote Access. If a domain controller is present on the network, RRAS will attempt to register itself in the Active Directory.

3. Click Remote Access Policies to view the currently installed policies. By default, there is only one policy defined, and that is Allow Access If Dial-in Permission Is Enabled.

4. Double-click the policy to open the Settings dialog for this pol-icy. Notice that the default schedule is to allow 24×7 access, but that the default action is to deny access. This configuration means that even if your account has been granted dial-in permis-sion, you will be denied access by default.

5. For the purpose of your target domain, you will most likely want to change the radio button to Grant Remote Access Permission if


you still want to control RAS access through the account permis-sions as users are moved to the target environment.

Configuring DHCP to Support Dynamic DNS

Updates

The first step in implementing DHCP is to authorize it in Active Directory. Once DHCP is authorized, you have many options, includ-ing supporting Dynamic DNS Updates for clients that cannot update the DNS server themselves.

1. Open the DHCP console by clicking Start � Programs � Admin-istrative Tools � DHCP.

2. Right-click the entry for your DHCP server name in the right pane, and select Properties from the context menu.

3. Click the DNS tab.

4. The default setting of Automatically Update DHCP Client Infor-mation In DNS should be checked. Click the second radio button under it to Always Update DNS.

5. Place a check in the box for Enable Updates For DNS Clients That Do Not Support Dynamic Update. This will cause the DHCP server to provide all dynamic information to the DNS server for every client that gets an address from it.

6. Click the OK button to apply the changes and exit the Properties dialog.

Exam Essentials

Know what trust relationships need to be in place for domain restruc-tures. When performing a domain restructure, it’s best to make sure that the source and target domains have a two-way trust between them. If the domains are already part of the same tree or forest, the trusts are automatically created.

Understand implications of various site designs. If you have remote physical locations, sites are a must for controlling replication.


However, to ensure that replication occurs properly, you must create site links or site link bridges.

Understand Group Policies. Group Policies are essential to Win-dows 2000 security and configuration. They can do a variety of tasks, including restricting users’ desktops, limiting computer functionality, and automatically installing software.

Know how to configure the critical network services. Being able to configure protocols, DHCP, WINS, RAS, and DNS is essential to proper network operations. DHCP needs to be authorized in Active Directory, WINS is only necessary for downlevel clients or applica-tions, and DNS is critical for proper operation of Active Directory.


FRS File Replication System is used by Windows 2000 to carry out replication of the Sysvol directory.

Group Policy objects GPOs hold Group Policy information, and ensure that Group Policies are applied to the proper users, groups, and computers.

linked GPOs must be linked to a site, domain, or OU to affect that particular container.

Operations Masters Critical domain-wide or forest-wide roles served by domain controllers. Also known as Flexible Single Master Operations (FSMO) roles.

PDC Emulator Master An Operations Master role that acts as a Windows NT Primary Domain Controller for computers or applica-tions that require the services of a PDC.

Remote Procedure Call (RPC) Protocol used for intra-site replica-tion between domain controllers.

Simple Mail Transfer Protocol (SMTP) Unsecure networking protocol originally designed for e-mail transport, used in inter-site domain replication.


site Logical division within Active Directory that represents a remote physical location of your network. Typically associated with a subnet.

source domain During restructuring, the original domain that provides the users, computers, or other resources.

target domain During domain restructures, the destination domain.

Wide Area Network (WAN) Network that is composed of multiple physical locations that are not well connected. Typically, anything less than T-1 speed (1.544 Mbps) is not considered well connected.

�Select and configure tools, including ADMT, ClonePrincipal, MoveTree, NETDOM, and the Windows 2000 Resource Kit tools.

Planning is probably the most integral part to a successful network migration or restructure. However, all the theoretical knowledge and plans in the world won’t do any good if you don’t know how to accom-plish what you are setting out to do.

The migration tools play a vital part in your migration and even in restructuring your network. You will need to be very familiar with them before using them in a production environment—and to pass the exam.


Microsoft has provided some tools with the Windows 2000 CD-ROM, and more are available on Microsoft’s Web site for free download. Even though there will likely be many more tools available from third-party software vendors over the coming months, concentrate only on Microsoft tools for the test.


Each tool Microsoft provides has specific features, and functions bet-ter in some situations rather than others. The ones to be aware of are the Active Directory Migration Tool (ADMT), ClonePrincipal, MoveTree, and NETDOM.

In an effort to get better acquainted with the tools, you need to review their specifications one by one, and discuss how to use them alone as well as in different settings. Troubleshooting the tools will be covered in Chapter 5, “Troubleshooting.”

While reviewing the following sections, it’s important to pay attention not only to how to configure these tools but also to all of their components. It’s critical that you know the tools themselves as well as how to configure them.

Active Directory Migration Tool (ADMT)

ADMT is a Microsoft Management Console (MMC) composed of several wizards to help you migrate information from an NT 4 or earlier domain to your Windows 2000 Active Directory domain. This tool can be a great help in a complex move, but it has some difficulties of its own. The online help for ADMT is fairly complete.

The ADMT wizards perform most of the work associated with the actual migration from your source domain to the new Windows 2000 environment. The wizards include the following:

User Migration Wizard This wizard migrates user accounts from the source domain to the target domain. It can move a single account or a large number of accounts at once. The User Migration Wizard includes options to rename accounts for easy identification after the migration or to assist with preventing name conflicts.

Group Migration Wizard As the name implies, this wizard migrates groups from the source domain to the target domain. Note that it will not migrate the built-in group accounts, since this would cause a secu-rity identifier (SID) conflict. Built-in accounts have the same SID on all domains, so the ADMT wizards will ignore these accounts.

Computer Migration Wizard This wizard moves the existing NT computer accounts from the source domain to the target domain.


Security Translation Wizard This wizard translates the existing security policies for the source domain into the format used by Windows 2000 and migrates them to the target domain.

Reporting Wizard The Reporting Wizard includes several options for creating reports that aid in planning the real migration. Options include reports on potential name conflicts, expired com-puter accounts, and accounts that can be safely migrated.

Service Account Migration Wizard This wizard migrates any accounts used for services. An example of this would be the user account that SQL Server uses to communicate with other SQL Servers for replication.

Exchange Directory Migration Wizard This wizard aids in bringing accounts from Exchange Server into Active Directory. The Exchange Directory can be used to populate your Active Directory if you so desire, though this may not be the best way to fill your Directory since the Exchange Directory won’t have the same properties for the accounts.

Undo Wizard Like an eraser for a migration, the Undo Wizard will attempt to undo a migration action. If it can, it will move accounts back to the source domain.

Retry Tasks Wizard This wizard will attempt to complete the tasks that were cancelled. If this doesn’t work, you will want to try the Undo Wizard.

Trust Migration Wizard This wizard migrates existing trusts to the target domain. This is really useful when migrating an NT 4 domain to a Windows 2000 target domain. When complete, the target domain will have the same trust relationships that the source domain had, thereby preventing any failed permissions issues across the trusts.

Group Mapping and Migration Wizard This wizard helps you prepare your existing group accounts in the source domain for the migration to the target domain. It helps prevent name conflicts by merging two groups with the same name.

The first step in preparing to use ADMT is to create a target domain structure, where all of your existing domains will be migrated. Be sure to pick computers that have enough hardware resources to handle the


load of being the first domain controllers in the target domain. Remember that the first domain controller in a domain will have all five of the FSMO roles by default.

You can read more about ADMT at

www.microsoft.com/WINDOWS2000/guide/server/solutions/admt.asp

Installing ADMT

ADMT is not included with the Windows 2000 product. Instead, you will need to download it from Microsoft’s Web site at

www.microsoft.com/windows2000/downloads/deployment/admt/default.asp

ADMT must be installed on a domain controller in the target domain. You must ensure that the domain controller has at least the following minimum hardware requirements to run ADMT:

� Pentium II or later CPU

� Adequate memory for the migration process: minimum of 10MB of available RAM for the process and 4KB per user to be migrated

� At least 35MB of free disk space for the tool itself (around 7MB) and for the data and log files

To install the ADMT software on your target domain controller, execute the self-extracting file ADMT.exe and answer the prompts. About the only real decision you will be asked to make is the folder location to install to. This Setup Wizard is really very simple. Most of the time, accepting the defaults will be sufficient.

ADMT works by transmitting an Agent to the old domain controller. The Agent is initiated by your logged-on user credentials (which must have administrator rights on the local and source domains), and then it is sent to the source domain. The Agent will run there as a system process, then write data back to the target domain. The ADMT Agent can run on the following operating systems:

� Windows NT 3.51 with Service Pack 5 (Intel and Alpha platforms)


� Windows NT 4 with Service Pack 4 or higher (Intel and Alpha platforms)

� Windows 2000

You need to establish a two-way trust between the source and target domains and then add yourself to the built-in local administrators group on both domains. That way, when you log on to the computer where you will be running ADMT in the target domain, your account will also have administrative permissions on the source domain. Since the migration process will be run using your user credentials on both domains, your account needs administrative rights on both domains.

Configuring ADMT

Most of the configuration of ADMT falls into the category of prepa-ration. Before attempting any kind of migration, be sure to synchronize the system clocks on all domain controllers.

NOTE Again, remember that you need to establish a two-way trust between the source and target domains. Also, add the Domain Admins global groups from each domain to each other’s local Administrators group to ensure that you have administrative rights on both domains.

Another interesting pre-migration step for ADMT is to empty the Recycle Bin for all user accounts that are to be migrated before per-forming the migration. This will prevent the accounts from generat-ing an error that the Recycle Bin is corrupted. The error is generally considered harmless, in that you can simply delete the contents of the Recycle Bin and everything will be fine. But to avoid the errors, empty the Recycle Bin prior to performing the migration.

To use ADMT successfully, the following items must be configured:

The target domain must be in native mode. ADMT requires the use of the SIDHistory feature to correctly migrate security principals from the source domain to the target environment. SIDHistory is available only in native mode.


The source domain must either be an NT 4 domain or be in the same forest. The source domain can be either an NT 4 or Windows 2000 environment. If it is Windows 2000, it can be in either native or mixed mode, but it must be in the same forest as the target domain.

A new local group should be created in the source domain.ADMT will create a group called SourceDomainName$$$ in the source domain if it can, but Microsoft recommends that you create the group manually. The name is the name of the source domain plus the three dollar signs ($$$), so if the source domain is Boston, the local group name would be Boston$$$.

Disconnect any active sessions. There must not be any current drive mappings, browse lists, or anything else that will generate a network session between the source and target domain controllers. If there is a current session, ADMT may fail with a credentials conflict.

Edit the Registry on the source PDC. The PDC or PDC Emulator should have an entry added to the Registry to enable the Local Security Authority (LSA) to use TCP/IP. The setting is HKLM\System\CurrentControlSet\Control\LSA. The value name is TcpipClient-Support, the type is REG_DWORD, and the data is a hexadecimal 0x1.

Enable auditing on the source and target domains. You should enable auditing for the success and failure of user and group manage-ment on the source domain. Also enable auditing for the success and failure of audit account management on the target domain in the Default Domain Controllers policy.

These settings will handle most of the issues that may arise while using ADMT. You need to keep a few other items in mind for secu-rity. For example, you must have administrator rights in the source domain in order to migrate the security principals. Adding the Domain Admins group to each local Administrators group would be tedious at best. However, if resources on member servers need to be migrated, you need administrative privileges on those machines as well.


If you are using ADMT to perform an intra-forest migration, there are some additional considerations. When performing an intra-forest migra-tion, ADMT must be in communication with the Relative Identifier (RID) Master.

Because ADMT must communicate heavily with the RID Master during a migration to create new SIDs for all of the security principals, it is best to install ADMT on the RID Master. This enables ADMT and the RID Master to communicate without involving network traffic.

Using ADMT

The first time you open ADMT from the Administrative Tools group, the console is pretty empty. The only entry under the console root is Reports. The Reports branch of the console tree will be populated as you run the various report utilities and migration wizards that make up ADMT. When you click Reports, you will receive some useful information, as shown in Figure 4.3.

F I G U R E 4 . 3 : The Reports tree is unpopulated by default but gives you information to get started.


The Reporting Wizard generates reports that detail the tasks necessary to complete your migration to the target domain. To run the wizard, right-click the Active Directory Migration Tool icon in the left pane of the Migrator console and select Reporting Wizard from the context menu. The second page of the wizard asks you to define the source and target domains, as shown in Figure 4.4.

F I G U R E 4 . 4 : The Reporting Wizard prompts you for the source and target domains.

If everything is configured correctly, ADMT will be able to open information from both the source and the target domains. This is the point at which an error will be generated if there is no trust between the domains or if the account you are using doesn’t have administrative permissions in both domains. You will also receive an error if the target domain isn’t in native mode. Assuming that everything is configured correctly, you will be prompted for the location to store the report information, as shown in Figure 4.5.


F I G U R E 4 . 5 : ADMT prompts for a location to store the reports.

The next page presents you with a list of the possible reports the wizard can generate for you, as shown in Figure 4.6. You will need to pick the report(s) you want from the list before proceeding with the next step. The first time you run the wizard, none of the reports have ever been run, and the status under Date/Time Last Created is Not Created. Select all of the reports, and then click Next.


F I G U R E 4 . 6 : The Reporting Wizard gives you a list of possible reports.

The Reporting Wizard then requests your account information for the source domain. You will be prompted to supply a username, a password, and the source domain name, as shown in Figure 4.7. The account you use must have local administrator rights, which should be taken care of by the trust you created in preparation for using ADMT. If you did not remember to add your global Domain Admins group from the target domain to the local Administrators group on the source domain, you’ll want to do that right away.


F I G U R E 4 . 7 : Provide user credentials for the source domain.

After your credentials have been verified on the source domain, the Reporting Wizard asks you to identify the computers that have the security principals you wish to move. Typically, you will pick the Primary Domain Controller of the source domain when you reach this page in the wizard, shown in Figure 4.8. Highlight the server that contains the accounts you want to move and click Next.


F I G U R E 4 . 8 : Select the computer that contains the security principals you want to move.

After you have completed these steps, the Reporting Wizard summarizes your choices on the final page of the wizard, shown in Figure 4.9. Once you click Finish on this summary page, the Reporting Wiz-ard will run the reports you specified and return the information to the Migrator console window.


F I G U R E 4 . 9 : The Reporting Wizard summarizes your choices on the last page.

While the Reporting Wizard is running, you will be able to view the current status in the Active Directory Migration Tool Agent Monitor, shown in Figure 4.10. Most of the other utilities in ADMT will operate in a similar fashion. If the Reporting Wizard can run successfully, then you know that your configuration is correct. ADMT will prompt you with surprisingly helpful error messages, often telling you specifically how to fix the error condition.


F I G U R E 4 . 1 0 : The ADMT Agent Monitor provides current status messages during reporting.

The Reporting Wizard is the best place to start in ADMT, as it will provide helpful information about the accounts that are going to be migrated. It also helps you to iron out any bugs you may have in your configuration. Once you have proven that the configuration is solid, you can move on to the other utilities in ADMT. The next step will depend on the type of migration you are performing. Some migration types will require more steps than others—and perhaps even a different order of events.

USING ADMT IN AN INTER-FOREST RESOURCE DOMAIN MIGRATION

When performing an inter-forest resource domain migration, you will want to follow this course of action:

1. Use the Trust Migration Wizard to help you to identify and re-create trusts between resource domains and the target domain. The wizard first identifies all of the existing trusts between a given resource domain and its accounts domains,


then gives you the option of creating parallel trusts from the resource domain to the target account domain.

2. Use the Service Account Migration Wizard to identify service accounts used on specific computers in the source resource domain. You will be asked to specify the computers that are using service accounts, and then the wizard will examine those servers for all service accounts. These accounts will then be included when you later migrate user accounts.

3. Use the Computer Migration Wizard. Resource domains frequently hold the computer accounts for user workstations and application servers. The Computer Migration Wizard will migrate the local com-puter information and account for each of the workstations and member servers in the resource domain. ADMT dispatches an Agent to each of the computers to be migrated. At the completion of the Agent’s duties, it will force the computer to shut down and restart.

4. Use the Security Translation Wizard to translate the local user profiles on the computers that have been migrated to the target domain, from the original SID of the user to the new SID of the user in the target domain. On the Translate Objects page of the wizard, select User Pro-files as the object to translate.

5. Use the Group Migration Wizard at this point to migrate shared local groups from the resource domain to the target domain. On the Group Options page, make sure you select Migrate Group SIDs To Target Domain and also Do Not Rename Accounts.

6. Use the User Migration Wizard to migrate service accounts to the target domain. Be aware that while the service accounts themselves will be migrated, some applications must be modified to use the new accounts in the target domain. Exchange Server 5.5 is a good example of this. ADMT cannot change the service account set-tings within Exchange, so you must change the service account manually in the Exchange Administrator console.

7. Use the Security Translation Wizard to update the service account user rights. Be sure to select the domain in which the service account resides and not the domain of the computer on which the service account is being used (if they are different). On the Translate Objects


page of the wizard, select Local Groups and User Rights as the options to translate.

After these steps have been completed, you are ready to upgrade the domain controllers to Windows 2000 (if they aren’t already running Windows 2000) and move them into the target domain. ADMT cannot migrate the domain controllers for you using the Computer Migration Wizard as it can the member servers and workstations, but you can use all of the other ADMT tools on them.

Once the domain controllers have been migrated, you can successfully decommission the old resource domains.

USING ADMT IN AN INTER-FOREST ACCOUNT DOMAIN MIGRATION

In these scenarios, you will be moving resources from an existing account domain to a new target account domain. Here are some general tips to use when performing this type of migration:

1. Create the Windows 2000 target domain.

2. Use the Trust Migration Wizard to establish proper trust relation-ships between the source account domain and the target domain. You can also use NETDOM for this task.

3. Use the Group Migration Wizard to migrate the domain global groups from the source domain to the target account domain. If the global group you are migrating contains a large number of users, it can take quite a while to process all of the members. This will also cause a heavy impact on your network traffic. Consider using the option to migrate the user accounts with the group instead.

4. Use the User Migration Wizard to move the accounts incrementally, using a pilot group first. This enables you to test your migration plan-ning while affecting only a small group of users at one time. If a large number of user accounts are in the source domain, it will take quite a while to build the list of user accounts to migrate, which will cause a heavy impact on network performance.


After these steps have been successfully completed, you can either move on to migrate your resource domains or decommission the source account domain, according to your migration plan.

USING ADMT IN AN INTRA-FOREST RESOURCE DOMAIN MIGRATION

This migration type is very similar to the inter-forest resource domain migration. Once again, here are some guidelines to follow when performing this type of migration:

1. Use the Service Account Migration Wizard. ADMT cannot deter-mine whether a service account is used by more than one service. You will need to do this yourself. You will be asked to specify the computers that are using service accounts, and then the wizard will examine those servers for all service accounts. These accounts will then be included when you later migrate user accounts.

2. Use the Computer Migration Wizard. Resource domains frequently hold the computer accounts for user workstations and application servers. The Computer Migration Wizard will migrate the local com-puter information and account for each of the workstations and member servers in the resource domain. ADMT dispatches an Agent to each of the computers to be migrated. At the completion of the Agent’s duties, it will force the computer to shut down and restart.

3. Use the User Migration Wizard to migrate service accounts to the target domain. Remember that you might have to manually reset some service accounts for applications.

4. Use the Group Migration Wizard at this point to migrate shared local groups from the resource domain to the target domain. On the Group Options page, make sure you select Migrate Group SIDs To Target Domain and also Do Not Rename Accounts.

From here, your steps will be dictated by your migration plan. You will either decommission the resource domain or migrate other domains.


USING ADMT IN AN INTRA-FOREST ACCOUNT DOMAIN MIGRATION

Here again, the process is very similar to the inter-forest account domain migration. Because this type of migration is within a forest by definition, you won’t need to establish trust relationships. All domains within a forest have transitive trusts by default. To perform an intra-forest account domain migration, follow these guidelines:

1. Use the Group Migration Wizard to migrate the domain global groups from the source domain to the target account domain. If a high number of users are in the global group you are migrating, it can take quite a while to process all of the members. This will also cause a heavy impact on your network traffic. Consider using the option to migrate the user accounts with the group instead.

2. Use the User Migration Wizard to migrate both user accounts and their roaming user profiles. On the User Options page of the wizard, make sure you check the Translate Roaming Profiles and the Update User Rights check boxes.

3. Use the Security Translation Wizard at this point to translate the local user profiles on the computers that have been migrated to the target domain, from the original SID of the user to the new SID of the user in the target domain. On the Translate Objects page of the wizard, select User Profiles as the object to translate.

After completing these steps, you can manually migrate a domain controller from the source domain to the target domain and decommission the source domain.

ClonePrincipal

Unlike ADMT, which generally moves objects from a source domain into the Active Directory target domain, ClonePrincipal works by creating a copy of the object in the new domain. Essentially, it makes a clone of the original object in the new location. ClonePrincipal is especially useful when you want to incrementally move users from the source domain to the new target domain.


The ClonePrincipal tool is a series of Visual Basic script files that perform various migration tasks. Included in the set are scripts that will migrate user accounts, local group accounts, and global group accounts. ClonePrincipal doesn’t make any changes to the source domain. It simply copies information out of the Security Accounts Manager (SAM) database and imports it into Active Directory in the target domain.

Since ClonePrincipal is made up of Visual Basic scripts, the individual scripts can be used easily in migration scripts. This makes it possible to completely script your migration and execute it as a series of phased rollouts. Once the accounts have been cloned and are being used successfully in the target domain, you should delete the original accounts.

The scripts that make up ClonePrincipal are installed with the Sup-port Tools from the Windows 2000 Server CD-ROM. The Support Tools are installed from the Support Tools folder on the CD-ROM; simply browse for the folder and then double-click the setup.exe file.

Benefits of using ClonePrincipal include the following:

� Users can log on to the clone account in the new domain but still have an emergency fallback account in the old domain.

� The source domain isn’t disrupted during the migration of accounts to Windows 2000.

� You can shift users to the new environment in small groups. If there are problems, fewer people are involved, and you can easily move them back to their original accounts.

� You don’t have to modify the Access Control Lists (ACLs) on shared resources in order to preserve the user’s ability to access them. ClonePrincipal will use the SIDHistory feature to maintain both the new and the old SID for a security principal.

� You can upgrade a Backup Domain Controller (BDC) to Win-dows 2000, then use the Active Directory Wizard to demote the server. Once demoted to a member server, the computer can be migrated to the new domain without having to change the local


groups or permissions assigned to local resources. This is particu-larly useful if the server is acting as a resource server for applica-tions or file storage.

� Multiple groups from different domains can be merged into a single group in the target domain.

The ClonePrincipal script syntax is fully documented in the clonepr.doc file that is installed in the Support Tools folder under Program Files. This document contains notes on the use of the tool and examples of how the scripts might be used in a batch file.

Once the Support Tools are installed, they will be saved to the Program Files\Support Tools folder, and shortcuts are placed on the Start menu. The folder contains a copy of the Deployment Plan-ning Guide from the Windows 2000 Server Resource Kit in electronic Help format, as well as Help files for the tools themselves. To use ClonePrincipal, however, you will work from the command prompt.

WARNING If your target domain was recently upgraded from NT to Windows 2000, neither ClonePrincipal nor ADMT will properly add the SIDHistory of objects to the destination domain. To resolve this, delete and rebuild the trust relationships between your source and target do-mains before using ClonePrincipal or ADMT.

ClonePrincipal includes five sample Visual Basic scripts that provide the basic functionality for your migration needs. These scripts can be used to clone accounts from the source domain to the target domain, or they can be used as guides to create your own scripts. The five scripts are:

sidhist.vbs This script copies the SID of a security principal from the source domain to the SIDHistory attribute of an existing security principal in the target domain.

clonepr.vbs This particular script is a sample script that clones a single security principal from the source domain to the target domain. It will create the destination account if it doesn’t already exist and copy the SID to the SIDHistory attribute. If you are cloning a user


account or a global group, it will also create the memberships in the target domain. If you are cloning a local group, it will also clone all of the members to the target domain.

clonegg.vbs This script clones all of the global groups in a given domain to the target domain.

cloneggu.vbs Rather than cloning from a given domain, this script clones all global groups and user accounts from the source domain to the target domain.

clonelg.vbs This last script clones all of the shared local groups on the domain controllers in the source domain to the target domain.

Preparing to Use ClonePrincipal

ClonePrincipal accesses two different domains for some very sensitive work in terms of security. For this reason, you must have administra-tor permissions in both domains, and trusts must be established between the domains. SIDs must be unique within a forest whether they are the primary SID or the SIDHistory. Because of this, the source domain must be in a different forest than the target domain. The target domain must be in native mode because the SIDHistory attribute is required for the destination accounts.

ClonePrincipal must be run at the command prompt of a domain con-troller in the target domain. This should be the PDC Emulator for best results, but it can be any Windows 2000 domain controller. The PDC of the source domain should be the focus of operations from the source domain. The source PDC must be running Windows NT 4 with Service Pack 4 or later, or it can be running Windows 2000. Again, the PDC Emulator should be chosen if the source domain is Windows 2000 because the auditing will then be generated on only one computer.

The PDC or PDC Emulator should have an entry added to the Reg-istry to enable the Local Security Authority (LSA) to use TCP/IP. The setting is HKLM\System\CurrentControlSet\Control\LSA. The value name is TcpipClientSupport, the type is REG_DWORD, and the data is a hexadecimal 0x1. ClonePrincipal requires a group called SourceDomainName$$$ in the source domain. The name is the name


of the source domain plus the three dollar signs ($$$), so if the source domain is Boston, the local group name would be Boston$$$.

The last step in preparing for ClonePrincipal is absolutely required, and that is to enable auditing in both the source and target domains for account management. You will need to use auditing for User and Group Management (in Windows NT 4) or Account Management (in Windows 2000) for both success and failure events. This enables you to track the progress of the migration and determine when accounts have not migrated successfully. It also give administrators a way of determining when this procedure has been run on their domain, help-ing to prevent unauthorized use of ClonePrincipal.

Using ClonePrincipal

You can choose to use ClonePrincipal with the sample scripts pro-vided by Microsoft, or you can write your own scripts. If you decide to write your own scripts, consult the white paper for ClonePrincipal, clonepr.doc, which is provided on the CD-ROM with the tools. Otherwise, if you want to go ahead and use the samples that have been included with the tool, here is some syntax to use:

sidhist.vbs This script copies the current SID of one account to the SIDHistory attribute of one destination account. Its syntax is

Cscript sidhist.vbs /srcdc:<source PDC>

/srcdom:<source domain> /srcsam:<account name>

/dstdc:<target PDC> /dstdom:<target domain>

/dstsam:<target account>

clonepr.vbs To clone a single account from the source domain into the target domain, use clonepr.vbs. Its syntax is

Cscript clonepr.vbs /srcdc:<source PDC>

/srcdom:<source domain> /srcsam:<source account>

/dstdc:<target PDC> /dstdom:<target domain>

/dstsam:<target account> /dstDN:<destination

Distinguished Name>


cloneggu.vbs This script clones all global groups and users from the source domain to the target domain. Its syntax is

Cscript cloneggu.vbs /srcdc:<source PDC>

/srcdom:<source domain> /dstdc:<target PDC>

/dstdom:<target domain> /dstOU:<destination OU>

clonelg.vbs The task of this script is to clone shared local groups from the source domain controller to the destination domain con-troller. Its syntax is

Cscript clonelg.vbs /srcdc:<source PDC>



clonegg.vbs This script clones all global groups from the source domain to the target domain. Its syntax is

Cscript clonegg.vbs /srcdc:<source PDC>



An example of how to use ClonePrincipal to copy user accounts from the source domain in the fictitious company Coolcompany Inc. to the target domain of coolcompany.local would be to use cloneggu.vbs to clone all global groups and users from the Seattle domain of Coolcompany Inc. to the coolcompany.local target domain. To accomplish this move, you must have some more infor-mation. The source domain name is Seattle, and the PDC of the Seattle domain is Seattle_dc. The target domain is coolcompany.local, but the NetBIOS name of the domain is coolcompany. The target PDC is Cool_dc. You will clone the users and groups into the Seattle OU container within coolcompany.local. The command line for this would be

Cscript cloneggu.vbs /srcdc:seattle_dc /srcdom:seattle /dstdc:cool_dc /dstdom:coolcompany /dstOU:OU=Seattle,DC=coolcompany,DC=local


For this command to work properly, the organizational unit (OU) of Seattle must already exist in the coolcompany.local domain. Moving groups and user accounts will be discussed further in the next two objectives.

Last Notes about ADMT and ClonePrincipal

ADMT preserves passwords only in intra-forest migrations. For inter-forest migrations using ADMT, the only choices for passwords are random (password.txt) and username. The original password is not maintained. A disadvantage of using ClonePrincipal is that the source account is automatically disabled and passwords must be reset. In ADMT, you have the ability to disable the source and destination accounts.

MoveTree

The Active Directory Object Manager (MoveTree.exe) is a command-line utility for moving objects from one Active Directory domain to another. It can be used to move user accounts or even entire OUs from one domain to another in the same forest. This tool will be most useful once you have begun your migration and have integrated some of the old domains into the new Active Directory structure.

Be aware that there are some objects that MoveTree cannot migrate to another domain:

� System objects, such as the built-in special groups Everyone, System, or Interactive

� Any objects located in the domain’s special containers: Built-In, ForeignSecurityPrincipals, System, and LostAndFound

� Domain controllers or any object whose parent is a domain controller (such as a local account on a domain controller)

� Any object that has the same name as an object in the target domain


MoveTree is described as doing pretty much the same thing as ClonePrincipal. While the two tools appear to fulfill the same function, they do have some basic differences:

� MoveTree is designed to work within a single forest, whereas ClonePrincipal is exclusively designed to move objects from one forest to another. MoveTree is intra-forest and ClonePrincipal is inter-forest.

� MoveTree actually moves the objects it works with. This means that they are copied to the new domain and then destroyed in the original domain. ClonePrincipal copies the object to a new domain and leaves the original intact. ClonePrincipal also disables the accounts.

� MoveTree maintains the users’ current passwords after the move operation is completed. ClonePrincipal does not keep the users’ passwords.

� MoveTree maintains the object’s Globally Unique Identifier (GUID) after the move, while ClonePrincipal does not.

For a complete listing of the command syntax to use with MoveTree, consult the online Help file for the Support Tools.

NETDOM

The Windows 2000 Domain Manager, or NETDOM, is extremely useful for creating trusts, querying domains for their existing trusts, and adding or removing computers from Windows 2000 domains. Using NETDOM, you can easily configure two-way trusts between NT 4 domains and Windows 2000 domains. You can create shortcut trusts between domains in different trees of the same forest to expedite browsing.

This command has too much syntax to cover fully here, but there are some basic commands that you are likely to use during a migration. NETDOM can be used for the following functions:

Add Windows 2000 computers to a domain. NETDOM can add Windows 2000 computers to Windows 2000 or NT 4 domains and


can be used to specify the destination OU for the computer account in Windows 2000 domains.

Establish trust relationships. NETDOM can create one-way or two-way trusts between NT 4 domains and Windows 2000 domains. It can also create transitive trusts between Windows 2000 domains, to be used as shortcuts between domains in the same forest for faster browsing of Active Directory.

Verify and/or reset the secure channel between computers. This one is a little more arcane. NETDOM can verify or reset the secure channel of communication between either member servers and work-stations within a domain or BDCs with the PDC in NT 4 domains.

Manage trust relationships. NETDOM can be used to enumerate all trusts that currently exist for a given domain, including indirect trusts within a Windows 2000 forest.

NETDOM is installed as part of the Windows 2000 Support Tools. If you followed the steps in the ClonePrincipal section of this chapter to install the Support Tools, then you already have NETDOM installed.

For information regarding the specific use and syntax of the NET-DOM command, please consult the online Help files for the Win-dows 2000 Support Tools.


There are four necessary procedures for this objective. Two of them center on installing tools for your migration, and the other two are for configuring your environment properly. Both concepts are typically heavily tested.

Installing Active Directory Migration Tool

To perform this exercise, you must first download ADMT from this URL: www.microsoft.com/windows2000/downloads/deployment/admt/default.asp.


This procedure will lead you through the necessary steps to install ADMT on your computer. Note the hardware requirements for ADMT listed earlier in this chapter and make sure that your computer meets these requirements. The computer should be a domain controller, but ADMT will install on a member server.

1. Open My Computer and browse to the location where you saved the ADMT.exe self-extracting archive file.

2. Double-click the file to begin the extraction and installation.

3. Click Next on the opening banner page for the Active Directory Migration Tool Setup Wizard. The second page is the license agreement. Click the button to accept the license agreement, then click Next.

4. Select an installation path for the program. The default is to install it in your Program Files folder. Click Next to proceed.

5. Click Next to begin the installation. The files will now be copied to your hard disk. When setup completes, click Finish to exit the Setup Wizard.

Now that you have installed ADMT, verify that it is working on your computer.

1. Open Start � Programs � Administrative Tools � Active Direc-tory Migration Tool. You will most likely find this at the bottom of the Administrative Tools � Group menu.

2. Click the Reports icon in the console tree. If you now see a set of instructions in the right pane of the Migrator console describing the Reports Wizard, you have correctly installed ADMT.

Enabling Auditing

Enabling auditing is a critical step to take before beginning the migra-tion or restructure. Auditing should be enabled on both the source NT


domain and the target Windows 2000 domain. To enable auditing on a Windows NT 4 domain, follow this procedure:

1. Open User Manager by clicking Start � Programs � Administra-tive Tools � User Manager For Domains.

2. Click the Policies menu and select Auditing.

3. Click Audit These Events, and then place check marks in the Suc-cess and Failure check boxes beside User and Group Management.

4. Click OK to apply the changes.

To enable auditing on a Windows 2000 domain, follow this procedure:

1. Click Start � Programs � Administrative Tools � Active Direc-tory Users And Computers.

2. In the console tree in the left pane of the console, right-click the Domain Controllers container and select Properties from the context menu.

3. Click the Group Policy tab.

4. Highlight Default Domain Controller Policy, and then click the Edit button.

5. In the left pane of the Group Policy console, expand the Audit Policies tree.

6. Right-click Audit Account Management and select Security from the context menu.

7. Check the Success and Failure box and then click OK. You can wait for the normal replication cycle to replicate this policy to all domain controllers, or you can force the replication using Active Directory Sites and Services.

Installing Support Tools

You need to install the Support Tools from the Windows 2000 CD-ROM in order to run ClonePrincipal and NETDOM. To install the Support Tools, perform the following procedure:


1. Insert the Windows 2000 CD-ROM in a drive on your computer. Many of the support tools are designed to be run on a domain con-troller, so keep that in mind when selecting a computer.

2. Browse to the Support Tools folder on the CD-ROM, and double-click the setup.exe program. The Windows 2000 Support Tools Setup Wizard opens. Click Next.

3. Enter your name and organization, and click Next.

4. Select the type of installation you want to perform, either Typical or Custom. Click Next.

5. If you selected a Custom setup, you will be presented with another option screen. Notice that you can only select to install the whole package or nothing at all. The Custom setup does allow you to choose the install path, however.

6. Click Next to begin the installation. When the setup is complete, you will see the final page in the wizard, summarizing the steps you have completed. Click Finish to close the wizard.

Configuring an Environment for ClonePrincipal

ClonePrincipal is a very useful tool for cloning user and group accounts into a new target domain. However, for it to work properly, you must perform some configuration steps. To configure your envi-ronment for ClonePrincipal, follow this procedure:

1. Make certain the source domain PDC is running the required operating system level—for example, Windows NT 4 with Service Pack 4 or higher.

2. Establish a trust from the source domain to the target domain. Optionally, use a two-way trust between the two domains.

3. Edit the Registry on the source domain controller to include the value TcpipClientSupport REG_DWORD 0x1 at this location: HKLM\System\CurrentControlSet\Control\LSA. This change enables the use of Remote Procedure Calls over TCP/IP.

4. Create a new local group on the source domain controller named <SourceDomainName$$$> where SourceDomainName is the


name of your source domain. This group name is used for the auditing of the ClonePrincipal operations in the NT 4 domain.

5. Enable auditing in both the source and the target domain. Audit for both success and failure of account management events. In NT 4, this would translate to User and Group management.

6. It is also possible that you would have to register the clonepr.dll file if you installed ClonePrincipal manually. To register the .DLL file, execute this command at a command prompt: regsvr32 clonepr.dll.

Exam Essentials

Know what ADMT is used for. The Active Directory Migration Tool is one of the primary tools used during migrations and restruc-tures. It consists of a bunch of wizards that help during the migration process. It also moves objects from the source domain to the target domain, and is considered a destructive process.

Know what ClonePrincipal does. ClonePrincipal is another important tool. Unlike ADMT, it copies, or clones, objects and does not destroy the original. It performs its tasks through a series of VBScripts.

Know what MoveTree is used for. MoveTree is similar to ClonePrincipal in function. However, it moves objects instead of copying them, and is used intra-forest instead of inter-forest.

Know where to use NETDOM. NETDOM’s most important tasks are creating, querying, and managing trust relationships, and adding computers to and removing computers from a domain.

Know what computer to install ADMT onto. ADMT works best when installed on a domain controller in the target domain. It will work on a member server, but installing it on a domain controller is preferred.


Know what operating systems the ADMT Agent will run on. The ADMT Agent will run on Windows NT 3.51 with Service Pack 5, Windows NT 4 with Service Pack 4 or higher, and Windows 2000.

Know the pre-migration configuration steps for running ADMT.There are a lot of specific steps involved, so here is a summary. Ensure that the target domain is running in native mode, and the source is either a Windows NT 4 domain or a Windows 2000 domain. Create a local group called SourceDomainName$$$ on the source domain controller. Disconnect any active sessions between the domain con-trollers, edit the Registry, and enable auditing on both the source and target domain controllers.

Understand the key difference in source domain types when using ADMT. You have two choices for source domains: Windows NT and Windows 2000. If the source domain is Windows 2000, it must be in the same forest as the target for you to use ADMT.

Know the differences between ClonePrincipal and MoveTree.MoveTree works within a forest, and ClonePrincipal works between forests. MoveTree moves the object and destroys the original, and ClonePrincipal copies and retains the original. MoveTree will main-tain user passwords, and retain the original object’s Globally Unique Identifier (GUID).


ADMT The Active Directory Migration Tool is a major tool used for inter-forest and intra-forest domain migrations.

ClonePrincipal Tool used to clone objects from the source domain and copy them into the target domain.

MoveTree Tool used to move objects within a forest.

NETDOM Tool used to query and manage trust relationships, and modify computer membership in a domain.


RID Master The Relative Identifier (RID) Master is the Operations Masters role that provides unique security identifiers to objects in a domain.

�Migrate global groups and user accounts.

When performing a migration, this is one of the most critical steps to get right. The network is about the users, and those users being able to access things they need to get their job done. Therefore, it makes sense that getting the users and the global groups they belong to migrated properly is highly important.

Migrating users and groups (as well as computers, which is given more coverage in the next objective) is accomplished with the same tools that were covered in the previous objective. As you will see, the previous objective, this objective, and the next objective are very closely related.


Moving user accounts and global groups often correlates with mov-ing local groups and computers. However, since local groups and computers more often imply “resource access,” and users and global groups relate more to the user side of resource access, Microsoft has broken them into separate objectives. This objective concentrates on the users and the groups they belong to, and on getting them migrated properly using the right tools.

Migrating User Accounts with ADMT

ADMT is a great tool for analyzing the progress of your migration. It includes a number of wizards for reporting the account conflicts between the source and target domains, as well as wizards for migrat-ing trusts and security principals. It can also help with users.


The Microsoft strategy for selecting the “proper” migration tool suggests that you would only copy security principals with Clone-Principal and migrate them with ADMT. Like so many other Microsoft tools, ADMT is actually capable of performing both roles. The exam is likely to prefer the official strategy, so if you’re preparing for the test, keep that in mind. In the real world, ADMT is much easier for many people to use.

To migrate user accounts with ADMT, you will be using the User Account Migration Wizard, as shown in Figure 4.11.

F I G U R E 4 . 1 1 : The User Account Migration Wizard

Performing the Migration of User Accounts

Here are some guidelines to follow when migrating user accounts using ADMT. Because you get to use a wizard, it may make the pro-cess seem less “real” or complicated as opposed to using a command prompt. Be assured that this process does take some involvement from the administrator, but having the wizard as guidance is a major bonus.


1. Open ADMT by clicking Start � Programs � Administrative Tools � Active Directory Migration Tool. Right-click the Active Directory Migration Tool node in the console and select User Account Migration Wizard from the menu.

2. Decide whether you will migrate users or only perform a test migration. The test migration won’t actually move any accounts; it will only test the possibility.

3. Select the source and target domains for the migration.

4. Select some user accounts for the migration.

5. The Select Users dialog shows the source domain chosen for the Look In field. You should see a list of all the user accounts in the source domain, from which you can select individuals or sets of users. When you have selected the users’ accounts, click the Add button to move their accounts to the bottom text box of the dialog.

6. Verify that the correct user accounts are displayed in the user list.

7. The Organizational Unit Selection page opens and prompts you to provide the OU in the target domain where the accounts should be created. The entry should be listed by the distinguished name (DN). If you are unsure of the DN for the target OU, click the Browse button to display the dialog.

8. On the Password Options page, you must determine what the initial password will be for each migrated account. You can select either Complex Passwords or Same As User Name as the password option to assign. Either way, the list of user accounts and the matching passwords will be stored in the local file path specified in the Loca-tion To Store Password File list box.

9. The Account Transition Options page prompts you to decide how to handle the user accounts when they are migrated. Your options include Disable Source Accounts, Disable Target Accounts, and Leave Both Accounts Open. The last option will leave the accounts in both domains active and available for users to log on to. This has the same effect as using ClonePrincipal to clone the user accounts. Check the box for Days Until Source Account Expires to cause the account in the source domain to automatically become


unavailable at the end of the specified day. Check the box for Migrate User SIDs To Target Domain to have ADMT copy the current SID to the SIDHistory field of the new account.

10. If you chose to have the SIDHistory created, the User Account page will prompt you to supply a user account with local administrator rights on the source domain controller.

11. The User Options page provides some options governing how user account names should be handled and what information will be migrated with the account. You have three options for related information: Translate Roaming Profiles, Update User Rights, and Migrate Associated User Groups. This last option will migrate any group that the user account belongs to. It has a sub-option that lets you update any of the groups that may have already been migrated with this account’s information. The rest of the page is dedicated to the naming of the migrated user accounts: Do Not Rename Accounts, Rename With Prefix, and Rename With Suffix.

12. The Naming Conflicts page lets you resolve any duplicate names that might be created by migrated accounts. Built-in accounts won’t be migrated anyway, so don’t worry about those accounts. This page defines how to handle a user account that has the same name as one that has already been created in the target domain. You can choose to ignore the conflict, replace the conflicting account in the target domain with the account being migrated, or rename the migrated account with either a prefix or a suffix to keep the names unique.

13. The last page of the wizard displays a summary of your selec-tions. Click the Finish button when you are satisfied with the options, or click the Back button to go back and change any of the options. When you click the Finish button, the User Account Migration Wizard will perform the tasks you selected. During the migration process, you will see the status of the operation dis-played in the Migration Progress dialog.

That’s really all there is to migrating user accounts using ADMT. Microsoft recommends using the testing option of the wizard until you receive no error messages in the process. Selecting the options to


leave both accounts open after the migration and copy the current SID to the SIDHistory value of the new account in the target domain gives you a way out if there are any serious problems later with the migration. The users will still have the ability to log on to their original accounts if necessary.

Migrating Group Accounts with ADMT

Migrating group accounts is handled very much like the user accounts. Here you can use either ClonePrincipal to copy the group accounts or Active Directory Migration Tool to move the accounts to the target domain. If you want to migrate groups from one tree to another within a single forest, try using MoveTree. If you would rather copy the groups into the target domain, then you should be using ClonePrincipal. ADMT can be used to migrate group accounts in addition to user accounts.

To migrate groups using Active Directory Migration Tool, you will be using the Group Account Migration Wizard within ADMT. Here are some steps to follow:

1. Open ADMT by clicking Start � Programs � Administrative Tools � Active Directory Migration Tool.

2. Right-click the Active Directory Migration Tool node in the console and select Group Migration Wizard from the context menu. This opens the Group Account Migration Wizard.

3. Decide whether you will migrate users or only perform a test migration. The test migration won’t actually move any accounts; it will only test the possibility.

4. Select the source and target domains for the migration.

5. Select some group accounts for the migration. You can use any criteria you’ve chosen in your migration plan to choose a set of group accounts, or you can migrate all of them at once.

6. The Organizational Unit Selection page opens and prompts you to provide the OU in the target domain where the accounts should be created. The entry should be listed by the distinguished name (DN). If you are unsure of the DN for the target OU, click the


Browse button to display a dialog where you can easily browse for the proper OU.

7. On the Group Options page, you will find some options to control how the groups are migrated. For example, you can copy the group’s SID to the SIDHistory of the new group account in the target domain. You can also choose to copy the members of each group to the new location at the same time the group is migrated.

8. If you chose to have the SIDHistory created, the User Account page will prompt you to supply a user account with local administrator rights on the source domain controller. Enter the appropriate information.

9. The Naming Conflicts page lets you resolve any duplicate names that might be created by migrated accounts. This page defines how to handle a user account that has the same name as one that has already been created in the target domain. You can choose to ignore the conflict, replace the conflicting account in the target domain with the account being migrated, or rename the migrated account with either a prefix or a suffix to keep the names unique.

10. If you chose to have the group members copied to the target domain, you will be prompted to set the password options to decide how a password will be assigned to the new accounts and where the password file will be written. Then you will need to decide whether the accounts will remain active in both domains or disabled in one or the other.

11. Finally, the wizard displays a summary of all the options you selected during the previous steps. When you click Finish, the wizard will complete the steps.

You will use these same steps to migrate either global or local accounts from the source domain. The Group Account Migration Wizard will enable you to migrate either type of group account individually or all together.


Migrating User Accounts With ClonePrincipal

If your plan calls for migrating users with minimum impact to the production environment and maximum fault tolerance, you should choose to use ClonePrincipal. If anything goes wrong, the user accounts are still intact in the original source environment. The users can simply log on to their old accounts and continue working while you go about figuring out what went wrong.

ClonePrincipal gives you the opportunity to perform a gradual, controlled migration to Windows 2000 and Active Directory. If your plan calls for migrating small groups of users at one time, with maximum reliability and minimum disruption to the produc-tion environment, ClonePrincipal is the tool you should use. Most migration plans describe moving user accounts, rather than clon-ing them. If you are going to be moving accounts to the target domain and you don’t want the added fault tolerance of creating clones of your security principals, then you should be using Active Directory Migration Tool.

NOTE Both ClonePrincipal and Active Directory Migration Tool require you to create a special local group in the source domain to use for the migration with the name DomainName$$$, where DomainName is the name of the source domain. If you receive an error that the specified local group does not exist, verify that this group exists in the source domain.

To clone user accounts from the source domain into the new Active Directory environment, you could use the clonepr.vbs script to copy single accounts across. This could potentially be very slow if you were to type in the script commands for each user that you wanted to clone. Instead, create a batch file that calls this script repeatedly to clone single user accounts. This way, you can clone groups of user accounts in a gradual, controlled fashion.

A batch file is a great way to call clonepr.vbs to clone individual user accounts from the source domain to the target domain. Of course, the


cloneggu.vbs script would be even better if you wanted to clone all of your global groups and users at the same time.

Migrating Global Group Accounts with

ClonePrincipal

Migrating group accounts is handled very much like the user accounts. Here again you can use either ClonePrincipal to copy the group accounts or Active Directory Migration Tool to move the accounts to the target domain. If you want to migrate groups from one tree to another within a single forest, try using MoveTree instead of ClonePrincipal. If you are planning to copy the groups into the tar-get domain, then you should be using ADMT.

Migrating groups from the source domain using ClonePrincipal is easier than migrating user accounts. The sample scripts included with ClonePrincipal provide a method to clone all groups of a specific type at one time. For instance, the clonegg.vbs script will clone all global groups from the source to the target domain, and clonelg.vbs will do the same for domain local groups.

Clonegg.vbs This script clones all global groups from the source domain to the target domain. Its syntax is

Cscript clonegg.vbs /srcdc:<source PDC>



Use the distinguished name (DN) for the destination OU. If you don’t use this format, the script will be unable to attach to the correct loca-tion in the target Active Directory. The special local group you cre-ated when setting up the computers for ClonePrincipal—for this example, the group Seattle$$$—will also be cloned when you run this script. As the script runs, you will be able to watch its progress on the screen because it will print out the information for each group as it is cloned. When you use this script, use the earlier example as a guide and modify the necessary parameters for your own environment.


There is a built-in problem involved in running either the clonegg.vbs or the cloneggu.vbs script. These scripts, by default, will also attempt to clone the built-in global groups. Windows NT/2000 sees these groups as well-known RIDs, because these groups exist on all NT/2000 domain controllers and always have the same Relative Identifier. If you intend to clone the source groups onto the existing global groups in your tar-get domain (for instance, to give them access to all resources the orig-inal group has through the SIDHistory feature), then the problem is that the built-in groups are not located in the destination OU. You can move the groups temporarily to the destination OU, or you can change the script.

Fortunately, this edit in the script is very simple. You will be searching for a block of code near the end of the script that will prevent the script from cloning the well-known RIDs, leaving it free to concen-trate on the groups you have created in the source domain. To edit the script, open it either by using the File � Open command in Notepad or right-clicking the file and selecting Edit from the context menu. Use the Edit � Find command in Notepad to locate the following block of code:

'To Stop Cloning Well Known Sids Uncomment 4 lines

below

' if HasWellKnownRid(sidString) then

' ShouldCloneObject = False

' exit function

' end if

Once you’ve found the code, remove the leading single quotes (') from those lines, then save the file and run the script using the pre-vious example as a guideline. When you run the script in a production environment, change the command syntax to include the names that are appropriate for your network.



This objective was filled with step-by-step procedural instructions on how to properly migrate users and global groups. However, one more procedure is included here for practice on migrating user accounts.

Migrating Accounts Using the Migration Tools

This procedure assumes that you have access to at least two com-puters capable of running Windows 2000 Server. One may be installed with NT 4 Server as a PDC. The other should have Win-dows 2000 Server installed as a domain controller of its own domain.

1. Install ADMT on the Windows 2000 domain controller.

2. Install the Windows 2000 Support Tools.

3. Use NETDOM to create a two-way trust between your two domains.

4. Configure auditing in both domains for Account Management success and failure.

5. Add the special local group on the Windows NT domain controller, SourceDomainName$$$.

6. Create some test user accounts and global groups in the source domain using User Manager for Domains if running NT or Active Directory Users and Computers if running Windows 2000.

7. Use ADMT to run the Reporting Wizard to determine the name conflicts between the domains. The only conflicts should be the built-in groups and accounts.

8. Use ClonePrincipal to copy the global groups and users from the source domain to the target domain using the cloneggu.vbs script.

9. Verify that the users were migrated successfully by logging on to the target domain using one of the cloned accounts. Then log on to the source domain using the same accounts to verify that they still work in the source domain.


Exam Essentials

Know the advantages of using ADMT. ADMT can be used to migrate users and groups, and is easier for most people to use because it’s a graphical wizard, instead of a command-line script such as ClonePrincipal.

Know the advantages of using ClonePrincipal instead of ADMT.The biggest advantage to using ClonePrincipal is that it lets you do a gradual migration. It also leaves the original users and groups intact, giving you a back-out plan if something goes wrong during the migration.

Know what other tools can be used, and when they should be used.You can also use MoveTree to move objects if they are within the same domain. NETDOM is not used for migrating users or groups.


Relative Identifier (RID) Number that identifies an object, such as a user or group, relative to other objects within the same domain.

�Migrate local groups and computer accounts.

Migrating local groups and computer accounts is typically done at or close to the same time as migrating users and global groups. Therefore, a lot of the material for this objective is similar to the last one. This objective and the procedures tested are closely related to the last two objectives and procedures.



The best way to accomplish the migration of your computer accounts is to use the Active Directory Migration Tool’s Computer Migration Wizard. This wizard helps to automate the tasks required to migrate the computer accounts from your source domain to the target Windows 2000 environment.

The process of migrating computer accounts is almost identical to migrating user accounts with ADMT. Instead of selecting user accounts, you will be selecting computer names from the list of all the computers in the source domain.

You need to determine the destination to which the computer accounts will be migrated. This is expressed as a distinguished name (DN) and can be determined by browsing for the appropriate container or OU in the target domain.

An interesting difference between migrating computer accounts and migrating user accounts is the Translate Objects page, where you decide which properties of the computer will be translated. Trans-lation is the process of mapping the current object’s SID to the SIDHistory of the new account. The objects that can be translated for computers include the following:

� Files and folders

� Local groups

� Printers

� Registry

� Shares

� User profiles

� User rights

The SID information for the objects you select on the Translate Objects page will be updated to accept the same user accounts in their new incarnation within the target domain. This is a necessary step if


you want the migration to be as seamless as possible for your users. The translation process provides three different methods for applying the translated security:

Replace This option replaces the SID of the source domain security principal with the SID of the equivalent target security principal.

Add The Add option adds the SID for the equivalent security prin-cipal in the target domain to the Access Control List (ACL) of the object and leaves the SIDs of the original security principals in place.

Remove The Remove method adds the new SID information for the target security principals and then deletes the original SID information.

Because the migration of a computer account to a new domain requires restarting the computer, this process is included in the Migration Wizard. You must set the number of minutes that the com-puter will wait after completing the migration before it restarts and uses the new computer account in the target domain. You will also be given the same options for handling the renaming of the computer accounts when they are migrated, as you saw when migrating users and groups. You can then determine how any duplicate names will be resolved. Finally, you will receive a summary of the selected options before the migration tasks are run.

Migrating Local Group Accounts with

ClonePrincipal

Migrating group accounts is handled very much like migrating the user accounts. Here again you can use either ClonePrincipal to copy the group accounts or Active Directory Migration Tool to move the accounts to the target domain. If you want to migrate groups from one tree to another within a single forest, try using MoveTree instead of ClonePrincipal. If you are planning to move the groups into the tar-get domain, then you should be using ADMT.


NOTE The information regarding migrating local groups is nearly identical to that for migrating global groups. The major difference is the script you use.

Migrating groups from the source domain using ClonePrincipal is easier than migrating user accounts. The sample scripts included with ClonePrincipal provide a method to clone all groups of a specific type at one time. For instance, the clonegg.vbs script will clone all global groups from the source to the target domain, and clonelg.vbs will do the same for domain local groups.

clonelg.vbs This script clones shared local groups from the source domain controller to the destination domain controller. Its syntax is

Cscript clonelg.vbs /srcdc:<source PDC>



To use these scripts in the example company’s migration, first migrate the shared domain local groups using clonelg.vbs. Consult Table 4.1 for the configuration.

T A B L E 4 . 1 : Configuration for the Coolcompany Example

Configuration Option Source Domain Target Domain

Domain name Seattle coolcompany.local

Domain controller SeattleDC Sea-1

Administrator account

Administrator Administrator

Administrator password

Password Password

Organizational Unit N/A Seattle


So, to clone the domain local groups from the PDC of the Seattle domain to the Seattle OU in the coolcompany.local target domain, you would use this script:

Cscript clonelg.vbs /srcdc:SeattleDC /srcdom:Seattle

/dstdc:Sea-1 /dstdom:coolcompany.local

/dstOU:OU=Seattle,DC=coolcompany,DC=local

Notice the use of the distinguished name (DN) for the destination OU. If you don’t use this format, the script will be unable to attach to the correct location in the target Active Directory. The special local group you created when setting up the computers for Clone-Principal—for this example, the group Seattle$$$—will also be cloned when you run this script. As the script runs, you will be able to watch its progress on the screen because it will print out the information for each group as it is cloned. When you use this script, use the earlier example as a guide and modify the necessary parameters for your own environment.

Exam Essentials

Know what tools you can use to migrate local groups. You can use ADMT, ClonePrincipal, or MoveTree to migrate local groups.

Know the difference between cloning local and global groups using ClonePrincipal. If you are going to clone local groups, you will run the script clonelg.vbs. Global groups are cloned with the clonegg.vbs script.


translation The process of mapping the current object’s SID to the SIDHistory of the new account.


�Perform test deployments of intra-forest migrations and inter-forest migrations.

Before you begin your migration, you’ll do a lot of planning. Even the best planners occasionally forget one or two details. Per-forming test deployments will show you what details you forgot and, in most cases, give you ideas on how to fix the problem before it becomes a serious one.


Your test lab will play a vital part in testing your deployments. Ideally, you were able to configure a pristine environment, or a close copy of your existing network, and have used that to run trial migrations.

When performing trial migrations, here are some considerations to keep in mind:

Migrate small numbers at a time. It’s back to the idea of a pilot group. Migrate a small group of users and some of their resources, and see if they can access what they need. If you are going to use ADMT, this may cause problems on the real network, so here is where the test environment comes into play. If you are going to use ClonePrincipal, you have the original user accounts still available.

Migrate users as well as resources. If your users don’t have any-thing to access, there is no point to them logging on to the network. Don’t forget to migrate resources for them to access. Also have them try to access resources they shouldn’t be able to get to. Security is not only about allowing access, but about denying it as well.

Log any errors during the trial migration. This is probably the most important step. You are running a trial because you presume


that there will be some problems. Write them down, and figure out what caused them. Once you have solved the problem, it’s time to ver-ify that the fix worked, and then attempt the procedure all over again.

Know your tools. One tool in particular has a built-in safety valve. ADMT comes with an Undo Wizard, which attempts to undo the migration changes you made. If possible, it will even put the objects back into the original location. Although this wizard exists, it’s still not wise to put all your faith in one tool that may run into difficulties. ClonePrincipal leaves the original objects intact.

Exam Essentials

Know how to perform a trial migration. During the trial migra-tion, you will use the same tools as before (ADMT, ClonePrincipal), but either in a test environment or on a small scale.

Know how to back out if there are problems. ADMT comes with an Undo Wizard, which can be immensely helpful. Since Clone-Principal leaves the original objects in place, other back-out measures are not necessary.


pilot group Small group of test users, typically those who have a good understanding of computers (and a sense of humor).

�Implement disaster recovery plans.

Your test environment will play an important role in disaster-recovery schemes as well as the deployment itself. It gives you an opportunity to perform some trial backups and restores to test your disaster-recovery plan.

In the case of creating a disaster-recovery plan, remember that no backup should be considered good until it has been tested. Once you


have created a plan for backups, try it out in the test lab where you have created an image of the production environment. Document your expe-riences here, as they will be valuable if and when it becomes necessary to perform a real recovery of a domain controller.


Here are some recommendations for preparing your environment for possible problems encountered during a migration to Windows 2000:

Keep one Backup Domain Controller offline. Pick one of your BDCs to fully synchronize before the PDC is upgraded, then take it offline. This will provide a means of recovery for the domain in case you need to roll back the migration.

Perform a full backup of every server before it is upgraded. A full backup preserves not only the system information, but also the data that the server may contain. This measure will provide a safe way to restore the original environment.

Follow your migration plan. You’ve spent a lot of time preparing doc-uments that detail every step of the process. Makes sense to use them.

Document any deviation from the migration plan. In some cases, you will find reasons to change the plan. Decide whether this will be a temporary departure from the migration plan or if the plan needs to be modified. Either way, document your changes.

Set expectations. Let your users and your management know what to expect during the migration. If problems are encountered, keep them informed of the status as well as when they can expect a resolution.

Restoring the pre-migration environment

Now you need to consider the unthinkable: what to do when your migration fails. For most of you, this will merely be a thought exercise, since you won’t have any problems at all. But some of you will encounter problems during the migration.


This section looks at ways that you can recover a failed server or even a failed network migration. If you have taken steps to provide a way out of a failure during an upgrade or a migration, then you will be in good shape. If not, then this section may also give you some ideas of things to do to recover your server or your network.

Using Disaster-Recovery Tools

The Windows 2000 Backup utility is useful in migrations for making backups in case you need to restore. You also know about preparing for migrations by taking a fully synchronized BDC offline prior to the upgrade. Also, the Backup utility and the Recovery Console can be used to restore a server after a partial or complete failure.

Windows 2000 Backup

Windows Backup can be used to restore data, but it can also be used to recover deleted objects from the Active Directory. You can use Backup to restore the System State information, restore the entire computer image, or just replace one object that was accidentally deleted from the Active Directory. There are three basic scenarios to examine: a failed domain controller, a damaged Active Directory database, and an authoritative restore of a single object in the Directory.

RESTORING A FAILED DOMAIN CONTROLLER

In the event of a partial or total failure of a Windows 2000 domain controller, you must first make sure that the computer is able to run Windows 2000. This may entail reinstalling the operating system, or it may mean repairing some files or replacing hardware to get the machine booting again. Starting fresh with a new format on the disks is a good idea when recovering a server. (This is assuming that you have a recent backup from which to restore.) Once Windows 2000 is reinstalled and running correctly, use Windows Backup to restore the System State and all data. Doing so will restore the domain controller to the state it was in when the last backup was run.

After the restore has completed, Windows 2000 will perform a couple of tasks when it is rebooted:


Consistency check Windows 2000 will perform a consistency check on the Active Directory database. The database will be verified and re-indexed.

Replication The Active Directory services will replicate with the replication partners in the domain to bring the version of the Direc-tory up-to-date. This will give it a chance to replicate any changed data and make its version of the Directory current. The File Replica-tion Service will also replicate with its partners to get a current version of any scripts being replicated between servers.

When these steps have been completed, your domain controller will be restored.

RESTORING A DAMAGED DIRECTORY

This scenario occurs when the Windows 2000 installation is running normally but the Active Directory database is damaged on that one computer. In this case, you don’t have to repair or restore the computer or the operating system, but you do need to restore the Active Directory database.

Restart the computer and select Directory Services Restore Mode from the Advanced Options menu. You get to the Advanced Options by pressing the F8 key during boot.

Once the computer is restarted in Directory Services Restore Mode, use Windows Backup to restore the latest System State information from the backup. When you restart the computer, Windows 2000 will re-index the Directory database and replicate current information from the other domain controllers.

Backing up the System State is as simple as placing a check in a box. However, not doing it could be disastrous if your domain controller crashes.

PERFORMING AN AUTHORITATIVE RESTORE

An authoritative restore marks the newly restored information as the correct copy to be replicated to all domain controllers. Without this mechanism, any Directory information that has been deleted and then restored would simply be deleted again when replication


occurred. With an authoritative restore, you have a very similar situation to the damaged database discussed previously. What’s unique here is that the operating system and the Directory are operating normally; you’re just trying to replace one or more objects that have been deleted from the Directory.

WARNING Before you do an authoritative restore, make sure the data you are restoring needs to overwrite more “current” data on the network.

Restart the computer and select Directory Services Restore Mode from the Advanced Options menu. Once Windows 2000 is running in Directory Services Restore Mode, restore the most recent System State information that contains the objects you want to restore. Now you have to tell Active Directory that these objects should stay and not be removed when the next replication event occurs.

The Recovery Console

One of the best Windows 2000 enhancements to troubleshooting pro-blems is the Recovery Console. Unfortunately, Microsoft decided not to install this utility by default. The Recovery Console is a command-prompt version of Windows 2000 to which you can boot your com-puter if it won’t boot to the graphical version of Windows 2000. It is an add-on to the Safe Mode options available from the Advanced Options.

To install the Recovery Console, place the original Windows 2000 CD-ROM in your local CD drive and run the following command: D:\i386\Winnt32 /cmdcons where D:\ is the letter assigned to your CD-ROM drive (substitute the letter assigned to your CD-ROM drive for D:). This command will run a mini version of the Windows 2000 Setup program that will install the Recovery Console.

The Recovery Console can also be accessed through the Repair process. If you need to use the Recovery Console and have not installed it ahead of time, you can access it by booting the com-puter with the Windows 2000 startup disks or by booting with the


Windows 2000 CD-ROM. When the Setup program prompts you to choose between setting up Windows 2000 and performing a repair, select Repair. When you reach the Repair menu, one of the options presented to you will be to run the Recovery Console.

NOTE The Windows 2000 startup floppies can be created with the MAKEBOOT.EXE and MAKEBT32.EXE programs in the Bootdisk folder on the Windows 2000 CD-ROM.

The Recovery Console is almost like a small version of MS-DOS, except that the commands are native to Windows 2000. But the con-cept is the same—you’re booting the computer to a command prompt where you can perform various tasks using the commands built into the Recovery Console.

You can use the Recovery Console to repair Windows 2000 if the prob-lem you are working on involves corrupted or missing files or services and devices that are misbehaving. The Enable and Disable commands in particular will be useful for resolving issues with services and devices. If your problem involves the Registry or Active Directory, then the Recovery Console won’t be of much help. However, Reg-istry issues that prevent your Windows 2000 computer from boot-ing will often involve some new software service or device driver that you’ve installed. From that standpoint, the Recovery Console will be of great use.

For a complete list of Recovery Console commands, please consult the Windows 2000 Help files.

Restoring Network Services

Restoring network services in the event of a failed network migration will be possible if you took precautions before beginning the migra-tion to Windows 2000. This means that you prepared backups of your network servers and that you held one server offline with current copies of your network service databases.


To restore your network services, you can use either of two basic approaches, depending on your preparation:

� Reinstall NT and restore the system data and the Registry from the tape backup. This will give you a very clean restore of the original environment, but it does take time to perform a separate reinstallation of the operating system and restore from tape on every server.

� Bring the offline server back online. If you prepared a single server with current versions of your network services under NT, then bringing this server back online may be all that you need to do to restore the original services.

Restoring your DHCP services may be more difficult to accomplish by restoring from tape. It is very possible that the address leases stored in the backup version of the database do not match the current leases. One of the easiest ways to resolve this would be to bring the DHCP server back online and then have your client computers release and renew their IP addresses. Alternatively, you can manually release all of the leases from the DHCP server and then have your clients release and renew their addresses.

Restoring the WINS servers is something best done from scratch. Restore the servers that will be running the Windows Internet Naming Service (WINS) and then delete all of the entries in the WINS database. When your clients reboot their computers, they will create new entries in the database automatically.

NOTE Even though the above procedure is the cleanest, Microsoft recommends restoring all services, including WINS, from backed-up copies.

Restoring the Domain Name System (DNS) servers can be done sim-ply by restoring the system from tape. DNS databases are held in static text files, and they won’t have changed since they were backed up, except for the dynamic information entered by Windows 2000.


Since earlier versions of NT cannot use this dynamic information, you really aren’t losing much when you lose the dynamic information.

Restoring Accounts

Restoring accounts to your network is simple if you prepared a BDC before the migration. If you did not take that precaution, then your work to restore the original environment will be somewhat more difficult.

By previously taking the domain controller offline, you enabled your user accounts to remain intact, just as they were when the BDC was last synchronized prior to the migration. Adding the other computer accounts back into the domain makes them and the resources they con-tain accessible to the users. Be sure to carefully check user permissions and rights when moving back to the original domain environment, as you won’t have the luxury of the SIDHistory to help maintain user access.

Restoring user accounts without a BDC held in reserve will take more legwork, since you will have to visit every computer that needs to be reinstalled and then perform the tape restore on each of the servers.

Most likely, everything will go well for your migration and you will never have to resort to these methods to roll back the migration. But it is required knowledge for the exam, and it should be a required skill for anyone who is going to manage a Windows 2000 migration project.


The necessary procedures for this objective are ones that you should hope you will never need to do in a real-life situation. However, it’s better to learn them now and never need them than to not know them and find yourself needing them.

Marking Objects to Remain during a Replication

Windows 2000 also calls this process an authoritative restore. Nor-mally when you restore data from backup, Windows recognizes it as older data, and deletes it if necessary when replication occurs. When


you perform an authoritative restore, the objects you have chosen as authoritative will essentially be the “master” objects for the next round of domain controller synchronization.

1. Boot into Directory Services Restore Mode.

2. At the command prompt, run Ntdsutil.exe.

3. Type authoritative restore at the command prompt. This indicates to Ntdsutil.exe that you want to mark recently restored Directory information as authoritative.

4. Use the command restore subtree <distinguished name> to mark the restored object as authoritative for the Directory. For example, if you had accidentally deleted the Seattle OU of the example company Coolcompany, you would use the command restore subtree OU=Seattle,DC=coolcompany,DC=local to mark the Seattle OU that had been restored from tape as authoritative. This will cause the restored OU to be replicated to other domain controllers instead of being deleted again when replication occurs.

Backing up System State Information

The System State is critical for the operation of a Windows 2000 domain controller. Backing it up is equally important. This procedure assumes that you have a Windows 2000 computer set up as a domain controller and that it has over 300MB of free space on a local hard disk.

1. Open Backup by clicking Start � Programs � Accessories � System Tools � Backup.

2. Click the Backup tab.

3. Expand the My Computer node in the left pane of the Backup window if it isn’t already expanded. Place a check mark in the box beside System State.

4. Click the Browse button next to the Backup Media Or File Name field at the bottom left of the dialog.

5. Browse for a local hard drive location that has at least 300MB of free space. Name the file System.bkf and click Open. This will return you to the Backup dialog.


6. Click the Start Backup button to begin the backup operation. Make note of the information provided on the various dialogs during the backup operation.

Once you have successfully performed a backup of the System State, try it again using the Backup Wizard.

Restoring Accounts Using a Backup Domain

Controller

You did take a BDC, synchronize it with the PDC, and take it offline, right? Good. Here is the procedure to restore your domain accounts using a BDC from the original domain:

1. Shut down all running Windows 2000 domain controllers for the upgraded domain.

2. Bring the BDC connected to the network online.

3. Promote the BDC to become the PDC for its domain. This means that the copy of the domain user database that the BDC had is now made writable and is the master copy of the database.

4. Reinstall some of the other domain controllers with NT as BDCs for the original domain.

5. Move server computer accounts into the original domain.

6. Move client computer accounts into the original domain.

Restoring User Accounts without a Reserved

Backup Domain Controller

Because not everyone is perfect and some people like to play golf in a thunderstorm, here is the procedure to restore your user accounts without a reserved BDC:

1. Pick a server to become the Primary Domain Controller (PDC) for the restored domain. Reinstall NT Server on this server.

2. Restore the last tape backup of the PDC onto this server, including the Registry.


3. Verify that this computer comes online as the PDC of the original domain.

4. Repeat these steps with the other domain controllers.

5. Move server computer accounts into the original domain.

6. Move client computer accounts into the original domain.

Exam Essentials

Know what two tools to use when trying to restore a failed migration.The best two tools for this are Windows Backup and the Recovery Console.

Know the best practice for recovering user accounts. Take an NT BDC, synchronize it with its PDC, and take it offline. If this is not pos-sible, make sure to have current backup copies readily available.

Know how to restore network services. Although the best means of restoring network services may be debated in real life, the best solu-tion in terms of the exam is to restore the services from tape backup.


authoritative restore Restore in which specific data or objects are marked as authoritative. These authoritative objects will take prece-dence when the next domain controller synchronization occurs.

the System State Critical Windows 2000 data that contains the Active Directory, boot files, COM+ Class Registration Database, Registry, and Sysvol.

�Perform post-migration tasks.

Even though the migration has been successfully completed, or at least mostly completed, there are still a few details that must be


taken care of. This objective covers those last few tasks that must be finished in order to have a truly complete and successful migration to Windows 2000.

The tasks include examining the Access Control Lists (ACLs) used by Windows 2000—especially the Discretionary Access Control List (DACL) and its impact on network security during and after the migration. From there, you need to back up source domains, decom-mission source domains and re-deploy domain controllers, verify new functionality, and look at removing the SIDHistory attribute from objects.


Not all post-migration tasks are critical. You could, for instance, leave the SIDHistory and conceivably have no problems. Other tasks, such as verifying object migrations and network services functional-ity, are critical. The post-migration tasks listed in this objective are critical. (They are not listed in the order they should be performed.)

Redefining DACLs

Discretionary Access Control Lists (DACLs) are part of the Secu-rity Descriptor attached to every object in Windows 2000. The Security Descriptor is the set of information attached to an object that describes all of the security properties for that object. The DACL portion of the Security Descriptor contains the lists of users and groups that have been granted access to the object and the per-missions assigned to them. The other part of the Security Descrip-tor is the System Access Control List (SACL). The SACL contains the information that controls the security auditing for the object.

To understand why the DACLs are important when performing a migration, you need to know some of the things that DACLs do and how those are affected by the transition to a new domain.


Security Identifiers

A security identifier (SID) is a 128-bit number that uniquely identifies an object within a domain, such as a user, a group, or a file. The oper-ating system uses this 128-bit number as a handle to manipulate the object. Windows 2000 uses these handles to decide whether or not it should give you access to a file, folder, printer, or other resource on your computer or network. Windows NT used SIDs in exactly the same way. So if you are migrating away from NT and toward Win-dows 2000, your resources already have SIDs assigned to them, and those SIDs keep track of the permissions to the resources on the network.

SIDs are considered unique because the authority issuing the SID never reuses a number if an account is deleted, and it never issues the same number twice. A SID consists of a hierarchy of information within that 128-bit number. An example of a SID would be S-1-5-21-5184503-1044856909-627647339-512. It is composed of the following:

Revision number The revision number in a SID marks the version of the SID structure. Currently, all Windows NT and Windows 2000 SIDs are using revision 1 of the SID structure.

Identifier authority This value denotes the highest level of authority that can issue SIDs for the current object type. For example, the iden-tifier authority value in a typical account’s SID is 5, which denotes NT Authority.

Subauthorities The list of subauthorities creates the hierarchy of the SID’s structure. The subauthorities include two sections:

Domain Identifier The bulk of the subauthorities portion of the SID is the identifier of the domain and may contain several entries to fully describe the domain’s relationship with the enterprise network.

Relative Identifier (RID) This is the last field in the SID. The RID identifies the individual account or group. This value is assigned by the Flexible Single Master Operations (FSMO) RID Master, and it ensures uniqueness of SIDs throughout the domain.

SIDs are stored in binary format but are converted to string format when they are displayed, such as when they are viewed in the Registry editor.


When viewed in their string format, the structure of the SID is easier to understand. For instance, in binary form, SIDs have the form shown in Figure 4.12. The first three fields are considered the header for the SID; they mostly identify the type and contents of the SID. The identifier authority comes next and will most commonly be 5 for NT Authority, meaning that it was an account created in Windows NT or 2000.

F I G U R E 4 . 1 2 : The structure of a security identifier

The next portion of the SID belongs to the subauthorities. There may be one or more subauthorities listed in the SID. The list of subauthor-ities up to but not including the very last subauthority entry uniquely identifies the domain that issued the SID. The very last subauthority in the list is the Relative Identifier (RID), which uniquely identifies the SID within the domain. No two domains within an enterprise net-work may have the same SID. The combination of these entries makes each SID unique.

The built-in groups and users within Windows 2000 all have the same domain identifier, 32. When you look at the string representation of the Administrators group, for example, you’ll see that the string begins with S-1-5-32-544. The S signifies that the string represents a SID. The 1 is the revision (always the same for Windows NT and 2000), and the 5 denotes NT Authority. The 32 is the number that all built-in groups have in every domain, and the 544 is the RID representing the Administrators group. The built-in groups always have the same SIDs because they are local in nature; that is, they exist only within either the local computer or a single domain. They never interact across domains, so there is no need to keep them unique.

SubauthorityCount Reserved Revision

NumberIdentifierAuthority

Subauthority[1 to N-1]

Subauthority[N]

DomainIdentifier

RelativeIdentifier


The domain value of 32 denotes the Builtin domain, which exists on every Windows NT or Windows 2000 computer and domain. But the Relative Identifier of 544 is unique within the Builtin domain, belong-ing only to the Administrators group. As another example, the global group Domain Admins does interact with other domains and so must be uniquely identified by its SID. The Domain Admins group in cool-company.local has the SID string S-1-5-21-5184503-1044856909-627647339-512. The beginning of the string is the same, S-1-5, and it has the same meaning as in the built-in Administrators group string. The domain identifier for the coolcompany.local domain is 21-5184503-1044856909-627647339. The final number is the RID, 512, and represents the built-in Domain Admins global group.

By combining the revision number, the ID of the assigning authority (the domain controller that issued the SID), and the domain ID with the RID, a new SID is created. In a Windows 2000 domain, the RIDs are created from a pool of numbers controlled by the RID Master, which is one of the five Flexible Single Master Operations (FSMOs). Without a RID Master, you would not be able to create domain-level SIDs in Windows 2000 for long. The RID Master allocates a block of RIDs to each domain controller when they request a block. As the domain controllers issue SIDs for newly created objects in the Active Directory, they use up their block of RIDs. When they run out, they ask the RID Master for a new block of RIDs. The RID Master keeps track of all of the RIDs that have been allocated and never duplicates a block of RIDs. The domain controllers are responsible for keeping track of the SIDs they have issued to ensure that they never duplicate a SID that they have issued.

Because SIDs are unique to the domain in which they were created, when you move a security principal (such as a user or group) from the original domain to a new domain, the SID will be changed. This may seem very academic, but remember that the SID assigned to a security principal is how Windows 2000 determines access. If the SID assigned to your user account changes, you may no longer have access to the resources on the network or even on your local computer. When you migrate users and groups from your source domain to the


new target domain, you are changing the SIDs for all of those accounts. Without some mechanism to preserve the old SID informa-tion, your users won’t be able to access their resources.

Windows 2000 provides that mechanism with the SIDHistory fea-ture. SIDHistory stores the original SID of a security principal when it is moved or copied to the new domain. Windows 2000 understands the SIDHistory feature and will evaluate security access both by the current SID and by the SIDHistory. When you upgrade a domain to Windows 2000, you don’t affect any of the SIDs assigned to objects within the domain. Upgrading maintains the same SIDs because Win-dows 2000 maintains all data and settings during the upgrade process.

Restructuring or migrating requires that you move existing accounts to a new domain. This means that you would have to create new SIDs in the process. Once the users and groups have new SIDs, their resource access may be interrupted if you don’t resolve the issue of assigning new permissions to the new SIDs instead of relying on the SIDHistory feature.

Access Tokens

The next step in understanding the security process is the Security Access Token. An access token is a protected object that contains information regarding a user’s identity and group membership and is used to evaluate a user’s access to secure resources in Windows 2000.

The token is created during the logon process just after the user’s cre-dentials have been authenticated by the domain (or the local com-puter in the case of a local logon) and is attached to the user’s process. Every process you start will have a copy of this token attached to it. This means that every program you start will be able to operate with the same privileges and permissions that your user account has.

Every process has a primary token that defines the security informa-tion for the accounts that started the process. A process may also have an impersonation token that will enable the process to operate under different security credentials.


A number of SIDs are present in a typical access token, including the user’s SID and the SIDs of any groups the user belongs to. These SIDs may be active for use in checking the permissions assigned to the user, or they may be used to check for the Deny Access permission.

Discretionary Access Control Lists

DACLs are extremely important to the authorization process in Win-dows 2000. Authorization is the process of examining an account’s credentials to evaluate its security permissions. A DACL is a portion of the Security Descriptor attached to an object in Windows 2000 that houses the list of permitted users and groups, as well as the per-missions assigned to them. These entries are referred to as Access Control Entries (ACEs). An ACE is a single entry within a DACL that contains a SID of a user or group account and the associated permission assigned to that account.

DACLs are made up of a list of ACEs. The ACEs have a default order in Windows 2000. The preferred order of the ACEs within a DACL is called the canonical order. For Windows 2000, the canonical order of ACEs is as follows:

Explicit ACEs All explicitly assigned Access Control Entries are placed in a group at the head of the list before the inherited ACEs.

Deny ACEs Within any group of ACEs, the denied permission ACEs are listed before the allowed permission ACEs.

Inherited ACEs These are the permissions that have flowed down the directory structure from parent objects. They are listed in order of inheritance, beginning with ACEs acquired from the object’s parent, then from the grandparent, and so on.

ACEs are created when you assign permissions to an object in Windows 2000. Figure 4.13 shows the Security tab of a folder’s Properties sheet where you would change the default permissions for the folder. These entries would then become the explicit entries in the DACL for the selected folder. Any Deny permissions you set in this dialog will be listed ahead of the Permit entries in the DACL. This enables Windows 2000 to always evaluate the Deny permissions before the Permit permissions.


F I G U R E 4 . 1 3 : The Security tab enables you to alter the DACL for an object in Windows 2000.

Changes to the DACL in a Migration

When you move resources or security principals during a migration, there will necessarily be some changes to the DACLs of the resources. When a security principal is moved from one domain to another, its SID will change to reflect that move, and the old SID will be stored in the SIDHistory attribute. This assumes that you are moving the secu-rity principal to a Windows 2000 domain running in native mode, because the SIDHistory attribute is available only in Active Directory.

The SIDHistory attribute will help maintain resource access during your migration, but you should consider reassigning the permissions to the new accounts once the migration is complete. The DACLs for all of your resources will still reference the original SID of every secu-rity principal that you had assigned in the old environment. This brings up a few possible options to consider.


NOTE These first scenarios assume that the SIDHistory attribute is not available, as an illustration of the function it fills. You should be aware of these scenarios in case your migration requires that you not depend on the SIDHistory attribute to maintain resource access.

ADDING THE NEW SID FOR A USER

The first solution to the change of SIDs in a migration would be to reassign the permissions for all of the resources that a single user needs to the new SID for that user. Effectively, you are bypassing good administrative practice and assigning permissions directly to users instead. This fix is very time-consuming because the administrators working on the problem would have to touch every resource. This fix is undesirable for the following reasons:

� Restructures and migrations often stretch out over a long period of time. Because of this, there might be new resources created for any given global group that is migrated, so reassigning permissions would have to continue over the entire duration of the project.

� Adding the SID for a single user is a problem because that user may change job functions during the migration period and no longer need the resource. In that case, you would have to assign the per-missions yet again. It is much easier to use global and local groups to assign permissions, because if the user changed jobs, you would simply have to change the user’s group memberships.

MOVING THE GROUP

Groups can be moved in Windows 2000. You could consider simply moving the group that contains your users to the target domain. The problem with this method as a solution to the SID problem with user accounts is that moving the group causes it to have a new SID as well. So in addition to your user accounts having new SIDs and being unable to access existing resources, the groups they belong to also have new SIDs and are unable to access those same resources.

When you move a group to another domain in Windows 2000, the group will receive a new SID. You would then have to reassign


permissions to the new group SID to reflect the changed location of the group and its members, which results in quite a lot of work.

USING A PARALLEL GROUP

If you are cloning accounts during your migration, you might use a parallel group as a solution. In this scenario, you would create a group in the new domain with the same name and properties as the old group and then assign permissions to the new group for any exist-ing resources the group needs access to.

This method does permit access to the resources, and it does enable you to move the user accounts incrementally. However, it also requires that you continue the reassignment of permissions through-out the migration as user accounts are moved or cloned. The benefits here are that the old group is still functional during the migration and that you could decide to roll back the migration and still have all of the original groups and permissions.

HOW SIDHISTORY RESOLVES THIS PROBLEM

In most cases, these scenarios are unnecessary because of the intro-duction of the SIDHistory attribute in Windows 2000. SIDHistory stores the original SID of the security principal when it is moved or copied to a new location. This attribute will become a part of the access token along with the current SID, to be evaluated when a user requests access to a resource. The SIDHistory attribute is available only in Active Directory.

When you clone or move a security principal using a Windows 2000 migration utility, the tool will copy the existing SID to the SIDHistory attribute. This process is used for both user and group accounts.

When you log on to an Active Directory domain running in native mode, the system checks your current SID and your SIDHistory and copies them both to the access token when you are authenticated. The SIDHistory attribute is seen as a normal SID by pre–Windows 2000 computers and can be used to grant user access to a resource even on Windows NT computers that don’t understand the SIDHistory attribute.


There is one drawback to this scenario, however, and that involves the way the Windows NT 3.51 and earlier systems evaluate group member-ship. When you log on to an Active Directory domain using an NT 3.51 computer, the computer will retrieve only group information relative to the local domain or to accounts located on the local computer. Because of this, the computer won’t see the SID contained in the SIDHistory attribute as pertaining to the user account. NT 3.51 cannot see local groups from other domains or retrieve universal group information stored in other domains. This means that you may not have full access to resources located in other domains when logging on to the domain from a Windows NT 3.51 computer.

Backing up source domains

In many cases, you won’t have to back up the data on your servers in the source domain, since you can upgrade them and then move them to the new domain. However, it’s always a good idea to have current backups of your data before performing a significant change to any server. And installing Windows 2000 definitely qualifies as a signifi-cant change.

Windows 2000 provides a useful tool for backing up data both locally and remotely. Windows Backup can be used in the following ways in your Windows 2000 network:

Local computer backup You can use Windows Backup to back up and restore data on the local computer using a tape drive or other storage medium that is also located on your local computer. This method is good because it generates no additional traffic on the net-work. It’s bad because your users will be responsible for backing up their own data.

Remote backup In a remote backup, the backup operation is per-formed from a single server (or possibly multiple servers). The Win-dows Backup program is used to back up or restore data from shared folders on various computers across the network. This task can be made easier by implementing the Distributed File System (Dfs), since the Backup program would only have to connect to one shared folder in order to back up all the network data.


Server-only backup In this scenario, users are instructed to store data only in a shared location on a server. Then, every night (or what-ever regular period you decide on) a backup is performed of the server’s data. This method has the benefit that all of the backup work is performed locally on each server, protecting all data without added network traffic.

Server and computer backup This last type of backup operation is a combination of the previous types. In this type, the server data is backed up locally, and any user data located on workstations is backed up across the network.

Obviously, there are many ways that backups can be performed, depend-ing on the needs of your environment. There is no single “right way” to perform the backup of domain data prior to decommissioning the old domains after a migration to Windows 2000. But local backups are faster and generate no additional network traffic.

Security is another consideration when planning for the backup of domain data. Such data will very likely include sensitive information from your original domain environment that must be protected dur-ing the transition from one domain to another. Implement a plan for securing the data media while migrating between the domains.

Before decommissioning the servers in the source domain and after backing up the data from those servers, try to restore some data from each of the tapes to ensure that the tapes aren’t corrupted. No backup to tape should ever be considered good until you have successfully restored data from the tapes.

Decommissioning source domains and re-deploying

domain controllers

Once all accounts and data have been migrated from the source domains to the target domain, you’re ready to get rid of the old domains. There are a couple of possible scenarios to consider for decommissioning your old domains. In the first, you would have already moved your member servers and workstations to the new domains, and all that are left to tear down are the domain controllers. The second scenario occurs


when you have created a parallel domain structure and cloned all of the security principals to the new environment and all of the servers are still in the original domain.

Many organizations will find that this last step in a migration actually involves merely turning off the old domain controllers. This is the eas-iest decommissioning process of all.

Decommissioning Domain Controllers

If your migration plans included moving the client workstations and member servers to the new Active Directory domain locations, then the only servers left in your source domain will be the domain controllers. This scenario is easier to handle for decommissioning purposes, since all you have to do is reinstall the computers with Windows 2000 and use them for the new domains.

Many organizations will choose to upgrade their network server hard-ware at the same time that they are upgrading the software. If this is the case, then you would use the new servers to provide the domain control-lers and member servers in the new domains. Otherwise, you would want to reclaim these servers to take over the member server roles in the new domain.

To decommission the old domain, format the hard disks and install Windows 2000 Server on the remaining servers. They can now be used for member servers, or you can run dcpromo.exe to promote them to become additional domain controllers. If you are replacing the servers with newer models, then you will probably be sending the old machines to surplus once the new environment is fully configured and tested, or perhaps you will be using some of the old machines for testing or other purposes in the network.

Decommissioning Domains

In the case where your migration called for creating a parallel struc-ture to use for the target domains, you may have installed new com-puters for all of the servers in the new environment and possibly for the desktop computers as well. In this scenario, the resources have been copied to the new environment, and all of the users are logging


on to the new domains after having been cloned from the source domains. All that remains are the old servers and possibly the desktop computers.

When you have thoroughly tested the new Active Directory environ-ment and are sure that everything is running as planned, you can tear down the old environment. If the servers are being sent to surplus, make certain the data is safely removed from the drives first. A simple partitioning and formatting will suffice in most cases, though the most sensitive data should be erased using a utility that completely destroys all traces of the data from the disks.

Verifying success of object migrations

The biggest measure of success for your deployment will be after everything is completed. If all of your users can access their resources, and no one is reporting logon or access problems, you have done well.

Verifying object migrations is a critical but obvious step in ensuring that everyone comes out okay. If you are performing incremental migrations, run checks after every batch of objects you move. Make sure at least one user from the migrated group can log on. Make sure they can access resources they need. These steps may seem a bit triv-ial, but it’s better to detect a problem early than after everything is completed.

Verifying functionality of network services

The single most common network protocol today is TCP/IP. Its pop-ularity is most likely due to the Internet, but it’s also because TCP/IP is an industry-standard suite of protocols designed to perform specific tasks. This means that if you have Macs and NetWare and Unix com-puters on your network, your Windows 2000 Professional computer can easily communicate with all of them using TCP/IP. This protocol is also popular with support people because it has so many trouble-shooting tools built in.


Ping

The Packet Internet Groper (Ping) is the most basic test of network connectivity over TCP/IP. What Ping does for you is bounce a series of packets off a remote host. You’re essentially just saying “Hello?” four times and (you hope) getting a response each time. The basic syn-tax is ping www.host.com or ping 10.1.0.44.

Getting a response when pinging by IP address means that your net-work card is installed correctly, the driver is working, the TCP/IP pro-tocol is working, the other computer is working, and everything in between is working. That’s quite a lot of information for just one small command! When you ping by hostname, you get all the previ-ous information, plus you know that your hostname resolution is working.

You can also ping the address 127.0.0.1. This address is reserved for the local host (the local computer) and is a loop-back diagnostic test of your installed TCP/IP software. Successfully pinging the local host verifies that TCP/IP is correctly installed on the local computer.

Hostname

The Hostname utility returns the hostname of the local computer. This utility can be helpful when you aren’t sure what the hostname is.

IPConfig

IPConfig is right up there with Ping when it comes to valuable TCP/IP utilities. This tool enables you to view some or all of your TCP/IP configuration, as the name might imply. To use it, type ipconfig at the command prompt to receive your IP address, subnet mask, and default gateway. If you type ipconfig /all, you will see a listing of every TCP/IP configuration for every interface on your computer.

IPConfig can also be used to release and renew IP addresses acquired through DHCP. The commands for this are ipconfig /release and ipconfig /renew.


A new feature of IPConfig in Windows 2000 allows you to renew your DNS registrations. This feature can be very useful when you are trying to add computers to a domain and you are unable to locate the domain controllers. Use the ipconfig /registerdns switch to add the dynamic registration for the computer to the DNS server. Name resolution for Windows 2000 domain controllers depends on the presence of the Service (SRV) records in dynamic DNS servers. These SRV records will be renewed with the ipconfig /registerdns switch. However, this command won’t help if the problem is caused by a bad A record for a host.

ARP

The ARP utility views and modifies the Address Resolution Protocol (ARP) cache. TCP/IP uses the ARP protocol to resolve an IP address to a unique hardware address or media access control (MAC) address.

At the Application layer, the user types in a Uniform Resource Loca-tor (URL) to browse a favorite Web site. The user’s computer is con-figured to use a certain Domain Name System (DNS) server that is responsible for resolving the name in the URL to an IP address. Then TCP/IP uses ARP to resolve that IP address to a unique physical address. Every network card has a unique hexadecimal number assigned to it when it is manufactured. That’s the physical address or MAC address of the card.

When ARP resolves an IP address to a unique hardware address, it stores the resolution in its cache. One thing you can do to improve the connection speed to a server that you use frequently is to make a static entry in the ARP cache.

Tracert

The Trace Route (Tracert) utility is very much like Ping in that it bounces several packets of information off a remote computer. But Tracert does more than that. It also shows a response from every router that the packets go through on their way to the remote computer.


This can be especially useful when dealing with communications issues with a remote host that is very far away (as in many routers away). TCP/IP uses a mechanism called a Time To Live (TTL) to determine how long a packet of data should be allowed on the net-work. If packets weren’t dropped after a set period of time, they would keep roaming the Internet—including packets from 20 years ago or more. The TTL is decremented automatically by at least one at each and every router it passes through, also called a hop. If a packet is forced to wait in a router due to network congestion, its TTL is dec-remented by one for each second the packet stays in the router.

Tracert can reveal when the default TTL isn’t high enough to allow for network congestion on the way to the remote host. The TTL set-ting can be adjusted in Windows 2000 through the Registry at this location:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\

Services\Tcpip\Parameters

Value name: DefaultTTL

The maximum setting for this value is 255.

Netdiag

Netdiag is a utility that helps isolate networking and connectivity prob-lems by performing a series of tests to determine the state of your net-work client and whether it is functional. These tests and the key network status information they expose give you a more direct means of identify-ing and isolating network problems. Also, this tool does not require parameters or switches to be specified. This lets you focus on analyzing the output instead of worrying about tool usage.

Netdiag diagnoses network problems by checking all aspects of a host computer’s network configuration and connections. Beyond trouble-shooting TCP/IP issues, it also examines a host computer’s Internet-work Packet Exchange (IPX) and NetWare configurations.


Run Netdiag whenever a computer is having network problems. The utility tries to diagnose the problem and can even flag problem areas for closer inspection. Netdiag performs its tests by examining .DLL files, output from other tools, and the system Registry to find poten-tial problem spots. It checks to see which network services or func-tions are enabled and then runs up to 25 network configuration tests, depending on which services are running on the computer.

Netdiag gives you everything ipconfig /all gives you, and then some. For more information about Netdiag, see Windows 2000 Sup-port Tools Help.

PathPing

The PathPing tool is a route-tracing tool that combines features of Ping and Tracert with additional information that neither of those tools provides. PathPing sends packets to each router on the way to a final destination over a period of time and then computes results based on the packets returned from each hop. Since PathPing shows the degree of packet loss at any given router or link, you can pinpoint which routers or links might be causing network problems. A number of switches are available for custom testing. For more information about PathPing, see Windows 2000 Support Tools Help.

Network Monitor

Windows 2000 Network Monitor can be a useful tool for trouble-shooting network performance. The only limitation of Network Monitor is that it cannot capture all traffic on the network, only traf-fic sent to or from the computer on which it is running. To capture all traffic, you would need a third-party network monitor or Microsoft’s Systems Management Server (SMS).

Network Monitor is best suited for capturing and analyzing network packets. This helps in detecting network cards that are producing excessive network traffic. Often when network adapters fail, they become “chatty” cards, broadcasting excessively. This can cause the network to flood and reduce production.


Removing SIDHistory from objects

There may be some cases in a migration where you will be moving security principals from one domain to another and want to prevent them from having any access to the previous domain environment. SIDHistory would normally keep a list of the security principal’s past SIDs in order to facilitate resource access during the migration. This means that the security principals would have their old permis-sions and rights in the source domain as well as any new permissions and rights granted in the new domain.

To remove the SIDHistory list from a security principal, you will use the Active Directory Service Interfaces Editor, ADSI Edit. ADSI Edit gives you direct access to the attributes of any object in Active Directory.

Reassigning Permissions

In the preceding section, there were some scenarios that gave possible solutions to reassigning permissions. Most of these solutions weren’t necessary because of the SIDHistory attribute in Active Directory accounts. But there is one case that does require the redefinition of the DACLs. When you decommission your old domains at the end of the migration process, all of the SIDs from those old domains will cease to be valid. If the domain cannot be validated, the SID cannot be val-idated for access.

When the old domains are decommissioned, you will want to reassign permissions for the resources located in your network.

REASSIGNING FILE PERMISSIONS

The bottom section of the Security tab of the file’s Properties dialog controls the kind of access you get. This dialog is shown in Figure 4.14.


F I G U R E 4 . 1 4 : The Security tab of a file’s Properties sheets lets you adjust the file permissions.

By default, it’s Full Control for the Everyone group, but several other options are available: Modify, Read & Execute, List Folder Contents, Read, and Write. Full Control can be modified by special accesses.

If the five levels of access are a bit coarse for your needs, you can fine-tune someone’s access with what Microsoft calls special access. To modify the special access permissions for a file or folder, on the Secu-rity tab for that object click the Advanced button to open the Access Control Settings dialog shown in Figure 4.15. This dialog is used to directly set the special access for the object, as well as set the auditing and ownership. You can add or remove accounts and permissions on this dialog.


F I G U R E 4 . 1 5 : The Access Control Settings dialog

To view the special access permissions, click the account whose permis-sions you want to modify, then click the View/Edit button. Now you have more options.

These permissions have changed quite a bit from previous versions of NT where only six permissions made up the standard permissions: Read, Write, Execute, Delete, Take Ownership, and Change Permis-sions. The new levels of granularity make security a more difficult topic to learn in Windows 2000, but they give a skilled administrator much finer control over how files and folders can be accessed.

To prevent someone from accessing a file or folder, you have two choices. The first—and usually the best—way is to simply not grant the person access to the file or folder. This means that you don’t add their account to the list of permissions. Not having explicit permis-sion is like having No Access; either way, you don’t get in. The second method is to add the person’s account to the permissions list but check Deny for each permission. This creates an explicit No Access-type permission.


REASSIGNING FOLDER PERMISSIONS

When your migration is in progress, you will very likely still have per-missions for resources assigned to user and group accounts from the old domains. Figure 4.16 shows just such a scenario for a test folder on the Sea-1 domain controller in coolcompany.local, where the Everyone group is defined, along with three user accounts from the old Seattle domain.

F I G U R E 4 . 1 6 : The Security tab for the Test folder in cool-company.local

When the trusts between the new coolcompany.local domain and the old Seattle domain are removed, the appearance of the accounts will change. For any accounts that exist solely in the source domain (the domain that was decommissioned), the Security tab will be unable to resolve the display names. Instead, the accounts will be listed by their SIDs, as shown in Figure 4.17. These accounts should be removed once you are certain that the old domains are no longer needed.


F I G U R E 4 . 1 7 : The Security tab showing some orphaned accounts

The only real difference between the Permissions dialog for a folder and the Permissions dialog for a file is the List Folder Contents per-mission. Of course, there are some other differences in how folder permissions work, but they are hidden for the most part in the Advanced Security options. The Security tab for folders works just like the Security tab for files.

One option you should be aware of on the Security tab is the check box at the bottom of the tab, Allow Inheritable Permissions From Parent To Propagate To This Object. What it’s trying to say is that if this box is checked (which it is by default), Windows 2000 security will propagate any permission changes from the parent container, or the folder that this folder is in, to this folder and all its contents. This enables you to prevent your permissions from being overwritten by someone else changing permissions at a higher folder level.


Clicking the Advanced button brings up the Access Control Set-tings dialog for the folder. At first glance, this appears to be the same dialog as for Advanced settings on file permissions, and it does work the same way. The difference is in the check box at the bottom of the dialog. Checking the option to reset permissions on all child objects will deliberately overwrite any existing permis-sions on subfolders and files.

REASSIGNING PRINTER PERMISSIONS

By default, only administrators have full access to the printer. Only those with Manage Printers permission can pause or resume a printer or change its permissions. Those who have only print access can administer only their own documents.

NOTE The default print permissions in Windows 2000 are as fol-lows: Administrators and Power Users have Full Control permission; the Everyone group has Print permission; Creator Owner (the person who submits a job) has Manage Documents permission for the job they have submitted. If the printer is located on a domain controller, the Print Operators and Server Operators groups will also have Full Control.

In the Printer Properties dialog, click the Security tab to see the dialog shown in Figure 4.18.


F I G U R E 4 . 1 8 : The Security tab of the Printer Properties sheet

The Security tab lists the accounts for which some kind of printer access has been set up. From here, you can change the level of access that each user group has. Printing permissions are usually granted to groups, not individual users. Therefore, granting a user a permission means making that user a member of a group with the printing per-mission you want that user to have.

The default permission levels are as follows:

Print Members of the user group can print documents and manage their own documents.

Manage Documents Members can control document settings and pause, resume, restart, and delete documents lined up for printing, including documents submitted by others.

Manage Printers Members can do anything with the printer—print; control document settings; pause, resume, and delete documents and printers; change the printing order of documents; and change printer properties and permissions.


To change someone’s level of permission for the printer, simply check the box beside the type of permission you want to grant. In NT 4, you could assign the No Access permission to a user or group if you really wanted to keep them out of your printer. Windows 2000 no longer has a separate No Access permission. Generally, if you want to keep the user out of your printer, simply add that person to the list of groups and users but uncheck all of the boxes. If you do not grant per-mission, it’s the same thing as saying No Access. The problem is, they may still have permission through a group. In that case, if you really want to keep someone out of your printer, you could assign Deny per-missions for each of the permission levels.


For this objective, there is only one necessary procedure. Removing the SIDHistory may be necessary for security reasons. Removing SIDHistory can also decrease the size of access tokens, which will speed up logon and resource access.

Removing the SIDHistory Attribute

To remove the SIDHistory attribute for an object, follow thisprocedure:

1. Open ADSI Edit from the Windows 2000 Support Tools group on the Start menu.

2. Browse down to the object you want to change in Active Directory. For instance, to remove the SIDHistory from a user object, expand the Domain NC (Naming Context) node in the left pane and browse to the container where the user account resides. In the Users container (or OU where the account is), find the user object.

3. Right-click the object you wish to modify, and select Properties from the context menu.

4. Click the Down arrow on the Select A Property to view a drop-down list and select SIDHistory. The current SIDHistory list will


be displayed. If the account has been moved more than once, there will be more than one SID listed in the SIDHistory list.

5. Highlight the SIDs to be removed, and click the Remove button. Click OK to save the changes and close the dialog.

Exam Essentials

Know what happens to SIDs during a migration. Since the object is being placed in a new domain, a new security identifier will be cre-ated for the object. The old SID from the previous domain will be retained as SIDHistory as part of the object’s properties.

Know how to decommission old domains. After all workstations and member servers are out of the domain, you can bring down the last domain controller(s), and decommission the old domain. For security purposes, you may want to format the hard drives of any remaining domain controllers.

Know what tools are available to test network connectivity. For testing TCP/IP connectivity, tools include Ping, Hostname, IPConfig, ARP, Tracert, Netdiag, and PathPing.


Access Control Entry (ACE) An entry in an object’s DACL that contains user identifiers and their corresponding permissions to that object.

access token Process associated with a user account when the user logs on. Determines what levels of permissions the user has, based on identity and group memberships.

Address Resolution Protocol (ARP) Protocol used by TCP/IP to resolve IP addresses to MAC addresses. Also a Windows command-line utility used to check the ARP cache.


authorization Examining an object’s security credentials to see if it has proper access to a resource.

canonical order The preferred order of ACEs within a DACL.

Discretionary Access Control List (DACL) A portion of the Security Descriptor attached to an object in Windows 2000 that houses the list of permitted users and groups, as well as the permissions assigned to them. (It holds the ACEs.)

Hostname Command-line TCP/IP utility that will return the com-puter’s hostname.

IPConfig TCP/IP utility that displays current protocol configura-tion information, such as IP address, subnet mask, default gateway, DNS server address, and others.

Netdiag Windows 2000 network diagnostic utility.

PathPing Windows 2000 TCP/IP utility that combines the features of Ping and Tracert, along with providing additional information.

Packet Internet Groper (Ping) TCP/IP testing command that sends packets to a destination host to ensure that the remote computer is online and all connectivity is fine.

System Access Control List (SACL) The SACL contains the infor-mation that controls the security auditing for the object.

Systems Management Server (SMS) Microsoft’s ultimate network management software. It offers features such as software deployment, advanced auditing and network monitoring, and remote system control.

Tracert Short for “trace route,” Tracert is a TCP/IP utility that traces the route of a packet from the source computer to the desti-nation host.

Chapter

5

Troubleshooting


�


(pages 255 – 272)�

Resolve hardware failures.�

Resolve third-party tool issues.�

Resolve issues associated with rights necessary for upgrade.

�

Resolve domain name issues.

�

Troubleshoot account issues for all types

of migrations.

(pages 272 – 290)�

Resolve system policy translation issues.�

Resolve logon script failures.�

Resolve issues associated with duplicate accounts that have different SIDs.

�

Resolve issues associated with user rights.

�

Troubleshoot access issues for all types

of migrations.

(pages 291 – 309)�

Resolve client computer connectivity issues.�

Resolve permission issues involving NTFS.�

Resolve issues associated with the inaccessibility and absence of shared resources.

�

Resolve authentication issues.�

Resolve trust relationship and inappropriate access issues.

�

Troubleshoot network services problems for all

types of migrations.

(pages 309 – 337)�

Resolve name resolution issues.�

Resolve remote access permissions failures and logon failures.

�

Resolve file and directory replication issues.�

Resolve network service issues, including DHCP, WINS, and DNS.

�

Troubleshoot application failures for all types

of migrations.

(pages 337 – 345)�

Resolve incompatibility issues.�

Resolve issues associated with hard-coded account information in third-party applications.

�

Troubleshoot tool issues for domain

restructures. Considerations include ADMT,

ClonePrincipal, NETDOM, MoveTree, and

Windows 2000 Resource Kit tools.

(pages 345 – 348)

S

o far in this book you’ve been learning how to handle things when they go right, and how to ensure that they go right. Now you will focus on troubleshooting techniques to use when things go wrong. In this chapter, you will learn about common problems that can occur while upgrading a domain to Windows 2000 and, more important, what to do about those problems.

This chapter is a troubleshooter’s dream. It starts with generic domain upgrade troubleshooting tips. From there, account issues, access issues, network services problems, application failures, and migration tools are all covered.

Troubleshooting typically gives people problems on Microsoft exams. This is because Microsoft exams are very situational. Many questions will throw you into the middle of a migration, or a failed one, and make you figure out where to go next. This has proven to be an effective way of testing your knowledge. It’s also speculated to cause ulcers.

In real life, troubleshooting is often common sense. To diagnose the problem, narrow down the scope of what could be causing it. Obviously, knowing the product you are working with, and the tools you have available, aids in this process considerably.

�


I

deally, domain upgrades will not fail, and your knowledge in this area will remain covered with cobwebs. The problem is, things happen. You need to be able to correct anything that fails during the migration. This topic is also important for test purposes. You


256

can expect questions regarding failed domain upgrades at various stages of the upgrade process, and to be asked how to proceed.


Most of the troubleshooting you do with Windows NT/2000 will involve either faulty hardware or misconfigured hardware. The first section will cover most of the problems you might see when upgrad-ing a server to Windows 2000. But don’t dismiss the other sections dealing with third-party software drivers or tools or configuration issues like permissions and domain-level problems that can occur.

Using the Readiness Analyzer

Many of the problems you’ll encounter during the setup of Win-dows 2000 will be related to hardware in some way. Typically, these will be issues that can be avoided by ensuring that your hard-ware is compatible with Windows 2000 before you begin the installation. One tool that Microsoft provides to help with this process is the Readiness Analyzer, which can be accessed a couple of different ways. The Readiness Analyzer is part of the

Winnt32.exe

Setup program for Windows 2000. It will run auto-matically when you start the setup process within an earlier ver-sion of Windows, or you can modify the

Winnt32.exe

program to run only the Readiness Analyzer by using the

winnt32 /checkupgradeonly

command. If you run the setup command and it does not detect any problems, you won’t even know it had run.

The Readiness Analyzer can also be downloaded as a separate stand-alone program (

chkupgrd.exe

) from Microsoft’s Web site at

www.microsoft.com/WINDOWS2000/downloads/deployment/readiness/default.asp

. The Readiness Analyzer can perform a fairly thorough check of your computer for both hardware and software compatibility issues. This program is able to notify you of possible compatibility issues and, in many cases, recommend a course of action that will resolve the conflict either before or after the upgrade to Windows 2000.

Chapter 5 �

Troubleshooting

257

Once the Readiness Analyzer has completed its scan of your computer, it displays a brief summary of its findings, as shown in Figure 5.1. A more complete report will be placed in your

Winnt

folder (or whatever folder the operating system is installed in).

F I G U R E 5 . 1 :

The Readiness Analyzer displays a brief report.

The report generated by the Readiness Analyzer is entitled either

Upgrade.txt

(on Windows 9

x

) or

Winnt32.log

(on Windows NT) and is a plain text ASCII file located in the root of your operating system folders. In the report, you would find sections for hard-ware, software, and any general compatibility issues.

In most cases, the Readiness Analyzer is completely accurate in its reports and is very helpful in determining what needs to be updated prior to installing Windows 2000. Occasionally, you will see ambiguities in reporting, but that may be caused by specific software configurations.

Resolving hardware issues

Early in the lifespan of any operating system, the main issue seems to be driver support for your hardware. Later on, the issue is whether


258

the operating system can support the latest hardware innovations. Windows 2000

should

be easier to support over the long term for a variety of reasons, including Plug and Play, a unified driver model, and better diagnostics within the operating system.

The best way to avoid hardware problems is to select a computer system from the Hardware Compatibility List (HCL). Microsoft goes to great lengths to test computer systems that are submitted by manufacturers to ensure that the hardware will be fully com-patible with the operating system. The testing includes setup and a barrage of automated procedures designed to prove that all areas of the operating system would be correctly supported.

If your computer system is not on the HCL, then you should check with the manufacturer’s Web site to see if they offer driver and technical support for Windows 2000. If they do, then the system will most probably work fine with Windows 2000. If the manu-facturer isn’t willing to support Windows 2000 on their computer system, then you can assume there is cause for the lack of support. This would be a good reason to choose another computer system instead.

The HCL for Windows 2000 has substantially changed from what Microsoft used in the past. Microsoft has created a dynamic Web page that enables you to search for computer systems, hardware devices, and software titles that are compatible with Windows 2000. The addition of the software category is especially useful. The ability to enter the name of the device or computer system and search the HCL is particularly nice, since the HCL has grown so large that it would occupy hundreds of pages.

If you encounter problems while upgrading from Windows 9

x

or NT, double-check the HCL. If the computer is included in the HCL, then the problem is most likely either a faulty piece of hard-ware or something configured incorrectly. If your hardware isn’t on the HCL, you will need to contact the manufacturer for more information before proceeding.

Chapter 5 �

Troubleshooting

259

NOTE

Always check the manufacturer’s Web site for the most

up-to-date drivers for your hardware.

Troubleshooting Disk Problems

Disk problems are something you can expect to encounter during setup. They’re fairly common if you’ve changed the hardware con-figuration of the computer prior to the upgrade to Windows 2000. If you are working with a server, the hard disks most likely use the Small Computer System Interface (SCSI)-type disks and controllers. In most cases, Windows 2000 Setup troubleshooting issues on SCSI-based computers involve termination problems. But there are other issues as well to be aware of. Check to see if the BIOS of the SCSI controller is activated. If not, Setup may be unable to find the drive on which to install Windows 2000.

A low-level format that is incorrect for the current drive geometry is a possible cause of file corruption, drives not being recognized by Setup, and system crashes. If you are installing a new SCSI drive or changing to a new make or model of SCSI controller, you should perform a low-level format of the drive to ensure that the drive geometry will line up correctly.

If you have multiple SCSI controllers in the computer, check to see if they each have an active BIOS. If so, they may be competing for Int13 calls. This means that the wrong controller may be trying to boot the computer and therefore preventing the right controller from doing its job.

Of course, you have to assume that the computer was able to boot a previous operating system during the upgrade process, so many of these issues are moot. Still, if you are using SCSI devices, check your termination and the controller settings. If you are not using SCSI, then you’re probably using drives that use the Integrated Device Electronics (IDE) bus type.


260

Most IDE systems are relatively trouble-free. One possible issue is the use of Ultra DMA/66 drives and unsupported drive controllers. If you find that the Windows 2000 Setup program does not recognize your drive, contact the manufacturer of your motherboard or hard-drive controller for a new driver.

Troubleshooting Display Problems

Display problems in Windows 2000 usually involve the driver. In some rare cases, the problem resides in the chipset used on the display adapter, but even then the problem can usually be overcome with a new video driver. One serious issue that could be a problem is that the drivers used in Windows 2000 are very different from the drivers used in Windows NT 4. In fact, there are some cases documented in the Knowledge Base where using an older driver (such as a driver for NT 4) can cause Windows 2000 to blue-screen.

The Setup program for Windows 2000 tries to help with this problem by running in a plain, 16-color, 640

×

480 resolution. Nearly every adapter on the market can handle this setting, so display problems won’t normally cause you any grief during setup.

The one area where some real problems have been reported with Windows 2000 displays is in the use of a second monitor. Win-dows 2000 supports multiple monitors, but a number of display adapters cannot currently be used for the second display adapter. Most of the problems have symptoms similar to using an incorrect resolution or refresh rate, such as a distorted picture, portions of the image appearing as black blocks, or the entire image being dis-torted and appearing slightly brown in color. Unfortunately, the only solution for most of these problems is to use a different dis-play adapter for the second monitor.

Chapter 5 �

Troubleshooting

261

Any time you find that you cannot see your screen after changing either the driver or the resolution, you should use the advanced startup features of Windows 2000 to choose Safe mode. Safe mode uses a standard VGA driver and allows you to change your display back to a driver that works.

Troubleshooting Memory Problems

Windows 2000 can be very sensitive to memory problems. Unfortu-nately, the symptoms of bad memory can vary radically. Everything from blue screens to random crashes, to hanging, to individual programs crashing can be tied to bad memory.

One trick used to diagnose blue screens caused by bad memory is to carefully record the memory address of the module that caused the blue screen. If the address is the same each time the error occurs, you probably have some bad RAM causing the problem. It’s normal for programs to load into memory at different addresses from time to time. If the driver or program causes the error, the memory address should vary. If the address stays exactly the same for each error, then the memory at that address is probably the culprit.

If you suspect that a problem with Windows 2000 is being caused by bad memory, there are some things you can do to try to isolate the prob-lem. Try swapping memory modules in the slots on the motherboard. Sometimes you can move the problem to a different address. Many of the error messages that you will be troubleshooting will give you an address in memory where the error occurred. If you move the memory modules to different slots on the motherboard, and the address of the error moves, you know that you have a bad memory module.

Another technique used with Windows NT 4 was to add the switch

/maxmem:

x

to the

boot.ini

file. The switch told Windows NT 4 to boot with only a portion of its memory. This technique should work


262

equally well with Windows 2000. However, don’t try to limit the memory to something that Windows 2000 will not operate with. The

/maxmem

switch limits memory used to only the bottom portion of memory. If the bad memory exists in the upper memory range, the switch will block out the bad memory and prevent the error from occur-ring. If this switch doesn’t resolve the error, try swapping the memory modules around and using the switch again. To use the

/maxmem:

x

switch, replace

x

with the amount of memory in megabytes you plan to use.

Troubleshooting Resource Conflicts

One of the most common causes of problems during setup is conflicting resources in your hardware. Many operating systems allow you to share hardware resources, but Windows 2000 absolutely will not allow such sharing. A common scenario today for hardware conflicts is that an Industry Standard Architecture (ISA) device is trying to use the same resource as a Peripheral Component Interface (PCI) device. This is because ISA devices are usually manually set, while PCI devices are dynamic. A possible solution to this problem is to reserve the resources that the ISA devices use in the system BIOS.

The usual indication of a resource conflict is when two devices on the computer do not work. Sometimes this problem will be very easy to detect; for example, the mouse will not work and neither will the sound card. Other times, the conflict is more subtle. For instance, it might be difficult to detect the conflict between a SCSI controller that is used for a scanner and a sound card. Neither of these devices would be used during setup, and so the problem would be difficult to spot until later.

Assuming that you can boot into Window 2000, you can use Device Manager to help spot the problem. To open Device Manager in Windows 2000, right-click My Computer and choose Properties. Click the Hardware tab, and then click the button for Device Manager. Figure 5.2 shows Device Manager for Windows 2000.

Chapter 5 �

Troubleshooting

263

F I G U R E 5 . 2 :

Device Manager will display any conflicts.

Device Manager will display the conflicts in your system with either a red X through the device, meaning that the device isn’t working, or a yellow exclamation point (!), meaning that there is a warning. If you have a device that is showing a warning in Device Manager, double-click the device to open its Properties page.

The Properties page for a device provides a general description of the device, the settings for the device driver, and the resources used by the device. If the device has a conflict, click the Resources tab to change the resources and resolve the conflict. On the Resources page, uncheck the Use Automatic Settings box to make changes to individual resource settings.

You can set ISA devices in this fashion if they are Plug and Play–compliant. PCI devices do not give you this option, since their settings are set by the BIOS. If you cannot resolve the hardware conflicts using Device Manager, you may have to remove some devices from the com-puter to resolve the conflict. If you find yourself in this situation, remove devices that are not required for the operation of the computer.


264

Once you have installed Windows 2000, you can start adding devices back to the computer until you find the source of the conflict.

Troubleshooting Blue-Screen Errors

Blue-screen errors, stop screens, or the dreaded Blue Screen of Death are all the same type of error: Something blew up in Kernel mode and the operating system is unable to continue working. These errors can be caused by a wide variety of problems, from software to hardware—or even by environmental factors (such as heat). They all have some common points that will be useful for troubleshooting. Consider the following illustration of the top line of a STOP message:

STOP: 0x0000000A (0x00000060, 0x0000001C,

0x00000000, 0x80114738)

IRQL_NOT_LESS_OR_EQUAL

The first line provides most of the troubleshooting information you will need to resolve the issue. First of all, the

STOP: 0x0000000A

seg-ment tells you that the blue screen is a STOP 0xA (it’s okay to omit the leading zeros when talking to tech support), which usually refers to a bad hardware driver. A STOP 0xA can also be caused by bad memory, though, so you still need to do some troubleshooting. The set of four 8-digit hexadecimal numbers in the parentheses is a vital clue to what happened to cause the error. Always write them down with the actual stop code because you will need them to query the Knowledge Base on Microsoft’s Web site for the solution. If you end up calling technical support, they will need to have these numbers to help you. The remainder of the screen is really only useful if you are capable of performing a live debug of the crashed system.

Two blue screens are most commonly seen during setup. The first is

STOP: 0x0000001E

KMODE_EXCEPTION_NOT_HANDLED

Chapter 5 �

Troubleshooting

265

And the second is

STOP: 0x0000000A

IRQL_NOT_LESS_OR_EQUAL

Misbehaving drivers most commonly generate these, though a hardware problem can also cause them, especially a memory problem. One of the first things to rule out is any third-party driver you may be installing. Try to use only drivers supplied by Windows 2000, if possible. If you can’t avoid using a driver supplied by someone else, then be certain the driver was written specifically for Windows 2000 and not for an earlier version of NT. Try contacting the vendor for an updated driver file, possibly through their Web site.

Another common blue-screen error involves Windows 2000’s inability to access the hard drive to boot the computer. The STOP code is

STOP 0x0000007B

INACCESSIBLE_BOOT_DEVICE

This one is usually not nearly as bad as it first seems. What Win-dows 2000 is telling you is that it can’t use the driver you chose during the Text-mode portion of Setup. You can work through this blue screen by using standard hard-disk troubleshooting. Check the cables, and if it’s a SCSI drive, check the termination. Be sure the drive is getting power and is spinning normally. If the drive is connected to a controller that has a BIOS, check the BIOS settings for the con-troller to make certain the controller can see the drive.

One of the most interesting causes of the STOP 0x7B is adding an IDE drive to a SCSI-based system. IDE controllers are enumerated before the SCSI controllers, meaning that the BIOS of the computer looks for them first. If you add an IDE drive to a computer that is already work-ing fine with SCSI hard drives, you may very well see this blue screen. You can fix this situation in the computer’s BIOS. If your BIOS sup-ports the option, set the boot order to go to the SCSI drives first, then to the IDE drive.


One last thing to mention about blue screens applies mostly to upgrading Windows 2000 from an earlier version and less to a fresh install. If you are using third-party drivers or programs that run in NT as services, you should always disable them until after setup is completed. Please be aware that some services, especially network clients, are specifically designed for one version of Windows NT.

There’s one last critical error to talk about here:

Setup has encountered a fatal error that prevents

it from continuing. Contact your software

representative for help. Status code (0x4, 0,

0, 0)

This error message is displayed on a blue screen, but it is not actually considered a “blue screen” because it does not display the typical STOP message. The message indicates a problem with the Master Boot Record (MBR). Either the MBR has become corrupted or it’s infected with a boot-sector virus. This usually happens only on dual-boot systems, but it can also happen if you boot the computer with an infected floppy disk. NTFS is resistant to viruses because Win-dows 2000 doesn’t allow any program to access the hardware directly. Resistant, but not immune.

It is possible to repair the MBR if you have a bootable floppy that you know is clean of any virus infection (that’s the hard part in getting rid of a virus). An emergency boot disk from Windows 95/98 is especially helpful for this because you need fdisk.exe. After booting the infected computer with the boot floppy (you did write-protect the floppy, didn’t you?), run mem.exe at the command prompt. The Total Bytes of Memory (before anything is subtracted) should equal 640K. Next, run chkdsk.exe and look at the line for Total Bytes of Memory (it’s near the bottom), which should read 655,360. If either amount of memory is off, and especially if only one of them is off, you probably have a boot-sector virus loaded in memory. If both of these programs correctly report the amount of conventional memory, you can be rea-sonably certain that the virus is not in memory. If that’s the case, you can type fdisk /mbr at the command prompt to rebuild the MBR.

Chapter 5 � Troubleshooting 267

This command won’t do anything else, provided the virus is not in memory. However, if the virus is in memory, this command may be fatal to your data.

WARNING The fdisk /mbr command is dangerous and should never be used without being absolutely positive that a boot-sector virus is not loaded in memory. The result could be total data loss. Most boot-sector viruses work by moving the MBR elsewhere on the disk, then re-placing it with their own code. Anything that tries to scan the MBR is first infected by the virus and then redirected out to the real MBR in its new location.

NOTE It’s interesting to note that the Master Boot Record is operating system independent. It’s quite possible to rebuild the MBR for a Win-dows 2000 computer using an emergency boot disk from Windows 98.

Resolving third-party tools

It’s very common to use software on Windows NT that runs as a service, especially for anti-virus or network client access. The only thing wrong with these programs is that they can cause problems when performing an upgrade of the operating system. If you stop their services prior to performing the upgrade, everything should go fine. The Readiness Analyzer will assist you with these issues as well as the hardware issues discussed in the previous section.

Outside of the recommendations made by the Readiness Analyzer, it would be prudent to temporarily disable any third-party software you are currently running before upgrading to Windows 2000. This will help to avoid any nasty surprises during the setup procedure. As a gen-eral practice, you should disable all third-party software packages before installing Windows 2000, especially all anti-virus programs. This last step is particularly important because Windows 2000 Setup will modify the boot sector of the hard drive.


The problems caused by third-party tools can range from blue-screen errors to system crashes. If you encounter a blue-screen error, please consult the earlier section on troubleshooting blue screens. If you can determine which third-party tool was at fault, simply disable it and the error should be resolved. Of course, by the time you receive the blue-screen error, it may already be too late to disable the third-party software. Once again, it’s better to disable all of these packages before performing an upgrade.

Once the upgrade has been performed, you should be able to reinstall or reenable your software. As a precaution, always check with the vendor of the software’s Web site prior to enabling it in Windows 2000.

Resolving user rights issues

Normally, user rights issues should be resolved by using the SIDHistory property of the user accounts in Active Directory. But in some cases after upgrading a computer to Windows 2000, you may find yourself unable to log on to the computer with a normal user account. This should happen only if you’ve chosen to upgrade the member server to a domain controller in Active Directory. This is because domain controllers do not allow normal user accounts to log on locally at the computer. If you are able to log on using an administrator account, you’ll be able to change the local rights in the computer to allow local logon for users.

Problems with rights and permissions typically show up when you access resources. The SIDHistory property of the accounts should help users to maintain access to resources in Windows 2000. And, of course, remember that an Access Denied message always means you do not have permission to do what you just tried to do.

One note of interest with Windows 2000 Professional is that all users will have administrator rights after the upgrade. This behavior occurs when you have upgraded from Windows 95 or 98, where all users have full control access to the entire operating system. This situation is caused by design and is completely normal behavior, based on the type of upgrade you have performed. When you upgrade from NT Server to Windows 2000 Server, this behavior does not exist, as all permissions and rights are maintained in the upgrade.


Other problems you might experience with rights and permissions during an upgrade occur with Remote Installation Services (RIS), where the user installing the client workstation must be able to create the computer account and must even have the ability to run the Remote Installation Services to begin with. In order for someone to install a client machine using RIS, they must have permission to log on as a batch service.

A good resource for troubleshooting service accounts in Windows 2000 is the Event Viewer application in the Administrative Tools group. In most cases, Event Viewer will display the service and the account name that is having trouble starting.

Resolving domain name issues

The domain issues you are likely to run into when upgrading to Windows 2000 are mostly based on finding the domain con-trollers. Because the Windows 2000 network depends on DNS exclusively for locating the servers, older clients may have diffi-culty if they are not configured for DNS resolution. Possible solu-tions to this problem include using a Hosts file or making sure that the TCP/IP configuration is set to use DNS for resolution.

Along the lines of the DNS resolution issue, the DNS servers in your network should support the dynamic update feature. One solution for the older clients is to use the Windows Internet Naming Service (WINS) server to provide NetBIOS name resolution. Since WINS is not used in a native Windows 2000 environment, WINS will likely not be available if you’re creating the network from the ground up. Providing name resolution for clients being upgraded to Windows 2000 might be a great example of why you would want to include the WINS server.

Another possible solution would be to use an LMHosts file to provide the NetBIOS resolution. Using this method, the NetBIOS resolution would contain a mapping for the domain controllers in the network with a #DOM in the LMHosts file. The best solution, however, is still to provide DNS resolution for clients being upgraded to Windows 2000.

When troubleshooting domain problems, be sure to start with the basics. For example, make sure that you have established network


connectivity with the domain controllers. This is another area where asking whether the domain controller is plugged in or turned on may be beneficial. Sometimes your inability to add a computer to a domain will stem from the lack of network connectivity. Check the cables to be sure that they are connected. Verify that your computer is running the same network protocol that the servers are running. Simple network troubleshooting should always be used in these cases.

One last situation to consider is a member server that is being promoted to a domain controller in a new domain. In order for a member server to be promoted to a domain controller in a domain, there must be reliable communication with an existing domain controller in the domain. This means that the domain controller must be able to be resolved through DNS. For this to work, dynamic DNS entries in the DNS server must support the location of the domain controllers within an Active Direc-tory network. Dynamic DNS entries are supported in the BIND DNS server version 8.1.2 and higher and in the DNS server supplied with Win-dows 2000. If your domain is still running in mixed mode, you must be able to reach the Primary Domain Controller (PDC). This is where Net-BIOS name resolution will be important.

In mixed mode, domain client computers will locate the domain con-trollers by using NetBIOS name resolution. This means using a WINS server or an LMHosts file. If the client computer and the domain con-troller are on the same network segment, the client will also be able to locate the domain controller through a NetLogon broadcast. Once your domain has been converted to native mode, a client computer will be able to add itself to the network by contacting any domain controller.


There is one necessary procedure for this objective. It’s important to be familiar with the Readiness Analyzer and its output. When you are per-forming upgrades, or otherwise getting ready to install Windows 2000, the Readiness Analyzer can help resolve problems before they happen.


Using the Readiness Analyzer

To use the Readiness Analyzer, follow this procedure:

1. Browse to the folder where you stored the chkupgrd.exe file after downloading it from Microsoft’s Web site. Double-click the file to start it.

2. Read through the License Agreement and click Yes to signify that you agree to its terms. The program will now extract its files to begin.

3. The program will run without intervention and compile a report of compatibility information. Browse through the reports to see if there are any issues.

Exam Essentials

Know what the Readiness Analyzer does. The Windows 2000 Readiness Analyzer will check the hardware of a machine to make sure it’s compatible with the Windows 2000 operating system. It also reports errors if it finds any.

Know how to troubleshoot display problems. Most of the time, display problems are related to driver incompatibility. During boot, you can press F8 to get to advanced options and choose either VGA Mode or Safe Mode to load the standard VGA video driver for troubleshooting.

Know how to set up name resolution in a Windows 2000 environment. Windows 2000 relies on DNS to resolve computer names. Hosts files can also be used, but are not the preferred method. If you are supporting downlevel clients or applications that require NetBIOS naming, you will need to use a WINS server or an LMHosts file.



Hardware Compatibility List (HCL) List published by Microsoft that contains hardware they have tested with and approved for the Windows 2000 operating system.

Master Boot Record (MBR) First sector of the hard drive, which contains boot information for the operating system installed on that computer.

�Troubleshoot account issues for all types of migrations.

Because Windows 2000 has a completely different way of dealing with user accounts and groups than NT 4, you may encoun-ter several problems along the way. This objective considers some of the troubleshooting you may have to do with user accounts and group accounts. Issues include duplicate user accounts with differ-ent SIDs and what happens when you have insufficient user rights to perform a specific task.


Learning how to deal with duplicate accounts and user rights is important. However, another major issue in Windows 2000 is taking care of some of the problems that may arise with the transition from System Policy to Group Policy Objects (GPOs) and with the transi-tion from logon scripts to Windows 2000.

Resolving system policy translation issues

In Windows NT, System Policy could enforce a specific view of the Desktop for all of your users. Even though there were problems asso-ciated with System Policy, it was an effective way to control the user’s


workspace. System Policy was applied directly to the Registry of the user’s computer. This method was effective for controlling quite a few different options. However, there were problems in terms of making changes to the policy, which were not always correctly applied, and problems in applying the correct policies in the correct order. You would sometimes experience unexpected results stemming from the order in which System Policies were applied. Also, old policies had to be manually removed from the Registry in NT. In 2000, they are auto-matically removed.

Instead of using System Policy, you now use GPOs to apply a specific policy to users, computers, OUs, or an entire domain or site. With Windows 2000 and Active Directory, a much more granular config-uration is possible. You can set Group Policy to flow down from the very highest level, or you can set it at a lower level and apply it directly to one OU. In addition, you can block Group Policy inherit-ance at any level or prevent it from being blocked.

Windows 2000 includes the ability to enable diagnostic logging for Group Policy. The logging events will be displayed in the Event Viewer. These events can be useful in diagnosing problems associated with Group Policy by providing greater detail on what went wrong.

Once you have enabled diagnostic logging for Group Policy, you’ll be generating a large number of events in the application log. These events will occur mostly when a user logs on to the local computer. You can also choose to enable verbose logging to generate more details in a separate log file. This involves adding another value to the Registry. To enable verbose logging, use the Registry Editor to browse down to HKEY_Local_Machine\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon. From the Edit menu, select Add Value, then name the value UserEnvDebugLevel, with a type of REG_DWORD. Entering a value of 30002 enables verbose logging; a value of 30001 enables logging of errors and warnings only, and a value of 30000 turns off logging. To disable verbose logging, delete the new value from the Registry.


Group Policy Troubleshooting Tools

Windows 2000 offers four tools for troubleshooting Group Policy. Two of the tools are included in Windows 2000, and the other two are available in the Windows 2000 Resource Kit. Some of the tools, such as Netdiag, relate to network connectivity, and some of them relate directly to the replication of policy and to the functioning of Group Policy. The troubleshooting tools for Group Policy are:

Netdiag.exe This command-line tool from the Windows 2000 CD-ROM helps solve connectivity problems by performing a series of tests to determine where the connection occurs. Netdiag is useful to determine whether the Group Policy problems are being caused by network failure.

Replmon.exe This tool can help you solve problems that are related to incomplete or incorrect replication of the Group Policy container and the Group Policy template. Replmon is included on the Windows 2000 CD-ROM and is installed automatically with the Support Tools. This tool lets you see the low-level replication activities of Active Directory in your network. It enables you to force replication, monitor replica-tion, and force synchronization between domain controllers.

GPOtool.exe GPOtool is a command-line tool from the Resource Kit that lets you check the status of Group Policy Objects on domain controllers. You can check all portions of the GPOs on the domain controller.

GPResult.exe This command-line tool is available in the Win-dows 2000 Resource Kit. GPResult displays information about the results of all GPOs applied to the current user and the computer.


You should be able to determine much about the source of the problem from the reports from your users. If their Group Policy is not being applied at all, then you need to investigate network con-nectivity. If the policy is not being applied correctly, then you need to investigate the Group Policy on the domain controllers. In this last case, the source of the trouble may be replication of the GPOs or it may be a result of incorrectly applied GPOs. Figure 5.3 shows the results of using GPOtool to display the status of GPOs on a domain controller.

F I G U R E 5 . 3 : The output of GPOtool.exe

GPResult enables you to determine how GPOs are being applied to a given user, which can be especially useful when troubleshooting incorrectly applied GPOs. Figure 5.4 shows the output of GPResult.exe.


F I G U R E 5 . 4 : GPResult.exe is useful for determining how GPOs are applied.

When troubleshooting System Policy problems on Windows NT, it was often necessary to use a piece of graph paper to map users and the groups they belonged to. Now when troubleshooting Group Policy within Windows 2000, GPResult allows you to see which groups a user belongs to and how Group Policy is applied to that user.

Common GPO Issues

There are a couple of scenarios that you might have to troubleshoot with Group Policy. In the first scenario, you cannot access or open the GPO. In the second scenario, your GPO is not being implemented as expected.


In the first situation, you intend to either open or edit a GPO but receive an error message telling you that the GPO cannot be accessed or opened. Two possible causes for this are:

� You do not have the correct permissions to access the GPO. Check the DACL (Discretionary Access Control List) for the GPO that you’re trying to access. You must have both Read and Write permissions to open or edit a GPO.

� You’re unable to connect to the domain controller that the GPO is trying to reach. This problem can be caused either by network connectivity problems or by failure to resolve the domain con-troller name in DNS.

Another thing to check when you receive an Access Denied message for the GPO is the delegation of authority for the GPO. You may be logged on with an account that you believe has authority for the GPO but that actually does not. If you were logged on as a normal user but expected to be an administrator, this could be an issue.

In the second scenario, your GPOs are not being applied as you would expect. There are several possible causes for this scenario:

Inheritance conflicts If Group Policy settings are not being applied as you expect, be sure that inheritance is not being blocked or that the inheritance is not causing problems at a lower level. This can take some time to track, depending on the size of your Active Directory hierarchy. Starting at the top of the forest, work your way down through all of the sites, domains, and OUs that apply in this inher-itance. Don’t forget to also check computer settings in the GPOs. Remember that, in most cases, computer settings will override user settings if they are in conflict. The last thing to check for in this scenario is a No Override setting on some OU in the chain.

Permission issues Check the DACLs of all GPOs that you expect to be applied to the user or the computer in question. Remember that a user must have Read and Apply Group Policy permissions in order to have a GPO applied. You also need to check in the groups that the user belongs to. Make certain that you check for Deny permissions set


on any of the DACLs. Always remember that Deny permissions override Allow permissions.

Disabled GPOs If your GPOs are not being applied as you would expect, make certain that the GPOs have not been disabled. Remem-ber to check both the user configuration and the computer configu-ration to see if they have been disabled.

Computer or user object has been moved If the user or com-puter object has been moved to Active Directory, it may not have the correct location for its GPO. Remember that a client caches the Active Directory location information for up to 30 minutes, so this situation should correct itself in due time. If the Group Policy refreshes before the cache location does, the new Group Policy set-tings will not be processed. However, they will be processed the next time Group Policy refreshes.

Replication issues Remember that GPOs depend on both the Group Policy container and Group Policy template portions that are stored in the Sysvol. If replication has not completed, these portions of the GPO will not be present on all domain controllers. Make certain that both Active Directory replication and Sysvol replication have com-pleted successfully. If one or both of these replications fails, the GPO will not be applied correctly—and possibly not be applied at all.

Inter-domain GPO link issues If you have linked a site, domain, or OU to a GPO in another domain, the GPO must be accessed across a trust relationship. If the trust fails for any reason—perhaps due to data network connectivity problems—the GPO will be unavailable. If the GPO is unavailable, then Group Policy processing will fail. Hav-ing multiple domain controllers per domain should correct this prob-lem. If you have multiple domains in a single site, you should also try to have more than one domain controller from each domain in the site.

Just because these are called common troubleshooting issues with Group Policy doesn’t necessarily mean that Group Policy will fre-quently have problems. If you read these situations carefully, you will see that most of them can be avoided with vigilant administration of


Group Policy. Here is a list of things to keep in mind when you’re designing your Group Policy:

� Try to place limits on your use of the No Override and Block Inher-itance permissions and the filtering of GPOs, especially across domains. Every time you make changes to the flow of inheritance of Group Policy, you introduce complications into the overall flow.

� Always try to limit the number of GPOs that affect anyone within your network. The more GPOs you add to the network, the more complicated your job will become. Troubleshooting is always easier if there are a limited number of GPOs to view.

� Logically group related settings within a single GPO. For example, group Registry settings for Office 2000 within the same GPO that controls the software installation for Office 2000. That way, if there are any problems with Office 2000, you have to look at only one GPO.

� Limit the number of administrators for any single GPO. The more administrators you have for a single GPO, the greater the chance that two of them will modify the same GPO at the same time. Exercise caution when setting up delegation of authority for GPOs to prevent possible conflicts.

� Try to avoid linking a GPO to a site that contains multiple domains. When you assign the GPO to a site, it affects every domain within that site. Computers from each domain must contact the domain controller for the domain that houses the GPO every time they log on.

� Disable unused portions of a GPO. Disabling portions of a GPO that will not be needed or that no longer apply can improve per-formance.

� Carefully lay out your needs for Group Policy during your plan-ning of the network. This tends to head off most problems.

Careful planning prior to installing Windows 2000 in your network will enable you to make sensible decisions about the structure of the network. Most of the problems that you run into with Group Policy can be avoided with careful planning before the installation.


Resolving logon script failures

Windows 2000 supports the use of scripting to control the user environment. In NT 4, the only scripting used was batch files. Windows 2000 lets you use batch files, Visual Basic scripting, exe-cutable files, and any other files supported by the scripting host.

You can use Group Policy in Windows 2000 to assign scripting to four different events:

Startup scripts Startup scripts run when the computer is booted. They run hidden, in the background, and are run synchronously by default. This means that each script must complete before the next script can begin running. If one script fails, the other script must wait for its timeout before it can begin.

Logon scripts These are the same scripts that have been around since the early days of Windows NT. They can be the same batch files that you’ve run all along, or they can be any of the new supported files. By default, logon scripts are hidden and run asynchronously.

Logoff scripts Logoff scripts execute when the user logs off the current session. These scripts can be useful in cleaning up custom settings after a user session.

Shutdown scripts Shutdown scripts execute in the background when the computer is being shut down and after a user has logged off.

The scripts are very useful for doing things that Group Policy is unable to do. For example, they might be helpful when you want to attach network drives, connect to network printers, or create custom shortcuts on the Desktop. It’s a good idea to continue running your custom logon scripts until you have fully established Group Policy in the network. Over time, you may find that most logon scripts can be replaced with Group Policy.

It’s possible to assign scripts to a user individually in the properties for the user account. However, the preferred method is to assign scripts using Group Policy. That way, policy can be defined according


to site, domain, or organizational unit. Within Group Policy, you can specify the order in which scripts will run if there are multiple scripts of the same type.

Since the default action for these scripts is to run hidden, in the back-ground, it may be difficult to determine when they are in fact running. Being familiar with what the scripts actually accomplish will help you determine whether a script has been run. The default value for the time-out to run a script is 10 minutes. If you have a script that will require more than 10 minutes to run, you must increase the timeout value in the Active Directory. Be aware that when you increase a script’s timeout value, you affect the time that all scripts will have to run.

Assigning scripts to run with a GPO is a two-step process. First, you must make the GPO aware of the script by copying the script into the Group Policy template. Second, you must assign the scripts from the Group Pol-icy template to the GPO script settings.

Troubleshooting Scripts

The troubleshooting for scripts falls into two categories. The first cate-gory occurs when the user does not have permission to access a script during logon, logoff, or shutdown. The second category occurs because of errors in the script file. To troubleshoot the second category, use the Microsoft Script Debugger included with Windows 2000. To trouble-shoot the first category, you need to complete some steps to determine whether a permission issue, network connectivity issue, or some other problem is preventing the script from loading.

You can use the GPResult utility included with the Windows 2000 Resource Kit to troubleshoot scripts assigned to a user or to a GPO. GPResult will show you the GPOs affecting a given user. It can also show you the result of any scripts being assigned to the user by any of those GPOs. When you run GPResult in verbose mode, you see which scripts have actually been received for execution. Figure 5.5 shows GPResult.exe displaying the list of scripts applied to a user.


F I G U R E 5 . 5 : Running GPResult.exe in verbose mode displays which scripts have been received.

Look for the heading entitled The User Received “Scripts” Settings From These GPOs. If no text appears in the output, the user is not receiving the correct scripts. Now you can begin your troubleshoot-ing for network connectivity, permissions, or the actual presence of the scripts on the servers. The scripts must be present on all domain controllers to be applied reliably. Make certain that the Sysvol folder is being replicated to all domain controllers correctly.

The first thing to try is to make sure that the client computer can con-nect with the domain controller. Try resolving the name of the


domain controller by pinging the DC from a command prompt. If this works, attempt to map a drive using the name of the domain control-ler and a known shared folder. These steps verify network connectiv-ity and name resolution. One last thing to try from this computer is to verify that other users are receiving the script. This final step iden-tifies whether the problem belongs to a single user or to all users try-ing to access the domain through this computer.

When troubleshooting scripts from the server side, the first thing to check is whether the script actually exists and is in the correct location on the server. Open the properties for the GPO in question and double-click the entry for the correct type of script. For example, if you’re troubleshooting a logon script, double-click the node for logon scripts in this GPO. Make certain the scripts are assigned correctly to this GPO. If they do not show up in the list, they will not be applied.

Once the scripts have been added, they will be applied in order from top to bottom. This order in itself can cause some of the problems. If your scripts apply conflicting settings, the one that is applied last will win, which may cause unexpected results. Another point to consider is whether you have assigned the script to the correct policy. It’s easy to mistakenly assign a logon script to an incorrect policy. For exam-ple, you could have assigned a logon script to the logoff event.

When troubleshooting a script problem, you will have to check each GPO that applies to the user in question. Check the computer settings and the user settings within the GPO. Make certain that the logon script is assigned to the logon event, the logoff scripts are applied to the logoff event, and so on.

Resolving issues associated with duplicate accounts

that have different SIDs

Duplicate accounts can cause security holes or prevent users from get-ting to resources they are authorized to use. When migrating from one operating system to another, it is easy to create duplicate accounts without realizing it. For example, consider the use of ClonePrincipal to move accounts from one domain to another. ClonePrincipal works by copying the accounts, or “cloning” them, from the source domain


to a new Active Directory location. This is considered normal behav-ior for this tool. Now consider the use of ClonePrincipal within an Active Directory forest. In this case, you can clone accounts from one domain to another within the same forest, creating duplicate accounts within that forest.

Having two accounts within the same forest that have the same SID can cause serious conflicts. Consider the following situation: A Group Policy is applied to affect a single user account in the source domain. Then the same account is affected in the new domain by applying a different GPO. Which GPO will be applied when the user logs on may depend on which domain controller authenticates the user logon first.

Remember that when accounts are cloned from the source domain to the target domain, the SID is copied to the SIDHistory value of the new account. So even though the distinguished name of the account has changed, the SID and the SIDHistory will remain the same. Win-dows 2000 evaluates security according to the SID of the user. It will also use the SIDHistory to check for additional permissions. As a gen-eral rule, you should never duplicate user accounts anywhere on the same network. By adhering to this practice, you will avoid any com-plications caused by duplicate user accounts or duplicate SIDs. This shouldn’t be much of a problem since Active Directory Users and Computers should prevent you from creating duplicate accounts in the enterprise. Duplicate accounts will probably be a problem only during and immediately after migration.

NOTE Duplicate user accounts are most commonly created during a clone or by the use of scripts.

Resolving issues associated with user rights

If you follow the standard administrative philosophy of granting user rights by adding users to the appropriate groups, then you will rarely experience problems when troubleshooting user rights. But if you


start to customize the assignment of rights, then all bets are off. Here are some guidelines to follow when assigning custom user rights:

Assign user rights to groups instead of individual users. Customiz-ing the assignment of rights is something that you normally want to avoid. But if you find that you must assign an individual user right to someone, create a group for the user(s) who need the right and assign the right to the group.

Grant rights only when you must. The standard rights assignments will be adequate in nearly every case. If you need to delegate a specific task for a server to a user in your organization, and you cannot use one of the existing groups for some reason, then you will need to assign the necessary rights.

Grant no more rights than are necessary. Just because you can grant rights doesn’t mean that doing so is a good idea. It is a funda-mental principle of administration to never grant more ability than is necessary to perform a job. In this case, grant no more user rights than are absolutely needed.

Very often, you’ll find that Windows 2000 will shield you from having to assign custom user rights. If there are tasks that require elevated user rights, the operating system will frequently assign those rights through the wizard that you’re using to configure the service. But if you have incorrectly assigned user rights, there is no easy answer to fix the problem.

This is one of those areas of troubleshooting where the only way to solve the problem is by performing the tedious work. You’ll need to check the assignment of user rights before you can determine the problem. The Domain Security Policy console will help you deter-mine what rights have been assigned at the domain level. If you’re troubleshooting the use of user rights at the local computer, use the Local Security Policy console instead.

One possible source of confusion with User Policy is that domain policies will override local computer policies. You may have assigned the correct policies using the Local Security Policy only to discover that domain-level policies are overriding your local policies.


To change settings in the Local Security Policy console, simply double-click the user right that you want to change. This will open up the dialog shown in Figure 5.6. This dialog will display the users and groups currently granted the user right and the effective setting for those users. On this dialog you can click the Add button to add additional users and groups for this right.

F I G U R E 5 . 6 : The Local Security Policy Setting dialog

Viewing these dialogs for each user right is really the only way to determine which user rights have been assigned to which users.


This objective has three necessary procedures. The first is editing the Registry to enable diagnostic logging for Group Policies. Once log-ging is enabled, you will concentrate more directly on user accounts, looking at how to determine the results of a given Group Policy and examining user rights.


Enabling Diagnostic Logging

It’s often hard to tell if Group Policies are working properly. Most of the time, the only sure way to know something is wrong is when a user calls in complaining. There is a remedy, which is to enable diag-nostic logging. Remember that enabling this logging can cause a large number of events to be recorded in Event Viewer. To enable diagnos-tic logging, follow this procedure:

1. Log on as a local administrator account.

2. Click Start � Run and type Regedt32.exe. Click OK.

3. Browse down to HKLM\Software\Microsoft\WindowsNT\CurrentVersion key.

4. Select Add Key from the Edit menu. Enter Diagnostics as the name of the new key. Click OK.

5. Highlight the Diagnostics key, and select Add Value from the Edit menu. In the Value Name field, type RunDiagnosticLoggingGlobal, and in the Data Type field, type REG_DWORD.

6. Double-click the new RunDiagnosticLoggingGlobal value, type 1 in the Data field, and click OK. This setting will cause all events generated by Group Policy to be recorded in the Event Viewer. Now exit the Registry Editor.

Determining the Result of Group Policy

This procedure requires that you have access to a Windows 2000 domain running in native mode with Active Directory and that you have installed the Windows 2000 Resource Kit tools. You will first need to create at least one Group Policy Object to be assigned within the domain to a group or a single user. The results of the procedure are more satisfying if you create multiple GPOs at different levels of Active Directory. As a suggestion, do the following:

� Create a user account to which you can apply Group Policy.

� Create a GPO at the site level to control software distribution.


� Create a GPO at the domain level to control logon hours for users.

� Create a GPO at the user’s OU level to redirect the My Documents folder.

After you have applied Group Policy at various levels to groups and your test user, run the GPResult.exe tool to analyze the resulting pol-icy as it applies to your user. To determine the Group Policy results, follow this procedure:

1. Log on to your test computer with the test user account you created for this procedure.

2. Open a command prompt.

3. Type gpresult.exe and press Enter.

4. Examine the output of the command to determine the policy results for the user and the computer.

5. Type gpresult.exe /? at the prompt to display the various options for modifying the output of the gpresult.exe command.

6. Enter the command to display the Group Policy results for the currently logged-on user only.

Troubleshooting User Rights

This procedure requires the use of a Windows 2000 server com-puter and a suitable client computer running the Terminal Services Client. The computer may be either a stand-alone or a member of a domain. The computer system must have Terminal Services installed. This procedure will introduce a problem related to user rights and then resolve it.

1. Open the Local Security Settings console by clicking Start � Pro-grams � Administrative Tools � Local Security Settings.

2. Expand Local Policies � User Rights Assignment.

3. Double-click the Log On Locally user right to open the Local Security Policy Settings dialog for this right. CAUTION: Do not proceed unless you have an administrative account with which to access the machine so that you can undo your settings after the exercise.


4. Uncheck the Local Policy Setting box for the Users group.

5. Click OK to close the dialog and save your changes. Exit from Windows 2000.

6. Attempt to log on to the computer using the test user account you created in the last procedure. Did it work? Record the error message if it did not work.

7. Attempt to connect to the computer using the Terminal Services Client from another computer. Record the error message you receive.

8. Attempt again to access the server with the Terminal Services Client, this time with an administrator account. Did it work?

9. Repeat steps 1 through 4 to restore the ability of the Users group to log on locally to the server, except this time check the Local Policy Setting box.

You may have noticed that the error message doesn’t tell you exactly which user right is missing, only that the local policy doesn’t allow you to log on interactively. Based on this error message, do you think you would be able to identify which user right needs to be adjusted? The most important thing to note here is that the error message directs you to examine the assignment of user rights.

Exam Essentials

Know how to deal with System Policy translation failures.Windows 2000 uses Group Policy instead of System Policy, and there are some differences that result in incorrect translations. The best bet is to set up and test potential Group Policies, and make sure they accomplish what your System Policies did.

Know how to resolve script failures. There are four types of scripts supported by Windows 2000: startup, logon, logoff, and shutdown. You need to make sure that the appropriate script is associated with the proper GPO and affects the right people. Also, place scripts in the


Sysvol share on all domain controllers. This can be accomplished by placing them in Sysvol on one domain controller, and letting replica-tion take care of the rest.

Understand the difference between permissions and rights.Permissions allow users to access a resource, like a file or a printer. Rights give the user the ability to perform a system task, such as changing the system time, shutting down the computer, or logging on locally to the machine.

Know the proper place to create and assign security policies.If you want the security policy to affect only the local machine, you use the Local Security Policy console. For domain controllers, there is a Domain Controllers Security Policy MMC. To affect an entire domain, you would open the Domain Security Policy applet. All three look extremely similar, so make sure you have the right one.


GPOtool Diagnostic tool that displays the status of GPOs on domain controllers.

GPResult Windows 2000 diagnostic tool that shows you the cumu-lative results of GPOs applied to a specific user.

permissions Conditions that allow (or deny) users access to a resource, such as a file, folder, or printer.

Replmon Windows 2000 diagnostic utility that allows you to check replication status regarding the Group Policy Container and Group Policy Templates.

user rights Settings that grant users the ability to perform a system task, like logging on locally, accessing the computer from the network, and adding computers to a domain.


�Troubleshoot access issues for all types of migrations.

If your migration fails to provide access for users after it is complete, then it cannot be regarded as a success. This is why networks exist—to provide access to files and printers remotely, and to eliminate the need for the “sneaker net.” If users are unable to access all or part of the network, you need to be able to get the problem resolved quickly so everyone can do their jobs.


This objective includes examining how to troubleshoot client access issues; shared permissions and how they interact with NTFS permissions; and missing or inaccessible shared resources. These typically involve network access to the domain controllers or other file and print resources.

The latter portion of this section will deal more with network prob-lems such as authentication issues. This discussion will examine authentication problems when logging on to a domain and when accessing resources. Trust relationship issues and how they may affect users in a larger Windows 2000 environment are also covered.

Resolving client computer connectivity issues

In troubleshooting the connectivity problem, you should determine whether the problem involves name resolution or is a more funda-mental networking issue. If the customer cannot map a drive by using the server name, suggest that they try mapping the drive using the IP address of the server.

Windows 2000 gives you another factor to consider, DNS. The importance of DNS to Windows 2000 networks cannot be overstressed.


The primary name-resolution method for Windows 2000 is to submit a name query to a DNS server. Windows 2000 also uses DNS to locate the domain controllers and Kerberos servers that will provide authentication into the domain.

Troubleshooting the Network

When troubleshooting network connectivity issues, keep in mind the basics of what is required to connect two computers. At a bare min-imum, you need the following in order to make network connections:

Physical connectivity There must be a physical medium to carry the signals between computers before they can communicate.

Common protocol The network protocol sets the rules of commu-nication between two hosts. Before the computers can communicate, there must be a common language.

Proper addressing In network protocols such as TCP/IP, you must use the correct addressing before the computers can communicate.

Application-level support One computer must have a redirector, and the other computer must have a server component to host a ses-sion at the application level. There are many different client-side applications. To get networking to work, your client software needs to know how to talk to the specific server software. For example, if you have a Microsoft network-based client but a NetWare server, they won’t talk.

Begin at the physical layer and work your way up, slowly verifying each level before proceeding. Always check simple things like con-nections first. Most connectivity problems are the result of some-thing being unplugged.

When troubleshooting TCP/IP, you have several tools at hand to help the process. For instance, you can use the IPConfig and Ping utilities from the command prompt to verify that the physical layer is working and that IP addressing is working. Once you verify that you can ping by IP address, you can also try pinging by DNS name.


NOTE Microsoft recommends pinging yourself first, then working your way out to your gateway and then to a remote host. In real life, it’s best to ping the remote host first, and then work your way backwards.

If you can ping the IP address, try using the hostname for each computer. One extra step to take if the remote host fails to respond is to try to ping the address of another computer on the same sub-net. If another computer on the same remote subnet responds, you know that the remote host you are trying to reach is most likely offline. Using these steps to test TCP/IP connectivity proves that the physical media are working, the network cards are working, and the TCP/IP stack up to the Internet layer is working correctly. If pinging by the hostname does not work, then you need to move on to troubleshooting hostname resolution.

Most of the hostname-resolution troubleshooting you perform with Windows 2000 will involve DNS servers. However, before moving on to troubleshooting DNS, you need to be careful that there is no Hosts file present on the Windows 2000 computer. The Hosts file is located in the following directory path: %SystemRoot%\System32\Drivers\Etc. The Hosts file is a static text file that performs host-name-to-IP address resolution. Typically the Hosts file will be checked before the computer will go to a DNS server to resolve a hostname to an IP address. If the Hosts file containing the resolu-tion is incorrect, you may reach an incorrect address or fail to connect to a server. Check the Hosts file carefully for incorrect mappings.

NOTE In Windows 2000, Microsoft wants to avoid the use of Hosts files if at all possible. The current DNS service is a more than adequate solution for name resolution. The Hosts file has become passé.


One critical point about client connectivity issues and DNS is that the client computer must be configured to use a DNS server. You can accomplish this configuration either manually or through DHCP. Once the client computer is set up to look for at least one DNS server, it will begin using DNS for hostname resolution whenever required. If the com-puter doesn’t appear to be using DNS at all, check to make sure that it has been configured with the address of at least one DNS server.

NOTE Windows 2000 DNS caches DNS name resolutions. Before troubleshooting DNS resolution issues, clear the DNS cache with the IPConfig /flushdns command.

The premier tool for troubleshooting DNS issues is the NSLookup utility. NSLookup enables you to query a DNS server either in inter-active mode or in a single lookup mode. To perform a simple query using NSLookup, you would simply type (at the command prompt) nslookup followed by the hostname you are trying to resolve.

There are many options available to an NSLookup query. For a com-plete list of all of the options available to NSLookup, type help at the DNS Lookup interactive prompt.

As stated earlier, DNS is one of the most critical services available on a Windows 2000 network. If you have resolved all issues with DNS and your client computers still cannot connect with the domain con-troller, then you need to start troubleshooting basic connectivity problems a little more deeply. In a Windows 2000 network environ-ment, DNS will be one of the most common sources of network con-nectivity problems. But you still need to consider things that may interfere with basic connectivity from the outside.

Microsoft has included a tool with Windows 2000 that will help in diagnosing network behavior. The Netdiag utility will help you isolate


and identify various network connectivity issues. This command-line utility runs several types of queries against network connectivity and records the results. Figure 5.7 shows a sample of output from typing netdiag at the command prompt. The full output of the command is about three times what is shown here. You’ll need to run this command yourself to really appreciate what it can do for you.

F I G U R E 5 . 7 : Netdiag reports connectivity for your network line.

One of the best features about Netdiag is that it does not require any command-line switches. This means that if you use this command


while you’re on the phone with a customer, you do not have to spend time teaching the customer how to use Netdiag. Since you don’t have to really teach anyone how to use it, the simplest way to parse this is have them scan the screen for words like “FATAL.” On the down-side, Netdiag will not be able to clearly identify problems on the net-work. If you use Netdiag along with Ping and NSLookup, however, you should be able to clearly identify the problems in short order. For a complete list of the tests that Netdiag performs, please consult the Windows 2000 Support Tools Help.

Another option for using Netdiag is to save the output to a text file. Once it’s saved to a text file, you can use any text editor (such as Notepad) to examine the Netdiag output. To save Netdiag output to a file, type Netdiag.exe <localdrive>:\<documenttitle.txt> where localdrive is the current hard drive, and documenttitle is what you want to call the output file. By default, the document is saved to the current directory.

You should bear in mind that troubleshooting is the process of eliminating possible causes until you’re left with only one answer; using these tools in combination will help you along that path. Ping will help you to verify basic network connectivity. NSLookup will help you to verify name resolution in DNS. And Netdiag will help you to verify other network connectivity issues.

Using Network Monitor

Microsoft has packaged a version of Network Monitor with Win-dows 2000 for the purpose of checking network traffic. Network Monitor is a full-featured network analyzer. You can use it to capture data moving across the network wire, record that data, modify it, and retransmit it if necessary.

Although it is not very user friendly, Network Monitor is a handy utility. Figure 5.8 shows the main interface of Network Monitor.


F I G U R E 5 . 8 : The main interface of Network Monitor while capturing network traffic

The Network Monitor window contains four main sections while it’s performing a network capture:

Graph pane The first section displays a histogram of the local network activity. This section is located in the upper-left portion of the main window.

Session statistics pane The next section contains information about current sessions being maintained between pairs of computers. The session statistics pane is located midway down the left side of the main window.


Total statistics pane The total statistics pane is located on the top-right side of the main window. As the name implies, the total statistics pane contains information about the capture since it began.

Station statistics pane The station statistics pane contains statistics for every host that has transmitted or received data during the cap-ture. The station statistics pane is located across the bottom of the main window.

Capturing the data is the easy part. Deciphering the mass of informa-tion you have just captured is the difficult part. Figure 5.9 displays a capture analysis window. When you first display the capture win-dow, you see only the summary pane. The summary pane contains a line-by-line listing of every frame of data captured from the network.

F I G U R E 5 . 9 : The summary pane of Network Monitor displays a list of all frames captured from the network.


To display more information, double-click one of the frames listed in the summary pane. This will split the window into three separate panes, each displaying a portion of information about the highlighted frame. The sections are:

Summary pane The summary pane is still displayed at the top of the window. The selected frame is still highlighted in this pane.

Detail pane The detail pane is located in the middle of the window and contains detailed information about the layers of data within the frame. Each layer that appears with a plus sign (+) to the left of it can be expanded to display more information within the layer.

Hexadecimal pane The pane in the bottom of the window displays hexadecimal translations of the binary data in the frame. This is one of the most useful panes in the entire display. Notice the column of ASCII data to the right to the hexadecimal information. This column translates the binary data into plain ASCII text.

Any person running a network analyzer on your network has access to sensitive data as it passes across the wire. Fortunately for the network administrator, Network Monitor also announces its presence to other Network Monitor computers. When you’re actively capturing data, another Network Monitor computer can detect your capture. This feature helps to preserve the security of your network.

The version of Network Monitor included with Windows 2000 Server is a somewhat limited version. The full version of Network Monitor with all of the tools enabled is available only in Microsoft’s Systems Management Server (SMS). However, the limited version of Network Monitor will help you to diagnose traffic problems that exist between computers on your physical network.

Resolving NTFS permission issues and shared

resource issues

Sharing folders and printers on a server is not a particularly difficult task, but you may encounter some problems along the way. Typically, most problems arise because of the combination of NTFS file system permissions and shared folder permissions.


When dealing with share and NTFS permissions, there is a logical order in which to think about how they are applied. First, evaluate the NTFS file and folder permissions. The permissions are cumulative for the user. Next, evaluate the shared folder permissions. Permissions are cumulative here as well. Finally, compare the results of the two sets of permissions to find the effective permissions. When combining the results, take the most restrictive.

If you take this one step at a time, you’ll find that the process is actu-ally fairly simple. However, you may find that it will take a lot of practice before it becomes easy for you.

When the Deny permission starts getting used, things become more complex. In Windows 2000, all permission levels can be granted or denied. This is where your troubleshooting will become very compli-cated. Consider the example in Figure 5.10.

F I G U R E 5 . 1 0 : An example of Deny permissions

PublicPublic

NTFS

Group1 Group1

Group2 Group2

Group3 Group3

BobR BobR

= Modify = Read

= Deny Read = Deny Read

= None = Change

= Read and Write = Full Control

Modify (Deny Read)

Effective Permission = Modify (but Deny Read)

Totals = Full Control (Deny Read)


In this example, the Read permission is being denied to Group2. Because Group2 is being denied the Read permission, the NTFS permission becomes Modify without Read, and the shared permission becomes Full Control without Read. This is a rather interesting situation. It means that BobR will be able to write to the file, delete the file, or execute the file. But no matter what BobR does, he will not be able to read the file.

Imagine BobR’s confusion at having been granted Full Control permission for the shared folder and Modify for the NTFS folder when he cannot read the file. This can be a very difficult situation to troubleshoot. You’ll have to manually add up all of the permissions on both the NTFS side and shared folder side to determine where the problem lies. This problem arises because Windows 2000 always evaluates denied permissions before granted permissions.

There is one other issue with NTFS permissions that changed with Win-dows 2000, and that is the inheritance of permissions. In Windows 2000, the default behavior when applying permissions is that they will be inher-ited throughout the entire folder tree. This means that when you set a permission on one folder, it applies to everything in the folder and all subfolders automatically. The reason why this becomes important with troubleshooting permissions is that the permission causing your problem may be coming from a parent container rather than from the folder you’re trying to access.

When you apply permissions in NTFS, you have the choice of block-ing the inheritance or allowing the permissions to propagate down through all of the folders. When you use the Security tab of the folder’s Properties dialog to apply permissions, you can block inher-itance of the permissions by simply removing the check mark beside Allow Inheritable Permissions From Parent To Propagate To This Object.

If you remove the check mark for the inheritance, you’ll be asked how to apply the initial permissions. Windows 2000 needs to know what to do with the inherited permissions. Will you copy the previously inherited permissions to this object and then modify them from there? Are you going to remove the inherited permissions and keep only the explicitly assigned permissions? In Windows 2000, inheritance of permissions can


be a powerful tool in NTFS. But as with any powerful tool, it can also present a number of problems.

Consider an example of what can happen with inheritance. Say that you have applied explicit permissions to the root level of the hard drive on your Windows 2000 server and are counting on those permissions propagating downward. If you are unaware that someone has changed the permissions of a folder at a lower level, it may drastically change the security of your system. If this person were to block inheritance of permissions on the lower folder and apply permissions that opened up the security, people would be able to access sensitive data below that folder. On the other hand, that person may just as easily set permissions to prevent people from getting the data they need.

Resolving Shared Resource Issues

There are two possible courses of action to avoid problems in the future. It’s good practice to always apply Deny permissions to individual users rather than groups. Denying permissions to groups can cause conflicts when people are members of multiple groups. Denying permissions to an individual user, on the other hand, means that only one specific user will be blocked from that permission. This is the behavior that you actually intend in almost every case.

NOTE Use Deny permissions sparingly. Typically, they should only be used in emergency cases where you realize someone has access to critical information that they should not have. Deny them permission, and then go back and figure out what went wrong.

Nearly every case of permission issues is due to someone granting Deny permissions to a group. Remember that denying access will always override any granted permission.

Permission conflicts will account for most of the shared-resource access problems. But there are other issues that you may have to troubleshoot when accessing shared resources. If you can determine that the


problem is not caused by permissions, you need to start with basic network troubleshooting.

If you discover that you can connect to a server but are still unable to locate the shared resource, make certain that the resource is actually shared. Sharing a resource is easy to do, but also easy to forget to do.

Resolving authentication issues

When troubleshooting authentication problems, as with any other troubleshooting, always start with the simple things first. If you are unable to log on to a Windows 2000 computer, verify that the Caps Lock key is not turned on. In Windows 2000, usernames are not case-sensitive, but the passwords are.

The next most likely cause of logon problems is trying to log on to the wrong domain. Windows 2000 will attempt to validate your user account based on the location you define. If you give an incorrect domain location for your account, don’t blame the operating system when it fails to log you on. The standard method of logging on to Windows 2000 is to enter your username and password and use the drop-down list box to select the correct domain.

Windows 2000 also offers a new method of logging on to the domain. Instead of having to enter your name and domain separately, you can enter instead your user principal name (UPN). The UPN is your [email protected], and it uniquely identifies your user account name as well as its location in Active Directory. When you enter your UPN, Windows 2000 will gray out the box for selecting a domain. If you’re troubleshooting a logon problem, try having the user enter their UPN instead of their simple username.

Authentication problems reach beyond logon. You may be trouble-shooting the inability to access a shared resource because of an authentication problem. If you have more than one user account within the domain, this problem will be common. To determine how you are logged on to Windows 2000, press Ctrl+Alt+Del to open the Security dialog. The Security dialog clearly displays how you are currently logged on.


Resolving trust relationship and inappropriate

access issues

In Windows NT, trust relationships existed between only two domains, and they pointed in only one direction. What’s more, trust relationships in Windows NT were nontransitive, meaning that security information did not flow across more than one trust. In a native Windows 2000 forest, trust relationships are estab-lished automatically, are two-way, and are transitive.

In a Windows NT multiple domain environment, troubleshooting a trust relationship usually involved the flow of access from one domain to another. The trust relationship was established between two domains, but users still could not access the resource that they thought they should be able to access. Often it would be because the trust relationship was established in the wrong direction. This situa-tion can still occur with Windows 2000 domains that are running in mixed mode.

In a native-mode Active Directory environment, every domain in the forest has a two-way transitive trust with its direct parent and any child domains. This can cause some interesting situations to occur after migrating from a Windows NT environment. In a Windows NT environment, trust relationships are carefully crafted to allow resource access from domains housing the user accounts. If your migration plan calls for an upgrade of existing domains, you may discover that users now have access to resources that they were not able to reach before.

If the access permissions for resources are defined using domain groups, security will probably be preserved. If some of those domain groups also contain users or groups from other domains, however, you may be inad-vertently allowing access to unauthorized users. This is one of the rea-sons why a migration to a parallel Windows 2000 environment is a bet-ter migration than an upgrade of an existing environment. When you upgrade your domain structure to Windows 2000, you also maintain all of the existing problems in the network. When you replace the network with a parallel Windows 2000 network, you have the opportunity to start fresh and clearly define the security for the network.


Another trust issue that may arise in your network environment comes from the use of shortcut trusts. A shortcut trust is a trust that you manually establish between two domains in separate portions of an Active Directory network for the purpose of speeding up searches of Active Directory. For example, in Figure 5.11 the process normally used to browse for resources in Active Directory requires that you search from the Sales domain all the way to the root domain of cool-company.local and back down another branch of the tree to reach resources in the Marketing domain. Creating a shortcut trust from the Sales domain to the Marketing domain prevents a user from hav-ing to browse all the way to the root of the forest and back down the other branch.

F I G U R E 5 . 1 1 : The use of a shortcut trust can speed access to other branches of an Active Directory tree.

Shared folder

CoolCompany.local

Seattle.CoolCompany.localMarketing.CoolCompany.local

Shortcut Tr

ust

Sales.Seattle.CoolCompany.local

User


Shortcut trusts are established manually and have the same properties as trust relationships in Windows NT. This means that they are single-directional by default and nontransitive. If the two domains connected by the shortcut trust are native-mode Windows 2000 domains, the trust can be made two-way and transitive. You can even establish an external trust from a Windows 2000 domain in a forest to a Windows NT domain outside the forest. An external trust from a Windows 2000 domain to an NT domain will be single-directional and nontransitive. These trusts follow the Windows NT rules for trusts. You must point the trust in the correct direction in order to provide correct resource access.

If you have manually created trusts and determine that they cannot provide the correct access to resources, the best way to fix the prob-lem is to delete the trust and reestablish it. If the trust is a shortcut trust between two native-mode Windows 2000 domains, and you determine that the problem is due to a single-directional trust pointed in the wrong direction, you can also solve the problem by converting the trust to a two-way transitive trust.


The two necessary procedures for this objective deal with Network Monitor. It’s not the easiest or most intuitive tool to use, but prac-tice and time make it a useful troubleshooting resource. Remember that the version that comes with Windows 2000 is not Microsoft’s full version of Network Monitor. To get that, you need to purchase Microsoft’s Systems Management Server (SMS).

Capturing Network Traffic with Network Monitor

This procedure requires a Windows 2000 computer with Network Monitor installed. It also assumes that your Windows 2000 computer is connected to a local area network. It’s difficult to capture network packets if you are not attached to a network.

1. Open Network Monitor by clicking Start � Programs � Adminis-trative Tools � Network Monitor.


2. If your Windows 2000 computer has more than one network inter-face, you will be prompted to decide which network to capture traffic on. When you highlight each network interface, its proper-ties will be displayed in the pane on the right. This will help you to identify the correct interface for the capture.

3. Start the capture by selecting Start from the Capture menu. You should begin to see some activity in your network capture. If not, you may need to generate some activity by browsing the network or opening a file from another computer. Allow the capture to con-tinue for a few minutes, or at least until you have some activity recorded.

4. When you’re ready to end the capture, select Stop from the Capture menu.

5. Select Display Captured Data from the Capture menu to display the data that you just recorded from your network.

Analyzing Captured Data in Network Monitor

In this procedure, you analyze some of the data from your earlier capture. If you have not captured some traffic from your local net-work, please use the instructions from the previous procedure to perform a network capture now. Once you have captured packets, you can follow this procedure:

1. Display the data in your network capture by selecting Display Captured Data from the Capture menu.

2. Browse down the Protocol column until you locate a frame that reads ARP_RARP.

3. Double-click this frame to see its information.

4. In the details pane, double-click the plus sign beside Frame. This will expand the properties for the Frame layer. This layer is not actually a part of the network frame, but instead is included by Network Monitor to describe the properties of the frame itself.

5. Now double-click the plus sign beside ETHERNET. This will expand the properties for the Ethernet header on the frame. In this


section of the frame, you can find information about the source hardware address of the client making the request, as well as the destination hardware address. The purpose of an Address Resolu-tion Protocol (ARP) frame is to resolve an IP address to a hardware address. Notice that the destination address is FFFFFFFFFFFF, which is the hardware broadcast address. Since the client does not know the hardware address of its destination computer, it must send the request to the broadcast address. The destination com-puter will hear the broadcast and respond by sending back its own hardware address.

6. Now double-click the plus sign beside the ARP layer. This will expand the actual packet of information being sent across the wire. Notice that the terms packet and frame, although often used interchangeably, are different. A packet is the chunk of data being sent, while frame refers to the entire pattern being sent across the wire, including all of the header information defining the structure of the data.

7. An ARP request is a very simple frame of data. Browse to some of the other frames of information recorded in your capture. You’ll no doubt find some frames that are much more complex than an ARP frame.

Exam Essentials

Know how to resolve computer connectivity issues. The first step in resolving connectivity issues is to determine whether it’s a con-nectivity problem or a name-resolution problem. Obviously, if you can’t connect with an IP address, it’s connectivity or configuration. If you can ping the target by IP address, but not by name, it’s a name-resolution problem. Check your DNS servers.

Understand new permission issues. With Windows 2000, the Deny permission will cause issues for people familiar with Windows NT’s security structure. A specific Deny overrides a specific Allow. Otherwise, figuring out effective permissions is the same as NT.


Know how to figure out effective permissions in Windows 2000. It’s a three-step process. First, take all NTFS permissions and combine them. Then, take all share permissions and combine them. Take the final per-missions from the first two steps, and use the most restrictive.

Know how Windows 2000 deals with trust relationships. In a for-est, Windows 2000 creates two-way transitive trusts between parent and child domains. This effectively allows any user in any domain the ability to access resources in any other domain. You can also create trust relationships manually.


effective permission Permission the user has on a given resource after all assigned permissions are calculated.

frame A complete chunk of data, including header and footer infor-mation. Often called packets, frames are frequently composed of multiple packets.

nslookup DNS troubleshooting utility included with Windows 2000.

packet Individual piece of information sent across the wire on a network.

shortcut trust Explicit trust created between two domains to speed up resource access across domains. Often created between distant domains in a tree or forest.

user principal name (UPN) Complete name that identifies the user and the domain they belong to when they attempt to log on. It takes the form of [email protected].

�Troubleshoot network services problems for all types of migrations.

Network services play critical roles for the proper functioning of a Windows 2000 Active Directory domain. It’s been said before,


and it will be said again, that DNS is crucial for Active Directory. However, other services provide vital roles as well.

All major network services are covered in this objective. This includes DNS, RRAS, replication, DHCP, and WINS. These topics are typically tested heavily. Knowing how to implement them is one thing, but being able to fix them can be another story.


This objective goes into more depth about troubleshooting name resolution, especially the Domain Name System (DNS), exploring some of the more serious symptoms of name-resolution issues. Also examined are the entries that Windows 2000 places in DNS to provide domain logon services to Windows 2000 clients. The Windows Internet Naming Service (WINS) service also plays a role in a Windows 2000 environment.

Issues you may encounter in supporting the Remote Access Service (RAS) in Windows 2000 are covered, and closely related are policy changes that will affect your users when they dial in and connect to the RAS server. File Replication Service (FRS) is the new replication method, and is covered too. Lastly, you need to spend some time examining how to recover DHCP, WINS, and DNS.

Resolving name-resolution issues

DNS is the primary and default method of name resolution in a Windows 2000 environment. Windows 2000 also supports Net-BIOS name resolution using either the LMHosts file or a WINS server, though it doesn’t require NetBIOS at all. It supports a Hosts file for static hostname resolution, and it will also fall back to broadcasting in the local subnet.

Most of the time when you work with name-resolution issues on Windows 2000 networks, you’ll be working with DNS. The pri-mary tool for troubleshooting DNS is NSLookup. NSLookup can be used in two modes: The interactive mode can be used to run


multiple queries against the DNS server, and the single-query mode can be used to submit a single query.

Understanding NetBIOS Name Resolution

Before you can readily understand name resolution in Windows 2000, it’s helpful to become acquainted with the name-resolution techniques that the operating system will attempt to use. The operating system will use the following methods in the order listed to resolve NetBIOS names:

NetBIOS name cache NetBIOS maintains a local cache of all names that have been recently resolved. During any NetBIOS name-resolution attempt, this cache will be checked first to see if the information already exists locally. If the resolution exists in the cache, the IP address of the destination can be passed immediately to IP for hardware address reso-lution using the Address Resolution Protocol (ARP). The NetBIOS name cache can be preloaded with static entries by using the #PRE command in the LMHosts file. The #PRE entries will remain in the NetBIOS name cache until the computer is rebooted. Other cache entries will be period-ically flushed from the NetBIOS name cache.

NetBIOS name server The next step in name resolution is to consult a NetBIOS name server (NBNS). In a Windows 2000 or Windows NTnetwork, this would be a WINS server. WINS is a dynamic database of NetBIOS-name-to-IP-address resolutions. Client computers must be configured with the address of at least one WINS server before they can take advantage of this service on the network.

Broadcast If the previous methods fail, the client computer will attempt to resolve the NetBIOS name through a broadcast on the local subnet. This is perhaps the biggest problem with NetBIOS: It uses broadcasts for several of its functions. The broadcast will succeed if the destination computer is online and located on the same physical network segment as the client computer.

LMHosts file The LMHosts file is a static text file that maintains a list of NetBIOS-name-to-IP-address resolutions. The LMHosts file is similar in structure to the Hosts file used for hostname resolution, but it also includes several commands that can modify the behavior of the NetBIOS client. These include the #PRE command, which will insert a


name-resolution entry into the NetBIOS name cache when the computer is started.

Hosts file A NetBIOS name-resolution method that surprises many people is that Windows 2000 will check the Hosts file for a resolution. The Hosts file is a static text file that contains hostname-to-IP-address resolutions. Windows 2000 is making a big assumption here—that the hostname and the NetBIOS name of the destination computer are the same. They don’t have to be, but the default action in Microsoft network operating systems is to make them the same.

Domain Name System DNS is a server-based method of resolving hostnames to IP addresses. But Windows 2000, still operating on the assumption that the hostname is the same as the NetBIOS computer name, will try to query its configured DNS server to resolve the NetBIOS name. This is another of Microsoft’s propri-etary methods, though it’s actually fairly clever.

NOTE A helpful mnemonic device for memorizing the order of Net-BIOS name resolution is “Can We Buy Large Hard Drives?” This rep-resents Cache-WINS-Broadcast-LMHosts-Hosts-DNS.

The first three methods are fairly reliable. The NetBIOS name cache will always contain correct information provided the source of the information is correct. If there is any doubt of the validity of the cache information, you can easily purge the NetBIOS name cache by using the NBTStat –R command from the command line. Note that the –R switch is case-sensitive. This command will purge the NetBIOS name cache and also preload the new cache with the #PRE entries in the LMHosts file, which can be very useful while troubleshooting NetBIOS name resolution.

WINS will be covered in more detail later in this objective, but essen-tially the database should contain only name-resolution entries sub-mitted by client computers. Thus, the information should be correct. Of course, if computers go offline suddenly or are improperly shut down, they won’t have the opportunity to release their registrations


from the WINS database, and so the information may no longer be correct.

NetBIOS name resolution by broadcast works just fine, as long as you understand its limitations. The biggest limitation is that these broadcasts are confined to the local subnet by design. This is because routers are typically configured to block broadcasts. Of course, broadcast resolution also depends upon basic networking requirements, such as a common protocol and correct addressing.

The remaining methods of NetBIOS name resolution are really more of a last-ditch effort to resolve the name. Of the remaining methods, checking the LMHosts file is the most reliable. The limitations of this file are mainly that it is static and that it falls victim to any name mis-spellings that you placed in the file. Otherwise, checking the LMHosts file is actually a good method of NetBIOS name resolution.

Microsoft’s use of DNS and the Hosts file for NetBIOS name resolution is based on the assumption that the hostname and the NetBIOS com-puter name are one and the same. This is the default on all Microsoft net-work operating systems, but it does not have to be the case.

NOTE If your computer has not resolved the NetBIOS name by the time it’s done examining the LMHosts file, chances are it will not resolve the name at all.

USING LMHOSTS FOR NETBIOS NAME RESOLUTION

The LMHosts file is a little known or understood file nowadays. Back in the days of Windows for Workgroups, the LMHosts file was com-monly used for NetBIOS name resolution. Table 5.1 lists the com-mands used in the LMHosts file.

The LMHosts file is parsed from the top down. This means that an incorrect entry near the top of the file will be read instead of the cor-rect entry at the bottom of the file. For this reason, you should be very careful about duplicate entries. Always place the #PRE state-ments at the end of the file. Because these statements are preloaded


into the NetBIOS name cache, they need to be read only at the startup of the computer or when the NetBIOS name cache is flushed. This will save you time when parsing the LMHosts file for other resolutions.

T A B L E 5 . 1 : Available Commands for the LMHosts File

Command Description

#PRE Preloads the entry into the NetBIOS name cache. The #PRE command is often used to define important servers or in conjunction with the #DOM command to identify domain controllers.

#DOM:domain_name

Identifies a domain controller. This command is also used to locate a master or backup browser on remote subnets.

#BEGIN_ALTERNATE

Begins a list of possible locations for alternate LMHosts files. The list is typically redundant in that the client can draw the LMHosts information from any single location. Identify these locations by the Universal Naming Convention (UNC) path for best results.

#END_ALTERNATE Signifies the end of the alternate location list.

#INCLUDE Defines the UNC path to a centrally located, shared LMHosts file. This command instructs the local computer to also use the defined LMHosts file for NetBIOS name resolutions. The #INCLUDE com-mand makes it possible to maintain one central copy of the LMHosts file, while the only items defined in the local LMHosts file would be the #INCLUDE command and the resolution for the server where the included file resides. The path should be defined by UNC for best results.

#MH Enables you to list multiple IP addresses to be asso-ciated with a single NetBIOS name. Used for multi-homed computers, or computers with more than one network interface card.


NOTE A sample LMHosts file is located on all Windows 2000 com-puters in the \%systemroot%\system32\drivers\etc directory.

The LMHosts file must be a plain ASCII text file in order to be used correctly. Since Windows 2000 has the ability to save files as Unicode text, it is important to specify this. Unicode text stores each character with two bytes, whereas ASCII text uses only a single byte per character. If you save the LMHosts file as anything but ASCII text, Windows 2000 will not read the file and NetBIOS name resolution will fail. This caution also extends to editing the LMHosts file with WordPad.

NOTE For an LMHosts solution to work, every computer on the network (that wishes to resolve names) must have a current copy of the LMHosts file.

Understanding Hostname Resolution

Hostname resolution in Windows 2000 bears many similarities to NetBIOS name resolution. In fact, the same resolution methods are used but in a different order. Since Windows 2000 uses hostnames rather than NetBIOS names for primary name resolution, this process is critical to the success of your Windows 2000 network.

Windows 2000 will attempt to resolve the hostname in the following order:

Local hostname The computer will first check its own configured host-name to see if it matches the destination hostname. If it does, it commu-nicates directly with itself. If it does not match, the name-resolution process continues.

Hosts file This text file will be parsed next to see if there is an entry that resolves the destination hostname to an IP address.

Domain Name System DNS is a server-based method of resolving hostnames to IP addresses. DNS is required if you plan to use Active Directory.


NetBIOS name cache Before proceeding to any NetBIOS name-resolution attempt, Windows 2000 will check this cache first to see if the information exists locally. If the resolution exists in the cache, the computer will assume that the NetBIOS name is the same as the hostname and attempt to contact the computer at the address listed in the cache.

NetBIOS name server The next step in hostname resolution is to consult a NetBIOS name server. In a Windows 2000 or Windows NT network, this would be a Windows Internet Naming Service (WINS) server. Again, the computer is making the assumption that the Net-BIOS name and the hostname are the same; otherwise, this method will not work.

Broadcast If the previous methods fail, the client computer will attempt to resolve the NetBIOS name through a broadcast on the local subnet.

LMHosts file The LMHosts file is a static text file that maintains a list of NetBIOS-name-to-IP-address resolutions. If the NetBIOS name is the same as the hostname, and if it is listed in the LMHosts file, then name resolution will succeed with this method.

If none of these name-resolution methods succeeds, then the only way to communicate with the destination host will be to use the IP address.

NOTE If the computer gets through the Hosts file without a success-ful resolution, the query will likely fail.

UNDERSTANDING THE HOSTS FILE

The Hosts file is a static text file that maintains hostname-to-IP-address resolutions. Like the LMHosts file, the Hosts file must be plain ASCII text in order to be read by Windows 2000. The Hosts file is parsed from the top down, and so duplicate entries may cause problems. Figure 5.12 shows a sample of the Hosts file.


F I G U R E 5 . 1 2 : A sample of the Hosts file

Comments in the Hosts file are preceded by the pound symbol (#). Notice in the sample in Figure 5.12 that some of the entries simply have hostnames listed, while others have a fully qualified domain name (FQDN). An FQDN includes the hostname and the domain name of the destination host.

If an entry in the Hosts file does not have a domain name specified, the computer will assume that the hostname exists within the same domain. That is to say, if my computer does not see a domain name appended to the hostname, it will append my domain name. The Hosts file entries are better defined by a FQDN if the host’s domain name is different from your computer’s domain name.


NOTE When discussing hostname resolution, the term domain refers to a DNS domain and not to a Windows 2000 domain. This similarity of terms has been very confusing for years, and it has become even worse with Windows 2000 since Windows 2000 uses DNS names for its domain names.

You may have also noticed in the sample Hosts file that the IP address is followed by a hostname and sometimes by another name. The first name listed is the actual hostname of the destination computer. The second name listed (if present) is an alias for the hostname. It is not uncommon in Microsoft network operating systems to see the host-name listed in lowercase followed by the hostname in uppercase as the alias. Windows 2000 is case-insensitive when dealing with the Hosts file. This means that listing the hostname in uppercase as the alias entry is completely optional. On the other hand, if you wanted to list a true alias name for the host, enter the alias name as the second name for the entry.

There must be a Hosts file on each computer. At a minimum, the Hosts file must contain an entry for localhost resolved to the IP address 127.0.0.1. Localhost is another name for the local computer. Since the Hosts file is parsed from the top down, you should place the most commonly referenced hostnames at the top of the Hosts file. Another restriction on the Hosts file is that each entry can be no more than 255 characters in length. The Hosts file is located in the follow-ing path on Windows 2000: %systemroot%\System32\Drivers\Etc. The Hosts file can have no file extension. Windows 2000 will ignore any Hosts file with a file extension.

Understanding the various methods of name resolution in Win-dows 2000 will help you in troubleshooting. For instance, if you are unable to connect to another computer using the name, you can try using the IP address. If you can connect by IP address but not by name, this is a clear indication that name resolution is fail-ing. To test NetBIOS name resolution, use the Net View command at the command prompt. This command will attempt to resolve the


name using NetBIOS and will list the shared resources on the remote computer. To test hostname resolution, ping the remote host by its host-name. If this fails, ping the remote host by its IP address.

When troubleshooting name resolution, always remember the LMHosts and Hosts files. If the client computer is having trouble with name resolution, verify that it isn’t receiving bad information from either the LMHosts or the Hosts file. Be very careful to check for the presence of duplicate entries in either of these files. If the incorrect entry is in the LMHosts file and has been preloaded with the #PRE statement, you’ll need to clear the NetBIOS name cache after correct-ing the entry.

Resolving remote access permissions failures and

logon failures

The Routing and Remote Access Service (RRAS) in Windows 2000 enables clients to dial up and connect to your network from remote locations. RAS is the component of Windows 2000 that enables inbound connections over serial lines, ISDN, or direct cable con-nections. Because it covers so many components, it can be very diffi-cult to troubleshoot.

Troubleshooting the Physical Components of RAS

The physical components of RAS can be broken down into two sections: the physical hardware and the communication line. Windows 2000 pro-vides several tools for troubleshooting computer hardware, including Device Manager, Event Viewer, and Phone and Modem Options in Con-trol Panel. But before you move on to any of these tools, the first thing that you should do in troubleshooting RAS is to carefully write down any error messages you receive. This often-neglected step will enable you to find the correct answer in Microsoft’s Knowledge Base.

If you receive an error message from the modem diagnostics, you can try uninstalling the modem and reinstalling it. Another possibility is to check the Web site for the modem’s manufacturer to see if they have any white papers or software updates that will solve the prob-lem. If these steps do not resolve the problem with the modem, you must proceed with hardware troubleshooting.


Troubleshooting the communication lines can be a little more diffi-cult. The troubleshooting methods are indirect in nature. If you’re dealing with a normal analog phone line, you can simply plug in a telephone to see if the line is active. You can check a digital line with a digital phone. If the line outage is intermittent in nature, you may not be able to catch it in progress. Here the system event log will be helpful to you, as it records any intermittent failures that RAS detects.

Another possible cause of intermittent line failures is faulty hardware in the computer. Always check the serial ports to see if they are func-tioning correctly and are correctly configured in the system BIOS. If you have a multiport adapter, such as the DigiBoard, you can try run-ning the system diagnostics software for the card. When you examine the system log for errors due to faulty hardware, you will see that the modem port in question will appear to be unused even during periods of high activity.

Verifying RAS Configuration

Troubleshooting RAS configuration must be done in one of several different ways, depending upon the type of error that is being encoun-tered. If the RAS client can dial in and appears to connect correctly-but is still unable to access network resources, then you need to troubleshoot network connectivity issues. If the client computer can dial up successfully but never connects to the server, then you need to troubleshoot the client’s configuration. If none of the client computers can connect to the server, you need to troubleshoot the server’s con-figuration.

Most often the troubleshooting you’ll need to do for RAS configura-tion will involve the client computer. The first step you should take in troubleshooting the client, after writing down any error messages received, is to check the Event Viewer’s system log. Once you’ve com-pleted this step, verify the setup of the physical hardware. When you’re satisfied that the hardware is working correctly, move on to the logical setup of the connection. Verify that the Phone Book entry is configured correctly for the type of server being dialed in to. Pay particular attention to the security settings for the Phone Book entry.


You’ll often discover that the problem stems from a change that the user made in their configuration. To quickly determine whether the problem stems from a configuration error on the client computer, re-create the Phone Book entry for the server. If the newly created Phone Book entry works to connect to the remote access server, you’ll know that the original Phone Book entry was configured incorrectly.

While RAS problems happen less frequently with the server, you do have better tools for troubleshooting from the server end. Of course, some rules remain the same. Always write down the error message you receive, as this will shorten your troubleshooting a great deal. Next, check the event logs for any events that may give you a clue as to what is happening when the clients dial in to the server. The final step that you can take is to trace remote access connections.

Monitoring the Remote Access Service

Microsoft has incorporated several different types of monitoring for the RAS. There are three basic types of monitoring for RAS that will be helpful to your troubleshooting efforts: the event logs, modem logging, and tracing RAS connections.

The event logs are the first place you should check when trouble-shooting an issue in Windows 2000. The system log will commonly contain information that will help you troubleshoot operating system components or hardware problems. Any problems regarding RAS will be listed in the system log.

Windows 2000 is capable of automatically recording a log of all communications made from the computer to the modem during the connection. By default, Windows 2000 Professional has this logging enabled. On the Windows 2000 Server products, the log-ging must be enabled manually.

NOTE In Windows NT, you had to edit the Registry to enable modem logging, called the “device log.” Windows 2000 allows you to enable modem logging through Modem Properties.


After enabling modem logging, when you want to view the modem log go back to the Diagnostics tab in the modem Properties dialog and click the View Log button. The modem log will display details of all modem activity and may be used to troubleshoot connections.

The last type of monitoring available for RAS is to trace connections. Connection tracing collects very detailed information about the routing of packets from RAS to the network interfaces on the computer. The information gathered is very complex, but may be useful. Tracing also consumes a large amount of computer resources and so should not be left enabled for a long period of time.

Resolving file and directory replication issues

Windows NT offered the Directory Replication service to assist in moving files from one domain controller to another. This was used primarily for logon scripts and policy files. It was one of the more problematic services ever invented for Windows NT, as it could be very cranky and difficult to configure initially. Directory Repli-cation in NT used an export computer to send the original versions of the files out to other computers that were designated as import computers.

Windows 2000 has several different requirements for file repli-cation. Logon scripts and policy files are still replicated, but there is also a need to replicate the Active Directory information and the data used by the Distributed File System (Dfs). To answer these needs, Windows 2000 includes the File Replication Service (FRS). Enhancements to FRS over Directory Replication include:

Multimaster replication Windows 2000 uses a multimaster replication model. This means that there is no single source for replicated infor-mation, but rather multiple sources for replicated data. FRS includes the ability to track changes being made by multiple replication masters.

Site-aware clients All of the Active Directory clients have the ability to query DNS to locate servers hosting the Sysvol. These clients use this awareness to locate domain controllers and servers hosting Dfs resources.


Scheduling capability Portions of FRS can be scheduled for available replication times and frequency of replication.

Replication of all attributes FRS is able to replicate all of the attributes of files, including ACLs. This enhances the ability to create complete replicas of data on multiple servers while maintaining the security of the resources.

While Active Directory replication and FRS are technically separate, Active Directory replication does depend on FRS to move several portions of its data. For example, the Sysvol stores portions of Active Directory’s Group Policy structures, and FRS is responsible for repli-cating the Sysvol. Just as the Sysvol is automatically created on every Windows 2000 domain controller, replication of Sysvol using FRS is also enabled by default. When replicating the Sysvol objects, FRS will use the same connection objects as Active Directory replication uses. Therefore, FRS will also be affected by any scheduling you impose upon Active Directory replication connections.

NOTE Because FRS practices multimaster replication, it can be difficult to determine where the originating copy came from. To test whether FRS is replicating correctly, create a sample file in Sysvol named after the server where the file is placed. You can then verify that the other servers are receiving correct replication by checking for the test file in their Sysvol.

Replicating Dfs

The Distributed File System enables Windows 2000 administrators to share resources from multiple servers as though they were located on a single server. Users can connect to the Dfs root and browse through a folder structure that appears to be one single hard drive, when actually the folders may be located on a variety of different servers.

Dfs can be installed in stand-alone fashion on a Windows 2000 mem-ber server, or integrated with Active Directory on a domain controller. A stand-alone Dfs root stores all of the topology information on that server and does not use Active Directory to replicate information. If Dfs


is integrated with Active Directory, information about the folder struc-ture is replicated automatically as part of Active Directory. However, the data must be manually enabled for replication in the Dfs console before it will be shared with other servers.

There are a few instances when replication will not be an allowable option for a Dfs replica. In these cases, the shared folder will appear as N/A:

� When the shared folder is located on a computer that does not have FRS installed

� When the shared folder is located on an NTFS partition that has not been updated to NTFS version 5

� When the shared folder uses a cluster name as part of its path

� When the shared folder is located on a computer that is not a member of a Windows 2000 domain

� When the shared folder is located on a computer in a domain that is inaccessible to the currently logged-on user

If you are trying to configure Dfs replication and the console will not permit you to establish replication, carefully check out these five possibilities. Typically, problems with Dfs replication stem from configuration more than any other issue.

When dealing with possible conflicts in replicated data, FRS uses a “last writer wins” algorithm. That is to say, FRS checks the time stamp of the last change and decides that is the most recent infor-mation and writes that to the data.

It is possible that during a migration to Windows 2000, you will see file replication problems. This is likely due to the transition from directory replication to FRS.

Windows 2000 does not support the directory replication that was used in Windows NT. This can create problems if you need to maintain a mixed environment of Windows 2000 and NT servers. Do not confuse this with mixed-mode operation in a domain. Mixed environment means a Windows 2000 domain with a few Windows NT servers that


need to participate in file replication. To accomplish this, choose one of your Windows 2000 servers to be a bridgehead for replication to the Windows NT servers. You will then need to write a script that will copy the necessary files from the Windows 2000 server to the correct folder on the Windows NT server. The directory replication service on NT can then move the files from that NT server to all of the other NT servers.

FRS will display its events in the system log. When troubleshooting FRS, check the system log to see if events are being filed for the staging direc-tory that’s filling up. If this directory fills up, FRS will be unable to do its job correctly. Next, check the Services console in the Administrative Tools group to verify that FRS is started and correctly running. You’ll need to do this on all computers involved in the replication issue. When checking the System Log in Event Viewer, look to see if event number 13508 is present. This event signifies an issue with RPC communication between servers. If this number is present, there could be a problem with the RPC services on either of the computers. Other events to watch out for include 13511, database is out of disk space, and 13522, staging directory is full.

Replicating Active Directory

There are two basic types of replicas of the Active Directory information: full replicas and partial replicas. Full replicas contain all three of the following partitions:

� The schema partition, which contains all class and attribute defi-nitions for the entire forest. There is only one schema partition for the forest.

� The configuration partition, which contains replication configuration information for the entire forest. There is one configuration partition per forest.

� The domain partition, which contains all objects that are stored within a single domain. There is one domain partition for each domain in the forest.

Every domain controller within a domain contains a full replica of the domain partition. Every domain controller within a forest contains a rep-lica of the forest configuration and schema partitions. A partial replica


contains only a subset of Active Directory information, is set to Read Only, and is stored only on a global catalog server.

On any given domain controller, a single Active Directory data-base stores copies of the objects that belong to that domain only, in addition to copies of the schema in the configuration objects that apply to every domain in the forest. If the domain controller is also a global catalog server, the database will also contain a partial replica of directory partition objects for every domain within the forest. The partial replica is stored on global catalog servers to facilitate searches of Active Directory.

The components of the Active Directory replication model include:

Multimaster loose consistency with convergence Multimaster refers to the fact that Windows 2000 has multiple sources of repli-cated information instead of a single authority. Any single domain controller can be modified and will then replicate that modification to all other domain controllers within the domain.

Loose consistency refers to the fact that replicas are not guaranteed to be consistent with each other at any given point in time. Convergence means that if no changes are made for a period of time and the domain controllers are allowed to become stable, then all replicas of Active Directory will converge on a single given version.

Store and forward replication Windows 2000 domain controllers replicate changes in Active Directory to only a few domain controllers. Those domain controllers then pass on the information to other domain controllers. This pattern continues until the changes have been replicated to every domain controller within the domain.

Pull replication In the Windows 2000 replication model, domain controllers request changes from the replication partners, or “pull” the changes down from their replication partners.

State-based replication Windows 2000 does not store a full change log for Active Directory replication. Instead, each Active Directory partition stores per-object and per-attribute data for the replication.


Windows 2000 automatically builds the replication topology for Active Directory by using the Knowledge Consistency Checker (KCC). The KCC is the built-in Windows 2000 process that ensures synchronization of Active Directory throughout the entire forest. If you have more than one site, the KCC also manages site links.

There are several errors you may encounter in Active Directory replication. To fix many of the common problems, use the Active Directory Sites and Services console. Some of the common prob-lems in Active Directory replication include:

Replication does not complete This is more common in multisite Active Directory environments. The problems are caused by some sites not being connected to other sites and the network. You can correct this in the Active Directory Sites and Services console by creating a site link from the current site to another site that is con-nected with the rest of the network.

Replication is slow This can happen when your sites are connected in a daisy-chain pattern. Site link scheduling can add to this problem if the site links are available only during off-hours or at longer than normal intervals.

Replication causes an increase in network traffic This one may be difficult to fix, since it points to the fact that your network may not be capable of handling the network traffic that is present. You may need to investigate segmenting your network further with additional routers, increasing the throughput of the network by going to a faster network medium, or reducing network load. As a temporary fix, use Active Directory Sites and Services to adjust the scheduling on site links so that the replication can occur during off-hours.

The KCC is unable to complete the topology for given serverThe KCC locates all domain controllers by querying DNS and looking for Service (SRV) records. If the SRV records are missing for a domain controller, then that domain controller may not be added to the replication topology.


Some of the practices you can use to avoid problems with Active Directory replication include:

� Schedule Active Directory replication across site links for times when traffic is light. This will help to alleviate the burden on the network that is caused by Active Directory replication.

� Place at least one domain controller in every physical site throughout your forest. This will help to ensure that no clients will have to go across a WAN link in order to find the server for authentication.

� Install at least one DNS server in every physical site.

� Place a global catalog server in every physical site. Universal groups are stored only on global catalog servers. If a client computer is unable to contact the global catalog server to retrieve universal group mem-bership information, the user will be unable to log on to the domain.

Resolving network service issues

The three major network services that provide support for a Win-dows 2000 network are: the Dynamic Host Configuration Protocol (DHCP), the Windows Internet Naming Service (WINS), and the Domain Name System (DNS).

When troubleshooting network services, it’s useful to understand where to find the configuration information for each service. Services and devices are no longer controlled from the Control Panel, but rather from the Services console in the Administrative Tools group. Figure 5.13 shows the Services console.


F I G U R E 5 . 1 3 : The Services console gives you access to all Windows 2000 Services configurations.

When you want to modify the properties of a service, simply double-click the Services entry in the Services console. The Properties dialog for any given service offers tabs that allow you to enter the informa-tion to control how the service will behave.

The Properties sheets for a given service have some very nice capabil-ities. Here are the tabs of the Server Properties dialog:

General tab The General tab allows you to modify properties such as the display name of the service, its description, and its startup type. The General tab also has the buttons for starting or stopping the service.

Log On tab The Log On tab allows you to determine which account the service will use to log on to the server during startup. This


tab also allows you to enable or disable the service for a particular hardware profile.

Recovery tab You can use the Recovery tab to specify what action the operating system should take if the service fails for any reason. You can select Run A File, in which case if the service fails, it will launch a particular file that you specify. A nice option that is included here is the ability to have the service automatically restart if it fails.

Dependencies tab The final tab of the four enables you to determine which other services must be loaded before the service can start successfully.

DHCP

Two main aspects of DHCP have changed with Windows 2000. The first is that all DHCP servers in an Active Directory environment must be authorized in Active Directory before they will be permitted to hand out client leases. This is to prevent rogue DHCP servers from handing out bad addresses on the network.

The second change in DHCP is its participation in dynamic DNS. The process by which dynamic DNS works depends upon the participa-tion of the DHCP server that is handing out client leases. By default, when the DHCP server issues the client lease, it notifies the DNS server of the reverse lookup information. The DHCP client is then responsible for notifying the DNS server of the forward lookup information. The DHCP service in Windows 2000 can be configured to create both portions of the dynamic DNS entries.

Authorization of DHCP servers will be a common issue during migrations to Windows 2000; it will probably also be a question that appears frequently on the exams.

If you’re troubleshooting dynamic DNS and want to find out why some clients are not being registered correctly, you’ll want to check the DNS configuration of your DHCP server service. These proper-ties are set at the DHCP server level and apply to every scope within the DHCP server. The DNS tab of the DHCP Properties dialog, as shown in Figure 5.14, enables you to set the properties for dynamic DNS updates.


F I G U R E 5 . 1 4 : The DNS tab of the DHCP server Properties dialog

By default, DHCP will only inform the DNS server of an inverse query for clients that request the service. You can select the option to always update DNS for every DHCP lease it has handed out. You can also determine whether the DHCP server will enter only inverse query information or if it will update both the forward and inverse lookup.

DHCP is derived from the Bootstrap Protocol (BootP) and is broadcast based on the initial lease acquisition. Because routers normally are configured to block the propagation of broadcast traffic, you must be certain that the router will allow the DHCP broadcast to propagate. Depending on the router operating system, you may see this option listed either as BootP propagation or as RFC 1542 compliance.

If the routers on your network are either unable to propagate BootP packets or not configured to do so, you must find another way for your clients to contact DHCP servers. There are two possible solutions to this situation. The first involves the use of the DHCP relay on remote


subnets to the DHCP server. The second solution is to place the DHCP server on every subnet of your network.

WINS

WINS is no longer truly required for network communication in Windows 2000. However, it is still provided with Windows 2000 Server products in order to support backward compatibility. Windows 9x and Windows NT clients depend on NetBIOS name resolution to communicate. WINS provides them with this service.

Some of the ways you can recognize a problem with the WINS server would be error messages stating that the RPC server is unavailable, or that the TCP/IP NetBIOS helpers service on the WINS client is down and cannot be started, or that WINS itself is down and cannot be started. When you suspect that you are experiencing the WINS issue, you should first verify that WINS is actually running on the server and that the client can connect to the server. If the service is not running, try to start it.

If WINS still refuses to start, the database may be corrupted. WINS normally maintains a backup of the WINS database at all times and will restore it automatically when the service starts. Although the res-toration of a backup copy of the database will happen automatically if WINS detects corruption in the primary database, this occasionally fails. The WINS database is a Jet database entitled WINS.mdb, located in the systemroot\system32\WINS folder. If you suspect that the database has become corrupt, or simply that it is becoming fragmented and performing poorly, you can compact the database to restore perfor-mance by using jetpack.exe.

Here are some other common problems you may encounter with WINS, along with their solutions:

Network path not found If you’re trying to connect to another com-puter and WINS does not have a name resolution for the computer, it could be that the destination computer is not a WINS client. Possible solutions for this situation include enabling the computer as a WINS client or adding a static mapping for the destination computer in the WINS database.


Unable to replicate If two or more WINS servers are unable to replicate their database information, you must check the replication configuration on each of the WINS servers. Typically, replication issues stem from configuration mistakes and sometimes from network-connectivity problems.

Duplicate name errors To troubleshoot this problem, look in the WINS database for the name that generated the error to see if more than one computer is registered for that name. If so, and if one of them is a static entry, delete the static entry to resolve the problem.

DNS

Troubleshooting DNS is an art form in itself. Here are some rather common issues you might encounter with Windows 2000 and DNS:

Event ID 7062 This error signifies that the DNS server has sent a packet of information to itself. Normally, this is caused by a miscon-figuration of the server. Typical causes of this problem are that the DNS server lists itself as a forwarder or that it contains secondary zones that list it as the master. Another possible cause would be if the server contains a primary zone that lists the server in the notify records.

Zone transfers to BIND are slow The DNS server in Windows 2000 supports fast zone transfers. A fast zone transfer means that records will be compressed and that each message sent to another DNS server will contain multiple records. This enables a much faster transfer of zone information between servers. The problem is that older versions of the Berkeley Internet Name Domain (BIND) do not support fast zone trans-fers. Normally, Windows 2000 installs DNS with fast zone transfers disabled by default. If you have enabled fast zone transfers and you have BIND 4.9.4 servers or older on the network, the BIND servers may have great difficulty handling the fast zone transfers. If this occurs, you’ll need to disable fast zone transfers on the Windows 2000 DNS servers.

Default servers are not available When troubleshooting DNS with NSLookup, you may receive an error message that the default servers are not available when you start the command. This problem occurs when NSLookup cannot find the PTR record for the DNS server. If you receive a message that the default server is not available, you


should check your inverse lookup zone to make sure that there is a PTR record for the DNS server.

DNS server returns incorrect data Traditionally, DNS zone files have been manually configured. If your DNS server returns the incor-rect IP address for the hostname, it is possible that you made a mis-take when you configured the entry in the DNS console. This problem should never occur with dynamically created DNS entries, since the DHCP server that assigns the IP address entered the resolution infor-mation and DNS directly.

Dynamic updates to DNS can also be problematic at times. A new command switch for IPConfig is /registerdns. This switch forces a Windows 2000 computer to renew its dynamic information in DNS. It may take a few minutes for this update to take effect, but it can solve many problems.


This objective has three procedures pertaining to network services and related issues. Avoided here are procedures relating to DNS. Even though DNS is possibly the most critical Windows 2000 service, it was covered in Chapters 1, 2, and 3 in greater detail. Here, the focus is on RAS, which involves modems to a great extent.

Troubleshooting a Modem

If you are going to use RAS, you need a modem. Of course, it helps if the modem is working properly. To check your modem to make sure it’s working in Windows 2000, follow this procedure:

1. Choose Start � Settings � Control Panel to open Control Panel.

2. Double-click Phone And Modem Options to open the Phone And Modem Options dialog.

3. Click the Modems tab.

4. Select the modem you want to troubleshoot, and click the Properties button.


5. In the modem Properties dialog, click the Diagnostics tab.

6. Click the Query Modem button. The test may take a few seconds. You will receive either a report if the test passed or an error message saying that Windows 2000 couldn’t communicate with the modem.

Enabling Modem Logging

Logging is especially helpful if you want to monitor all modem communications, or if your modem is experiencing intermittent problems. To enable modem logging, use this procedure:

1. Open Control Panel and double-click Phone And Modem Options. This will open the Phone And Modem Options dialog.

2. Click the Modems tab, select the modem that you want to configure, and then click Properties.

3. In the Properties dialog for the modem, click the Diagnostics tab.

4. To enable modem logging, check the Record A Log box. Click OK to close the Properties dialog. On Windows 2000 Professional, this option appears as Append To Log.

Enabling Connection Tracing

Connection tracing is an advanced option for monitoring RAS communications. Therefore, the only way to enable tracing is through directly editing the Registry. Microsoft doesn’t want inex-perienced net admins to risk hurting themselves with this tool unless they absolutely need to. Once connection tracing is enabled, you will be able to check routing information about packets being sent via the RAS service.

1. Open the Registry Editor by clicking Start � Run and typing REGEDT32.EXE.

2. Browse down to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing. Double-click the EnableFileTracing value to open the value editor. Enter a value of 1 to enable tracing; a value of 0 disables tracing. The default value is 0.


3. Browse down to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing. Double-click the FileDirectory value. Enter the path to the folder where you want to store the tracing information. The default value is %systemroot%\Tracing.

4. Browse down to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing. Double-click the FileTracingMask value. This value determines the amount of information gathered in the tracing process and is expressed as a hexadecimal value. The default is FFFF0000, which is the maximum amount of detail.

5. Browse down to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing. Double-click the MaxFileSize value. This value sets the maximum size of the tracing log file. The default value is 65,536 bytes (64K).

Exam Essentials

Know how to resolve name-resolution issues. Before resolving name-resolution issues, make sure the issue at hand is related to name resolution. Check network connectivity first, and if that works, move on to name resolution. If the name you are trying to resolve is a host-name, then check DNS or the Hosts file. If it’s a NetBIOS name, check WINS or the LMHosts file.

Know how to resolve remote access failures. Windows 2000 provides some tools to help troubleshoot RAS, including modem diagnostics, modem logging, and tracing connections. Also, make sure the user was granted appropriate permissions to log on via Remote Access.

Know how to fix DHCP problems. There are two common issues with DHCP. One is when administrators forget to authorize the DHCP server in Active Directory. This will cause the DHCP server to not be able to give out IP addresses. The second problem comes when administrators configure multiple DHCP scopes with overlapping addresses. This causes address conflicts, which will disrupt network communications.


Know everything you can about DNS. This essential seems very general, but this is the last place DNS is discussed, so it’s a good time to bring it up. Knowing everything is impossible, but you need to know what versions of BIND will work with Windows 2000 Active Directory, which different BIND versions provide which features, and how to set up, configure, and troubleshoot DNS.


broadcast A message sent on the network addressed to all computers.

DigiBoard Expansion board that provides the functionality of multiple modems.

File Replication Service (FRS) The Windows 2000 replication system that replaced LMRepl from Windows NT.

Hosts Static file used to resolve hostnames to IP addresses.

LMHosts Static file used for NetBIOS name-to-IP address resolutions.

pull replication Replication method in which one machine contacts another requesting information, usually based on a regular time schedule.

�Troubleshoot application failures for all types of migrations.

This objective covers troubleshooting application failures. To accomplish this, you need to understand application-compatibility testing in the Windows 2000 environment and know how to avoid application failures by assessing compatibility before the applications are installed.

Next, you’ll learn how to resolve incompatibilities that may arise with particular applications. These will include commercial applications as well as line-of-business applications that may have been developed inter-nally in your organization. You will find out where to obtain and how to


apply compatibility patches for Windows 2000. You will also learn where to find more information regarding application compatibility.

Also discussed is how to resolve connectivity issues between applica-tions and a Windows 2000 network environment. This would mostly involve applications written for Windows networking that depend upon NetBIOS to make network connections. Finally, issues caused by hard-coded information in your application are covered.


It would be wonderful to say that Windows 2000 supports applica-tions without any problems whatsoever. But, unfortunately, that just isn’t true. While being fairly stable, Windows 2000 has incorporated some newer technologies, which means that some applications may not run correctly on the new operating system. The only way to know for sure is to thoroughly test the applications you will be using.

Verifying application compatibility

One of the best ways to begin testing applications is by using the Readi-ness Analyzer from Microsoft. The Readiness Analyzer is useful mostly for commercial applications and for some hardware issues. As a gen-eral rule, applications that ran under Windows NT should run under Windows 2000. Notice the words “general rule” and “should.”

The Readiness Analyzer can perform a fairly thorough check of your computer for both hardware and software compatibility issues. This program is able to notify you of possible compatibility problems and in many cases recommend a course of action that will resolve the issue either before or after the upgrade to Windows 2000.

Microsoft assists in your evaluation of application compatibility by establishing standards for compatibility certification. The Windows 2000 Application Specification defines various levels of software support under Windows 2000. There are four Application Levels:

Certified Means that the application meets every requirement for compatibility and that it has been tested both by Microsoft and an


independent test laboratory. This is the highest level of certification an application can achieve.

Ready Indicates that the Independent Software Vendor (ISV) has performed Windows 2000 compatibility testing and certifies that the application will run correctly on Windows 2000. The ISV also prom-ises to provide support for their application on Windows 2000.

Planned Means that the ISV intends to provide support for Windows 2000 in a future release of the application.

Caution Means that you may very well encounter problems with this application on Windows 2000. In this case, there is most likely a known issue that is documented and that probably has a workaround or solution available.

Microsoft also makes your decisions easier from the standpoint of software compatibility by providing the Software Compatibility List (SCL) on their Web site. The SCL is a browsable database of tested applications and their compatibility with Windows 2000. The Soft-ware Compatibility List is available at: www.microsoft.com/windows2000/upgrade/compat/search/software.asp.

By recognizing these certification levels, you will be better prepared to deploy applications on your Windows 2000 network. Some other things to keep in mind to help compatibility are to thoroughly test applications before deploying them in production, and to simplify the number and scope of applications you wish to install. There should be no need for three different word processors on one network.

Application Compatibility Toolkit

The Application Compatibility Toolkit contains documents and tools to help you diagnose and resolve application-compatibility issues. It includes the Windows Server and Professional logo documents, the white paper on common compatibility issues, several documents on best testing practices, and tools to help fix compatibility issues. You can find the toolkit and download it from http://msdn.microsoft.com/compatibility/.


Resolving incompatibility issues

Careful testing should reveal most of the issues that you’ll face in your organization’s migration to Windows 2000. When you do find incompatibilities with applications, the first course of action to take is to check for software patches that will correct the issue. Microsoft has released a number of compatibility patches for various applica-tions running on Windows 2000. You should also check the Web site of the software manufacturer to see if they have compatibility patches enabling their application to be run on Windows 2000.

The Microsoft Developers Network (MSDN) Web site contains considerable information regarding application compatibility with Windows 2000. The Windows 2000 Compatibility Guide, located on the MSDN Web site, breaks down compatibility issues into four basic areas:

� Setup and installation

� General Windows 2000 compatibility

� Application stability

� Windows platform

This information will be of particular use to your in-house software development teams. Encourage your software development teams to spend some time examining the Windows 2000 Compatibility Guide.

Application incompatibility issues can be broken down into several key areas with Windows 2000. In addition to the four listed for the Windows 2000 Compatibility Guide, some of the common issues that cause incompatibilities are:

System file protection Traditionally, the Windows operating systems have allowed applications to replace system files as needed. Often times, system files are replaced incorrectly. A common example of this was the Winsock.dll file. Installing one version of the file could break every other application that required that file.

Windows 2000 enforces Windows File Protection, a feature that prevents applications from replacing system files in Windows 2000.


This is a big step forward for supportability in Windows 2000; however, it may cause problems for some applications that require a specific version of the file.

Enumeration of hardware devices Plug and Play is a significant new feature in Windows 2000. It also has a major impact on the list of devices that are supported for the operating system. Some software applications will discover that they no longer have the devices they require.

Enumeration of fonts Windows 2000 has a new list of fonts. In addition to the fonts present in the Fonts folder, new Registry entries have been added to support internationalization of fonts. Because of this, some older applications may see duplicate lists of fonts in Windows 2000.

Changed Registry structure The structure of the Registry has been modified in several areas in Windows 2000. Applications that modify the Registry through the Win32 APIs should encoun-ter no difficulties in Windows 2000. But if you have an older appli-cation that makes changes to the Registry by writing directly to it, you may see problems.

Version checking Setup programs that check versions incorrectly will encounter difficulties with Windows 2000. If the setup program checks the version through the Registry by using standard Win32 API calls, there should be no problem.

File input/output security The security in Windows 2000 has been tightened significantly over Windows NT, extending even to file input and output. This tightened security may cause problems with applications that filter file input and output, such as anti-virus pro-grams. The behavior may even extend to causing problems with net-work firewalls that have not been written specifically to deal with Windows 2000.

Some of the things you can do to resolve software incompatibilities include checking the software vendor’s Web site for updates and patches, checking Microsoft’s Web site for compatibility patches, and contacting Microsoft’s Support Services to find out if there have been any solutions for known issues. Other solutions would include


replacing the application with a newer version or another application that does not have the incompatibility. Most of the major software vendors have already released versions of their programs specifically designed to run on Windows 2000.

Another point to keep in mind is whether the problem exists on all of your hardware platforms on Windows 2000. Verify that the problem is truly specific to Windows 2000 and not due to some particular hardware and software combination on the test computer.

Troubleshooting connection issues

Many applications in businesses today require interaction between a client desktop computer and a server. The applications your organi-zation uses to perform its daily work will likely demand interaction with a server. Your testing of applications on Windows 2000 may reveal connectivity issues between the client and the server platform.

The major issue dealing with application connectivity is name reso-lution. Because Windows 2000 depends heavily on DNS for name resolution and rarely if ever uses NetBIOS, some applications may have trouble resolving computer names.

When testing applications that use data on a server, you should be testing the connectivity as well as the ability to handle a concurrent load. For example, you could have multiple users connect to the server using the same application at the same time. Or you could try to run complex interactions with the server concurrently to reveal any problems with loading. You can automate this process through the use of scripts or with a software-testing program.

When you experience software incompatibilities, you need to deter-mine how much incompatibility your organization is willing to tol-erate. Many environments are able to tolerate small incompatibilities, which require a workaround on the part of the user. Other environ-ments cannot tolerate any kind of a breakdown in the workflow. Hints on the exam will lead you to the proper course of action.

Network-based applications are less likely to tolerate interruptions in service than are desktop applications. This lack of tolerance


necessitates the use of a parallel system for testing. It also requires that you pay a great deal of attention to the amount of load that can be placed on network-based applications when running on Windows 2000.

When evaluating a new software solution for a particular business need, you might do well to evaluate it on your current Windows plat-form before evaluating it on Windows 2000. This will help you to identify whether any issues that arise are due to Windows 2000 or to networking problems that already exist in your organization.

If you encounter name-resolution issues, try configuring the applica-tion with the IP address of the server instead of the server name. If the application requires a NetBIOS name in order to connect to the server and NetBIOS name resolution is not functioning on your network, troubleshoot it from that aspect. This may require a WINS server if you do not already have one on your network. Another possibility would be using the LMHosts file to provide NetBIOS name resolu-tion on the client.

If your application requires a specific network protocol, such as NetBEUI, you are faced with a decision. You can keep the appli-cation and add NetBEUI to your Windows 2000 network, or remove NetBEUI from the picture and upgrade your application to a version that supports TCP/IP. If you are faced with this dilemma, contact the vendor of the application for a possible solution.

Resolving issues associated with hard-coded

account information in third-party applications

Every so often, application developers decide that their program should run only on one particular version of Windows. This causes tremendous problems for people who want to use the application but who also want to upgrade their version of Windows to a newer release. You may be able to fix this problem by editing the Registry to change the current version’s setting to the correct version of Windows for the application. The major problem with this approach is that it may very well break other applications that require Windows 2000.


Fortunately, Microsoft has provided a way to fix this problem in Windows 2000. There is a little-documented program called Appli-cation Compatibility (apcompat.exe). The Application Compatibil-ity program enables you to “lie” to your application so that it believes it is running on the correct version of Windows. To start the program, run apcompat.exe. Figure 5.15 shows the Application Compatibility program.

F I G U R E 5 . 1 5 : The Application Compatibility program lets you set version information for applications.

The Application Compatibility program requires you to enter the name of the program that you want to modify and select the operat-ing system version that the application requires. Nothing older than Windows 95 will be permitted. An interesting feature is that you can set a specific Service Pack version of Windows NT 4.

It also lets you disable certain portions of Windows 2000’s new features. The first option disables the Heap Manager on Windows 2000. The heap is a portion of memory from which applications can allocate or free memory for their own usage. The Heap Manager may cause problems with a number of applications that may not be freeing memory correctly when they close. The second option enables you to use a Temp path that complies with pre-Windows 2000 compatibility.


Because some applications have difficulty seeing more disk space than 2GB, the third check box enables you to correct the space detection for the application to enable it to see more disk space. The final check box allows you to make the settings permanent for the application.

Exam Essentials

Know the best way for testing incompatibility issues. The best way is a test environment. Ideally, the test environment would be identical to your production network.

Know some methods for resolving application issues. Some pre-ferred methods include looking for patches on the manufacturer’s Web site and downloading current service packs.

Know how to deal with applications that require a specific platform for operation. Microsoft’s Application Compatibility program tricks applications into thinking they are running on an alternate operating system when they are running on Windows 2000.


heap Section of memory that applications can use for their own pur-poses, including allocation or freeing-up.

�Troubleshoot tool issues for domain restructures. Considerations include ADMT, ClonePrincipal, NETDOM, MoveTree, and Windows 2000 Resource Kit tools.

When performing a migration, there are many areas to main-tain controls on, including connectivity, users, services, and appli-cations. Another thing to control when migrating is the tools that you


are using to perform the migration. The tools themselves are covered in extensive detail in Chapter 4, “Planning and Deploying an Intra-Forest Domain Restructure and an Inter-Forest Domain Restruc-ture.” This objective specifically deals with troubleshooting tips for those tools.


Most of the troubleshooting you will have to do with these migration tools will be related to the configuration required for each tool. For instance, when installing and configuring the Active Directory Migra-tion Tool (ADMT), you must install the tool on a domain controller in the target domain. Failure to do so will generate some errors that may be difficult to track down.

To protect yourself from errors that could impede migration, you should look at each of the tools before you begin the migration pro-cess. The descriptions of the tools are just as important as the section on understanding how to configure the tools themselves. More often than not, administrators find themselves having to work out glitches to keep projects moving smoothly.

Troubleshooting ADMT

ADMT comes with a fairly thorough Help file, which actually contains a useful troubleshooting section. There are 22 different troubleshooting scenarios listed in this Help file, and nearly all of them have to do with improper ADMT configuration. This insinuates that if you are receiving any kind of error with ADMT, you should spend some time verifying the setup of the tools. You should also check your spelling, since the computer will take your command literally, as com-puters usually do.

Make certain that you have correctly established the trusts to communi-cate between your domains. Authentication issues seem common with ADMT. You will need to have administrator accounts and/or permis-sions in both domains.


If you have Exchange Server installed in your domain, you will have an additional service to configure. When ADMT migrates the service account for Exchange, it correctly updates all of the information for the account, including the SIDHistory attribute. But Exchange Server will fail to start after the migration because the service account must also be updated within Exchange Server. Use the Exchange Adminis-trator console to update the service account to the new account within the target domain.

Troubleshooting ClonePrincipal

ClonePrincipal won’t be quite as troublesome from one point of view: It works by copying the accounts to a new location. You can always fall back to using the old accounts on the source domain if something goes wrong with the new accounts. But if something does go wrong, you will have two main sources of information.

First of all, ClonePrincipal logs all operations. The log file is located in %SystemRoot%\debug and is called clonepr.log. Check this file for more detailed information if and when you have a problem with ClonePrincipal.

The other source of information at your disposal is the Security log in Event Viewer. Since one of the configuration requirements is to enable auditing on both the source and target domains, you will have an audit trail of everything that ClonePrincipal did while cloning accounts.

ClonePrincipal directs quite a bit of information to your monitor while it is running. It is possible, and recommended, to redirect this output to a file for later review in case of problems. You can redirect the output by typing:

cscript script.vbs options > scriptname.txt

Using this method enables you to save any messages that are gener-ated by ClonePrincipal while it is running.


Troubleshooting NETDOM

The troubleshooting for NETDOM falls under the heading of simple network troubleshooting. If you are using NETDOM to manage or create trusts, you will need to verify the configuration requirements for trust relationships. Check that the domain controllers and the domains have unique SIDs and that the PDC and/or PDC Emulators can communicate across the network. Also make sure that they don’t have a current network session established.

The only other troubleshooting to be done with NETDOM is to make sure that you entered the correct syntax and user credentials. Accu-rate typing is vital, especially since you have to deal with potentially long command lines. Always double-check your spelling and syntax before pressing the Enter key. Consult the online Help for the Support Tools for more detailed descriptions of the syntax for the NETDOM command.

Exam Essentials

Know how to fix most ADMT errors. ADMT has an extensive Help file, which is a very good reference. Most often, ADMT problems occur because of improper configuration or authentication issues.

Know how to investigate ClonePrincipal problems. ClonePrincipal logs all of its actions in the clonepr.log file. You should also check the Security log in Event Viewer.

Know how to avoid problems with NETDOM. The biggest issue with NETDOM is typically spelling. Computers do what you tell them to.


%systemroot% Variable that refers to the directory in which the operating system is installed. This is the winnt directory by default in Windows 2000.

Index

Note to the Reader:

Throughout this index

boldfaced

page numbers indicate pri-mary discussions of a topic.

Italicized

page numbers indicate illustrations.

A

Access Control Entries (ACEs), 230Access Control Lists (ACLs)

with ClonePrincipal, 185for GPOs, 277with moved accounts,

39–40

redefining,

225–234

,

227

,

231

and SIDs,

39

Access Control Settings dialog, 243–244,

244

, 247access issues,

291

authentication,

303

client computer connectivity,

291–292

Network Monitor for,

296–299

,

297–298

,

306–308

network troubleshooting for,

292–296

,

295

exam essentials for,

308–309

with GPOs, 276key terms and concepts in,

309

NTFS permissions,

299–302

,

300

procedures in,

306–308

shared resources,

302–303

trust relationships,

304–306

,

305

access tokens, 41,

229–230

account informationfor Reporting Wizard, 176in third-party applications,

343–345

,

344

Account Policies option, 110

Account Transition Options page, 200accounts, 137,

272

ADMT for,

182–184

,

198–203

,

199

ClonePrincipal for,

204–206

,

210–212

computer, 168, 181, 183,

208–210

duplicate,

283–284


289–290

key terms and concepts in,

290

logon script failures,

280–283

,

282

moved,

39–41

procedures for,

207

,

286–289

restoring,

221

,

223–224

service,

47–48

,

48

system policy translation issues,

272–279

,

275–276

user rights,

284–286

,

286

,

288–289

ACEs (Access Control Entries), 230ACLs (Access Control Lists)

with ClonePrincipal, 185for GPOs, 277with moved accounts,

39–40

redefining,

225–234

,

227

,

231

and SIDs,

39

Active Directorybacking up, 131–132DDNS for,

53–54

DHCP for, 156, 165DNS for,

52–53

, 70domain selection for, 15–16,

17

Active Directory Connector (ADC) – ADMT (Active Directory Migration Tool)

350

in domain upgrades, 97linking GPOs to, 106Multiple Master Domain model

migration to,

18–19

,

18

in PDC upgrades, 4replicating,

325–328

restoring,

217

security for, 35–36Single Master Domain model

migration to, 17,

18

Active Directory Connector (ADC)installing,

60

purpose of, 45Active Directory Connector (ADC),

45,

60

Active Directory Connector Manage-ment console, 46,

46

Active Directory Connector Setup Wizard, 60

Active Directory Domains and Trusts console, 149,

161–162

Active Directory Installation Wizard, 96, 116

Active Directory-integrated zones, 70Active Directory Migration Tool.

See

ADMT (Active Directory Migra-tion Tool)

Active Directory Migration Tool Agent Monitor, 179–180,

180

Active Directory Migration Tool Setup Wizard, 193

Active Directory Service Interfaces Editor (ADSI Edit), 242

Active Directory Sites and Services console

for GPO links, 106for sites, 162

Active Directory Users and Computers console

for auditing, 194for Group Policies, 113, 163for OUs, 162

ADC (Active Directory Connector), 45,

60

ADC folder, 45, 60ADC Setup Wizard, 45–46Add method for translation, 210Add/Remove Programs applet, 49,

50

Add/Remove Snap-in dialog, 112–113Add/Remove Windows Components,

72Add Standalone Snap-in dialog, 112–

113Address resolution Protocol (ARP)

for NetBIOS, 311purpose of, 308verifying functionality of,

239

addresses.

See

IP addressesAdministrative Templates, 103,

109–110

,

113–114

administrators for GPOs, 279ADMT (Active Directory Migration

Tool)configuring,

171–173

for group accounts,

202–203

installing,

170–171

,

192–193

for inter-forest migration, 10,

180–183

for intra-forest migration,

183–184

for service accounts, 47troubleshooting,

346–347

for user accounts,

198–202

,

199

wizards in,

168–170

working with,

173–180

,

173–180

ADSI Edit (Active Directory Service Interfaces Editor) – Backup Domain

351

ADSI Edit (Active Directory Service Interfaces Editor), 242

Advanced option for Folder Redirec-tion, 114

Advanced Options menu, 217–218Agent in ADMT, 170air conditioning, 135Allow Access If Dial-In Permission Is

Enabled option, 164Allow Dynamic Updates option, 76Allow Inheritable Permissions From

Parent To Propagate To This Object option, 246, 301

Always Update DNS option, 165analyzing Network Monitor data,

307–308

anti-virus software, 267Append To Log option, 335AppleTalk requirements, 99Application Compatibility program,

344,

344

Application Compatibility Toolkit,

339

application serversin domain upgrades,

96–97

in inter-forest migration, 12applications

compatibility of,

43

,

338–342

Exchange Server,

45–48

,

46

,

48

line of business applications,

48–49

software deployment,

49–51

,

50

Web services,

44–45

failures in,

337–338

compatibility issues,

338–342

connection issues,

342–343


345

key term and concept in, 345

third-party, 343–345, 344with limited licensing, 37support for, 292

Apply Group Policy permission, 107ARP (Address resolution Protocol)

for NetBIOS, 311purpose of, 308verifying functionality of, 239

assigningapplications, 51permissions, 242–250, 243–246,

248attribute replication, 323Audit These Events option, 194auditing, 193–194Authenticated Users permission, 107authentication issues, 303authoritative restores, 217–218, 221–

222authorizing

DHCP, 60–61DNS servers, 330

Automatically Update DHCP Client Information In DNS option, 165

BBackup Domain Controllers (BDCs)

backing up, 87with ClonePrincipal, 185in domain restructure, 145in domain upgrades, 93–98in native mode conversions, 121offline, 215in recovery, 78–79for restoring accounts, 223upgrading, 4–6

Backup program – clonepr.log file352

Backup program, 130–133, 131, 133, 216–217, 234

Backup tab, 131, 131, 222Backup Wizard, 130backups, 130–133, 131, 133

domain, 137, 234–235in recovery, 81, 216–217for rollbacks, 135–136System State, 217, 222–223before upgrading, 87

Bandwidth Allocation Protocol (BAP), 57

basic disks, 129Basic option for Folder Redirection,

114BDCs. See Backup Domain Control-

lers (BDCs)#BEGIN_ALTERNATE command,

314Berkeley Internet Name Domain

(BIND)for DDNS support, 53–54performance of, 101for SRV records, 158zone transfers to, 333

BIOS for SCSI controllers, 259Block Inheritance permission, 279Block Policy Inheritance option, 104,

108blue-screen errors, 264–267boot files, backing up, 132boot.ini file, 261–262boot-sector viruses, 266–267Bootdisk folder, 219Bootstrap Protocol (BootP), 55, 331bridges, replication. See file replication

bridgesbroadcasts in NetBIOS, 311, 313, 316

built-in groups and users, 227–228Builtin domain, 228business-related goals, 85

Ccabling, 33–34caches

in DNS name resolution, 294in NetBIOS, 311–312, 316

capturing Network Monitor data, 306–307

Caution application level, 339central processing unit (CPU)

for ADMT, 170for domain controllers, 94requirements for, 31–32

Certified application level, 338change/configuration management,

mixed mode vs. native mode, 122chkdsk.exe program, 266cleaning up after domain upgrades,

138–139client computers

connectivity of, 291–292Network Monitor for, 296–299,

297–298, 306–308network troubleshooting for,

292–296, 295for domain restructure, 145

clonegg.vbs script, 187, 189, 205–206, 211

cloneggu.vbs script, 187, 189, 206clonelg.vbs script, 187, 189, 211clonepr.dll file, 196clonepr.doc file, 186, 188clonepr.log file, 347

clonepr.vbs script – connectivity 353

clonepr.vbs script, 186–188, 204–205ClonePrincipal tool, 184–187

for group accountsglobal, 205–206local, 210–212

with inter-forest migration, 10vs. MoveTree, 191preparing, 187–188, 195–196for security principals, 42troubleshooting, 347for user accounts, 204–205working with, 188–190

COM+ Class Registration Database, 132

combining domains, 19command-line DNS administration,

71common network protocols, 292communication lines in RAS, 320compatibility

application, 43Exchange Server, 45–48, 46, 48issues in, 340–342line of business, 48–49software deployment, 49–51, 50verifying, 338–339Web services, 44–45

hardware, 33, 258mixed mode for, 6Readiness Analyzer for, 256–257,

257, 338Completing The Configure DNS

Server Wizard page, 75Completing the Reporting Wizard

page, 178, 179Complex Passwords option, 200Component Selection page, 60components in Group Policy Con-

tainer, 104

computer accounts, 208–210Computer Migration Wizard, 168

in inter-forest migration, 181in intra-forest migration, 183

Computer Selection page, 177, 178config.pol file, 102configuration partitions, 325Configure And Enable Routing And

Remote Access option, 164Configure DNS Server Wizard, 73Configure The Server option, 73configuring

ADMT, 171–173DHCP, 99–100, 155–156, 165directory replication, 156–157DNS, 158–160DNS servers, 73–75Group Policies, 108–112, 109LMRepl, 100network services, 154–160protocols, 155RAS, 154–155, 164–165, 320–321TCP/IP, 155WINS and NetBIOS, 100–101,

157–158conflicts

inheritance, 277permissions, 302–303resource, 262–264, 263in scripts, 283SID, 284

connectionsapplication, 342–343tracing, 335–336

connectivity, 291–292Network Monitor for, 296–299,

297–298, 306–308network troubleshooting for, 292–

296, 295

consistency checks – Dfs (Distributed File System)354

problems in, 240consistency checks, 217convergence, 326converting

to native mode, 5–6, 119–121exam essentials for, 123key terms and concepts in, 124mixed vs. native modes in, 121–

123System Policies to Group Policies,

112copying

folders, 157passwords, 10, 13SAM database, 185

CPU (central processing unit)for ADMT, 170for domain controllers, 94requirements for, 31–32

cross-domain administration, 122current environment evaluation, 26–

27application compatibility, 43

Exchange Server, 45–48, 46, 48line of business applications, 48–

49software deployment, 49–51, 50Web services, 44–45

domain restructure in, 28–29exam essentials for, 29, 61–62key term and concept in, 29key terms and concepts in, 62–63network services. See network

servicesprocedures for, 59–61

current hardware evaluationnetwork cabling, 33–34network routers and subnets, 34

requirements, 29–33security implications. See security

DDACLs (Discretionary Access Control

Lists)for GPOs, 277redefining, 225–234, 227, 231

damaged directories, restoring, 217Days Until Source Account Expires

setting, 200dcpromo.exe program

for decommissioned domains, 236in domain upgrades, 97for Sysvol, 116

DDNS (Dynamic DNS), 53–54, 330decommissioning domains, 145–146,

235–237default permissions in RRAS, 58default servers in DNS, 333Define This Policy Setting option, 163delegation of authority, 277demoting in inter-forest migration, 12Deny ACEs, 230Deny permissions, 300, 302Dependencies tab, 330deployment

software, 49–51, 50test, 124–126, 213–214

Deployment Planning Guide, 186destinations, planning, 20–21detail pane in Network Monitor, 299Device Manager, 262–263, 263Dfs (Distributed File System)

FRS for, 115for remote backups, 234

DHCP – DNS 355

in replication, 322–325DHCP (Dynamic Host Configuration

Protocol), 55–56authorizing, 60–61configuring, 155–156, 165in domain upgrades, 97, 99–100issues in, 330–332, 331recovering, 79–80verifying operation of, 138

diagnostic logging, 273, 286–287Diagnostics tab, 322, 335directories. See Active Directorydirectory replication, 156–157Directory Services Restore Mode

option, 217–218, 222DirectX 7.0A, 27Disable command, 219Disable Source Accounts option, 200Disable Target Accounts option, 200disabled GPOs, 278–279disaster recovery plans, 77–78, 126–

127account restoration in, 221for DHCP, 79–80for DNS, 79exam essentials for, 81–82, 136,

224hardware in, 127–130implementation rollback in, 135–

136infrastructure in, 134–135key terms and concepts in, 82, 136–

137, 224network services restoration in,

219–221pre-migration environment restora-

tion in, 135, 215–219procedures for, 221–224

for protecting data, 81for SAM database, 78–79software in, 130–133, 131, 133–

134for WINS, 80–81

Discretionary Access Control Lists (DACLs)

for GPOs, 277redefining, 225–234, 227, 231

disks. See hard disksdisplay

for domain controllers, 94troubleshooting, 260–261

Display Captured Data option, 307distinguished names (DNs), 200, 202Distributed File System (Dfs)

FRS for, 115for remote backups, 234in replication, 322–325

DLC requirements, 99DMA resources, 96DNs (distinguished names), 200, 202DNS (Domain Name System), 52–54,

69–72configuring, 158–160configuring servers, 73–75and connectivity, 294DHCP in, 155for domain upgrades, 101domains in, 318dynamic updates for, 76exam essentials for, 76installing, 72–74, 72–73issues in, 333–334key terms and concepts in, 76–77with NetBIOS, 312, 315procedures for, 74–76recovering, 79

DNS console – Domain Security Policy console356

registration renewals in, 239restoring servers, 220verifying operation of, 138

DNS console, 73, 73.dns files, 75DNS installation wizard, 74DNS tab, 165, 330–331, 331Do Not Rename Accounts option,

183, 201#DOM command, 314Domain Admins permission, 107domain controllers

backing up, 87, 137with ClonePrincipal, 185for domain restructure, 145in domain upgrades, 93–98with MoveTree, 190in native mode conversions, 121offline, 215promoting member servers to, 270re-deploying, 235–237in recovery, 78–79in replication, 328restoring, 216–217for restoring accounts, 223upgrading, 4–6

Domain Identifiers in SIDs, 226Domain Name System. See DNS

(Domain Name System)Domain NC (Naming Context) node,

249domain partitions, 325domain restructure, 6–7, 28

for DHCP, 79–80disaster recovery plans for, 214–

215account restoration in, 221

key terms and concepts in, 224network services restoration in,

219–221pre-migration environment res-

toration in, 215–219procedures for, 221–224

for DNS, 79exam essentials for, 81–82, 136,

224global group and user account

migration for, 207–208with ADMT, 198–203, 199with ClonePrincipal, 204–206

local group and computer account migration for, 208–212

post-migration, 29post-upgrade, 28strategies for, 143–144

exam essentials for, 146key term and concept in, 147migrating to new domains, 144–

146target domains in. See target

domainstest deployments for, 213–214tools for, 167–168

ADMT. See ADMT (Active Directory Migration Tool)

ClonePrincipal, 184–190exam essentials for, 196–197key terms and concepts in, 197–

198MoveTree, 190–191NETDOM, 191–192procedures for, 192–196

vs. upgrades, 28Domain Security Policy console, 285

Domain Selection page – Dynamic DNS Update functions 357

Domain Selection page, 174, 174domain upgrades, 3–4, 84

application servers in, 96–97beginning, 4completing, 5–6disaster recovery plans in, 126–127

exam essentials for, 136hardware in, 127–130implementation rollback in,

135–136infrastructure in, 134–135key terms and concepts in, 136–

137pre-migration environment res-

toration in, 135software in, 130–133, 131, 133–

134vs. domain restructure, 28failed. See failed domain upgradesfault tolerance in, 95file replication bridges for, 115–

119Group Policies for. See Group Poli-

cies and Group Policy Objects (GPOs)

native mode conversions in, 119–124

operating systems in, 90–92PDCs and BDCs in, 4–5, 93–98post-migration tasks in, 137–139service configuration for, 99–102strategies for, 84–85

exam essentials for, 89key term and concept in, 90migration order in, 86–89

test deployments of, 124–126

domain upgrades with restructure, 6–13, 7

inter-forest migration, 9–12intra-forest migration, 12–13multiple NT domains, 8–9NT to Windows 2000, 7–8

domainsbacking up, 137, 234–235combining, 19decommissioning, 145–146, 235–

237in DNS, 318names for, 15–16, 17, 269–270restructures. See domain restruc-

turein security, 35–36selecting and ordering, 15–20, 17–

19upgrades. See domain upgrades;

domain upgrades with restruc-ture

downlevel clients in upgrades, 101drivers

blue screen problems from, 265–266

for display, 260support for, 258–259

dual boots, 91duplicate accounts, 283–284duplicate names

for group accounts, 203for user accounts, 201in WINS, 333

dust, 135dynamic disks, 129–130Dynamic DNS (DDNS), 53–54, 330Dynamic DNS Update functions, 155

Dynamic Host Configuration Protocol – File Replication Service (FRS)358

Dynamic Host Configuration Proto-col. See DHCP (Dynamic Host Configuration Protocol)

dynamic updates, 70, 76, 269–270

EEAP (Extensible Authentication Proto-

col), 56–57editing scripts, 206emergency boot disks, 266–267Emergency Repair Disk, 130employee files, security for, 37Enable command, 219Enable Updates For DNS Clients That

Do Not Support Dynamic Update option, 165

enablingconnection tracing, 335–336modem logging, 322

Encrypted File System, 111#END_ALTERNATE command, 314Enterprise Admins permission, 107environment preparation

DNS service, 69–77, 72–73pristine environments, 66–68recovery plans, 77–82restoring, 135, 215–219

Ethernet networks, 33–34Event ID 7062 error, 333Event Log option, 111event logs

for Group Policies, 111for RAS, 321

Event Viewerfor account troubleshooting, 269for Dfs replication, 325

for RAS, 320Exchange Directory Migration Wiz-

ard, 169Exchange Server, 45–48, 46, 48Explain tab, 110Explicit ACEs, 230Extensible Authentication Protocol

(EAP), 56–57

Ffailed domain upgrades, 255–256

domain name issues, 269–270exam essentials for, 271hardware issues. See hardwarekey terms and concepts in, 272procedures for, 270–271Readiness Analyzer for, 256–257,

257, 271third-party tool problems in, 267–

268user rights issues, 268–269

fault tolerance, 95, 127–130fdisk.exe program, 266–267file permissions, reassigning, 242–244,

243–244file replication bridges, 115–116

exam essentials for, 118key terms and concepts in, 118–119LMRepl to FRS upgrades for, 117–

118Sysvol for, 116–117

File Replication Service (FRS), 156benefits of, 322for Dfs replication, 324–325file replication bridges for, 115vs. LMRepl, 58–59

file systems in RAID – Group Policies and Group Policy Objects (GPOs) 359

LMRepl upgrades to, 117–118for multimaster replication, 323in native mode conversions, 120

file systems in RAID, 128File Transfer Protocol (FTP), 44–45filters with Group Policies, 279Flexible Single Master Operations

(FSMO), 226, 228flow management for Group Policies,

107–108Folder Redirection, 103, 111–112,

114Folder Selection page, 174, 175folders

copying, 157permissions for, 245–247, 245–246

fonts for application compatibility, 341

forward lookup zones, 74, 76FQDNs (fully qualified domain

names), 72, 317frames in ARP, 308FRS. See File Replication Service (FRS)FSMO (Flexible Single Master Opera-

tions), 226, 228FTP (File Transfer Protocol), 44–45Full Control permission, 301fully qualified domain names

(FQDNs), 72, 317future growth, security planning for, 38

GGeneral tab

in DNS, 76in Services Properties, 329

geographical settings, domains for, 36

global catalog servers, 328global groups, 198

ClonePrincipal for, 205–206in domain restructure, 146with moved accounts, 40

Globally Unique Identifiers (GUIDs)GPTs in, 104in inter-forest migration, 10in intra-forest migration, 13with MoveTree, 191

GPOs. See Group Policies and Group Policy Objects (GPOs)

GPOtool tool, 274–275, 275GPResult tool, 274–276, 276, 281–

282, 282, 288GPTs (Group Policy Templates), 104Grant Remote Access Permission

option, 164granularity, 20–21, 244graph pane in Network Monitor, 297Group Account Migration Wizard,

202–203Group Mapping and Migration Wiz-

ard, 169Group Migration Wizard, 168

for inter-forest migration, 181–182for intra-forest migration, 183–184

Group Options page, 203Group Policies and Group Policy

Objects (GPOs), 102–104Administrative Templates for, 109–

110, 113–114for applications, 37configuring, 108–112, 109creating, 106, 113for deployment, 50diagnostic logging for, 273, 286–

287

Group Policy Container – Hostname service, verifying functionality of360

exam essentials for, 114–115flow management for, 107–108Folder Redirection for, 103, 111–

112, 114implementing, 153–154, 163–164inheritance in, 104–105, 108, 277key term and concept in, 115for logon scripts, 280–283, 282permissions for, 107, 277–279procedures for, 112–114processing, 105–106from system policies, 112for system policy translation issues,

274–279, 275–276, 287–288Group Policy Container, 103–104Group Policy snap-in, 106, 112–113Group Policy tab, 106, 108–109, 113,

163–164, 194Group Policy Templates (GPTs), 104groups

accounts for. See accountsClonePrincipal for, 205–206in domain restructure, 146in mixed mode vs. native mode, 122with moved accounts, 40moving, 232–233parallel, 233rights for, 285

growth, security planning for, 38GUIDs (Globally Unique Identifiers)

GPTs in, 104in inter-forest migration, 10in intra-forest migration, 13with MoveTree, 191

Hhard-coded account information,

343–345, 344hard disks

for ADMT, 170blue screen problems from, 265for domain controllers, 94duplexing, 128–129requirements for, 31–32striping, 128–130troubleshooting, 259–260

hardwarefor application compatibility, 341current. See current hardware eval-

uationin disaster recovery plans, 127–130issues in, 257–259

blue-screen errors, 264–267disk problems, 259–260display problems, 260–261memory problems, 261–262resource conflicts, 262–264, 263

for RAID, 129Hardware tab, 262HCL (Hardware Compatibility List),

33, 258Heap Manager, 344heat concerns, 135hexadecimal pane in Network Moni-

tor, 299high-security resources, 36–37hostname resolution, 52, 315–319,

317. See also DNS (Domain Name System)

Hostname service, verifying function-ality of, 238

Hosts file – ISA cards 361

Hosts file, 293, 312–313, 315–319, 317

IIAS (Internet Authentication Service),

57, 154IDE drives, 259–260, 265identifier authorities, 226IIS (Internet Information Services),

44–45implementation rollback, 135–136#INCLUDE command, 314incremental object migrations, 22Incremental Zone Transfers (IXFRs),

71, 101Industry Standard Architecture (ISA)

devices, 262–263INFORM packets, 156infrastructure in disaster recovery

plans, 134–135inheritance

in Group Policies, 104–105, 108, 277

of permissions, 301–302Inherited ACEs, 230Install Location page, 60installing

ADC, 60ADMT, 170–171, 192–193DNS, 72–74, 72–73Recovery Console, 218Support Tools, 194–195

Int13 calls, 259inter-domain link issues, 278inter-forest migrations

ADMT for, 180–183

in domain upgrades with restruc-ture, 9–12

test deployments for, 213–214intermittent line failures in RAS, 320international networks, 36Internet access, 37–38Internet Authentication Service (IAS),

57, 154Internet Information Services (IIS),

44–45Internet Protocol Security (IPSec), 27,

57, 111Internet Services Manager, 44Internet Software Consortium (ISC),

53, 159intra-forest migration

ADMT for, 183–184in domain upgrades with restruc-

ture, 12–13test deployments for, 213–214

inverse lookup (PTR) records, 156IP addresses

ARP for, 239format for, 153in NetBIOS, 311pinging, 238, 293proxy servers for, 37resolving hostnames to. See DNS

(Domain Name System)in troubleshooting, 292

IP Security (IPSec) option, 111IP subnets, 152IPConfig service, 238–239IPSec (Internet Protocol Security), 27,

57, 111IPX/SPX requirements, 99IRQ resources, 96ISA cards, 96

ISA (Industry Standard Architecture) devices – lookup zones362

ISA (Industry Standard Architecture) devices, 262–263

ISC (Internet Software Consortium), 53, 159

IXFRs (Incremental Zone Transfers), 71, 101

Jjetpack.exe program, 332

KKerberos security, 27Knowledge Consistency Checker

(KCC), 327

LL-bridge.cmd batch file, 157L2TP (Layer 2 Tunneling Protocol),

57LAN Manager replication (LMRepl)

service, 58–59, 100, 117–118last writer wins algorithm, 324Layer 2 Tunneling Protocol (L2TP),

57Leave Both Accounts Open option,

200licensing for applications, 37line of business (LOB) applications

in compatibility, 43, 48–49in incremental object migrations,

22in pilot programs, 25

linking GPOs, 106, 279

Links tab, 164List Folder Contents permission, 246LMHosts file

for dynamic updates, 269–270in NetBIOS, 311–316for trusts, 149

LMRepl (LAN Manager replication) service, 58–59, 100, 117–118

LOB (line of business) applicationsin compatibility, 43, 48–49in incremental object migrations,

22in pilot programs, 25

local groups, 182, 204, 208–212Local Groups option, 182local hostnames in NetBIOS, 315Local Policies option, 111Local Policy Setting option, 289Local Security Authority (LSA), 187Local Security Policy console, 285–

286, 286Local Security Policy Settings dialog,

288Log On tab, 329–330logoff scripts, 110, 280logon scripts, 280

failures in, 280–283, 282for Group Policies, 110

logons and logon serviceaccess tokens for, 41in native mode conversions, 120

logsClonePrincipal, 347Group Policy, 111, 273, 286–287modem, 322, 335RAS, 321for trial migrations, 213–214

lookup zones, 74–76

loose consistency – Multiple Master Domain model 363

loose consistency, 326low-level format problems, 259LSA (Local Security Authority), 187

MMAKEBOOT.EXE program, 219MAKEBT32.EXE program, 219Manage Documents permission, 248Manage Printers permission, 247–248manageability as upgrade goal, 85Management Console, 71mapping SIDs to SIDHistory, 209Master Boot Record (MBR), blue

screen problems from, 266/maxmem switch, 261–262MD5-CHAP (Message Digest 5 Chal-

lenge Handshake Authentication Protocol), 56–57

mem.exe program, 266member servers

in domain restructure, 145in domain upgrades, 91, 93in inter-forest migration, 12promoting, 270

memoryfor ADMT, 170for domain controllers, 94requirements for, 31–32troubleshooting, 261–262

Message Digest 5 Challenge Hand-shake Authentication Protocol (MD5-CHAP), 56–57

#MH command, 314Microsoft Developers Network

(MSDN), 340Microsoft DNS, 159–160

Microsoft Script Debugger, 281migpol.exe tool, 112Migrate Associated User Groups

option, 201Migrate Group SIDs To Target

Domain option, 183Migrate User SIDs To Target Domain

option, 201migration order in domain upgrades,

86–89Migration Progress dialog, 201mirrored environments, 24mirroring in RAID, 128–130mixed mode and environments

LMRepl to FRS bridges for, 117–118

vs. native mode, 121–123support for, 3switching from, 5–6

modems, 322, 334–335Modems tab, 334monitoring RAS, 321–322monitors, multiple, 260MoveTree tool, 190–191moving objects

in domain restructure, 145and Group Policies, 278groups, 232–233security principals, 38–41

_msdcs sub-domain, 158MSDN (Microsoft Developers Net-

work), 340.MSI files, 50Multilink, PPP, 57multimaster loose consistency, 326multimaster replication, 122, 322–323Multiple Master Domain model, 18–

19, 18, 148–149

multiple monitors – network services364

multiple monitors, 260multiple NT domains in restructuring,

8–9multithreaded replication engines, 116

Nname caches, 294, 311–312, 316name resolution, 69, 310–311

DNS. See DNS (Domain Name Sys-tem)

hostname, 315–319, 317NetBIOS, 311–315

namesdomain, 15–16, 17, 269–270group accounts, 203user accounts, 201

Naming Conflicts page, 201, 203native mode

for ADMT, 171conversions to, 5–6, 119–121

exam essentials for, 123key terms and concepts in, 124mixed vs. native modes in, 121–

123NBNSs (NetBIOS name servers), 311,

316NBStat command, 312nesting

groups, 122OUs, 151

Net View command, 318NetBIOS

configuring, 157–158for domain upgrades, 100–101name-resolution in, 311–313

for dynamic updates, 269–270

LMHOSTS for, 313–315WINS for, 54–55

support for, 53NetBIOS name servers (NBNSs), 311,

316Netdiag tool, 240–241, 274, 294–296,

295NETDOM tool

in deployment testing, 125in domain restructure, 191–192for inter-forest migration, 10troubleshooting, 348for trusts, 41–42, 149

netlogon share, 102network cabling, 33–34network hardware for domain con-

trollers, 94Network Monitor

analyzing data in, 307–308capturing data in, 306–307for client computer connectivity,

296–299, 297–298verifying functionality of, 241

Network News Transfer Protocol (NNTP), 45

network paths in WINS, 332network protocols, 52network routers and subnets, 34network services, 51

configuring, 154–160DHCP, 55–56, 330–332, 331DNS, 52–54, 333–334issues in, 309–310, 328–334, 329

exam essentials for, 336–337file and directory replication,

322–328key terms and concepts in, 337name-resolution, 310–319, 317

New Site option – PDC Operations Masters 365

permissions, 319–322procedures in, 334–336

LAN Manager replication, 58–59network protocols, 52RAS, 319–322restoring, 219–221RRAS, 56–58, 58verifying, 138, 237–241WINS, 54–55, 332–333

New Site option, 163NNTP (Network News Transfer Pro-

tocol), 45No Access permission, 249No Administrative Policy Specified

setting, 114No Override option, 104, 108No Override permission, 279NSLookup utility, 294, 310NT to Windows 2000 restructuring,

7–8ntconfig.pol file, 102NTFS systems, 266, 299–302, 300

Ooffline BDCs, 215opening GPOs, 276operating systems in domain

upgrades, 90–92Operations Masters roles, 148optional components for domain con-

trollers, 94ordering domains, 15–20, 17–19Organizational Unit Selection page,

200, 202organizational units (OUs)

for granularity, 20–21

for group accounts, 202in target domains, 150–151, 150,

162for user accounts, 200

Ppackages, 50Packet Internet Groper (Ping) service,

238, 293packets in ARP, 308parallel groups, 233parity in RAID, 129partitions

for RAID, 129in replicas, 325

Password Options page, 200passwords

with ADMT, 190in authentication, 303filters for, 122for group accounts, 203in inter-forest migration, 10in intra-forest migration, 13for user accounts, 200

PathPing service, 241paths

in Folder Direction, 114in WINS, 332

PCI (Peripheral Component Interface) devices, 262–263

PDC Emulator Master, 5PDC Emulators

with ClonePrincipal, 187Group Policies for, 109

PDC Operations Masters, 109

PDCs – processors366

PDCs. See primary domain controllers (PDCs)

Peripheral Component Interface (PCI) devices, 262–263

permissionsconflicts in, 302–303for Group Policies, 107, 277–279inheritance of, 301–302for new SIDs, 232in NTFS, 299–302, 300reassigning, 242–250, 243–246,

248in RRAS, 58

Permissions dialog, 246Phone And Modem Options dialog,

334–335Phone Book entry, 320–321physical connectivity, 292pilot groups, 213pilot migration strategies, 22–25ping service, 238, 293Planned application level, 339planning

destinations, 20–21domain selection in, 15–20, 17–19exam essentials for, 25for growth, 38for incremental object migrations,

22key terms and concepts in, 26pilot migration strategies, 22–25for recovery. See disaster recovery

plansPoint to Point Tunneling Protocol

(PPTP), 57policies, group. See Group Policies and

Group Policy Objects (GPOs)

post-migration tasks, 224–225backing up source domains, 234–

235decommissioning source domains,

235–237domain restructure, 29in domain upgrades, 137–139exam essentials for, 250key terms and concepts in, 250–251redefining DACLs, 225–234, 227,

231removing SIDHistory from objects,

242–250, 243–246, 248verifying network services func-

tionality, 237–241verifying success, 237

post-upgrade domain restructure, 28power protection, 134PPTP (Point to Point Tunneling Proto-

col), 57#PRE command, 311–314pre-migration environment, restoring,

135, 215–219primary domain controllers (PDCs)

backing up, 87in domain restructure, 145in domain upgrades, 93–98in recovery, 78upgrading, 4–5

Print permission, 248printer permissions, 247–249, 248Printer Properties dialog, 247, 248pristine environments, 66–68processing order of Group Policies,

108processors

for ADMT, 170for domain controllers, 94

promoting member servers – remote procedure calls (RPCs) 367

requirements for, 30–31promoting member servers, 270protocols

configuring, 155network, 52

proxy servers, 37PTR (inverse lookup) records, 156Public Key Policies option, 111publishing applications, 50–51pull replication, 326

Qqueries, mixed mode vs. native mode,

122Query Modem option, 335

RRADIUS (Remote Authentication

Dial-In User Service), 57RAID (redundant arrays of indepen-

dent disks), 127–130RAS (Remote Access Service), 319

configuring, 154–155, 164–165, 320–321

in domain upgrades, 97monitoring, 321–322in native mode conversions, 120–

121physical components, 319–320

re-deploying domain controllers, 235–237

Read permission, 107, 301Readiness Analyzer

for compatibility, 256–257, 257, 338

for third-party software, 267working with, 271

Ready application level, 339reassigning permissions, 242–250,

243–246, 248Record A Log option, 335record aging, support for, 70recovery. See disaster recovery plansRecovery Console, 216, 218–219Recovery tab, 330Recycle Bin in ADMT installation,

171redefining DACLs, 225–234, 227, 231redirection for Group Policies, 111–

112, 114redundant arrays of independent disks

(RAID), 127–130refreshing Group Policies, 106Registry

for ADMT, 172for application compatibility, 341backing up, 132for ClonePrincipal, 195for Group Policies, 111, 286for third-party applications, 343

Registry option, 111Relative Identifier (RID) Masters, 173,

228Relative Identifiers (RIDs), 206, 226–

228Remote Access Service. See RAS

(Remote Access Service)Remote Authentication Dial-In User

Service (RADIUS), 57remote backups, 234Remote Installation Services (RIS),

269remote procedure calls (RPCs), 152

Remove method for translation – SACLs (System Access Control Lists)368

Remove method for translation, 210removing SIDHistory from objects,

242–250, 243–246, 248Rename With Prefix option, 201Rename With Suffix option, 201renewing DNS registrations, 239Repair menu, 218–219Replace method for translation, 210replication, 322–323

Active Directory, 325–328Dfs, 322–325FRS. See File Replication Service

(FRS)with Group Policies, 278in restoring failed domain control-

lers, 217in WINS, 333

replication bridges. See file replication bridges

replmon.exe tool, 274Report Selection page, 175, 176Report System Compatibility page,

257, 257Reporting Wizard, 169, 174–180,

174–179Reports tree, 173resolving hostnames to IP addresses.

See DNS (Domain Name System)resource domain migration, 180–183resources

conflicts in, 262–264, 263in trial migrations, 213

Resources tab, 263restore subtree command, 222Restore tab, 133, 133Restore Wizard, 130restoring, 133, 133

accounts, 221, 223–224

damaged directories, 217failed domain controllers, 216–217network services, 219–221pre-migration environment, 135,

215–219Restricted Group option, 111restructure, domain. See domain

restructure; domain upgrades with restructure

Retry Tasks Wizard, 169Reverse Lookup Zone page, 75reverse lookup zones, 75revision numbers in SIDs, 226, 228RID (Relative Identifier) Masters, 173,

228RIDs (Relative Identifiers), 206, 226–

228, 227rights. See permissionsRIS (Remote Installation Services),

269ROBOCOPY utility, 157rollback in disaster recovery plans,

135–136rollout preparation, 24–25root domains

for Multiple Master Domain model, 18, 19

names for, 15–16, 17roots, OUs off, 151routers, 34Routing and Remote Access Service

(RRAS), 56–58, 58, 154, 164RPCs (remote procedure calls), 152

SSACLs (System Access Control Lists),

225

Safe mode – server-only backups 369

Safe mode, 261safe mode of operations, 80SAM (Security Accounts Manager)

databasecopying, 185in PDC upgrades, 4recovering, 78–79

Same As User Name option, 200saving Netdiag output, 296scalability as upgrade goal, 85Scavenge Stale Resource Records

option, 76scavenging, DNS support for, 70Schedule Jobs tab, 133, 134schedules

for backup operations, 130, 133, 134

for FRS, 323for replication, 328

Schema Master, 46schema partitions, 325SCL (Software Compatibility List),

339scripts

for ClonePrincipal, 185–187conflicting settings from, 283failures in, 280–283, 282for Group Policies, 103, 110

SCSI-based systems, 259, 265second monitors, problems with, 260secure channels, NETDOM for, 192security, 34–35

and application compatibility, 341for applications with limited licens-

ing, 37for backups, 235cloning security principals, 42domain structures in, 35–36

for future growth, 38Group Policies for, 103, 110–111high-security resources, 36–37for Internet access, 37–38in mixed mode, 121moving security principals, 38–41trust relationships, 41–42as upgrade goal, 86

Security Access Tokens, 229–230Security Accounts Manager (SAM)

databasecopying, 185in PDC upgrades, 4recovering, 78–79

Security Configuration and Analysis tool, 86

Security Descriptors, 225Security dialog, 303security identifiers. See SIDs (security

identifiers)Security Options option, 163Security Policy Setting dialog, 163Security tab

for DACLs, 230, 231in NTFS, 301for permissions, 242, 243

folder, 245–246, 245–246printer, 247–248, 248

security tokens, 41Security Translation Wizard, 169

for inter-forest migration, 181–182for intra-forest migration, 184

Select Group Policy Object Wizard, 112–113

Select Users dialog, 200selecting domains, 15–20, 17–19server and computer backups, 235server-only backups, 235

servers in domain restructure – software in disaster recovery plans370

servers in domain restructure, 145Service Account Migration Wizard,

47–48, 48, 169in inter-forest resource domain

migration, 181in intra-forest resource domain

migration, 183service accounts, 47–48, 48service configuration for domain

upgrades, 99–102service packs, 92Service (SRV) records

for Active Directory, 53–54BIND for, 101DNS for, 70for domain controllers, 239in replication, 327support for, 158–159

Services console, 328–329, 329session statistics pane in Network

Monitor, 297Settings tab, 114setup, blue screens during, 264–265setup program, 35, 43Setup Wizard, 60, 170shared local groups, 145shared resource issues, 302–303shortcut trusts, 305–306, 305shutdown scripts, 110, 280sidhist.vbs script, 186, 188SIDHistory feature, 229, 231, 284

for ADMT, 171with ClonePrincipal, 185, 187for group accounts, 203in inter-forest migration, 10mapping SIDs to, 209with moved accounts, 40–41purpose of, 233–234

removing from objects, 242–250, 243–246, 248

in restoring accounts, 221for user accounts, 202

SIDs (security identifiers), 210, 226–229, 227

with duplicate accounts, 283–284in inter-forest migration, 10mapping to SIDHistory, 209for moved accounts, 39new, 232in RRAS, 58

Simple Mail Transfer Protocol (SMTP)

in IIS installation, 44–45in site design, 152

Single Master Domain modelmigrating to Active Directory, 17,

18trusts in, 149

site-aware clients, 322site level, inheritance in, 105sites, creating, 151–153, 162–163Sites container, 163_sites sub-domain, 159Small Computer System Interface

(SCSI)-based systems, 259, 265SMS (Systems Management Server),

241SMTP (Simple Mail Transfer Proto-

col)in IIS installation, 44–45in site design, 152

Software Compatibility List (SCL), 339

software deployment, 49–51, 50software in disaster recovery plans,

130–133, 131, 133–134

Software Installation – target domains 371

Software Installation, 103source domains

backing up, 234–235decommissioning, 235–237

speed of replication, 327SRV records. See Service (SRV)

recordsstand-alone servers in domain

upgrades, 91Standard Primary zones, 74–75Standard Secondary zone, 74startup floppies, 219startup scripts, 110, 280state-based replication, 326station statistics pane in Network

Monitor, 298status information in Group Policy

Container, 104stop screens, 264store and forward replication, 326strategies, migration

domain upgrades, 3–6domain upgrades with restructure,

6–13, 7exam essentials for, 13–14key words and concepts in, 14

striping, 128–130striping with parity, 128–129sub-domains, 158–159subauthorities in SIDs, 226subnets, 34summary pane in Network Monitor,

298–299, 298Support Tools, installing, 194–195Support Tools folder, 186System Access Control Lists (SACLs),

225system files, protecting, 340

System Log, 325system objects with MoveTree, 190System permission for Group Policies,

107System Policies, 102

Group Policies from, 112translation issues, 272–279, 275–

276, 287–288System Services option, 111System State information

backing up, 131–132, 217, 222–223

restoring, 217–218%SystemRoot% directory, 347Systems Management Server (SMS),

241Sysvol

backing up, 132for file replication bridges, 116–

117GPTs in, 104replication information in, 156

Ttarget domains, 147–148

creating, 160–161exam essentials for, 165–166Group Policy implementation for,

153–154, 163–164key terms and concepts in, 166–167network services configuration for,

154–160OUs for, 150–151, 150, 162procedures for, 160–165site design implementation for,

151–153, 162–163

target paths for Folder Redirection – _udp sub-domain372

trusts for, 148–149, 149, 161–162target paths for Folder Redirection,

114TCP/IP, 52

for Active Directory, 99ARP for, 239configuring, 155TTLs in, 240

_tcp sub-domain, 159technical support, 258, 264temperature concerns, 134–135templates, 103, 109–110, 113–114termination problems in SCSI, 259test deployments

for domain restructure, 213–214for domain upgrades, 124–126

test environments, creating, 22–24third-party drivers, services, and tools

applications, 343–345, 344blue screen problems from, 265–

266DNS servers, 71in domain upgrades, 95troubleshooting, 267–268

Time To Live (TTL) mechanism, 240TLS (Transport Layer Security), 57tools

for domain restructure. See domain restructure

troubleshooting, 345–346ADMT, 346–347ClonePrincipal, 347exam essentials for, 348key term and concept in, 348NETDOM, 348

total statistics pane in Network Moni-tor, 298

Trace Route utility, 239–240Tracert service, 239–240transitive trust relationships, 121–122Translate Objects page, 209

Translate Roaming Profiles option, 184, 201

translation processSecurity Policies, 272–279, 275–

276, 287–288for SIDs, 209–210

Transport Layer Security (TLS), 57troubleshooting

access issues. See access issuesaccounts. See accountsapplications. See applicationsdomain upgrades. See failed

domain upgradesmodems, 334–335network services. See network ser-

vicestools, 345–346

ADMT, 346–347ClonePrincipal, 347exam essentials for, 348key term and concept in, 348NETDOM, 348

Trust Migration Wizard, 169, 180–182

trustsin ADMT, 171for domain restructure, 145–146establishing, 41–42in inter-forest migration, 11issues in, 304–306, 305in mixed mode, 121NETDOM for, 41–42, 192for target domains, 148–149, 149,

161–162Trusts tab, 161TTL (Time To Live) mechanism, 240two-way trusts, 171, 304, 306

U_udp sub-domain, 159

underscore (_) characters in BIND – WINS 373

underscore (_) charactersin BIND, 101in subdomain names, 158

Undo Wizard, 169Uniform Resource Locators (URLs),

239uninterruptible power supplies (UPSs),

96, 134universal groups, 328Update User Rights option, 184, 201updates, dynamic, 70, 76, 269–270Upgrade.txt file, 257upgrades, domain. See domain

upgrades; domain upgrades with restructure

UPNs (user principal names), 303UPSs (uninterruptible power supplies),

96, 134URLs (Uniform Resource Locators),

239Use Automatic Settings option, 263User Account Migration Wizard, 199–

201, 199User Account page, 176, 177, 203User Manager For Domains, 194User Migration Wizard, 168

for inter-forest migration, 181–182for intra-forest migration, 183–184

User Options page, 201user principal names (UPNs), 303User Rights option, 182users

accounts for. See accountsfor pilot programs, 24–25rights for, 268–269, 284–286, 286,

288–289in trial migrations, 213

Vverbose logging, 273

verifyingapplication compatibility, 338–339network services, 138, 237–241successful migration, 237

versionsin application compatibility, 341in Group Policy Container, 103

Virtual Private Networks (VPNs), 57virus protection in domain upgrades,

95viruses, boot-sector, 266–267Visual Basic scripts, 185–187Visual Interdev RAD Remote Deploy-

ment Support, 45VPNs (Virtual Private Networks), 57

WWeb services, compatibility of, 44–45Web sites for compatibility issues, 43well-connected TCP/IP subnets, 152Windows 95 and 98 systems in

domain upgrades, 91Windows File Protection feature, 340–

341Windows Installer, 49–50Windows Internet Naming Service.

See WINS (Windows Internet Naming Service)

Windows NT systems in domain upgrades, 90–91

Windows Update, 43winnt32.exe program

access to, 35in domain upgrades, 96for Readiness Analyzer, 256

Winnt32.log file, 257WINS (Windows Internet Naming

Service), 54–55configuring, 157–158for domain upgrades, 100–101

WINS.mdb file – Zone Type page374

for dynamic updates, 269–270issues in, 332–333recovering, 80–81verifying operation of, 138

WINS.mdb file, 332WINS servers, restoring, 220Winsock.dll file, 340Workstation 3.51 and 4 systems in

domain upgrades, 90–91World Wide Web (WWW) in IIS

installation, 44

Xxcopy.exe utility, 157

YYes, Create A Forward Lookup Zone

option, 74

ZZone File page, 75Zone Name page, 75zone transfers, 71, 101, 333Zone Type page, 74–75

MCSE: Windows 2000 Migration Exam Notes

Documents

Transcript of MCSE: Windows 2000 Migration Exam Notes