Active Directory™
Bible
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

i
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

i
i
Active Directory™
Bible
Curt Simmons
IDG Books Worldwide, Inc.
An International Data Group Company
Foster City, CA ✦ Chicago, IL ✦
Indianapolis, IN ✦ New York, NY
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

i
i
i
Active Directory™ Bible
Published by
IDG Books Worldwide, Inc.
An International Data Group Company
919 E. Hillsdale Blvd., Suite 400
Foster City, CA 94404
www.idgbooks.com (IDG Books Worldwide Web site)
Copyright © 2001 IDG Books Worldwide, Inc. All
rights reserved. No part of this book, including
interior design, cover design, and icons, may be
reproduced or transmitted in any form, by any means
(electronic, photocopying, recording, or otherwise)
without the prior written permission of the publisher.
ISBN: 0-7645-4762-3
Printed in the United States of America
10 9 8 7 6 5 4 3 2 1
1B/RU/RR/QQ/FC
Distributed in the United States by IDG Books
Worldwide, Inc.
Distributed by CDG Books Canada Inc. for Canada;
by Transworld Publishers Limited in the United
Kingdom; by IDG Norge Books for Norway; by IDG
Sweden Books for Sweden; by IDG Books Australia
Publishing Corporation Pty. Ltd. for Australia and
New Zealand; by TransQuest Publishers Pte Ltd.
for Singapore, Malaysia, Thailand, Indonesia, and
Hong Kong; by Gotop Information Inc. for Taiwan;
by ICG Muse, Inc. for Japan; by Intersoft for South
Africa; by Eyrolles for France; by International
Thomson Publishing for Germany, Austria, and
Switzerland; by Distribuidora Cuspide for Argentina;
by LR International for Brazil; by Galileo Libros for
Chile; by Ediciones ZETA S.C.R. Ltda. for Peru; by
WS Computer Publishing Corporation, Inc., for the
Philippines; by Contemporanea de Ediciones for
Venezuela; by Express Computer Distributors
for the Caribbean and West Indies; by Micronesia
Media Distributor, Inc. for Micronesia; by Chips
Computadoras S.A. de C.V. for Mexico; by Editorial
Norma de Panama S.A. for Panama; by American
Bookshops for Finland.
For general information on IDG Books Worldwide’s
books in the U.S., please call our Consumer Customer
Service department at 800-762-2974. For reseller
information, including discounts and premium sales,
please call our Reseller Customer Service
department at 800-434-3422.
For information on where to purchase IDG Books
Worldwide’s books outside the U.S., please contact
our International Sales department at 317-572-3993
or fax 317-572-4002.
For consumer information on foreign language
translations, please contact our Customer Service
department at 800-434-3422, fax 317-572-4002, or
e-mail rights@idgbooks.com.
For information on licensing foreign or domestic
rights, please phone +1-650-653-7098.
For sales inquiries and special prices for bulk
quantities, please contact our Order Services
department at 800-434-3422 or write to the
address above.
For information on using IDG Books Worldwide’s
books in the classroom or for ordering examination
copies, please contact our Educational Sales
department at 800-434-2086 or fax 317-572-4005.
For press review copies, author interviews, or other
publicity information, please contact our Public
Relations department at 650-653-7000 or fax
650-653-7500.
For authorization to photocopy items for corporate,
personal, or educational use, please contact
Copyright Clearance Center, 222 Rosewood Drive,
Danvers, MA 01923, or fax 978-750-4470.
Library of Congress Cataloging-in-Publication Data
Simmons, Curt, 1968-
Active directory bible / Curt Simmons.
p. cm.
ISBN 0-7645-4762-3 (alk. paper)
1. Directory services (Computer network
technology) 2. Microsoft Windows (Computer file)
I. Title.
TK5105.595 .S55 2000
005.7'1369--dc21
00-046159
CIP
LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND AUTHOR HAVE USED THEIR
BEST EFFORTS IN PREPARING THIS BOOK. THE PUBLISHER AND AUTHOR MAKE NO
REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE
CONTENTS OF THIS BOOK AND SPECIFICALLY DISCLAIM ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. THERE ARE NO WARRANTIES WHICH
EXTEND BEYOND THE DESCRIPTIONS CONTAINED IN THIS PARAGRAPH. NO WARRANTY MAY BE
CREATED OR EXTENDED BY SALES REPRESENTATIVES OR WRITTEN SALES MATERIALS. THE
ACCURACY AND COMPLETENESS OF THE INFORMATION PROVIDED HEREIN AND THE OPINIONS
STATED HEREIN ARE NOT GUARANTEED OR WARRANTED TO PRODUCE ANY PARTICULAR RESULTS,
AND THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY
INDIVIDUAL. NEITHER THE PUBLISHER NOR AUTHOR SHALL BE LIABLE FOR ANY LOSS OF PROFIT OR
ANY OTHER COMMERCIAL DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, INCIDENTAL,
CONSEQUENTIAL, OR OTHER DAMAGES.
Trademarks: All brand names and product names used in this book are trade names, service marks,
trademarks, or registered trademarks of their respective owners. IDG Books Worldwide is not associated
with any product or vendor mentioned in this book.
is a registered trademark or trademark under exclusive license
to IDG Books Worldwide, Inc. from International Data Group, Inc.
in the United States and/or other countries.
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

i
v
Eleventh Annual
Computer Press
Awards 1995
Tenth Annual
Computer Press
Awards 1994
Eighth Annual
Computer Press
Awards 1992
Ninth Annual
Computer Press
Awards 1993
IDG is the world’s leading IT media, research and exposition company. Founded in 1964, IDG had 1997 revenues of $2.05
billion and has more than 9,000 employees worldwide. IDG offers the widest range of media options that reach IT buyers
in 75 countries representing 95% of worldwide IT spending. IDG’s diverse product and services portfolio spans six key areas
including print publishing, online publishing, expositions and conferences, market research, education and training, and
global marketing services. More than 90 million people read one or more of IDG’s 290 magazines and newspapers, including
IDG’s leading global brands — Computerworld, PC World, Network World, Macworld and the Channel World family of
publications. IDG Books Worldwide is one of the fastest-growing computer book publishers in the world, with more than
700 titles in 36 languages. The “...For Dummies®” series alone has more than 50 million copies in print. IDG offers online
users the largest network of technology-specific Web sites around the world through IDG.net (http://www.idg.net), which
comprises more than 225 targeted Web sites in 55 countries worldwide. International Data Corporation (IDC) is the world’s
largest provider of information technology data, analysis and consulting, with research centers in over 41 countries and more
than 400 research analysts worldwide. IDG World Expo is a leading producer of more than 168 globally branded conferences
and expositions in 35 countries including E3 (Electronic Entertainment Expo), Macworld Expo, ComNet, Windows World
Expo, ICE (Internet Commerce Expo), Agenda, DEMO, and Spotlight. IDG’s training subsidiary, ExecuTrain, is the world’s
largest computer training company, with more than 230 locations worldwide and 785 training courses. IDG Marketing
Services helps industry-leading IT companies build international brand recognition by developing global integrated marketing
programs via IDG’s print, online and exposition products worldwide. Further information about the company can be found
at www.idg.com.
1/26/00
Welcome to the world of IDG Books Worldwide.
IDG Books Worldwide, Inc., is a subsidiary of International Data Group, the world’s largest publisher of
computer-related information and the leading global provider of information services on information technology.
IDG was founded more than 30 years ago by Patrick J. McGovern and now employs more than 9,000 people
worldwide. IDG publishes more than 290 computer publications in over 75 countries. More than 90 million
people read one or more IDG publications each month.
Launched in 1990, IDG Books Worldwide is today the #1 publisher of best-selling computer books in the
United States. We are proud to have received eight awards from the Computer Press Association in recognition
of editorial excellence and three from Computer Currents’ First Annual Readers’ Choice Awards. Our best-
selling ...For Dummies® series has more than 50 million copies in print with translations in 31 languages. IDG
Books Worldwide, through a joint venture with IDG’s Hi-Tech Beijing, became the first U.S. publisher to
publish a computer book in the People’s Republic of China. In record time, IDG Books Worldwide has become
the first choice for millions of readers around the world who want to learn how to better manage their
businesses.
Our mission is simple: Every one of our books is designed to bring extra value and skill-building instructions
to the reader. Our books are written by experts who understand and care about our readers. The knowledge
base of our editorial staff comes from years of experience in publishing, education, and journalism —
experience we use to produce books to carry us into the new millennium. In short, we care about books, so
we attract the best people. We devote special attention to details such as audience, interior design, use of
icons, and illustrations. And because we use an efficient process of authoring, editing, and desktop publishing
our books electronically, we can spend more time ensuring superior content and less time on the technicalities
of making books.
You can count on our commitment to deliver high-quality books at competitive prices on topics you want
to read about. At IDG Books Worldwide, we continue in the IDG tradition of delivering quality for more than
30 years. You’ll find no better book on a subject than one from IDG Books Worldwide.
John Kilcullen
Chairman and CEO
IDG Books Worldwide, Inc.
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

v
Credits
Acquisitions Editor
Judy Brief
Project Editor
Amanda Munz
Technical Editor
Jim Kelly
Copy Editor
Kevin Kent
Project Coordinator
Marcos Vergara
Graphics and Production Specialists
Bob Bihlmayer
Jude Levinson
Michael Lewis
Victor Pérez-Varela
Ramses Ramirez
Quality Control Technician
Dina F Quan
Permissions Editor
Carmen Krikorian
Media Development Specialists
Brock Bigard
Angela D. Denny
Media Development Coordinator
Marisa Pearman
Illustrators
Gabriele McCann
Shelley Norris
Karl Brandt
Proofreading and Indexing
York Production Services
Cover Illustration
Lawrence Huck
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

v
i
About the Author
Curt Simmons, MCSE, MCT, CTT, is a freelance author and technical trainer focus-
ing on Microsoft operating systems and networking solutions. Curt is the author of
almost a dozen high-level technical books on Microsoft products, including Master
Active Directory Visually and MCSE Windows 2000 Server For Dummies. He has been
working closely with Windows 2000 and the Active Directory since Beta 1. Curt lives
with his wife and daughter in a small town outside of Dallas, Texas. You can reach
him at curt_simmons@hotmail.com or at http://curtsimmons.hypermart.net.
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

v
i
i
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

v
i
i
i
Preface
The Active Directory Bible is your comprehensive resource for planning, installing,
configuring, and managing the Microsoft Active Directory. The Active Directory,
which is the core networking technology in Windows 2000, provides advanced direc-
tory service features that makes your network — regardless of its size — easier to
manage and use.
Welcome to the World of Active Directory
You have heard plenty of things about the Active Directory. Some say the Active
Directory is the best product Microsoft has ever produced — some say the
Active Directory is still a baby that has a lot of maturing to do. No matter your
position, we can all agree that the Active Directory is Microsoft’s flagship product
at the moment and that the Active Directory is here to stay.
The Active Directory is the foundational networking component in Windows 2000.
The Active Directory completely revamps Microsoft networking from the days of
NT and brings Windows networking to a hierarchical, directory service model. This
model modernizes NT and paves the way for the future. With the Active Directory,
you have more manageability, more support for network resources, standardized
naming, and excellent query capabilities. In short, the Active Directory opens an
entire new world for Windows.
Before I get too carried away with the details (which you can jump into in Chap-
ter 1) and before I sound like I’m singing Microsoft’s praises, let me just answer
two questions I am asked quite frequently. The first is simply, “Do you like the
Active Directory?” The answer is — yes, I do. Quite a bit, actually. The second
question is, “Is the Active Directory perfect?” I usually smile and shake my head
because you already know the answer. No — the Active Directory is not perfect,
and there are some serious design issues Microsoft will need to address in the
future. But in Microsoft’s defense, I will say that the first release of the Active
Directory is awfully good — and when you see the potential a live directory
service can bring to a network, I think you will agree.
If you are reading this book, you are likely one of two people. First, you’re a newcomer
to Windows 2000. Perhaps you have joined the ranks of the technical professionals in
search of a better career, and you know that Windows 2000 is a wise move. If that is
you — you have come to right place. This book is all you need to learn all about the
Active Directory and the technologies that make it tick.
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

i
x
x
Preface
Second, you may be a systems administrator — someone who has a place in design-
ing an Active Directory implementation and in keeping everything running after it is
in place. You have a lot of work to do, and you need a resource that helps you meet
your goals quickly. You have come to the right place as well.
The Active Directory Bible is a comprehensive look at this new directory service.
You’ll learn how to plan, install, configure, manage, and integrate other technolo-
gies with the Active Directory with this book.
How to Read This Book (Don’t Skip This Part!)
By now, I have read more than a few Active Directory books, white papers, and other
Microsoft documentation. One of my biggest complaints with these resources is the
problem with organization. The Active Directory is often difficult to explain because
you need to know about points A, B, and C at the same time before understanding D.
Likewise, you can’t explain C without A, and you can’t understand B without know-
ing about D ... you get the picture. The problem is that the Active Directory is built
on a number of components that all play an equal role, so structuring a book or
document so that it makes sense is not easy.
I have worked very hard on this book to present a logical, chapter-by-chapter
approach to the Active Directory. If you are already familiar with the Active
Directory, you can turn straight to the chapter you need and get started. If you
are new to the Active Directory, read each chapter in order. I have tried to make
the book as sequential as possible so all of this will be easier to understand.
Along the way, you’ll find many useful step-by-step instructions and sidebars to
give you additional explanations. Be sure to read these as you learn all about
Active Directory.
A Little about This Book’s Structure
This book is divided into four parts. The following sections give you an overview of
what you will find in each part.
Part I: Planning an Active Directory Deployment
In Part I, you learn about the Active Directory technology and conceptual framework,
and then you jump right into Active Directory planning. The planning process is
extremely important, and this part teaches you all about the Active Directory names-
pace, constructing forests and trees, developing an OU plan, upgrading and migrating
to the Active Directory, and planning Active Directory sites and replication.
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
xi
Preface
Part II: Implementing the Active Directory
Once you have planned an Active Directory deployment, your next step is to imple-
ment your plan. This part shows you how to install the Active Directory in a number
of scenarios; set up forests and trees; configure sites and trusts; set up users, com-
puters, and groups; publish your resources; and deploy security.
Part III: Active Directory Management
Once your implementation is in place, you’ll need to know how to manage and
maintain the Active Directory. This part explores backup and recovery, various
tools, defragmentation, replication management, and modification of the schema.
Part IV: Integrating Supporting Technologies
This part explores supporting technologies that work with the Active Directory.
Here, you learn about IntelliMirror, Group Policy, Distributed File System, Indexing
Service, Exchange Server and the Active Directory, and Domain Name System.
Appendixes
The book concludes with six helpful appendixes. You will find an MMC tutorial,
an exploration of Resource Kit and AdminPak tools, a PDC and BDC upgrade tuto-
rial, an exploration of Windows 2000 deployment strategies, a schema class and
attribute reference, and an appendix discussing what’s on the CD-ROM included
with the book.
Icons Used in This Book
This book contains a few icons to help point out important information to you.
As you see these, make sure you take note of them:
This icon gives you information that could cause planning, implementation, or
functionality problems. I use these only when necessary, so do pay attention to
them.
This icon points the way to useful information in other locations in the book.
Cross-
Reference
Caution
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
i
xii
Preface
This icon gives you some additional information about a subject at hand. You’ll
find these helpful as you read.
This icon tells you about a utility or product that is available on this book’s CD-ROM.
This is a piece of friendly advice.
Tip
On the
CD-ROM
Note
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
i
i
Acknowledgments
Iwould like to thank everyone at IDG Books for all their hard work on this book.
Thanks to Judy Brief who made the initial offer and to Amanda Munz and Kevin
Kent, my editors at IDG Books, who have made this book easier for you to read.
Special thanks to Jim Kelly, my technical editor, who brought his expertise and con-
tent suggestions to this project. As always, thanks to my agent, Margot Maley, for
taking care of my career. Finally, thanks to my wife, Dawn, and my daughter, Hannah,
for always supporting me and giving me the “alone time” I need to write books.
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
i
i
i
Contents at a Glance
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Part I: Planning an Active Directory Deployment . . . . . . . . . . . . . 1
Chapter 1: Introduction to Active Directory Technology and Deployment Planning . . 3
Chapter 2: The Active Directory Namespace . . . . . . . . . . . . . . . . . . . . . 19
Chapter 3: Planning an Active Directory Structure . . . . . . . . . . . . . . . . . . 35
Chapter 4: Upgrading and Migrating to the Active Directory . . . . . . . . . . . . 61
Chapter 5: Planning Active Directory Sites . . . . . . . . . . . . . . . . . . . . . . 79
Part II: Implementing the Active Directory . . . . . . . . . . . . . . . . 97
Chapter 6: Installing the Root Domain . . . . . . . . . . . . . . . . . . . . . . . . . 99
Chapter 7: Setting Up Resources
. . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Chapter 8: Configuring Active Directory Domains and Sites . . . . . . . . . . . . 145
Chapter 9: Setting Up Users, Groups, and Computers . . . . . . . . . . . . . . . 167
Chapter 10: Publishing Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Chapter 11: Implementing Active Directory Security Features . . . . . . . . . . 211
Part III: Active Directory Management . . . . . . . . . . . . . . . . . . 233
Chapter 12: Maintaining the Active Directory . . . . . . . . . . . . . . . . . . . . 235
Chapter 13: Managing Active Directory Replication . . . . . . . . . . . . . . . . 259
Chapter 14: Active Directory Schema . . . . . . . . . . . . . . . . . . . . . . . . . 285
Part IV: Integrating Supporting Technologies . . . . . . . . . . . . . . 301
Chapter 15: Implementing IntelliMirror and Group Policy . . . . . . . . . . . . . 303
Chapter 16: Implementing Distributed File System and Indexing Service . . . . 331
Chapter 17: Connecting Exchange Server and the Active Directory . . . . . . . 349
Chapter 18: Implementing Microsoft DNS . . . . . . . . . . . . . . . . . . . . . . 369
Appendix A: What’s on the CD-ROM . . . . . . . . . . . . . . . . . . . . . . . . . 399
Appendix B: Microsoft Management Console Tutorial . . . . . . . . . . . . . . . 401
Appendix C: Additional Administrative Tools . . . . . . . . . . . . . . . . . . . . 417
Appendix D: PDC and BDC Upgrade Reference . . . . . . . . . . . . . . . . . . . 449
Appendix E: Windows 2000 Deployment Strategies . . . . . . . . . . . . . . . . . 459
Appendix F: Schema Class and Attribute Reference . . . . . . . . . . . . . . . . 491
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
i
v
Contents
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Part I: Planning an Active Directory Deployment
1
Chapter 1: Introduction to Active Directory Technology and
Deployment Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
What Is a Directory? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
What Is a Directory Service? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
What Does the Active Directory Do? . . . . . . . . . . . . . . . . . . . . . . . 4
Active Directory Logical Structure . . . . . . . . . . . . . . . . . . . . . . . . 6
DNS and LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Windows 2000 Domain Controllers
. . . . . . . . . . . . . . . . . . . . . . . 11
Global catalog servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Multimaster roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
The Active Directory Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Planning an Active Directory Deployment . . . . . . . . . . . . . . . . . . . 15
Gather business data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Consider IT management structure . . . . . . . . . . . . . . . . . . . . 17
Examine your physical locations . . . . . . . . . . . . . . . . . . . . . 17
Examine employee distribution . . . . . . . . . . . . . . . . . . . . . . 17
Gather network topology data . . . . . . . . . . . . . . . . . . . . . . . 17
Study network services . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Explore protocol usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Consider computer hardware . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 2: The Active Directory Namespace . . . . . . . . . . . . . . . 19
What Is a Namespace? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Exploring the DNS Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Issues with DNS Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Service Location Records
. . . . . . . . . . . . . . . . . . . . . . . . . 24
Dynamic Update Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 25
DHCP updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Incremental zone transfers . . . . . . . . . . . . . . . . . . . . . . . . . 25
The Active Directory Domain Hierarchy . . . . . . . . . . . . . . . . . . . . 26
Designing the Root Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Permanent considerations with the root domain . . . . . . . . . . . . 27
Options and considerations with the Internet . . . . . . . . . . . . . . 29
Planning Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
v
xvi
Contents
Chapter 3: Planning an Active Directory Structure . . . . . . . . . . . 35
Active Directory Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Domains under Windows NT . . . . . . . . . . . . . . . . . . . . . . . . 35
Building domain trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Using multiple domain trees . . . . . . . . . . . . . . . . . . . . . . . . 41
Using multiple forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Understanding transitive trusts . . . . . . . . . . . . . . . . . . . . . . 43
Revisiting domain controllers . . . . . . . . . . . . . . . . . . . . . . . 48
Planning Your Domain Structure . . . . . . . . . . . . . . . . . . . . . . . . . 52
Understanding Organizational Unit Structure . . . . . . . . . . . . . . . . . 55
Understanding the OU hierarchy . . . . . . . . . . . . . . . . . . . . . 55
OU administrative functions . . . . . . . . . . . . . . . . . . . . . . . . 57
Problems with nested OUs . . . . . . . . . . . . . . . . . . . . . . . . . 57
Planning Your Organizational Unit Structure . . . . . . . . . . . . . . . . . . 58
Chapter 4: Upgrading and Migrating to the Active Directory . . . . . 61
Upgrading to the Active Directory . . . . . . . . . . . . . . . . . . . . . . . . 61
Upgrading NT to 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Getting ready to upgrade the PDC to 2000 . . . . . . . . . . . . . . . . 63
Using the Active Directory Sizer . . . . . . . . . . . . . . . . . . . . . . 64
Considering domain consolidation . . . . . . . . . . . . . . . . . . . . 65
Migrating to the Active Directory . . . . . . . . . . . . . . . . . . . . . . . . 77
Chapter 5: Planning Active Directory Sites . . . . . . . . . . . . . . . . 79
What Is a Site? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Sites and Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Why Are Sites Necessary? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
User traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Replication traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Understanding Site Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Understanding the Bridgehead Server
. . . . . . . . . . . . . . . . . . . . . 91
Understanding Site Link Bridges . . . . . . . . . . . . . . . . . . . . . . . . . 93
Sites and Server Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Final Planning Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Part II: Implementing the Active Directory
97
Chapter 6: Installing the Root Domain . . . . . . . . . . . . . . . . . . 99
Examining Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . 99
How Do I Install the Root Domain? . . . . . . . . . . . . . . . . . . . . . . . 101
Installation Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Installing the Root Domain
. . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
v
i
xvii
Contents
Chapter 7: Setting Up Resources . . . . . . . . . . . . . . . . . . . . . 117
Installing Additional Domain Controllers . . . . . . . . . . . . . . . . . . . 117
Creating Child Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Creating Grandchild Domains . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Creating a New Tree in an Existing Forest . . . . . . . . . . . . . . . . . . . 125
Operations Master Placement . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Global catalog server . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Domain naming master . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Infrastructure master . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
RID master
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
PDC Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Uninstalling the Active Directory . . . . . . . . . . . . . . . . . . . . . . . . 138
Chapter 8: Configuring Active Directory Domains and Sites . . . . . 145
Configuring Domains and Trusts . . . . . . . . . . . . . . . . . . . . . . . . 145
Managing a domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Changing from mixed to native mode . . . . . . . . . . . . . . . . . . 146
Trust relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Adding UPN suffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Configuring Active Directory Sites and Services . . . . . . . . . . . . . . . 152
Creating a new site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Defining a site subnet . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Moving domain controllers into a site . . . . . . . . . . . . . . . . . . 156
Selecting a licensing computer for a site . . . . . . . . . . . . . . . . 157
Configuring site links . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Assigning a bridgehead server . . . . . . . . . . . . . . . . . . . . . . 163
Configuring site link bridges . . . . . . . . . . . . . . . . . . . . . . . 164
Chapter 9: Setting Up Users, Groups, and Computers . . . . . . . . . 167
Creating and Managing User Accounts . . . . . . . . . . . . . . . . . . . . . 167
Creating user accounts . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Configuring user account properties . . . . . . . . . . . . . . . . . . 173
Other user account management options . . . . . . . . . . . . . . . . 183
Creating and Managing Group Accounts . . . . . . . . . . . . . . . . . . . . 184
Creating a new group account . . . . . . . . . . . . . . . . . . . . . . 186
Configuring group account properties
. . . . . . . . . . . . . . . . . 187
Other management tasks . . . . . . . . . . . . . . . . . . . . . . . . . 189
Examining Computer Accounts . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chapter 10: Publishing Resources . . . . . . . . . . . . . . . . . . . . 191
Setting Up Organizational Units . . . . . . . . . . . . . . . . . . . . . . . . . 191
Creating a new OU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Configuring OU properties . . . . . . . . . . . . . . . . . . . . . . . . 194
Publishing Contact Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Creating a contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Configuring contact properties . . . . . . . . . . . . . . . . . . . . . . 198
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
v
i
i
xviii
Contents
Publishing Printer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Publishing printers connected to Windows 2000 computers . . . . . 202
Publishing printers from downlevel computers . . . . . . . . . . . . 203
Publishing Shared Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Publishing a shared folder . . . . . . . . . . . . . . . . . . . . . . . . 206
Configuring shared folder properties . . . . . . . . . . . . . . . . . . 207
Chapter 11: Implementing Active Directory Security Features . . . . 211
Security Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Windows Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Advanced permissions . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Delegation of Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Configuring Class and Attribute Security . . . . . . . . . . . . . . . . . . . 227
Installing the AdminPak . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Opening the Schema Manager . . . . . . . . . . . . . . . . . . . . . . 229
Setting class security . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Part III: Active Directory Management
233
Chapter 12: Maintaining the Active Directory . . . . . . . . . . . . . 235
Backing Up the Active Directory . . . . . . . . . . . . . . . . . . . . . . . . 235
Windows disk fault-tolerant solutions . . . . . . . . . . . . . . . . . . 236
Windows backup strategies . . . . . . . . . . . . . . . . . . . . . . . . 238
Understanding System State Data . . . . . . . . . . . . . . . . . . . . 239
Performing a Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Restoring Active Directory Data . . . . . . . . . . . . . . . . . . . . . . . . 246
Performing an Authoritative Restore . . . . . . . . . . . . . . . . . . . . . . 249
Using the Recovery Console . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Common Maintenance Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Checking the LostAndFound container . . . . . . . . . . . . . . . . . 255
Online and offline defragmentation . . . . . . . . . . . . . . . . . . . 256
Removing ghost objects . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Chapter 13: Managing Active Directory Replication . . . . . . . . . . 259
How Replication Works
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Replication concepts
. . . . . . . . . . . . . . . . . . . . . . . . . . . 260
The Replication process . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Solving replication problems . . . . . . . . . . . . . . . . . . . . . . . 265
Examining Intrasite Replication . . . . . . . . . . . . . . . . . . . . . . . . . 267
Examining Intersite Replication . . . . . . . . . . . . . . . . . . . . . . . . . 268
Forcing replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Manual connection creation . . . . . . . . . . . . . . . . . . . . . . . 271
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
v
i
i
i
xix
Contents
Using Replication Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Adding a monitored server . . . . . . . . . . . . . . . . . . . . . . . . 275
Domain controller replication errors . . . . . . . . . . . . . . . . . . 277
Server monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Server properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Replication Monitor options . . . . . . . . . . . . . . . . . . . . . . . 282
Chapter 14: Active Directory Schema . . . . . . . . . . . . . . . . . . 285
Schema Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Planning for Schema Modification . . . . . . . . . . . . . . . . . . . . . . . 288
Protection process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Issues with inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Schema Modification Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Using the Schema Manager . . . . . . . . . . . . . . . . . . . . . . . . 290
Using ADSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Part IV: Integrating Supporting Technologies
301
Chapter 15: Implementing IntelliMirror and Group Policy . . . . . . 303
Understanding IntelliMirror . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Offline files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Synchronization Manager . . . . . . . . . . . . . . . . . . . . . . . . . 306
Windows Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Disk quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Remote Installation Services . . . . . . . . . . . . . . . . . . . . . . . 311
Installing RIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Setting up RIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
RIS server properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Prestaging RIS clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Creating a client boot floppy . . . . . . . . . . . . . . . . . . . . . . . 317
Group Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Group Policy basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Group Policy objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Accessing a Group Policy . . . . . . . . . . . . . . . . . . . . . . . . . 320
Configuring a Group Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Computer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 324
User Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Chapter 16: Implementing Distributed File System and
Indexing Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Understanding Distributed File System (Dfs) . . . . . . . . . . . . . . . . . 331
Standalone Dfs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Adding Dfs links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Creating a replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
i
x
xx
Contents
Active Directory Integrated Dfs . . . . . . . . . . . . . . . . . . . . . . . . . 340
Indexing Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Installing Indexing Service . . . . . . . . . . . . . . . . . . . . . . . . 342
Indexing Service catalogs . . . . . . . . . . . . . . . . . . . . . . . . . 343
Managing the Indexing Service . . . . . . . . . . . . . . . . . . . . . . . . . 346
Chapter 17: Connecting Exchange Server and the Active Directory 349
Exchange and the Active Directory . . . . . . . . . . . . . . . . . . . . . . . 349
Exchange 5.5 and the Active Directory . . . . . . . . . . . . . . . . . 350
Exchange 2000 and the Active Directory . . . . . . . . . . . . . . . . 351
Installing the Active Directory Connector . . . . . . . . . . . . . . . . . . . 353
Configuring Connector Management Properties . . . . . . . . . . . . . . . 356
Creating and Configuring Connection Agreements . . . . . . . . . . . . . . 357
ADC Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Using Multiple ADC Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Synchronizaton with the ADC . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Chapter 18: Implementing Microsoft DNS . . . . . . . . . . . . . . . 369
Understanding DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
The DNS namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
How name resolution works . . . . . . . . . . . . . . . . . . . . . . . 372
Understanding DNS zones . . . . . . . . . . . . . . . . . . . . . . . . . 376
Understanding Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 377
Installing DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Creating Forward and Reverse Lookup Zones
. . . . . . . . . . . . . . . . 379
Creating a new forward lookup zone . . . . . . . . . . . . . . . . . . 379
Creating a reverse lookup zone . . . . . . . . . . . . . . . . . . . . . . 381
Managing the DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Interfaces tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Forwarders tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Advanced tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Root Hints tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Logging tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Monitoring tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Managing DNS Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Host records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Alias records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Mail Exchanger records . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Other records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Zone properties
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Final DNS Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
x
xxi
Contents
Appendix A: What’s on the CD-ROM . . . . . . . . . . . . . . . . . . . 399
Appendix B: Microsoft Management Console Tutorial . . . . . . . . 401
Appendix C: Additional Administrative Tools . . . . . . . . . . . . . . 417
Appendix D: PDC and BDC Upgrade Reference . . . . . . . . . . . . 449
Appendix E: Windows 2000 Deployment Strategies . . . . . . . . . 459
Appendix F: Schema Class and Attribute Reference . . . . . . . . . 491
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
End-User License Agreement . . . . . . . . . . . . . . . . . . . . . . . . . 574
CD-ROM Installation Instructions . . . . . . . . . . . . . . . . . . . . . . 578
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
x
i
4
7
6
2
-
3

F
M
.
f
.
q
c


1
0
/
2
5
/
0
0


4
:
3
1

P
M


P
a
g
e

x
x
i
i
Introduction to
Active Directory
Technology and
Deployment
Planning
If you have been at all involved in the networking and com-
puter scene during the past few years, you have certainly
heard about the Active Directory. Perhaps you are facing an
upcoming Active Directory implementation, or perhaps you
are already waist deep in one. Maybe you want to tackle the
Active Directory to further your career options. You have
come to the right place. This book helps you make sense of
the Active Directory — how to plan an implementation and
how to configure it. Specifically, this chapter gets you started
off by exploring Active Directory’s architecture, concepts, and
definitions. This chapter serves as an introduction — a start-
ing place for the rest of the book. You can rest assured that
the topics covered in this chapter are explored in other places
in the book as well. With that said, let’s jump into the Active
Directory.
What Is a Directory?
You’ve heard all the marketing hoopla. You’ve heard the com-
petitor’s complaints. However, with all the excitement (and
lack of excitement), I think I can safely say that the Active
Directory is a permanent part of Windows 2000 (and beyond)
1
C H A P T E R
✦
✦
✦
✦
In This Chapter
Exploring directory
services
Examining the Active
Directory’s features
Understanding the
Active Directory’s
logical structure
Planning for the
Active Directory
✦
✦
✦
✦
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
1

P
M


P
a
g
e

3
4
Part I ✦ Planning an Active Directory Deployment
networking. You have heard that directory services in computer networks will
change the face of computing. Whether this is true or not I’ll leave to your own
opinion. Still, directory services certainly do change networking, and I believe
you will find the change for the better. In order to begin talking about the Active
Directory, the term directory should first be defined.
A directory is, at its most fundamental level, a collection of information that is
organized in a particular way. The organizational method makes sorting through
the information fast and easy so you can find the desired data. Directory services
are often compared to a phone book. A phone book is a collection of data organized
by last name, first name, phone number, city, and state. Because the information is
organized in a particular way, you can quickly find a particular person and get his
or her telephone number. Directories, of course, are nothing new — they have been
used for about as long as books have been available; but in terms of networking,
directories are still on the cutting edge of networking technology.
What Is a Directory Service?
The Active Directory is not the first directory service to hit the market. In fact,
directory services have been around for some time now. However, the release of
Windows 2000 and the Active Directory from Microsoft and the existence of NDS
from Novell solidify the idea that networks should be directory based.
Only a few short years ago, networking was not as important as it is today. There
were, of course, big businesses with big mainframes and a lot of data. But, it was
not until the PC took hold that computing began to change and networks began to
grow at an alarming rate. In most major networks today, every user has a computer,
public and personal data, and many kinds of different computing needs. Because of
sheer numbers, networks today can easily get out hand — too many servers, too
many resources, too much mass confusion. In fact, finding needed information on
the network can be a serious time-loss issue and a common complaint among users.
Enter directory services. The goal of directory services is to bring order to both big
and small networks. Directory services provide a streamlined approach to network
and resource discovery. With a directory, users can perform search queries and
find network information quickly and easily. The Active Directory is Microsoft’s
answer to the directory services needs of today’s networks.
What Does the Active Directory Do?
The Active Directory is a directory service — it provides a number of different ser-
vices relating to the organized storage of network resources. The following points
highlight some of the Active Directory’s features:
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
1

P
M


P
a
g
e

4
5
Chapter 1 ✦
Introduction to Active Directory Technology and Deployment Planning
✦ Organized Approach — The Active Directory brings order to your network by
organizing network resources, such as user accounts, group accounts, shared
folders, printers, and so on. With the Active Directory, users can quickly find
information they need.
✦ Ease of administration — Windows 2000 networks no longer use primary
domain controllers (PDCs) and backup domain controllers (BDCs). All domain
controllers are simply peers, providing you a single point of administration
and excellent fault tolerance.
✦ Removes Topology from Users — The Active Directory helps remove knowl-
edge of the network topology from end users. End users do not have to know
which server holds which resource and where it is located on the network.
The Active Directory contains powerful query capabilities so users can per-
form full text searches to find what resources they need.
✦ Reduction of NT Domains — This is the part where all Windows NT network
administrators cringe. A major goal of the Active Directory is to make large
networks more manageable — and part of that lofty goal is to reduce the num-
ber of NT domains. The Active Directory does not have a domain user/group
account limit (well, it does have one of about 1 million), and due to its design,
many networks that currently have several existing NT domains now need
only one Windows 2000 domain.
✦ Growth Potential — Two buzzwords thrown around about the Active Directory
are scalability and extensibility. Scalability means that a service can grow with
the needs of your network. The Active Directory is a scalable product because
it can grow to meet the needs of your network. The Active Directory works on
a network of a few hundred computers or on a network of thousands of com-
puters. Extensibility means that service can be extended. The Active Directory
can be extended in terms of its namespace and through resources it contains.
✦ Standardization — The Active Directory is completely built on networking
and protocol standards that currently exist and are heavily used. In other
words, there are no totally new standards that must be mastered. The Active
Directory is built on a TCP/IP network, which is the networking protocol of
choice these days, and it is completely integrated with Domain Name System
(DNS) and Lightweight Directory Access Protocol (LDAP), both of which are
explored in detail later in this book.
✦ Network Control — The Active Directory offers a very fine level of network
management, both in terms of server management and desktop management.
Through Windows 2000’s Group Policy, you can manage network user desktop
configurations much more easily and effectively. Through the Active Directory,
you can finely control resource security and even delegate administrative tasks
to other people through Delegation of Control.
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
1

P
M


P
a
g
e

5
6
Part I ✦ Planning an Active Directory Deployment
✦ Easier WAN Management — Once you get Active Directory correctly set up,
it manages its own replication topology. The Active Directory includes more
internal services that help it manage and control its own processes, including
replication. This feature keeps administrators out of such deathly details and
enables software to take care of itself and replicate data between domain con-
trollers and sites as needed.
Aside from these major points, the Active Directory also brings order and man-
agement options to larger networks, which was a major pitfall with Windows NT
networks. NT networks functioned well, especially if the network did not get too
large. However, the NT architecture was flat in that there were not different levels
of administration and security. The larger NT networks became, the more domains
were needed, which increased network traffic, trust relationship issues between
domains, and administrative headaches. The Active Directory solves this problem
because it is built on a hierarchy where information can be managed at different
levels.
Active Directory Logical Structure
To begin the exploration of the Active Directory, I want to take a look at its logical
structure. In order to effectively plan, implement, and administer the Active Direc-
tory, this logical structure will need to become second nature.
The Active Directory is built on the domain level. Before Windows 2000 was released,
it was often rumored that domains were no longer going to be a part of Windows
2000. That is not all true, but domains have changed quite a bit because they can be
bigger and do not have the restrictions found in NT domains. As a point of reference,
a domain is a logical grouping of computers and users for both administrative and
security purposes. In Windows NT, you found yourself working with and spending
a lot of time troubleshooting domains. If you currently have an NT network of any
size, you probably have quite a few domains. NT domains were so limited that they
seemed to grow and multiply too rapidly, creating headaches and confusion for both
users and administrators.
The Windows 2000 Active Directory domain model is different. Windows 2000 Active
Directory domains are organized into domain trees that exist in a forest. When you
first install the Active Directory, you create the first domain in a new forest. That
new domain becomes the root domain. If you choose to install additional domains,
they are created from the forest root.
You can create additional domain trees in a single forest. In other words, a forest
can contain more than one domain tree. These issues are explored in detail in
Chapters 2 and 3.
The Active Directory prefers a few domains (or even just one) with several Organi-
zational Units (OUs). An OU is like a file folder — it holds important information.
Tip
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
1

P
M


P
a
g
e

6
7
Chapter 1 ✦
Introduction to Active Directory Technology and Deployment Planning
OUs are containers designed to hold all kinds of Active Directory resources, such as
users, computers, printers, and even other OUs. The great thing about OUs is you
can set security, administrative control, and even policies at the OU level. In fact,
many existing NT networks that have several domains can now be replaced with
one domain and several OUs.
As I mentioned, an OU is designed to hold resources, such as users, computer
accounts, printers, shared folders, and so on. These resources are called objects,
and from this point on, I will refer to them as such. Figure 1-1 shows you a graphical
representation of this model.
Figure 1-1: Active Directory logical structure
Each object that the Active Directory contains possesses attributes, shown in
Figure 1-2. You can think of attributes as qualities of an object that help define it.
For example, a user account has attributes such as user name, password, e-mail
address, phone number, group memberships, and so on. These attributes define
the object. Each object in the Active Directory contains predefined attributes.
Domain
Domains hold organizational units, which
contain Active Directory objects.
Organizational
Unit
User
Accounts
Applications
Shared
Folders
Printers
Computer
Accounts
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
1

P
M


P
a
g
e

7
8
Part I ✦ Planning an Active Directory Deployment
If you think of the Active Directory as a database (which it is), think of an object as
a database entry and the attributes as fields for the object.
Figure 1-2: Objects and attributes
Consequently, in the logical structure, you have the domain, the OU, and the object,
and each object has attributes that define it. The Active Directory also uses sites,
but sites are not considered a part of the Active Directory logical structure, or hier-
archy. Sites are maintained in the Active Directory for replication and traffic-control
purposes only. A site, by definition, is a physical location of computers and users,
contrasting to a domain, which is a logical grouping of computers and users. It is
important to note that sites and domains are not interrelated — a site can contain
several domains or a domain could span multiple sites. While a domain is a logical,
administrative level of networking, a site is a physical level. In the Active Directory,
sites are based on well-connected IP subnets, and they can be a point of planning
and configuration confusion. Several of the following chapters address site configu-
ration and replication traffic to help clear up this confusion.
Object
Attributes
username
password
email address
phone number
group
membership
Say Good-bye to Difficult Trust Relationships
If you have worked in a multiple domain NT network, you know a thing or two about trust
relationships. Trust relationships enable a user in Domain A to access resources in Domain
B. Trust relationships must be established to enable remote domain resource access, and in
Windows NT, you had to configure each side of the trust — determining who was trusted
and who was trusting. In complex environments, trust relationship became very complex
and difficult to configure and manage.
Say good-bye to complex trust relationships in Windows 2000. In Windows 2000 environ-
ments that need more than one domain, automatic Kerberos transitive trusts are established
when you create new domains in the forest tree. Kerberos is the security protocol in Windows
2000, replacing NTLM in Windows NT. Kerberos provides superior security technology and
many new security features, like transitive trust relationships. A transitive trust simply means
that if Domain A trusts Domain B, and Domain B trusts Domain C, then Domain A automati-
cally trusts Domain C. The transitive trust relationships are automatically configured with all
other domains and domain trees within the forest. The forest serves as your boundary, and
all domains automatically trust each other—no configuration from you required!
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
1

P
M


P
a
g
e

8
9
Chapter 1 ✦
Introduction to Active Directory Technology and Deployment Planning
DNS and LDAP
I mentioned earlier in the chapter that Active Directory is fully compatible with
Domain Name System (DNS) and Lightweight Directory Access Protocol (LDAP).
DNS is explored in several later chapters, so I’ll approach it from an overview per-
spective here. DNS is a name resolution method that resolves host names to IP
addresses. DNS is used on TCP/IP networks and is the name resolution system
used on the entire Internet. DNS enables a host name like www.microsoft.com to
be resolved to a TCP/IP address like 131.107.2.200. Computers communicate using
an IP address. IP addresses are difficult for humans to remember because we are
language-based creatures. DNS allows us to give friendly, language names, like
microsoft.com, to hosts instead of having to remember its numerical IP address.
DNS’s job is to resolve the two. When a user requests www.microsoft.com, DNS
uses several name servers to find the actual IP address of microsoft.com. Once
it is found, the IP address is returned to the client so the client can use the IP
address to contact microsoft.com. All of this is invisible to users and very fast.
So, what does all of this have to do with the Active Directory? DNS is a namespace,
which means it is an area that can be resolved. A phone book is a namespace because
it contains certain data that you resolve (name to phone number) in a certain way.
Internet names, such as microsoft.com, yahoo.com, amazon.com, and so forth, all
follow this naming scheme in order to be resolved. The Active Directory is built on
DNS — in fact, Active Directory names are DNS names. In earlier versions of Windows,
NetBIOS was used to provide friendly names to computers, and Windows Internet
Name Service (WINS) was used for the locator service. In pure Windows 2000 net-
works, DNS is now used for the locator service.
WINS is still supported in Windows 2000 for backward compatibility, but Windows
2000 computers (Server and Professional) need only DNS.
It is important to note that the Active Directory namespace is not the DNS name-
space. The DNS namespace is used on the Internet while the Active Directory
namespace is used for private networks. However, the Active Directory namespace
is based on DNS, and it connects into the DNS namespace. In other words, DNS is a
global namespace that makes up the entire Internet, and the Active Directory name-
space is built on the DNS hierarchical structure so that it connects into the DNS
global namespace. For now, it is important to remember that you cannot implement
the Active Directory without DNS, and all Active Directory names are DNS names.
The Active Directory is also a fully compliant LDAP directory service. To under-
stand why this is important, you need to understand a few things about LDAP. LDAP
is based on the Directory Access Protocol (DAP), which was an implementation of
X.500 networks. X.500 is a very broad directory service that is built on a hierarchi-
cal structure, much like DNS. X.500 directories are searchable, and DAP is used in
X.500 networks to query the database in order to locate directory information. The
problem with DAP is that it places a lot of the processing burden on client comput-
ers and so gained the reputation of having a high overhead. LDAP was developed
Note
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
1

P
M


P
a
g
e

9
10
Part I ✦ Planning an Active Directory Deployment
from DAP (RFC 1777), but it does not have the high overhead of DAP and does not
require the X.500 network implementation. LDAP maintains the functionality of DAP
without the X.500 overhead.
Since it was developed, LDAP has become an Internet standard. You use it in
search engines and newsgroups. It works great, is a standard, and is used in the
Active Directory for client queries. Let’s say that a user performs a directory
search to locate all “laser printers.” LDAP uses the keywords to perform a search
of objects and attributes to locate all laser printers. All access to Active Directory
objects is performed through LDAP, and it is used when administrators modify
Active Directory objects.
LDAP can be used in any attribute-based, hierarchical directory, which is why it
works well with the Active Directory.
In order to provide the powerful query capabilities that make LDAP so popular,
LDAP assigns Active Directory objects several different names. These different
names provide information about the object that can be used for query matches.
First, LDAP gives objects a distinguished name (DN) and a relative distinguished
name (RDN). The DN shows the complete path to the object or where the object
resides within the Active Directory. Remember that the Active Directory hierarchy
begins at the domain level, then moves to the OU, and finally to the object level.
The DN shows this complete path. The RDN provides the common name of the
object. For example, the following line shows the DN and RDN of a user account.
Cn=ksmith,ou=namerica,dc=triton,dc=com
The RDN is ksmith, the common name for a user account. The DN provides the
entire path to the user account, which exists in an Organizational Unit called
“namerica,” which in turn resides in the triton.com domain. (Remember that all
Active Directory names are DNS names, so your domain names will be followed
by .com or some other DNS first-level domain.) The RDN (cn) always appears first,
followed by the DN (path to the object — dc stands for domainDns object class).
Here’s another example:
Cn=HPDeskJet30,ou=resources,ou=acct,dc=triton,dc=com
In this example, the RDN is HPDeskJet30, a shared network printer that resides
in the Resources OU, which resides in the Acct OU, which resides in the domain
triton.com.
Tip
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

1
0
11
Chapter 1 ✦
Introduction to Active Directory Technology and Deployment Planning
Neither administrators nor users see the DN information when working with the
Active Directory, but you can view this information using various Active Directory
administration tools found in the Windows 2000 Resource Kit. See Appendix C for
more information.
In addition to the DN and RDN, LDAP also uses the user principal name (UPN) to
locate objects. The UPN is a friendly name assigned to an object that is displayed
as objectname@domainname. For example, a user account named ksmith in the tri-
ton.com domain appears as ksmith@triton.com. To LDAP, this is a local name on
a local network. On the Internet, this same name is an e-mail address. The UPN is
used both by LDAP and to make Windows logon much simpler. Administrators can
generate UPN suffixes to make user logon more mainstream and less confusing.
See Chapter 8 for more information on user principal names.
While on the subject of LDAP names, this is a good place to mention that each
Active Directory object also has a Globally Unique Identifier (GUID). The GUID is a
128-bit number that is assigned to the object when it is created. The GUID is worth
mentioning here because it never changes for a particular object, unlike the DN or
RDN, which can both change.
An object’s GUID is actually an attribute of that object. The GUID, like other attri-
butes, is required for every object. Depending on the object, some attributes are
mandatory while others are optional. The GUID is always required for every object.
Which attributes are required and which attributes are not required depend on the
object itself. For example, when creating a user account, a GUID is assigned, and
you also have a required attribute of user name. You can’t create the account with-
out a user name, so that attribute is required. Other attributes, such as e-mail
address and phone number, are optional — you can include them if you want, but
these are not required by the Active Directory.
Windows 2000 Domain Controllers
I mentioned earlier that Windows 2000 no longer uses PDCs or BDCs. That’s enough
to rattle the brain of any NT administrator, but to truly get into Active Directory
mode, you’ll have to lose a few sacred artifacts from the NT world. A couple of
those are PDCs and BDCs.
Note
Cross-
Reference
Note
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

1
1
12
Part I ✦ Planning an Active Directory Deployment
Windows 2000 domain controllers function as peers. This means there is no single
primary domain controller. All domain controllers are simply “domain controllers”
and all of them are equal. Because you can use any domain controller to make
changes to the Active Directory and fault tolerance is automatically built-in, this
is an excellent management feature. If one domain controller crashes, no problem,
the other domain controllers continue functioning as normal, and network activity
functions as normal. In Windows NT networks, the PDC contains the writable copy
of the database while BDCs all have a replicated copy from the PDC. In Windows
2000 networks, all domain controllers contain a writable copy of the database.
So, now that you know that all Windows 2000 domain controllers are peers, let me
throw a little confusion into the mix. Although all Windows 2000 domain controllers
are peers, some domain controllers have certain specialized roles assigned to them.
These specialized roles exist because they do not work well functioning on all domain
controllers. The following two sections examine these specialized roles.
Global catalog servers
Some domain controllers are global catalog servers. Depending on your network
configuration, you may have several global catalog servers. Global catalog servers
perform two major functions:
1. Global catalog servers contain a full replica of all Active Directory objects
in their domain and a partial replica of all Active Directory objects in other
domains in the forest. For example, let’s say that Karen Anderson, a user
in a domain called triton.com, needs to use a printer in the prod.triton.com
domain. Karen searches for the printer. In order to fulfill Karen’s request, a
global catalog server is consulted because the global catalog server has a par-
tial replica of all objects in the other domain. Using the global catalog server,
Karen can find and connect to a desired printer (assuming she has appropri-
ate permission to do so).
A partial replica simply means that the global catalog server is aware of the object
and the most common attributes for that object. Since its job is to help with user
queries, only the most common attributes that might be used in a search process
are kept on global catalog server.
2. Global catalog servers are required for user logons. This may sound strange,
but global catalog servers assist with user logons in that they provide infor-
mation about Universal groups, a new type of group in Windows 2000, to a
domain controller where the logon request initiated.
For more information on Universal groups, see Chapter 9.
Cross-
Reference
Tip
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

1
2
13
Chapter 1 ✦
Introduction to Active Directory Technology and Deployment Planning
Global catalog servers are necessary for user logons if the domain is running
in native mode — not mixed mode – because Universal groups are only sup-
ported in Native mode. Mixed mode means that Windows NT BDCs are still in
use while native mode means that only Windows 2000 servers are in use.
Users cannot logon to the network if a global catalog server is not available when
the domain is running in native mode. You can learn more about mixed mode and
native mode in Chapter 8.
When installing the Active Directory for the first time, the first domain controller
where you begin the installation becomes the global catalog server for the domain.
You can change this role to another server if necessary.
Multimaster roles
Aside from the global catalog server, some domain controllers also run what is called
flexible single master operation (FSMO) roles. In order to explain FSMO roles, I need
to mention a few things about Windows 2000 replication (which is covered in detail
in Chapters 5 and 13). Replication is the process of sending update information to
other domain controllers. Windows 2000 uses multimaster replication. Just as with the
absence of a PDC, there is no single master replicator. This means that changes to the
database can occur from any domain controller and that then that domain controller
is responsible for letting all other domain controllers know about database changes.
Imagine this scenario. Let’s say you add a new user account to one domain controller.
Remember that each domain controller maintains its own copy of the Active Direc-
tory database. If the domain controller does not let all other domain controllers
know about the new user account, will the user be able to log on? No — not unless
by some stroke of luck the user attempts authentication on the domain controller
where the account was created. Now imagine if this happens over and over each
day. Eventually, each domain controller will have a different database and a different
view of the network because the domain controller would not know about database
changes on all other domain controllers. Enter replication. Replication is a fairly com-
plex process that sends changes to other domain controllers so that each domain
controller can keep up with all the database changes made on different domain con-
trollers. Without effective replication, the Active Directory would quickly become a
hopeless mess of inaccurate data due to the peer domain controller design.
With all that said, turn your attention back to FSMO roles. Multimaster replication
works great, but for some database changes, the process does not work well. In
order to solve this problem, certain domain controllers hold certain FSMO roles.
This means that only those domain controllers accept certain types of database
changes and perform certain functions. There are five different FSMO roles that
cover the replication exceptions and process handling exceptions of multimaster
replication. Table 1-1 gives you a preliminary overview of these five roles.
Tip
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

1
3
14
Part I ✦ Planning an Active Directory Deployment
Table 1-1
FSMO Roles
FSMO Role
Explanation
Schema Master
The schema master role belongs to only one domain con-
troller in the entire forest. The schema is simply a schematic,
or blueprint, of all Active Directory objects and their attributes.
The schema determines what kinds of objects can be stored
in the directory and what attributes define those objects. Any
modifications made to the schema must be made on the
domain controller holding the schema master role.
Domain Naming Master
The domain naming master role belongs to only one domain
controller in the forest. The domain naming master controls
the addition and removal of domains in the forest.
Relative ID (RID) Master
The RID master manages the distribution of RID numbers to
other domain controllers. When a domain controller generates
a new security ID (SID) for a new user, computer, or group
account, a domain security ID and a RID number are used.
The RID master makes certain that no two domain controllers
have the same or overlapping RID numbers. Each domain in
the forest has one RID master.
PDC Emulator
Windows 2000 domains that have Windows NT BDCs still in
operation (mixed mode) and Windows 2000 domains that
have downlevel clients (such as 9x and NT) expect a PDC to
be present on the network. The PDC Emulator role is played
by one domain controller in each domain to “act like” a
Window NT PDC.
Infrastructure Master
The Infrastructure master role, which is held by one domain
controller in each domain, updates group members as
necessary. For example, when the membership of a particular
group changes, the Infrastructure master updates the group
to ensure that changes are processed appropriately.
The Active Directory Schema
I’ve mentioned the Active Directory schema in Table 1-1. The Active Directory
schema is a complete collection, or schematic, of Active Directory objects and
attributes and the classes to which objects belong. The schema determines
what can be stored in the Active Directory, where it belongs in the database,
and what attributes belong to what objects. As a result, you can think of the
schema as rules that determine what can be stored in the Active Directory.
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

1
4
15
Chapter 1 ✦
Introduction to Active Directory Technology and Deployment Planning
Within the schema, objects belong to different classes. For example, user objects
belong to the user class. Whenever you create new objects, the schema determines if
the object can be created, and it determines what mandatory attributes and optional
attributes belong with that class. Windows 2000 Active Directory ships with a default
schema that is installed when you install the Active Directory. For most Active Direc-
tory implementations, the default schema is all you need for an effective implementa-
tion; however, you can extend the schema by adding new classes of objects and new
attributes to define those objects. Extending the schema is a serious operation that
can have devastating consequences on your enterprise implementation if performed
incorrectly, so modification is something that requires careful planning. As a security
precaution, schema modification can occur only on the domain controller holding the
Schema master role.
Chapter 14 explores modification issues in more detail.
The schema exists on each domain controller in the Schema container. Upon instal-
lation, the first domain controller receives the schema and each domain controller
thereafter. Like all Active Directory data, the schema is replicated among domain
controllers to ensure accuracy in the event that a schema modification does occur.
The schema is found on all domain controllers, along with the Active Directory
database, in %systemroot%\system32\ntds.
Planning an Active Directory Deployment
The entire first part of this book is devoted to Active Directory deployment plan-
ning. This fact alone should tell you a thing or two. Like all complex networking tech-
nologies, the Active Directory requires a significant amount of planning in order to
deploy the directory service in a way that will function from a networking view to an
administrative view. I can’t say enough here about how important deployment plan-
ning is to the success of your Active Directory implementation. It is always tempting
to start with that installation CD, but you have some pencil-and-paper work to do
before ever starting an installation.
The remaining chapters in this section explore planning your deployment — from
your namespace to your domain and OU structure, your site structure, as well as
upgrade and migration plans. Before getting into those technical issues, however,
you have some up-front work to do.
As a starting place for your implementation, you and your company will first have to
decide who will make the Active Directory implementation decisions. Under most
circumstances, the best solution involves a number of people, including IT adminis-
trators, company managers, and possibly even team/division leads. Choose a mix-
ture of people who can bring different perspectives to the table. As an administrator,
it is easy for you to get caught up in the technical details, but when you are planning,
Cross-
Reference
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

1
5
16
Part I ✦ Planning an Active Directory Deployment
gather information from all kinds of people on the network. The following are some
questions to consider:
✦ What do your users need?
✦ What have been the previous problems?
✦ How can an Active Directory implementation meet the needs of users and
solve existing problems?
✦ How can you plan for future growth and changes?
These are all complex questions, but ones that need to be addressed. After all,
the Active Directory seeks to provide end users with a network environment that
is basically invisible to them and helps them find the resources they need.
So, you’ll need to decide who will be a part of the planning process. It is not unusual
for an enterprise to include several people on a primary committee and a number of
additional people on a review committee. This ensures that all issues, concerns, and
potential problems are addressed.
Once the planning group is established, you have some preliminary actions to take
before you begin designing your own Active Directory infrastructure. You can call
this boring detective work. Nevertheless, this boring detective work will pay off as
you begin planning. I’ve broken this action out into sections for quick review and
reference.
Gather business data
The Active Directory is designed to help your network meet the needs of your
business. Thus, Active Directory’s structure and design allows business policy to
become network policy and to assist in all business goals. Obviously, the purpose
of networks is to exchange information so that companies can be more productive
and lower the Total Cost of Ownership (TCO). The Active Directory can help you
accomplish this goal, but you’ll need to know a thing or two about your business
to make the goal a reality. Aside from business goals and processes with your com-
pany, take a look at how your company management is structured. Businesses are
either structured in a centralized or decentralized management structure (or a
combination of the two). It is not unusual for a company to begin operations with
a centralized management structure where there is one chain of command, but
as companies grow, this structure usually becomes impractical. Therefore, most
larger companies use a decentralized management structure where there are
several chains of command. Of course, there is no right or wrong here, but you do
need to find out how your business functions. A flowchart or schematic will help,
so consider generating one as you gather data about your business.
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

1
6
17
Chapter 1 ✦
Introduction to Active Directory Technology and Deployment Planning
Consider IT management structure
Your existing IT management structure may need some revamping, and an Active
Directory implementation gives you a good reason to do so. Let’s face the facts —
networks grow and change and, due to growth and politics, IT administration can
become complicated and redundant. This is a good opportunity to perform an
analysis and make certain your IT structure is effective and logical.
Examine your physical locations
You should create a chart of your company’s physical locations. This data includes
geographic locations, city locations, buildings, and even locations within a particu-
lar building. Gather this information, chart it, and make sure it is accurate. Include
any subsidiaries or alternate groups as well. You’ll use this information as you con-
sider your Active Directory deployment scope.
Examine employee distribution
Along with your physical locations, gather information about the number of employ-
ees at each physical location. For example, you may have one building that holds
1,200 employees while another office across town holds only 10. Gather this data
and combine it with the physical locations chart you created. This will give you an
accurate view of your network employee distribution.
Gather network topology data
The Active Directory will function only as well as the network it is built on. If you
have network problems now, then you will have network problems when you imple-
ment the Active Directory (and maybe even more). During the planning process,
you should carefully chart your network topology, noting any and all WAN links
between sites and their speeds. This information will greatly impact your Active
Directory design so make certain the data is accurate. As you gather network data,
create a list of current network problems, especially problems with connectivity
reliability and lack of bandwidth. As you consider these problems, it may be time
to make some network upgrades in order to support the Active Directory.
Study network services
In an existing network, you no doubt have a number of different services that may
be in operation. For the moment, take a look at how your network functions, con-
sidering the following questions:
✦ What are the services that are needed by your clients and are critical for your
business operations?
✦ What about custom applications?
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

1
7
18
Part I ✦ Planning an Active Directory Deployment
✦ Do you have applications that need to be tested before implementing
Windows 2000?
Explore protocol usage
The Active Directory must be built on a TCP/IP network. If your existing network is
not running TCP/IP, it must be converted and updated as necessary before you con-
tinue. Also, consider other protocols that may be in use. Will they be necessary
once the Active Directory is in place? If not, begin removing those and streamlining
your network.
Of course, if you are building a new network from scratch, this issue and the fol-
lowing issue do not apply. However, you should continue reading and considering
the information in this section because your design plans might still be impacted.
Consider computer hardware
If you are upgrading your Windows NT computers to Windows 2000 and upgrading
your client computers to Windows 2000 Professional, you’ll need to spend some
time examining server and computer hardware. Windows 2000 is rather resource
intensive, and the NT server that limped along okay will probably not be able to
handle Windows 2000. Alas, hardware upgrades may be needed to get the perfor-
mance satisfaction you need. The Windows 2000 Server and Professional documen-
tation lists system requirements, but keep in mind these are bare minimums. The
reality is your server and desktop systems will need more processing power and
RAM to perform optimally, so consider these issues and potential upgrades as a
part of your implementation plan.
The key point with all of these initial planning considerations is to gather informa-
tion. As always, information is power. With more information, you will make wiser
decisions as you prepare to implement the Active Directory.
Summary
This chapter gave you a technical overview of the Active Directory and explored
a starting point for your Active Directory implementation planning. The Active
Directory is a rich, extensible, and scalable directory service whose namespace
is built on the DNS standard. The Active Directory is built on a TCP/IP network
and is designed to make network management and user resource usage easier and
less problematic. As you begin planning your Active Directory infrastructure, begin
by collecting data about your business and your network. With this data, you can
begin to create an Active Directory deployment that will meet your company’s busi-
ness plans and function in an appropriate manner on your physical network.
✦
✦
✦
Note
4
7
6
2
-
3

c
h
0
1
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

1
8
The Active
Directory
Namespace
In Chapter 1, you learned that the Active Directory must
be built on some specific technologies. For example, the
Active Directory must be built on a TCP/IP network, and
the Active Directory uses LDAP for database queries. You
were also introduced to the fact that the Active Directory is
built on the Domain Name System (DNS). In fact, DNS and the
Active Directory are completely tied together, and you cannot
even install the Active Directory without DNS. As a part of
the planning process, you must design the Active Directory
namespace before ever beginning an installation, and as you
can probably guess, that namespace must follow DNS. In this
chapter, I explore all you need to know about designing your
namespace and give you plenty of examples along the way.
What Is a Namespace?
A namespace is simply a word that describes an “area” that can
be resolved. It refers to a system of name resolution where a
single computer can be found due to the namespace pattern. If
you are new to the concept of namespace, it can be somewhat
confusing. The concept of namespace is often compared to a
telephone book or the U.S. mail system. For example, the U.S.
mail system is essentially a namespace because letters and
packages are addressed in a particular way in order to reach a
destination. For example, a letter always contains a person’s
name, address, city, state, and zip code. Using these namespace
components, a letter can be delivered to a single person in a
single place in the United States. By the information on the let-
ter, millions of people can be disregarded and the correct recip-
ient located (at least, we hope).
2
C H A P T E R
✦
✦
✦
✦
In This Chapter
Describing a
namespace
Exploring the
DNS hierarchy
Understanding the
Active Directory
namespace
Planning and
designing the forest
domain root
✦
✦
✦
✦
4
7
6
2
-
3

c
h
0
2
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

1
9
20
Part I ✦ Planning an Active Directory Deployment
The reason millions of people can be disregarded and the correct recipient located
is that the letter follows addressing rules for the namespace. If some letters con-
tained only a name and street address, or a name and a city or state, the postal
system would never be able to deliver mail because it would not follow a particular
namespace. In other words, the addressing information on the letter is resolvable
to a particular person residing in a particular place.
The Active Directory namespace is the same. Following the DNS namespace, Active
Directory names follow a particular namespace. This organized approach enables
a computer in one domain to locate and communicate with a computer in another
domain. The namespace enables one domain to be distinguished from another and
permits clients both within the domain and outside of the domain to have a unique
name that can be resolved. Just as a person has a unique postal address, domains
and computers in an Active Directory network all have a unique DNS name that
can be resolved.
Exploring the DNS Namespace
In order to fully understand the Active Directory namespace and begin planning
your own Active Directory domain name, you first must take a look at the DNS
hierarchy. The Active Directory is built on DNS, and all Active Directory names
are DNS names — you cannot separate the two. Thus, once you understand the
DNS hierarchy, you’ll understand the Active Directory namespace hierarchy.
You should note that although the DNS namespace and the Active Directory
namespace are the same in terms of the hierarchy, they are not the same in terms
of management. DNS is used to manage the Internet while the Active Directory
using DNS is used to manage your private network. The two namespaces can
interconnect, however, so that you have both an Internet presence and a private
network.
As you learned in Chapter 1, DNS is a name system that enables domain names
to be resolved to a unique TCP/IP address. For example, www.idgbooks.com is
a domain name that can be resolved to an exact TCP/IP address assigned to IDG
Books. Each fully qualified domain on the Internet has a unique IP address. DNS’s
job is to resolve the friendly name, such as www.idgbooks.com, to a not-so-friendly
TCP/IP address, such as 131.107.2.200. Of course, you do not have to use a com-
puter’s domain name to communicate with it. You can bypass all of this resolution
trouble by just remembering and using the computer’s IP address. The problem
is simply that we are language-based creatures who do not remember strings of
numbers very well. In a large network or on the Internet, people would never be
able to remember computers and Web sites without DNS.
So now that you know the virtues of DNS, why did Microsoft choose to implement
DNS in Windows 2000? In previous versions of Windows and in Windows networking,
NetBIOS names were used with Windows Internet Name Service (WINS) to perform
the computer name–to–IP address resolution. What happened to WINS? Why DNS?
Note
4
7
6
2
-
3

c
h
0
2
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

2
0
21
Chapter 2 ✦ The Active Directory Namespace
There are a couple of reasons. First, NetBIOS works fine (although many administra-
tors will be more than happy to kiss it good-bye), but it doesn’t provide an organized,
network-wide approach to name resolution. WINS is not completely gone — yet. WINS
is supported in Windows 2000 for backward compatibility with downlevel Windows
computers, such as NT and 9x systems. However, Windows 2000 computers only
need DNS for name resolution. In a pure Windows 2000 network, you don’t need to
implement WINS at all, and you can expect WINS to die a slow death in the next sev-
eral years as NT and 9x clients are slowly retired to 2000 and beyond OS versions.
Microsoft chose DNS for a couple of important reasons, and I believe it was a wise
choice. First, DNS is an extensible name resolution method. This means that DNS
can be extended, or it can grow to meet the needs of your organization. If you have
a small network of 500 computers, DNS will work fine for you. If you have a network
of 10,000 computers, DNS will work just fine. What if you have a network of a million
computers? No problem — after all, DNS makes up the entire Internet. Because of
DNS’s extensibility, there is no concern about limiting your network’s size due to
naming limitations.
Another reason Microsoft chose to use DNS is because of its common use on the
Internet. Internet surfers use DNS all the time. They may not know it, but the system
is very familiar in today’s Internet age. Using DNS in private Active Directory net-
works makes the networks more familiar and more easily integrated with intranets
and the Internet. For example, triton.com can be both an Internet web site and the
name of a local network. Peggy_anderson@triton.com can be both an Internet e-mail
address and a user name on the private network. This integration makes remember-
ing information easier and begins to blur lines between traditional networks, the
Internet, and e-commerce.
With all that said, then, you now understand that the Active Directory is built on
the DNS namespace hierarchy. In order to build your own implementation, first
consider how the DNS hierarchy works. The DNS hierarchy can be thought of as
an upside-down tree structure. A DNS name is resolved from the root down through
the branches of the tree structure until the actual host computer is located.
Returning to the postal example, suppose that John Smith has the following address:
John Smith
110 Apple Bird Lane
Anycity, Texas 75000
In order to resolve the postal address so that a letter actually reaches John Smith,
the postal service works the address in reverse order. In other words, they begin at
the root of the address in order to resolve it. Using the zip code and state, all other
49 states can be automatically ruled out. So far, the letter has been resolved from the
entire United States to Texas. Next, the address is resolved further by locating the
specific city, Anytown. Now the address has been further resolved from the entire
state to only one city. Once the letter reaches the city, a postal carrier resolves
Apple Bird Lane in order to rule out all other streets and then resolves 110 in order
4
7
6
2
-
3

c
h
0
2
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

2
1
22
Part I ✦ Planning an Active Directory Deployment
to rule out all other houses on that street. The postal carrier compares the street
address with the owner, John Smith, to verify accurate delivery.
DNS resolves domain names in much the same way. Because a DNS address is
made up of resolvable domain names, each domain can be resolved until the
actual computer host is finally reached. The domains are as follows:
✦ Root domain — The very top of the inverted domain tree. The root domain
is represented by a period. “.”
✦ First-level domains — First-level domains, owned by the InterNIC, are major
divisions of addresses. The following are common first-level domains:
• com — stands for commercial
• net — stands for network
• edu — stands for education
• gov — stands for government
• mil — stands for military
• org — stands for nonprofit organizations
✦ Second-level domains — Second-level domains represent private businesses,
organizations, or groups. For example, microsoft, idgbooks, amazon, msn,
yahoo, and so on, are all second-level domains.
✦ Third-level domains — Third-level domains can be a type of service, such
as www or ftp, or they can further subdivide the second-level domain,
such as acct.idgbooks.com.
✦ Child domains — You can have any additional domains beyond the third-level
domain. These are called child domains and are further used to subdivide
other domains. For example, in acct.corp.namerica.idgbooks.com, acct and
corp would be considered child domains.
Beyond the final domain is the actual server or computer for which the address
belongs. The full DNS address ending at a particular server or computer is called
a Fully Qualified Domain Name (FQDN). As you can see in Figure 2-1, the DNS
hierarchy begins at the root and branches from the root.
When DNS needs to resolve a name, it begins with the Internet root and works
it way through each domain until it reaches the final leaf or end node, which is a
computer. The computer can then answer the resolution with its IP address so
that the FQDN is resolved to a single IP address.
You can learn more about the DNS resolution process in Chapter 18.
Cross-
Reference
4
7
6
2
-
3

c
h
0
2
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

2
2
23
Chapter 2 ✦ The Active Directory Namespace
Figure 2-1: DNS hierarchy
Internet
root
"."
First-level domains
gov
org
com
net
Second-level domains
Third-level domains (additional child
domains possible)
amazon
yahoo
idgbooks
microsoft
production
sales
Host Computers
4
7
6
2
-
3

c
h
0
2
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

2
3
24
Part I ✦ Planning an Active Directory Deployment
Issues with DNS Planning
Chapter 18 explores DNS implementation, how to install it, and how to set it up on
a Windows 2000 Server in great detail. However, while discussing the topic of name-
space planning, it is a good time to mention DNS requirements. In an Active Directory
implementation, as you have learned, DNS is required. The Active Directory naming
structure is built on DNS, and the Active Directory simply will not work without DNS.
In fact, when you install the Active Directory, the Active Directory Installation Wizard
will search for a DNS server. If it does not find one, the wizard will prompt you to
allow it to install DNS with the Active Directory. You can think of the Active Directory
as interconnected and interdependent with the DNS.
You can find step-by-step installation information on DNS in Chapters 6 and 7.
So, when you are planning your Active Directory implementation, you need to
stop and take a serious look at DNS. If you do not have a DNS implementation, your
best approach is to use Microsoft DNS that installs automatically with the Active
Directory. (DNS is a service that can be installed from your Windows 2000 CD-ROM
like any other service.) This ensures complete compatibility and will avoid a world
of problems. However, you may already have a DNS implementation in your network.
You may have already spent a lot of money and configuration time on your imple-
mentation, and it may not be Microsoft DNS. Now what can you do?
The Active Directory does not require that you implement Microsoft DNS, but it does
require a DNS implementation that supports certain DNS features. If you have an
existing DNS infrastructure and you want to keep it, then you need to spend some
serious time investigating and testing that infrastructure to ensure compatibility
with the Active Directory. There are some specific issues you should pay close
attention to, and these are explored in the following sections.
Service Location Records
Service Location Records (SRV) are DNS resource records that map Windows 2000
servers that run the DNS service. Each server maintains a list of SRV records for the
domain or zone in which the server resides. SRV records are used to find domain
controllers, and they can be used in several ways. For example, if you want several
servers to respond to a single domain name, you can use SRV records to configure
this option. When client computers need to contact a domain controller, they do so
through LDAP, which accesses the SRV record. In short, SRV records are required for
an Active Directory implementation. If your current DNS implementation does not
support SRV, you are going to have to upgrade to a version that does. Microsoft DNS
supports SRV (naturally) and BIND 8.1.1 and higher also support SRV records. If you
do not have these versions, you can delegate child domains to a DNS server that
does support SRV. However, this solution is likely to cause you more headaches and
poor performance. My best advice is to upgrade to a version of BIND that supports
SRV, or preferably, to Microsoft DNS.
Cross-
Reference
4
7
6
2
-
3

c
h
0
2
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

2
4
25
Chapter 2 ✦ The Active Directory Namespace
Dynamic Update Protocol
Dynamic Update Protocol (RFC 2136) enables the DNS server to dynamically
update its records when the DNS name–to–IP address mappings change. This may
not sound like much, but before RFC 2136, DNS was a static database that had to be
manually updated by an administrator. Dynamic Update Protocol enables the DNS
server to automatically update its database when it is notified of DNS name–to–IP
address mapping changes (such as in the case of a new DHCP lease). RFC 2136
was a much needed improvement and helps administrators keep their hands off
DNS HOSTS file manual configuration. Technically, the support of Dynamic Update
Protocol is not required for an Active Directory implementation, but considering
that your computer names are DNS names and that IP addresses can regularly
change when DHCP is used, Dynamic Update is required for all practical purposes.
Microsoft DNS supports Dynamic Update Protocol as does BIND 8.1.1 and higher.
Before Dynamic Update Protocol, DNS was a static creature. DNS host names–to–IP
address mappings were kept in a static text file called a HOSTS file. If a DNS host
name–to–IP address mapping changed, an administrator had to open the text
file and manually make the change. As you can imagine, this would be an impossi-
ble administrative feat in the Active Directory. Dynamic Update Protocol enables
DNS host–to–IP mappings to be dynamic— they can automatically be updated as
mappings are updated.
DHCP updates
In conjunction with the Dynamic Update Protocol, the Windows 2000 version of
DHCP is designed to provide DNS with name–to–IP address mapping changes.
As you can imagine, without this dynamic update feature, the DNS database would
quickly become a hopeless mess of incorrect name–to–IP mappings. Not to sound
like a commercial, but if you implement Microsoft DNS, you can be assured of
compatibility between DHCP and DNS. If you use BIND or another DNS service,
you should perform some testing to make certain that your DNS servers can
receive dynamic updates from DHCP.
Incremental zone transfers
You can refer to Chapter 18 to learn more about DNS zones, but for now, let me just
say that a zone is a contiguous portion of the DNS namespace that is segmented for
management purposes. Within that zone, there is a primary DNS server that holds
the primary zone database file. All other servers are provided for load balancing and
contain a copy of the primary zone database file called the secondary zone database
file. The primary zone database file is the only writable version, so all updates are
made to the primary zone database file and replicated to the secondary zone
database files through a process called zone transfer. Incremental zone transfers
(RFC 1995) enable only the portions of the database that have changed to be sent
to the secondary zone servers instead of the entire database. This feature, though
not at all a requirement, you should consider important because it will help reduce
network traffic.
Note
4
7
6
2
-
3

c
h
0
2
.
f
.
q
c


1
0
/
2
5
/
0
0


2
:
4
2

P
M


P
a
g
e

2
5