MCSE: Windows 2000 Migration Exam Notes

MCSE: Windows® 2000 Migration Exam Notes™ Todd Phillips Quentin Docter SYBEX® MCSE: Windows 2000 Migration Exam Note...

Author: Todd Phillips | Quentin Docter | TBD

23 downloads 794 Views 5MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

MCSE: Windows® 2000 Migration Exam Notes™

Todd Phillips Quentin Docter

SYBEX®

MCSE: Windows 2000 Migration Exam Notes

This page intentionally left blank

MCSE: Windows® 2000 Migration Exam Notes™

Todd Phillips Quentin Docter

San Francisco • Paris • Düsseldorf • Soest • London

Associate Publisher: Neil Edde Contracts and Licensing Manager: Kristine O’Callaghan Acquisitions and Developmental Editor: Elizabeth Hurley Editor: Suzanne Goraj Production Editor: Mae Lum Technical Editor: Donald Fuller Electronic Publishing Specialists: Jangshi Wang, Judy Fung Book Designer: Bill Gibson Graphic Illustrator: Tony Jonick Proofreaders: Andrea Fox, Mae Lum Indexer: Ted Laux Cover Designer: Archer Design Cover 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: 2001086973 ISBN: 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 Incorporated. 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 trademarks 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 limited 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 Writing 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 giving 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 Chapter

Chapter

Chapter

1

2

3

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

Evaluate current hardware. 29

26

Preparing the Environment for Migration

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

Planning and Deploying a Domain Upgrade

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

65

83

viii Contents

Chapter

4

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

Planning and Deploying an Intra-Forest Domain Restructure and an Inter-Forest Domain Restructure

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

Implement disaster recovery plans. 214

Perform post-migration tasks. 224

141

Contents

Chapter

Index

5

Troubleshooting

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

ix

253

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 Corporation, to give you the critical skills and knowledge you need to prepare for one of the elective requirements of the new MCSE certification 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 appealing. 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 understanding of the technologies involved matches up with the expectations of the MCSE test makers in Redmond. Or, perhaps you’re relatively new to the world of Microsoft networking, drawn to it by the promise of challenging work and higher salaries. You’ve just waded through an 800-page MCSE Windows 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 available. 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 candidates familiarize themselves with the subjects on which they can expect to be tested in the MCSE exams. For complete, in-depth coverage 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 Troubleshooting. 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 according to the type of information presented.

xii Introduction

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 computer to be completed. From installing operating systems to modifying 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 Windows 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 electives you need to complete your MCSE track.

Exam Requirements Successful candidates must pass a minimum set of exams that measure technical proficiency and expertise:

Candidates for MCSE certification must pass seven exams, including 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.

xiv Introduction

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: 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


One of these exams is required: Exam #

Title

Requirement Met

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

Exam #

Title

Requirement Met

70-221

Designing a Microsoft® Windows® 2000 Network Infrastructure

Core (Design)

xv

Two of these exams are required: Exam #

Title

Requirement Met

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

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.

xvi Introduction

Exam Registration You may take the exams at any of more than 1,000 Authorized Prometric Testing Centers (APTCs) and VUE Testing Centers around the world. For the location of a testing center near you, call Sylvan Prometric at 800-755-EXAM (755-3926), or call VUE at 888-837-8616. Outside the United States and Canada, contact your local Sylvan Prometric 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 requirements, 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 systems, 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 centers. 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

xviii Introduction

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 materials 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 Prometric 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 development phases or to report a problem with an exam. Address written correspondence to: Certification Development Team, Microsoft Education 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 certification 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: the migration type. Types consist of domain Select 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

Developing the Migration Strategy

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.

Critical Information 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 restructuring 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 9x 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 structures in a test environment that parallels your existing network. This

4 MCSE: Windows 2000 Migration Exam Notes

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 Controller (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 security principals. 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 playing the Operations Master role of PDC Emulator Master. It will use Active Directory to store objects but will remain backwardcompatible 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 9x 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 immediate 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.


In some cases, you may want to stay running in mixed mode. Mixed mode provides the best in backward compatibility with older network operating systems. There are generally only a few specific reasons 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 downlevel 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

Inter-forest migrations

Intra-forest migrations


7

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.

Existing Network

Parallel Network

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 existing NT domain controllers when performing your migration.


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 situations: post-upgrade, instead of upgrade, or post-migration. Postupgrade restructuring is used to eliminate network complexity once the initial Windows 2000 domain has been established. If your current Windows NT network is considered unsalvageable, you may just want to scrap the whole thing and install a new Windows 2000 network. 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 network 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 database 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 relationships 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 numbers 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 cannot 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 target domain. This is the primary migration scenario when migrating 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


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 migrations. 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 Identifiers (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 functionality 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. Create 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 maintaining 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, application 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.


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 mixedmode 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 cannot 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 configuration 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 passwords 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 network, 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.


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.

Key Terms and Concepts 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 hexadecimal 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 9x. mixed mode A Windows 2000 network that contains Windows NT Server domain controllers. Primary Domain Controller (PDC) Windows NT Server designated 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 settings 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


15

Plan migration.

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.

P

lanning is the most critical stage of any successful project. Performing 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 migration strategy. This includes knowing what to migrate, when to migrate it, and where to migrate it.

Critical Information 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 consider 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.


A major consideration when choosing the new root domain name is whether or not the resources will be available on the Internet. Choosing 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 Internet, 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 network 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.

Chapter 1


17

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

Pinkeel.com

Seattle

Dallas

Boston

Existing Network

Seattle

Dallas

Boston

Parallel Network

In more traditional NT domain models, the migration is more clearcut. The easiest by far is the single domain model, as you would simply upgrade your domain controllers to Windows 2000 in mixed mode. Once everything is running smoothly on Windows 2000, convert 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 controlled by local administrators, migrate the resource domains as their own OUs within the new domain, and delegate control to the appropriate people.


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

Root Domain

Master Domain

Resource Domain 1

Resource Domain 2

Child Domain

Child Domain

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

Forest MAD1

MAD2 MAD1 MAD2

R1

R2

R3

R1

R2 R3

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.

Chapter 1


19

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

Root MAD1

MAD2 MAD2

MAD1

R1

R2

R3

R1

R2

R3

The other options involve combining domains. One such choice would be to combine the master domains into one root domain containing 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 questions, you must consider the information you have been given as part of the case study. What are the company’s priorities for the migration? Pay particular attention to the information about which computers 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 building, a child for the department, and so on. However, object names start getting ridiculous. Imagine locating an object with the unique


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 logical 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 network 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 granularity, 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

Chapter 1


21

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 implement 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 centralized 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 distributed, 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 administration. 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 administrator 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 centralized 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 servers 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 procedures will really work, to planning for restoring your current network 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

Chapter 1


23

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 equipment 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 process 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 running 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 opportunity 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 services for them and upgrading their workstations to Windows 2000. The pilot gives these users a chance to learn the new features of Windows 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 environment. 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

Chapter 1


25

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 Internet. 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 migration. Both test labs and pilot migrations are great for ironing out issues that may occur during the actual migration.


Key Terms and Concepts granularity Being able to set options (such as security) at a very confined 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 applications 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 company’s political structure.

Evaluate the current environment.

W

indows 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 reallife situations.

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

Chapter 1


27

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 security 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 application 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 structure 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 relatively 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 postupgrade restructure, the restructure instead of upgrade, and the postmigration 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 something 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 restructured domains. This means that you are creating an ideal forest structure for your organization that is isolated from the production environment. Over time, as more accounts are moved to the pilot network, the pilot network becomes the production environment.

Chapter 1


29

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, restructuring 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 authentication 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 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

his 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 variety 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 Replication will also be especially helpful.

Critical Information When determining the suitability of your current computer hardware for Windows 2000, the best place to start is with the minimum hardware 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 requirements. With Windows 2000, it will also be important to remember the recommended hardware. With NT 4, offices could still use 80386 computers. With Windows 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.

Chapter 1


31

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

Hardware Resource

Minimum Requirement

CPU (central processing unit)

133MHz Pentium—up to two processors supported

Memory

32MB

Hard disk

2GB with at least 650MB free space

Recommended

64MB

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

Hardware Resource

Minimum Requirement

Recommended

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 Requirement

CPU

133MHz Pentium—up to eight processors supported

Memory


Recommended

256MB


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

Hardware Resource Hard disk

Minimum Requirement 2GB with at least 1GB free space

Recommended 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 Requirement

Recommended

CPU

Pentium III Xeon Processors or higher—up to 32 processors supported

Memory


256MB

Hard disk

2GB with at least 1GB free space

Requires more free space if installing over a network

NOTE With these requirements in mind, you should carefully assess your current hardware on any computer that will be upgraded to Windows 2000. In some cases, you will find systems that need to have one or more resources upgraded before the operating system can be upgraded. 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.

Chapter 1


33

Another resource to help you evaluate your current hardware’s suitability 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 hardware, 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 outcome 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 practical 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 hardware 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 priority, 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 category 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 network 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 effectively cut the broadcast traffic in half, too. Routers are normally configured 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 considering a move to Windows 2000 because so many of the security features have changed from NT 4. Since so many networks today are connected 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 implications 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.

Chapter 1


35

Evaluating network security needs can be a very time-consuming process. 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 security in Windows 2000. You’ll also want to consider where your network 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 organization need to be. It is possible to collapse almost any multipledomain 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 controls, multiple domains may be necessary. Two, if different locations represented in your network have different geographical settings, different 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 administrative 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 location, 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.

Chapter 1


37

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 legitimate need to use them. Keep entries for each of these in your inventory lists. One approach would be to prevent normal users from having 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 network 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 policies 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 greatest 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

Chapter 1


39

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, Windows 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 feature 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 removing 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 target domain to parallel the old global group, but you would have to assign permissions again for all of the resources to which the old global group had access. Another possible solution would be to use Windows 2000’s ability to move security principals to relocate the existing 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 management utilities that Microsoft provided for Active Directory under-

Chapter 1


41

stand how to update the SIDHistory when you move a security principal 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 adding the SIDHistory to the access token. This has the effect of authenticating the user for resource access based on his or her current SID, the SIDs of any groups the user belongs to, and the previous 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 target 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. Windows 2000 automatically creates two-way transitive trust relationships 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 Windows 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 alternative 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. ClonePrincipal 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.

Chapter 1


43

Evaluating application compatibility Application compatibility is one of the greatest concerns in any operating 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. Windows 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 product 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) version 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 compatibility issues, but you should still install a test server to fully evaluate the compatibility with your own Web content. The administration console for IIS has changed, at least in its location. You can find the Internet Services Manager in the Administrative 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 thirdparty 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 during setup include the Simple Mail Transfer Protocol (SMTP) mail service, in addition to World Wide Web (WWW) and File Transfer

Chapter 1


45

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 common in NT 4 or Windows 2000 networks. Microsoft has integrated 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 Connector (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 administrative 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 Directory 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 Directory 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

Chapter 1


47

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 Directory 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 Figure 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 wizard prompts you to enter the names of the computers that will provide 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 industry or even one business, and often poorly documented. They include

Chapter 1


49

databases, incident tracking, monitoring, and other applications essential 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 program isn’t supported at all on Windows 2000, and have a contingency plan for this situation. Check Microsoft’s Windows 2000 compatibility Web site to see if there are any necessary updates for the program.

NOTE Many LOB applications are designed to run on a specific operating 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 installation packages, the Windows Installer package (a file with an .MSI extension). This file contains the information needed to tell the Windows 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 forest 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 software 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

Chapter 1


51

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 network. 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 environment. 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 Windows 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 network. Downlevel clients, such as Windows NT and 98, do not support 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

Chapter 1


53

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 recommended. 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 information. 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 services 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 Windows 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 domain. 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 secondary 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 structure. 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 organization—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 target domain to use the WINS servers, then the new domains will begin

Chapter 1


55

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 Windows 2000 and NT or Windows 9x clients, consider running the WINS server service on one or more of your Windows 2000 servers. However, 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 further 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 deployment. If at all possible, try to eliminate the need for NetBIOS-based services. NETBIOS

NetBIOS is not required in a native-mode Windows 2000 network, though you may still need its services if you have applications 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 requirement 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 Windows 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 Service (RRAS) in Windows 2000. It offers improved performance for dialup 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. Possibilities include generic token cards, Message Digest 5 Challenge Hand-

Chapter 1


57

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 Provider. 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 configure. 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 create 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 manage 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

Chapter 1


59

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 others acting as import computers. FRS uses the same replication mechanism 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 replication 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.

Necessary Procedures 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 CDROM 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 service, 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 authorize the service—i.e., an Enterprise Administrator, unless the permission has been delegated. 2. After installing DHCP on your Windows 2000 server, open the

DHCP console by clicking Start Programs Administrative Tools DHCP.

Chapter 1


61

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 common migration issue is dealing with the service account. After migrating 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 applications. 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 environments, 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 enhancement on the PPTP RAS protocol. It is most commonly used in conjunction 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 controller replicates to the other NT domain controllers.

Key Terms and Concepts 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.

Chapter 1


63

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 MICROSOFT EXAM OBJECTIVES COVERED IN THIS CHAPTER: and configure a pristine Create environment. (pages 66 – 68) the Windows 2000 DNS service or configure Install the existing DNS implementation as appropriate. (pages 69 – 77) and deploy a recovery plan. Consider Develop 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 structure, 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.

The 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

Critical Information 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 relationships, 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 created, 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.


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 isolated network. In its pristine state, it will not contain any users (other than Administrator and Guest), but is ready for a migration.

Key Term and Concept 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 implementation as appropriate.

D

NS has long been the name resolution method of choice on the Internet. Now with the addition of Active Directory in Windows 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 implementations. You may be expected to take an existing network’s DNS structure and analyze it for use with Windows 2000. You may also be required to suggest alternate methods of name resolution if the existing structure is not sufficient for the migration. For a detailed discussion 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.

Critical Information 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


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 standards for DNS and implements a few new features as well, such as dynamic updates and Service (SRV) records. These features in particular 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 tolerance and security. All zones that are integrated with Active Directory are automatically replicated to all domain controllers in the forest. The new DNS service also acts as a locator service for Windows 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, Windows 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 configured to accept updates only from an authorized user account.

Chapter 2


71

Administration through the Management Console The DNS service in Windows 2000 is fully integrated into the Microsoft Management Console (MMC) for easier administration. Command-line administration Windows 2000 provides a commandline 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 transfers that contain only the changed records. This can help to reduce network 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.


Windows 2000 computers use fully qualified domain names (FQDNs) to communicate. An FQDN is the combination of the hostname 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 Services 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 Configure 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.


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.

Necessary Procedures 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 network 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 master 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.


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 scavenging, 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.

Key Terms and Concepts 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 certainly covers recovery planning, is another critical step in the migration process. This way, if anything goes wrong, you have something to fall back on besides your resume.

Critical Information Recovery planning should enable you to restore the original environment 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.


With a migration from NT to Windows 2000, there are some preventive 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 network 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 promote 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 controllers and install them as BDCs to the new (old) domain. It will take some time to perform all of the reinstallations, but no account information 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 migration. 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 performing 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 activate 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 service 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 Windows 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 conflicts, 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 conflicts 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


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

Key Term and Concept 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 MICROSOFT EXAM OBJECTIVES COVERED IN THIS CHAPTER: a domain upgrade strategy. Develop (pages 84 – 90) an operating system upgrade path. Develop Considerations may include operating system version and service packs. (pages 90 – 92) the PDC, BDCs, application servers, DNS Upgrade servers, and RRAS servers. (pages 93 – 98) networking protocols, DHCP, LAN Configure Manager Replication, WINS, NetBIOS, Windows 2000 DNS Server service, and existing DNS service. (pages 99 – 102)

Implement group policies. (pages 102 – 115) file replication bridges. Implement (pages 115 – 119) domains to native mode. Convert (pages 119 – 124) test deployments of domain Perform upgrades. (pages 124 – 126) disaster recovery plans. Implement (pages 126 – 137)

Restore pre-migration environment.

Roll back implementation to a specific point.

Perform post-migration tasks. (pages 137 – 139)

Back up domains.

Verify functionality of network services.

T

his is the meat and potatoes of your entire migration. 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 involving 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.

Develop a domain upgrade strategy.

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.

Critical Information Before you begin planning, take a moment to remember your upgrade goals. Most of the time, goals center on either business needs or technology 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 features 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) database. Active Directory can store literally millions of objects without trouble.


Improved security Through the use of Group Policy, administrators can assign very specific restrictions to users, groups, and computers. 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 implications 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 disruption 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 security 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 insufficient 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 controller. 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 controller (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 synchronized 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.


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 controller 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 controllers 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 outlined 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.


Key Term and Concept 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.

Critical Information 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 combinations 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

T A B L E 3 . 1 : Upgrade Options from NT to Windows 2000 (continued) Operating System

Can Upgrade to

Can Become

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 Datacenter Server

Stand-alone server, member server, domain controller

Windows 95 or 98

Windows 2000 Professional

The ability to upgrade from Windows 9x 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 Windows 9x 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. Examples would be upgrading Windows 3.1 to Windows 98 or upgrading NT 3.1 to NT 3.51 or NT 4. Once that upgrade is completed, upgrade the new operating system to Windows 2000.


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 information and security information is maintained. This will save you the headache of having to re-create all users and groups, as well as reassigning permissions to all resources. Since you should have been running the latest service pack for Windows NT, service packs should not be an issue when migrating to Windows 2000. If by chance you have not upgraded to the latest service 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 Windows 2000. Windows 95, 98, and NT machines can be directly upgraded to Windows 2000. Know how to upgrade an “incompatible” operating system to Windows 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 second choice is to completely reinstall the machine.

Key Terms and Concepts 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 computer that is part of a domain, but is not a domain controller. Member servers do not authenticate users in the domain. service pack Collection of patches and upgrades to critical operating 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 controllers to begin the migration to Windows 2000. Most of your servers 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.

Critical Information 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 Windows 2000 Server or Advanced Server.

Member server running NT Server 3.51 or 4

Member server running Windows 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 performed 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 hardware 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 minimum 256MB or more recommended

Hard disk

1.2GB of free space on the boot partition 6MB 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

Keyboard Mouse or other pointing device

Chapter 3


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 application, 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 controllers 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 sophisticated enough to recognize that you’re installing an operating system 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 temporarily 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 Windows 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 computer’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 network 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

Chapter 3


97

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 upgrades, 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 upgrading 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 Directory immediately after the upgrade. If the DHCP server is not authorized in Active Directory, it will not be allowed to offer leases to client computers. If the member server is running the DNS service, the zones will be available immediately after the upgrade with no further 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 support 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.

Key Terms and Concepts 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.

Chapter 3


99

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

M

ost 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.”

Critical Information 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, services, 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 ability 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 themselves. Other than that, the major DHCP rules still apply: Use more than


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

LAN Manager Replication Windows 2000 does not support Windows NT’s replication mechanism, LAN Manager replication (LMRepl). LMRepl controlled replication 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 replication 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 function 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.

Chapter 3


101

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 computers 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 implementation of DNS, do it. It’s designed to provide everything Active Directory needs. It’s also least likely to cause you problems on a Windows 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 administrative 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 cooperating, you need to create a file replication bridge.


Know when to use WINS. You only need WINS if you have downlevel 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.

Key Term and Concept downlevel clients Client machines that are running a preWindows 2000 operating system.

Implement group policies.

A

dministrators of Windows NT domains frequently used System 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 Windows 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.

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

Chapter 3


103

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 Windows 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 administrators 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 virtual 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 subcontainers that describe the individual policies that apply to computers, 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 Policy information. The GPTs are stored by the Globally Unique Identifier (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 overwriting 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 administrator, 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.

Chapter 3


105

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 having 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 completed. 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 Services 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.

Chapter 3


107

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 administer 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 permissions 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 overrides 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 policies 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 settings, 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 second is to open the Properties sheet for a container in Active Directory,

Chapter 3


109

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 machinespecific 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 password length, age, uniqueness, and other options that affect user accounts.

Chapter 3


111

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 information 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 settings for public key encryption. The Encrypted File System in Windows 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 network 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 redirected. This also serves to make their data available from any computer on the network. The data is not downloaded to the computer they are logging on to, so it doesn’t create any additional logon network 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.

Necessary Procedures 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

Chapter 3


113

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 settings 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’ folders. 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 automatically, 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 processed in the following order: Local GPO, Site GPOs, Domain GPOs, and OU GPOs.

Chapter 3


115

Know what Group Policies are used for. Group Policies have many functions in Windows 2000, including enforcing security settings, controlling 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 Windows NT System Policies into Windows 2000 Group Policies. However, Microsoft does not provide documentation on how to complete this process. It’s best to use trial-and-error for your new Group Policies.

Key Term and Concept 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 information is replicated among all domain controllers. If you have both Windows NT and Windows 2000 domain controllers, this can be a problem. Windows NT used LMRepl, which is replaced in Windows 2000 by FRS. In order to make the two communicate, you need a replication bridge.

Critical Information Windows 2000 Server uses the File Replication Service (FRS) to replicate 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 settings are necessary to ensure security, it’s critical that all domain controllers 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 replicate 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 automatically. 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 replication, it uses the same replication mechanisms. Therefore, it uses the

Chapter 3


117

same replication schedule for inter-site replication as ADS. However, unlike Active Directory, replication content between sites is not compressed. 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 mechanisms 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 controller, 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 compatible 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 supported 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 Volume, or Sysvol, contains the Sysvol shared directory, the Netlogon shared directory, all system policies, group policies, and logon and logoff scripts.

Key Terms and Concepts Distributed File System (Dfs) System of sharing files in a Windows 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.

Chapter 3


119

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 features. 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 converting to native mode.

Critical Information During the migration of your network from NT to Windows 2000, there will be a time when you have a mixture of domain controllers. 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 controllers and Active Directory has been set to function as the exclusive security model. When you have determined that all domain controllers 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 network 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 replication 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

Chapter 3


121

establish the session and then log on using NT credentials. Windows 2000 won’t allow anyone with null credentials to query the Active Directory properties, so this won’t work. It can work, however, 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) database. In this case, authentication is possible. The RAS server contacts an NT BDC. This scenario is very unpredictable 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 Directory 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 information 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 Windows 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 Windows 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


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

Mixed Mode

Native Mode

Multimaster replication

Yes, among the Windows 2000 domain controllers. PDC Emulator provides singlemaster 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 Windows 2000 clients.

Yes

Transitive trust relationships

No

Yes

Change/configuration management

Only on Windows 2000 computers.

Yes

Password filters

Only if installed on each domain controller individually.

Yes, installed automatically on all domain controllers.

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.

Chapter 3


123

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 controller 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 application 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 recommends 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 applications out there.


Key Terms and Concepts 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.

Y

ou have your plan. You have the approval. You have everything 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 deployment gives you the opportunity to safely find out what things you have forgotten.

Critical Information 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 simulate 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

Chapter 3


125

to begin. This may vary according to the project goals, but that usually 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 environment. 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 during 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.


Key Terms and Concepts 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.

I

t’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 Windows 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.

Critical Information 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

Chapter 3


127

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 prevention and disaster recovery. Most of the time, they are very much interrelated. Even the best-laid disaster-prevention plans can’t prevent 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 vendor. Important here is a discussion of redundant arrays of independent (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. 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 number of disks

2

2

3

Maximum number of disks

32

2

32

File systems supported

FAT, FAT32, NTFS

FAT, FAT32, NTFS

FAT, FAT32, NTFS

RAID 0 is called disk striping. Striping provides very high performance 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

Chapter 3


129

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 tolerance. 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 recreate 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 writing to the disk sets. The operating system on a computer with hardware 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 software version is free. Windows 2000 also incorporates new types of partitions. Windows 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 partitioning 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 limitations, 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 volume 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 Windows 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 program. 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 program. 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,

Chapter 3


131

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 configuration 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, computers, groups, and policies. Boot files These are the files required to boot Windows 2000, typically 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 cannot back up a single component of the System State. With the System State information safely backed up, you can recover your domain controller from a complete failure. You would have to reinstall Windows 2000 Server on your computer after repairing whatever 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 information 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.

Chapter 3


133

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 integrated 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 temperature 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

Chapter 3


135

data center, one of the greatest concerns is how to apply air conditioning to prevent heat buildup. And as for dust, the big reason for eliminating dust is that it acts like a blanket inside the computer, causing an ever-greater increase in temperature.

Restoring the pre-migration environment This goes back to the idea of backups. Before you began your migration, 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 necessary 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 completely 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 something 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 difference 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 additional 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 original 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.

Key Terms and Concepts 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.

Chapter 3


137

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.

N

ow that you are done with the migration, you need to make sure everything is working properly. Once you have verified functionality, make sure to back up all critical data and services, just in case one fails.

Critical Information The next area of your network where you need to test your deployment plan is your user and group accounts. It is critical to be certain that they will be upgraded successfully because no migration is considered 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 monitor the user calls to the help desk. If the trouble tickets being cut indicate 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 network 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 connections and cabling. If you did not change the physical backbone of your network, it’s less likely a cabling problem and more likely a network 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 afterwards. 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.

Chapter 3


139

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 troubleshoot 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 complete, make sure users can access all required resources. Also test services such as DHCP, WINS, and DNS.

Key Terms and Concepts 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 MICROSOFT EXAM OBJECTIVES COVERED IN THIS CHAPTER: a domain restructure Develop strategy. (pages 143 – 147) or configure the Windows 2000 target Create 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.

and configure tools, including ADMT, Select ClonePrincipal, MoveTree, NETDOM, and the Windows 2000 Resource Kit tools. (pages 167 – 198) global groups and user accounts. Migrate (pages 198 – 208) local groups and computer accounts. Migrate (pages 208 – 212) test deployments of intra-forest Perform migrations and inter-forest migrations. (pages 213 – 214)

disaster recovery plans. Implement (pages 214 – 224)

Restore pre-migration environment.

Roll back implementation to a specific point.

post-migration tasks. Perform (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


your network may lose functionality. You also need to be aware of the potential security risks involved with a domain restructure.

Critical Information There are two basic scenarios for restructuring domains. The first involves migrating users from an NT environment to a new Windows 2000 structure. The second involves consolidating Windows 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


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 member servers and workstations to the new domain, and decommission the original source domain.

Chapter 4


147

Key Term and Concept 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 establishing 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.

Critical Information 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


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 applications that require communication with an NT PDC. Placing all roles upon the first domain controller in the forest can be a burden, 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 network 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

Acct_Dom

Sprockets.local

Target Domain Resource1

Resource2

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 target domain. Use either an LMHosts file or a static entry in the Windows Internet Naming Service (WINS) server’s database.


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 organizational 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 restructuring 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

IT

Accounting

IT OU

Sales

Original Domain

Accounting OU

Sales OU

Target 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 security principals to the default containers in the target domain, and then after the move divide them into OUs.

Chapter 4


151

NOTE On the exam, OUs are a perfect alternative to having a multiple 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 management 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 container, 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 company, 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 Migration 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


Active Directory terms, a site is one or more well-connected TCP/IP subnets organized for security and replication topology. In this definition, 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 computers 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 distributing software and assigning user rights, and they take the place of the System Policy from NT. Group Policy is an improvement 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


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 security. 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 Policies 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


155

NOTE Windows NT gave users dial-in permissions once their account 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 migration 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, routing, 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 important part of your network services in most networks. DHCP can be implemented on an NT Server, a Windows 2000 Server, other operating 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). Windows 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 controllers can participate in FRS. Because the two services are incompatible, 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 Windows 2000 environment, and if so you will be using the FRS exclusively. In this case, you need to use the appropriate scripts to convert 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.

Chapter 4


157

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 Windows 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 synchronize 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 network 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 possibility for reducing the use of NetBIOS over your Windows 2000 network: 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.

Chapter 4


159

_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 identifies the actual file containing the zone information as _msdcs .sprockets.db. check-names ignore turns off the default namechecking 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 Windows 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.

Necessary Procedures 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 Windows 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

Chapter 4


161

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.

Chapter 4


163

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 permission, 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

Chapter 4


165

you still want to control RAS access through the account permissions 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, including 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 restructures. 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 Windows 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 applications, and DNS is critical for proper operation of Active Directory.

Key Terms and Concepts 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 applications that require the services of a PDC. Remote Procedure Call (RPC) Protocol used for intra-site replication between domain controllers. Simple Mail Transfer Protocol (SMTP) Unsecure networking protocol originally designed for e-mail transport, used in inter-site domain replication.

Chapter 4


167

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

Critical Information 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 better 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 security 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.

Chapter 4


169

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 computer 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)

Chapter 4


Windows NT 4 with Service Pack 4 or higher (Intel and Alpha platforms)

Windows 2000

171

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 preparation. 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 performing the migration. This will prevent the accounts from generating 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 TcpipClientSupport, 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 management 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 security. 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.

Chapter 4


173

If you are using ADMT to perform an intra-forest migration, there are some additional considerations. When performing an intra-forest migration, 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.

Chapter 4


175

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.

Chapter 4


177

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 Wizard will run the reports you specified and return the information to the Migrator console window.

Chapter 4


179

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,

Chapter 4


181

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 computer 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 Profiles 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 settings 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 planning 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.

Chapter 4


183

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

Chapter 4


185

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 Support 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 Windows 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 particularly useful if the server is acting as a resource server for applications 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 Planning 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 domains 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: 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. sidhist.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 clonepr.vbs

Chapter 4


187

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. This script clones all of the global groups in a given domain to the target domain. clonegg.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.

cloneggu.vbs

This last script clones all of the shared local groups on the domain controllers in the source domain to the target domain. clonelg.vbs

Preparing to Use ClonePrincipal

ClonePrincipal accesses two different domains for some very sensitive work in terms of security. For this reason, you must have administrator 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 controller 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 Registry 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, helping to prevent unauthorized use of ClonePrincipal. Using ClonePrincipal

You can choose to use ClonePrincipal with the sample scripts provided 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: This script copies the current SID of one account to the SIDHistory attribute of one destination account. Its syntax is sidhist.vbs

Cscript sidhist.vbs /srcdc:<source PDC> /srcdom:<source domain> /srcsam: /dstdc: /dstdom: /dstsam: To clone a single account from the source domain into the target domain, use clonepr.vbs. Its syntax is clonepr.vbs

Cscript clonepr.vbs /srcdc:<source PDC> /srcdom:<source domain> /srcsam:<source account> /dstdc: /dstdom: /dstsam: /dstDN:<destination Distinguished Name>

Chapter 4


189

This script clones all global groups and users from the source domain to the target domain. Its syntax is

cloneggu.vbs

Cscript cloneggu.vbs /srcdc:<source PDC> /srcdom:<source domain> /dstdc: /dstdom: /dstOU:<destination OU> The task of this script is to clone shared local groups from the source domain controller to the destination domain controller. Its syntax is clonelg.vbs

Cscript clonelg.vbs /srcdc:<source PDC> /srcdom:<source domain> /dstdc: /dstdom: /dstOU:<destination OU> This script clones all global groups from the source domain to the target domain. Its syntax is clonegg.vbs

Cscript clonegg.vbs /srcdc:<source PDC> /srcdom:<source domain> /dstdc: /dstdom: /dstOU:<destination OU> 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 information. 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 interforest 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 commandline 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

Chapter 4


191

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 twoway 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 workstations 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 NETDOM command, please consult the online Help files for the Windows 2000 Support Tools.

Necessary Procedures 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.

Chapter 4


193

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 migration 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:

Chapter 4


195

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 controller, so keep that in mind when selecting a computer. 2. Browse to the Support Tools folder on the CD-ROM, and doubleclick 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 environment 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 restructures. 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.

Chapter 4


197

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 controllers, 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 maintain user passwords, and retain the original object’s Globally Unique Identifier (GUID).

Key Terms and Concepts 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.

W

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

Critical Information Moving user accounts and global groups often correlates with moving 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 migrating trusts and security principals. It can also help with users.

Chapter 4


199

The Microsoft strategy for selecting the “proper” migration tool suggests that you would only copy security principals with ClonePrincipal 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 process 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 Location 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

Chapter 4


201

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 displayed 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

Chapter 4


203

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 production environment, ClonePrincipal is the tool you should use. Most migration plans describe moving user accounts, rather than cloning 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

Chapter 4


205

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 target 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. This script clones all global groups from the source domain to the target domain. Its syntax is Clonegg.vbs

Cscript clonegg.vbs /srcdc:<source PDC> /srcdom:<source domain> /dstdc: /dstdom: /dstOU:<destination OU>

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 location in the target Active Directory. The special local group you created 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 target domain (for instance, to give them access to all resources the original 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 concentrate 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 previous 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.

Chapter 4


207

Necessary Procedures 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 computers capable of running Windows 2000 Server. One may be installed with NT 4 Server as a PDC. The other should have Windows 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.

Key Term and Concept 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.

M

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

Chapter 4


209

Critical Information 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. Translation 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 principal 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 computer 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 target domain, then you should be using ADMT.

Chapter 4


211

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. This script clones shared local groups from the source domain controller to the destination domain controller. Its syntax is clonelg.vbs

Cscript clonelg.vbs /srcdc:<source PDC> /srcdom:<source domain> /dstdc: /dstdom: /dstOU:<destination OU>

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

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.

Key Term and Concept translation The process of mapping the current object’s SID to the SIDHistory of the new account.

Chapter 4


213

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

Critical Information 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 anything 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 verify 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 migration, 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 ClonePrincipal leaves the original objects in place, other back-out measures are not necessary.

Key Term and Concept 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.

Y

our test environment will play an important role in disasterrecovery 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

Chapter 4


215

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 experiences here, as they will be valuable if and when it becomes necessary to perform a real recovery of a domain controller.

Critical Information 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 documents 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:

Chapter 4


217

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 Directory up-to-date. This will give it a chance to replicate any changed data and make its version of the Directory current. The File Replication 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 problems is the Recovery Console. Unfortunately, Microsoft decided not to install this utility by default. The Recovery Console is a commandprompt version of Windows 2000 to which you can boot your computer 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 computer with the Windows 2000 startup disks or by booting with the

Chapter 4


219

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 concept 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 problem 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, Registry issues that prevent your Windows 2000 computer from booting 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 migration 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 simply 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.

Chapter 4


221

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

Necessary Procedures 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. Normally 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 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.

Chapter 4


223

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 possible, 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 solution in terms of the exam is to restore the services from tape backup.

Key Terms and Concepts authoritative restore Restore in which specific data or objects are marked as authoritative. These authoritative objects will take precedence 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

Chapter 4


225

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, decommission source domains and re-deploy domain controllers, verify new functionality, and look at removing the SIDHistory attribute from objects.

Critical Information 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 functionality, 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 Security 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 permissions assigned to them. The other part of the Security Descriptor 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 operating 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 Windows 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-51845031044856909-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 identifier 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.

Chapter 4


227

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 Subauthority Count

Reserved

Revision Number

Identifier Authority

Subauthority [1 to N-1]

Subauthority [N]

Domain Identifier

Relative 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 subauthorities 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 network 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.


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, belonging 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 coolcompany.local has the SID string S-1-5-21-5184503-1044856909627647339-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

Chapter 4


229

new target domain, you are changing the SIDs for all of those accounts. Without some mechanism to preserve the old SID information, your users won’t be able to access their resources. Windows 2000 provides that mechanism with the SIDHistory feature. 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 Windows 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 credentials have been authenticated by the domain (or the local computer 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 information 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 Windows 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 permissions 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.

Chapter 4


231

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 security 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 security 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 permissions 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

Chapter 4


233

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 existing 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 throughout 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 introduction 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 membership. 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 significant 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 network. 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 performed from a single server (or possibly multiple servers). The Windows 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.

Chapter 4


235

Server-only backup In this scenario, users are instructed to store data only in a shared location on a server. Then, every night (or whatever 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, depending 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 during 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 easiest 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 hardware 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 controllers 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 structure to use for the target domains, you may have installed new computers 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

Chapter 4


237

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 environment 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 trivial, 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 popularity 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 computers 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 troubleshooting 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 syntax is ping www.host.com or ping 10.1.0.44. Getting a response when pinging by IP address means that your network card is installed correctly, the driver is working, the TCP/IP protocol 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 previous 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.

Chapter 4


239

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 Locator (URL) to browse a favorite Web site. The user’s computer is configured 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 network. 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 decremented 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 setting 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 problems by performing a series of tests to determine the state of your network client and whether it is functional. These tests and the key network status information they expose give you a more direct means of identifying 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 troubleshooting TCP/IP issues, it also examines a host computer’s Internetwork Packet Exchange (IPX) and NetWare configurations.

Chapter 4


241

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 potential problem spots. It checks to see which network services or functions 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 Support 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 troubleshooting network performance. The only limitation of Network Monitor is that it cannot capture all traffic on the network, only traffic 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 permissions 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 validated 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.

Chapter 4


243

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 finetune someone’s access with what Microsoft calls special access. To modify the special access permissions for a file or folder, on the Security 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 permissions 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 Permissions. 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 permission 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 Accesstype permission.

Chapter 4


245

REASSIGNING FOLDER PERMISSIONS

When your migration is in progress, you will very likely still have permissions 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 coolcompany.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 permission. 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.

Chapter 4


247

Clicking the Advanced button brings up the Access Control Settings 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 permissions 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 follows: 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 permission 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.

Chapter 4


249

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 permission, 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 permissions for each of the permission levels.

Necessary Procedures 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 this procedure: 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 created 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.

Key Terms and Concepts 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 commandline utility used to check the ARP cache.

Chapter 4


251

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 computer’s hostname. IPConfig TCP/IP utility that displays current protocol configuration 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 information 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 destination host.


Chapter

5

Troubleshooting MICROSOFT EXAM OBJECTIVES COVERED IN THIS CHAPTER: a failed domain upgrade. Troubleshoot (pages 255 – 272)

Resolve hardware failures.

Resolve third-party tool issues.

Resolve issues associated with rights necessary for upgrade.

Resolve domain name issues.

account issues for all types Troubleshoot 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.

access issues for all types Troubleshoot 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.

network services problems for all Troubleshoot 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.

application failures for all types Troubleshoot of migrations. (pages 337 – 345)

Resolve incompatibility issues.

Resolve issues associated with hard-coded account information in third-party applications.

tool issues for domain Troubleshoot 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.

Troubleshoot a failed domain upgrade.

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


can expect questions regarding failed domain upgrades at various stages of the upgrade process, and to be asked how to proceed.

Critical Information 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 upgrading 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 Windows 2000 will be related to hardware in some way. Typically, these will be issues that can be avoided by ensuring that your hardware 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 automatically when you start the setup process within an earlier version 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 9x) 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 hardware, 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


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 compatible 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 manufacturer 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 9x 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 hardware 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 configuration 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.


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. Windows 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 distorted and appearing slightly brown in color. Unfortunately, the only solution for most of these problems is to use a different display 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. Unfortunately, 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 problem. 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


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 occurring. 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 computer to resolve the conflict. If you find yourself in this situation, remove devices that are not required for the operation of the computer.


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 segment 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 Windows 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 controller 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 working 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 supports 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 dualboot systems, but it can also happen if you boot the computer with an infected floppy disk. NTFS is resistant to viruses because Windows 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 reasonably 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 bootsector viruses work by moving the MBR elsewhere on the disk, then replacing 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 Windows 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 general 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.

Chapter 5

Troubleshooting

269

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 controllers. Because the Windows 2000 network depends on DNS exclusively for locating the servers, older clients may have difficulty if they are not configured for DNS resolution. Possible solutions 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 Directory network. Dynamic DNS entries are supported in the BIND DNS server version 8.1.2 and higher and in the DNS server supplied with Windows 2000. If your domain is still running in mixed mode, you must be able to reach the Primary Domain Controller (PDC). This is where NetBIOS name resolution will be important. In mixed mode, domain client computers will locate the domain controllers by using NetBIOS name resolution. This means using a WINS server or an LMHosts file. If the client computer and the domain controller 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.

Necessary Procedures There is one necessary procedure for this objective. It’s important to be familiar with the Readiness Analyzer and its output. When you are performing upgrades, or otherwise getting ready to install Windows 2000, the Readiness Analyzer can help resolve problems before they happen.

Chapter 5

Troubleshooting

271

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.


Key Terms and Concepts 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.

B

ecause Windows 2000 has a completely different way of dealing with user accounts and groups than NT 4, you may encounter 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 different SIDs and what happens when you have insufficient user rights to perform a specific task.

Critical Information 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 transition 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 associated with System Policy, it was an effective way to control the user’s

Chapter 5

Troubleshooting

273

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 automatically 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 configuration 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 inheritance 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: 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. Netdiag.exe

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 replication, and force synchronization between domain controllers. 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. GPOtool.exe

This command-line tool is available in the Windows 2000 Resource Kit. GPResult displays information about the results of all GPOs applied to the current user and the computer. GPResult.exe

Chapter 5

Troubleshooting

275

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

Chapter 5

Troubleshooting

277

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 controller 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 inheritance. 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. Remember to check both the user configuration and the computer configuration to see if they have been disabled. Computer or user object has been moved If the user or computer 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 settings 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 completed 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. Having multiple domain controllers per domain should correct this problem. 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 frequently have problems. If you read these situations carefully, you will see that most of them can be avoided with vigilant administration of

Chapter 5

Troubleshooting

279

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 Inheritance 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 performance.

Carefully lay out your needs for Group Policy during your planning 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, executable 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

Chapter 5

Troubleshooting

281

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 background, 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 timeout 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 Policy template to the GPO script settings. Troubleshooting Scripts

The troubleshooting for scripts falls into two categories. The first category 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 troubleshoot 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 troubleshooting 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 connect with the domain controller. Try resolving the name of the

Chapter 5

Troubleshooting

283

domain controller by pinging the DC from a command prompt. If this works, attempt to map a drive using the name of the domain controller and a known shared folder. These steps verify network connectivity and name resolution. One last thing to try from this computer is to verify that other users are receiving the script. This final step identifies whether the problem belongs to a single user or to all users trying 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 example, 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 getting 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 behavior 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. Windows 2000 evaluates security according to the SID of the user. It will also use the SIDHistory to check for additional permissions. As a general rule, you should never duplicate user accounts anywhere on the same network. By adhering to this practice, you will avoid any complications 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

Chapter 5

Troubleshooting

285

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. Customizing 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 fundamental 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 determine 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.

Necessary Procedures This objective has three necessary procedures. The first is editing the Registry to enable diagnostic logging for Group Policies. Once logging 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.

Chapter 5

Troubleshooting

287

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 diagnostic logging. Remember that enabling this logging can cause a large number of events to be recorded in Event Viewer. To enable diagnostic 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 policy 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 computer 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.

Chapter 5

Troubleshooting

289

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

Key Terms and Concepts GPOtool Diagnostic tool that displays the status of GPOs on domain controllers. GPResult Windows 2000 diagnostic tool that shows you the cumulative 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.

Chapter 5

Troubleshooting

291

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.

Critical Information 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 problems 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 fundamental 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 minimum, 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 communication 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 session 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 connections first. Most connectivity problems are the result of something 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.

Chapter 5

Troubleshooting

293

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 subnet. 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 hostname-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 resolution 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 computer 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 interactive 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 complete 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 controller, then you need to start troubleshooting basic connectivity problems a little more deeply. In a Windows 2000 network environment, DNS will be one of the most common sources of network connectivity 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

Chapter 5

Troubleshooting

295

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 downside, Netdiag will not be able to clearly identify problems on the network. 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 :\<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 Windows 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.

Chapter 5

Troubleshooting

297

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 topright 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 capture. The station statistics pane is located across the bottom of the main window. Capturing the data is the easy part. Deciphering the mass of information you have just captured is the difficult part. Figure 5.9 displays a capture analysis window. When you first display the capture window, 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.

Chapter 5

Troubleshooting

299

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 actually 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 complicated. Consider the example in Figure 5.10. F I G U R E 5 . 1 0 : An example of Deny permissions

NTFS Public

Public

= Modify Group1

= Read Group1

= Deny Read Group2

= Deny Read Group2

= None Group3

= Change Group3

= Read and Write BobR Totals =

= Full Control BobR

Modify (Deny Read)

Full Control (Deny Read)

Effective Permission = Modify (but Deny Read)

Chapter 5

Troubleshooting

301

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 Windows 2000, and that is the inheritance of permissions. In Windows 2000, the default behavior when applying permissions is that they will be inherited 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 blocking 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 inheritance 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

Chapter 5

Troubleshooting

303

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 troubleshooting 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 established 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 situation 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 inadvertently allowing access to unauthorized users. This is one of the reasons why a migration to a parallel Windows 2000 environment is a better 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.

Chapter 5

Troubleshooting

305

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 coolcompany.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 having 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.

CoolCompany.local

Shared folder Seattle.CoolCompany.local Marketing.CoolCompany.local st

t tcu

or Sh

User Sales.Seattle.CoolCompany.local

Tru


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

Necessary Procedures The two necessary procedures for this objective deal with Network Monitor. It’s not the easiest or most intuitive tool to use, but practice 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.

Chapter 5

Troubleshooting

307

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 properties 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 continue 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 network, 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 Resolution 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 computer 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 connectivity 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.

Chapter 5

Troubleshooting

309

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 permissions from the first two steps, and use the most restrictive. Know how Windows 2000 deals with trust relationships. In a forest, 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.

Key Terms and Concepts 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 information. 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.

N

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

Critical Information 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 NetBIOS 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 primary tool for troubleshooting DNS is NSLookup. NSLookup can be used in two modes: The interactive mode can be used to run

Chapter 5

Troubleshooting

311

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 resolution 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 periodically 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 NT network, 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 proprietary methods, though it’s actually fairly clever.

NOTE A helpful mnemonic device for memorizing the order of NetBIOS name resolution is “Can We Buy Large Hard Drives?” This represents 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 essentially the database should contain only name-resolution entries submitted 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

Chapter 5

Troubleshooting

313

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 misspellings 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 computer name are one and the same. This is the default on all Microsoft network 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 commonly used for NetBIOS name resolution. Table 5.1 lists the commands 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 correct entry at the bottom of the file. For this reason, you should be very careful about duplicate entries. Always place the #PRE statements at the end of the file. Because these statements are preloaded


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 command 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 associated with a single NetBIOS name. Used for multihomed computers, or computers with more than one network interface card.

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.

Chapter 5

Troubleshooting

315

NOTE A sample LMHosts file is located on all Windows 2000 computers 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 hostname to see if it matches the destination hostname. If it does, it communicates 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 nameresolution 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 NetBIOS 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 successful 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.

Chapter 5

Troubleshooting

317

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 hostname 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 following 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 Windows 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 failing. To test NetBIOS name resolution, use the Net View command at the command prompt. This command will attempt to resolve the

Chapter 5

Troubleshooting

319

name using NetBIOS and will list the shared resources on the remote computer. To test hostname resolution, ping the remote host by its hostname. 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 correcting 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 connections. Because it covers so many components, it can be very difficult 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 provides several tools for troubleshooting computer hardware, including Device Manager, Event Viewer, and Phone and Modem Options in Control 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 problem. 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 difficult. 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 functioning correctly and are correctly configured in the system BIOS. If you have a multiport adapter, such as the DigiBoard, you can try running 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 encountered. If the RAS client can dial in and appears to connect correctlybut 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 configuration. Most often the troubleshooting you’ll need to do for RAS configuration 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 completed 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.

Chapter 5

Troubleshooting

321

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 troubleshooting 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 logging 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 Replication 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 replication. 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 information, 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.

Chapter 5

Troubleshooting

323

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 replicating 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 member 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 structure 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 information 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

Chapter 5

Troubleshooting

325

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 directory 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 definitions 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 replica 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 database 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 replicated 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.

Chapter 5

Troubleshooting

327

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 problems 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 connected 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 server The 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 membership 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 Windows 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.

Chapter 5

Troubleshooting

329

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 doubleclick the Services entry in the Services console. The Properties dialog for any given service offers tabs that allow you to enter the information to control how the service will behave. The Properties sheets for a given service have some very nice capabilities. 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 participation 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 properties 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.

Chapter 5

Troubleshooting

331

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 restoration 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 performance 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 computer 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.

Chapter 5

Troubleshooting

333

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 misconfiguration 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 transfers. 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 incorrect IP address for the hostname, it is possible that you made a mistake 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 information 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.

Necessary Procedures 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.

Chapter 5

Troubleshooting

335

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 inexperienced 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 hostname, 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.

Chapter 5

Troubleshooting

337

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.

Key Terms and Concepts 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.

T

his 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 internally 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 applications 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.

Critical Information It would be wonderful to say that Windows 2000 supports applications 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 Readiness Analyzer from Microsoft. The Readiness Analyzer is useful mostly for commercial applications and for some hardware issues. As a general 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

Chapter 5

Troubleshooting

339

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 promises 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 Software 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 applications 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.

Chapter 5

Troubleshooting

341

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 encounter no difficulties in Windows 2000. But if you have an older application 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 programs. The behavior may even extend to causing problems with network 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 organization 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 resolution. 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 determine how much incompatibility your organization is willing to tolerate. Many environments are able to tolerate small incompatibilities, which require a workaround on the part of the user. Other environments 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

Chapter 5

Troubleshooting

343

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 platform 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 application 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 resolution on the client. If your application requires a specific network protocol, such as NetBEUI, you are faced with a decision. You can keep the application 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 Application Compatibility (apcompat.exe). The Application Compatibility 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 operating 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.

Chapter 5

Troubleshooting

345

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

Key Term and Concept heap Section of memory that applications can use for their own purposes, 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 maintain controls on, including connectivity, users, services, and applications. 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 IntraForest Domain Restructure and an Inter-Forest Domain Restructure.” This objective specifically deals with troubleshooting tips for those tools.

Critical Information 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 Migration 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 process. 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 computers usually do. Make certain that you have correctly established the trusts to communicate between your domains. Authentication issues seem common with ADMT. You will need to have administrator accounts and/or permissions in both domains.

Chapter 5

Troubleshooting

347

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 Administrator 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 generated 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. Accurate 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.

Key Term and Concept Variable that refers to the directory in which the operating system is installed. This is the winnt directory by default in Windows 2000. %systemroot%

Index Note to the Reader: Throughout this index boldfaced page numbers indicate primary discussions of a topic. Italicized page numbers indicate illustrations.

A Access Control Entries (ACEs), 230 Access Control Lists (ACLs) with ClonePrincipal, 185 for GPOs, 277 with moved accounts, 39–40 redefining, 225–234, 227, 231 and SIDs, 39 Access Control Settings dialog, 243– 244, 244, 247 access 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, 276 key 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 information for Reporting Wizard, 176 in third-party applications, 343– 345, 344 Account Policies option, 110

Account Transition Options page, 200 accounts, 137, 272 ADMT for, 182–184, 198–203, 199 ClonePrincipal for, 204–206, 210– 212 computer, 168, 181, 183, 208–210 duplicate, 283–284 exam essentials for, 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), 230 ACLs (Access Control Lists) with ClonePrincipal, 185 for GPOs, 277 with moved accounts, 39–40 redefining, 225–234, 227, 231 and SIDs, 39 Active Directory backing up, 131–132 DDNS for, 53–54 DHCP for, 156, 165 DNS for, 52–53, 70 domain selection for, 15–16, 17

350 Active Directory Connector (ADC) – ADMT (Active Directory Migration Tool)

in domain upgrades, 97 linking GPOs to, 106 Multiple Master Domain model migration to, 18–19, 18 in PDC upgrades, 4 replicating, 325–328 restoring, 217 security for, 35–36 Single Master Domain model migration to, 17, 18 Active Directory Connector (ADC) installing, 60 purpose of, 45 Active Directory Connector (ADC), 45, 60 Active Directory Connector Management 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, 70 Active Directory Migration Tool. See ADMT (Active Directory Migration 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, 106 for sites, 162

Active Directory Users and Computers console for auditing, 194 for Group Policies, 113, 163 for OUs, 162 ADC (Active Directory Connector), 45, 60 ADC folder, 45, 60 ADC Setup Wizard, 45–46 Add method for translation, 210 Add/Remove Programs applet, 49, 50 Add/Remove Snap-in dialog, 112–113 Add/Remove Windows Components, 72 Add Standalone Snap-in dialog, 112– 113 Address resolution Protocol (ARP) for NetBIOS, 311 purpose of, 308 verifying functionality of, 239 addresses. See IP addresses Administrative Templates, 103, 109– 110, 113–114 administrators for GPOs, 279 ADMT (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, 47 troubleshooting, 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

ADSI Edit (Active Directory Service Interfaces Editor), 242 Advanced option for Folder Redirection, 114 Advanced Options menu, 217–218 Agent in ADMT, 170 air conditioning, 135 Allow Access If Dial-In Permission Is Enabled option, 164 Allow Dynamic Updates option, 76 Allow Inheritable Permissions From Parent To Propagate To This Object option, 246, 301 Always Update DNS option, 165 analyzing Network Monitor data, 307–308 anti-virus software, 267 Append To Log option, 335 AppleTalk requirements, 99 Application Compatibility program, 344, 344 Application Compatibility Toolkit, 339 application servers in domain upgrades, 96–97 in inter-forest migration, 12 applications 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 exam essentials for, 345 key term and concept in, 345

351

third-party, 343–345, 344 with limited licensing, 37 support for, 292 Apply Group Policy permission, 107 ARP (Address resolution Protocol) for NetBIOS, 311 purpose of, 308 verifying functionality of, 239 assigning applications, 51 permissions, 242–250, 243–246, 248 attribute replication, 323 Audit These Events option, 194 auditing, 193–194 Authenticated Users permission, 107 authentication issues, 303 authoritative restores, 217–218, 221– 222 authorizing DHCP, 60–61 DNS servers, 330 Automatically Update DHCP Client Information In DNS option, 165

B Backup Domain Controllers (BDCs) backing up, 87 with ClonePrincipal, 185 in domain restructure, 145 in domain upgrades, 93–98 in native mode conversions, 121 offline, 215 in recovery, 78–79 for restoring accounts, 223 upgrading, 4–6

352 Backup program – clonepr.log file

Backup program, 130–133, 131, 133, 216–217, 234 Backup tab, 131, 131, 222 Backup Wizard, 130 backups, 130–133, 131, 133 domain, 137, 234–235 in recovery, 81, 216–217 for rollbacks, 135–136 System State, 217, 222–223 before upgrading, 87 Bandwidth Allocation Protocol (BAP), 57 basic disks, 129 Basic option for Folder Redirection, 114 BDCs. See Backup Domain Controllers (BDCs) #BEGIN_ALTERNATE command, 314 Berkeley Internet Name Domain (BIND) for DDNS support, 53–54 performance of, 101 for SRV records, 158 zone transfers to, 333 BIOS for SCSI controllers, 259 Block Inheritance permission, 279 Block Policy Inheritance option, 104, 108 blue-screen errors, 264–267 boot files, backing up, 132 boot.ini file, 261–262 boot-sector viruses, 266–267 Bootdisk folder, 219 Bootstrap Protocol (BootP), 55, 331 bridges, replication. See file replication bridges broadcasts in NetBIOS, 311, 313, 316

built-in groups and users, 227–228 Builtin domain, 228 business-related goals, 85

C cabling, 33–34 caches in DNS name resolution, 294 in NetBIOS, 311–312, 316 capturing Network Monitor data, 306–307 Caution application level, 339 central processing unit (CPU) for ADMT, 170 for domain controllers, 94 requirements for, 31–32 Certified application level, 338 change/configuration management, mixed mode vs. native mode, 122 chkdsk.exe program, 266 cleaning up after domain upgrades, 138–139 client computers connectivity of, 291–292 Network Monitor for, 296–299, 297–298, 306–308 network troubleshooting for, 292–296, 295 for domain restructure, 145 clonegg.vbs script, 187, 189, 205– 206, 211 cloneggu.vbs script, 187, 189, 206 clonelg.vbs script, 187, 189, 211 clonepr.dll file, 196 clonepr.doc file, 186, 188 clonepr.log file, 347

clonepr.vbs script – connectivity

clonepr.vbs script, 186–188, 204–205 ClonePrincipal tool, 184–187 for group accounts global, 205–206 local, 210–212 with inter-forest migration, 10 vs. MoveTree, 191 preparing, 187–188, 195–196 for security principals, 42 troubleshooting, 347 for user accounts, 204–205 working with, 188–190 COM+ Class Registration Database, 132 combining domains, 19 command-line DNS administration, 71 common network protocols, 292 communication lines in RAS, 320 compatibility application, 43 Exchange Server, 45–48, 46, 48 issues in, 340–342 line of business, 48–49 software deployment, 49–51, 50 verifying, 338–339 Web services, 44–45 hardware, 33, 258 mixed mode for, 6 Readiness Analyzer for, 256–257, 257, 338 Completing The Configure DNS Server Wizard page, 75 Completing the Reporting Wizard page, 178, 179 Complex Passwords option, 200 Component Selection page, 60 components in Group Policy Container, 104

353

computer accounts, 208–210 Computer Migration Wizard, 168 in inter-forest migration, 181 in intra-forest migration, 183 Computer Selection page, 177, 178 config.pol file, 102 configuration partitions, 325 Configure And Enable Routing And Remote Access option, 164 Configure DNS Server Wizard, 73 Configure The Server option, 73 configuring ADMT, 171–173 DHCP, 99–100, 155–156, 165 directory replication, 156–157 DNS, 158–160 DNS servers, 73–75 Group Policies, 108–112, 109 LMRepl, 100 network services, 154–160 protocols, 155 RAS, 154–155, 164–165, 320–321 TCP/IP, 155 WINS and NetBIOS, 100–101, 157–158 conflicts inheritance, 277 permissions, 302–303 resource, 262–264, 263 in scripts, 283 SID, 284 connections application, 342–343 tracing, 335–336 connectivity, 291–292 Network Monitor for, 296–299, 297–298, 306–308 network troubleshooting for, 292– 296, 295

354 consistency checks – Dfs (Distributed File System)

problems in, 240 consistency checks, 217 convergence, 326 converting to native mode, 5–6, 119–121 exam essentials for, 123 key terms and concepts in, 124 mixed vs. native modes in, 121– 123 System Policies to Group Policies, 112 copying folders, 157 passwords, 10, 13 SAM database, 185 CPU (central processing unit) for ADMT, 170 for domain controllers, 94 requirements for, 31–32 cross-domain administration, 122 current environment evaluation, 26– 27 application compatibility, 43 Exchange Server, 45–48, 46, 48 line of business applications, 48– 49 software deployment, 49–51, 50 Web services, 44–45 domain restructure in, 28–29 exam essentials for, 29, 61–62 key term and concept in, 29 key terms and concepts in, 62–63 network services. See network services procedures for, 59–61 current hardware evaluation network cabling, 33–34 network routers and subnets, 34

requirements, 29–33 security implications. See security

D DACLs (Discretionary Access Control Lists) for GPOs, 277 redefining, 225–234, 227, 231 damaged directories, restoring, 217 Days Until Source Account Expires setting, 200 dcpromo.exe program for decommissioned domains, 236 in domain upgrades, 97 for Sysvol, 116 DDNS (Dynamic DNS), 53–54, 330 decommissioning domains, 145–146, 235–237 default permissions in RRAS, 58 default servers in DNS, 333 Define This Policy Setting option, 163 delegation of authority, 277 demoting in inter-forest migration, 12 Deny ACEs, 230 Deny permissions, 300, 302 Dependencies tab, 330 deployment software, 49–51, 50 test, 124–126, 213–214 Deployment Planning Guide, 186 destinations, planning, 20–21 detail pane in Network Monitor, 299 Device Manager, 262–263, 263 Dfs (Distributed File System) FRS for, 115 for remote backups, 234

DHCP – DNS

in replication, 322–325 DHCP (Dynamic Host Configuration Protocol), 55–56 authorizing, 60–61 configuring, 155–156, 165 in domain upgrades, 97, 99–100 issues in, 330–332, 331 recovering, 79–80 verifying operation of, 138 diagnostic logging, 273, 286–287 Diagnostics tab, 322, 335 directories. See Active Directory directory replication, 156–157 Directory Services Restore Mode option, 217–218, 222 DirectX 7.0A, 27 Disable command, 219 Disable Source Accounts option, 200 Disable Target Accounts option, 200 disabled GPOs, 278–279 disaster recovery plans, 77–78, 126– 127 account restoration in, 221 for DHCP, 79–80 for DNS, 79 exam essentials for, 81–82, 136, 224 hardware in, 127–130 implementation rollback in, 135– 136 infrastructure in, 134–135 key terms and concepts in, 82, 136– 137, 224 network services restoration in, 219–221 pre-migration environment restoration in, 135, 215–219 procedures for, 221–224

355

for protecting data, 81 for SAM database, 78–79 software in, 130–133, 131, 133– 134 for WINS, 80–81 Discretionary Access Control Lists (DACLs) for GPOs, 277 redefining, 225–234, 227, 231 disks. See hard disks display for domain controllers, 94 troubleshooting, 260–261 Display Captured Data option, 307 distinguished names (DNs), 200, 202 Distributed File System (Dfs) FRS for, 115 for remote backups, 234 in replication, 322–325 DLC requirements, 99 DMA resources, 96 DNs (distinguished names), 200, 202 DNS (Domain Name System), 52–54, 69–72 configuring, 158–160 configuring servers, 73–75 and connectivity, 294 DHCP in, 155 for domain upgrades, 101 domains in, 318 dynamic updates for, 76 exam essentials for, 76 installing, 72–74, 72–73 issues in, 333–334 key terms and concepts in, 76–77 with NetBIOS, 312, 315 procedures for, 74–76 recovering, 79

356 DNS console – Domain Security Policy console

registration renewals in, 239 restoring servers, 220 verifying operation of, 138 DNS console, 73, 73 .dns files, 75 DNS installation wizard, 74 DNS tab, 165, 330–331, 331 Do Not Rename Accounts option, 183, 201 #DOM command, 314 Domain Admins permission, 107 domain controllers backing up, 87, 137 with ClonePrincipal, 185 for domain restructure, 145 in domain upgrades, 93–98 with MoveTree, 190 in native mode conversions, 121 offline, 215 promoting member servers to, 270 re-deploying, 235–237 in recovery, 78–79 in replication, 328 restoring, 216–217 for restoring accounts, 223 upgrading, 4–6 Domain Identifiers in SIDs, 226 Domain Name System. See DNS (Domain Name System) Domain NC (Naming Context) node, 249 domain partitions, 325 domain restructure, 6–7, 28 for DHCP, 79–80 disaster recovery plans for, 214– 215 account restoration in, 221

key terms and concepts in, 224 network services restoration in, 219–221 pre-migration environment restoration in, 215–219 procedures for, 221–224 for DNS, 79 exam essentials for, 81–82, 136, 224 global group and user account migration for, 207–208 with ADMT, 198–203, 199 with ClonePrincipal, 204–206 local group and computer account migration for, 208–212 post-migration, 29 post-upgrade, 28 strategies for, 143–144 exam essentials for, 146 key term and concept in, 147 migrating to new domains, 144– 146 target domains in. See target domains test deployments for, 213–214 tools for, 167–168 ADMT. See ADMT (Active Directory Migration Tool) ClonePrincipal, 184–190 exam essentials for, 196–197 key terms and concepts in, 197– 198 MoveTree, 190–191 NETDOM, 191–192 procedures for, 192–196 vs. upgrades, 28 Domain Security Policy console, 285

Domain Selection page – Dynamic DNS Update functions

Domain Selection page, 174, 174 domain upgrades, 3–4, 84 application servers in, 96–97 beginning, 4 completing, 5–6 disaster recovery plans in, 126–127 exam essentials for, 136 hardware in, 127–130 implementation rollback in, 135–136 infrastructure in, 134–135 key terms and concepts in, 136– 137 pre-migration environment restoration in, 135 software in, 130–133, 131, 133– 134 vs. domain restructure, 28 failed. See failed domain upgrades fault tolerance in, 95 file replication bridges for, 115– 119 Group Policies for. See Group Policies and Group Policy Objects (GPOs) native mode conversions in, 119– 124 operating systems in, 90–92 PDCs and BDCs in, 4–5, 93–98 post-migration tasks in, 137–139 service configuration for, 99–102 strategies for, 84–85 exam essentials for, 89 key term and concept in, 90 migration order in, 86–89 test deployments of, 124–126

357

domain upgrades with restructure, 6– 13, 7 inter-forest migration, 9–12 intra-forest migration, 12–13 multiple NT domains, 8–9 NT to Windows 2000, 7–8 domains backing up, 137, 234–235 combining, 19 decommissioning, 145–146, 235– 237 in DNS, 318 names for, 15–16, 17, 269–270 restructures. See domain restructure in security, 35–36 selecting and ordering, 15–20, 17– 19 upgrades. See domain upgrades; domain upgrades with restructure downlevel clients in upgrades, 101 drivers blue screen problems from, 265– 266 for display, 260 support for, 258–259 dual boots, 91 duplicate accounts, 283–284 duplicate names for group accounts, 203 for user accounts, 201 in WINS, 333 dust, 135 dynamic disks, 129–130 Dynamic DNS (DDNS), 53–54, 330 Dynamic DNS Update functions, 155

358 Dynamic Host Configuration Protocol – File Replication Service (FRS)

Dynamic Host Configuration Protocol. See DHCP (Dynamic Host Configuration Protocol) dynamic updates, 70, 76, 269–270

E EAP (Extensible Authentication Protocol), 56–57 editing scripts, 206 emergency boot disks, 266–267 Emergency Repair Disk, 130 employee files, security for, 37 Enable command, 219 Enable Updates For DNS Clients That Do Not Support Dynamic Update option, 165 enabling connection tracing, 335–336 modem logging, 322 Encrypted File System, 111 #END_ALTERNATE command, 314 Enterprise Admins permission, 107 environment preparation DNS service, 69–77, 72–73 pristine environments, 66–68 recovery plans, 77–82 restoring, 135, 215–219 Ethernet networks, 33–34 Event ID 7062 error, 333 Event Log option, 111 event logs for Group Policies, 111 for RAS, 321 Event Viewer for account troubleshooting, 269 for Dfs replication, 325

for RAS, 320 Exchange Directory Migration Wizard, 169 Exchange Server, 45–48, 46, 48 Explain tab, 110 Explicit ACEs, 230 Extensible Authentication Protocol (EAP), 56–57

F failed domain upgrades, 255–256 domain name issues, 269–270 exam essentials for, 271 hardware issues. See hardware key terms and concepts in, 272 procedures for, 270–271 Readiness Analyzer for, 256–257, 257, 271 third-party tool problems in, 267– 268 user rights issues, 268–269 fault tolerance, 95, 127–130 fdisk.exe program, 266–267 file permissions, reassigning, 242–244, 243–244 file replication bridges, 115–116 exam essentials for, 118 key terms and concepts in, 118–119 LMRepl to FRS upgrades for, 117– 118 Sysvol for, 116–117 File Replication Service (FRS), 156 benefits of, 322 for Dfs replication, 324–325 file replication bridges for, 115 vs. LMRepl, 58–59

file systems in RAID – Group Policies and Group Policy Objects (GPOs)

LMRepl upgrades to, 117–118 for multimaster replication, 323 in native mode conversions, 120 file systems in RAID, 128 File Transfer Protocol (FTP), 44–45 filters with Group Policies, 279 Flexible Single Master Operations (FSMO), 226, 228 flow management for Group Policies, 107–108 Folder Redirection, 103, 111–112, 114 Folder Selection page, 174, 175 folders copying, 157 permissions for, 245–247, 245–246 fonts for application compatibility, 341 forward lookup zones, 74, 76 FQDNs (fully qualified domain names), 72, 317 frames in ARP, 308 FRS. See File Replication Service (FRS) FSMO (Flexible Single Master Operations), 226, 228 FTP (File Transfer Protocol), 44–45 Full Control permission, 301 fully qualified domain names (FQDNs), 72, 317 future growth, security planning for, 38

G General tab in DNS, 76 in Services Properties, 329 geographical settings, domains for, 36

359

global catalog servers, 328 global groups, 198 ClonePrincipal for, 205–206 in domain restructure, 146 with moved accounts, 40 Globally Unique Identifiers (GUIDs) GPTs in, 104 in inter-forest migration, 10 in intra-forest migration, 13 with MoveTree, 191 GPOs. See Group Policies and Group Policy Objects (GPOs) GPOtool tool, 274–275, 275 GPResult tool, 274–276, 276, 281– 282, 282, 288 GPTs (Group Policy Templates), 104 Grant Remote Access Permission option, 164 granularity, 20–21, 244 graph pane in Network Monitor, 297 Group Account Migration Wizard, 202–203 Group Mapping and Migration Wizard, 169 Group Migration Wizard, 168 for inter-forest migration, 181–182 for intra-forest migration, 183–184 Group Options page, 203 Group Policies and Group Policy Objects (GPOs), 102–104 Administrative Templates for, 109– 110, 113–114 for applications, 37 configuring, 108–112, 109 creating, 106, 113 for deployment, 50 diagnostic logging for, 273, 286– 287

360 Group Policy Container – Hostname service, verifying functionality of

exam essentials for, 114–115 flow management for, 107–108 Folder Redirection for, 103, 111– 112, 114 implementing, 153–154, 163–164 inheritance in, 104–105, 108, 277 key term and concept in, 115 for logon scripts, 280–283, 282 permissions for, 107, 277–279 procedures for, 112–114 processing, 105–106 from system policies, 112 for system policy translation issues, 274–279, 275–276, 287–288 Group Policy Container, 103–104 Group Policy snap-in, 106, 112–113 Group Policy tab, 106, 108–109, 113, 163–164, 194 Group Policy Templates (GPTs), 104 groups accounts for. See accounts ClonePrincipal for, 205–206 in domain restructure, 146 in mixed mode vs. native mode, 122 with moved accounts, 40 moving, 232–233 parallel, 233 rights for, 285 growth, security planning for, 38 GUIDs (Globally Unique Identifiers) GPTs in, 104 in inter-forest migration, 10 in intra-forest migration, 13 with MoveTree, 191

H hard-coded account information, 343–345, 344 hard disks for ADMT, 170 blue screen problems from, 265 for domain controllers, 94 duplexing, 128–129 requirements for, 31–32 striping, 128–130 troubleshooting, 259–260 hardware for application compatibility, 341 current. See current hardware evaluation in disaster recovery plans, 127–130 issues in, 257–259 blue-screen errors, 264–267 disk problems, 259–260 display problems, 260–261 memory problems, 261–262 resource conflicts, 262–264, 263 for RAID, 129 Hardware tab, 262 HCL (Hardware Compatibility List), 33, 258 Heap Manager, 344 heat concerns, 135 hexadecimal pane in Network Monitor, 299 high-security resources, 36–37 hostname resolution, 52, 315–319, 317. See also DNS (Domain Name System) Hostname service, verifying functionality of, 238

Hosts file – ISA cards

Hosts file, 293, 312–313, 315–319, 317

I IAS (Internet Authentication Service), 57, 154 IDE drives, 259–260, 265 identifier authorities, 226 IIS (Internet Information Services), 44–45 implementation rollback, 135–136 #INCLUDE command, 314 incremental object migrations, 22 Incremental Zone Transfers (IXFRs), 71, 101 Industry Standard Architecture (ISA) devices, 262–263 INFORM packets, 156 infrastructure in disaster recovery plans, 134–135 inheritance in Group Policies, 104–105, 108, 277 of permissions, 301–302 Inherited ACEs, 230 Install Location page, 60 installing ADC, 60 ADMT, 170–171, 192–193 DNS, 72–74, 72–73 Recovery Console, 218 Support Tools, 194–195 Int13 calls, 259 inter-domain link issues, 278 inter-forest migrations ADMT for, 180–183

361

in domain upgrades with restructure, 9–12 test deployments for, 213–214 intermittent line failures in RAS, 320 international networks, 36 Internet access, 37–38 Internet Authentication Service (IAS), 57, 154 Internet Information Services (IIS), 44–45 Internet Protocol Security (IPSec), 27, 57, 111 Internet Services Manager, 44 Internet Software Consortium (ISC), 53, 159 intra-forest migration ADMT for, 183–184 in domain upgrades with restructure, 12–13 test deployments for, 213–214 inverse lookup (PTR) records, 156 IP addresses ARP for, 239 format for, 153 in NetBIOS, 311 pinging, 238, 293 proxy servers for, 37 resolving hostnames to. See DNS (Domain Name System) in troubleshooting, 292 IP Security (IPSec) option, 111 IP subnets, 152 IPConfig service, 238–239 IPSec (Internet Protocol Security), 27, 57, 111 IPX/SPX requirements, 99 IRQ resources, 96 ISA cards, 96

362 ISA (Industry Standard Architecture) devices – lookup zones

ISA (Industry Standard Architecture) devices, 262–263 ISC (Internet Software Consortium), 53, 159 IXFRs (Incremental Zone Transfers), 71, 101

J jetpack.exe program, 332

K Kerberos security, 27 Knowledge Consistency Checker (KCC), 327

L L-bridge.cmd batch file, 157 L2TP (Layer 2 Tunneling Protocol), 57 LAN Manager replication (LMRepl) service, 58–59, 100, 117–118 last writer wins algorithm, 324 Layer 2 Tunneling Protocol (L2TP), 57 Leave Both Accounts Open option, 200 licensing for applications, 37 line of business (LOB) applications in compatibility, 43, 48–49 in incremental object migrations, 22 in pilot programs, 25 linking GPOs, 106, 279

Links tab, 164 List Folder Contents permission, 246 LMHosts file for dynamic updates, 269–270 in NetBIOS, 311–316 for trusts, 149 LMRepl (LAN Manager replication) service, 58–59, 100, 117–118 LOB (line of business) applications in compatibility, 43, 48–49 in incremental object migrations, 22 in pilot programs, 25 local groups, 182, 204, 208–212 Local Groups option, 182 local hostnames in NetBIOS, 315 Local Policies option, 111 Local Policy Setting option, 289 Local Security Authority (LSA), 187 Local Security Policy console, 285– 286, 286 Local Security Policy Settings dialog, 288 Log On tab, 329–330 logoff scripts, 110, 280 logon scripts, 280 failures in, 280–283, 282 for Group Policies, 110 logons and logon service access tokens for, 41 in native mode conversions, 120 logs ClonePrincipal, 347 Group Policy, 111, 273, 286–287 modem, 322, 335 RAS, 321 for trial migrations, 213–214 lookup zones, 74–76

loose consistency – Multiple Master Domain model

loose consistency, 326 low-level format problems, 259 LSA (Local Security Authority), 187

M MAKEBOOT.EXE program, 219 MAKEBT32.EXE program, 219 Manage Documents permission, 248 Manage Printers permission, 247–248 manageability as upgrade goal, 85 Management Console, 71 mapping SIDs to SIDHistory, 209 Master Boot Record (MBR), blue screen problems from, 266 /maxmem switch, 261–262 MD5-CHAP (Message Digest 5 Challenge Handshake Authentication Protocol), 56–57 mem.exe program, 266 member servers in domain restructure, 145 in domain upgrades, 91, 93 in inter-forest migration, 12 promoting, 270 memory for ADMT, 170 for domain controllers, 94 requirements for, 31–32 troubleshooting, 261–262 Message Digest 5 Challenge Handshake Authentication Protocol (MD5-CHAP), 56–57 #MH command, 314 Microsoft Developers Network (MSDN), 340 Microsoft DNS, 159–160

363

Microsoft Script Debugger, 281 migpol.exe tool, 112 Migrate Associated User Groups option, 201 Migrate Group SIDs To Target Domain option, 183 Migrate User SIDs To Target Domain option, 201 migration order in domain upgrades, 86–89 Migration Progress dialog, 201 mirrored environments, 24 mirroring in RAID, 128–130 mixed mode and environments LMRepl to FRS bridges for, 117– 118 vs. native mode, 121–123 support for, 3 switching from, 5–6 modems, 322, 334–335 Modems tab, 334 monitoring RAS, 321–322 monitors, multiple, 260 MoveTree tool, 190–191 moving objects in domain restructure, 145 and Group Policies, 278 groups, 232–233 security principals, 38–41 _msdcs sub-domain, 158 MSDN (Microsoft Developers Network), 340 .MSI files, 50 Multilink, PPP, 57 multimaster loose consistency, 326 multimaster replication, 122, 322–323 Multiple Master Domain model, 18– 19, 18, 148–149

364 multiple monitors – network services

multiple monitors, 260 multiple NT domains in restructuring, 8–9 multithreaded replication engines, 116

N name caches, 294, 311–312, 316 name resolution, 69, 310–311 DNS. See DNS (Domain Name System) hostname, 315–319, 317 NetBIOS, 311–315 names domain, 15–16, 17, 269–270 group accounts, 203 user accounts, 201 Naming Conflicts page, 201, 203 native mode for ADMT, 171 conversions to, 5–6, 119–121 exam essentials for, 123 key terms and concepts in, 124 mixed vs. native modes in, 121– 123 NBNSs (NetBIOS name servers), 311, 316 NBStat command, 312 nesting groups, 122 OUs, 151 Net View command, 318 NetBIOS configuring, 157–158 for domain upgrades, 100–101 name-resolution in, 311–313 for dynamic updates, 269–270

LMHOSTS for, 313–315 WINS for, 54–55 support for, 53 NetBIOS name servers (NBNSs), 311, 316 Netdiag tool, 240–241, 274, 294–296, 295 NETDOM tool in deployment testing, 125 in domain restructure, 191–192 for inter-forest migration, 10 troubleshooting, 348 for trusts, 41–42, 149 netlogon share, 102 network cabling, 33–34 network hardware for domain controllers, 94 Network Monitor analyzing data in, 307–308 capturing data in, 306–307 for client computer connectivity, 296–299, 297–298 verifying functionality of, 241 Network News Transfer Protocol (NNTP), 45 network paths in WINS, 332 network protocols, 52 network routers and subnets, 34 network services, 51 configuring, 154–160 DHCP, 55–56, 330–332, 331 DNS, 52–54, 333–334 issues in, 309–310, 328–334, 329 exam essentials for, 336–337 file and directory replication, 322–328 key terms and concepts in, 337 name-resolution, 310–319, 317

New Site option – PDC Operations Masters

permissions, 319–322 procedures in, 334–336 LAN Manager replication, 58–59 network protocols, 52 RAS, 319–322 restoring, 219–221 RRAS, 56–58, 58 verifying, 138, 237–241 WINS, 54–55, 332–333 New Site option, 163 NNTP (Network News Transfer Protocol), 45 No Access permission, 249 No Administrative Policy Specified setting, 114 No Override option, 104, 108 No Override permission, 279 NSLookup utility, 294, 310 NT to Windows 2000 restructuring, 7–8 ntconfig.pol file, 102 NTFS systems, 266, 299–302, 300

O offline BDCs, 215 opening GPOs, 276 operating systems in domain upgrades, 90–92 Operations Masters roles, 148 optional components for domain controllers, 94 ordering domains, 15–20, 17–19 Organizational Unit Selection page, 200, 202 organizational units (OUs) for granularity, 20–21

365

for group accounts, 202 in target domains, 150–151, 150, 162 for user accounts, 200

P packages, 50 Packet Internet Groper (Ping) service, 238, 293 packets in ARP, 308 parallel groups, 233 parity in RAID, 129 partitions for RAID, 129 in replicas, 325 Password Options page, 200 passwords with ADMT, 190 in authentication, 303 filters for, 122 for group accounts, 203 in inter-forest migration, 10 in intra-forest migration, 13 for user accounts, 200 PathPing service, 241 paths in Folder Direction, 114 in WINS, 332 PCI (Peripheral Component Interface) devices, 262–263 PDC Emulator Master, 5 PDC Emulators with ClonePrincipal, 187 Group Policies for, 109 PDC Operations Masters, 109

366 PDCs – processors

PDCs. See primary domain controllers (PDCs) Peripheral Component Interface (PCI) devices, 262–263 permissions conflicts in, 302–303 for Group Policies, 107, 277–279 inheritance of, 301–302 for new SIDs, 232 in NTFS, 299–302, 300 reassigning, 242–250, 243–246, 248 in RRAS, 58 Permissions dialog, 246 Phone And Modem Options dialog, 334–335 Phone Book entry, 320–321 physical connectivity, 292 pilot groups, 213 pilot migration strategies, 22–25 ping service, 238, 293 Planned application level, 339 planning destinations, 20–21 domain selection in, 15–20, 17–19 exam essentials for, 25 for growth, 38 for incremental object migrations, 22 key terms and concepts in, 26 pilot migration strategies, 22–25 for recovery. See disaster recovery plans Point to Point Tunneling Protocol (PPTP), 57 policies, group. See Group Policies and Group Policy Objects (GPOs)

post-migration tasks, 224–225 backing up source domains, 234– 235 decommissioning source domains, 235–237 domain restructure, 29 in domain upgrades, 137–139 exam essentials for, 250 key terms and concepts in, 250–251 redefining DACLs, 225–234, 227, 231 removing SIDHistory from objects, 242–250, 243–246, 248 verifying network services functionality, 237–241 verifying success, 237 post-upgrade domain restructure, 28 power protection, 134 PPTP (Point to Point Tunneling Protocol), 57 #PRE command, 311–314 pre-migration environment, restoring, 135, 215–219 primary domain controllers (PDCs) backing up, 87 in domain restructure, 145 in domain upgrades, 93–98 in recovery, 78 upgrading, 4–5 Print permission, 248 printer permissions, 247–249, 248 Printer Properties dialog, 247, 248 pristine environments, 66–68 processing order of Group Policies, 108 processors for ADMT, 170 for domain controllers, 94

promoting member servers – remote procedure calls (RPCs)

requirements for, 30–31 promoting member servers, 270 protocols configuring, 155 network, 52 proxy servers, 37 PTR (inverse lookup) records, 156 Public Key Policies option, 111 publishing applications, 50–51 pull replication, 326

Q queries, mixed mode vs. native mode, 122 Query Modem option, 335

R RADIUS (Remote Authentication Dial-In User Service), 57 RAID (redundant arrays of independent disks), 127–130 RAS (Remote Access Service), 319 configuring, 154–155, 164–165, 320–321 in domain upgrades, 97 monitoring, 321–322 in native mode conversions, 120– 121 physical components, 319–320 re-deploying domain controllers, 235– 237 Read permission, 107, 301 Readiness Analyzer for compatibility, 256–257, 257, 338

367

for third-party software, 267 working with, 271 Ready application level, 339 reassigning permissions, 242–250, 243–246, 248 Record A Log option, 335 record aging, support for, 70 recovery. See disaster recovery plans Recovery Console, 216, 218–219 Recovery tab, 330 Recycle Bin in ADMT installation, 171 redefining DACLs, 225–234, 227, 231 redirection for Group Policies, 111– 112, 114 redundant arrays of independent disks (RAID), 127–130 refreshing Group Policies, 106 Registry for ADMT, 172 for application compatibility, 341 backing up, 132 for ClonePrincipal, 195 for Group Policies, 111, 286 for third-party applications, 343 Registry option, 111 Relative Identifier (RID) Masters, 173, 228 Relative Identifiers (RIDs), 206, 226– 228 Remote Access Service. See RAS (Remote Access Service) Remote Authentication Dial-In User Service (RADIUS), 57 remote backups, 234 Remote Installation Services (RIS), 269 remote procedure calls (RPCs), 152

368 Remove method for translation – SACLs (System Access Control Lists)

Remove method for translation, 210 removing SIDHistory from objects, 242–250, 243–246, 248 Rename With Prefix option, 201 Rename With Suffix option, 201 renewing DNS registrations, 239 Repair menu, 218–219 Replace method for translation, 210 replication, 322–323 Active Directory, 325–328 Dfs, 322–325 FRS. See File Replication Service (FRS) with Group Policies, 278 in restoring failed domain controllers, 217 in WINS, 333 replication bridges. See file replication bridges replmon.exe tool, 274 Report Selection page, 175, 176 Report System Compatibility page, 257, 257 Reporting Wizard, 169, 174–180, 174–179 Reports tree, 173 resolving hostnames to IP addresses. See DNS (Domain Name System) resource domain migration, 180–183 resources conflicts in, 262–264, 263 in trial migrations, 213 Resources tab, 263 restore subtree command, 222 Restore tab, 133, 133 Restore Wizard, 130 restoring, 133, 133 accounts, 221, 223–224

damaged directories, 217 failed domain controllers, 216–217 network services, 219–221 pre-migration environment, 135, 215–219 Restricted Group option, 111 restructure, domain. See domain restructure; domain upgrades with restructure Retry Tasks Wizard, 169 Reverse Lookup Zone page, 75 reverse lookup zones, 75 revision numbers in SIDs, 226, 228 RID (Relative Identifier) Masters, 173, 228 RIDs (Relative Identifiers), 206, 226– 228, 227 rights. See permissions RIS (Remote Installation Services), 269 ROBOCOPY utility, 157 rollback in disaster recovery plans, 135–136 rollout preparation, 24–25 root domains for Multiple Master Domain model, 18, 19 names for, 15–16, 17 roots, OUs off, 151 routers, 34 Routing and Remote Access Service (RRAS), 56–58, 58, 154, 164 RPCs (remote procedure calls), 152

S SACLs (System Access Control Lists), 225

Safe mode – server-only backups

Safe mode, 261 safe mode of operations, 80 SAM (Security Accounts Manager) database copying, 185 in PDC upgrades, 4 recovering, 78–79 Same As User Name option, 200 saving Netdiag output, 296 scalability as upgrade goal, 85 Scavenge Stale Resource Records option, 76 scavenging, DNS support for, 70 Schedule Jobs tab, 133, 134 schedules for backup operations, 130, 133, 134 for FRS, 323 for replication, 328 Schema Master, 46 schema partitions, 325 SCL (Software Compatibility List), 339 scripts for ClonePrincipal, 185–187 conflicting settings from, 283 failures in, 280–283, 282 for Group Policies, 103, 110 SCSI-based systems, 259, 265 second monitors, problems with, 260 secure channels, NETDOM for, 192 security, 34–35 and application compatibility, 341 for applications with limited licensing, 37 for backups, 235 cloning security principals, 42 domain structures in, 35–36

369

for future growth, 38 Group Policies for, 103, 110–111 high-security resources, 36–37 for Internet access, 37–38 in mixed mode, 121 moving security principals, 38–41 trust relationships, 41–42 as upgrade goal, 86 Security Access Tokens, 229–230 Security Accounts Manager (SAM) database copying, 185 in PDC upgrades, 4 recovering, 78–79 Security Configuration and Analysis tool, 86 Security Descriptors, 225 Security dialog, 303 security identifiers. See SIDs (security identifiers) Security Options option, 163 Security Policy Setting dialog, 163 Security tab for DACLs, 230, 231 in NTFS, 301 for permissions, 242, 243 folder, 245–246, 245–246 printer, 247–248, 248 security tokens, 41 Security Translation Wizard, 169 for inter-forest migration, 181–182 for intra-forest migration, 184 Select Group Policy Object Wizard, 112–113 Select Users dialog, 200 selecting domains, 15–20, 17–19 server and computer backups, 235 server-only backups, 235

370 servers in domain restructure – software in disaster recovery plans

servers in domain restructure, 145 Service Account Migration Wizard, 47–48, 48, 169 in inter-forest resource domain migration, 181 in intra-forest resource domain migration, 183 service accounts, 47–48, 48 service configuration for domain upgrades, 99–102 service packs, 92 Service (SRV) records for Active Directory, 53–54 BIND for, 101 DNS for, 70 for domain controllers, 239 in replication, 327 support for, 158–159 Services console, 328–329, 329 session statistics pane in Network Monitor, 297 Settings tab, 114 setup, blue screens during, 264–265 setup program, 35, 43 Setup Wizard, 60, 170 shared local groups, 145 shared resource issues, 302–303 shortcut trusts, 305–306, 305 shutdown scripts, 110, 280 sidhist.vbs script, 186, 188 SIDHistory feature, 229, 231, 284 for ADMT, 171 with ClonePrincipal, 185, 187 for group accounts, 203 in inter-forest migration, 10 mapping SIDs to, 209 with moved accounts, 40–41 purpose of, 233–234

removing from objects, 242–250, 243–246, 248 in restoring accounts, 221 for user accounts, 202 SIDs (security identifiers), 210, 226– 229, 227 with duplicate accounts, 283–284 in inter-forest migration, 10 mapping to SIDHistory, 209 for moved accounts, 39 new, 232 in RRAS, 58 Simple Mail Transfer Protocol (SMTP) in IIS installation, 44–45 in site design, 152 Single Master Domain model migrating to Active Directory, 17, 18 trusts in, 149 site-aware clients, 322 site level, inheritance in, 105 sites, creating, 151–153, 162–163 Sites container, 163 _sites sub-domain, 159 Small Computer System Interface (SCSI)-based systems, 259, 265 SMS (Systems Management Server), 241 SMTP (Simple Mail Transfer Protocol) in IIS installation, 44–45 in site design, 152 Software Compatibility List (SCL), 339 software deployment, 49–51, 50 software in disaster recovery plans, 130–133, 131, 133–134

Software Installation – target domains

Software Installation, 103 source domains backing up, 234–235 decommissioning, 235–237 speed of replication, 327 SRV records. See Service (SRV) records stand-alone servers in domain upgrades, 91 Standard Primary zones, 74–75 Standard Secondary zone, 74 startup floppies, 219 startup scripts, 110, 280 state-based replication, 326 station statistics pane in Network Monitor, 298 status information in Group Policy Container, 104 stop screens, 264 store and forward replication, 326 strategies, migration domain upgrades, 3–6 domain upgrades with restructure, 6–13, 7 exam essentials for, 13–14 key words and concepts in, 14 striping, 128–130 striping with parity, 128–129 sub-domains, 158–159 subauthorities in SIDs, 226 subnets, 34 summary pane in Network Monitor, 298–299, 298 Support Tools, installing, 194–195 Support Tools folder, 186 System Access Control Lists (SACLs), 225 system files, protecting, 340

371

System Log, 325 system objects with MoveTree, 190 System permission for Group Policies, 107 System Policies, 102 Group Policies from, 112 translation issues, 272–279, 275– 276, 287–288 System Services option, 111 System State information backing up, 131–132, 217, 222– 223 restoring, 217–218 %SystemRoot% directory, 347 Systems Management Server (SMS), 241 Sysvol backing up, 132 for file replication bridges, 116– 117 GPTs in, 104 replication information in, 156

T target domains, 147–148 creating, 160–161 exam essentials for, 165–166 Group Policy implementation for, 153–154, 163–164 key terms and concepts in, 166–167 network services configuration for, 154–160 OUs for, 150–151, 150, 162 procedures for, 160–165 site design implementation for, 151–153, 162–163

372 target paths for Folder Redirection – _udp sub-domain

trusts for, 148–149, 149, 161–162 target paths for Folder Redirection, 114 TCP/IP, 52 for Active Directory, 99 ARP for, 239 configuring, 155 TTLs in, 240 _tcp sub-domain, 159 technical support, 258, 264 temperature concerns, 134–135 templates, 103, 109–110, 113–114 termination problems in SCSI, 259 test deployments for domain restructure, 213–214 for domain upgrades, 124–126 test environments, creating, 22–24 third-party drivers, services, and tools applications, 343–345, 344 blue screen problems from, 265– 266 DNS servers, 71 in domain upgrades, 95 troubleshooting, 267–268 Time To Live (TTL) mechanism, 240 TLS (Transport Layer Security), 57 tools for domain restructure. See domain restructure troubleshooting, 345–346 ADMT, 346–347 ClonePrincipal, 347 exam essentials for, 348 key term and concept in, 348 NETDOM, 348 total statistics pane in Network Monitor, 298 Trace Route utility, 239–240 Tracert service, 239–240 transitive trust relationships, 121–122 Translate Objects page, 209

Translate Roaming Profiles option, 184, 201 translation process Security Policies, 272–279, 275– 276, 287–288 for SIDs, 209–210 Transport Layer Security (TLS), 57 troubleshooting access issues. See access issues accounts. See accounts applications. See applications domain upgrades. See failed domain upgrades modems, 334–335 network services. See network services tools, 345–346 ADMT, 346–347 ClonePrincipal, 347 exam essentials for, 348 key term and concept in, 348 NETDOM, 348 Trust Migration Wizard, 169, 180– 182 trusts in ADMT, 171 for domain restructure, 145–146 establishing, 41–42 in inter-forest migration, 11 issues in, 304–306, 305 in mixed mode, 121 NETDOM for, 41–42, 192 for target domains, 148–149, 149, 161–162 Trusts tab, 161 TTL (Time To Live) mechanism, 240 two-way trusts, 171, 304, 306

U _udp sub-domain, 159

underscore (_) characters in BIND – WINS

underscore (_) characters in BIND, 101 in subdomain names, 158 Undo Wizard, 169 Uniform Resource Locators (URLs), 239 uninterruptible power supplies (UPSs), 96, 134 universal groups, 328 Update User Rights option, 184, 201 updates, dynamic, 70, 76, 269–270 Upgrade.txt file, 257 upgrades, domain. See domain upgrades; domain upgrades with restructure UPNs (user principal names), 303 UPSs (uninterruptible power supplies), 96, 134 URLs (Uniform Resource Locators), 239 Use Automatic Settings option, 263 User Account Migration Wizard, 199– 201, 199 User Account page, 176, 177, 203 User Manager For Domains, 194 User Migration Wizard, 168 for inter-forest migration, 181–182 for intra-forest migration, 183–184 User Options page, 201 user principal names (UPNs), 303 User Rights option, 182 users accounts for. See accounts for pilot programs, 24–25 rights for, 268–269, 284–286, 286, 288–289 in trial migrations, 213

V verbose logging, 273

373

verifying application compatibility, 338–339 network services, 138, 237–241 successful migration, 237 versions in application compatibility, 341 in Group Policy Container, 103 Virtual Private Networks (VPNs), 57 virus protection in domain upgrades, 95 viruses, boot-sector, 266–267 Visual Basic scripts, 185–187 Visual Interdev RAD Remote Deployment Support, 45 VPNs (Virtual Private Networks), 57

W Web services, compatibility of, 44–45 Web sites for compatibility issues, 43 well-connected TCP/IP subnets, 152 Windows 95 and 98 systems in domain upgrades, 91 Windows File Protection feature, 340– 341 Windows Installer, 49–50 Windows Internet Naming Service. See WINS (Windows Internet Naming Service) Windows NT systems in domain upgrades, 90–91 Windows Update, 43 winnt32.exe program access to, 35 in domain upgrades, 96 for Readiness Analyzer, 256 Winnt32.log file, 257 WINS (Windows Internet Naming Service), 54–55 configuring, 157–158 for domain upgrades, 100–101

374 WINS.mdb file – Zone Type page

for dynamic updates, 269–270 issues in, 332–333 recovering, 80–81 verifying operation of, 138 WINS.mdb file, 332 WINS servers, restoring, 220 Winsock.dll file, 340 Workstation 3.51 and 4 systems in domain upgrades, 90–91 World Wide Web (WWW) in IIS installation, 44

X xcopy.exe utility, 157

Y Yes, Create A Forward Lookup Zone option, 74

Z Zone File page, 75 Zone Name page, 75 zone transfers, 71, 101, 333 Zone Type page, 74–75

MCSE: Windows 2000 Migration Exam Notes

MCSE: Windows 2000 Migration Study Guide (Exam 70-222)

MCSE: Windows 2000 Network Infrastructure Design Exam Notes

MCSE: Windows 2000 Network Infrastructure Design Exam Notes

MCSE: Windows 2000 Network Security Design Exam Notes(tm)

MCSE : Windows 2000 Network Infrastructure Administration Exam Notes

MCSE: Windows 2000 Network Security Design Exam Notes(tm)

MCSE Windows 2000 Server Exam Cram2 (Exam 70-215)

MCSE Windows 2000 Directory Services Design Exam Notes Exam 70-219

MCSE: Windows 2000 Server Study Guide Exam 70-215

MCSE Windows 2000 Network Infrastructure Exam Cram 2

MCSE Windows 2000 Active Directory Services Infrastructure Exam Cram 2 (Exam 70-217) (Exam Cram)

MCSE: Windows 2000 Server Study Guide

MCSE: Windows 2000 Network Security Design

MCSE Windows 2000 professional study guide

MCSE Training Kit Upgrading to Microsoft Windows 2000: MCSE Training for Exam 70-222

MCSE Windows XP Professional Exam Cram 2 (Exam 70-270)

MCSE Windows 2000 Active Directory Services Infrastructure Exam Cram 2 (Exam 70-217)(

MCSE: SQL Server 2000 Design Study Guide (Exam 70-229)

MCSE: SQL Server 2000 Design Study Guide (Exam 70-229)

MCSE: SQL Server 2000 Design Study Guide (Exam 70-229)

MCSE Training Kit Exam 70-219: Designing a Microsoft Windows 2000 Directory Services Infrastructure

ExamInsight For MCP MCSE Certification: Microsoft Windows 2000 Network Infrastructure Exam 70-221

MCSE Windows Server 2003 Network Infrastructure (Exam 70-293)

MCSA MCSE Self-Paced Training Kit (Exam 70-210): Microsoft Windows 2000 Professional, Second Edition

MCSA MCSE Self-Paced Training Kit: Microsoft Windows 2000 Server, Exam 70-215, Second Edition

ExamInsight For MCP MCSE Certification: Security for a Microsoft Windows 2000 Network Exam 70-220

ExamInsight For MCP MCSE Certification: Microsoft Windows 2000 Directory Services Infrastructure Exam 70-219

MCSE Training Kit Microsoft Windows 2000: Network Infrastructure Administration

MCSE: Windows 2000 Network Management Study Guide with CD-ROM

MCSE: Windows 2000 Network Security Design Study Guide Exam 70-220 (With CD-ROM)

MCSE: Windows 2000 Migration Exam Notes

MCSE: Windows 2000 Migration Study Guide (Exam 70-222)

MCSE: Windows 2000 Network Infrastructure Design Exam Notes

MCSE: Windows 2000 Network Infrastructure Design Exam Notes

MCSE: Windows 2000 Network Security Design Exam Notes(tm)

MCSE : Windows 2000 Network Infrastructure Administration Exam Notes

MCSE: Windows 2000 Network Security Design Exam Notes(tm)

MCSE Windows 2000 Server Exam Cram2 (Exam 70-215)

MCSE Windows 2000 Directory Services Design Exam Notes Exam 70-219

MCSE: Windows 2000 Server Study Guide Exam 70-215

MCSE Windows 2000 Network Infrastructure Exam Cram 2

MCSE Windows 2000 Active Directory Services Infrastructure Exam Cram 2 (Exam 70-217) (Exam Cram)

MCSE: Windows 2000 Server Study Guide

MCSE: Windows 2000 Network Security Design

MCSE Windows 2000 professional study guide

MCSE Training Kit Upgrading to Microsoft Windows 2000: MCSE Training for Exam 70-222

MCSE Windows XP Professional Exam Cram 2 (Exam 70-270)

MCSE Windows 2000 Active Directory Services Infrastructure Exam Cram 2 (Exam 70-217)(

MCSE: SQL Server 2000 Design Study Guide (Exam 70-229)

MCSE: SQL Server 2000 Design Study Guide (Exam 70-229)

MCSE: SQL Server 2000 Design Study Guide (Exam 70-229)

MCSE Training Kit Exam 70-219: Designing a Microsoft Windows 2000 Directory Services Infrastructure

ExamInsight For MCP MCSE Certification: Microsoft Windows 2000 Network Infrastructure Exam 70-221

MCSE Windows Server 2003 Network Infrastructure (Exam 70-293)

MCSA MCSE Self-Paced Training Kit (Exam 70-210): Microsoft Windows 2000 Professional, Second Edition

MCSA MCSE Self-Paced Training Kit: Microsoft Windows 2000 Server, Exam 70-215, Second Edition

ExamInsight For MCP MCSE Certification: Security for a Microsoft Windows 2000 Network Exam 70-220

ExamInsight For MCP MCSE Certification: Microsoft Windows 2000 Directory Services Infrastructure Exam 70-219

MCSE Training Kit Microsoft Windows 2000: Network Infrastructure Administration

MCSE: Windows 2000 Network Management Study Guide with CD-ROM

MCSE: Windows 2000 Network Security Design Study Guide Exam 70-220 (With CD-ROM)

Recommend Documents