Windows .

NET Server 2003 Domains &

Active Directory
Alex Tchekmarev

A-List

Copyright © 2003 A-LIST, LLC

All rights reserved.

No part of this publication may be reproduced in any way, stored in a retrieval system
of any type, or transmitted by any means or media, electronic or mechanical,
including, but not limited to, photocopy, recording, or scanning, without prior
permission in writing from the publisher.

A-LIST, LLC
295 East Swedesford Rd.
PMB #285
Wayne, PA 19087
702-977-5377 (FAX)
mail@alistpublishing.com
http://www.alistpublishing.com

All brand names and product names mentioned in this book are trademarks or
service marks of their respective companies. Any omission or misuse (of any kind) of
service marks or trademarks should not be regarded as intent to infringe on the
property of others. The publisher recognizes and respects all marks used by
companies, manufacturers, and developers as a means to distinguish their products.

Windows .NET Server 2003 Domains & Active Directory

By Alex Tchekmarev

1-931769-00-1

03 04 7 6 5 4 3 2 1
A-LIST, LLC titles are distributed by Independent Publishers Group and are available
for site license or bulk purchase by institutions, user groups, corporations, etc.

Book Editor: Rizwati Freeman

LIMITED WARRANTY AND DISCLAIMER OF LIABILITY

A-LIST, LLC., INDEPENDENT PUBLISHERS GROUP, AND/OR ANYONE WHO

HAS BEEN INVOLVED IN THE WRITING, CREATION, OR PRODUCTION OF THE
ACCOMPANYING CODE ("THE SOFTWARE") OR TEXTUAL MATERIAL IN THE
BOOK, CANNOT AND DO NOT WARRANT THE PERFORMANCE OR RESULTS
THAT MAY BE OBTAINED BY USING THE CODE OR CONTENTS OF THE BOOK.
THE AUTHORS AND PUBLISHERS HAVE USED THEIR BEST EFFORTS TO
ENSURE THE ACCURACY AND FUNCTIONALITY OF THE TEXTUAL MATERIAL
AND PROGRAMS CONTAINED HEREIN; WE HOWEVER MAKE NO WARRANTY
OF ANY KIND, EXPRESSED OR IMPLIED, REGARDING THE PERFORMANCE OF
THESE PROGRAMS OR CONTENTS.

THE AUTHORS, THE PUBLISHER, DEVELOPERS OF THIRD PARTY

SOFTWARE, AND ANYONE INVOLVED IN THE PRODUCTION AND
MANUFACTURING OF THIS WORK SHALL NOT BE LIABLE FOR DAMAGES OF
ANY KIND ARISING OUT OF THE USE OF (OR THE INABILITY TO USE) THE
PROGRAMS, SOURCE CODE, OR TEXTUAL MATERIAL CONTAINED IN THIS
PUBLICATION. THIS INCLUDES, BUT IS NOT LIMITED TO, LOSS OF REVENUE
OR PROFIT, OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OF THE PRODUCT.

THE USE OF "IMPLIED WARRANTY" AND CERTAIN "EXCLUSIONS" VARY FROM

STATE TO STATE, AND MAY NOT APPLY TO THE PURCHASER OF THIS
PRODUCT.

Introduction
This book is based on Windows 2000 Domain & Active Directory published in March
2001. It has been totally revised and adapted to conform to the Windows .NET
Server 2003 environment and over 100 pages have been added. (From now on, all
products of the Windows .NET Server 2003 family will be referred to as Windows
.NET for short.) As a result, this book will be useful for those administrators who
currently work with Windows 2000 domains and for those who are planning to deploy
Active Directory on Windows .NET servers. For an administrator, the new version of
Active Directory does not have any new principle features, and all options that are
only available on Windows .NET servers are specifically described in the book.
Therefore, an administrator can deal with any version of Active Directory domains
and compare the working environment's features with those that were on the old
platform.

Many books have already been published which cover Active Directory's goals, its
advantages and disadvantages, strategies for developing Active Directory in a large
corporate network, and other important questions that have not changed with the
advent of Windows .NET. (However, this does not mean that the new version of
Active Directory is not more mature, effective, and convenient for administrators than
the initial version that appeared in Windows 2000!) In this book, the author has tried
to take a look at the more practical problems that come up while using Active
Directory. Even though the book may not offer an answer to all the problems that
might arise, you will at least learn how to approach them.

One probably would not even consider repairing a defective car or a complex
electronic device without special additional tools and facilities. Nonetheless,
administrators who work with Active Directory often forget that the problems which
come up in the process of working with Active Directory are also impossible to
eliminate without the help of the appropriate tools and utilities. Most of the tools that
you need for working with Active Directory (and that are looked at in this book) are
furnished along with the system, and are found in the Windows Support Tools pack.
This book is dedicated, to a large extent, to working with exactly these tools. A few
tools and scripts from the Windows 2000 Server Resource Kit are also considered,
since they work properly in the Windows .NET environment.

Besides, the author would like to turn administrators' attention to methods of program
access to Active Directory, and in part to scripts that use the Active Directory Service
Interfaces (ADSI). Scripts can be used to solve many administrative tasks, and you
may use already written scripts after a minimal number of modifications to fit your
needs. Creating scripts does not require you to be a highly qualified programmer — a
fact which the author tried to get across in the last two chapters of the book.

This book is geared towards a relatively prepared reader, one who has already had
some experience working with Windows 2000, and is familiar with the basic work
methods and components of the system (e.g., with Microsoft Management Console
snap-ins). However, information on these questions can easily be found in the Help
system.

Below is a summary of each chapter.

Part I: Active Directory Fundamentals and Standards

ƒ Chapter 1, "LDAP Basics," covers one of the standards that make up the basis
of Active Directory — the Lightweight Directory Access Protocol (LDAP).
ƒ In Chapter 2, "Active Directory Terminology and Concepts," relates the
essential Active Directory concepts. The terms and concepts described in
Chapter 1 and in this chapter will be widely used in the rest of this book;
therefore, their knowledge will affect how the reader understands Active
Directory operating mechanisms and topics described later in the other
chapters. New Active Directory features offered by domain controllers running
Windows .NET are also reviewed.
ƒ Chapter 3, "Domain Name System (DNS) as Main Naming Service,"
comprises Active Directory requirements of mandatory DNS service, as well
as new DNS features introduced in Windows .NET.

Part II: Deploying Active Directory Domains

ƒ In Chapter 4, "Windows .NET DNS Server," the essential operations of

installing, configuring, and verifying Windows 2000/.NET DNS Servers are
considered. An example of interoperation between Active Directory and a
legacy DNS infrastructure is discussed.
ƒ Chapter 5, "Installing Active Directory," tells you what you need to pay
attention to before and during installation of Active Directory. Certain typical
problems that you may encounter when deploying Active Directory forests (on
Windows 2000 and Windows .NET domain controllers) are also examined.
ƒ Chapter 6, "Configuring and Troubleshooting Active Directory Domains," gives
recommendations that you need to consider when deploying and
troubleshooting Active Directory domains.
Part III: Administering Active Directory

ƒ In Chapter 7, "Domain Manipulation Tools," we will look at all standard snap-

ins intended for administering Active Directory. To use them effectively
(especially in the new, Windows .NET Server 2003, environment), the
administrator must be aware of certain features and methods of working with
them.
ƒ In Chapter 8, "Common Administrative Tasks," we will examine both typical
administrative tasks — like working with user and network resources — and
tasks specific to Active Directory domains, like delegating administrative
control, managing FSMO roles, refreshing group policies, searching and
recovering Active Directory, and others.

Part IV: Using System Utilities and Support Tools

ƒ The main task of Chapter 9, "General Characteristics and Purpose of System

Tools," is to give the administrator an idea of what a certain utility is used for,
and to help in choosing the tool to use for a specific task.
ƒ Described in Chapter 10, "Diagnosing and Maintaining Domain Controllers,"
are utilities that allow you to determine the health of a single domain controller
and the integrity of the Active Directory database replica stored on it.
ƒ Chapter 11, "Verifying Network and Distributed Services," covers the utilities
that allow you to diagnose problems that arise due to the fact that Active
Directory is a distributed network database, that is, problems of connectivity
between domain controllers, authentication, and replication.
ƒ Chapter 12, "Manipulating Active Directory Objects," looks at the utilities used
for work with Active Directory logical objects — tools for searching directory for
objects of various types and editing their attributes, utilities for exporting and
importing objects, and tools used for manipulating workstations, domain
controllers and trust relationships.
ƒ In Chapter 13, "Migration and Directory Reorganization Tools," those utilities
intended for reorganizing domain trees and migration of objects between
forests are examined.
ƒ The tools that allow you to view and manage access permissions on Active
Directory objects are looked at in Chapter 14, "Security Tools".
ƒ Chapter 15, "Group Policy Tools" offers an examination of those utilities that
allow you to test Group Policy Objects (GPOs) and determine the resulting
security settings defined by group policies.

Part V: Program Access to Active Directory

ƒ Chapter 16, "Active Directory Service Interfaces (ADSI)," will acquaint

administrators with ways to manage Active Directory programmatically. The
difficult thing about working with the documentation on ADSI is that it is tough
for a novice to find what he/she needs in the midst of such a huge amount of
unfamiliar information. This chapter gives the reader an understanding of the
basic concepts, which will be illustrated in the following chapter with examples.
ƒ Chapter 17, "Scripting Administrative Tasks," consists almost completely of
program examples. It seems to me that the principles of programming with
ADSI are easier to master when you have a specially designed example with
 commentary. After having understood these basic concepts, it will be much
easier to work with documentation that describes in detail all of the interfaces
and their methods and properties.

Part VI: Appendixes

ƒ The Appendixes include "must-see" and simply useful references to web

resources; a list of registry keys and directory objects that allow you to "fine
tune" Active Directory or manage its internal mechanisms; a table of ADSI
interfaces supported by the main system providers and a list of all the
functions implemented by the IADsTools ActiveX object, which are useful for
developing administrative scripts.

The Glossary will help you find a short description of an unfamiliar term quickly, or to
verify your understanding of this term.

The "How to …?" section is set up like a typical FAQ. In this section, you may find the
solution you need for a specific problem faster than if you were to simply look through
the table of contents or the Index.

For finding references to a certain utility or tool in the Index, use its file name. You
can also find references to interfaces, methods, properties, attributes, enumerations,
etc., the same way — under their names.

The author can be reached at ATchekmarev@msn.com. The listings included in this

book can be found at http://www.alistpublishing.com.

Conventions

Here are the conventions used in the book:

ƒ Names of administrative snap-ins and UI elements (such as menu,

commands, pop-up windows, etc.) are in bold, for example, "the Active
Directory Users and Computers snap-in" or "the Delegate Control
command on the Action menu".
ƒ Names of Active Directory object attributes, ASDI interfaces, methods, and
properties, are shown in italics, for example, objectSid.
ƒ Certain important words or new terms are also marked in italics.
ƒ If a long command or string displayed on the screen does not fit on one line in
the book, the $$ symbol will be used. For example:
ƒ createusers LDAP://OU=Staff, DC=w2k, DC=dom cn: "User User01"
ƒ samAccountName: user-ldap01 password:psw1

This means that the line shown should be considered as one, unbreakable
line.

ƒ As you can see from the previous example, the mandatory elements of a
command line — the command name and the parameters — are in bold in
order to be more visible. The other elements of the command are specific to
your environment and you should determine them.
Part I: Active Directory Fundamentals
and Standards
Chapter 1: LDAP Basics
Chapter 2: Active Directory Terminology and Concepts
Chapter 3: Domain Name System (DNS) as Main Naming Service

Chapter 1: LDAP Basics

The purpose, advantages, organization, and role of Active Directory for Windows
2000-based domains have already been described extensively in many books and
articles. If you are not familiar with Active Directory basics at this point,
comprehensive information on it can be easily found. The Windows .NET version of
Active Directory is a rather evolutionary step in the architecture of Windows domains.
(The Windows 2000 version of Active Directory was, indeed, a revolution if one
compares it with "flat" NT Directory Service (NTDS) domains.) Therefore, an
administrator deploying Active Directory on computers running Windows .NET will
face the same problems that are peculiar to the Active Directory in general. In
addition, most requirements for installing Active Directory and the methods of
administering the Windows .NET-based domains have not been changed in the new
version of Active Directory.

There are two Internet standards that appeared long before Active Directory, but
which are very closely related to it. These standards are Lightweight Directory
Access Protocol (LDAP v3) and Domain Name System (DNS). It is impossible to
speak about Active Directory without using the terms stated by these standards. That
is why in the first three chapters of the book, we will discuss the terminology and
concepts that are widely used in the remaining chapters.

LDAP as a Cornerstone of Active Directory

Use of the Active Directory service (both on Windows 2000 and Windows .NET
operating systems) requires a good understanding of the LDAP protocol basics since
this protocol is used everywhere for accessing directory information. Familiarity with
and knowledge of LDAP are also necessary for working with many tools and utilities,
such as the Active Directory Administrative Tool (Ldp.exe), ADSI Edit snap-in,
Search.vbs script, LDIF Directory Exchange utility (LDIFDE.exe), and others, and are
needed for scripting as well. This concerns all four LDAP models discussed below.
Therefore, before we begin to discuss the Active Directory installation, administrative
snap-ins, system tools, and other topics, let us first review the LDAP concepts. Then,
some Active Directory specific terms and technologies will be considered in the next
chapter.

Note All main features of LDAP v3 are described in RFC 2251 through RFC 2256.
Refer to these RFCs for more information, or check out the Q221606 article in
the Microsoft Knowledge Base. You may also find links to other related
standards there.
Informational Model

The informational (data) model of the LDAP protocol, and therefore, of Active
Directory as well, is based on X.500 — the International Standards Organization
(ISO) special standard defining elements of a distributed directory service. This
standard proposes an object-oriented data model; therefore, it uses such terms as
class, instance, and inheritance.

Schema

The schema defines classes and attributes, from which all directory objects can be
derived. The schema itself is stored in the directory as a set of objects.

Directory Entry (Object)

Entry is an instance of a specific structural class and in Active Directory is usually

called an object. An object can either be a container or a leaf. It is uniquely identified
by its relative distinguished name (RDN) and distinguished name (DN).

Classes

Each directory object is an instance of one or more classes defined in the schema. In
general, every object inherits from at least one structural object class and zero or
more auxiliary object classes. There are three types of classes:

ƒ Abstract classes serve as templates for deriving new abstract, auxiliary, and
structural classes. Abstract classes cannot be instantiated in Active Directory,
i.e., you cannot create a directory object of an abstract class. The definition of
an abstract class can include any number of auxiliary classes.
ƒ Structural classes are derived from abstract or structural classes and inherit all
attributes of all parent classes. Active Directory objects can only be instances
of structural classes. The definition of a structural class can include any
number of auxiliary classes.
ƒ An auxiliary class is derived from an abstract or auxiliary class and can be
included in the definition of a structural, abstract, or auxiliary class. The
defined class inherits all attributes of the auxiliary class listed in the
mustContain, systemMustContain, may Contain, and systemMayContain
properties. Auxiliary classes cannot be instantiated in Active Directory. The
definition of an auxiliary class can include any number of auxiliary classes.

Attributes

Attributes contain the data used to describe properties of the defined classes.
Attributes may be mandatory or optional, single- or multi-valued. An attribute is
defined in the schema by a name and an object identifier (OID). Attributes are
defined in RFC 2252 and RFC 2256. Here are the examples of attributes (these are
the values of the lDAPDisplayName and attributeID attributes of the attributeSchema
objects in the Schema container):

ƒ nTSecurityDescriptor (1.2.840.113556.1.2.281)
 ƒ distinguishedName (2.5.4.49)

Attribute Syntax

The attribute syntax (see RFC 2252) defines the type of an attribute (e.g., a Unicode
string, a number, an octet string, etc.), byte ordering, and the matching rules for
comparisons of property types. The syntax of LDAP attributes is represented by
object identifier (OID). For example:

ƒ Distinguished Name (1.3.6.1.4.1.1466.115.121.1.12)

ƒ UTC time (1.3.6.1.4.1.1466.115.121.1.53)

RootDSE Object

Every LDAP v3-complaint server has an individual DSA-Specific Entry object —

RootDSE — defined in RFC 2251. This object is the root of the Directory Information
Tree (DIT), but is not a part of any naming context (partition). It defines a directory
server's configuration and capabilities.

Note Directory System Agent (DSA) is the system process that provides clients with
access to directory information physically stored on a hard disk of a domain
controller, or directory server. In Active Directory servers running on Windows
2000 or Windows .NET, the DSA is a part of the Local System Authority (LSA)
subsystem.

RootDSE has properties that can be retrieved programmatically (see Listing 17.2) or
by using a query tool (such as Ldp.exe or the ADSI Edit snap-in). To query a
RootDSE from Ldp.exe, specify the empty base DN, the base scope, and the filter
objectClass=*. (Search operations will be considered a bit later.) It is possible to bind to
a specific server, or to use a server-less query. In the latter case, the first available
LDAP server (a Windows 2000-or Windows .NET-based domain controller) will
respond. Here is an example of the RootDSE data:

1> currentTime: 6/12/2002 9:29:2 Central Standard Time Central Standard Time;
1> subschemaSubentry:
CN=Aggregate, CN=Schema, CN=Configuration, DC=net, DC=dom;
1> dsServiceName: CN=NTDS Settings, CN=NETDC2, CN=Servers, CN=NET-Site, CN=Sites,
CN=Configuration, DC=net, DC=dom;
5> namingContexts: CN=Configuration, DC=net, DC=dom;
CN=Schema, CN=Configuration, DC=net, DC=dom; DC=subdom, DC=net, DC=dom;
DC=DomainDnsZones, DC=net, DC=dom; DC=ForestDnsZones, DC=net, DC=dom;
1>defaultNamingContext: DC=subdom, DC=net, DC=dom;
1> schemaNamingContext: CN=Schema, CN=Configuration, DC=net, DC=dom;
1> configurationNamingContext: CN=Configuration, DC=net, DC=dom;
1> rootDomainNamingContext: DC=net, DC=dom;
20> supportedControl: 1.2.840.113556.1.4.319; 1.2.840.113556.1.4.801;
1.2.840.113556.1.4.473; 1.2.840.113556.1.4.528; 1.2.840.113556.1.4.417;
1.2.840.113556.1.4.619; 1.2.840.113556.1.4.841; 1.2.840.113556.1.4.529;
1.2.840.113556.1.4.805; 1.2.840.113556.1.4.521; 1.2.840.113556.1.4.970;
1.2.840.113556.1.4.1338; 1.2.840.113556.1.4.474; 1.2.840.113556.1.4.1339;
1.2.840.113556.1.4.1340; 1.2.840.113556.1.4.1413; 2.16.840.1.113730.3.4.9;
2.16.840.1.113730.3.4.10; 1.2.840.113556.1.4.1504; 1.2.840.113556.1.4.802;
2> supportedLDAPVersion: 3; 2;
 11> supportedLDAPPolicies: MaxPoolThreads; MaxDatagramRecv;
MaxReceiveBuffer; InitRecvTimeout; MaxConnections; MaxConnIdleTime;
MaxPageSize; MaxQueryDuration; MaxTempTableSize; MaxResultSetSize;
MaxNotificationPerConn;
1> highestComittedUSN: 124992;
4> supportedSASLMechanisms: GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5;
1> dnsHostName: netdc2.subdom.net.dom;
1> ldapServiceName: net.dom:netdc2$@SUBDOM.NET.DOM;
1> serverName: CN=NETDC2, CN=Servers, CN=NET-Site,
CN=Sites, CN=Configuration, DC=net, DC=dom;
3> supportedCapabilities: 1.2.840.113556.1.4.800;
1.2.840.113556.1.4.1670; 1.2.840.113556.1.4.1791;
1> isSynchronized: TRUE;
1> isGlobalCatalogReady: TRUE;
1> domainFunctionality: 2;
1> forestFunctionality: 2;
1> domainControllerFunctionality: 2;

(Notice the numbers at the beginning of the lines — they indicate the number of
values within an attribute.)

RootDSE contains the following standard attributes (refer to RFC 2251 and 2252):

ƒ altServer — references to other servers that can be used when this server
becomes unavailable. By default, this attribute is absent on Active Directory
servers.
ƒ namingContexts — the list of naming contexts stored on the server. Notice that in
our example, the domain naming context (directory partition) refers to the
subdom.net.dom domain, but two other contexts, the Schema and
Configuration, refer to the forest root domain — net.dom. These contexts
should be used when searching the directory. Windows .NET-based domain
controllers can also store application directory partitions, and this attribute lists
their names, too. In the example, you can see the distinguished names of two
application partitions: domainDnsZones.net.dom and
forestDnsZones.net.dom.
ƒ subschemaSubentry — the name of the subschema entry (or the abstract
schema; see Chapter 16, "Active Directory Service Interfaces (ADSI)"). This
object contains definitions of available attributes and classes.
ƒ supportedControl — the object identifiers (OID) of the LDAP controls that the
server supports. This attribute may be absent. In comparison with Windows
2000, Windows .NET-based domain controllers support four new controls.
ƒ supportedExtension — the object identifiers (OIDs) of the extended LDAP
operations that the server supports. By default, this attribute is absent on
Active Directory servers.
ƒ supportedLDAPVersion — the LDAP versions supported by the server.
ƒ supportedSASLMechanisms — the Simple Authentication and Security Layer
(SASL) mechanisms supported by the server. This attribute may be absent. In
comparison with Windows 2000, Windows .NET-based domain controllers
support two new controls.

In addition, Active Directory supports the following attributes:

ƒ configurationNamingContext — the Configuration context.

 ƒ currentTime — the current time.
ƒ defaultNamingContext — the default context for the server. By default, this is the
distinguished name of the domain where the server is located.
ƒ dnsHostName — the server's DNS name.
ƒ dsServiceName — the name of the directory service (NTDS).
ƒ highestCommittedUSN — the highest USN committed to the database on this
server.
ƒ ldapServiceName — the Service Principal Name (SPN) for the server; used for
mutual authentication.
ƒ rootDomainNamingContext — the name of the forest where the server is located.
ƒ schemaNamingContext — the Schema context.
ƒ serverName — the distinguished name of the server object.
ƒ supportedCapabilities — the object identifiers (OID) of the capabilities that the
server supports. In comparison with Windows 2000, Windows .NET-based
domain controllers support two new capabilities.
ƒ supportedLDAPPolicies — supported LDAP management policies.

There are also two important operational attributes:

ƒ isSynchronized — TRUE, if initial synchronization of this Active Directory replica

with its partners has been completed (i.e., a newly promoted server can
advertise itself as a domain controller).
ƒ isGlobalCatalogReady — TRUE, if the domain controller has not simply been
promoted to be a Global Catalog (GC) server, but has already advertised itself
as a GC server.

Windows .NET-based domain controllers support three additional operational

attributes, which represent domain and forest functional levels (see the next chapter
for details):

ƒ domainFunctionality — either 0 (both Windows 2000 mixed and Windows 2000

native levels) or 2 (Windows .NET level).
ƒ forestFunctionality — either 0 (Windows 2000 level) or 2 (Windows .NET level).
ƒ domainControllerFunctionality — is equal to 2 for any Windows .NET-based domain
controller.

Naming Model

The naming model defines how directory objects can be uniquely specified. The OSI
directory model uses distinguished names for that purpose.

Distinguished Name (DN)

A distinguished name is unique within a forest or Directory Information Tree (DIT)

that it is placed in, and serves as a primary key for a directory object. DN consists of
relative distinguished names (RDN), which represent branches in the directory
information tree.

Here is an example of an object's distinguished name (CN stands for Common

Name, OU means Organizational Unit, and DC means Domain Component):
CN=John Smith,OU=Staff,DC=net,DC=dom

Relative Distinguished Name (RDN)

A relative distinguished name uniquely identifies objects in a container. The RDNs

consist of an attribute naming specifier (DC, CN, and OU; other specifiers are not
usually used in Active Directory) and a value, for example:

ƒ CN=Domain Controllers
ƒ OU=Staff
ƒ DC=net

Other Name Types Used in Active Directory

ƒ SAM (Pre-Windows 2000) Account Names. SAM account names are required
for compatibility with down-level clients. A SAM name must be unique within a
domain.
ƒ Globally Unique Identifiers – the Globally Unique Identifier (GUID) is a 128-bit
number, which uniquely identifies the object when it is created. It never
changes and ensures that the object will be addressed — even if it has been
renamed or moved.
ƒ Fully Qualified Domain Name (FQDN) is also known as the full computer
name; this is a concatenation of the host name (the NetBIOS name) and the
primary DNS suffix, for example:
ƒ netdc2.subdom.net.dom
ƒ User Principal Names – the User Principal Name (UPN) consists of the user
logon name and a UPN suffix (the current or root DNS domain name, or a
specially created shortened name), for example, JohnS@net or John@net.dom.
UPN is intended for simplified logon and can be used for logging on to the
network on a computer that can belong to any domain within the forest.
ƒ LDAP Uniform Resource Locator (URL). LDAP URLs are used by LDAP-
enabled clients for accessing Active Directory objects. LDAP URLs can also
be used as binding strings in scripts and applications, for example (the server
name is optional):
ƒ LDAP://netdc4.net.dom/CN=John Smith,OU=Staff,DC=net,DC=dom
ƒ Active Directory Canonical Name. Canonical names are used in the
administrative snap-in's user interface for displaying object names. A
canonical name is similar to the distinguished name without the naming
attribute specifiers (DC, CN, etc.). For example, the canonical name for the
LDAP URL shown above is:
ƒ net.dom/Staff/John Smith

Referrals

In a multi-domain forest, complete directory information is not available on a single

domain controller (DC). (You can only obtain a subset of attributes of all objects from
a Global Catalog server.) You need to have a mechanism that will redirect the query
from a DC to the DC that stores the requested object. This mechanism may also be
required if the object is located in another naming partition on the same server (for
example, if you specify the domain naming context as the search base and want to
find objects that can be stored in either Schema or Configuration partitions).
To inform a client that the server does not have a copy of the requested object, the
requested server uses an LDAP referral in accordance with RFC 2251. Ideally, the
referral indicates the DC that stores the necessary object. The server can generate
referrals to other DCs according to the cross-reference objects stored in the directory.
Cross-references give every DC the opportunity to be aware of all directory partitions
in the forest. The references are stored in the Configuration container, and are
therefore replicated to every DC in the forest. Hence, any DC can generate referrals
to any other domain in the forest, as well as to the Schema and Configuration
partitions. Cross-references can be created either automatically or manually by an
administrator.

Functional Model

The functional model describes the operations that can be conducted with
information stored in a directory using the LDAP protocol. You need to be able to
access information, and read and update it as well. These operations are
implemented in somewhat different ways for various system tools that use the LDAP
protocol, but the main concepts and parameters remain the same.

Authentication

Authentication operations allow a user to establish a connection with a Directory

System Agent (DSA) and to get the right to access the stored information.

ƒ Open — this command creates and initializes a connection block, and then
opens a connection to the DSA.
ƒ Bind — this command initiates a protocol session to the DSA and
authenticates the client to the DSA.
ƒ Unbind — this command terminates a session, frees all resources associated
with the session, and closes a connection.

Interrogation

Interrogation methods describe ways of retrieving information.

Search

The widely used search operations retrieve information based on user criteria.
Search operations have the following parameters:

ƒ Search base — the distinguished name of a directory object (called the base
object) from which the search begins (e.g., DC=net, DC=dom or OU=Stuff, DC=net,
DC=dom).

Note All search parameters are mandatory. Many LDAP-compatible tools and
utilities, such as DsQuery, LDIFDE, Search.vbs, and so on, do not
require that users specify some parameters. However, this only means
that these tools themselves substitute some default values instead of the
missed parameters.
Note The search base can also have the "<GUID=…>" format (the angle
 brackets are included!) (e.g., "<GUID=0855ae368790cb4b8726cf37cb2222a5>").

ƒ Search scope — defines the depth of searching relative to the search base
(Fig. 1.1 shows various scopes for the domain object). There are three
options:
ƒ Base. Only the base object is searched (i.e., you will work with properties of
the base object only).
ƒ One level. The children of the base object are searched; the base object itself
and grandchildren are excluded.
ƒ Subtree. The entire subtree is searched, beginning with and including the
base object (i.e., all "visible" objects in the subtree).
ƒ Filter. A rule (see RFC 2254) for selecting objects from a subtree (e.g., (cn=*)
or & (objectCategory=Person) (cn=d*) ).
ƒ Selection. A list of attributes returned from the selected objects that match the
filter.
ƒ Optional controls. LDAP functions that extend or modify a LDAP operation;
for example, you may ask the LDAP server to sort the results or return a large
result set in small pages. (See examples of using some LDAP controls in
Chapter 12, "Manipulating Active Directory Objects.")

Figure 1.1: Search scopes for a domain object (which is the search base)

Types of Filters

The following table shows a few examples of search filters:

Condition Filter

Equality match (sAMAccountName=jsmith)

Partial match (name=s*) or (name=*s*)
Comparing with a value (uSNChanged>=10000) or (CN<=Sales)
Presence of object (objectClass=*)
Logical AND of two conditions (users with names (& (objectClass=user) (cn>=h))
that begin with "H")
Logical OR of two conditions (objects with names (|(cn=a*) (cn=h*))
that begin with "A" OR "H")
Condition Filter

Logical NOT (all users with name that begin with (& (objectClass=user) (cn=a*) (!
"A" except "Administrators") (cn=adm*)))

Binary (attributes with syntax 2.5.4.1) (attributeSyntax=\32\2e\35\2e\34\2e\31)

Selection Options

Usually, you provide the list of object attributes returned by a query. There are,
however, a few special cases:

ƒ If you only need the objects' DNs rather than their attributes, specify OID 1.1
as the selection.
ƒ It is possible to specify the attribute OID instead of its name; for example, you
can replace objectClass with 2.5.4.0.

Example. Listing Attributes replicated to Global Catalog

As an example of a search operation, let us consider how to view all attributes

replicated to Global Catalog. You may use any search tool, such as the Search.vbs
script or the Ldp.exe utility. (For more information, see Chapter 12.) Here is a sample
command:

search "LDAP: //CN=Schema, CN=Configuration, DC=net, DC=dom"

/C:" (& (objectClass=attributeSchema)
(isMemberOfPartialAttributeSet=*))"
/P: ADsPath, attributeID, attributeSyntax, isSingleValued,
lDAPDisplayName, oMSyntax

The query produces a result similar to the following (only one entry from the list is
shown):

...
ADsPAth 140 = LDAP://CN=User-Principal-Name,CN=Schema,
CN=Configuration, DC=net, DC=dom
attributeID 140 = 1.2.840.113556.1.4.656
attributeSyntax 140 = 2.5.5.12
isSingleValued 140 = True
lDAPDisplayName 140 = userPrincipalName
oMSyntax 140 = 64
...

The same results can be obtained with the DsQuery utility:

C:\>dsquery * "CN=Schema, CN=Configuration, DC=net, DC=dom"

-filter
"(&(objectClass=attributeSchema) (isMemberOfPartialAttributeSet=*))"
-attr ADsPath attributeID attributeSyntax isSingleValued
lDAPDisplayName oMSyntax -1 -limit 1000 | more
Compare

The compare operation returns a Boolean result (TRUE or FALSE) based on the
comparison of an attribute value with a specified value.

Administrative Limits and Query Policy

The LDAP server resources, which are available to clients that make LDAP queries
and request paged or sorted result sets, are limited by the Default Query Policy.
Administrative limits constitute the query policy objects which are stored in the
container CN=Query-Policies,CN=Directory Service,CN=Windows NT,CN=Services
in the Configuration partition.

If there are no assigned policies, all domain controllers use the default query policy. A
site policy can also be assigned. However, if a specific policy has been assigned to a
domain controller, this policy overrides all others. There is no UI for assigning a policy
to a site. You can do this by manually editing the queryPolicyObject attribute of the
NTDS Site Settings object of the nTDSSiteSettings class object. Use the ADSI Edit
snap-in. It is also possible to use the ModifyLDAP.vbs script (see below).

Query policy applies to the following LDAP query-related operations:

ƒ Search. By default, you cannot obtain a result set whose size exceeds 1000
rows. You need to use a paged search to perform operations that generate a
significant amount of information. Also, you may exceed the default timeout
set for search operations.
ƒ Paged search. The client may ask the server to hold the result set and return
it in pages. In this case, the query policy defines the page size. (See also
comments to Listing 16.1.)
ƒ Search with Sorted Results. The requested result set can be sorted in a
particular order. This operation can significantly overload the LDAP server.
ƒ Search with Replication. The client can specify the maximum number of
attribute values that can be returned per request.
ƒ Change Notify. The client can request change notification in an asynchronous
LDAP query. The query policy can limit the number of simultaneous
asynchronous requests.

Tools for Manipulating LDAP Query Policies

There are two standard tools that allow you to work with LDAP query policies (see
Chapter 10, "Diagnosing and Maintaining Domain Controllers"):

ƒ The NTDSutil.exe tool. This tool can only be used with the Default Query
Policy object. It allows you to view or modify the query policy of a domain
controller.
ƒ The ModifyLDAP.vbs script from the Windows 2000 Server Resource Kit. This
script can create, delete, assign, or modify the query policy objects.
Update

The update operations perform modifications of the stored information.

ƒ Add allows user to create an object, which must meet the schema
requirements for the object class.
ƒ Modify creates, modifies, and deletes attributes of an object.
ƒ Modify RDN is actually an operation of renaming or moving an object to
another location.
ƒ Delete deletes an object (if it is possible and the user has the appropriate
rights to the object).

Security Model

To provide secure access to an LDAP server, the LDAP v.3 protocol allows the use
of Simple Authentication and Security Layer (SASL) mechanisms. Active Directory
confirms the LDAP v.3 requirements and, therefore, supports SASL mechanisms,
which include Kerberos version 5 and MS Negotiate (on Windows 2000). The
supported-SASLMechanisms attribute of the RootDSE object stored on every Active
Directory server (a domain controller running on Windows 2000 or Windows .NET)
contains two values: GSSAPI and GSS-SPNEGO. GSSAPI means Kerberos, and
GSS-SPNEGO stands for NT Negotiate (Kerberos, NT LAN Manager (NTLM), etc.).
Windows .NET-based domain controllers also support two other SASL mechanisms:
EXTERNAL and DIGEST-MD5.

LDAP Ports

The connections via the LDAP protocol between a client and DSA use either a
Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). The table
below lists the protocol sockets used in different access modes:

Function Port

LDAP 389
LDAP Secure Sockets Layer (SSL) 636
Global Catalog (GC) 3268
Global Catalog Secure Sockets Layer 3269

Chapter 2: Active Directory

Terminology and Concepts
This chapter relates to basic Active Directory elements, features, and requirements
that will be mentioned repeatedly in the other chapters of the book. You should have
a solid understanding of all these concepts and ideas before you go any further. If a
term is not clear to you, you can easily find detailed information in other sources. For
example, you can use the search function and quickly find an exhaustive description
of any term (including its relation to other Active Directory elements) in the Help and
Support Center. Thus, it is not necessary to place such information here.

Active Directory Essentials and Components

Let us first consider what essential information is necessary to comprehend in order

to deploy and manage both Windows 2000 and Windows .NET domains. (You may
skip this section, if you are familiar with Active Directory basics, and go to the new
features' description.) The Active Directory elements considered in this section will be
addressed later, in subsequent chapters. If you find that you are not completely
grasping the meaning of a particular word, just search for it in Help and Support
Center. (It would take up too much space to put everything here.)

Logical Organization

The Active Directory service is the foundation for domains managed by domain
controllers (that are also called Active Directory servers) running Windows 2000
or/and Windows .NET. A domain is a group of logically linked computers and users
who work on them and are united by an idea of centralized management.

All "housekeeping" tasks are performed on domain controllers that hold the Active
Directory database which contains information about managed objects such as
users, computers, groups, and so on. This information is stored as directory objects
of corresponding types. User, group, and computer (and InetOrgPerson—in Windows
.NET) objects (so-called accounts) represent security principles that can be granted
privileges to perform certain computer-, domain, or forest-wide tasks or permissions
for access to shared network resources (such as files, folders, and printers). Thus, a
domain client being logged on to the domain once using an account can access all
allowed resources without needing to log on repeatedly to each server holding a
resource. A domain administrator can change Active Directory objects on any domain
controller and, thus, control all options permitted to domain members. Therefore, a
domain is a boundary of administrative power.

In short, to deploy an Active Directory domain, you need to first plan it, install domain
controller(s), add domain client computers, and create user (and group) accounts.
Then you can share resources on domain members and assign necessary privileges
and permissions to users (and groups). (All required operations and tools used to
perform them will be described in this book in Chapters 3 through Chapter 8. The
remaining chapters consider problems that occur during exploitation of Active
Directory domains as well as all necessary system utilities.)

An Active Directory domain can contain sets of directory objects that are called
organizational units (OU), and that usually contain user or computer accounts. Each
OU can have its own administrator and a Group Policy Object (GPO)(s) linked to OU
object. The group policy technology is intended for centralized configuration of user
environment and computer system settings. GPOs can be local or linked to site,
domain, or OU objects.

Active Directory domains form a forest (a forest can comprise one or more domains),
where all domains are linked by two-way, transitive trusts. Trusts allow users logged
on to a domain to access resources located in any location in the forest, or to have
privileges in any domain. Administrator-created trusts can be established with foreign
Active Directory forests or Windows NT 4.0 domains.

Physical Organization

The entire Active Directory database is logically divided into directory partitions,
which are units of replication (i.e., each partition is replicated independently, although
the replication mechanisms, such as scheduled replication or notification procedure,
may affect all partitions). Since Active Directory is a distributed network database,
any domain controller holds a replica of the entire database.

Each replica counts at least three partitions: the Schema and Configuration partitions
that are shared by all domains in a forest and stored on every domain controller; and
domain partition that contains objects of a specific domain and is stored on domain
controllers that belong to that domain. Each forest has one more partition called
Global Catalog (GC), which contains a limited set of attributes of all Active Directory
objects. GC allows users to quickly find any directory object in the forest. GC is a part
of the Active Directory database and can be stored on any domain controller.

Active Directory can take into account the fact that a large enterprise network (a
forest) usually contains a number of subnets linked by fast and slow channels. A set
of subnets connected with fast channels can be referred to as a site. Sites, in turn,
are connected with slow (dial-up) channels. By default, all domains are placed in the
same Default-First-Site (which can be safely renamed).

Directory partition requirements as well as site infrastructure will determine the

replication topology that, by default, is automatically generated by the Knowledge
Consistency Checker (KCC) service running on every domain controller. This service
manages replication connections between domain controllers depending on which
directory partitions they store. Replication is performed in accordance with rules,
intervals, and schedules defined for inter- and intra-site replication types.

Active Directory Clients

Pre-Windows 2000 clients (running Windows 9x/ME and Windows NT 4.0) regard an
Active Directory domain (operating in any mode or at any functional level) as a
Windows NT domain, i.e., they can be authenticated in the domain and access the
shared domain resources (see also later the "Domain Modes and Functional Levels"
section).

Active Directory Client Extension allows pre-Windows 2000 clients to use some
Active Directory features, such as Active Directory Service Interfaces (ADSI), site
awareness, DFS fault tolerance, search options, and NTLM version 2 authentication
(see the Web or the Help and Support Center for a detailed description). Active
Directory Client Extension is available on the Windows 2000 Server CD or the
Microsoft website (the links are in Appendix A). Certainly, all of the listed features as
well as many others are available on Windows 2000/XP/.NET-based clients.
Active Directory Client Extension does not support some important Active Directory
options, such as Group Policy functionality, Kerberos V5 protocol, IPSec and L2TP,
nor does it allow users to browse through the Active Directory organizational units
(OU) and containers (thus, the only visual options that appear when the extension
has been installed on a computer are the For printers and For People commands
on the Start | Search menu).

New Active Directory Features on Windows .NET Servers

This section covers the most important, and up-to-date Active Directory features that
are available on the Windows .NET Server family domain controllers and may allow
administrators to manage Windows .NET domains more efficiently (certainly, this will
not be a complete list of features).

Domain Modes and Functional Levels

Let us first discuss certain general domain and forest functionalities that, to some
degree, are common for both Windows 2000 and Windows .NET domains.

Windows 2000 domains can operate in either default mixed mode (when a domain
can contain Windows 4.0 Backup Domain Controllers, BDC) or native mode (when a
domain contains only Windows 2000-based domain controllers).

When a domain's mode is changed to native, the following considerations should be

taken into account:

ƒ Domain controllers (DC) no longer support NTLM replication; as a result, the

domain's PDC Emulator (a DC that performs the role of Windows NT 4.0
Primary Domain Controller, PDC) cannot replicate data to Windows NT 4.0
BDCs, and Windows NT 4.0-based DCs cannot be added to the domain.
ƒ Domain controllers provide pass-through authentication that allows users and
computers using pre-Windows 2000 systems to be authenticated in any
domain in the forest (notwithstanding the fact that these systems do not
support the Kerberos V5 protocol). Thus, they can use transitive trusts existing
in an Active Directory forest and access resources in any domain.

In Windows .NET domains, a new term, functional level, is introduced. Functional

levels are defined for a domain as well as for the forest.

The following table lists three available domain functional levels and DC types
supported (or that can be introduced into the domain) at these levels:

Domain functional level Domain controllers supported

Windows 2000 mixed (default) Windows NT 4.0, Windows 2000, and Windows .NET
Windows 2000 native Windows 2000 and Windows .NET
Windows .NET Windows .NET only
Two first levels correspond to the Windows 2000 modes, and aforementioned
considerations for the native mode domains are applicable to the Windows 2000
native functional level, too.

Among features that require the Windows .NET domain functional level is the Domain
Controller Rename option (see later). Native mode Windows 2000 domains as well
as Windows .NET domains at the Windows 2000 native or Windows .NET domain
functional level support the following features: universal groups; group nesting;
converting group types, and the SID History option (discussed in Chapter 13,
"Migration and Directory Reorganization Tools").

Forest functional levels define features available across all domains within a forest.
The following table lists two available forest functional levels and DC types supported
at these levels:

Forest Domain controllers Domain functional levels

functional level supported permitted for existing or new
domains

Windows 2000 Windows NT 4.0, Windows Any level

(default) 2000, and Windows .NET

Windows .NET Windows .NET only Windows .NET only

There is also a special Windows .NET Interim forest functional level that is only
available when a Windows NT 4.0 domain is upgraded to a new Windows .NET
forest, which does not contain domain controllers running Windows 2000. (When
upgrading a Windows NT 4.0 domain, you might also be interested in the Q284937
and Q298713 articles from the Microsoft Knowledge Base.)

The forest-wide features available at the Windows .NET forest functional level are
listed later in this chapter.

Keep in mind the following information regarding the domain modes or forest/domain
functional levels:

ƒ It is impossible to change a domain mode from native to mixed mode or to

lower a functional level without re-installing Active Directory in this domain or
in the entire forest.
ƒ Domains in a forest are not required to operate in the same mode or at the
same functional level.
ƒ The native mode or a functional level higher then Windows 2000 mixed level
has no impact (except the pass-trough authentication ability) on down-level
clients such as Windows 9x/ME or Windows NT (with or without the Active
Directory Client extension). This is also the case with trusts between the local
domain and any external domains (Windows NT 4.0, Windows 2000 or
Windows .NET). However, remember that any external trust is always explicit,
unidirectional (one-way), and non-transitive (except for forest trusts).
To learn how to change a domain mode or to raise a domain/forest functional level,
see Chapter 5, "Installing Active Directory".

New Features for Windows .NET Domain Controllers

Any domain controller running Windows .NET provides new features described
below.

Enhancements in the Administrative Tools

In Windows .NET, the standard administrative snap-ins available in Windows 2000

provide additional options that allow administrators to manage domains more
effectively. Among these options are the following:

ƒ Saved directory queries in the Active Directory Users and Computers snap-
in
ƒ Selection and modification of multiple of directory objects
ƒ Drag-and-drop operations
ƒ Efficient search capabilities that include new filter and find options

For detailed information, see Chapter 7, "Domain Manipulation Tools".

Active Directory Command-Line Tools

New LDAP-compliant tools, such as DsQuery.exe, DsAdd.exe, DsMod.exe, etc.,

allow administrators to perform batch and routine operations with directory objects.
You can find the tools' descriptions in Chapter 12, "Manipulating Active Directory
Objects."

Adding Domain Controllers from Backup Files

An additional domain controller in a domain can be installed from the files restored
from a backup of an existing domain controller. This reduces the promotion time, as
well as network replication traffic. This installation type will be described in Chapter 5,
"Installing Active Directory."

Universal Group Membership Caching

All user authentication attempts are verified on a Global Catalog server to check user
membership in the universal groups. This process will generate additional traffic
across a WAN to a remote GC server. To eliminate the need to have a GC server in
every site, you can designate a DC to cache universal group membership and update
that information from a specified site. To learn how to enable caching, see Chapter 7,
"Domain Manipulation Tools."

Application Directory Partitions

An application directory partition can be created by an application or administrator,

who also defines the partition replication scope. This is the main distinction between
this partition type and other Active Directory partitions (whose replication topology, as
a rule, is generated automatically by the Knowledge Consistency Checker, KCC).
The replication scope for an application partition can include any set of domain
controllers in the forest.

An application partition can store any directory objects (except security principals)
defined in the schema (including dynamic objects). Objects in application partitions
are not replicated to Global Catalog. There are two built-in application partitions that
can be used by the Windows .NET DNS servers running on domain controllers (see
the next chapter for details).

To view the contents of application partitions, you can use the ADSI Edit snap-in
(see Chapter 7, "Domain Manipulation Tools"). To learn how to manage application
directory partitions, see Chapter 10, "Diagnosing and Maintaining Domain
Controllers."

InetOrgPerson Object Class

The inetOrgPerson object class defined in RFC 2798 has been added to the Active
Directory schema to make migration from third party LDAP directories to Active
Directory more efficient. The objects of that class are the security principals and can
be used as standard user objects.

New Features for Pure Windows .NET Domains and Forests

This section describes new features that are only available when the domain/forest
functional level has been raised to Windows .NET.

Rename Options

You can rename a domain controller without first demoting it or change the DNS or
NetBIOS name of any domain. Renaming a domain may result in moving it to other
location in the forest infrastructure. Detailed descriptions are provided later in this
chapter.

Forest Trusts

Forest trust is established between the forest root domains that operate at the
Windows .NET functional level and can have a one-way as well as a two-way
direction. Unlike usual external trusts, the forest trusts are transitive, i.e., they allow a
user authenticated in one forest to access resources located in any domain in
another forest.

Forest trusts are discussed in detail in Chapter 5, "Installing Active Directory."

Defunct Objects

Active Directory does not allow you to delete a directory object class or attribute: you
can only deactivate it. A deactivated class or attribute is called defunct. It is possible
to activate a deactivated class or attribute and redefine it, if there was an error when
the class or attribute was initially created.

Replication Enhancements

Some replication related problems existing in Windows 2000 have been addressed in
Windows .NET. Primarily, this concerns the enhanced linked value and Global
Catalog replication as well as algorithms used by the Knowledge Consistency
Checker (KCC) for generating replication topology in forests with large number of
sites.

Linked value replication reduces network traffic when group membership is changed:
only new or deleted group members are replicated instead of the entire list of group
members stored in the member attribute. This is essential for groups with a large
number of members.

In Windows 2000, when a new attribute is added to Global Catalog, a full

synchronization of partial replicas is required, and this process affects all domains in
the forest. In a Windows .NET, only the new attribute is replicated to Global Catalog
servers.

Dynamic Auxiliary Classes and Dynamic Objects

It is possible to dynamically link or remove auxiliary classes to object instances as

well as to object classes.

Dynamic objects are instantiated from an object class that has the auxiliary class
dynamicObject. This class can also be added to an object instance by using a
program or script. As a result, a dynamic object exists during the time defined by a
Time-to-Live (TTL) value that is assigned at the object creation and can be renewed
by a client or an application (see also Appendix B).

Renaming Domains

The Windows .NET version of Active Directory allows administrators to change

domain names and, thus, reconstruct the forest. This procedure is not intended to be
a routine operation and is only possible when the forest functional level has been
raised to Windows .NET. The rename procedure is not simple and includes a step-
by-step process that requires use of the RenDom.exe utility (see the link in Appendix
A) and depends on the kind of rename operation.

The simplest case is when you rename a domain and do not change the forest
parent-child structure. A more complex case is when you change the domain position
in a forest tree, e.g., make a child domain a tree root domain or change the parent for
a child domain. The rename procedure may require many supplementary operations,
such as pre-creating additional inter-domain trusts, preparing DNS zones, configuring
member computers, and so on.

The rename procedure allows you to:

 ƒ Change the DNS or/and NetBIOS names of any domain without affecting the
forest structure. This includes renaming a root domain, which results in
changing names of all child domains.
ƒ Change the parent domain for a child domain (the new parent can be in the
same or another domain tree).
ƒ Rename a child domain to be a new tree-root domain.

None of the listed operations is possible in a Windows 2000 forest.

The following rename operations are not possible:

ƒ You cannot redefine the forest root domain (i.e., the forest root will always be
the same domain). However, you can change its DNS or/and NetBIOS name.
ƒ One cannot delete or add a domain: the total number of domains in a forest
must remain the same. A usual promotion/demotion procedure should be used
in such cases.

You cannot rename two domains in a single operation and give a domain the name
of another domain. The rename procedure requires quite a long, detailed description
— and so, it is inappropriate to include one here. You can find two comprehensive
operation guides (about 90 pages in total) on the Microsoft website (see the link in
Appendix A) if you are interested in learning more about this topic.

Renaming Domain Controllers

In a Windows .NET domain, you may rename a domain controller (i.e., change its
FQDN and NetBIOS names). To rename a domain controller from the local console:

1. Open the System Properties window. (Press the <Win>+<Pause/Break>

keys, or click System in Control Panel.)
2. On the Computer Name tab, click Change.
3. Click OK to continue renaming.
4. Enter a new computer name and click OK.
5. Enter a domain administrator's credentials if required.
6. Restart the domain controller. Wait until the DNS information and Active
Directory replication topology is renewed. After that, the clients and replication
partners will be able to locate the renamed DC and be authenticated on it.
Verify the DC with the dcdiag and repadmin /showreps commands.

Important To rename domain controllers, you must first raise the domain functional
level to Windows .NET. This is because only Windows .NET-based
domain controllers support the msDS-AdditionalDnsHostName, msDS-
AdditionalSamAccountName, and some other attributes necessary to
perform renaming. This means that it is not possible to rename a DC in
a Windows 2000 domain.

The rename operation does not change the domain membership of the
controller, i.e., it does not allow you to move a DC to another domain
(even if you change the primary DNS suffix). To do so, you must first
demote the DC and promote it with a new domain name.
To rename a remote domain controller, it is necessary to use the NetDom.exe utility.
The renaming procedure is not complicated and is described in the Help and Support
Center (search for the "rename controller" words).

Windows Time Service

Windows Time service provides computer clock synchronization for domain clients
and domain controllers. This is especially important on client computers running
Windows/XP/.NET and domain controllers since all of them rely on authentication
procedure that use Kerberos V5 protocol, which by default requires clock
synchronization with a delta of 5 minutes. The service operation is defined by registry
settings located in the HKLM\SYSTEM\CurrentControlSet\Services\W32Time key. (This key
will be the reference for all registry values mentioned in this section.)

Domain clients running Windows XP/.NET will automatically synchronize their clocks
with the PDC Emulator time upon their startup and authentication in the domain. A
domain's PDC Emulator, in turn, synchronizes its clock with the clock of the PDC
Emulator of a parent or forest root domain. The forest root domain's PDC Emulator
should synchronize its clock with an external timeserver(s) or you can leave it "as is".

To specify an external timeserver, use the net time /SETSNTP: timeSrvName command.
On Windows .NET DCs, you can also use the command

C:\>w32tm /config /manualpeerlist: timeSrvName /update

By default, all computers running Windows XP/.NET use the time.windows.com site
as the timeserver.

On a Windows .NET DC, to disable synchronization with an external timeserver, you

may set the registry value Parameters\Type to Nosync, clear the Parameters\NtpServer
value, and stop the NTP Client by setting the TimeProviders\NtpClient\Enabled value to
zero). On a Windows 2000 DC, you may use the following command:

C:\>net time /SETSNTP:w2kdc2.w2k.dom,

where w2kdc2.w2k.dom is the PDC Emulator name.

Note Each time you change the settings of the Windows Time service, restart it by
using the Service snap-in or from the command prompt (with the net stop w32time
and net start w32time commands).

When a client running Windows XP/.NET joins a domain, the Parameters\Type value is
automatically changed from default NTP to NT5DS. The same change is performed on
Windows .NET servers when they are promoted to domain controllers. On clients and
domain controllers running Windows 2000, you may either manually set the
Parameters\Type value or use the net time /SETSNTP command.

On computers running Windows XP/.NET, the following sample command allows you
to view the timeserver (marked as PDC) as well as the time offsets for computers in
the net.dom domain (if this parameter is omitted, the current domain is tested):
 C:\>w32tm /monitor /domain:net.dom
netdc1.net.dom *** PDC *** [192.168.1.2]:
ICMP: 0ms delay.
NTP: +0.0000000s offset from netdc1.net.dom
RefID: 'LOCL' [76.79.67.76]
netdc4.net.dom [192.168.1.103]:
ICMP: 0ms delay.
NTP: -0.0100835s offset from netdc1.net.dom
RefID: netdc1.net.dom [192.168.1.2]

Chapter 3: Domain Name System (DNS)

as Main Naming Service
Overview

Domain Name System (DNS) is one of the "cornerstone" services of an Active

Directory domain (both Windows 2000 and Windows .NET), and you must use it in
any domain structure based on Active Directory even if the forest root domain is not
registered in the Internet DNS namespace. It is possible to exploit other DNS servers
besides Microsoft DNS Server, but these servers must conform to specific
requirements. You need not become a DNS guru, but you have to be familiar with all
DNS essentials and its interoperation with the Active Directory.

Be careful! The system (even Windows .NET) permits promotion of a server to

domain controller (i.e., installation of the Active Directory and creation of a domain)
without specifying any DNS servers. However, this does not guarantee that your
domain will work correctly. Quite the contrary! Nevertheless, such an approach can
be useful in some cases (as a prelude to domain deployment) if you thoroughly
understand all the details of DNS configuring and its interoperation with Active
Directory.

You could, for example, first promote a server to DC, and then prepare a DNS server
for dynamic updating of the appropriate zones. Enter the DNS server's IP address in
the DC's TCP/IP properties, and reboot the DC (or restart the Netlogon service and
execute the ipconfig /registerdns command). The result will be a fully operable
configuration! The same procedure is used when you select another authoritative
DNS server for a domain and want to re-register all necessary DNS records.

This chapter covers some general aspects of Active Directory and DNS
interoperation, as well as basic features of Microsoft DNS servers. In Chapter 4,
"Windows .NET DNS Server", operations with native Microsoft DNS servers will be
considered, and the DNS issues related to Active Directory deployment and
maintenance will be considered in Chapter 5, "Installing Active Directory."

Note Name-resolving systems, such as DNS and WINS, are a vast, complex topic.
There are plenty of good specialized books on TCP/IP, DNS, and Windows
2000 DNS Server in particular, and you may wish to read them to obtain a
deeper understanding of the DNS system in general and its realization in
 Windows 2000. This information applies to Windows .NET DNS Server, too.

In this chapter and the entire book, "Microsoft DNS Server" refers to both
Windows 2000 DNS Server and Windows .NET DNS Server. The differences
between these products, if such exist, are specifically indicated when
necessary.

What Active Directory Requires from the DNS Service

There are no "secret relations" between Active Directory and DNS. All that Active
Directory requires from DNS is a standard-resolving of DNS names (including some
system names) into IP addresses. The following two postulates are related to Active
Directory and DNS:

ƒ Active Directory requires a DNS infrastructure. Active Directory uses DNS as

a locator service, and thus uses the DNS hierarchical name for naming
domains, computers, and many other Active Directory objects. (Windows
Internet Naming Service, WINS, used in Window NT domains, is now
regarded as supplementary and can be used in mixed environments
comprising pre-Windows 2000 computers. This is why WINS will not be
considered in this book.)
ƒ Active Directory does not necessary require a Microsoft DNS Server (on
either Windows 2000 or Windows .NET platforms).

To meet Active Directory requirements, a DNS server must have two of the following
features:

ƒ The server must support resource records of the SRV type according to RFC
2052 ("A DNS RR for specifying the location of services (DNS SRV)"), since
SRV records are widely used by domain clients and domain controllers for
locating various directory resources, such as domain controllers, Global
Catalog servers, Kerberos servers, and so on.
ƒ The server must permit use of underscores ("_") in the DNS names, since this
character is used in the reserved system DNS names
(e.g.,_gc._tcp.domain.com). (See examples of system DNS names in the last
section of this chapter.)

One more feature is eagerly required for deploying Active Directory; however, it is
not mandatory.

The server should support dynamic updates of resource records according to RFC
2136 ("Dynamic Updates in the Domain Name System (DNS UPDATE)"). By default,
all Active Directory domain controllers and clients automatically register and update
the appropriate records of SRV, CNAME, and A types. If dynamic updates are not
supported, an administrator must manually manage all records, which is a difficult
task in a large network.

Any DNS server that meets at least the first two requirements can be used in an
Active Directory environment (e.g., Windows NT 4.0 DNS Server with SP 4 or higher;
however, that server does not support dynamic updates). For example, according to
many sources, the DNS BIND 8.2.2 server or later is suitable for work with Active
Directory.

Note Reverse zones are not necessary for Active Directory to work; and Active
Directory Installation Wizard will not create them. However, it is recommended
that you create the applicable reverse zones so that various DNS utilities and
tools (e.g., Nslookup or Ping) can work well.

As a rule, on both client computers and domain controllers running Windows 2000 or
later systems, the IP address(es) of the same preferred DNS server(s) that holds the
authoritative zone for a domain should be entered into the TCP/IP properties on the
DNS tab in the Advanced TCP/IP Settings window. This address must not be the
Internet Service Provider (ISP) DNS server's address. If necessary, the preferred
server should forward clients' queries for external domains to the ISP's DNS servers.

Active Directory allows administrators to change IP addresses of DNS servers and

domain controllers, since the Active Directory infrastructure is linked to LDAP, DNS,
or GUID names. If the IP address of a DNS server is changed (or if another server is
selected), you need to specify the new address in the preferred DNS server settings
on all client computers and domain controllers, and re-register the appropriate
resource records on the DNS server. If the IP address of a domain controller is
changed, you need to re-register its A and SRV records on the preferred server.
Keep in mind that the DNS client (resolver) on Windows 2000/XP/.NET systems
caches both successful and failed DNS query responses, and this caching may affect
name resolving (for example, a domain controller can hold the outdated IP address of
its replication partner, which may result in replication errors).

Microsoft DNS Server Features

In addition to the above-mentioned options, the DNS service running on Windows

2000 or Windows.NET servers provides many other features; among them:

ƒ Integration with other network services, such as WINS and DHCP. (For
example, pre-Windows 2000 computers can neither register nor update their
DNS names directly; they can perform that operation through WINS, which
acts as an intermediary to DNS).
ƒ Interoperability with third party DNS servers. (For example, the Windows
.NET DNS development team has tested interoperability with the BIND DNS
server version 4.9.7, 8.1.2, 8.2, and 9.1.0.)
ƒ Support for secure dynamic updates that allows only domain-authenticated
clients to re-register DNS names.
ƒ Incremental zone transfers between DNS servers (zone transfers are only
required for non-Active Directory-integrated zones).
ƒ Support for Active Directory-integrated zones, i.e., zones that store their
data in the directory. These zones can only be created on DNS servers
running on domain controllers and, therefore, can benefit from Active Directory
multi-master replication.
 The replication scope for a zone depends on the directory partition where it is
stored. On Windows 2000 DNS Servers, a zone can only be stored in a
domain partition that is replicated among domain controllers that belong to that
domain. Even if you create a zone with the same name in another domain,
there will be two different zones, which results in a big mess for the entire DNS
infrastructure. If two DNS servers Belong to different domains, one server
must be primary for the other one. On Windows .NET DNS Servers, the
situation is simpler since these DNS servers can store their data in application
directory partitions whose replication scope is defined by administrators (see
details in the "Domain Management" section in Chapter 10, "Diagnosing and
Maintaining Domain Controllers").

ƒ Event logging and debug options.

As any typical DNS server, Microsoft DNS Servers can operate in the following
modes:

ƒ Caching sever — as a rule, a standalone DNS server that does not host any
authoritative zones after its installation, and therefore only caches the clients'
queries. A caching Windows .NET Server can also hold stub zones.
ƒ Primary server — the server that hosts an updatable, authoritative zone(s) for
some domain(s), i.e., it is permitted to resolve client queries. Resource records
from such a server may be transferred to the secondary servers.
ƒ Secondary server — the server that hosts a read-only replica(s) of zone(s)
transferred from a primary (authoritative) server. However, if both the primary
and secondary DNS servers hold an Active Directory-integrated zone(s), these
servers can be regarded as peers that are able to accept updates. Active
Directory integrated zones require a DNS server running on a Windows 2000-
based domain controller.

Certainly, any DNS server can combine any of these modes; however, you need to
thoroughly plan operation modes of all DNS servers in your network, as well as
interoperations between these DNS servers and "external" servers, e.g., your ISP's
DNS servers.

Two main tools that can be used for administering local and remote Microsoft DNS
Servers are:

ƒ The DNS snap-in (DNS console)

ƒ The DnsCmd.exe command-line utility

New DNS Features in Windows .NET

In comparison to Windows 2000, the Windows .NET Server family offers a few new
DNS related features that are implemented either in the system itself or in the
Windows .NET DNS Server. Let us consider features that are the most important for
administering both DNS servers and Active Directory domains:

ƒ Enhanced domain joining procedures. When a client computer is added to

a domain or a new domain controller is created in an existing or a new
 domain, the appropriate procedures verify the DNS infrastructure and explain
possible failures and how to fix them.
ƒ New group policies for managing DNS client settings on computers running
Windows XP/.NET (look at the Computer Configuration | Administrative
Templates | Network | DNS Client node of a Group Policy Object) and
policies that control DNS registration of SRV records by domain controllers
running Windows .NET.
ƒ Active Directory-integrated zones that can be stored in application directory
partitions. A DNS server installed on a domain controller running Windows
.NET can use two built-in application directory partitions for storing DNS
information. These partitions, ForestDnsZones.domainName and
DomainDnsZones.domainName, are replicated to all DNS servers in the forest
or in the domain, respectively. In addition, DNS server can store data in user
created application partitions with their own replication scopes. In both cases,
it is the administrator who defines the set of domain controllers that store
application partition replicas. (Keep in mind that DNS data stored in application
partitions is not replicated to Global Catalog.)
ƒ Stub zones and conditional forwarding. Stub zones only contain resource
records (of type SOA, NS, and A) that specify the authoritative DNS server(s)
(primary and secondary) for the zone, and therefore simply redirect a client
queries to the DNS server(s) that holds the authoritative zone and is able to
resolve these requests. Look, for example, at Fig. 4.1. If there are DNS
servers that are authoritative for the child domain (subdom.net.dom), you can
convert the child zone into a stub zone; as a result, the root DNS server will
remain aware of the DNS servers authoritative for the delegated child zone
and will only cache the answers to queries for the child zone names.

Conditional forwarders redirect client queries to other DNS servers depending

on the domain name contained in these queries. Conditional forwarders can
be useful, for example, when you establish trusts between different forests,
which have their own DNS servers, and do not want to query the Internet DNS
servers. To provide name resolving, you can specify the other side's DNS
server as a conditional forwarder for foreign forest DNS names.

DNS Records Registered by Active Directory Domain Controllers

All SRV and A resource records (20 in total, if the domain controller is a Global
Catalog server; 15 if it is not) that each Active Directory domain controller must
register on a DNS server, are contained in the %SystemRoot%\system32\config\
netlogon.dns file. (If your DNS server does not support dynamic records update, you
need to manually manage these records.) An example of such a file is presented
below.

Note It is possible to set a group policy that will prohibit registration of some or all
SRV records by Windows .NET domain controllers. This policy, DC Locator
DNS records not registered by the DCs, is located in the Computer
Configuration | Administrative Templates | System | Net Logon | DC
Locator DNS Records node of a Group Policy Object (GPO).
In this example: server name — netdc2.subdom.net.dom, domain name —
subdom.net.dom, root domain name — net.dom, site name — .NET-Site. The
records are sorted for clarity. The real order will differ, but this does not matter. The
records for a global catalog server are shown in bold. You can verify resource
records with the DNS snap-in.

subdom.net.dom. 600 IN A 192.168.1.102

laffcd49-c47f-4499-82b8-4872led1c799._msdcs.net.dom.
600 IN CNAME netdc2.subdom.net.dom.
_ldap.tcp.subdom.net.dom. 600 IN SRV 0 100 389 netdc2.subdom.net.dom.
_ldap._tcp.dc._msdcs.subdom.net.dom. 600 IN SRV 0 100 389
netdc2.subdom.net.dom.
_ldap._tcp.pdc._msdcs.subdom.net.dom. 600 IN SRV 0 100 389
netdc2.subdom.net.dom.
_ldap._tcp.gc._msdcs.net.dom. 600 IN SRV 0 100 3268
netdc2.subdom.net.dom.
_ldap._tcp. 729173d2-f48b-4655-ac5c-
5f1c0c93cbdd.domains._msdcs.net.dom. 600 IN SRV
0 100 389 netdc2.subdom.net.dom.
_ldap._tcp.NET-Site._sites.subdom.net.dom. 600 IN SRV 0 100 389
netdc2.subdom.net.dom.
_ldap._tcp.NET-Site._sites.dc._msdcs.subdom.net.dom.
600 IN SRV 0 100 389 netdc2.subdom.net.dom.
_ldap._tcp.NET-Site._sites.gc. _msdcs.net.dom.
600 IN SRV 0 100 3268 netdc2.subdom.net.dom.
gc._msdcs.net.dom. 600 IN A 192.168.1.102
_gc._tcp.net.dom. 600 IN SRV 0 100 3268 netdc2.subdom.net.dom.
_gc._tcp.NET-Site._sites.net.dom. 600 IN SRV 0 100 3268
netdc2.subdom.net.dom.
_kerberos._tcp.subdom.net.dom. 600 IN SRV 0 100 88
netdc2.subdom.net.dom.
_kerberos._udp.subdom.net.dom. 600 IN SRV 0 100 88
netdc2.subdom.net.dom.
_Kerberos.tcp.dc._msdcs.subdom.net.dom. 600 IN SRV 0 100 88
netdc2.subdom.net.dom.
_Kerberos._tcp.NET-Site._sites.dc._msdcs.subdom.net.dom.
600 IN SRV 0 100 88 netdc2.subdom.net.dom.
_kpasswd._tcp.NET-Site._sites.subdom.net.dom.
600 IN SRV 0 100 88 netdc2.subdom.net.dom.
_kpasswd._tcp.subdom.net.dom. 600 IN SRV 0 100 464
netdc2.subdom.net.dom.
_kpasswd._udp.subdom.net.dom. 600 IN SRV 0 100 464
netdc2.subdom.net.dom.

As you can see, the first two r cords are of the A (host) and CNAME (alias) types,
respectively; the other records are of the SRV (service location) type. Let us discuss
the purpose of every record in the order that they are presented in the listing above.
DNSDomainName is the name of the current domain, e.g., subdom.net.dom.
DNSRootName is the name of the forest root domain (it can be also a tree root
domain name if there is only one tree in the domain structure), e.g., net.dom.

Important Do not confuse a tree root domain name (there may be a few in the
forest) with the forest root domain name (only one). For example, a forest
may include two domain trees with the root domains net.dom and
net2.dom. Only the first created domain — net.dom — will be the forest
root domain. Therefore, if the Global Catalog servers appear in the
 net2.dom domain (or in any child domains), they will still register the
appropriate records in the net.dom DNS zone.

<DNSDomainName> — a client can use this A record to find a domain controller in the
domain by using a normal host record lookup.

<NTDSSettingsGUID>._msdcs.<DNSRootName> — each domain controller registers this

CNAME record for its child object (Directory System Agent, DSA), CN=NTDS
Settings, CN=<DCName>, CN=Servers, CN=<SiteName>, CN=Sites,
CN=Configuration, DC=<DomainName>, which uniquely identifies this controller in
the Active Directory replication topology. A client can use this CNAME record to find
a specific DC in the forest.

_ldap._tcp.<DNSDomainName> — a client can use this record to find a LDAP server in

the specified domain. Each domain controller registers this record.

_ldap._tcp.dc._msdcs.<DNSDomainName> — allows a client to find a DC in the specified

domain. Each domain controller registers this record. This record (with appropriate
domain names) is used for joining a domain, a tree, or a forest; the current, parent, or
root domain name is specified, respectively.

_ldap._tcp.pdc._msdcs.<DNSDomainName> — a client can use this record to find the

Primary Domain Controller (PDC) Emulator in a mixed-mode domain. Only the PDC
masters register this record.

_ldap._tcp.gc._msdcs.<DNSRootName> — a client can use this record to locate a Global

Catalog (GC) server in the forest. Only GC servers register this record.

_ldap._tcp.<DomainGUID>.domains._msdcs.<DNSRootName> — a client can use this

record to locate a domain controller in the domain specified by the domain GUID.
Each domain controller registers this record.

_ldap._tcp.<SiteName>._sites.<DNSDomainName> — a client can use this record to find

an LDAP server (not necessarily a DC) in the specified domain and site. Each Active
Directory DC registers this record for its site.

_ldap._tcp.<SiteName>.sites.dc._msdcs.<DNSDomainName> — a client can use this record

to locate a domain controller in the specified domain and site. Each domain controller
registers this record.

_ldap._tcp.<SiteName>.sites.gc._msdcs.<DNSRootName> — allows a client to find a GC

server for the forest in the specified site. Only GC servers register this record for their
site.

gc._msdcs.<DNSRootName> — allows a non-SRV-aware client to find a GC server for

the forest.

_gc._tcp.<DNSRootName> — a client can use this record to locate a GC server (not

necessarily a DC) in the forest. Only an LDAP server that is the GC server registers
this record.
_gc._tcp.<SiteName>._sites.<DNSRootName> — allows a client to find a GC server (not
necessarily a DC) for the forest in the specified site.

_ldap._tcp.<SiteName>._sites.<DNSRootName> — a client can use this record to find a

LDAP server (not necessarily a DC) in the forest.

_kerberos._tcp.<DNSDomanName> — a client can use this record to locate a server (not

necessarily a DC) that is running the Kerberos Key Distribution Center (KDC) service
in the specified domain. Each Active Directory DC registers this record.

_kerberos._udp.<DNSDomanName> — the same as above, but for the UDP protocol.

_kerberos._tcp.dc._msdcs.<DNSDomanName> — a client can use this record to locate a

server (not necessarily a DC) that is running the Kerberos KDC service in the
specified domain and site. Each DC registers this record.

_kerberos._tcp.<SiteName>._sites.dc._msdcs.<DNSDomanName> — a client can use this

record to locate Active Directory DC that is running the Kerberos KDC service in the
specified domain. Each DC regisders this record.

_kerberos._tcp.<SiteName>._sites.<DNSDomanName> — a client can use this record to

locate an Active Directory DC that is running the Kerberos KDC service in the
specified domain and site. Each DC registers this record.

_kpasswd._tcp.<DNSDomanName> — a client can use this record to locate a server (not

necessarily a DC) that is running the Kerberos Password Change service in the
specified domain. Each Active Directory DC that is running the Kerberos KDC service
registers this record.

_kpasswd._udp.<DNSDomanName> — the same as above, but for the UDP protocol.

Note Notice that all records for global catalog servers refer to the forest root domain
name.

Resource Records for Application Partitions

If a Windows .NET domain controller holds one or more application directory

partitions, it registers two SRV records and an A record for each partition in DNS.
These records are not currently used by Active Directory; however, they allow other
applications to find a server for a specific partition by using a DNS lookup operation.
For example, if the DC netdc2.subdom.net.dom stores replicas of two built-in DNS
application partitions, it will register the following records on the preferred DNS
server:

DomiainDnsZones.net.dom. 600 IN A 192.168.1.102

ForestDnsZones.net.dom. 600 IN A 192.168.1.102
_ldap._tcp.DomainDnsZones.net.dom. 600 IN SRV 0 100 389
netdc2.subdom.net.dom.
_ldap.tcp.NET-Site._sites.DomainDnsZones.net.dom. 600 IN SRV
0 100 389 netdc2.subdom.net.dom.
_ldap.tcp.ForestDnsZones.net.dom. 600 IN SRV 0 100 389
 netdc2.subdom.net.dom.
_ldap._tcp.NET-Site._sites.ForestDnsZones.net.dom. 600 IN SRV
0 100 389 netdc2.subdom.net.dom.

Verifying and Updating DNS Registration

To test the DNS configuration for the entire forest, use the Nslookup command. The
following sample dialog illustrates how to query the DNS server for the records
registered by the Global Catalog servers. (Input commands are in bold.)

C:\>nslookup
Default Server: netdc1.net.dom
Address: 192.168.1.2
> Set type=SRV
> _gc._tcp.net.dom
Server: netdc1.net.dom
Address: 192.168.1.2
_gc._tcp.net.dom SRV service location:
priority = 0
weight = 100
port = 3268
svr hostname = netdc2.subdom.net.dom
_gc._tcp.net.dom SRV service location:
priority = 0
weight = 100
port = 3268
svr hostname = netdc1.net.dom
netdc2.subdom.net.dom internet address = 192.168.1.102
netdc1.net.dom internet address = 192.168.1.2
>

The DCdiag command verifies DNS settings of a domain controller's replication

partners and connectivity with them.

To verify DNS records registered by a specific domain controller, you can use on that
DC the following commands:

ƒ netdiag /test:DNS (or netdiag /test:DNS /v) — a very powerful and trustworthy tool.
ƒ nitest /DSQUERYDNS — available on Windows .NET-based DCs; this command
does not test SRV records for application partitions.

To re-register the register records on a DNS server (provided that it implements

dynamic updating), one of the following methods can be used:

ƒ Run the ipconfig /registerdns or netdiag /fix command

ƒ Restart the Netlogon service in the Services snap-in
ƒ Enter net stop netlogon, then net start netlogon at the command prompt
ƒ On Windows .NET-based DCs, run the nltest /DSREGDNS command

For a Windows .NET domain controller, it is also possible to de-register (e.g., for the
test purpose) all SRV records with the command

C:\<nltest /DSDEREGDNS: netdc1. net.dom

The command completed successfully
Important When you are testing DNS, remember the cache of the DNS server as
well as local DNS resolver. Its stale data can affect your test results. You
might want to flush the cache after some DNS settings have been
updated.

Part II: Deploying Active Directory

Domains
Chapter 4: Windows .NET DNS Server
Chapter 5: Installing Active Directory
Chapter 6: Configuring and Troubleshooting Active Directory Domains

Chapter 4: Windows .NET DNS Server

Overview

This chapter deals with various aspects of Microsoft DNS Server installation and
configuration and covers two product versions: Windows 2000 DNS Server and
Windows .NET DNS Server. Most of the things considered can be applied to both
products (in such a case, we will call them the Microsoft DNS Server); the
differences, if they exist, are explicitly stated. (Windows NT 4.0 DNS Server is only
mentioned in the section "Configuring Windows 2000/.NET DNS Server for Use with
Legacy DNS.")

The DNS service is mandatory for Active Directory, and you should be familiar with
all DNS requirements within an Active Directory environment, which have been
discussed in detail in Chapter 3, "Domain Name System (DNS) as Main Naming
Service". You can skip this section if DNS service has already been deployed in your
network and configured accordingly. Some DNS specific problems will also be
considered in Chapter 5, "Installing Active Directory."

This chapter also contains an example of using a legacy DNS system (that, for
example, does not support SRV resource records and updatable DNS zones) for
deploying Active Directory.

Prerequisites

To install a Microsoft DNS Server successfully, you have to consider some issues
listed below.

IP Address

The server providing the DNS Service must have a static IP address. You should not
use the address assigned by a DHCP Server.

Important This IP address can be changed if needed, even if the DNS server is
running on a domain controller. (However, this is not a normal practice!)
 In such a case, you also have to change the preferred DNS settings on all
domain clients and domain controllers and update registration of all DNS
resource records.

Primary DNS Suffix

Before installing DNS service, you must check the primary DNS suffix for the server
(see "Setting the DNS Suffix" section). This is especially important if this server is
also going to be a domain controller. In that case, you can either set the DNS suffix to
be the same as the DNS name of the domain that the domain controller will belong
to, or first promote the server and then install the DNS service. In any configuration,
you must be sure that all names — the computer name (that includes the primary
DNS suffix), the domain name of a member server or domain controller, and the
name(s) of authoritative zone(s) stored on the DNS server — are consistent.

Planning DNS

Microsoft DNS Server can operate as:

ƒ Caching server
ƒ Primary server
ƒ Secondary server

A DNS server can perform all listed roles at the same time (for example, it can be the
primary server for one zone and the secondary server for another zone). In addition,
each zone can be stored in a standard text file or in Active Directory. Therefore, you
need first to carefully plan the DNS namespace and any questions related to DNS
(see details in the previous chapter).

Installing a Microsoft DNS Server

To install and start the DNS service on a computer running Windows 2000/.NET
Server, use the standard Windows Component Wizard that can be found in the
Add/Remove Programs applet in the Control Panel. Select Network Services and
click Details. Check the Domain Name System (DNS) box and click OK and then
Next.

After the system files have been copied (the Windows 2000/.NET Server installation
CD will be required) and the service started, you will see a new DNS snap-in in the
Administrative Tools group. The DNS service is now installed on the computer and
needs to be configured.

At first, the new DNS server running on a normal server will work as a caching server
and will not be authoritative for any zones. Look up the DNS Server log in the Event
Viewer to be sure that the service was started successfully. (If you have installed the
DNS server on a domain controller, its behavior will be different; see the next
sections of this chapter.)

To configure and manage a Microsoft DNS Server, run the DNS command from the
Administrative Tools menu. In the DNS snap-in's main window (see Fig. 4.1), you
can use a convenient wizard — New Zone Wizard that will help you to create forward
and reverse zones.

Fig. 4.1: The DNS snap-in's main window containing a few authoritative zones

Installing a DNS Server on the First Domain Controller

When you simultaneously install Active Directory and the DNS service on a server
that is the first domain controller in the network, the Active Directory Installation
Wizard (DCpromo.exe) automatically creates an authoritative zone for the forest root
domain on the DNS server. (If a DNS server already exists, you must first manually
create a zone for the new forest and enable dynamic updates of the zone.)

When a child domain in an existing forest is created, the zone of the forest root
domain is used, and the wizard itself will create an authoritative zone for that child.
(You may change this behavior; see later in this chapter.) However, if you add a tree
to a forest, you must manually create an authoritative zone for the new DNS name-
space. Therefore, you always need to create the authoritative zones for every new
domain tree manually (or new forest), except with simultaneous installation of Active
Directory and DNS service on the same server.

Caution The Dcpromo utility does not create any reverse zones on the DNS server.
Therefore, to make the DNS server configuration fully operational, it is
recommended that you: manually create an appropriate reverse zone
(because some utilities and applications use it), enable dynamic updates for
it, and re-register the domain controller address with the ipconfig / registerdns
command.

Secure updates are only enabled for Active Directory-integrated zones. These zones
are available if only the DNS server is installed on a domain controller.

When a text file zone becomes Active Directory-integrated, the appropriate zone file
is moved from the %System Root%\system32\dns folder to the nested \backup
folder. At the same time, new objects (of dnsZone and dnsNode types) for the zone
are created in the Active Directory in the System/MicrosoftDNS container in the
domain partition (if zones are stored on domain controllers) or within the appropriate
application partition (on a Windows .NET Server). The reverse transformation of a
zone (from Active Directory-integrated zone to text file zone) is also possible.
Important Remember that Windows 2000 does not support application directory
partitions. Therefore, to enable a DNS server running on a Windows 2000
DC to replicate Active Directory-integrated zones from a Windows .NET
DNS server running on a Windows .NET DC, you must select the
appropriate zone replication scope.

A Windows 2000 Environment

By default, the forward forest root domain authoritative zone (that includes the
_msdcs subdomain, or node) and the root zone (".") are created as Active Directory-
integrated and allow Only secure updates. This means that only authenticated users
can update records. Sometimes, the Yes option in the Allow dynamic updates? list
appears to be a better choice.

The "." zone, configured by default, makes the DNS server the root server, which
prevents clients' queries from being sent — forwarded — to an external DNS name-
space, e.g., to the Internet. To enable forwarders, you can just delete the "." zone. By
default, the DNS server's IP address is specified on the Root Hints tab in the
server's Properties window. If you have deleted the "." zone, make sure the server
name has also been deleted from that tab.

A Windows .NET Environment

The root zone (".") is not created by default on Windows .NET DNS servers. As a
result, the DNS server can "natively" resolve DNS queries for external names (e.g.,
the Internet names) provided that the default gateway has been configured for the
server and network connectivity has been established. In that case, root hints are
used. To resolve external queries more efficiently, you may specify a DNS server's IP
address (e.g., the server of your Internet Service Provider, ISP) on the Forwarders
tab in the server's Properties window.

By default, the Dcpromo utility creates two authoritative zones: the forest zone and
the domain system zone _msdcs (see Fig. 4.1). Both zones are Active Directory-
integrated and allow Only secure updates. The former zone is stored in the Domain
DnsZones application partition that is replicated to all DNS servers in the forest root
domain. The latter zone is stored in the Forest DnsZones application partition that is
replicated to all DNS servers in the entire forest. Therefore, to enable a Windows
2000 DNS server running on a Windows 2000 DC to support these zones, you
should change the replication scope of these zones.

Installing a Secondary DNS Server

You can increase the reliability of your network and install an additional (backup)
DNS server. This task will be very simple if all the zones are Active Directory-
integrated and the DNS server is installed on a domain controller. In that case, all
DNS servers will be peers, and the term "secondary server" is not applicable since
the authoritative zone(s) can be updated on any server.

In a Windows 2000 environment, every DC in the domain contains full DNS

information. In a Windows .NET environment, you should first enable the DC to store
replicas of the appropriate application partitions that hold DNS information.
(Otherwise, the new DNS server will act as a simple caching server.) In either case,
when you install a new DNS server, it will automatically load zone(s) from Active
Directory and you need not create any zones. (For more information on managing
application partitions, see the NTDSutil description in Chapter 10, "Diagnosing and
Maintaining Domain Controllers.")

If the new DNS server is installed on a normal server, or if Active Directory-integrated

zones are not used, you must create the zones manually and maintain the zone
transfers. In that case, the new DNS server will act, most likely, as a secondary
server, and the zones must be created as secondary.

When an additional DNS server has been installed, you may add the server's IP
address to the list of DNS servers on every domain client computer or domain
controller.

Configuring Windows 2000/.NET DNS Server for Use with Legacy

DNS

If Active Directory is deployed in an existing network which already uses DNS

service, an interoperation problem may arise if the legacy DNS service does not
conform to Windows 2000/.NET DNS requirements. This is a neither rare, nor
hopeless situation; there is a way to achieve a compromise. We shall use the
adjective legacy for any DNS servers that support neither dynamic records update,
nor SRV records (this can be, for example, an NT 4.0 DNS Server or a UNIX DNS
server). In addition, the configuration shown below can serve as an example of
heterogeneous DNS service deployment and DNS zone delegation (which may be
helpful in various cases).

You can easily diagnose the problem by looking up the System log after creating the
first domain controller. (It is strongly recommended that you check all logs when each
DC is created!) After the domain controller boots, the warning (ID 5773) from
Netlogon may appear in the System log; Windows .NET systems provide a clear
issue explication:

The following DNS server that is authoritative for the DNS domin controller
locator records of this domain controller does not support dynamic DNS updates:
DNS server IP address: 192.168.1.155
Returned Response Code (RCODE): 4
Returned Status Code: 9004

USER ACTION
Configure the DNS server to allow dynamic DNS updates or manually add
the DNS records from the file
'%SystemRoot%\System32\Config\Netlogon.dns' to the DNS database.

Let us take a specific scenario and discuss in detail how to solve the problem. To
simplify the situation, we will use a minimal number of computers.

Suppose we have an existing Windows NT 4.0 DNS server authoritative for the
net.dom domain. The server stores the forward and reverse zones: net.dom and
1.168.192.in-addr.arpa. All domain controllers and clients (including Windows
2000/XP/.NET computers) have to use this server as preferred.

Note Remember that reverse zones are not necessary for Active Directory, but rather
provide a fully operational DNS configuration.

The second DNS server (based on a Windows 2000 or Windows .NET server) has to
be configured to support all updateable resource records for an Active Directory
domain. Computer names and addresses are shown in the table below:

Computer's name and role FQDN IP address

NT4SRV5 (NT 4.0 DNS server) nt4srv5.net.dom 192.168.1.155

NETDC1 (Windows .NET DNS server) netdc1w.net.dom 192.168.1.2
NETDC4 (Windows .NET domain controller) netdc4.net.dom 192.168.1.4

By default, the dynamic registration of a host's name and address on the preferred
DNS server is enabled; so, in our scenario we need to disable registration on all
Windows 2000/XP/.NET computers to avoid error messages in the computers'
System logs. To do this, reset the Register this connection's addresses in DNS
flag on the DNS tab in the Advanced TCP/IP Setting window. Then, you have to
manually create a host record (type A) for each domain controller and computer on
the preferred server.

Creating Authoritative Zones

On the Windows .NET DNS server, we need to create four dynamic authoritative
zones necessary for domain functioning. These zones will answer the DNS queries
for specific IP addresses that could not be resolved by the preferred server. In our
scenario, all these zones' names have the net.dom suffix. (In general, these zones
can be either standard or Active Directory-integrated.)

The zones created will be the following:

ƒ _msdcs.net.dom
ƒ _sites.net.dom
ƒ _tcp.net.dom
ƒ _udp.net.dom

Furthermore, we also have to allow dynamic updates of these zones. Fig. 4.6
illustrates the result obtained in this preliminary step. Notice that each zone has SOA
and NS records. This means that the server that supports such a record can resolve
DNS queries stored in that zone.
Fig. 4.6: Creating dynamically updatable authoritative zones on a Windows .NET
DNS server

Delegating Names from the Main Authoritative Zone

It is now necessary to create the dynamic zone names in the domain authoritative
zone and delegate them to the Windows .NET DNS server, where the zones will be
stored and updated. All zone names are created as domains within the main
authoritative zone net.dom. (The procedure described below will also help you to
create a zone on any type of DNS server and delegate the zone to another DNS
server.) The following operations have to be carried out:

1. Right click the main zone name and select the New Domain command from
the context menu. Create four necessary domains.
2. Right click a created domain (e.g., _msdcs.net.dom) and select the New
Record command the context menu. Then you must select the NS Record
type and specify the DNS name of the server that stores the authoritative zone
with the same name. Repeat this step for each created domain.

The result that should be obtained is illustrated in Fig. 4.7. (A Windows NT 4.0 Server
SP6a was used.) All DNS queries for records that belong to the zones shown will be
addressed to the DNS server NETDC1 (that is authoritative to resolve these queries).

Fig. 4.7: Authoritative DNS server for domain net.dom and the zones delegated to the
dynamic DNS server NETDC1

In addition, we need to register the following records on the Windows NT 4.0 DNS
server in the domain authoritative zone:

ƒ Two type A (host) records (with corresponding PTR records) for the Windows
.NET computers: NETDC1 and NETDC4. (Such records will be necessary for
each domain computer.)
 ƒ A type A (host) record for the net.dom name (this record is needed for finding
a domain controller using a simple name lookup). To create such a record,
select a usual A Record, leave out its name, and specify the IP address of a
domain controller (NETDC4). (This record must be created for each domain
controller in the net.dom domain.)

The latter type A record requires additional attention. By design, this record is
dynamically updatable. The domain controllers' Netlogon service re-registers it after
each system boot. In our case, an update is impossible, so an error message will be
periodically generated in the System log. You may get rid of the problem by adding
the RegisterDNSARecords DWORD value (set the value to 0x0) to the registry subkey
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.

If you disable registration of A records using the RegisterDNSARecords subkey equal

to 0, two records will be deleted from the netlogon.dns file on the domain controller
NETDC4:

net.dom. IN A 192.168.1.4

and

gc._msdcs.net.dom. IN A 192.168.1.4

If a domain controller stores an application partition, a corresponding A record will

also be deleted, for example:

ForestDnsZones.net.dom. 600 IN A 192.168.1.4

Caution The RegisterDNSARecords value (being set to 0x0) also prevents the Netlogon
service from updating the host (type A) record for the gc._msdcs.net.dom
name. You must manually add this record, and re-register it if a Global
Catalog server's location is changed.

Resulting Configuration

Thus, we have covered the preliminary steps and now the domain controller NETDC4
is able to update (or first to create) all necessary SRV records. You need to restart
the Netlogon service or, preferably, reboot the system. (You can also use the nltest
/DSREGDNS command.) After this, you will get all updatable records on the Windows
.NET DNS server (NETDC1) (Fig. 4.8).
Fig. 4.8: The name structure of all needed SRV records, shown on a dynamic DNS
server

Now you can (and should) check all DNS logs and test the domain controller to be
sure that all records have been registered correctly.

Verifying the DNS Service

After you have installed DNS service on a Windows 2000/.NET Server, or if you
already have a functioning Microsoft DNS server (or a third party DNS server), you
may wish (or rather, need) to verify the DNS configuration. This is especially
important if you use an "outside" DNS server (a server running on a remote computer
or even in another organization). It is not enough that you yourself think that all DNS
parameters are properly set; rather, it is the system and program tests that should
confirm that everything is working fine.

You must check that the DNS server holds the correct forward and reverse zones
and that these zones allow dynamic record updates. For testing Microsoft DNS
Servers, it is helpful to use a general-purpose command-line DnsCmd.exe utility (that
is standard in Windows .NET, or has been included in the Windows 2000 Support
Tools pack). You can start it from any computer that has access to the inspected
DNS server. This utility can perform all operations necessary for remote maintenance
of a Microsoft DNS server.

Note In Chapter 5, "Installing Active Directory", we will discuss how to use

specialized utilities that also help to verify DNS configuration, such as
DCdiag.exe and NetDiag.exe.

To verify a zone, use the /enumzones command. You will get an output similar to the
following (which is the output for the simplest configuration):

C:\>dnscmd netdcl.net.dom /EnumZones

Enumerated zone list:

Zone count = 8
 Zone name Type Storage Properties
. Cache AD-Domain
_msdcs.net.dom Primary AD-Forest Update
1.168.192.in-addr.arpa Primary AD-Forest Update Rev
net.dom Primary AD-Domain Update

Comand completed successfully.

In this case, netdcl.net.dom is the Microsoft DNS Server name, "." corresponds to the
cached lookups, net.dom is an authoritative zone name and the DNS name of the
future domain, and 1.168.192.in-addr.arpa is a manually created reverse zone for the
private network 192.168.1.0 (255.255.255.0 mask; the address and mask depend on
your network configuration).

The Update parameter indicates whether or not the zone is dynamically updatable.
You can also check this property of zones (e.g., the net.dom zone) using the following
command. (Be careful; in the Windows 2000 version of DnsCmd, the AllowUpdate and
other zone properties are case-sensitive!):

C:\>dnscmd netdcl.net.dom /ZoneInfo net.dom AllowUpdate

Zone query result:
Dword: 1 (00000001)
Command completed successfully.

The value 1 indicates that this zone can be dynamically updated.

You must also verify DNS server responsiveness. It is recommended that you do this
before any DC creation in a Windows 2000 environment (in Windows .NET, similar
tests are built-in), in order to avoid serious domain problems in the future. Enter the
following command on the inspected computer (a client, or a server to be promoted):

C:\>nslookup 192.168.1.2

192.168.1.2 is the DNS server's IP address, specified in the TCP/IP properties of that
computer. The result will be similar to the following output:

Server: netdcl.net.dom
Address: 192.168.1.2

Name: netdcl.net.dom
Address: 192.168.1.2

Here, the Server reply contains the DNS server name, and Name is the name
resolved from the specified IP address. In this case, the names are the same
(because we have asked the DNS server for its own name), but you may want to
resolve any other IP addresses if their corresponding host names are registered on
the DNS server. You may also verify resolving DNS computer names into IP
addresses, for example: nslookup net.dom.

Note In contrast to DnsCmd.exe, the Nslookup command can be used with any type
of DNS servers.
If you receive any different outputs or error messages, like "Can't find server name
for address" or "Default servers are not available," you need to check all TCP/IP
properties, the connectivity and the existence of forward and reverse zones. The
DNS server may reply with the aforementioned messages, if, for example, the server
is operational but the reverse zone is absent or corrupted.

After a domain controller is created (and especially when the first DC in the forest is
created), it is strongly recommended that you verify the registration of all necessary
SRV records (see Chapter 3, "Domain Name System (DNS) as Main Naming
Service"). You can check an SRV record with the DNSCmd.exe utility by entering, for
example, the command (asking the SRV record registered by the PDC operations
master):

C:\>dnscmd netdcl.net.dom /EnumRecords _msdcs.net.dom _tcp.pdc /Type SRV

Returned records:
_Idap [Aging:3519689] 600 SRV 0 100 389 netdcl.net.dom.
Command completed successfully.

(Here, _msdcs.net.dom is the authoritative zone name.)

In conclusion, it is worth repeating that the best command for testing domain
controllers is the DcDiag.exe utility that reliably verifies DNS issues for a specified
computer. For example, if the following command returns no information, you may be
sure that the selected DC is "healthy":

C:\>dcdiag /s:netdc4.net.dom /q

All described procedures will help you to avoid some pitfalls of domain functioning.
Do not forget to set aside at least a half an hour for DNS testing. Take your time and
be thorough, or you could spend days trying to resolve potential problems, such as
"why is network reaction so slow?" or "why doesn't the new domain controller
replicate data?"

Setting the DNS Suffix

To set the primary DNS suffix on a computer running Windows 2000/XP/.NET, open
the System Properties window (press <Win>+<Break>, or right click My computer
on the Start menu or the desktop, and click Properties). Then, click Properties on
the Computer Name tab (in Windows 2000 — Network Identification), click
Change, and More. In the pop-up window (Fig. 4.9), enter the DNS name of the
domain to which the computer will belong.
Fig. 4.9: Setting the DNS suffix of the computer
Note Note that the Change primary DNS suffix when domain membership
changes checkbox must be normally set. This is especially important for
servers that have to be promoted.

You can manage the primary DNS suffix by using a group policy. See the
Primary DNS Suffix policy at the node Computer Configuration |
Administrative Templates | Network | DNS Client.

Chapter 5: Installing Active Directory

Overview

An administrator who is not yet closely acquainted with Active Directory must be
aware of the two following postulates:

ƒ The terms "creating a domain controller", "installing Active Directory", and

"promoting a server" are, in a sense, synonymous because they describe the
same process. You cannot install Active Directory without creating a domain
controller and vice versa.
ƒ Active Directory-based (Windows 2000 and Windows .NET) domains simply
do not work without DNS.

Administrators, even those who are quite experienced, should always remember that
the DNS is the "heart" of Active Directory domains, and many, many faults, all very
different by nature (e.g., issues related to the authentication process, or applying
group policies to users and computers), can derive from an improperly configured
DNS system. That is why troubleshooting practically every domain-level problem
should begin with verifying the DNS configuration. And that is why the DNS related
issues are mentioned in this chapter again.

This chapter does not contain step-by-step descriptions of all typical operations;
instead, it deals with only the most important issues.

Note In this chapter, "Windows DNS Server" means either a Windows 2000 DNS
Server or Windows .NET DNS Server, depending on the platform used.
Installing Domain Controllers

Active Directory can only be installed on an existing Windows 2000/.NET Server.

Active Directory installation is a process independent from installing/upgrading the
operating system itself. Moreover, you can demote a domain controller (or uninstall
Active Directory) to a member (or standalone) server (and promote it again if you
wish). The Active Directory Installation Wizard is used in both operations. This
behavior differs principally from the Windows NT 4.0 "rules", where the role of a
server (member server, Primary Domain Controller (PDC), or Backup Domain
Controller (BDC)) is specified during installation, and typically cannot be changed
without full system re-installation.

Therefore, you can create an Active Directory domain controller (DC) in the following
ways:

ƒ Start the Active Directory Installation Wizard on a Windows 2000/.NET Server

(standalone or member server) that has already been installed. The
DCpromo.exe utility is used in such cases. You can work with it either
interactively or in unattended mode (discussed later in this chapter). The result
will be a DC in a new domain or an additional DC in an existing domain.
ƒ Upgrade a Windows NT 4.0-based domain controller (PDC or BDC). You can
also upgrade a Windows 2000-based DC to Windows .NET. The
DCpromo.exe utility will start automatically after the upgrade to Windows
2000/.NET Server has been completed and the computer has been rebooted.
ƒ A Windows NT 4.0 PDC can only be upgraded to a DC in a new
domain.
ƒ A Windows NT 4.0 BDC can be upgraded to an additional DC in an
existing domain, or to a member server (if one chooses not to install
Active Directory).

Upgrading from a Windows NT/2000 Domain

We will not discuss this topic in detail, since all the necessary information pertaining
to it can be found quite easily in the Help and Support Center. Let us note the most
important aspects only.

To upgrade a Windows NT domain to Windows 2000/.NET, you must upgrade the

Primary Domain Controller (PDC) first. This ensures that you will keep all existing
users and groups. If the DNS service was not used in the Windows NT environment,
you must plan a DNS namespace and install a DNS server (of any type). It is also
possible to use a legacy DNS with the Windows 2000/.NET DNS Server (see an
example in Chapter 4, "Windows .NET DNS Server"). Provide a recovery plan in
case of an unsuccessful upgrade.

To upgrade a Windows 2000 domain to Windows .NET, or to install a Windows .NET-

based domain controller within a Windows 2000 domain, you must upgrade the
schema first, or in other words, prepare the forest and domains.
At first, you need to prepare the forest with the adprep /forestprep command that should
be run on the Schema Master. All changes must be replicated within the forest. If the
command has run without errors, continue the procedure.

During your second step, you will need to prepare each domain with the adprep
/domainprep command that should be run on the Infrastructure Masters separately.

You may also consider migrating Windows NT or Windows 2000 domains to a

pristine Active Directory domain by using such tools as Active Directory Migration
Tool (ADMT) and ClonePrincipal (see Chapter 13, "Migration and Directory
Reorganization Tools").

Adding Windows 2000 Domain Controllers to a Windows .NET Domain

You can promote a Windows 2000 server to be a domain controller in a Windows

.NET domain running at the Windows 2000 mixed or Windows 2000 native functional
levels only. Keep in mind that in this case, the new Windows 2000 DC will support
the Windows .NET schema version (26 or higher) rather than the schema version 13
designated for pure Windows 2000 domains.

If you try to add a Windows 2000 DC to a Wndows .NET (version 2002) level domain,
or to create a Windows 2000 domain within a Windows .NET (version 2002) level
forest, the Active Directory installation will fail. The system reports "An error with no
description has occurred" in the former case, or "Indicates two revision levels are
incompatible" in the latter.

Adding Windows .NET Domain Controllers to a Windows 2000 Domain

A Windows .NET server can be promoted to be a domain controller only in a forest

(domain) that supports the Windows .NET schema version. You can upgrade the
schema by using the adprep /forest and adprep /domain commands, and create a
Windows .NET domain controller; however in such a case, one should speak about a
Windows .NET forest (running at the Windows 2000 mixed functional level) rather
than a pure Windows 2000 forest (domain).

Note See also the section entitled "Adding a Windows NT 4.0 BDC to a Windows
2000/.NET Domain."

Requirements and Restrictions

The Active Directory can be installed only if several critical conditions are met. The
Active Directory Installation Wizard (DCpromo.exe) will check different parameters
depending on the type of DC that is being created. Among these conditions are the
following:

ƒ Active Directory can be installed only on a NTFS 5.0 formatted disk partition.
ƒ This partition must have at least 250 MB of free space. (This does not mean
that all that space will be employed at once; the default size of the Active
Directory database including the log files is about 40 Mbytes. However, the
system must have reserved space for normal work.)
ƒ If the server is a standalone computer, only a user that is a member of the
local Administrators group can start DCpromo.exe. If the server is a member
of a domain, members of the Domain Admins and Enterprise Admins groups
can also initiate promotion.

Important Remember that you cannot add a Windows NT 4.0 BDC to a

native mode Windows 2000 domain or create a Windows 2000-
based domain controller in a Windows .NET domain running at the
Windows .NET (version 2002) domain functional level. It is also not
possible to create a Windows 2000 domain in a Windows .NET
forest running at the Windows .NET (version 2002) forest
functional level (see details in Chapter 2, "Active Directory
Terminology and Concepts").

If you create a new Windows .NET domain in a forest running at

the Windows .NET (version 2002) forest functional level, the
domain functional level of the new domain will automatically be
raised to the same level.

ƒ When a new DC is created in an existing forest, any user that is not logged on
as a domain or enterprise administrator must provide sufficient credentials (a
pre-Windows 2000 logon name and a password; names in UPN form, e.g.,
admin@net.dom, are not acceptable):
ƒ Only members of the Enterprise Admins group can create new domains
(child domains or new trees). It is possible to have a pre-created new
domain in the forest (see the description of NTDSutil.exe in Chapter 10,
"Diagnosing and Maintaining Domain Controllers").
ƒ The members of the Domain Admins and the Enterprise Admins groups
are permitted to add a DC to an existing domain. The privileges to join a
computer to the domain and create the appropriate replication objects
can also be given to some user accounts.
ƒ TCP/IP protocol must be installed and configured on the computer. Typically,
domain controllers have static IP addresses (however, conceptually this does
not necessarily have to be the case).

Important It is possible to safely change the IP address of a domain controller

and then re-register all SRV records (see the previous chapter).
Sometimes, this change can affect directory replication, since the
controller's replication partners have to learn the new IP address.
However, this is not a crucial issue. Remember also that the
caching of DNS requests on the preferred DNS server and clients
can prevent the new address from "propagating" in a moment.

ƒ The computer should have the primary DNS suffix (see the previous chapter).
This is a critical requirement if the computer is also going to act as a DNS
server. For an ordinary domain controller, the Change primary DNS suffix
when domain membership changes checkbox must at least be set. The
suffix will be properly set if the computer is a member of a domain, and you
need not change anything.
 ƒ An already deployed DNS service must be available. If a legacy or third party
DNS server is used, it should meet the Active Directory requirements and be
properly configured. If the promoted server is the first DC and there is no DNS
server in the network, you must allow the Active Directory Installation Wizard
to install and configure the Windows DNS server.

Important If you create the first DC and enable the DNS installation and
configuration on the same computer, you must assign an
applicable IP address (e.g., 192.168.1.1) to the computer and
specify that address as the preferred DNS server address. The
Active Directory Installation Wizard will not do this itself, and as a
result, the new domain (forest) will not be operational!
Note A reverse DNS zone is not required for Active Directory. Nevertheless, it
is recommended that you configure one for the other applications that
use it.

ƒ The server NetBIOS name must be unique in the domain. The NetBIOS (pre-
Windows 2000) name of new domain must be unique in the forest.
ƒ If a child domain (or a new tree) is created, the parent and forest root domains
must exist and be accessible. This means that you cannot create a child
domain — e.g., subdom.net.dom — if the net.dom domain does not exist.
ƒ Without going into detail and in order to considerably simplify the situation, it is
possible to say that all FSMO masters should be available for starting and
successfully completing server promotion. Otherwise, you should always know
and remember which FSMO masters are required for each specific type of
domain controller created (an additional DC, a new tree, and so on).

Note By default, all domain controllers will be created in the Domain Controllers OU
in the domain partition.
Note The computer SID remains the same after the Active Directory installation or
removal.
Note Let us suppose a server was previously a domain controller and has been
demoted, and that you wish to install the Active Directory on to it again. It may
be useful to make sure that the folders where the Active Directory files (the
database and logs) were stored have been deleted (by default, the
%SystemRoot%\NTDS folder is used). Moreover, if the Distributed File System
(DFS) is not used on this computer, stop the File Replication Service by using
the net stop ntfrs command and delete the contents of the
%SystemRoot%\ntfrs\jet folder. Then restart the service: net start ntfrs.
Important During one of the preliminary steps, the Active Directory Installation
Wizard asks for your "Directory Services Restore Mode Administrator
Password". This password is only used in the logon process after you
have pressed the <F8> key in the boot menu and selected the Directory
Services Restore Mode. The password is not used often, so try not to
forget it (this does happen!).
Verifying DNS Configuration

DNS testing is one of the most important steps in preparing a server for promotion.
Any undetected errors in DNS configuration may result in an inoperable domain
controller. The following DNS related faults are possible:

ƒ The computer has no settings for the preferred DNS server.

ƒ The specified DNS server does not host the specified authoritative zone
(domain name).
ƒ The authoritative zone exists, but is not updatable.

Microsoft has done a great job in extending the initial functionality of the DCdiag and
NetDiag utilities from the Support Tools to allow an administrator to verify the DNS
configuration in a few seconds. (For a Windows 2000 environment, you can
download updated versions from the Microsoft website. For additional information on
these tools, see Chapter 10, "Diagnosing and Maintaining Domain Controllers" and
Chapter 11, "Verifying Network and Distributed Services.")

A further step has been taken in the Windows .NET Server family: the Active
Directory Installation Wizard diagnoses DNS-related and forest configuration issues
and stops server promotion if any problems exist. Nevertheless, you can use the
DCdiag and NetDiag utilities on computers running Windows .NET, too.

Important All tests described below verify DNS only; connectivity with existing
domain controllers is not checked. The Active Directory Installation
Wizard verifies both DNS and connectivity (including authentication)
issues.

If a preferred DNS server's IP address is not specified on the tested computer in the
TCP/IP Properties window, the dcdiag /test:DcPromo or dcdiag /test:RegisterInDNS
command outputs a message with the error 9852, which means "No DNS servers
configured for local system."

The following command reports that you can safely create an additional domain
controller in an existing Windows 2000 or Windows .NET domain (net.dom in this
example):

C:\>dcdiag /test:DcPromo /DnsDomain:net.dom /ReplicaDC

Starting test: DcPromo
The DNS configuration is sufficient to allow this computer to be
promoted as a replica domain controller in the net.dom domain.

...
DNS configuration is sufficient to allow this domain controller to
dynamically register the domain controller Locator records in DNS.

The DNS configuration is sufficient to allow this computer to

dynamically register the A record corresponding to its DNS name.

......................... netdc4 passed test DcPromo

In such a case, you can begin to promote the server. (For compactness, some lines
are skipped in this output. When the Windows 2000 version of the tool is used, all
tests executed (both successful and failed) end with the same "passed test" line. The
Windows .NET version reports results more correctly.)

The following output indicates that the authoritative zone (w2000.dom) exists, but
there are no SRV records registered by the existing domain controller(s):

C:\> dcdiag /test:DcPromo /DnsDomain:w2000.dom /ReplicaDC

Starting test: DcPromo
This computer cannot be promoted as a domain controller of the
w2000.dom domain. This is because either the DNS SRV record for
_ldap._tcp.dc._msdcs.w2000.dom is not registered in DNS, or some
zone from the following list of DNS zones doesn't include
delegation to its child zone: w2000.dom, dom and the root zone.
Ask your network/DNS administrator to perform the following
actions: To find out why the SRV record for
_ldap._tcp.dc._msdcs.w2000.dom is not registered in DNS, run the
dcdiag command prompt tool with the command RegisterInDNS on the
domain controller that did not perform the registration.

...
DNS configuration is sufficient to allow this domain controller to
dynamically register the domain controller Locator records in DNS.

The DNS configuration is sufficient to allow this computer to

dynamically register the A record corresponding to its DNS name.

......................... netdc4 failed test DcPromo

This might be a serious problem: the existing DC for the specified domain could be
promoted incorrectly. You should verify the DNS configuration and make the DC re-
register all its SRV records. Then run DCdiag on that DC.

In all cases when updating of an authoritative zone is not enabled on the DNS server
(or the server does not support dynamic updates), the command output will be similar
to the following:

C:\>dcdiag /test:DcPromo /DnsDomain:dotnet.dom /ReplicaDC

Starting test: DcPromo
The DNS configuration is sufficient to allow this computer to be
promoted as a replica domain controller in the dotnet.dom domain.

Messages logged below this line indicate whether this domain

controller will be able to dynamically register DNS records
required for the location of this DC by other devices on the
network. If any misconfiguration is detected, it might prevent
dynamic DNS registration of some records, but does not prevent
successful completion of the Active Directory Installation Wizard.
However, we recommend fixing the reported problems now, unless you
plan to manually update the DNS database.

This domain controller cannot register domain controller Locator

DNS records. This is because either the DNS server with IP address
192.168.1.2 does not support dynamic updates or the zone
 dotnet.dom is configured to prevent dynamic updates.
...

............. netdc4 failed test DcPromo

Detailed instructions on configuring the DNS server are also displayed. You must
follow them. To check whether a zone is updatable, it is also possible to use the
command

dcdiag /test:RegisterInDNS /DnsDomain:dotnet.dom

which produces a similar output.

Other parameters of the dcdiag /test:DcPromo command allow you to test whether you
can create a child domain, new tree, or new forest in the current domain structure.
The command's messages are clear, and it is not necessary to place them all here.

If the preferred DNS server is specified incorrectly or not accessible, or if the

authoritative zone did not configure on the server, the following command will
discover the problem and instruct you on what to do:

C:\>dcdiag /test:RegisterInDNS /DnsDomain: net2.dom

Starting test: RegisterInDNS
Please verify that the network connections of this computer are
configured with correct IP addresses of the DNS servers to be used
for name resolution. If the DNS resolver is configured with its
own IP address and the DNS server is not running locally, the
DcPromo will be able to install and configure local DNS server,
but it will be isolated from the existing DNS infrastructure (if
any). To prevent this, either configure local DNS resolver to
point to existing DNS server or manually configure the local DNS
server (when running) with correct root hints.

If the DNS resolver is configured with its own IP address and the
DNS server is not running locally, the Active Directory
Installation Wizard can install and configure the local DNS
server. However, if this server is not connected to the network
during domain controller promotion then admin needs to
appropriately configure root hints of the local DNS server after
the completion of the domain controller promotion.

DnsUpdateTest returned 1460. The A record test is thus

inconclusive.

......................... netdc4 passed test RegisterInDNS

Do not forget that you should also test the DNS configuration (registration of the SRV
records) after the server promotion has been completed.

Running the Active Directory Installation Wizard

There are two ways to start the Active Directory Installation Wizard in interactive
mode:
 ƒ Choose the Start | All Programs | Administrative Tools | Configure Your
Server Wizard command, and then assign the domain controller role to the
server.
ƒ Open the Run window and enter dcpromo.exe.

In general, you have four options for installing the Active Directory; these are
graphically represented in Fig. 5.1. (Installation from a backup media is described
later in this chapter.) The selections, which you should consequently make on the
wizard's pages[1], are listed below for each option:

Fig. 5.1: Four scenarios for creating a new domain controller

1. The first Active Directory installation in the network, or creating a new forest:
o Domain controller for a new domain
o Domain in a new forest

Note Creating a new forest is the only option that does not require any existing
domain (or domain controller). In all other cases, the Schema and the
Configuration partitions are replicated from a source domain controller
located in either an existing domain (for an additional DC), the parent (for
a child domain), or the root domain (for a new tree). Even if you are
installing a Windows .NET-based DC from backup media, some other
domain controllers must be accessible (dealt with later in this chapter).

2. Additional DC in any existing domain:

o Additional domain controller for an existing domain
3. Creating a new child domain:
o Domain controller for a new domain
o Child domain in an existing domain tree
 4. Creating a new tree (a root domain with a non-contiguous DNS name) in an
existing forest:
o Domain controller for a new domain
o Domain tree in an existing forest

Depending on the selected option, the wizard will ask you to enter a domain name. It
can be the name of an existing domain, parent domain, or forest root domain. In
Windows 2000, it is always recommended that you specify a DNS name because
DNS name resolving must already be operational at this stage. (Although the wizard
can sometimes accept NetBIOS domain names, this does not guarantee successful
execution of the subsequent Active Directory installation steps.) In Windows .NET,
you simply have no alternatives.

Caution During the next step, you must specify the domain NetBIOS name. You can
choose a name different from the one offered by default if you like (e.g., if
the DNS domain name is net.dom, then the default NetBIOS name will be
NET). If Service Pack 1 or later is not installed on a server running Windows
2000, you will get an error when publishing a printer in Active Directory (see
Chapter 8, "Common Administrative Tasks").
Note During Active Directory installation, synchronization with existing domain
controllers is carried out. It is possible to stop that process by clicking the
Finish Replication Later button in the wizard window. The domain controller
will be advertised when the replication is completed (after the computer has
been rebooted).

DNS Issues

In Windows .NET, the Active Directory Installation Wizard will stop if a preferred DNS
server address is not configured on the computer and you simply will not be able to
continue with Active Directory installation.

In Windows 2000, the message shown in Fig. 5.2 may appear at a certain moment
during the execution of Active Directory Installation Wizard. It means one of the
following:

ƒ There is no DNS server in the network (you are going to install the DNS server
and the domain controller on the same server).
ƒ No address or an incorrect preferred DNS server address has been entered in
the computer's TCP/IP Properties window. (This is a configuration error that
the system identifies as the absence of a DNS server.)
ƒ There is no authoritative zone for the new domain on the specified DNS
server.

Fig. 5.2: This window displays warnings about potential problems with the preferred
DNS server
The warning window will not appear if a DNS server address has been entered
correctly and the authoritative zone has been configured on this server. However, this
zone may not allow dynamic updates. In such a case, the wizard page "Configure
DNS" (Fig. 5.3) will be next. A similar window will appear on a Windows. NET server
that has no preferred DNS server and is promoted to be the first forest domain
controller.

Fig. 5.3: At this point, you must decide whether or not to install the DNS server

This step is a critical point in the installation process, because whether the new
domain configuration will work or not depends on what you do here. You only have
three options:

ƒ Click Cancel, which will terminate the wizard, and verify the DNS
configuration. You must select this option if the promoted server is not the first
controller in the domain (forest). If you do not, the Active Directory installation
on this server will definitely be unsuccessful: the server will not be able to
locate other domain controllers and replicate the Active Directory information
from them.
ƒ Agree with the default option and install the DNS server and domain controller
on the same computer.
ƒ If you are using a legacy DNS service and have the required sub-zones
delegated to a DNS server that allows dynamic updates, select the No, I will
install and configure DNS myself option and continue the Active Directory
installation.

You may also refuse the default option and continue the installation process if the
promoting server is the only DC in the network and if for some reason, you are
planning to connect it to a fully configured DNS server only after installing Active
Directory and before the first DC reboot. This approach may not seem very logical,
but is technically quite possible. When the domain controller boots for the first time, it
will register all necessary resource records on the DNS server (but in the forward
zone only, since the wizard does not create a reverse zone).
And only if the DNS configuration fully meets all the necessary requirements, you will
not see any of the wizard pages described above, and the wizard will go onto the
subsequent steps.

The Active Directory Installation Wizard on a Windows .NET server provides an

exhaustive DNS diagnostic that allows an administrator to easily locate possible
problems. Basically, problem origins and an administrator's actions are the same as
those described above. For example, if the wizard cannot find the authoritative zone
for a new specified domain, you will see results of DNS queries performed (Fig. 5.4).
Depending on the situation, you can verify the DNS configuration and re-run the DNS
test, or install the DNS server.

Fig. 5.4: DNS diagnostics reveal name resolution problems for a future domain
controller

If you add a DC to an existing domain and the wizard could not get the DNS name of
a DC located in that domain, you will see a window similar to the one shown in Fig.
5.5. The domain name (net.dom) as well as the preferred DNS server address
(192.168.1.2) are displayed here, and should be verified.
Fig. 5.5: Failed DNS diagnostics for a server promoted to be an additional domain
controller

Fig. 5.6: An example of a successful DNS test

Fig. 5.5 illustrates an example of a successful DNS test. Normally, every promotion
operation should be completed with a similar result. In such a case, you can be sure
that the new domain controller will not have name resolution problems.

Completing and Testing the Installation

After completing the Active Directory installation, the system automatically installs
and configures the Windows DNS Server if this operation has been requested.

After system restart, you can logon to the created domain with the local administrator
credentials. The local administrator of the server that has been promoted to the first
domain controller in a new forest will become a member of the following groups:

ƒ Administrators (built-in local group)

ƒ Domain Admins (is a member of the Administrators group)
ƒ Domain Users (is a member of the built-in local Users group)
 ƒ Enterprise Admins (is a member of the Administrators group)
ƒ Group Policy Creator Owners
ƒ Schema Admins

Note Sometimes, while working on domain controllers in the test environments,

administrators attempt to logon to a domain using a domain user account, and
encounter the "The local policy of this system does not permit you to logon
interactively" message. Open the Default Domain Controllers Policy GPO, and
click the Computer Configuration | Windows Settings | Security Setting |
Local Policies | User Rights Assignment node. Find the Log on locally policy.
This policy is defined by default, and only the following groups can logon
locally: Account Operators, Administrators, Backup Operators, Print Operators,
and Server Operators. Therefore, "normal" users cannot logon on domain
controllers. If you wish (and if security requirements permit), add the
Authenticated Users or Everyone group to this list, and you will be able to logon
locally using any account.

If any applications are running on a Windows NT 4.0-based server that is a member

of an Active Directory domain, verify that the Everyone group has been included in
the Pre-Windows 2000 Compatible Access group with the net localgroup "Pre-Windows
2000 Compatible Access" command. If not, type net localgroup "Pre-Windows 2000 Compatible
Access" everyone /add at the command prompt on a domain controller computer and
then restart the domain controller computer. Do not perform this operation by using
the Active Directory Users and Groups snap-in!

On Windows .NET domain controllers, the Everyone group does not include the NT
AUTHORITY\ANONYMOUS LOGON group. Therefore, if backward compatibility is
required, add both security groups to the Pre-Windows 2000 Compatible Access
group.

You can manage backward compatibility during a server promotion (by selecting the
appropriate permissions option), as well as at any moment (manually, by using the
net localgroup command).

Log Files

The events that have taken place during Active Directory installation are written in the
logs located in the %SystemRoot%\Debug folder (and are especially useful if the
installation has crashed):

ƒ csv.log
ƒ DCPROMO.LOG
ƒ dcpromohelp.log
ƒ dcpromoui.log
ƒ NetSetup.LOG
ƒ NtFrs_xxxx.log
ƒ NtFrsApi.log
Installation from a Backup Media

A Windows .NET server can be promoted using the System State data from an
existing Windows .NET domain controller. (Such a feature is absent in Windows 2000
domains.) This approach considerably reduces the initial replication time if slow dial-
up lines are used or the Active Directory database is large enough. However, the
promotion process still requires network connectivity with the existing domain!

The only restriction of this approach is that the replicas of any application partitions
existing on the backed up domain controller will not be created automatically on the
new DC. You should manage the application partitions manually (see the NTDSutil
description in Chapter 10, "Diagnosing and Maintaining Domain Controllers").

To install an additional DC in an existing domain:

1. Backup the System State of a DC located in the domain where you are
creating an additional DC. Make sure that the Automatically backup System
Protected Files with the System State box is cleared (you do not need the
system files!). (See additional information on system backup in Chapter 8,
"Common Administrative Tasks.")
2. Copy the backup file to the server that is to be promoted.
3. Restore the System State data to any empty folder on the target server.
4. To do so, start the NTBackup utility, click Catalog a backup file on the Tools
menu, and enter the backup file name. Check the System State box, select
Alternate location from the Restore files to list, and enter the target folder
name (Fig. 5.7). Click Start Restore. In the Confirm Restore window, click
OK.

Fig. 5.7: Restoring the System State to an alternate location

5. When the restore operation is completed, enter dcpromo /adv in the Run window
(click Start | Run). The Active Directory Installation Wizard will start.
6. On the "Domain Controller Type" wizard page, select the Additional domain
controller for an existing domain option and click Next. If you select the
other option, a normal DC creation procedure will begin.
 7. On the "Copying Domain Information" page, select the From these restored
backup files option, enter the backup file name, and click Next.
8. If the System State was backed up from a DC that was a Global Catalog
server, the wizard will ask you whether to configure the new DC as a GC
server ("No" by default).

Then, the installation process will proceed as a usual server promotion.

[1]
The Active Directory Installation Wizard pages in Windows .NET are slightly differ
from the wizard's pages in Windows 2000; however, all operations' general concepts
are the same in both versions.

Missing part

Adding Domain Client Computers

When a computer running Windows NT/2000/XP/.NET system joins an Active

Directory domain, a corresponding computer account is always created in the
Computers container. You can then move this account to any desired OU or
container. There is, however, an alternative way. It is possible to create an account
before actually adding the computer to the domain (manually, or with the netdom ADD
command). Pre-create the account in any container, and then add the computer
using this account.

There are two main problem sources that can prevent domain members running
Windows 2000/XP/.NET from correctly joining or working with a domain:

ƒ DNS
ƒ Windows Time service

Verifying the Preferred DNS Server

To add a client computer (a workstation running Windows 2000/XP or a member

server running Windows 2000/.NET) to an Active Directory domain, you should first
verify the client's DNS settings and the availability of a DC that belongs to that
domain. The updated version of the NetDiag.exe utility is the best instrument for that
purpose. The test command and successful sample output are shown below:

C:\>netdiag /test:DsGetDc /d:net.dom /v

...
DC discovery test. . . . . . . . . : Passed

Find DC in domain 'NET':

Found this DC in domain 'NET':
DC. . . . . . . . . . . : \\netdcl.net.dom
Address . . . . . . . . : \\192.168.1.2
Domain Guid . . . . . . : {36622959-3372-43E6-BBBA-8D77CAA1FC46}
Domain Name . . . . . . : net.dom
Forest Name . . . . . . : net.dom
DC Site Name. . . . . . : NET-Site
Our Site Name . . . . . : NET-Site
Flags . . . . . . . . . : PDC emulator GC DS KDC TIMESERV GTIMESERV WRIT
 ABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE 0x8

Find PDC emulator in domain 'NET':

Found this PDC emulator in domain 'NET':
DC. . . . . . . . . . . : \\netdcl.net.dom
...

Find Windows 2000 DC in domain 'NET':

Found this Windows 2000 DC in domain 'NET':
DC. . . . . . . . . . . : \\netdcl.net.dom
...

The command completed successfully

This result indicates that you can add the tested computer to the specified domain.

When a client computer is already added to a domain, you may verify that this
operation has been successfully completed. Both command — netdiag /test:DsGetDc
and netdiag /test:DcListx — should run successfully. The following example indicates
that problems exist: the command reports that for some reason the client cannot
access the DC:

C:\>netdiag /test:DcList /d:net.dom /v

...
DC list test . . . . . . . . . . . : Failed

Find DC in domain 'NET':

Found this DC in domain 'NET':
DC. . . . . . . . . . . : \\netdcl.net.dom
...
You don't have access to DsBind to netdcl (192.168.1.2).
[ERROR_ACCESS_DENIED]
List of DCs in Domain 'NET':
netdcl.net.dom

The command completed successfully

DNS Settings and Domain Name

Make sure that the primary DNS suffix is properly set. (It is enough if the Change
primary DNS suffix when domain membership changes checkbox is always set;
in that case, the suffix is changed automatically and you need not worry about it.) An
improper value may affect DNS registration of the computer name, which results in
various errors, such as a failed secure channel, authentication problems, etc.

When a Window XP/.NET client computer is deleted from a domain, its primary DNS
suffix will be cleared, and as a result, its name is de-registered from the domain's
authoritative zone. The primary DNS suffix will remain on clients running Windows
2000 and therefore, the computer name will still be present in the domain zone,
whereas the computer itself no longer belongs to that domain.

If a computer runningd Windows 2000/XP/.NET is added to a domain, it is strongly

recommended that you specify the DNS name of the domain rather than its NetBIOS
name. (Nevertheless, the latter case is also possible, especially if you perform the
operation on a remote computer.) In any case, when a computer has been added to
a domain, verify that a secure channel has been established between the computer
and a domain controller. On a local computer, it is possible to use the commands
nltest /query and nltest /sc_query (see details in Chapter 11, "Verifying Network and
Distributed Services"). On a remote computer, use the following command
parameters:

C:\>netdom VERIFY xp-pro3 /D: net.dom

or

C:\>nltest /sc_query: net.dom /server: xp-pro3

When the TCP/IP settings are incorrect on a Windows XP/.NET computer, or the
specified domain is not accessible, you will see a pop-up window similar to the one
shown in Fig. 5.5. A Windows 2000 computer will report, "The specified domain
either does not exist or could not be contacted". If this happens, you will need to
check the computer network configuration and accessibility of domain controllers
(see later "Verifying DNS and Availability of Domain Controllers").

While adding a client computer running Windows 2000/XP/.NET to a domain, you

may specify the NetBIOS name of the domain. If, nevertheless, the computer can find
a domain controller belonging to that domain, it will be added to the domain.
However, if the computer's TCP/IP settings are incorrect, the following NetDiag tests
may fail (the Windows 2000 and Windows .NET version of NetDiag may produce
slightly different results):

ƒ DC discovery test
ƒ DC list test
ƒ Trust relationship test
ƒ Kerberos test (skipped with a diagnostic message "Cannot find DC")
ƒ LDAP test

Therefore, it is always recommended that you verify the computer's DNS settings if
the computer experiences problems such as slow system startup or access to shared
resources; improper group policies applied; failed start of domain administrative tools,
and so on.

Windows Time Service

When you add a Windows XP/.NET client to a domain, the client computer will then
periodically synchronize its clock with the PDC Emulator of that domain. The register
value Parameters\Type that controls the Windows Time service and is set by default to
NTP, will be changed to NT5DS (see details in Chapter 2, "Active Directory
Terminology and Concepts"). The following command will help you to see the
computer time offset and the name and IP address of a domain controller that serves
as the timeserver:

C:\>w32tm /monitor /domain:net.dom

A domain client running Windows 2000 does not automatically synchronize its clock
with the domain. You may manually set both registry values — Parameters\ServerType
and Parameters\Type — to NT5DS and thus enable time synchronization with the PDC
Emulator. The following command will display the name and IP address of the
timeserver:

C:\>w32tm -source -v
Note Windows 2000 and Windows .NET systems have different versions of the
W32tm utility. Therefore, you need to select the appropriate parameters for the
version that you happen to be using.

Adding a Windows NT 4.0 BDC to a Windows 2000/.NET Domain

You may, for some reason, need to have the Windows NT 4.0-based Backup Domain
Controllers (BDC) in a Windows 2000/.NET domain. The only problem that may (or
rather, will) arise during the BDC installation is that the Windows NT 4.0 Setup
program creates the wrong type of account. A pop-up window with the following error
message will appear:

The Machine Account for This Computer either does not exist or is
inaccessible.

If, for example, the account NT4BDC5 was used when installing BDC, the following
error will be registered in the System log on the Windows 2000- or Windows .NET-
based domain controller that owns the PDC Emulator FSMO role:

...
Event Source: SAM
...
Event ID: 12298
...
Description:

x The account NT4BDC5$ cannot be converted to be a domain controller

account as its object class attribute in the directory is not computer
or is not derived from computer. If this is caused by an attempt to
install a pre Windows 2000 domain controller in a Windows 2000 domain or
later, then you should precreate the account for the domain controller
with the correct object class.

As a result, you will not be able to proceed with the BDC installation. See the
instructions below.

Windows 2000 Domain Scenario

To pre-create a computer account for a Windows NT 4.0 BDC, log on to the domain
using an administrative account on any Windows 2000 domain member, and perform
the following operations:

1. Start the Server Manager (enter srvmgr at the command prompt), which is
supported with Windows 2000. (Do not use the Server Manager from the
Windows NT 4.0 installation!)
2. Select Add to Domain from the Computer menu.
 3. Select Windows NT Backup Domain Controller, enter the BDC computer
name, and click Add, then Close. A "Windows NT Backup" type account will
appear in the computer list. The account will be created in the "default"
Domain Controllers OU.

Then you can install a Windows NT 4.0 server as BDC. Or, if the BDC was already
installed, it may be necessary to use NetDom.exe to reset the computer account
password.

The following operations will yield the same result as described above:

1. Open the Active Directory Users and Computers snap-in and create a
computer object in any container.
2. Start the ADSI Edit snap-in, find the userAccountControl property (decimal
INTEGER type; see ADS_USER_FLAG_ENUM in the ADSI SDK) for the new
computer object, and change the value from 4128 (0x1020 —
WORKSTATION_TRUST_ACCOUNT) to 8192 (0x2000 —
SERVER_TRUST_ACCOUNT).

The third way to create a computer account for a BDC is to install the Support Tools
pack and enter the following string at the command prompt (this command does not
work on Windows .NET domains!):

netdom ADD <BDC-computer-name> /D:<domain-name> /DC

The account will be created in the "default" Domain Controllers OU.

Windows .NET Domain Scenario

To add a Windows NT 4.0 BDC to a Windows .NET domain (that should run at the
Windows 2000 mixed functional level!), use the following operations:

1. Open the Active Directory Users and Computers snap-in and select any
applicable container.
2. Select the New | Computer command from the Action menu.
3. Enter the computer name and set the Assign this computer account as a
pre-Windows 2000 computer and Assign this computer account as a
backup domain controller checkboxes. Click OK.
4. Install a Windows NT 4.0 server as BDC or continue a failed installation.

Raising Functional Levels. Switching to Native Mode

If there isn't a Windows NT 4.0 BDC in a Windows 2000 domain, this domain can be
switched from the default mixed mode to native mode. In Windows .NET domains,
the "functional level" term is used in such a case. You can raise the domain
functional level to a level that depends on the types of domain controllers used in the
domain. If there are no Windows NT 4.0- or Windows 2000-based domain controllers
in the entire Windows .NET forest, it is also possible to raise the forest functional
level (see details in Chapter 2, "Active Directory Terminology and Concepts").
Remember that only the type of controllers located in a domain affect the domain
mode or level; the domain clients (with or without Active Directory client software) will
"see" this level of functionality of an Active Directory domain (see Chapter 2, "Active
Directory Terminology and Concepts" for just about the only exception.)

To change a domain mode or functional level, use either snap-in:

ƒ Active Directory Users and Computers

ƒ Active Directory Domains and Trusts

In the Windows 2000 environment, select a domain and open its Properties window.
Click the Change Mode button on the General tab and wait 15 minutes for
replication of the changes to all DCs in the domain. Operations in the Windows .NET
environment will be described in the "Raising Functional Level" section in Chapter 7,
"Domain Manipulation Tools."

To check that the domain is now in the native mode (or at a higher level), you may try
to create a universal group or to add a domain local group to another local group.

To view a domain's mode or level, it is convenient to use the Active Directory

Domains and Trusts snap-in. You can quickly select any domain and see its mode
(level).

Establishing Domain Trusts

Creating inter-domain trusts is a rather simple operation if one understands the trusts
mechanism used in Active Directory. The Active Directory Domains and Trusts
snap-in is used for all work with any trusts in Active Directory domains. You can
easily select domains in the snap-in's tree window and look up existing trusts.
However, to verify, create, or remove trusts, you must provide the credentials of a
user that has privileges to modify trusts.

Let us discuss various trust types by using a sample domain structure shown in Fig.
5.10.
Fig. 5.10: A sample domain structure that illustrates various trust types

These are the domains and trusts shown in Fig. 5.10:

ƒ net.dom — the forest root domain that has a Child relationship with its child
domain.
ƒ subdom.net.dom — a child domain that has a Parent relationship with the root
domain.
ƒ net2.dom — a tree root domain that is connected with the Tree Root
relationships with the forest root domain.

All of the above-mentioned trusts have been created automatically; they are transitive
and two-way. You can, for example, logon to the subdom.net.dom domain (i.e., you
can specify a user account located in that domain) on a computer that belongs to the
net2.dom domain. To speed up the authentication process, you may want to create
an explicit one-way or two-way trust between these domains:

ƒ The subdom.net.dom and net2.dom domains are also connected with a trust
marked as Shortcut (shown only for the net2.dom domain).

You are also able to establish trust relationships (one- or two-way) with other Active
Directory forests or Windows 4.0-based domains:

ƒ w2000.dom — the root domain of a foreign Windows 2000-based forest.

ƒ NT4DOM — an independent Windows 4.0-based domain. The relationships
with such domains, as well as with other Active Directory forests, are marked
as External.

In addition, Windows .NET-based forests that operate at the Windows .NET (version
2002) functional level can be linked with the Forest transitive relationships:
 ƒ dotnet.dom — a forest root domain that has two-way forest trusts with the
net.dom forest

Figs. 5.11 and 5.12 illustrate all listed trust types as they are represented in the
Active Directory Domains and Trusts snap-in.

Fig. 5.11: Various types of trusts existing in Active Directory forests

Fig. 5.12: The shortcut trust between two domains within the same forest
Note Keep in mind that any trusts are always possible between Windows NT 4.0,
Windows 2000, and Windows .NET domains, regardless of the mode in which
the Active Directory domains are working.

Only shortcut, external, or forest trusts can be removed. You cannot delete
"default" (Parent-Child and Tree Root) trusts by using the Active Directory
Domains and Trusts snap-in or other tools. This can only be done by
removing the appropriate domain or tree.

Verifying the Trust State

The state of all existing trusts can be verified. Select the desired trust on the Trusts
tab (see Fig. 5.11); click Properties, and then Validate[1]. Normally, you will get the
message: "The trust has been verified. It is in place and active". You may be asked
for additional credentials in another domain (e.g., if you test the "parent-child" trust
from a child domain, you will be asked for credentials in the parent domain).

Creating and Deleting the Shortcut and External Trusts

Basically, the trust creation process is the same on all platforms: for a one-way trust,
you should first create an outgoing trust in the trusting domain, and then create the
corresponding ingoing trust in the trusted domain. For a two-way trust, this process
should be executed twice: it is necessary to create both outgoing and ingoing trusts
in each domain. For the sake of simplicity, we will discuss trust creation in a Windows
.NET domain only.

For a Windows .NET domain, the trust creation process is simplified, since the wizard
allows you to create any trusts in both domains simultaneously (in that case, you
must specify the appropriate credentials in both trusting and trusted domains).

To discuss the trust creation in detail, let us use a sample domain structure shown in
Fig. 5.10. In this structure, you may create a shortcut to speed up the access from
the net2.dom to the resources located in the subdom.net.dom domain. The
subdom.net.dom domain (the trusting domain) will then trust the net2.dom (the
trusted domain).

Within a forest, users can log on to any forest domain on computers that can belong
to any domain in the same forest. This is possible due to transitive Kerberos trusts
existing within the entire forest. However, before a shortcut trust is created, there is
no direct trust between the net2.dom and subdom.net.dom domains, and the
authentication process should run over all domains that have direct trusts and
connect these two domains. A shortcut trust can speed up this process.

All direct trusts can be verified with the NLtest command. Initially, this command fails
on a DC in the subdom.net.dom domain (because there is no direct connection
between the current and specified domains, and there are no trusted servers in the
net2.dom domain):

C:\>nltest /sc_query:net2.dom
I_NetLogonControl failed: Status = 1355 Ox54b ERROR_NO_SUCH_DOMAIN
To create a shortcut trust:

1. Open the Active Directory Domains and Trusts snap-in, select the trusted
domain (net2.dom), and open the Properties window.
2. Click New Trust. The New Trust Wizard will help you to do all preliminary
work to create trusts of any type. Click Next.
3. Enter the name of the trusting (or target) domain (subdom.net.dom) and click
Next.
4. On the next wizard page (Fig. 5.13), you should select the trust direction. By
default, the wizard suggests that you create a two-way trust (therefore, the
domain selected earlier will be both a trusting and trusted domain). However,
in our case, it is necessary to choose the second option — One way:
incoming. Then click Next.

Fig. 5.13: Selecting the direction of the trust

5. The next wizard page (Fig. 5.14) will appear on Windows .NET-based DCs
only. If the target domain is based on domain controllers running Windows
2000 or Windows .NET, you can create the trust in both domains at the same
time. You should only provide the appropriate credentials for the target
domain.
 Fig. 5.14: You can create a trust in either the local domain only or both
domains at the same time

If the other "half" of a trust is a Windows NT 4.0 domain, you can create it in
the local domain only; the other side of the trust must be created on a DC in
the trusting domain by an administrator or a user that has trust creation
privileges in that domain. (Windows NT 4.0 does not support system calls
necessary for the "remote" trust creation.)

If you leave the default option, the wizard will ask you for the trust password
on the next step. This password is an arbitrary character sequence, which you
must reproduce when the other side of the trust is created on the target
domain.

In our case, we can select the lower option and go further.

6. On the next wizard page, you need to enter the credentials of a user with
appropriate privileges in the trusting (target) domain and click Next.
7. All selections are complete now. Click Next.
8. If the selections have been made properly, you will see the "Trust Creation
Complete" wizard page. Click Next.
9. On the next wizard pages, you may confirm the creation of outgoing and
incoming trusts. This is only necessary if you have selected the trust creation
in both domains. Otherwise, the trust must be created first in the trusting
(target) domain. Skip the confirmation steps if the other side(s) of the trust has
not been created yet.
10. On the last wizard page — "Completing the New Trust Wizard", you will see
the report on operations performed. Close the wizard by clicking Finish.

That is all. A one-way transitive trust has been created. (The trusts with foreign
forests or domains will not be transitive!) You can check it by using the NLtest
command. After the trust has been created, you should see:

C:\>nltest /sc_query:net2.dom
Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \\netdc4.net2.dom
 Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

This means that the displayed DC in the trusting domain will authenticate the
requests from DCs in the net2.dom domain.

You may also establish a two-way trust, in which both domains will trust each other.
To create the trust in the reverse direction, repeat the procedure described above,
but this time start from the other domain in the pair (in our example it would be the
subdom.net.dom domain). It does not matter from which domain — trusted or trusting
— one begins to create a trust. The main thing to remember is that every trust has to
be created on both sides of a domain pair, and you must use the same trust
password.

To delete a trust in a Windows .NET domain:

1. Select a trust on the Trusts tab and click Remove.

2. Select the necessary option in the pop-up window (Fig. 5.15) and click OK.

Fig. 5.15: You can delete a trust from either local domain only or from both
domains at the same time

3. Confirm the deletion.

If you have deleted the trust in the local domain only, do not forget to delete it from
the other domain, too.

Establishing Trusts with Windows NT 4.0-Based Domains

If the trusting domain in the example discussed in the previous section were a
Windows NT 4.0-based domain (named, let us say, NT4DOM), the necessary steps
would look like this:

1. Start the User Manager for Domains, and select the Policies | Trust
Relationships command.
2. Click Add (to the right of the Trusted domains panel).
3. Enter the NetBIOS (pre-Windows 2000) name of the trusted domain (NET2)
and the trust password entered in Step 5 (see above). Click OK.
 4. Normally, you will get the message: "Trusted Relationship with ('NET2' for our
example) successfully established".

Note You must establish two-way trusts between domains for migrating from a
Windows NT 4.0/2000/.NET domain to an Active Directory domain (which must
be in the native mode or higher) by using the Active Directory Migration Tool
(ADMT), ClonePrincipal, or similar (third-party) tools.

Creating Forest Trust

The forest trusts are always transitive and can have a one-way as well as two-way
direction. Remember that the forest functional levels of both forests must be raised to
Windows .NET (version 2002)! If this condition has not been met, you may create a
usual external trust only. Make sure that domain controllers of each forest can
resolve the DNS name of another forest.

To create a forest trust:

1. Open the Active Directory Domains and Trusts snap-in on any DC in the
forest root domain of either forest that participates in the forest trust. (The
forest root domain is preferred, because you should run this snap-in with the
administrative privileges in that domain.)
2. Open the Trusts tab in the Properties window of the forest root domain
(net.dom in our example) and click New Trust.
3. On the "Trust Name" wizard page, enter the DNS name of another forest's
root domain (dotnet.dom). (If you select any other domain names, the page
shown in Fig. 5.16, will never appear!)

Fig. 5.16: This page allows you to create a transitive forest trust

4. If you leave the default option on the "Trust Type" wizard page (Fig. 5.16), you
will be able to create a usual external trust only. Therefore, select the lower
option (Forest trust) and click Next.
5. On the next page (see an example in Fig. 5.13), select the direction of the trust
and click Next.
 6. Then, select the sides of the trust (see Fig. 5.14). Click Next. Enter credentials
of a user with appropriate privileges, if necessary.
7. A very important selection should be made on the next wizard page (Fig.
5.17). (The good news is that it is possible to change this selection at any
moment in the future.) By default, all users from the target forest will be able to
access those shared resources in the local forest that are available for the
Everyone group. Otherwise, you should grant the permissions manually.

Fig. 5.17: On this page, you will select the authentication scope for users from
the target forest

If the created trust is two-way, a similar page will appear for the target forest,
too. For an already created forest trust, you can open its Properties window
and manage the authentication scope on the Authentication tab.

8. On the consequent wizard pages, confirm the trust creation if necessary.

9. Then, you can confirm the name suffix routing parameters offered by the
system; in the future, you can change them (if necessary) on the Name Suffix
Routing tab in the trust's Properties window.
10. Close the wizard by clicking Finish.

Now, it is possible to grant permissions and privileges to any user within either forest.
For example, if you want to select an applicable user account and will open the
Locations window (Fig. 5.18), you will see any domains and forests that trust the
current domain. However, an external forest w2000.dom connected with non-
transitive trusts is shown as a usual domain, whereas the dotnet.dom forest is shown
as a domain tree, which means that it is possible to choose accounts from the entire
forest.
Fig. 5.18: This window displays all external forests
[1]
In Windows 2000, the corresponding buttons are named Edit (funny enough, you
cannot edit anything in the appropriate window) and Verify.

Chapter 6: Configuring and

Troubleshooting Active Directory
Domains
Certainly, the title of this chapter encompasses a broad topic that cannot be fully
covered even in a dozen books. We will discuss only certain issues here, ones that
you inevitably encounter in your practice, and that you should not forget about. See
also Chapter 9, "General Characteristics and Purpose of System Tools", that will help
you to select the necessary tools and utilities for your work, and simplify the
troubleshooting process. Do not neglect these very useful tools! (Though alas, in
practice, quite often many indeed do neglect them.)

In this chapter, all considerations of Active Directory domains cover both Windows
2000 and Windows .NET domains unless otherwise noted.

Placing Flexible Single-Master Operation (FSMO) Roles

Every Active Directory beginner first gets a piece of good news: all Active Directory
domain controllers (running either Windows 2000 or Windows .NET) are peers; write
operations are permitted on every domain controller (DC); and all changes are
replicated from the originating DC to others (so-called multi-master replication is
used). These features are quite advantageous when compared to the rules accepted
in Windows NT-based domains.

Some time later, the beginner gets some bad news: there are operations when some
DCs perform additional functions (i.e., in comparison with other DCs), and instead of
the one role available for a DC in Windows NT-based domains — either Primary
Domain Controller (PDC) or Backup Domain Controller (BDC)—an Active Directory
domain controller can simultaneously perform up to five different roles[1]. These roles
are known as Flexible Single-Master Operation (FSMO) roles. (You can easily find a
description of each role in the Help and Support Center. Open the Index tab and
enter FSMO as the keyword, or use the Search tab. See also the "Managing FSMO
Roles in the Forest" section in Chapter 8, "Common Administrative Tasks" and the
"How to Find an FSMO Master?" section in Chapter 17, "Scripting Administrative
Tasks.")

Fig. 6.1 illustrates the default placement of FSMO roles within a forest. As you can
notice, every first DC created in a domain holds three domain-wide roles; and in
addition, the first DC located in the forest root domain holds two forest-wide roles.

Fig. 6.1: Default placement of FSMO role owners in a forest

There are many guidelines for placing FSMO roles; we will consider only a few rules
that you should not violate:

ƒ Notwithstanding the fact that the Primary Domain Controller (PDC) Emulator in
Active Directory domains does not play as important a role as the PDC plays
in Windows NT domains, you must carefully assign this role. Even in the
native mode Windows 2000 domains or Windows .NET (version 2002) level
Windows .NET domains, the PDC Emulator is used as a primary authority for
updating user passwords and controlling failed authentication requests.

By default, the PDC Emulator is selected by the Group Policy Object Editor
snap-in, and you may have trouble editing group policies if the PDC Emulator
is inaccessible. Keep the PDC Emulator and Relative Identifier (RID) Master
role on the same DC. However, keep in mind that these two roles can produce
a considerable workload on that DC.

All DCs in a domain will synchronize the clock with the PDC Emulator. In a
multiple-domain forest, the PDC Emulator from each domain will synchronize
the clock with the PDC Emulator located in the forest root domain. The forest
root PDC Emulator should synchronize its clock with an external time source.

ƒ If a domain has two or more DCs, the Infrastructure Master and a Global
Catalog (GC) server must not be placed on the same DC; however, they need
to be connected by a high-speed link to reduce network traffic. (You can
ignore this requirement if there is only one DC in a domain, or if each DC in a
domain is the GC server.) It is advisable to deploy at least one GC per site.
(You may also consider universal group membership caching available in
Windows .NET domains.) However, it is not typically recommended that you
 designate all DCs in the domain as GC servers, since this produces additional
network traffic.
ƒ Place both per-forest roles — Schema Master and Domain Naming Master on
the same DC. In Windows 2000, assign this DC as a GC server; this is not
required, if Domain Naming Master runs on a Windows .NET-based DC. This
is mandatory to guarantee the uniqueness of names in the forest.
ƒ By default, the first DC installed into a domain owns all of the domain
operations master roles. If you remove Active Directory from this domain
controller, all roles are automatically transferred to another available DC. If the
demotion process fails, you must manually seize the operations master roles.
As a "best practices" rule, you might consider manual transferring of any roles
before demotion of a DC. (See the description of the NTDSutil tool in Chapter
10, "Diagnosing and Maintaining Domain Controllers.") If the demoting DC is a
GC server, you must first be sure that there are other GC servers in the forest,
and then designate a new GC server if necessary.
ƒ If you restore a DC that owns some FSMO roles, these roles will be also
restored. Therefore, you may need to review all current role owners after the
restore is completed.
[1]
In fact, this number may even increase if one takes into consideration the fact that
the Infrastructure Master role also exists for each created application directory
partition.

Replication Issues

The Active Directory service is a distributed network database, and synchronization

of its replicas stored on different domain controllers is vital in order for the whole
service to work. Replication issues are one of the main sources of trouble for an
administrator; that is why we will consider some replication-related topics in more
detail.

Intra- and Inter-Site Replication

The concept of the site that has appeared in Active Directory domains significantly
affects the methods of replicating directory partitions (within a site and between sites)
as well as the replication transports (protocols).

Replication Transports

The following table lists the rules applicable to the various transports used for
different types of replication:

Between sites
Directory partitions Within a site
The same domain Different domains
Domain Naming context RPC over IP "IP" (RPC over IP) –
Configuration "IP" (RPC over IP) "IP" (RPC over IP)
 Between sites
Directory partitions Within a site
The same domain Different domains
Schema or

Global Catalog SMTP over IP

Uncompressed Compressed (by default)

"RPC over IP" enables high-speed, synchronous replication.

"IP" (as accepted in the Active Directory Sites and Services snap-in) enables a
low-speed, point-to-point, synchronous replication for all directory partitions.

"SMTP over IP" provides low-speed, asynchronous replication between sites and
supports only Configuration, Schema, and Global Catalog replication; requires
installation of an enterprise Certification Authority (CA).

Important It is not possible to change the default replication transport for

connections generated automatically by the directory system. You may
either agree with the protocol used or mark the connection as manually
created (in the Active Directory Sites and Services snap-in, such
connections will have GUID names, whereas for the user created
connections you can specify any name).

Normal Replication Intervals

There are two default methods of replicating object changes in Active Directory
forests:

ƒ Change notification is usually used between DCs within a site. If a DC updates

an object attribute, it will send notification to its first replication partner within a
specified time interval (5 minutes by default). Then, the partner "pulls" the
changes from the originating DC. You can change the default interval (300
seconds) by modifying the Replicator notify pause after modify (secs) value under the
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters registry key. The
originating DC will notify the next replication partner within the time specified
by the Replicator notify pause between DSAs (secs) registry value (30 seconds by
default). On Windows .NET domain controllers, these values are not defined,
and the defaults are used. Therefore, you should first create the key values.
ƒ Changes are replicated between sites according to a schedule (configured for
site links and connections). You can configure change notifications between
sites too. (Microsoft, however, does not generally recommend such a
practice.) To do so, point to the Sites | Inter-Sites Transports | IP node in the
Active Directory Sites and Services snap-in, open the Properties window,
and check the Ignore schedules box on the General tab.

Tip Use ReplMon.exe for monitoring various replication parameters. Select a

monitored server and run the Generate Status Report command from the
context menu.
 If you experience unrecoverable problems after modification of the replication
structure, you can delete all disturbing connections in the Active Directory Sites
and Services snap-in and re-create them by starting the Knowledge Consistency
Checker (KCC) for each affected server. To do so, right click an NTDS Settings
object and select the All Tasks | Check Replication Topology command from
the context menu.

See also the "Replication Issues" section in Appendix B.

Urgent Replication

Certain events on DCs are replicated immediately rather than at predefined intervals.
This is known as urgent replication. The following events on any domain controller
trigger urgent replication between DCs in the same site:

ƒ Setting an account lockout after a certain number of failed user logon attempts
ƒ Changing a Local Security Authority (LSA) secret
ƒ Changing the RID Master FSMO role owner

(If a change notification is configured between sites, the urgent replication can be
propagated to other sites.)

Urgent replication in Active Directory domains is not initiated by the following events:

ƒ Changing the Account Lockout Policy

ƒ Changing the domain Password Policy
ƒ Changing the password on a machine account
ƒ Changing inter-domain trust passwords

If a user changes the password at a specific DC, that DC attempts to urgently

replicate the changes to the PDC Emulator. The updated password is then normally
replicated to other DCs located in the same site. If the user is repeatedly
authenticated by a DC that has not yet received the updated password, this DC
refers to the PDC Emulator to check the user credentials.

Replication of Group Policy Objects

A Group Policy Object (GPO) consists of two parts. One part is located in Active
Directory (the DS part), and the other part is stored on the hard disk in the SYSVOL
volume (the Sysvol part). Hence, GPOs are replicated in two ways: by normal Active
Directory replication and by File Replication Service (FRS). If one replication
completes successfully, this does not mean that there are no problems with the other
replication. That is why you should monitor the consistency of GPOs. For that
purpose, use such tools as Active Directory Replication Monitor (ReplMon.exe) (see
a server's Status Report) or GPOTool.exe that display the DS version and the Sysvol
version separately for each GPO. (See detailed description of GPOTool.exe in
Chapter 15, "Group Policy Tools.")
Monitoring Replication

You may wish to monitor replication events both in a test and a field environment.
(The only difference may be in the level of detail given for registering events.) To
fulfill this task, it is possible to use the event logs and performance counters.

Logging Replication Events

You can use the Directory Service event log for monitoring such events as the
moments of replication request completion, the number, total size, and names of
replicated attributes, and so on. The granularity level of logged events is set through
the system registry (see below).

Set the 5 Replication Events value at the

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics registry key equal to 3 or 4 (the
difference between the cases will be discussed later). This will help you to see all
replication requests, the sequence of replicated directory partitions, and the result of
the requests. (Two domain controllers from the same domain — NETDC3 and
NETDC4 — are used in the following examples.) The following two events are logged
after each directory partition has been successfully replicated (NETDC4 asks
NETDC3 for the changes):

Event Type: Information

Event Source: NTDS Replication
Event Category: Replication
Event ID: 1060
...
User: Everyone
Computer: NETDC4
Description:
Internal event: The directory replication agent (DRA) call completed
successfully.
-----
Event Type: Information
Event Source: NTDS Replication
Event Category: Replication
Event ID: 1488
...
User: NETDOM\administrator
Computer: NETDC4
Description:
Internal event: The Directory Service completed the sync request with
status code 0.

Any replicated information is logged as an event similar to the following (NETDC3

asks NETDC4 for the outbound changes):

Event Type: Information

Event Source: NTDS Replication
Event Category: Replication
Event ID: 1073
...
User: NETDOM\NETDC3$
Computer: NETDC4
Description:
 Internal event: The directory replication agent (DRA) got changes returning 2 objects, 2448 bytes
total and entries up to update sequence number (USN) 100225, with extended return 0.
-----
Event Type: Information
Event Source: NTDS Replication
Event Category: Replication
Event ID: 1490
...
User: NETDOM\NETDC3$
Computer: NETDC4
Description:
Internal event: The Directory Service finished gathering outbound
changes with the following results:

Object Update USN: 100225

Attribute Filter USN: 100225
Object Count: 2
Byte Count: 2448
Extended Operation Result: 0
Status: 0

To see replication events, set the registry value to at least level 3. Level 4 allows you
to track replication of each changed attribute. (Use this level for debugging only!

If many objects are replicated, the number of events in the Directory Service log may
be huge. This also significantly affects the performance of the DC.) You can easily
find all replicated data by the Event ID. A message (ID 1239) similar to the following
is written in the log for all unchanged attributes of the replicated objects:

Event Type: Information

Event Source: NTDS Replication
Event Category: Replication
Event ID: 1239
...
User: NETDOM\NETDC3$
Computer: NETDC4
Description:
Property 20002 (whenCreated) of object CN=John
Smith,OU=Staff,DC=net,DC=dom (GUID 3b2653cf-76e6-4d35-abf5-ec4c78fad8ee)
is not being sent to DSA a9d28d8e-e681-449f-blbe-38dadf6f4c06 because
its up-to-date vector implies the change is redundant.

If an attribute was changed, it is replicated to another DC, and a message with the ID
1240 will appear in the log:

Event Type: Information

Event Source: NTDS Replication
Event Category: Replication
Event ID: 1240
...
User: NETDOM\NETDC3$
Computer: NETDC4
Description:
Property d (description) of object CN=John Smith,OU=Staff,DC=net,DC=dom
(GUID 3b2653cf-76e6-4d35-abf5-ec4c78fad8ee) is being sent to DSA
a9d28d8e-e681-449f-blbe-38dadf6f4c06.
You can filter out events that do not have ID 1240, and quickly check all replicated
objects and changed attributes.

Using the Performance Counters

Performance counters are very useful to monitor replication events, especially the
replication traffic. To start monitoring, run the Performance snap-in (from the
Administrative Tools group). Select System Monitor and click the Add button on the
taskpad. Select NTDS in the Performance object list and add the counters shown in
Fig. 6.1.

(The Report View seems to be the most useful in this case.) All counters have zero
values immediately after startup of the DC. (The NTDS performance object has a
great number of counters, and I have selected only some of them that are related to
replication.)

Fig. 6.2: Some of the performance counters important for monitoring replication
Note As you can see in Fig. 6.1, compression of replication traffic (both inbound and
outbound) can reach a ratio 12 to 1 (ratios up to 20 to 1 are also possible). If
the replicated block of information is not large enough (less than 32 Kbytes),
compression of inter-site traffic is not carried out.

You can also create a custom MMC console that will contain a copy of the System
Monitor Control for each selected domain controller. (Start an MMC console, select
ActiveX Control in the Add Standalone Snap-in window, and find the System
Monitor Control in the Control type list. Repeat this procedure for each desired DC.
Then, select the performance counters from different DCs and add them to the
appropriate ActiveX controls.) See also the "Managing Replication" section in
Chapter 11, "Verifying Network and Distributed Services."

The DRA Sync Requests Successful value must normally be equal to the DRA Sync
Request Made value. However, these values usually differ on the DC(s) booted first,
when its replication partners may yet be non-operational. Remember the values
when all DCs in the network are online and replicated. From that moment on, the
difference between these values must not increase.

The DRA Pending Synchronizations counter displays the number of replication

requests that have not been completed yet (any result — a success or a failure — is
possible).
The DRA Inbound/Outbound Bytes Not Compressed (Within Site) Since Boot
counters register both intra- and inter-domain replication traffic, provided this traffic
has not been compressed (i.e., replication block size does not exceed 32 KB).

Some General Troubleshooting Tips

It is not possible to answer each question related to troubleshooting Active Directory.

(It is Microsoft Knowledge Base that tries to solve these problems, and usually, it
does so with success!) I'd rather like to consider a few relatively simple tips here,
which, nevertheless, could be very useful in various real-life situations. (Do not let the
brevity of the tips fool you; this information is quite profound. Try it for yourself.)

Logging Diagnostic Events

On Active Directory domain controllers, the

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics registry key contains diagnostic
entries (total 19 on Windows 2000, and 24 on Windows .NET) that represent the
events that Active Directory can register in the Directory Service log. Each entry has
a REG_DWORD value ranging from 0 to 5, which corresponds to the level of
granularity of logged events.

When the default level 0 is set, only critical events are logged. This is the normal
value for most entries. "Super-verbose" level 5 should be used with care, since it
causes all events to be logged and is only used for debugging specific problems. If
you have encountered an Active Directory-related problem, try to slightly increase the
value of the appropriate registry value and to reproduce the problem. Do not forget to
restore the default value after the problem has been solved.

There are no strict rules for selecting an entry value. You can do this in an
experimental way. Use of the Replication Events entry has been discussed above. If,
for example, the value of the Garbage Collection entry is set to 3, you can see when
the garbage collection starts and completes, as well as the volume of free space in
the directory database file. When the value is set to 5, each object deletion will also
be logged.

Internal Errors During Replication

There is a kind of replication error that happens when a specific object "prevents" a
replication request from being completed. (Remember that you cannot simply delete
this object, since deleted objects are also replicated.) The Q265090 article from the
Microsoft Knowledge Base describes troubleshooting similar errors that may appear
during the replication phase of the server promotion process. A similar approach can
also be used for other cases of internal errors related to replication. (You can also
consider this article as an example of troubleshooting replication issues.) To solve
the problem, you should delete the interfering object, decrease the tombstone lifetime
to the lowest value possible (2 days), and wait until the garbage collection entirely
deletes the object. In Windows 2000, this trick has saved my network a few times,
when all other means did not help at all. Windows .NET systems seem to be more
proof against similar problems.
Verifying an Active Directory Server Status

As you know, a server running Windows 2000 or Windows .NET systems can
advertise itself as a domain controller (if it has been promoted to perform such a
role), and an Active Directory domain controller can also advertise itself as a Global
Catalog (GC) server. There are quite a few cases when you may wish to be sure that
this process has been successfully completed.

For example, if the File Replication Service (FRS) encounters some trouble, it does
not initialize the system volume, and the Netlogon service thus cannot share the
SYSVOL volume. (The NETLOGON volume also cannot be shared in that case.) This
results in problems with applying group policies, as well as many other replication
and authentication problems.

Here is another situation. The promotion of a DC to a GC server is normally delayed

for 5 minutes. However, due to replication problems this process can last longer.

In both cases, before you begin to locate connectivity, authentication, or other

potential problems, you need to be sure that your server really acts as a domain
controller or a GC server.

Advertising a Server as a Domain Controller

Here are the methods that will allow you to identify whether a Windows 2000- or
Windows .NET-based server is a domain controller after its promotion or normal
reboot:

ƒ The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services registry key must

contain the NTDS subkey.
ƒ Enter net accounts at the command prompt. The "Computer role" of a domain
controller is "PRIMARY", while standalone servers identify themselves as
"SERVERS".
ƒ Enter net start at the command prompt. The list of running services must
contain the Kerberos Key Distribution Center (KDC) service.
ƒ Enter nbtstat −n at the command prompt. The domain name with the <1C> type
must be registered.
ƒ Enter net share at the command prompt. The SYSVOL
(%SystemRoot%\SYSVOL\sysvol) and NETLOGON
(%SystemRoot%\SYSVOL\sysvol\<DomainDNSName>\scripts) shares must
exist.
ƒ Use Ldp.exe to view the isSynchronized attribute of the RootDSE object. (For
additional information, see Chapter 1, "LDAP Basics" and Chapter 12,
"Manipulating Active Directory Objects".) After a server promotion, the system
must perform a full synchronization of all directory partitions. When this
process is completed, the isSynchronized attribute is set to TRUE.
ƒ Use NLtest.exe. (More details are in Chapter 11, "Verifying Network and
Distributed Services".)
ƒ Use NTDSutil.exe to connect to the domain controller and verify its responding
to LDAP queries. (For more information, see Chapter 10, "Diagnosing and
 Maintaining Domain Controllers".) You can also use this tool to verify whether
the DC knows about the FSMO roles in its domain.

Advertising a Domain Controller as a Global Catalog Server

Assigning a domain controller as a Global Catalog server (for example, in the Active
Directory Sites and Services snap-in) and advertising this DC as a GC server are
not the same things. A domain controller can advertise itself as a Global Catalog
server only after it has replicated in all domain partitions existing in the forest at the
moment.

You can use the following methods to verify advertising of a DC in the role of Global
Catalog server:

ƒ After a DC has been promoted to a GC server, the event with ID 1110 (Event
Source: NTDS General; Event Category: Replication) appears in the Directory
Service log. The advertising process completes with the ID 1119 event: "This
domain controller is now a global catalog."
ƒ The Global Catalog Promotion Complete registry value under the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters key
must be equal to 1.
ƒ Use Ldp.exe to view the isGlobalCatalogReady attribute of the RootDSE
object. (For more information, see Chapter 1 and Chapter 12.)
ƒ Use NLtest.exe. (More details are in Chapter 11.)

Part III: Administering Active Directory

Chapter 7: Domain Manipulation Tools
Chapter 8: Common Administrative Tasks

Chapter 7: Domain Manipulation Tools

This chapter has perhaps more illustrations than any other in the whole book. No
wonder! A picture is worth a thousand words! This is not a formal reference to all
administrative snap-ins' screens, menus, commands, features, or to the operations
that they implement. Neither are all snap-ins discussed. I wound like to make the
reader focus his or her attention on certain details and options that are unapparent or
which might not be noticed upon first acquaintance with snap-ins intended to manage
Active Directory. Using this "know-how" will allow you to organize your workplace
more efficiently. The differences between the Windows 2000 and Windows .NET
versions of the snap-ins are also considered.

This chapter unveils certain aspects involved in using the features of the
administrative tools for managing Active Directory. Other typical administrative tasks
carried out by these and other tools will be discussed in Chapter 8, "Common
Administrative Tasks," and in other chapters, where specific tasks are described in
detail.
Basic Active Directory Administrative Snap-ins

Both Windows 2000 and Windows .NET systems use the same set of snap-ins for
administering Active Directory. For the most part, these tools have not changed in the
new version; they perform the same fnctions (although in Windows .NET, all of them
have some additional features). Therefore, an administrator acquainted with
Windows 2000-based domains can easily master commonly used operations in the
Windows .NET environment.

After a Windows .NET Server has been promoted to a domain controller, new tools
(listed in Table 7.1) will appear in the Administrative Tools group on the Start
menu.

Table 7.1: Standard Tools for Administering Active Directory

Icon Tool name Main operations performed by the tool

Active Directory Selecting a domain for management in large forests.

Domains and Managing domain functional levels. Creating, verifying, and
Trusts deleting trusts between domains
Active Directory Creating and manipulating sites, transports, and subnets.
Sites and Managing replication schedules and links. Triggering
Services replication between domain controllers. Setting permissions on
objects. Linking GPOs to sites. Enabling DCs to act as global
catalog servers
Active Directory Creating and manipulating AD objects (users, groups, OUs,
Users and etc.). Setting permissions for objects. Linking GPOs to
Computers domains and OUs. Managing domain functional levels.
Transferring FSMO roles
Domain In Windows 2000-based domains:
Controller
Security Policy • Editing the Security Settings node of the GPO linked
to the Domain Controllers OU.

In Windows .NET-based domains:

• Editing any settings in the GPO linked to the Domain

Controllers OU.

Domain Security In Windows 2000-based domains:

Policy
• Editing the Security Settings node of the GPO linked
to a domain container.

In Windows .NET-based domains:

• Editing any settings in the GPO linked to a domain

 Table 7.1: Standard Tools for Administering Active Directory
Icon Tool name Main operations performed by the tool

container.

Group Policy Editing GPOs linked to an Active Directory container (site,

Object Editor[1] domain, OU) or stored on a local computer. This snap-in is not
shown on the Start menu, but is accessible from other
administrative snap-ins or can be added to a custom MMC
console.
[1]
In Windows 2000, this snap-in is called Group Policy.

These tools can be installed as a part of the Administration Tools Pack (see "Remote
Administration" in Chapter 8, "Common Administrative Tasks") onto any client
computer with Windows XP Professional or a member server with Windows .NET.
The Security Policy snap-ins will not appear on the Start menu in that case.

Note The Active Directory Schema Manager snap-in included in the Administration
Tools Pack is also installed on domain client computers and appears on the
Start menu.
Important It is not possible to install Windows .NET administrative snap-ins onto
Windows 2000-based computers.

Some other important tools (Table 7.2) for administering Active Directory are included
in the Support Tools pack. These tools might be regarded as mandatory for an
administrator, and are discussed later in this book.

Table 7.2: Some Additional Tools for Maintaining Active Directory (from Support
Tools)
Icon Tool name Main operations performed by the tool

ADSI Edit "Low-level" editing of the Active Directory objects that

(adsiedit.msc) belong to any directory partition (application, domain,
configuration, and schema). (The RootDSE object is also
accessible.) Setting permissions on objects.
Active Directory Searching Active Directory and modifying directory
Administration Tool objects using LDAP queries.
(Ldp.exe)
Active Directory Monitoring replication status and topology. Triggering
Replication Monitor replication. Monitoring FSMO roles and flags of domain
(replmon.exe) controllers.
Common Topics

Since most Active Directory administrative tools have been realized as MMC snap-
ins, all of them have similar interfaces and basic features. Knowing these features
allows you to use all of these tools in the most effective way possible, and to optimize
them to fit your specific tasks. Sometimes, a snap-in's design and features may even
affect some aspects of deploying Active Directory in an enterprise (see a bit later in
this chapter "Choosing Columns for Displaying"). Let us start by discussing
administrative snap-ins, taking into consideration some common features of snap-ins.

Making a Custom MMC Console

Most standard administrative tools can be started from the Start | Administrative
Tools menu, or can be added to a custom MMC console. Such tools as the Active
Directory Schema Manager snap-in or the Group Policy Object Editor snap-in
should always be initially added to an MMC document:

1. Enter mmc in the Start | Run window.

2. Press <Ctrl>+<M>, or select the Console | Add/Remove Snap-in command.
Click Add in the window that is open.
3. Select the desired snap-in in the Add Standalone Snap-in window, and click
Add. You can repeat this step for all the snap-ins you need. Then in turn click
Close and OK.
4. Save the resulting console with any name.

Making your own administrative console may have some valuable advantages:

ƒ You will have on hand all the instruments you want, which will be configured to
your discretion. For example, you may have snap-ins connected to different
domains, or Group Policy Object Editor snap-ins linked to various GPOs.
ƒ There will be more options for configuring and customizing snap-ins (see in
this chapter "Customizing Snap-ins").
ƒ The computer's memory is used more efficiently. A number of tools started
separately allocate considerably more memory than the same tools added to a
single MMC console.

Note On Windows .NET-based domain controllers (unlike those in Windows 2000),

all administrative snap-ins can be opened in the "Author" mode (right click on a
snap-in's name and select Author in the context menu), which allows you to
reconfigure these tools (add new snap-ins in the same MMC document, etc.).

Browsing the Tree Pane in a Snap-in's Window

While working in a snap-in window, don't forget about such simple but timesaving
web-style features on the Standard toolbar as the Forward and Back buttons,
the Up one level button, and the Refresh button. When pointing to an object,
you can view its properties either by selecting the Properties command in the
context menu, or — to do it faster — by clicking the Properties button.
Choosing Columns for Displaying

When working with different Active Directory objects, it is possible (and may be very
helpful) to display more fields than just the three default ones, or to delete
unnecessary ones. Select the Add/Remove Columns (in Windows 2000 — Choose
Columns) command in the View menu, and add or delete the necessary columns in
the Add/Remove Columns window (Fig. 7.1). Each object will have its own set of
fields.

Fig. 7.1: Choosing necessary object attributes to be displayed

In Fig. 7.1, note that in MMC v.2.0 you can move any item to the beginning of the
Displayed columns list. In Windows 2000, the Name item is always at the top.

Note When the Active Directory Users and Computers snap-in is used for creating
new users, the Full Name field is generated as a concatenation of the First
name and Last Name fields. The Full name field, in turn, determines the value
of the cn attribute. (You can, however, change this order, if you like — see
articles Q250455 and Q277717 in the Microsoft Knowledge Base.) You may
want, for some reason, to use proprietary naming conventions in your
organization. (This can be easily organized by using scripts or batch tools, such
as LDIFDE or CSVDE. Manual manipulations are also possible.) For instance,
you may wish for the cn attribute (i.e., the Full name field) to have the same
value as the sAMAccountName attribute (the Pre-Windows 2000 Logon Name
field) or as a proprietary ID code.
Note Sometimes, the Windows 2000 version of the Active Directory Users and
Computers snap-in does not sort a container contents on some columns. (In
Windows .NET, this is not an issue.) You can use the Find Users, Contacts,
and Groups window rather than the main snap-in's window. This window
allows you to sort rows according to the contents of any column. "Hide" the
Name column from view and rearrange the columns in the order most useful for
you. (It is not possible to remove this column in the main window. Moreover, in
Windows 2000, this column must always be first.) Click Browse to view the
forest tree and go to any location (then click Find Now). You can select the
most appropriate of the two windows depending on your requirements.
Exporting the List of Objects

To document the objects stored in Active Directory, you can export any currently
displayed list into a file for processing or printing from the Word or Excel applications.
Point to a container or an object and click the Export List button, or select the
Export List command in the context or Action menu. You can choose between tab-
separated (.txt) and comma-separated (.csv) formats. CSV files are easily imported
into Microsoft Excel documents.

Customizing Snap-ins

Standard configured administrative snap-ins lack certain useful features that are
realized in Microsoft Management Console (MMC) technology. These features are
common for all MMC consoles, and there are many reasons why using them in the
administrative tools allows an administrator to save a lot of time and effort.

Favorites

In Windows .NET, this feature is implemented in a slightly different way than it is in

Windows 2000. (Keep in mind that the Windows 2000 systems use the MMC version
1.2, whereas the Windows XP/.NET systems use the MMC version 2.0.)

In a custom MMC v.1.2 console, the Favorites tab will appear near the usual Tree
tab. A MMC v.2.0 console has the Favorites command on the main console menu.
You can browse Active Directory in a web-like style, and save the pages you'd like to
access later. Point to any container in the Tree pane, and select Add to Favorites in
the Favorites menu. This feature can be very helpful in large domains that contain
many OUs and other objects.

Notice also that any container in Active Directory that can be viewed in different
snap-ins can be designated as a favorite; it will be placed in the same list of favorites.
You can, for instance, simultaneously have main OUs from different domains,
authoritative DNS zones, DHCP scopes, site connections, etc., all on the Favorites
tab (or on the Favorite menu—in MMC v.2.0). Do not forget about traditional
browsing features, such as the Back, Forward, Up one level, and Refresh buttons.

Creating Custom Taskpads

An administrator may create specialized taskpads for him—or herself (for some
routine tasks) as well as for users that need to carry out certain (limited) tasks, or for
subordinate administrators to whom control of some OUs or objects is delegated.

Let us discuss an example of how to create a taskpad for administering

organizational units. This taskpad will allow us to view all accounts in an OU and
perform three predefined operations: create a computer, user, and group.

Select an OU in the Active Directory Users and Computers snap-in, and click New
Taskpad View from the Action menu. The New Taskpad View Wizard will be
started, which will guide you through all necessary steps. At any step of wizard
working, you can go back and change the selected options or entered information.

Leave the default options in the Taskpad Display and Taskpad Target steps
unchanged. This means that the tab of the created taskpad will appear for each OU
in the domain (but not for other domain containers!). Enter the necessary information
at the Name and Description step. When the wizard has finished (i.e., the view
without task buttons has been generated), check the Start New Task wizard box in
the last window and click Finish. The New Task Wizard will start.

The default Command Type is Menu command. In the Shortcut Menu Command
step, select Tree item task in the Command source list (Fig. 7.2). In this case, we
will be able to choose the commands for the entire OU. First, select New-
>Computer.

Fig. 7.2: Selecting the source of the commands for the new taskpad

At the next step, enter a relevant task name, and a description for this task. Then you
can choose a graphical representation (icon) for the task. A new task has now been
created. To add the other two commands, check the Run this wizard again box in
the last window of the wizard, and click Finish. The wizard will start again. Repeat
the necessary steps, the first time selecting New->User, and the second time—New-
>Group. Fig. 7.3 shows an example of a taskpad created according to the described
procedure.
Fig. 7.3: An example of a taskpad

You may add/delete tasks, and/or change the properties (options) of a taskpad by
selecting the appropriate tab and clicking Edit Taskpad View in the Action menu.

It is possible to define commands (tasks) for an entire container as well as for an

individual (selected) object in a container. While browsing the object tree, only those
commands that are acceptable for the selected object will be enabled in a taskpad.

Active Directory Users and Computers Snap-in

The Active Directory Users and Computers snap-in is perhaps one of the tools
that an administrator will use most often. That is why it is advisable to learn all of the
features that this snap-in provides for an administrator. This is especially true if a
domain contains thousands of objects, which complicates viewing and manipulating
them.

New Features

The Windows .NET version of the Active Directory Users and Computers snap-in
offers some new features:

ƒ Multiple selection of directory objects

ƒ Drag-and-prop option for move operations of various type and adding
member(s) to a group
ƒ Saved Queries

Connecting to Domain or Domain Controller

The Active Directory Users and Computers snap-in operates with only one DC —
and, therefore, one domain — at a time. By default, this is your current logon domain
and DC (unless you have changed the domain or DC and checked the Save this
domain setting for the current console box, Fig. 7.4).
Fig. 7.4: You may choose any domain in the forest to administer

You can choose a domain that you wish to investigate by pointing to the root of the
snap-in (or by selecting the domain object from the tree pane) and then selecting the
Connect to Domain command in the Action menu. In the Connect to Domain
window enter the domain name in the Domain field, or click the Browse button and
select the domain from the expanding domain tree. Notice the Save this domain
setting for the current console box, which allows you to have a few saved snap-ins
configured for different domains.

Similarly, you can select any domain controller in the current domain with the
Connect to Domain Controller command in the Action menu. It makes sense to do
this when, for some reason (e.g., regarding a replication issue), you need to
administer a Global Catalog server, or a DC performing a specific FSMO role, such
as PDC Emulator. In the Connect to Domain Controller window (Fig. 7.5) you can
see your current DC's name and the list of available controllers.

Fig. 7.5: Selecting a controller within a domain

Contents Displaying Options

The Active Directory Users and Computers snap-in has a few specific features,
which don't change the administrative options of the snap-in essentially, but
significantly affect the scope of objects available for manipulating. These features are
discussed below.

Saved Queries

This is a new feature available in Windows .NET only.

An administrator can create one or more queries using the LDAP filters and save
them in the snap-in for subsequent use. These queries will allow him or her to quickly
select the necessary objects only, which simplifies work with large number of
directory objects of a specific type (user, group, computer, etc.). All queries are
stored in the Saved Queries folder in the snap-in's tree pane and can be organized
in a folder structure (see an example in Fig. 7.6).

Fig. 7.6: A sample structure of saved queries

You can either immediately create a new query on a computer or import query
definition of an already existing query.

To create a query:

1. Select the Saved Queries folder and right click it.

2. Select New | Query in the context menu.
3. In the New Query window (Fig. 7.7), fill in the Name and Description
(optional) fields.
 Fig. 7.7: An example of a new saved query

4. Click Browse and select the query root — a container in the domain structure
(by default, the entire domain container will be looked through). Make sure that
the Include subdirectories box is properly set.
5. Click Define Query and compose a necessary query string. For detailed
information on that operation, see the "Filter Options" section.
6. Click OK. The query is ready.

The saved queries are not sorted and are placed in the query structure in the order
that they are created.

Saved queries are stored on the computer where they have been created. (These
queries are included in the roaming user profile if the user has such a profile.) To
distribute saved queries, the Help and Support Center proposes to copy the dsa.msc
file to other domain controllers (located in the same domain). However, this
statement most likely needs clarification.

In Windows .NET, some administrative snap-ins save the user settings in XML files
located in the “Documents and Settings\<UserName>\Application
Data\Microsoft\MMC folder. The name of such a file correlates with the snap-in's file
name (see details in the next chapter, section "File Names of Administrative Snap-
ins"). I have found in my own experience that you can safely copy the dsa file from
that folder to another computer (to a similar folder in the user profile). Remember,
however, that all snap-in's settings (including all saved queries) are copied with this
operation.

There is a legitimate and proven way to distribute saved queries. You can simply
export a query definition (in XML format) and import it to every computer where it is
necessary. Right click a query name and select Export Query Definition. Save the
definition to a file, copy the file to another computer, start the Active Directory Users
and Computers snap-in, right click the Saved Queries folder, and select Import
Query Definition.
Advanced Features Mode

By default, the Active Directory Users and Computers snap-in only displays five
nodes in basic mode. For some administrative tasks this is not enough, and you need
to switch to the Advanced Features mode that displays some important "invisible"
containers and has additional options. This can be done using the Advanced
Features command in the View menu.

Perhaps one of the most valuable nodes shown in advanced mode is the System
container (Fig. 7.8), which provides access to a number of system objects, for
instance, to the MicrosoftDNS container that stores DNS zone information if a zone
(zones) is (are) Active Directory-integrated and is replicated on all DCs in the current
domain. (This is the only option in Windows 2000-based domains and one of four
possible options in Windows .NET-based domains.)

Fig. 7.8: The advanced view of a domain objects tree

Even more important is that only in the Advanced Features mode will you have the
Object and Security tabs in the Properties window of any Active Directory object.
All changes related to delegation of control over some object are displayed in the
Security tab. For example, if you want to revoke an administrative right from a user
or a group, you need to open this tab for the object and delete the appropriate
permissions.

There is also one remarkable possibility related to this mode. You might notice that
five "default" nodes (plus the possible subdomains) are visible while browsing the
Directory node in the My Network Places folder from Windows 2000-based domain
clients (see Fig. 7.9 where a root and a child domains are shown). Sometimes this
information will annoy end users, while at other times you may not want end users to
be able to access these nodes.
Fig. 7.9: Browsing the entire domain tree may be tiresome or undesirable

You can control the "visibility" of any Active Directory container or object by using an
optional Boolean attribute showInAdvancedViewOnly (it can be set to FALSE or
TRUE, the case of the letters doesn't matter). The majority of Active Directory objects
have this attribute, and you can change its value as needed with the ADSI Edit tool
(see the "ADSI Edit Snap-in" section in this chapter). If an object (container) has this
attribute set to TRUE, the object will not be displayed during domain browsing or in
the base mode in the Active Directory Users and Computers snap-in. This has no
affect on the general behavior of the domain.

Fig. 7.10 shows the same domain structure that is represented in Fig. 7.9, but the
ShowInAdvancedViewOnly attribute has been set to TRUE for some domain objects,
so none of the users in the forest will be able to see the contents of these domains.
(In an actual situation, this might be too strict a limit, but do not forget that this is only
an example!)
Fig. 7.10: You can restrict browsing of both parent and child domains for clients and
"hide" unnecessary objects from viewing
Important Windows 2000-based client computers can browse any Active Directory
domains (Windows 2000- and Windows .NET-based). This feature has
not been included in Windows XP/.NET, and the Directory node is not
present in the My Network Places folder.
Note It is also possible to control the "visibility" of Active Directory objects using
access permissions. Both methods have their own pros and cons; therefore,
select the most convenient method, depending on your requirements. For
example, permissions allow for more comprehensive control, but if you use
them, rather than have the ability to make selected object invisible (or visible),
you will have to accept that all objects will become invisible (or visible) with your
selection.

Users, Groups, and Computers as Containers Mode

Some Active Directory objects act as containers for other objects. By default, this fact
has no visible representation in the Active Directory Users and Computers snap-
in. Nevertheless, there are situations when you may wish to see all object relations.
For example, compare the two screenshots shown in Fig. 7.11 and Fig. 7.12. The
first one is a default view of the Domain Controllers OU and the NETDC1 domain
controller; the second one shows the same controller as a container.
Fig. 7.11: The default view of a domain controller

Fig. 7.12: Using the Users, Groups, and Computers as containers mode for locating a
published printer connected to the selected domain controller

As you can see in Fig. 7.12, the domain controller has child objects; in particular, a
published printer. You might want to move the printer object to any other OU. This
will not affect the printer's behavior.

Note All printers are initially published in Active Directory as child objects of relative
computers. You may want to gather them in a single OU for users' or
administrators' convenience, although the Search option is a more convenient
way to work with printers.

Filter Options

As the number of objects in Active Directory considerably increases, the length of

time it takes to find specific objects may become unbearable. However, you can set a
filter and look up only the desired objects. Select the Filter Options command in the

View menu or click the Set Filtering Options button on the Standard toolbar.
You can set the types of objects to be displayed from a predefined list, or create your
own custom filter. The process of creating a filter is intuitively simple. Fig. 7.13 shows
how to create a filter for selecting user accounts with names starting with the letter
"a". To activate the filter, you must click the Add button and place the criteria onto the
list.

Fig. 7.13: An example of a custom filter

Caution Using a filter may present a potential danger when working with containers
(OUs). Suppose you have set a filter that displays only computer accounts.
You may decide that an OU is empty or holds only unnecessary computer
accounts (since it seems it does not contain any computers). You might just
forget that this OU can contain other objects and inadvertently delete the
entire OU rather than only the necessary accounts … Therefore, do not
forget to turn off any filters when doing such operations as deleting or
moving container objects!
Note Many Active Directory objects have the Name attribute. Regretfully, the object
name isn't displayed in the Fine Custom Search window in any form.
Therefore, you must remember all parameters of any added criteria.
Note Since two or more added criteria are AND-combined, an object is displayed in
the snap-in window only if all specified conditions are true. OR-combined
criteria are not available. Use the LDAP query if you need a complicated filter
condition.
Caution Filters, especially complex ones, may considerably slow down object display
in the snap-in window.

In addition, you can use LDAP queries. Click the Advanced tab in the Find Custom
Search window and enter a query (LDAP filter string) in text format. For example, the
following query fetches only non-default user accounts:

(& (objectCategory=Person) (objectClass=user) (displayName=*))

Caution All defined custom search filters along with the LDAP query are connected
by a logical AND. This means that you may, for instance, define the first filter
condition as "Name + Starts with + a", and view all user accounts whose
names start with "a". If you add the second filter condition defined as "Name
+ Starts with + d" (or add an LDAP query such as (cn=d*), you won't see user
accounts beginning with "a" or "d". (You must instead specify an OR-
condition in a single filter!) You'll see no accounts at all, because there are
no accounts whose names start with "a" and "d". Therefore, the combination
of filter conditions and LDAP queries has to be regarded as a chain of sub-
queries within other queries, i.e., as an intersection of sets.
Finding Active Directory Objects

Another option that helps to process large numbers of Active Directory objects is the
Find feature. In a sense, it works as a filter, but has a wider scope: you can find
objects in the entire directory (forest), in any domain, or in a selected container. To
find an object, you can use the Find command in each container's context menu or

select a container and click the Find objects in Active Directory button on the
toolbar.

Search (and advanced search) fields can vary, depending on the type of directory
objects (users, computers, printers, etc.). Search criteria for advanced operations are
composed in the same way as filters and have the same constraints. The Custom
Search option is the most flexible; it allows you to specify practically any attribute of
any directory object. The Windows .NET version of the Active Directory Users and
Computers snap-in provides also the Common Queries option that finds the user,
computer, and group objects only. For example, using this option, you can find
disabled user and computer accounts, or user accounts that have not been used
during a specified number of days.

Note When you find users in the Find Users, Contacts, and Groups window, the
string entered in the Name field is verified for matches with all user-naming
attributes — cn, First name, Last name, and Display name.
Note The In list comprises the names of containers (OUs) you've already visited.

In the window of the objects found, you can select all context menu commands that
are available for these objects in the usual snap-in window.

An example of the Find window and a sample result is shown in Fig. 7.14. This
search query finds all groups in the entire directory with names starting with the letter
"s". The example shown might not be particularly useful, but note that you can search
the whole domain forest (two domains in this case) as well as a selected domain or
container. In addition, it demonstrates that such a group as Server Operators is
present in either domain, but only one (root) domain has the Schema Admins group.

Fig. 7.14: Finding objects in Active Directory

Fine Tuning the Find Window

The display mode shown in Fig. 7.14 is not the default. To see the distinguished
names (i.e., all RDNs of the parent objects) of found objects, click Choose Columns
in the View menu, select the X500 Distinguished Name item and add it to Columns
shown.

To further filter the result of a find operation, click Filter in the View menu. The filter
bar will appear at the top of the result pane in the Find window. How to filter out
some groups and users among a number of similar objects is shown in Fig. 7.15.

Fig. 7.15: Filtering the search results: among all administrators, we have selected
those that belong to the ADMINs OU
Note In the Find window, it is possible to turn on the filter option for clients (by
default, the filter is set to off) by using the Enable filter in Find dialog box policy
in the user's administrative templates (sub-node Desktop | Active Directory).

It so happens that it is not possible to see some directory objects' (computers,

printers, etc.) distinguished names. In that case, you can add the Published At
column to the default view of the Find window. The canonical names of the objects
will be displayed in that column. For example, for the XP-PRO3 computer that
belongs to the net.dom domain and is placed in the COMPs organizational unit, the
displayed string will be ntds://net.dom/COMPs/XP-PRO3.

Multiple Selection of Directory Objects

One of the most troublesome disadvantages of the Active Directory Users and
Computers snap-in in Windows 2000 is its inability to manipulate a number of
directory objects, primarily, and user objects. Windows .NET offers a pleasant
improvement in that area.

For the most of directory objects (e.g., computers, groups, OUs, and etc.), you can
change the description only. However, in user objects, over 30 attributes can be
changed simultaneously. You select the objects as usual — using the <Shift> and
<Ctrl> keys. Then, you select the Properties command on the context or Action
menu. The set of allowed commands will be determined by the type of the objects
selected. When two or more objects are selected, the modified Properties window
opens. An example of that window for user objects is shown in Fig. 7.16.
Fig. 7.16: Appointing a profile and logon script to a number of users

On the Profile tab, it is possible to set all the same properties that are available in the
usual user's properties window. If you set a box, you define the value entered in the
appropriate field. If the field is empty, the existing attribute value will be cleared. If a
box is not checked (the appropriate field is grey), the existing value will be retained
without changes.

Active Directory Sites and Services Snap-in

The Active Directory Sites and Services snap-in is the main GUI tool that allows an
administrator to configure Active Directory as a distributed network service. (Other
administrative tools consider Active Directory as a whole, at a logical level.) You
might almost forget about this snap-in in a small, single-site network with just a few
domain controllers. However, in large networks with many sites, this snap-in
becomes one of the essential administrative tools.

The Active Directory Sites and Services snap-in allows you to perform the
following operations:

ƒ Designate domain controllers as Global Catalog servers.

ƒ Modify forest replication topology (create/delete sites, subnets, links, link
bridges, and connections); view replication contexts.
ƒ Enable caching of universal group membership.
ƒ Design a location scheme used by the printer, computer, site, and subnet
objects (for detailed information, search in the Help and Support Center for
"Enabling printer location tracking").
ƒ Trigger intra-site and inter-site replication events.
 ƒ Trigger the Knowledge Consistency Checker (KCC) to re-generate replication
topology.
ƒ Change schedules and intervals for intra-site and inter-site replications.
ƒ Assign costs to links.
ƒ Designate domain controllers as bridgehead servers.
ƒ Delegate control over sites, subnets, servers, and other containers to users or
groups.
ƒ Define security and auditing settings for various replication topology objects.
ƒ Select Group Policy Objects (GPO), link GPOs to sites, and start the Group
Policy Object Editor snap-in for editing GPO.
ƒ Select LDAP query policies.

In Fig. 7.17, you can see the main window of the Active Directory Sites and
Services snap-in, which displays practically all major elements of network
configuration: sites, subnets, inter-site links, connections, and servers (domain
controllers). Use and configuration of these elements is discussed in other chapters
of the book, since it is more advantageous to describe these questions in the context
of specific administrative tasks rather than in isolation.

Fig. 7.17: An example of a simple network with two sites

Caching Universal Group Membership

Domain controllers running Windows .NET can store universal group membership
information locally, and refresh it periodically (by default, every 8 hours). This
diminishes the necessity to have a Global Catalog server in branch office locations;
as well, it reduces network traffic that occurs when users are authenticated in a
forest.

To enable that option:

1. In the tree pane, select a site where GC server is not designated.

2. Right click the corresponding NTDS Site Settings object (of the
nTDSSiteSettings type) and select the Properties command on the context
menu.
 3. On the Site Settings tab of the Properties window, check the Enable
Universal Group Membership Caching box and select a site from the
Refresh cache from list (Fig. 7.18).

Fig. 7.18: Enabling universal group caching

4. Click Apply and OK.

Active Directory Domains and Trusts Snap-in

The Active Directory Domains and Trusts snap-in is an enterprise administrator's

tool that allows you to look up the forest easily and select a domain for administering.
Other purposes of the Active Directory Domains and Trusts snap-in are discussed
below in detail.

An example of a forest (which contains two non-adjacent trees — net.dom and

dotnet.dom) represented in the snap-in's main window is shown in Fig. 7.19. If you
point to a domain in the tree and select the Manage command on the context or
Action menus, the Active Directory Users and Computer snap-in will be started for
this domain.
Fig. 7.19: Selecting a domain for management in the enterprise (domain forest)

Raising Functional Level

Using the Active Directory Domains and Trusts snap-in, you can raise the domain
as well as the forest functional level. In Windows 2000, a similar operation is called
changing mode (mixed mode or native mode). Right click a domain in the domain
tree and select the Raise Domain Functional Level command on the context menu
(see Fig. 7.19). You will see a window (Fig. 7.20) that informs you about the current
domain level and possible levels (if available).

Fig. 7.20: Selecting functional level of a domain

If the domain consists of Windows .NET-based domain controllers only, you can raise
the domain level to Windows .NET (version 2002) right away. Select a level and click
Raise. If there are domain controllers on other platforms (Windows NT 4.0 or
Windows 2000), then the operation will fail. The system will report the controllers that
prevent raising the functional level. Such a report will contain lines similar to the
following:

The following domains include domain controllers that are running earlier
versions of windows:

Domain NameDomain Controller Version of Windows

subdom.net.dom w2kdc3.subdom.net.dom Windows 2000 Server 5.0 (2195)

Otherwise, the operation will be replicated over other controllers in the same domain.
Wait until replication has been completed. Then, you can verify functional levels by
querying the RootDSE object on domain controllers (see Chapter 1, "LDAP Basics").

To raise the forest level, point to the root in the tree pane (Fig. 7.21) and select the
Raise Forest Functional Level command on the context menu. Again, all errors that
have occurred will be reported.

Fig. 7.21: Raising forest functional level

If two domain forests have the Windows .NET (version 2002) functional level, then
the Active Directory Domains and Trusts snap-in will allow you to establish forest
trusts between root domains of those forests.

Using User Principal Names (UPN)

The concept of user principal names can considerably simplify the logon process in
large domain trees. While logging on, the domain users can use one of two methods
for specifying their names. They can:

ƒ Enter a UPN name, such as user@DNSdomainName (in this case, the domain list
becomes unavailable).
ƒ Enter a pre-Windows 2000 (SAM account) user name (without the "@"
symbol) and then select a domain from the list.

Each method has certain advantages. It may be inconvenient to enter long domain
names, such as dom1.comp1.ent1.com. The first method is, in fact, just a particular
instance of a general format: userName@UPNSuffix. The default UPN suffix is the
DNS name of that domain where a user account is located. It is possible to add
alternative suffixes that can be used by all users of a domain forest.

To add a UPN suffix, open the Active Directory Domain and Trusts snap-in, point
to the root in the tree pane, and select Properties from the context menu. Enter a
suffix in the Alternative UPN suffixes field and click Add and Apply. The entered
suffix (net in Fig. 7.22) will appear in the dialog box during new user creation.
Fig. 7.22: Adding an alternative UPN suffix

Now you can choose any UPN suffix for a new user (the current domain, parent
domain and alternative UPN suffixes) or change the UPN name for an existing user.
Let us create, for example, a user with the logon parameters shown in Fig. 7.23.
Initially, the logon name and the pre-Windows 2000 name are the same, but you can
specify any name you like.

Fig. 7.23: Choosing UPN suffixes during new user creation

The created user will be able to log onto the domain tree with the following names
(the password will be the same for both logon names):
 ƒ EntAdmin@net — UPN name
ƒ EAdmin (and a domain name selected from the list) — SAM account name

You can also check these names using the ADSI Edit snap-in (sAMAccountName is
a mandatory attribute, and userPrincipalName is an optional attribute).

Note Notice that, by default, the "built-in" Administrator and Guest accounts do not
have UPN names.
Attention UPN names are not supported by Windows 9x/ME clients.

Understandably, all account names must be unique. SAM account (pre-Windows

2000) names in the same domain cannot be repeated. A full name must not be used
more than once in an OU. However, the same full name can be used for accounts in
different OUs (because the canonical names of objects will differ, e.g.,
domain.com/OU1/John Smith and domain.com/OU2/John Smith), provided that the UPN and
SAM account names are different (e.g., jsmith@domain.com and johnSmith@domain.com;
JSMITH and JOHNS).

Verifying Trusts

A domain administrator can use the Active Directory Domains and Trusts snap-in
for verifying trusts between domains and for creating new trusts. This process
primarily concerns trusts with Windows NT 4.0 domains. Such trusts must be
manually created (see Chapter 5, "Installing Active Directory").

However, you may also want to create explicit, unidirectional trusts between AD-
based domains that belong to different domain trees (or forests — if the forest trusts
are established) or even to the same tree. This, for instance, may be required in
order to reduce logon time into a "remote" domain. Here, "remote" is related to the
"distance" between domains in a tree structure. (All considerations stated are even
applicable to transitive Kerberos trusts.)

For example, the dom1.comp1.ent1.com and dom2.comp2.ent2.com domains (Fig.

7.24) can be regarded as "remote", because trusts between trees in a forest are
established through the root domains.

Fig. 7.24: A shortcut trust between two "remote" domains

To check a trust between domains:

 1. Open the Properties window for a domain.
2. Select a trust on the Trusts tab and click Properties (in Windows 2000 —
Edit).
3. In the next window, click Validate (in Windows 2000—Verify). If the trust is
operational, you should see the message: "The trust has been verified. It is in
place and active." If the system reports an error and proposes that you reset
the trust, confirm the operation. Usually, the trusts will be reset successfully. In
Windows .NET, you can simultaneously verify both sides of two-way trusts if
you know a domain administrator's credentials in the second domain.

You can also use the NetDom tool for verifying and resetting trusts.

ADSI Edit Snap-in

The ADSI Edit snap-in, which is included in the Support Tools pack, is a tool that
provides "low-level" access to Active Directory. It allows you to perform the following
operations:

ƒ Connect to any directory partitions (including application partitions).

ƒ Connect directly to any Active Directory object using its distinguished name.
ƒ View, move, rename, and modify any attribute of any object.
ƒ Tune security settings down to a single attribute.
ƒ Perform a query through a whole domain tree and save it.
ƒ Create and delete objects of any type.
ƒ Connect to Global Catalog servers.

Connecting to Namespaces

The newly installed ADSI Edit snap-in is configured for work with three Active
Directory namespaces (contexts, or partitions):

ƒ Domain (DC=domainName, DC=com)

ƒ Configuration (CN=Configuration, DC=domainName, DC=com)
ƒ Schema (CN=Schema, CN=Configuration, DC=domainName, DC=com)

The first namespace is replicated among all DCs that belong to the same domain.
The other two are replicated over every DC in the domain tree.

The ADSI Edit snap-in allows you to connect to any application directory partitions.
There are two default (built-in) application partitions that can be created on a DC and
used by the DNS server installed on the same DC (see Chapter 3, "Domain Name
System (DNS) as Main Naming Service"):

ƒ ForestDnsZones (DN=ForestDnsZones, DC=domainName, DC=com)

ƒ DomainDnsZones (DN=Schema, CN=Configuration, DC=domainName,
C=com)

There is one more object, which the ADSI Edit snap-in can be connected to:

RootDSE
Note Note that the Windows 2000 version of ADSI Edit only shows the informational
(LDAP) attributes of the RootDSE object. Operational (system specific)
attributes, such as isSynchronized or isGlobalCatalogReady are not accessible.
The Windows .NET version of the tools displays all RootDSE's attributes.

You can also add the standalone ADSI Edit snap-in to any MMC console opened in
the author mode. In this case, it is added without any connection. If you create your
own MMC console, you have a feature such as the Favorites tab, which can be very
helpful for working with multilevel tree structures and various Active Directory objects
(which all have very long LDAP names).

To make a new connection, point the root node in the tree pane and select the
Connect to command from the context menu. Enter any string you want in the Name
field and specify the distinguished name of an object, or select a predefined name-
space from the Naming Context list (Fig. 7.25). You may also enter a domain or
server name different from the default one.

Fig. 7.25: Connecting to a namespace

You can also create a connection to any object while browsing through the object
tree. Point to an object and select New Connection from here in the context menu.
All new connections are saved upon exit from the snap-in.

In the Advanced window (click Advanced in the Connection window) you can
specify alternative credentials, a port number, or choose the protocol: LDAP or
Global Catalog. To view or modify the current properties of a connection, select the
Settings command from the context menu for this connection. Any connection may
be deleted with the Remove command.
Editing Attributes of Active Directory Objects

Let us see how to work with the ADSI Edit snap-in in the two following examples that
contain some tips which may be useful for an administrator.

Example 1. Hiding Directory Objects from Browsing

Using the example of the showInAdvancedViewOnly attribute (see the "Advanced

Features Mode" section), let us discuss how to locate attributes of an Active Directory
object and modify their values.

Suppose we would like to hide the Builtin container from browsing. Point to it in the
tree pane of the ADSI Edit snap-in and click Properties on the toolbar. In the
opened window, the Attributes pane (in Windows 2000 — the Select a property to
view drop-down list) contains all attributes of the selected object. You can quickly
locate an attribute in the list by typing in the first few characters of the attribute's
name (Fig. 7.26).

Fig. 7.26: Finding and editing an attribute of an Active Directory object

When the attribute has been selected, select True in the Boolean Attribute Editor
window and click OK, then Apply. (In Windows 2000, enter the new value TRUE, or
true — it does not matter — into the Edit Attribute field and click Set, then Apply.)
To delete the value of an attribute, click either Clear or Non set. If the attribute is
multi-valued, select a value, and click Remove.

Example 2. Enabling Creation of Containers through User Interface

This example shows how to modify the schema by using ADSI Edit.

By default, you cannot create a new object of the Container type using the Active
Directory Users and Computers snap-in. Sometimes it may be useful to have such
an option for organizing directory objects. (You might also wish to enable the creation
of any other object types.) To create this option, it is necessary to modify the schema.

1. If you have not yet connected to the schema name context, do so now.
2. Open the schema folder and find the container class (CN=Container).
3. In the Properties window, select the optional defaultHidingValue attribute (the
default value is TRUE).
4. Set value to False, then click Apply and OK.
5. Point to the Schema node and select Update Schema Now from the context
menu.

If the schema cache has been updated successfully, open the Active Directory
Users and Computers snap-in (restart it, if it has been already opened) and check
that the container object has appeared in the Action | New menu.

Creating a Custom Query

A query in the ADSI Edit snap-in is a custom template for displaying only desired
objects in the tree pane. (This is an analog to saved queries in the Active Directory
Users and Computers snap-in.) This makes working with large numbers of objects
or objects related to different Active Directory containers simpler. The queries can be
created in any Active Directory namespace (partitions), but remember that since a
namespace belongs to a specific domain, the queries work within the borders of one
domain only.

Let us create a query for all published folders. Point to the node related to the domain
context and select the New | Query command in the context menu. Give the new
query any name you like (Fig. 7.27) and click Browse to define a container — the
root of the search. In our case, it will be the root domain (net.dom).
Fig. 7.27: This window contains the parameters necessary for creating a custom
query

The next step is to define the query itself. You can either directly enter a query in the
Query String field or click Edit Query and start the wizard that helps to create a
custom filter (see the "Filter Options" section, Fig. 7.13). The generated string is
displayed in the Query String field. (Remember the limitations of custom filters!)

To see all folders, you must specify the Is present option (the "*" character) for the
folder name. Select the appropriate query scope — Subtree Search or One Level
Search.

An example of the resulting display is shown in Fig. 7.28. Notice (in the
Distinguished Name column) that the selected folders are related to different OUs in
the same domain. This means that you have really searched the entire domain.

Fig. 7.28: The query that allows you to work with all published folders in the whole
domain forest

All queries are saved upon snap-in closing, and refreshed upon its loading. You can
refresh the contents of a query at any time. To edit a query, select Setting from the
query's context menu.
Creating Active Directory Objects

Using the ADSI Edit snap-in, you can create Active Directory objects of any type.
However, it can hardly be recommended that you do so, because of a high probability
of errors with object attributes: you must be familiar with the meaning of all
mandatory and optional attributes and their valid values. Using the "standard"
administrative snap-ins and tools is much more preferable.

If, nevertheless, you do decide to create an object manually, point to the desired
object in the tree pane and select the New | Object command. The wizard will start
and ask you for all required values. The list of possible new objects depends on the
type of object selected initially. (See also "Extending the Schema" in Chapter 16,
"Active Directory Service Interfaces (ADSI).")

Working with Global Catalog

Being able to work directly with a global catalog (GC) server may be helpful while
troubleshooting the problems related to GC replication. You can connect to different
GC servers and compare the values of stored attributes (see also the description of
DsaStat.exe in Chapter 11, "Verifying Network and Distributed Services"). You can
also verify the representation of attributes in a GC. (This process can be controlled
via the Active Directory Schema Manager snap-in, see the next section.)

Note Only some of Active Directory object's attributes are presented in Global
Catalog. When you have enabled/disabled replication of an attribute to Global
Catalog, you may wish to use the ADSI Edit snap-in to verify the presence of
this attribute on a GC server.

In general, the procedures for working with Global Catalog are the same as
described above. The only difference is that you must select the Global Catalog
protocol in the Advanced window when creating a connection to an Active Directory
naming context (partition). It must be clear that it is impossible to create new objects
in Global Catalog.

Active Directory Schema Manager Snap-in

The Active Directory Schema Manager snap-in is the preferred GUI tool (the other
one is the ADSI Edit snap-in; its usage requires that you have a more advanced
familiarity with Active Directory's interiors) that allows viewing and modifying of Active
Directory classes and the attributes the classes contain. (Two other ways to extend
the schema are scripting and using command-line tools, such as LDIFDE and
CSVDE.) This snap-in allows an administrator to view X.500 OIDs of classes and
attributes, a range of values for attributes, mandatory and optional attributes for
classes, and other meta-information on attributes and classes.

Installation

The Active Directory Schema Manager snap-in is installed by default on domain

controllers. This snap-in is also included in the Windows Administration Tools pack,
and can be installed onto any computer with Windows XP/.NET. (Windows 2000 has
its own version of that tool.) It appears neither on the Start menu nor in the Control
Panel, and should be manually added to an MMC console. (If the snap-in is installed
as a part of Windows Administration Tools, it does appear on the Start menu as well
as other administrative snap-ins.) You only need to first register the DLL by entering
the following command at the command prompt:

regsvr32 schmmgmt.dll

You should get the message shown in Fig. 7.29.

Fig. 7.29: This message will appear if the DLL-file is registered successfully

If you install Windows Administrative Tools on a computer (see Chapter 8, "Common

Administrative Tasks"), the appropriate DLL is registered automatically.

After schmmgmt.dll is registered on a computer, you can create an MMC document

(which is a console saved with any name you like) containing the Active Directory
Schema Manager snap-in, or add the snap-in to an existing custom console.

Modifying the Schema

All modifications of the schema are only permitted on the DC that possesses the
Schema Master FSMO role. It is highly recommended that you adhere to this
requirement.

Note To find the Schema Master in a forest, use the following command: dsquery
server — hasfsmo schema.

In Windows 2000, by default, the modification of the schema is disabled. Therefore,

to modify the schema, start the Active Directory Schema Manager snap-in (which
by default is targeted to the Schema Master) and set first the flag The Schema may
be modified on this Domain Controller in the Change Schema Master window.
After this, you can change the schema itself and schema access permissions. In
Windows .NET, this flag is absent.

Attention By default, only members of the Schema Admins group can modify the
schema. It is, however, also possible to grant this permission to other
people.

The schema's updates are dumped from cache to disk every 5 minutes.
You can manually reload the schema to force this process.
Modification and, in particular, extension of the schema, require a profound
understanding of Active Directory concepts and classes structure, and this could be
the theme of a separate book. (Some basic information on this question is given in
Chapter 16, "Active Directory Service Interfaces (ADSI).") However, in routine work
an administrator may want to perform the following operations (these are the names
of checkboxes at the General tab in the Properties window of an attribute or a class;
see Fig. 7.31):

Fig. 7.31: Properties of an attribute

ƒ Attribute (class) is active (in Windows 2000, a similar flag Deactivate this
attribute (class) has an opposite meaning). If a newly created (e.g., a test)
attribute or class is not yet used (i.e., there are no new objects of that class, or
that attribute has not been added to a class) in Active Directory, you may
"disable" it. (You cannot delete attributes and classes in Active Directory.)
Such an attribute or class is considered to be defunct. In Windows .NET, it is
possible to redefine and reactivate it.
ƒ Index this attribute in the Active Directory. Indexing of an attribute speeds
up the frequently used query operations that include the attribute.
ƒ Replicate this attribute to the Global Catalog. If an attribute is included in
Global Catalog, you can get the attribute's values when performing forest-wide
queries.
ƒ Show objects of this class while browsing. This flag controls the state of
the showInAdvancedViewOnly attribute (see above "Hiding Directory Objects
from Browsing"). If this flag is set, the attribute's value is FALSE. The flag
possibly affects the custom (newly created) classes only.
To carry out these operations, expand the Attributes or Classes node in the tree
pane and find the desired attribute or class. Open the Properties window and set the
appropriate flag on the General tab.

Caution After a new attribute has been added to the global catalog, a forest-wide
replication is triggered. (This is the case regarding all schema modification
operations.) This can result in significant network traffic. Therefore, this
operation should not be performed often and should be well planned.

Extending the Schema

Extension of the schema is not a particularly complicated operation, but nonetheless,

it is a very crucial one. You must always remember that all extensions of the schema
are not reversible (even if you restore Active Directory from a backup copy!) and may
result in significant forest-wide replication traffic.

Let us discuss how to create a new attribute and class on a few examples. (See also
about extending the schema in Chapter 16, "Active Directory Service Interfaces
(ADSI)" and Chapter 17, "Scripting Administrative Tasks.")

Creating an Attribute

Before creating an attribute, you must carry out the following operations:

ƒ Choose the attribute's common and LDAP display names according to

Microsoft recommendations.
ƒ Obtain the base X.500 OID (see Chapter 16) and add your specific attribute ID
to it.
ƒ Select the attribute's syntax.
ƒ Choose the minimum and maximum values for the attribute (optional).

Attention The base X.500 OIDs — one for classes and one for attributes — are
obtained only once for your organization. Then you can add your own
increasing IDs to the base OIDs.

When you have gathered all this information, point to the Attributes node in the tree
pane and click Create Attribute in the context menu. Click Continue in the warning
window. Fill in the fields in the Create New Attribute window. (All fields except
Minimum and Maximum are mandatory.) Click OK. Fig. 7.30 displays sample
information necessary for the creation of a string attribute.
Fig. 7.30: An example of creating a new string attribute
Attention In Windows 2000, if you receive the "Schema update failed in
recalculating validation cache" error, verify the selected OID. Windows
.NET provides more specific diagnostic messages.

Now you can find the new attribute on the list, view the attribute's
properties (Fig. 7.31), give a description to it, and set the necessary flags
(checkboxes). At this point, you can use the created attribute, i.e., add it
to an existing class(es) (see below and in Chapter 17, "Scripting
Administrative Tasks").

Creating a Class

To create a class, you must gather the following information:

ƒ The class's common and LDAP display names according to Microsoft

recommendations
ƒ The base X.500 OID (and add your specific class ID to it)
ƒ The type of class (commonly, structural) and the parent class (optional; top by
default)
ƒ The lists of mandatory and optional attributes of the class (if a structural or
auxiliary class inherits only the attributes from the parent and does not have its
own attributes, why create such a class?)
ƒ The possible superior(s) — the container(s), in which creation of the class's
objects is permitted

Point to the Classes node in the tree pane and click Create Class in the context
menu. Click Continue in the warning window. Fill in the fields in the Create New
Schema Class window. Fig. 7.32 illustrates this step. Click Next.
Fig. 7.32: The first step in creating a new object class

In the next window (Fig. 7.33), you can add mandatory and optional attributes to the
class. If you leave both lists empty, the new class will have only the attributes of the
parent class. You can add and remove attributes until you click Finish.

Fig. 7.33: In this window, you can add mandatory and optional attributes
Attention It is possible to add optional attributes to a class at any time, but the
mandatory attributes are added only at the class's creation.

To define a possible superior for the new class, select the class from the list, open
the Properties window, and click the Relationship tab (Fig. 7.34). Add the
necessary class, click Apply, and close the window. You have now created a new
class.
Fig. 7.34: This window allows you to add auxiliary classes to a class and to define
containers (possible superiors), in which objects of that class can be created

If the class created is of the auxiliary type, you may wish to add it to an existing class.
To do this, select a class, open the Properties window, click the Relationship tab,
and add the new class to the Auxiliary Classes list (Fig. 7.34).

Adding Attributes to Existing Classes

It is possible to add newly created or existing attributes to classes — new or standard

ones. Select the applicable class from the list and open the Properties window.

You can add necessary attributes to the Optional tab on the Attributes tab: click
Add and choose an attribute from the Select Schema Object list. Click Apply and
close the window. Reload the schema or wait until the schema's updates are written
to disk. Then the new attributes of the class will be "visible" in other administrative
tools.

Group Policy Object Editor Snap-in

The main purpose of the Group Policy Object Editor[1] snap-in is the editing of a
group policy object (GPO) stored locally on a computer or in Active Directory, and
linked (in the second case) to an Active Directory container: a site, a domain, or an
OU.

In Windows 2000, you should have a solid understanding of the difference between
the Group Policy Object Editor snap-in and the Security Policy — Local, Domain
Controller, or Domain — snap-ins. (These last three snap-ins are configured by
default on every DC; the Local Security Policy snap-in is also configured on every
client Windows 2000 system.)

The Group Policy Object Editor snap-in works with an entire GPO, and can be run
from certain administrative snap-ins or from a custom MMC console. It contains both
computer and user policies (the Computer Configuration and User Configuration
nodes of GPO).

The Security Policy snap-ins deal only with the Security Setting sub-node of the
corresponding GPO, and can be run from the Start menu (the Administrative Tools
submenu). These snap-ins allow you to configure computer policies only.

In Windows .NET, the Security Policy snap-ins are always configured to work with
entire GPOs.

Note Do not forget about two other important snap-ins — Security Configuration
and Analysis and Security Templates — that also help an administrator to
deploy Active Directory security in an enterprise. Due to space limitations and
other reasons, these snap-ins are not discussed in this book.
Note See Chapter 8, "Common Administrative Tasks," about refreshing your
computer (machine) and/or user policies after editing a GPO's parameters.

Linking to a Group Policy Object (GPO)

A running Group Policy Object Editor snap-in is always linked to a GPO. Therefore,
you need to learn two things: how to start the snap-in itself, and how to link it to a
GPO.

There are three ways to start the Group Policy Object Editor snap-in:

ƒ From the Active Directory Users and Computers snap-in — select the
domain or an OU, open the Properties window, and click the Group Policy
tab (Fig. 7.35).
 Fig. 7.35: A sample list of GPOs linked to a domain container

ƒ From the Active Directory Sites and Services snap-in — select a site, open
the Properties window, and click the Group Policy tab.
ƒ From Microsoft Management Console (MMC) — start MMC (enter mmc in the
Run window) or open a custom console, and add the Group Policy Object
Editor snap-in. The Select Group Policy Object window allows you to link to
the local GPO (default option) on the local computer (it is also possible to
select another computer). An alternative option is to open the Browse for a
Group Policy Object window (by clicking Browse) (see Fig. 7.36).

Fig. 7.36: In this window, you can see the entire structure of OUs in a domain
as well as the GPOs linked to them
In two first cases, you have three options:

ƒ Select an existing GPO (i.e., already linked) in the list and edit it by using the
Group Policy Object Editor snap-in
ƒ Create a new GPO that will be linked to the selected container
ƒ Add (link) an existing GPO to the container

From a MMC console, you can only select an existing GPO.

Let us discuss the last case (use of MMC). If you click Add on the Group Policy tab,
the Browse for a Group Policy Object window will open. An example of the default
view of such a window is shown in Fig. 7.36. (You may click the circled icon and
create a new GPO.)

As shown in Fig. 7.37, all GPOs that exist in a domain are listed in the All tab, so you
can quickly find the necessary GPO.

Fig. 7.37: Use this tab to quickly find a GPO that you want to link to the current
container
Important When the Group Policy Object Editor snap-in is opened or a custom
MMC console is created, it is not possible to re-link the snap-in to another
GPO.

You cannot change the DC with which the Group Policy Object Editor
snap-in works (therefore, the default Security Policy snap-ins, too) (see
later "Selecting a Domain Controller", and it is not possible to connect to a
local GPO stored on another computer.

You can check which containers the selected GPO is currently linked to. In the
Group Policy Object Editor snap-in's window, point to the root node in the tree
pane and open the Properties window for the GPO. Click Links tab (Fig. 7.38).
Select an applicable domain and click Find Now. If the GPO is linked to other
containers, you will see their names on the list in addition to the name of the current
container.
Fig. 7.38: You can quickly verify whether the selected GPO is linked to other
containers besides the current one
Attention Due to possible security and administrative conflicts, it is not advisable to
link GPOs stored in a domain to containers from another domain.

Creating and Deleting a GPO

To create a GPO, it is sufficient to click New on the Group Policy tab in a container's
Properties window (see Fig. 7.35), or to click the button in the Browse for a Group
Policy Object window (see Fig. 7.36). Name the new GPO, and you may then begin
editing it.

When you are going to delete a GPO, you have two options:

ƒ Remove the link from the list. When selecting this option, you break only the
link between the selected GPO and the current container. The GPO remains
intact, and you can use it later.
ƒ Remove the link and delete the Group Policy Object permanently. As the
message indicates, this is a more decisive option, since you not only break the
link, but entirely delete the GPO. (Remember that this GPO can be used by
other containers!)

WMI Filters

In Windows .NET-based domains, you are able to "link" a GPO to a specific property
of client computer. Let me explain this in the following example.

Suppose we want to assign some group policy setting (a GPO) to users (or
computers) that work on Windows 2000 Professional systems only, and that GPO will
in no way affect the other users (or computers). The following procedure will permit
us to carry out this task:

1. Create a new GPO. (You can select an existing GPO. However, it would be
better to use a new GPO and link it to a container only when all configuration
operations are completed.)
2. Configure al necessary policies.
3. Open the GPO's Properties window and click the WMI Filter tab (Fig. 7.39).

Fig. 7.39: This tab allows you to select a WMI filter and link it to the GPO
selected

4. Click This filter and Browse/Manage.

5. The Manage WMI Filters window will allow you to create, delete, and edit
WMI filters as well as to perform other operations. To create a filter, click
Advanced and New.
6. Fill in the Name and Description (optional) fields and enter a WMI query
string in the Queries pane (Fig. 7.40). (See information on WMI in Chapter 17,
"Scripting Administrative Tasks".) For our task, we shall use the following
string:
 Fig. 7.40: Managing WMI filters

SELECT * FROM Win32_OperationSystem WHERE

caption="Microsoft Windows 2000 Professional"

7. Click Save and OK.

8. In the Properties window, click Apply and OK.
9. Link the GPO to a necessary container (domain, OU).

From the Manage WMI Filters window you can manipulate (edit, export, etc.) all
WMI filters stored in the system. Many examples of WMI filters can be found in the
Help and Support Center.

Selecting a Domain Controller

A Group Policy Object Editor snap-in is always targeted to a specific — "preferred"

— domain controller. (Notice the This list obtained from … line in Fig. 7.35. By
default, all Group Policy Object Editor snap-ins started on computers that belong to
the sample domain net.dom will select the name DC.) There are some rules that
define this behavior of the snap-in. To verify or change the default settings of a
Group Policy Object Editor snap-in, point to the root node in the tree pane and click
View | DC Options in the context menu. You can select one of the options shown in
Fig. 7.41. (This selection may be overridden by a group policy; see later.)

Fig. 7.41: These options determine which DC the Group Policy Object Editor snap-
in selects at its startup
It is necessary to comment only the second option. You can start the Group Policy
Object Editor snap-in from either the Active Directory Users and Computers or
the Active Directory Sites and Services snap-in, which is targeted to a DC (any DC
in the forest) at that moment. If you select the second option, the Group Policy
Object Editor snap-in will obtain a group policy setting from a GPO stored on that
DC.

The selected option is saved and used when the snap-in runs the next time.

Note In Windows 2000, you cannot define the "preferred" DC for the Security Policy
snap-ins.
Attention If the selected DC is not accessible at the snap-in's startup, an error will
be reported. Verify the setting (and the policy if defined), and select
another option if necessary.

A window similar to shown in Fig. 7.41 will appear when you start the
Group Policy Object Editor snap-in from an administrative snap-in and
the PDC Emulator is not accessible at the moment. In that case, you can
select any option except the first one and obtain a GPO from another DC.

Because the DNS is used for locating GPOs, the errors at the Group
Policy Object Editor snap-in's startup are very often related to the
malfunctioning of DNS. Therefore, always verify the DNS configuration
when you encounter such errors. Remember that DNS is a dynamic
system, and the registered records periodically expire.

There is a group policy that allows an administrator to define the strategy of selecting
a "preferred" DC. Open the Default Domain Policy GPO (or other applicable GPO)
and select the User Configuration | Administrative Templates | System | Group
Policy node. Double click the Group Policy domain controller selection policy.
Click Enable and select one of the following options:

ƒ Use the Primary Domain Controller

ƒ Inherit from the Active Directory Snap-ins
ƒ Use any available domain controller

If this policy is disabled or not configured, the Group Policy Object Editor snap-in
will always select the PDC Operation Master (PDC Emulator) for the domain. When
defined, the policy overrides the option selected in the Group Policy Object Editor
snap-in.

Note How to run the Group Policy Object Editor snap-in from the command
prompt, see the "Running GPO Editor" section in the next chapter.

Configuring Group Policy Objects

In Windows .NET, the user interface of the Group Policy Object Editor snap-in has
been enhanced. As you can see in Fig. 7.42, all nodes (primarily, the Administrative
Templates) comprise two tabs, — Extended and Standard. If you select a policy on
the Extended tab, you can view the policy of description and OS requirements. This
information is a good substitute for many pages of documentation and makes
learning the policy purpose and selection of a proper policy considerably simpler. In
Windows 2000, the policy description is only available on the Explain tab in the
policy's Properties window.

Fig. 7.42: The main window of new version of the Group Policy Object Editor snap
in

There are some common recommendations and tips for using and configuring GPOs.
Let us discuss them.

ƒ Disable unused settings in a GPO. This improves performance when a

computer or user is logged onto the domain. Open the Properties window of
the GPO (see Fig. 7.38 where the Links tab of this window is shown) and click
the General tab. Check the appropriate box: Disable Computer
Configuration settings or Disable User Configuration settings. When both
boxes are disabled, it means that the GPO is linked to the container, but does
not affect it.
ƒ In Windows 2000, for the Administrative Templates nodes, you can set the
Show Configured Policies Only flag (point to a node and set the flag in the
View menu). This prevents you from viewing not-configured policies. This flag
is set for the Computer Configuration and User Configuration node
separately.
ƒ In Windows .NET, the policy filtration feature is much more powerful (see Fig.
7.43). To open this window, point to an Administrative Templates node and
select Filtering on the View menu.
 Fig. 7.43: Filtering group policies in Windows .NET (default settings)

ƒ If your system was upgraded from Windows NT 4.0 and/or you use the older
ADS-files, pay attention to the value of the Show Policies Only flag in the
View menu for the Administrative Templates nodes. When set, this flag
prevents Windows NT 4.0-style system policy settings from applying to
Windows 2000/XP/.NET systems.
[1]
In Windows 2000, this snap-in is called Group Policy.

Chapter 8: Common Administrative

Tasks
This chapter deals with some typical administrative tasks related to Active Directory
(some operations have already been considered in the previous chapter). These
tasks in no way cover all the objectives which an administrator accomplishes every
day.

The tasks discussed below are carried out using administrative snap-ins or different
utilities from the Windows .NET Support Tools or the Windows 2000 Resource Kit.

Using the RunAs Command

Due to security requirements, it is not recommended that you be permanently logged

on to the system (domain) with a user account that has full administrative privileges.
Windows 2000/XP/.NET offers a very helpful command — RunAs. This command
allows a system administrator to carry out common tasks using an account with
restricted (or "normal" user) rights, and to start a specific command on behalf of a
"power" user (this can be an administrator account or an account with some
additional rights). Thus, it is not necessary to repeatedly re-register into the system.

Let us consider how to use this command with the administrative snap-ins.

Note If the RunAs command fails, make sure that the Secondary Logon service
(seclogon; in Windows 2000, it is called RunAs Service) is running on the
computer (run the Services snap-in and check the status of the service).

Running Administrative Tools from the Context Menu

You can select an administrative tool in one of the following ways:

ƒ Select the tool in the Start | Programs | Administrative Tools menu (or Start
| All Programs | Administrative Tools).
ƒ Open the window that contains all the tools. Click Start | All Programs |
Administrative Tools, and select either Open or Open All Users in the
context menu. (The former command will open the window that only contains
the tools created by the user, while the latter opens the window that contains
all tools installed by default.) Select the tool in the open window.
ƒ Copy (drag and drop) icons of the necessary tools to the desktop. (You may
also create one or more folders on the desktop, and copy the icons to them.)

Then, for any administrative snap-in, you can open the context menu and select the
Run as command. (There are some limitations on computers running Windows
2000.) You will see a window similar to the one shown in Fig. 8.1.

Fig. 8.1: By entering proper credentials in this window, you can start a program on
behalf of another user

The upper (default) switch allows you to start the tool on behalf of your current
account (i.e., with your current privileges). The other option (shown) — The
following user — will allow you to enter an administrator's credentials, and start the
tool in the "privileged" mode. Both the domain and user names should be used in this
window (this covers Windows 2000 domains, too): you can specify either a full SAM
account (pre-Windows 2000) name (as shown on the screenshot) or, in Windows
.NET, a UPN name (e.g., JSmith@net).

Note The procedure described above can be used with any EXE- or MSC-file, and
not only with administrative tools. (See the next section.)

In addition, you can open any administrative tool's Properties window, click
Advanced on the Shortcut tab, and set the Run with different credentials flag. In
Windows 2000, you should check the Run as different user box on the Shortcut
tab. After this operation is performed, the system will always propose that you start
the tool as another user.

Note Notice also the Author command on the context menu of administrative tools.
This command allows you to start a snap-in in author mode and then to modify
it. By default, all tools are saved in User mode — full access, and the Do not
save changes in this console box is not checked. To prevent users from
changing the administrative snap-ins, you may use the user administrative
templates in the Group Policy Object Editor snap-in.

Starting a Tool from the Command Prompt

Using the RunAs command, it is possible to start any executable file — EXE, COM,
CMD, BAT, MSC; shortcuts to programs (LNK); and Control Panel items (CPL) — on
behalf of a different user. Let us discuss some examples. (You can get complete
information on RunAs in the Help and Support Center or by running runas /?)

Note RunAs cannot be used with some items, such as Windows Explorer, the
Printers folder, and desktop items.
Note Usually, it is much more convenient to start MMC tools with RunAs from the
command prompt rather than from the Run window, because in the first case,
you will be able to see possible errors. For frequently used commands, you
may want to create shortcuts on the desktop.

Example 1. Work in the Same Domain

Suppose you are currently logged on to the net.dom domain with a "normal" user
account, and want to configure the domain controller security settings, which requires
administrative privileges (see Table 8.1). In the Run window or at the command
prompt enter the command:

Table 8.1: Some Administrative Tools and the Privileges Necessary to Use Them
Tool name Snap-in's name Necessary privileges

Active Directory Domains and Trusts domain.msc User

Active Directory Schema userCreatedName.msc User
Active Directory Sites and Services dssite.msc User
Active Directory Users and Computers dsa.msc User
 Table 8.1: Some Administrative Tools and the Privileges Necessary to Use Them
Tool name Snap-in's name Necessary privileges

Computer Management compmgmt.msc User

Distributed File System dfsgui.msc User
DNS dnsmgmt.msc User
Domain Controller Security Settings dcpol.msc Administrator
Domain Security Settings dompol.msc Administrator
Group Policy (see below) gpedit.msc Administrator
Local Security Settings secpol.msc Administrator
Routing and Remote Access rrasmgmt.msc Administrator
Services services.msc User
Snap-ins that aren't displayed on the Administrative Tools menu
Device Manager devmgmt.msc User
Disk Management diskmgmt.msc User
Local Users and Groups lusrmgr.msc User
Shared Folders fsmgmt.msc Administrator

runas /user:administrator@net.dom "mmc dcpol.msc"

Administrator is the name of a user that is a member of the Domain Admins group.
Enter the administrator's password when prompted.

Example 2. Administering Another Domain

Now you want to create a user in the subdom.net.dom domain using the Active
Directory Users and Computers snap-in (i.e., you would like to work in a domain,
other then the domain where you are logged on). Enter the following string:

runas /netonly /user:SUBDOM\administrator "mmc dsa.msc"

Note As you can see, it is possible to use two formats for representing a user
account: a UPN format, and a standard SAM format — DOMAIN\USER. Both
formats are acceptable, but in the last case, you must use the SAM format, or
the snap-in will be running for the domain in which you are currently logged on.

Example 3. Verifying User Permissions

RunAs can be very helpful for setting up user permissions on a file or Active Directory
objects. To set the necessary permissions for a user, you may start a tool using
administrative privileges. At the same time, it is possible to open the command
prompt or start a program on behalf of this user and check the resulting permissions.
You need not either repeatedly log on to the system using different accounts or use
several computers.
File Names of Administrative Snap-ins

To use administrative tools with RunAs, you should know the names of the
corresponding snap-ins. Also, some tools can only be used with administrative
privileges. Table 8.1 contains information on some important tools.

Note All installed snap-ins can be found in the %SystemRoot%\system32 folder.

Running GPO Editor

By default (when started without any parameters), the Group Policy Object Editor
snap-in is focused on the local GPO stored on computer. Generally, you have two
options:

ƒ Run this snap-in with a preconfigured GPO. You can use either the standard
snap-ins (gpedit.msc, dompol.msc, and dcpol.msc) or custom MMC consoles
with the Group Policy Object Editor snap-in.
ƒ Specify a GPO when the snap-in runs.

In the first case, you can create a custom MMC console, add the Group Policy
Object Editor snap-in to it, link the snap-in to a necessary GPO (stored on a remote
computer or in Active Directory), and save the console with any name you like. Then
you can start the console by its name. This is the "static" approach.

By using the second method, you are exploiting the fact that the Group Policy
Object Editor snap-in (the gpedit.msc file) allows you to change its focus (the
"dynamic" approach). For example, the following command allows you to open a
GPO stored on a remote computer (even the local computer specified with the
/gpcomputer parameter is considered to be a "remote" one!):

C:\>gpedit.msc /gpcomputer:"netdcl.net.dom"
Attention You cannot view and manage the Security Settings extension (except
for the IP Security Policies) of a remote computer's GPO. The Software
Installation and Folder Redirection extensions are never displayed for
local GPOs.

You can also run gpedit.msc and specify the distinguished name of any GPO stored
in Active Directory. The following approach will help the user to do this most
effectively.

At the command prompt, carry out a search operation by using the Search.vbs script
(Ldp.exe and DsQuery.exe can also be used) with parameters similar to:

C:\>search "LDAP: //DC=net, DC=dom"

/C: (objectCategory=GroupPolicyContainer)
/S: subtree /P:AdsPath, displayName

On the screen, you will see the list of all GPOs stored in the domain, for instance:

<LDAP://DC=net, DC=dom>; ((objectCategory=GroupPolicyContainer));

AdsPath,displayName;subtree
 Finished the query.
Found 5 objects.
AdsPath 1 = LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},
CN=Policies,CN=System,DC=net,DC=dom
displayName 1 = Default Domain Policy
AdsPath 2 = LDAP://CN={6AC1786C-016F-11D2-945F-00C04fB984F9},
CN=Policies, CN=System, DC=net, DC=dom
displayName 2 = Default Domain Controllers Policy
...

The DsQuery command shown below will produce the same result:

C:\>dsquery * -filter (objectCategory=GroupPolicyContainer) -attr

distinguishedName displayName

You can easily select a necessary policy by its friendly name and use its DN as the
parameter. (Don't forget about the copy-and-paste feature of the command prompt
window.) For example, to open the Default Domain Policy shown above, use the
following command (the quotes are mandatory):

C:\>gpedit.msc /gpobject:"LDAP://
CN= {31B2F340-016D-11D2-945F-00C04FB984F9},
CN=Policies, CN=System, DC=net, DC=dom"
This command used with the RunAs will have the following syntax:
C:\>runas /user:net\administrator "mmc gpedit.msc
/gpobject:\"LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},
CN=Policies, CN=System, DC=net, DC=dom\""

Remote Administration

To administer Active Directory from a domain client computer, you have the following
standard options (the order is not important):

ƒ Terminal Services allow an administrator to work on a client computer in the

same way as he or she can at the domain controller's console. This is the only
standard option for down-level client computers (Windows NT, Windows 9x) to
run the administrative tools, and the only option for low-speed (dial-up)
connections. Although many administrative command-line tools can connect
directly to remote computers, you will need the Terminal Services to get the
full functionality of the command prompt on a DC.

On Windows .NET-based computers, the Terminal Services are installed by

default. These computers have a built-in feature, Remote Desktop, that is
enabled on the Remote tab in the System Properties window and provides
an administrator with single-user access to the desktop of the computer.

Note There is no Terminal Service Connection option configured on

computers running Windows .NET. You can enter mstsc /console at the
command prompt or use the Remote Desktops command on the Start |
Administrative Tools menu.

ƒ The Windows .NET Administration Tools Pack contains practically all

administrative snap-ins (see Table 8.2). This pack is installed from the
 %SystemRoot%\system32\adminpak.msi file available on every Windows
.NET-based domain controller. You can install the Administration Tools on any
computer with Windows XP/.NET, but to use them, you must be logged on as
a user with domain administrative rights.

Table 9.2: Snap-ins Included in the Windows .NET Administration Tools Pack
Active Directory Domains and Trusts Internet Information Services
Active Directory Schema Manager Network Load Balancing Manager
Active Directory Sites and Services Remote Desktops
Active Directory Users and Computers Remote Storage
Certification Authority Routing and Remote Access
Cluster Administrator Server Extensions Administrator
Connection Manger Administration Kit Telephony
DHCP Terminal Services Licensing
Distributed File System Terminal Services Manager
DNS WINS
Caution The Windows .NET Administration Tools Pack cannot be installed on
computers running Windows 2000! In general, Windows 2000
Administration Tools could be used for administering Windows .NET-
based domains; however, some limitations exist in that case. A better
choice would be to install the Windows .NET Administration Tools
Pack and use it for managing domain controllers running both
Windows 2000 and Windows .NET systems.

ƒ You can manually install the selected administrative snap-ins on a client

computer (see the next section).

Installing Administrative Snap-ins Selectively

For some reason, you might want to install only one or just a few separate
administrative tools on a client computer instead of the entire Administration Tools
pack. This can be done quite easily. (But don't forget about security requirements!)
You will have to carry out the following steps:

1. Copy the necessary snap-ins (files with MSC extension) from the
%SystemRoot%\system32 folder on a DC to any local folder you wish.
2. Copy the appropriate DLL(s) to the local %SystemRoot%\system32 folder or
to any local folder.
3. If the DLL has been copied to a folder other than %SystemRoot%\system32,
you must first change the folder as necessary. To register the DLL, enter the
following string at the command prompt:
4. regsvr32 <DLLname>
5. For example, to register the DLL for the Active Directory Users and
Computers snap-in, enter regsvr32 dsadmin.dll.

Now you may create shortcuts for new snap-ins, and then run them. Of course, you
have to be logged on to the domain with appropriate (administrative) privileges.
The following table contains DLL names for some administrative snap-ins.

Tool name Snap-in's name DLL's name

Active Directory domain.msc domadmin.dll

Domain and
Trusts
Active Directory dssite.msc dsadmin.dll
Sites and
Services
Active Directory userCreatedName.msc schmmgmt.dll
Schema
Active Directory dsa.msc dsadmin.dll
Users and
Computers
Note After schmmgmt.dll has been copied to a local computer, you will be
able to add the snap-in to any custom MMC console (since there is no
schema snap-in configured by default).

By default, the Group Policy Object Editor snap-in is present on any

computer running Windows 2000/XP/.NET. Therefore, to use this tool
and link it to any domain GPO, you need only to have administrator's
privileges in the domain.

Notice that both the Active Directory Users and Computers and Active Directory
Sites and Services snap-ins use the same dsadmin.dll file. Both snap-ins actually
provide similar operations (browsing and editing properties) with directory objects.
The former enables you to work with the entire domain naming partition of Active
Directory. The latter provides access to two containers in the Configuration partition,
namely, Sites and Services (you can also view them with the ADSI Edit snap-in).

Querying Active Directory

Querying is a commonly used operation in network directories, and Active Directory

is not an exception. Active Directory may contain a huge number of objects, whose
precise locations are frequently unknown. Querying the directory rather than
browsing the directory tree is preferable for both users and administrators. Users of
AD-based domains have the following instruments (some of them are available to all
clients, including down level systems, and others only work on Windows
2000/XP/.NET systems) which assist the user in finding one or more objects in Active
Directory:

ƒ Built-in search features (see the next section) — the most convenient way for
a user to find a shared folder or printer, user, group, or other common
directory object. All other tools are intended for administrators.
ƒ DsQuery.exe and Dsget.exe — the standard Windows .NET command-line
search utilities (see Chapter 12, "Manipulating Active Directory Objects").
 ƒ The ADSI Edit snap-in (from the Support Tools) — using this tool, an
administrator can create powerful queries and modify objects in all directory
partitions (see Chapter 7, "Domain Manipulation Tools").
ƒ The Search.vbs script (from the Support Tools) — the simplest query tool that
uses the LDAP protocol. Can be used on any Windows platforms (see Chapter
12).
ƒ Active Directory Administration Tool (Ldp.exe from the Support Tools) and
Active Directory Browser (AdsVw.exe from ADSI SDK) — complicated
administrative tools that also allow an administrator to browse through the
directory tree and modify objects. Ldp.exe uses the LDAP protocol and is the
only tool that can retrieve deleted objects. AdsVw.exe uses both LDAP and
WinNT protocols, and works with AD-based (Windows 2000 and Windows
.NET) and Window NT domains (see Chapter 12).
ƒ The Guid2obj.exe utility (from the Windows 2000 Resource Kit) — a
specialized tool that can determine the distinguished name of an object from
its GUID.

Most of the listed tools require a good understanding of LDAP filter syntax. Only then
will you be able to quickly and precisely find or choose the necessary objects.

Configuring Search Option on the Client Computers

By default, users — those who are aware of this option — can search Active
Directory for various objects by using the Find command from the context menu of a
domain displayed in the Directory folder (in My Network Places). This option is
available on computers running Windows 2000 and has been removed from
Windows XP/.NET. (One can also use the Active Directory Users and Computer
snap-in installed on a client computer.) There are two specialized commands called
from the Start | Search menu: For printers and For People.

It is possible to provide users with powerful search features and add a shortcut for
these operations to the desktop or any folder. You need to perform the following
steps:

1. Right click the desktop and select New | Shortcut from the context menu.
2. Enter the following string (case sensitive!) in the Type the location of the
item field, and click Next:
3. rundll32.exe dsquery,OpenQueryWindow
4. In the next window, enter a name for the shortcut and click Finish.
5. You might also wish to move the created shortcut to some folder or menu.

After clicking the shortcut, the user will see the search window similar to the one
shown in Fig. 7.14. From that window, it is possible to find users, contacts, groups,
printers, OUs, etc.

Note This feature works fine on all Windows systems (from Windows 95 to Windows
NT 4.0) provided that the Active Directory Client Extension (DSClient.exe from
the Windows 2000 Server CD; see also links in Appendix A). (Windows
2000/XP/.NET systems have that client as a built-in feature.) Just keep in mind
that you must not enter a space between the dsquery and OpenQueryWindow
 parameters.

Modifying Directory Objects. Export and Import

There are, in fact, quite a number of tools that allow an administrator to create,
delete, and modify one or more Active Directory objects. You should be familiar with
all (or at least most) of them to be able to choose the most effective tool for a specific
task. Let us list all of the main facilities provided on Windows 2000 and Windows
.NET platforms:

ƒ Standard snap-ins installed by default (see Chapter 7, "Domain Manipulation

Tools") — universal GUI tools that work with one object only, and in Windows
2000, have modest support for group operations.
ƒ The Active Directory Users and Computers snap-in creates users,
contacts, groups, computers, printers, shared folders, and OUs.
ƒ The Active Directory Sites and Services snap-in creates sites,
subnets, links, and connections.
ƒ The Active Directory Domains and Trusts snap-in creates inter-
domain trusts.
ƒ Standard Windows .NET command-line utilities that perform specialized
operations and can be used for managing Active Directory objects from the
command prompt.
ƒ DsAdd.exe (see below) creates specific types of objects.
ƒ DsMod.exe (see Chapter 12, "Manipulating Active Directory Objects")
modifies properties of specific object types.
ƒ DsRm.exe removes any objects.
ƒ DsMove.exe moves any objects to another container as well as
renames them.

Note Pay attention to the fact that the DsMod.exe utility can pipe in results
from DsQuery.exe, which significantly enhances the utility's flexibility and
effectiveness.

ƒ Specialized administrative GUI tools (see Chapter 7 and Chapter 12) used for
specific operations and for fine-tuning and troubleshooting Active Directory.
ƒ The Active Directory Schema snap-in creates attributes and classes.
ƒ The ADSI Edit snap-in, Ldp.exe and AdsVw.exe create objects of any
type (including objects which cannot be created by any other tools), but
are primarily useful for editing attributes.
ƒ Tools for import/export (see Chapter 12) — command-line utilities that could
(and should) serve as powerful tools for administering large-scale Active
Directory installation. LDIFDE can also be used for changing the attributes of a
number of similar objects. On computers running Windows .NET, utilities from
the Ds*.exe "family" might be a better choice in many cases.
ƒ LDIFDE
ƒ CSVDE
ƒ Utilities intended for specific tasks (see later in this chapter and the Remote
Administration Scripts in the Windows 2000 Server Resource Kit).
ƒ AddUsers.exe, CreateUsers.vbs, and others (e.g., NetDom.exe can be
used for creating machine accounts in domains)
 ƒ ADSI scripts (see Chapter 16, "Active Directory Service Interfaces (ADSI)" and
Chapter 17, "Scripting Administrative Tasks") — the most flexible of the
options and, in fact, a quite simple way to manipulate Active Directory objects
(especially for periodic routine tasks and when a large number of objects are
to be processed).

Using the Active Directory Users and Computers Snap-in

The Active Directory Users and Computers snap-in is, maybe, the main tool that
an administrator will use daily to manage various domain resources. The procedure
of creating and deleting Active Directory objects is basically the same for all types of
objects. There are buttons on the Standard toolbar for some of the most used
objects:

ƒ Create a new user in the current container

ƒ Create a new group in the current container

ƒ Create a new organizational unit in the current container

You can select one, several, or all created objects and move them into any container
or OU in the current domain. As usual in Windows, use the <Shift> or <Ctrl> keys for
selecting multiple objects.

The Windows .NET version of the Active Directory Users and Computers snap-in
offers some improvements in the user interface: you can use drag-and-drop
operations, and modify properties of several objects selected (for more details, see
Chapter 7, "Domain Manipulation Tools").

It is possible to choose a user account as a template, and create users with the same
properties (group memberships, profile settings, etc.) To start this process, select a
"template" user and click Copy on its context menu.

Note Organizational units can only be created in the OU or domain containers.

Note If you want to move objects between different domains in the same tree or non-
adjacent trees, you need to use the MoveTree utility from the Support Tools
(see Chapter 13, "Migration Tools").
Caution Built-in domain local groups cannot be deleted or moved from the Builtin
container.

Adding Users and Groups to Domain

There are a few utilities (besides the batch import tools LDIFDE and CSVDE and
custom scripts) that simplify the creation of a number of user accounts in a field or
test environments.
Windows .NET Utility — DsAdd

A brand-new Windows .NET utility, DsAdd.exe, can create single computer, contact,
group, OU, and user objects in AD-based domains. It uses the LDAP protocol only.

With DsAdd, you can create a local, global, or universal (if it is allowed) group and
add specified members to it at the same time (not later!). For example:

C:\>dsadd group CN=Admins, OU=Staff, DC=net, DC=dom -members

"CN=John, OU=Staff, DC=net, DC=dom" "CN=Tim, OU=Personnel, DC=net, DC=dom"

Here is an example of how to use DsAdd to create a user and add it to the specified
groups:

C:\>dsadd user CN=Alice, OU=Staff, DC=net, DC=dom -memberof

xg312
"CN=Admins, OU=Staff, DC=net, DC=dom"
"CN=Account Operators, CN=Builtin, DC=net, DC=dom"

CreateUsers.vbs Script (RK)

This script can only create users. It operates with both the WinNT and LDAP
providers. The created accounts will be enabled. The following attributes are required
(the minimal set of attributes):

ƒ WinNT — name and password

ƒ LDAP — cn, samAccountName, and password

Note You can specify many other attributes, too; however, not any attribute available
for an user object is permitted. Carefully test your command (and the input file,
if present). Be sure that all specified attributes are consistent; otherwise, you
could easily get an error message similar to:

Error 0X80072035 occurred in settings properties for user cn=...

This error (8245) means that "The server is unwilling to process the request".
One of the possible sources of this error is the incorrect "naming" attributes: cn,
name, sn, distinguishedName, etc. Do not forget to enclose any attributes'
values containing spaces in double quotes.

Here is the simplest example of how to create a user with CreateUsers.vbs:

C:\>createusers WinNT://NET name:user01 password:psw1

The script must output the following:

Working ...
Getting domain WinNT://NET ...
Creating user user01
Succeeded in creating user user01 in NET.

To disable output of informative messages, use the /q parameter.

New users will always be created in the Users container. You could move them to
other containers (most probably, organizational units), but a better way would be to
use the "LDAP-version" of the CreateUsers.vbs, which "understands" the Active
Directory structure:

C:\>createusers LDAP: //OU=Staff, DC=net, DC=dom cn: "User User01"

samAccountName: user-ldap01 password:psw1

Maybe the most intriguing issue is how to create a number of users at once. It is
actually very easy. Create a file with the desired user properties and use the
appropriate provider (WinNT or LDAP). For example, the following command will
create users specified in a file in the Staff OU:

createusers LDAP://OU=Staff, DC=net, DC=dom /i:newUsers.txt

The file of descriptions may be similar to the following:

cn: "User01" samAccountName:user01 password:psw1

cn: "User02" samAccountName:user02 password:psw2
...

AddUsers.exe (RK)

In comparison to CreateUsers.vbs, AddUsers.exe has a few additional features.

Besides adding users and groups to a domain, it allows you to:

ƒ Dump account information (users and groups) to a file.

ƒ Specify the control account-creation options. By default, a new user must
change his or her password at logon.
ƒ Delete users or groups. Account names can only be specified in the input file.
ƒ Create an input file in a spreadsheet program, such as Microsoft Excel, and
save it in comma-delimited format, which the tool can use. A separator
character other than a comma can be specified.

One negative aspect of AddUsers.exe is that the tool doesn't "see" the Active
Directory structure.

Note Using AddUsers.exe, you can successfully add users to existing groups,
despite the "Group already exists" error message. The groups may be located
in any container in Active Directory, not only in the "default" Users container.

A sample dump file produced by AddUsers.exe is placed below (the attributes'

names are in bold braces and are not really included in the file). Such a file can easily
be imported to a spreadsheet.

[User]
{samAccountName, name, password, description, homeDrive, homeDirectory, profilePath,
scriptPath}
Administrator,,,Built-in account for administering the
computer/domain,,,,
Guest,,,Built-in account for guest access to the computer/domain,,,,
 JSmith,John Smith,,A test user,Z:,\\netdcl\UserData\JSmith,
\\netdcl\Profiles\JSmith,Users\Welcome.vbs...
[Global]
{samAccountName, description, member's account names...}
Domain Admins,Designated administrators of the domain,Administrator,
Domain Controllers,All domain controllers in the
domain,NETDC1$,NETDC4$,
Domain Users,All domain users,Administrator,HelpAssistant_67861b,
SUPPORT_388945a0, krbtgt,SUBDOM$,Bob,John,Pam,...
...
[Local]
{samAccountName, description, member's account names...}
Administrators,Administrators have complete and unrestricted
access to the computer/domain,NET\Administrator,NET\Enterprise
Admins,NET\Domain Admins,
DC1Loca1Group,NET\John,NET\Lee,NET\Jessica,NET\Globa1Gr1,NET\UniGr2,
NET\DC1LocGr1,
...

Notice in the last line that groups may contain other groups (the group names are
shown in bold) including local groups (at the native and Windows .NET (version
2002) functional levels of a domain).

Caution It is possible that this tool has problems displaying memberships in global
and universal (placed in the [Global] section) groups. Test this in your
environment before you do any real work!

As you can see, the dump file contains three sections: User, Global, and Local. The
same format can be used for creating new users and groups. The irrelevant trailing
commas, as well as unused sections, can be omitted in the input file. New groups
may either be empty or contain the names of their members.

Modifying Group Membership

The Active Directory Users and Computers snap-in has a feature for "bulk"
operations that permits you to add a number of selected users and contacts to a
group. Point to an account (or choose a few accounts) and select the Add to a
group command from the context or Action menu, or click the Add the selected

objects to a group you specify button on the toolbar. Then specify a group in
the Select Group window. In Windows .NET, you can also carry out drag-and-drop
operations.

If you initially select an OU, the system asks whether you want to add all users and
contacts from this container to the specified group. This feature is very helpful for
administering OUs (but in Windows .NET, it is lacking).

To populate groups, you can use the LDIFDE and CSVDE tools, as well as the
AddUsers.exe utility. LDIFDE is also able to delete members from groups.
On computers running Windows .NET, you can use the standard DsMod.exe utility
that performs all modifications of groups. For example, the following command adds
two new members to the Schema Admins group:

C:\>dsmod group "CN=Schema Admins,CN=Users,DC=net,DC=dom" -addmbr

"CN=John Smith,OU=Staff,DC=net,DC=dom"
"CN=Pamela,OU=Staff,DC=net,DC=dom"

The -rmmbr parameter removes the specified members, and the ‘-chmbr parameter
replaces all group members.

Publishing Folders and Printers

Active Directory considerably simplifies work with shared network resources in

comparison with the traditional method of browsing domains. If a resource has been
published in Active Directory, users can easily locate it (see, for example, the Search
| For Printers command in the Start menu) and connect to it (see Fig. 8.2).
Furthermore, to simplify the process of locating resources, you might want to publish
all of them in one OU.

Fig. 8.2: Search for all printers in the enterprise (forest)

Publishing a folder or a printer in Active Directory means, in other words, creating a

new directory object — Shared Folder or Printer, respectively.

Shared folders in Active Directory have a feature that helps users to search for
information according to its characteristics. Select a published folder from the Active
Directory Users and Computers snap-in's tree pane, open its Properties window,
and click Keywords. You can add words that are logically related to the folder's
contents to the list. Then, if a user begins a search for shared folders in the Find
window, he or she can specify keywords and find resources based on their contents
rather than their names.

Printers (more precisely — printer devices) connected to Windows 2000/XP/.NET

computers can be published only from a printer's Properties window (the List in the
Directory flag on the Sharing tab). In other cases, you can use the Pubprn.vbs
script.
By default, the local printer on a domain client computer is not published during its
installation if you do not share it at once. If a printer is installed as shared, it is
immediately published in Active Directory in the computer's container (see "Users,
Groups, and Computers as Containers Mode" in Chapter 7). You can clear the List
in the Directory flag at any moment, and the printer object will be deleted from
Active Directory.

Caution When publishing a folder, you must be cautious, because the system will not
verify the entered folder name, and, as a result, you may run into an error in
the future, but only when you open the folder or map to it.

If the RDN and NetBIOS names of a Windows 2000 domain are different,
you will get the error — "The system cannot find the file specified" — when
publishing a printer (see the Microsoft Knowledge Base article Q255496). To
resolve the problem, you must install the latest Windows 2000 Service Pack
(at least, SP 1).

You can configure the process of publishing and pruning printers in the domain by
using group policies (see the Computer Configuration | Administrative Templates
| Printers node in the Group Policy Object Editor snap-in).

Both in Windows 2000 and Windows .NET domain, it is possible to enable Location
Tracking, a feature that allows users to find printers accordingly to their physical
locations. (See a remark in the "Active Directory Sites and Services snap-in" section
of the previous chapter.)

Pubprn.vbs Script

You can execute the system Pubprn.vbs script without parameters and get the help
information. The following command, for example, publishes the HP6MP printer
connected to the WKS10 computer in the Staff OU of the net.dom domain:

pubprn \\wks10\hp6mp "LDAP://OU=Staff,DC=net,DC=dom"

The system verifies the printer name and the existence of the object that is specified
by the LDAP name. If the printer has been published successfully, you will see a
message displaying the LDAP name of the printer in Active Directory.

Connecting to Shared Resources

Search operations are the preferred way for locating shared network resources in
AD-based domains. A user can find the necessary printer or shared folder easily and
perform any operation available while browsing through the domain tree.

The scope of the search can vary from a specific container (OU) in a domain to the
entire forest. (The Entire Directory option is equivalent to searching Global Catalog.)
In addition, users can specify various search criteria such as printer speed,
resolution, and so on. Fig. 8.2 contains an example of how to find all printers in the
forest. As you can see in the Server Name column, the printers come from various
domains. A user can point to an applicable printer and select the necessary operation
from the context menu.

Users can carry out the following actions on the found shared folder: open, search
the folder, map a network drive, and others.

Managing FSMO Roles in the Forest

Because the location of the Flexible Single Master Operation (FSMO) roles' masters
is very important for the proper functioning of a multi-domain forest, an administrator
must know which domain controllers possess a specific role(s) at any moment of the
entire network's lifetime. Therefore, he or she must have the facilities to find the role
masters easily and to transfer a role from one DC to another. Moreover, it is
necessary to have a way to forcibly transfer a role from a defunct DC. This is referred
to as the "seizing of role" process.

Finding FSMO Role Owners

To find the owners of FSMO roles (operation masters), an administrator can use the
"standard" administrative tools (see the previous chapter):

ƒ The Active Directory Users and Computers snap-in displays the RID, PDC,
and Infrastructure masters.
ƒ The Active Directory Domains and Trusts snap-in displays the Domain
Naming master.
ƒ The Active Directory Schema snap-in displays the Schema master.

This approach is, however, time-consuming, and it makes sense to use some
command-line tools or scripts. Some such tools are described below; for more
information, see Chapter 17, "Scripting Administrative Tasks" (the "How to Find an
FSMO Master?" section and Listing 17.20).

Windows .NET — DsQuery Utility

A brand-new command-line utility, DsQuery.exe, will help you to find a specific role
master, for example:

C:\>dsquery server -hasfsmo rid

"CN=NETDC1,CN=Servers,CN=NET-Site,CN=Sites,CN=Configuration,
DC=net, DC=dom"

You can also specify other roles: pdc, infr, name, schema.

Windows Domain Manager (NetDom.exe) (ST)

NetDom.exe (see Chapter 12, "Manipulating Active Directory Objects") can display all
operation masters known to a specified DC. Use the following command syntax:

C:\>netdom QUERY /Domain:net.dom FSMO

DumpFSMOs.cmd (RK)

This command file is, in fact, a chain of instructions to the NTDSutil tool. (These
instructions can also be entered manually.) The main command in that file is the
following:

ntdsutil roles Connections "Connect to server %1" Quit

"select Operation Target" "List roles for connected server"
Quit Quit Quit

The only mandatory parameter is the name of the DC from which the information is
retrieved. A sample screen output is shown below (the utility's prompt is in bold):

C:\>dumpfsmos.cmd netdc1
ntdsutil: roles
fsmo maintenance: Connections
server connections: Connect to server netdc1
Binding to netdcl ...
Connected to netdc1 using credentials of locally logged on user.
server connections: Quit
fsmo maintenance: select Operation Target
select operation target: List roles for connected server
Server "netdc1" knows about 5 roles
Schema - CN=NTDS Settings, CN=NETDC1, CN=Servers,
CN=NET-Site,CN=Sites,CN=Configuration,DC=net,DC=dom
Domain - CN=NTDS Settings,CN=NETDC1,CN=Servers,
CN=NET-Site,CN=Sites,CN=Configuration,DC=net,DC=dom
PDC - CN=NTDS Settings,CN=NETDC1,CN=Servers,
CN=NET-Site,CN=Sites,CN=Configuration,DC=net,DC=dom
RID - CN=NTDS Settings,CN=NETDC1,CN=Servers,
CN=NET-Site,CN=Sites,CN=Configuration,DC=net,DC=dom
Infrastructure - CN=NTDS Settings,CN=NETDC3,CN=Servers,
CN=NET-Site,CN=Sites,CN=Configuration,DC=net,DC=dom
select operation target: Quit
fsmo maintenance: Quit
ntdsutil: Quit
Disconnecting from netdc1...

Active Directory Replication Monitor (ReplMon.exe) (ST)

All operation masters can be displayed with ReplMon.exe. Start the tool and add
servers to the Monitored Servers list (tree). (In this case, it is enough to add one
server only.) Select a DC from the tree pane, open the Properties window, and click
the FSMO Roles tab. Fig. 8.3 shows a sample view of this tab.
Fig. 8.3: Viewing all operation masters (the owners of FSMO roles) for a domain

From this window, you can test any operation master by clicking Query. ReplMon
answers with the following message: "Active Directory Replication Monitor was
able/unable to resolve, connect, and bind to the server hosting this FSMO role."

Note In addition, ReplMon can display all Global Catalog servers in the enterprise
(select the Show Global Catalog Servers in Enterprise command in a
monitored server's context menu).

Transferring and Seizing FSMO Roles

Usually, to transfer an FSMO role from one DC to another, the administrative snap-
ins should be used. To seize a role, you must use the NTDSutil.exe.

Note For additional information on FSMO roles, you might be interested in Microsoft
Knowledge Base articles Q223787 and Q223346.

RID, PDC, and Infrastructure Operation Masters

You might want, for some reason (e.g., before shut downing a DC for maintenance),
to transfer a FSMO role from the role's master to another DC in the domain. In the
Active Directory Users and Computers snap-in window, you must first connect to
the DC that is the potential (new) operation master, point to the root node in the tree
pane, and select the Operation Masters command on either the context or Action
menus. Click the appropriate tab: RID, PDC, or Infrastructure. You will see the
current owner of a FSMO role and the potential master name. Click the Change
button, and you will get a new operation master.

Be careful when transferring the Infrastructure role. If there are two or more DCs in
the domain, make sure that a message similar to the following one has not appeared
in the Directory Service log on the new operation master:

Event Type: Error

 Event Source: NTDS General

Event Category: Directory Access

Event ID: 1419

Date: 5/31/2002

Time: 6:07:14 PM

User: NT AUTHORITY\ANONYMOUS LOGON

Computer: NETDC1

Description:

The local domain controller is both a global catalog and the

infrastructure operations master. These two roles are not compatible.

If another domain controller exists in the domain, it should be made the

infrastructure operations master. The following domain controller is a
good candidate for this role.

Domain controller:

CN=NTDS Settings, CN=NETDC3, CN=Servers, CN=NET-

Site, CN=Sites, CN=Configuration, DC=net, DC=dom

If all domain controllers in this domain are global catalogs, then there
are no infrastructure update tasks to complete, and this message might
be ignored.

Domain Naming Operation Master

The Active Directory Domains and Trusts snap-in allows you to transfer the
Domain naming master FSMO role to any DC in the domain tree. This procedure is
simple: connect to the DC that will be the new role's owner, point to the root node in
the tree pane, and select the Operations Master command from the context menu.
Make sure that the names of the current master and future master are correct, click
Change, and confirm the operation. Remember that only one server in the forest
(enterprise) can perform the Domain naming master role, and in addition, that server
must be a Global Catalog server.

Schema Operation Master

The Active Directory Schema snap-in allows transfer of the Schema Master FSMO
role to any DC in the forest. You should first connect to the potential master of the
role, point to the root node in the tree pane, and select the Operations Master
command from the context menu. After checking the DC name, click Change.
Remember that only one server in the forest can perform the Schema Master role.

Attention To modify the schema in Windows 2000, you must first enable this
operation (see Chapter 7, "Domain Manipulation Tools"). When you have
transferred the Schema Master role to a DC, the flag The Schema may
 be modified on this Domain Controller remains set on the old schema
master. This might not be in accordance with your intentions, however.

Using NTDSutil

The NTDSutil can be used for transferring any FSMO role. This is the only tool that
allows an administrator to forcibly assign a role to a DC. (It is assumed that the old
owner of this role has been destroyed and cannot be repaired.) Using NTDSutil will
be discussed in detail in Chapter 10, "Diagnosing and Maintaining Domain
Controllers."

Refreshing Group Policy

When an administrator has changed a GPO, he or she may want to refresh group
policy application to verify the effect of the new settings. (Certainly, it is possible to re
boot the computer or make the user re-register to the domain. However, this is not
always convenient.) On computers running Windows 2000, to perform this task, you
can use the SecEdit.exe command-line utility. Windows XP/.NET systems offer a
new utility (which you should use) — GPupdate.exe — for that purpose.

The command syntax is very simple. To refresh user policies, enter either of the
following commands (applicable to your system):

C:\>secedit /refreshPolicy user_policy — on Windows 2000

C:\>gpupdate /Target:User — on Windows .NET

The following commands refresh computer policies:

C:\>secedit /refreshPolicy machine_policy

C:\>gpupdate /Target:Computer

The GPupdate command without parameters updates both user and computer
policies.

If you want to re-apply policies (GPOs), even if they have not changed since the last
time they were applied, add the /enforce parameter to the SecEdit command or the
/Force parameter to the GPupdate command. (Normally, GPOs are applied only once;
unchanged GPOs are skipped.)

Note You may want to change the default GPO refresh interval (90 minutes for client
computers and 5 minutes for domain controllers), as well as the offset (30
minutes for client computers and 0 minutes for domain controllers). For that
purpose, use group policies (Computer Configuration | Administrative
Templates | System | Group Policy) or modify the system registry. For more
information, see Microsoft Knowledge Base article Q203607.

Triggering Replication

An administrator has three tools that can be used to trigger Active Directory
replication of either all directory partitions (contexts) or just a specified partition
between a domain controller and one or all of its direct replication partners:
 ƒ The Active Directory Sites and Services snap-in
ƒ RepAdmin command line utility
ƒ ReplMon GUI utility

As is typical for practically any administrative task, you can also use scripts (see
example in Chapter 17, "Scripting Administrative Tasks").

Note Remember that the "source" server (DC) always replicates its changes to the
"target" server (DC). Usually, you first select the target, then the source.

The Active Directory Sites and Services Snap-in

This snap-in allows an administrator to initiate replication of all configured directory

partitions from each replication partner separately. Select a target DC from the
Servers container of the applicable site and point to its NTDS Settings object. You
can trigger replication from any server represented by a Connection object in the right
pane (see example in Fig. 8.4). Select a connection and click Replicate Now in the
context menu. You must wait until replication completes (with the "Active Directory
has replicated the connections" message if successful).

Fig. 8.4: Triggering replication from a direct partner

All directory partitions configured for that partner are replicated. (You can see all their
names — including application directory partitions — in a connection's Properties
window.) You have no options to replicate one partition only.

Replication Diagnostics Tool (RepAdmin.exe) (ST)

With RepAdmin.exe, you replicate each directory partition separately and from one or
all sources. (This command-line tool has the same functional capabilities as
ReplMon, a GUI tool.) For example, to trigger replication for a destination server, you
can use the following command:

C:\>repadmin /syncall netdc2.net.dom DC=net,DC=dom,

where netdc2.net.dom is the server DNS name, and DC=net, DC=dom is a partition name
(the domain naming partition in this case).

The difference between this command and the operation shown in Fig. 8.4 is the
following:
 ƒ The command replicates only one partition, but from all partners.
ƒ In the snap-in window you replicate all partitions, but from one partner only.

To force replication in the entire domain (forest), you might write similar commands
for each DC and all directory partitions to a command file, which will serve to fulfill
total replication in the domain.

Caution The repadmin /syncall serverName command replicates only one directory
partition (the Configuration partition), and performing such a command is not
enough to fully replicate the server specified.

The Windows .NET version of RepAdmin provides a new flag /A for the /syncall
operations. The following command synchronizes all partitions stored on NETDC1
DC with all its replication partners:

C:\>repadmin /syncall netdc1.net.dom /A

The following command replicates one partition from one partner (specified by its
GUID):

C:\>repadmin /sync DC=net,DC=dom netdc1.net.dom

a10bc624-6d04-44e7-adf9-5ef4282efbb1

Normally, RepAdmin waits for replication to be completed. You can add the /async
parameters to the command to start an operation and not wait for its completion.

RepAdmin will be described in detail in Chapter 11, "Verifying Network and

Distributed Service."

Active Directory Replication Monitor (ReplMon.exe) (ST)

A GUI tool, ReplMon.exe, provides an administrator with the following replication

modes (from the most "global" to more granular ones) for a server specified:

ƒ Synchronize each directory partition with all replication partners (there are
three additional options available with this mode)
ƒ Synchronize this directory partition with all replication partners
ƒ Synchronize this directory partition with this replication partner

You never need wait for a replication operation to complete, and all operation results
are written to the log files.

RepAdmin is described in detail in Chapter 11, "Verifying Network and Distributed

Service."

Additional Replication Tools To force synchronization of replica sets managed by

the File Replication Service (FRS), the contents of
the SYSVOL volume, for example, use the ntfrsutl poll
command. See details in Chapter 11, "Verifying
Network and Distributed Services."
To synchronize a Windows 2000- or Windows .NET-based server that owns the PDC
Emulator FSMO role with Backup Domain Controllers (BDCs) in a mixed-mode
domain, use the NLtest.exe tool. See the /REPL, /SYNC, /BDC_QUERY, and other
parameters of this tool. The LBridge.cmd command file from the Windows 2000
Server Resource Kit should be used for copying files from the System Volume
(SYSVOL) share to the export directory on a Windows 4.0-based BDC.

You can write custom scripts that will initiate replication events in accordance with
your own strategy. See, for example, Listing 17.17 in Chapter 17, "Scripting
Administrative Tasks."

Delegating Administrative Control

One of the most remarkable features that Active Directory realizes is the possibility of
delegating all or part of administrative power over an OU or a directory container to a
group or a user (in both Windows 2000 and Windows .NET domains). Delegation of
control is essentially the same thing as "wizard-aided" granting of permissions on
Active Directory objects to a user or group. You can manually assign the permissions
necessary for performing this administrative task to a user or group, but this process
is considerably simplified thanks to the Delegation of Control Wizard. Delegating
control is quite a simple operation, and problems are only possible when delegated
tasks are being revoked from the user or group.

An administrator can delegate control (i.e., use the Delegation of Control Wizard
rather than manually assign permissions) for the following Active Directory objects
(common administrative tasks are cited in parentheses):

ƒ In the Active Directory Sites and Services snap-in (typical permissions are
Full Control, Read/Write, Create/Delete All Child Objects, Read/Write All
Properties):
ƒ Sites container
ƒ Inter-Site Transport container
ƒ Subnets container
ƒ A site(s) (only Manage Group Policy links task)
ƒ Server container in site(s)
ƒ In the Active Directory Users and Computers snap-in (the list of available
permissions depends on the type of Active Directory container):
ƒ Entire domain (Join a computer to the domain; Manage Group Policy
links)
ƒ Organizational unit (Create, delete, and manage user account; Reset
passwords on user accounts; Read all user information; Create, delete,
and manage groups; Modify the membership of a group; and Manage
Group Policy links. In Windows .NET, there are a few additional tasks.)
ƒ Computers container
ƒ ForeignSecurityPrincipals container
ƒ System container
ƒ Users container

Attention Remember that the Authenticated Users group (i.e., any logged on user)
by default has permission to add 10 computers to a domain. This group
 has permission to Read All Properties of a domain object; consequently,
the group can read the value of the ms-DS-MachineAccountQuota
attribute, which by default is equal to 10. (This value can be viewed or
modified by using the ADSI Edit snap-in.) Draw your own conclusions.
(You might want to change this situation.)

To start the process of delegating control, run the appropriate snap-in, point to an
Active Directory container, OU, or the domain itself in the tree pane, and select the
Delegate control command on the context or Action menu. Depending on the
container type, you can select a common task(s) or create a custom task. In the first
case, you use a pre-defined set of permissions, while in the second case, you select
objects and permissions yourself, which allows you to be more specific in delegating
the administrative rights.

Although it is very simple to delegate control, revoking administrative rights from a

user or a group requires a bit more effort and clearer understanding of the process.
You must turn on the Advanced Features mode (see the previous chapter), select the
container over which control has been delegated, and open the Security tab in the
container's Properties window. Then, find the permissions and access control
settings for the user or the group, and delete them. By doing so, you are editing the
ACL entries for a directory object. Delegation of control is done using the same
process, but is simplified thanks to the wizard. Understanding this aspect will help
you to manipulate directory objects easily and flexibly and, as a result, to tune Active
Directory accordingly to fit your tasks.

Look at Fig. 8.5. The Delegation of Control Wizard has been executed twice. First,
the permission to join computers to the domain has been delegated to the Admins
group. (You can see that permission as inherited from the domain context
DC=net,DC=dom.) Second, the Admins group has received the permission to create,
delete, and manage user accounts in the Staff OU. That right is defined at the OU
level and not inherited. As a result, the Full Control, Create/Delete User Objects, and
Create Computer Objects permissions have been added to the access control lists
(ACL) of the domain container and the Staff OU. (In Fig. 8.5, you can see these
permissions in the Permission entries pane — the first three lines.) You could add
these permissions manually, but the wizard helps you to do this without error and
frees you from having to know about all the details of Active Directory object
inheritance and permissions.
Fig. 8.5: The result of using the Delegation of Control Wizard: the highlighted
permission allows the Admins group to join computers to the domain and manage
users in the Staff OU

If you want to revoke all administrative rights from the Admins group, you should
perform the following steps:

1. To revoke control power over the Staff OU, delete the first two lines in the
Permission entries pane.

In Windows .NET, you can click the Default button, and all permissions added
for the selected directory object will be deleted. Be careful, since: 1) other
users or groups might have administrative rights over the object, and you will
delete all additional permissions; and, 2) the inherited permissions will be
restored.

2. To delete the inherited permissions — the Create Computer Objects

permission in our case — open the Security tab of that object where the
permissions have been defined, and delete corresponding line(s) in the
Permission entries pane.

On the other hand, you might want to allow the Admins group to perform some
additional tasks (after the Delegation of Control Wizard has been executed once, or
in any moment). Click Edit on the Permissions tab (see Fig. 8.5). The Permission
Entry window will allow you to define permissions (or delegate/revoke administrative
control, which is the same thing) on the selected object with greater granularity then
the wizard allows. As you can see in Fig. 8.6, there are a number of operations
whose execution by the selected user or group it is possible to allow/forbid.
Fig. 8.6: "Fine tuning" of permissions on the selected directory object

Auditing Access to Active Directory Objects

In general, the procedure of enabling audit consists of two steps. To audit access to
Active Directory, you must:

1. Enable the appropriate auditing policy.

2. Specify events to audit.

Auditing access to Active Directory objects relates to operations performed on the

domain controller. Therefore, the most appropriate place to enable audit is the
Default Domain Controllers Policy (or another GPO linked to the Domain Controllers
OU). You may use either the Group Policy Object Editor snap-in linked to that GPO
or the Domain Controller Security Policy snap-in. Select the node Computer
Contiguration | Windows Settings | Security Setting | Local Policies | Audit
Policy and click twice on the Audit directory service access policy (Fig. 8.7). (Default
setting for all audit policies — NO auditing.) Then set the Define these policy
settings flag and check the Success and/or Failure box.
Fig. 8.7: Enabling auditing events related to access to Active Directory objects
Attention No auditing and Not defined are not the same thing. When a policy is Not
defined, you can define it at any other level. If a policy is set to No
auditing, it overwrites all possible settings from other levels. The group
policies for the Domain Controllers OU are applied the latest and have the
highest priority. Therefore, the default audit settings defined by these
policies override any parameters assigned at other (lower priority) levels.

After the policy has been set, you can immediately apply it with either the
secedit/refreshpolicy machine_policy or gpupdate /Target:Computer command.

For read operations, it is recommended that you audit failure events, because a large
number of successful event entries can quickly overflow the Security log.

The performance of domain controllers can also suffer. For write, create/delete, and
other similar operations (that are much less frequent than read operations), it is
possible to audit both success and failure events.

By default, special access (successful and failed events) to all objects in a domain is
audited for the Everyone group. All domain objects inherit this setting from the root
domain container (Fig. 8.8). Some containers have additional audit settings. All
settings include auditing for "critical" operations, such as Write, Delete, Modify, and
others. (Look up the entire list.)
Fig. 8.8: The default audit settings for the Users container

You can see all audit entries in an object's Properties window: open the Security
tab, click Advanced, and open the Auditing tab. Then click Edit to view or change
audit parameters. If you open the Auditing tab for a non-root directory object, you
will notice that all checked boxes are grayed out. This means that all parameters are
inherited from the parent object. They cannot be directly modified, so you may need
to address the parent or root object. If you check a free box, the system will create a
new auditing entry and add it to the list for the selected object only.

Caution Because successful events are registered by default, you might get a huge
number of entries in the Event Viewer when working with auditing turned on.
Therefore, you might want to change the default settings when performing
an audit for an extended period of time.

You can view all information on audit events in the Security log of the Event Viewer.
The source for these events is "Security", and the category is "Directory Service
Access".

Recovering Active Directory

General Considerations

The standard Backup utility (NTBackup.exe) allows you to back up and restore both
critical data and Active Directory. Operations with Active Directory can only be done
locally for each domain controller. A backup operation is performed while a DC is
online. To restore Active Directory on a DC, you must boot this DC into Directory
Service Restore Mode (press <F8> at the computer startup).

System State

Backing up Active Directory is a part of the process of saving the System State data
of a DC. You cannot back up (or restore) individual items of the System State. On a
member server or a workstation, the System State includes the following:

ƒ Boot Files
ƒ COM+ Class Registration Database
ƒ Registry

On a domain controller, two other items are added (Fig. 8.9):

Fig. 8.9: Components of a domain controller's System State

ƒ Active Directory (the ntds.dit, edb.chk, edb*.log, and resl.log and res2.log files)
ƒ SYSVOL (System Volume) (by default, the %SystemRoot%\SYSVOL\sysvol
folder)

If the Certificate Services are installed on a server or DC, there is one more item:

ƒ Certificate Server

Important From the foregoing, it is possible to draw two very important conclusions:

ƒ You cannot backup the System State on a DC and restore it to

another DC, since the System State comprises such important
information as Registry, COM+ Class Registration Database,
TCP/IP configuration, etc. If you restore backup media on another
computer, you will get the same system parameters as the original
DC has, which results in fatal conflict.
ƒ There is no means to save/restore Active Directory configuration
"itself", i.e., independently of the domain controllers' configuration.
During each restoration of the System State you will reconstruct a
specific DC. That is why the export/import tools, such as LDIFDE
and CSVDE, could be very useful, since they allow you to
save/restore the custom Active Directory information only.
Schema

Modifications of the schema are irreversible, so you cannot restore an older version
of the schema. Created attributes and classes cannot be deleted, and it is only
possible to deactivate them. When restoring Active Directory, you cannot mark the
Schema partition as authoritative.

Tombstones

A recovery plan should take into account the lifetime of the Active Directory
tombstones (60 days, by default; minimal value is 2 days). This parameter is stored
(if it is defined) in the tombstoneLifetime attribute of a directory object named
N=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=<ForestRoot>. Tombstone is a deleted
object that is maintained in Active Directory during its lifetime, before the system
eventually destroys it. The age of the backup tape should not exceed this period of
time, otherwise the outdated data will be rejected.

Using Backup Media to Install Additional Domain Controllers

To reduce the amount of replicated data while promoting a Windows .NET-based

server to additional domain controller, you can use a backup file that contains the
System State of an existing DC. Therefore, you first need to save current Active
Directory information. This operation will be the same the System State backup
discussed below. Chapter 5, "Installing Active Directory," covers information on how
to restore a backup file and use it for the promotion of a server.

Backing up Active Directory

To back up the System State:

1. Run the Backup utility: click Start | All Programs | Accessories | System
Tools | Backup or enter ntbackup in the Run window.
2. Click the Backup tab and check the System State box in the tree pane. (You
can include some files in the backup as well.)
3. Enter the name of the backup file in the Backup media or file name field (keep
the file extension BKF) and click Start Backup.
4. In the Backup Job Information window (Fig. 8.10), enter the necessary data
and click Advanced.
 Fig. 8.10: Configuring a backup operation

5. The next window (Fig. 8.11) will allow you to set backup options. The System
State should always be saved as a normal backup. You might want to clear
the Automatically backup System Protected Files with the System State
box set by default if you need a compact backup file without all system files.
Usually, it is enough to have such a compact file (40–50 MB for small
domains) for many operations related to saving/restoring Active Directory. A
full backup of the System State will be about 300 MB in size.

Fig. 8.11: Defining additional backup parameters

6. Close the Advanced Backup Options window and click Start Backup — the
backup process will begin.

Note Only the full backup will allow you to safely restore a crashed DC. It is possible
to repair the system from scratch in about 30–40 minutes. Restore a domain
controller image from a CD or network drive by using an image-duplicating tool
like Norton Ghost. Boot the server, and restore the full backup file. You will get
a fully operational DC retaining its SID, GUID, and other mandatory Active
 Directory parameters.

Restoring Active Directory

Restore is a more complicated process than back up. Generally, you have two
options:

ƒ Reinstall the system on the damaged computer, promote it to a domain

controller, and copy Active Directory information from other DCs through
replication. You will get an entirely new DC, and, therefore, need to delete any
references to the old DC from Active Directory.
ƒ Restore Active Directory from backup media, retaining the DC identity (SID,
GUID, etc.).

There are three different methods of restoring the System State from the backup
media:

ƒ Perform a primary restore when you have the only DC in the domain and
want to rebuild this domain. A primary restore builds a new FRS database;
therefore, the restored data will be replicated to other controllers in the
domain.
ƒ If there is at least one operational DC in the domain, perform a non-
authoritative (normal) restore. The repaired DC will receive current data
from other DCs through normal replication. The restored data will never be
replicated to other DCs. This is the most used type of restore.
ƒ If you want to restore inadvertently deleted Active Directory data and to
replicate these data to the other DCs, perform an authoritative restore. You
cannot perform a "true" rollback, since authoritative restore does not affect
changes made in the directory after the backup was created. These new data
will be replicated to the restored DC.

Important It is possible to authoritatively restore any directory partitions excluding

the Schema partition.

Remember that, in any case, Active Directory can be restored only when a DC has
been booted into the Directory Service Restore Mode.

Primary Restore

To restore a standalone domain controller:

1. Run the Backup utility and open the Restore and Manage Media tab (Fig.
8.12).
 Fig. 8.12: Restoring the System State from a backup media

2. Select the necessary media and check the System State box. Files should be
restored to the Original location.
3. Click Start Restore and confirm overwriting current System State in the
Warning pop-up window.
4. Click Advanced in the Confirm Restore window.
5. Set the checkbox shown in Fig. 8.13. Close the window, and begin restore.

Fig. 8.13: This checkbox is only set for a primary restore

6. When the Backup utility will finish and propose you to reboot the computer,
answer positively — reboot the computer into normal mode.

Non-Authoritative (Normal) Restore

A non-authoritative restore is performed as a primary restore; the difference is that

you should keep default settings of all options, i.e., the checkbox shown in Fig. 8.13
must be cleared. The restored DC will receive all changes from its replication
partners.
Authoritative Restore

To perform authoritative restore of Active Directory including the SYSVOL volume,

carry out the following operations:

1. Run the Backup utility and perform non-authoritative restore (see the previous
section). When the Backup utility completes its work, it proposes that you
restart the computer (Fig. 8.14). You must click No.

Fig. 8.14: Click No if you perform an authoritative restore

2. Restore the System State to an alternative location. See an example in Fig.

8.15.

Fig. 8.15: Selecting an alternative location for a restore operation

Important This second restore operation as well as Steps 5 and 6 below are
only necessary if you need to authoritatively restore the entire
System State or directory objects along with corresponding Group
Policy Objects. If you restore a single object, skip this step and go
directly to Step 3.

When the System State is restored to an alternative location, the

current System State (e.g., Registry or Active Directory data) will
stay intact. That is why you should carry out restore twice.

3. On Windows .NET-based servers, the following folders will appear in the

specified folder or on the disk (Fig. 8.16):
 Fig. 8.16: Structure of the SYSVOL folder in alternative location (for domain
net.dom)

o Active Directory (ntds.dit, edb*.log; these files can be used later to

promote a server to additional DC)
o Boot Files
o COM+ Class Registration Database (ComReg.Db.bak)
o Registry (default, SAM, SECURITY, software, system)
o SYSVOL (this folder reflects the structure of the SYSVOL volume)
4. When you restore data to an alternative location, the program does not offer to
reboot the computer. Close the Backup program.
5. Run NTDSutil.exe from the command prompt. A sample dialog for the
authoritative restore command is placed below (a subtree is restored in this
example):
6. C:\>ntdsutil
7. ntdsutil: Authoritative restore
8. authoritative restore: Restore subtree OU=Staff,DC=net,DC=dom
9. [Confirm the restore operation — click Yes in the pop-up window.}

Opening DIT database... Done.

The current time is 06-04-02 20:41.05.

Most recent database update occured at 06-03-02 17:52.23.
Increasing attribute version numbers by 200000.

Counting records that need updating...

Records found: 0000000038
Done.

Found 38 records to update.

Updating records...
Records remaining: 0000000000
 Done.

Successfully updated 38 records.

Authoritative Restore completed successfully.

authoritative restore: Quit
ntdsutil: Quit

10. Reboot the computer into normal mode and wait until the SYSVOL volume
will be published (look for event ID 13516 in the File Replication Service log
and use the net share command to monitor when the process will be
completed).
11. Copy contents of the SYSVOL volume from the alternative location to an
existing one. These changes of the SYSVOL volume will be the most recent
and, therefore, will be replicated to other DCs as the authoritative data.

In the example shown, an OU object has been restored. You can mark an individual
object (in the Windows .NET environment), subtree, or entire directory partition as
authoritative. This, however, does not extend to the Schema partition.

Caution Use authoritative restore with necessary directory objects only. Be very
selective and do not restore excessive objects. Be especially careful with the
Configuration partition. Do not use the restore database command unless you
completely understand how restore operations work.

Notice the line in bold that indicates an increment of the attribute version numbers,
and two previous lines. The version numbers increase by 100,000 for each day after
the original backup has been performed. You can view changes of metadata by using
ReplMon.exe. In our case, for example, the following command will be used:

repadmin /showmeta OU=Staff, DC=net, DC=dom netdc4.net.dom

By using this command on different DCs, you can verify whether the authoritative
restore was successful, and trace the replication's propagation.

If objects in your Active Directory installation have very low volatility, you might wish
to override the default value of the version increment. Use a command similar to the
following:

restore subtree OU=Staff, DC=net,DC=dom verinc 1000

Part IV: Using System Utilities and

Support Tools
Chapter 9: General Characteristics and Purpose of System Tools
Chapter 10: Diagnosing and Maintaining Domain Controllers
Chapter 11: Verifying Network and Distributed Services
Chapter 12: Manipulating Active Directory Objects
Chapter 13: Migration and Directory Reorganization Tools
Chapter 14: Security Tools
Chapter 15: Group Policy Tools

Where Can You Find All These Tools?

Windows .NET Support Tools

Sometimes, administrators forget or simply do not know that each Windows 2000 or
Windows .NET (as well as Windows XP) installation CD contains a pack of powerful
tools named Windows Support Tools. (This pack is the same for both Professional
and Server versions of Windows 2000. Windows .NET servers have more recent
versions of the Support Tools then Windows XP.) This pack must be installed
separately from the operation system itself. Run the Setup.exe or Suptools.msi file
from the \SUPPORT\TOOLS folder, and install the pack on the hard disk. (The
Windows.NET Support Tools require about 20 MB of the hard disk space.) Then you
will be able to start the tools from the Start menu or the command prompt.

Windows Resource Kit

The Windows Support Tools can be regarded as a subset of the Windows Resource
Kit, a separately purchased product that contains hundreds of various utilities as well
as comprehensive printed documentation. (There are two versions of the Kit: Server
and Professional. Many of the tools described below are present in both versions.)
The Windows 2000 Resource Kit requires about 60 MB of the hard disk.

The good news is that the Windows 2000 Resource Kits (both Professional and
Server versions including the Windows 2000 Server Deployment Planning Guide)
and Windows XP Professional Resource Kit are freely accessible on the Microsoft
Tech-Net website (see links in Appendix A). Moreover, some very useful tools from
these kits can be also downloaded for free from the Microsoft website (see Appendix
A).

At this time, the Windows .NET Server Resource Kit has not yet been released, so
some of the tools (as well as various administrative scripts) from Windows 2000
Server Resource Kit have been tested in the Windows .NET environment. They
appear to work properly.

The Windows 2000 Server Resource Kit contains a collection of Visual Basic (VB)
scripts called Remote Administration Scripts. Several scripts from this collection are
mentioned in the tables in this chapter. (These scripts can safely run on Windows
.NET servers, too.) If you are going to write your own scripts or applications, pay
close attention to these scripts, since they will help you speed up the process of
studying scripting basics (including ADSI programming concepts).

Classification by Purpose

First, you should become generally acquainted with the existing tools and the
administrative tasks for which they are used. Look at Table 9.1. The tools from the
Windows 2000 Server Resource Kit and Windows .NET Support Tools packs listed in
this table are divided into categories depending on the basic purpose of a tool. In
some cases, the grouping of tools is rather voluntary, since some utilities can be
used for different purposes.

Table 9.1: Windows 2000 Tools Sorted by the Purpose They Serve
Administrative task Tools to be used

Browsing and editing Active ADSIEdit.msc, Ldp.exe, DsMod.exe,

Directory objects DsMove.exe, DsRm.exe, AdsVw.exe,
ModifyUsers.vbs
Querying Active Directory DsQuery.exe, DsGet.exe, Ldp.exe, Search.vbs,
UserAccount.vbs, EnumProp.exe
Migration and restructure; ADMT, MoveTree.exe, NetDom.exe,
manipulating Active Directory ClonePrincipal, DsAdd.exe, AddUsers.exe,
objects GrpCpy.exe
Bulk import/export CSVDE.exe, LDIFDE.exe, AddUsers.exe,
CreateUsers.vbs
Active Directory database NTDSutil.exe
diagnostics and maintenance
Diagnosis NetDiag.exe, NSlookup.exe, DCdiag.exe,
NLtest.exe, DNSCmd.exe, RPCPing
Replication RepAdmin.exe, ReplMon.exe, DsaStat.exe,
NTFRSutl.exe
Active Directory security ACLDiag.exe, DsACLs.exe, SDCheck.exe,
KerbTray.exe, KList.exe
System objects (files, shares, SIDWalker, SublnACL.exe, ADMT
registry, etc.) security
Group Policies GPOTool.exe, GPResult.exe

Active Directory Migration Tool (ADMT) and AdsVw.exe (from the ADSI SDK) can be
downloaded for free from the Microsoft website (see links in Appendix A). They are
also included in the table. Every tool mentioned here is characterized in Table 9.2.

Table 9.2: Purpose of the Selected Windows 2000 and Windows .NET Tools
See
Toolname Contained in Purpose
chapter
ACLDiag.exe (ACL ST View permissions (ACLs) on a 14
Diagnostics) directory object. Verify delegation
of administrative control, and
whether the object security settings
correspond to the schema defaults.
AddUsers.exe (Add RK Output, create, and delete multiple 8
Users) user accounts. Add users to
 Table 9.2: Purpose of the Selected Windows 2000 and Windows .NET Tools
See
Toolname Contained in Purpose
chapter
groups.
ADSIEdit.msc (ADSI ST View and modify Active Directory 7
Edit snap-in) (GUI tool) objects (including application,
schema, and configuration
directory partitions). Set objects'
ACLs.
AdsVw.exe (Active ADSI SDK Same as above, for both Active 12
Directory Browser) (GUI Directory based (Windows 2000
Tool) and Windows .NET) and Windows
NT domains (SAM database).
ClonePrincipal ST Create a copy of a user or group 13
account in a different forest and
retain user or group access rights
to directory objects or shared
resources. (Includes Clonepr.dll,
Clonepr.vbs, Clonelg.vbs,
Clonegg.vbs, Cloneggu.vbs,
SIDHist.vbs tools.)
CreateUsers.vbs RK (RAS) Create multiple user accounts in 8
default or specified containers.
CSVDE.exe (CSV Sys Export and import multiple directory 12
Directory Exchange) objects using a file in CSV format.
DCdiag.exe (Domain ST Diagnose domain controller issues: 10
Controller Diagnostic connectivity, availability of the
Tool) directory and other services,
replication, etc.
DHCPloc.exe (DHCP ST Display active DHCP sewers and 4
Server Locator Utility) detect any unauthorized sewers.
Find DHCP servers available to a
DHCP client.
DNScmd.exe (DNS ST Check and/or modify zones and 4
Server Troubleshooting resource records on a Windows
Tool) 2000/.NET DNS server. Manage
the zones and the DNS server
configuration.

For the Windows .NET version

only:

Create/delete an application
directory partition, control partition
replication scope, move a zone to
another directory partition.
 Table 9.2: Purpose of the Selected Windows 2000 and Windows .NET Tools
See
Toolname Contained in Purpose
chapter
DsACLs.exe ST View and/or modify permissions 14
(ACLs) on directory objects.
Restore default permissions.
DsAdd.exe* Sys Add to the directory a computer, 8
contact, group, OU, or user object.
DsaStat.exe (DSA ST Compare directory partitions on two 11
Statistics) different domain controllers and
display statistics or :comparisons of
attributes. Global Catalog servers
can also be checked.
DsGet.exe* Sys Retrieve the attributes of a specific 12
object type from the directory.
DsMod.exe* Sys Modify attributes of a specific 12
object type (computer, contact,
group, OU, server, or user).
DsMove.exe* Sys Rename a directory object or move 12
it to another container.
DsQuery.exe* Sys Search the directory for objects of 12
any type and display any attributes
of found objects. The most flexible
command-line search tool.
DsRm.exe* Sys Delete a directory object or an 12
entire subtree.
DumpFSMOs.cmd RK Display the FSMO roles known to 8
the specified domain controller.
EnumProp.exe RK Display some or all attributes —
(including GUIDs, SIDs, and
security descriptor) of an Active
Directory object specified by its
distinguished name. (The LDAP
provider is used.)
GPOTool.exe (Group RK Test consistency of GPOs and 15
Policy Verification Tool) check their replication in a domain.
GPResult.exe (Group RK (Windows View group policy settings applied 15
Policy Results) 2000) Sys to a user and/or computer
(Windows
.NET)
GPUpdate.exe* Sys Re-apply computer and/or user 8
group policy
GrpCpy.exe (GUI Tool) RK Copy users from one group to —
another in the same or another
domain
 Table 9.2: Purpose of the Selected Windows 2000 and Windows .NET Tools
See
Toolname Contained in Purpose
chapter
KerbTray.exe (Kerberos RK Display and purge all cached 14
Tray) (GUI tool) Kerberos tickets for authenticated
services
KList.exe (Kerberos RK Same as above. Can purge only 14
List) specified tickets
Ksetup.exe (Kerberos ST Configure Windows 2000 clients to —
Setup) use an MIT Kerberos server
instead of a Windows 2000 domain
KTPass.exe (Kerberos ST Configure a non-Windows 2000 —
Keytab Setup) (UNIX) Kerberos service as a
security principal in the Windows
2000 Active Directory
LDIFDE.exe Sys Export and import one or more 12
directory objects using a file in
LDIF format. Modify attributes of
object(s)
Ldp.exe (Active ST Perform LDAP operations against 12
Directory Administration any LDAP-compliant directory such
Tool) (GUI tool) a Active Directory
ModifyUsers.vbs RK (RAS) Modify specified attributes of —
multiple domain users. An input
text file with defined values can be
used
MoveTree.exe (Active ST Move directory objects, such as 13
Directory Object user accounts, OUs, and universal
Manager) groups from one domain to another
in the same forest
NetDiag.exe (Network ST Test various networking and 11
Connectivity Tester connectivity issues (protocols,
binding, DNS, WINS, and many
others) on client computers
NetDom.exe (Windows ST Manage and verify trusts and 12
Domain Manager) secure channels; join, move, and
remove computer accounts
NLtest.exe (NLTest) ST List domain controllers for a 11
domain, query for, trusted domains,
query and reset secure: channels
between domain computers, force;
replication to Windows NT 4.0
BDCs
NTDSutil.exe (Active Sys Manage Active Directory database 10
Directory Diagnostic files, operations masters, orphaned
Tool) domains and controllers. Perform
 Table 9.2: Purpose of the Selected Windows 2000 and Windows .NET Tools
See
Toolname Contained in Purpose
chapter
authoritative restore
NTFRSutl.exe RK Manage the File Replication 11
Service (including SYSVOL and
DFS roots replication)
RepAdmin.exe ST Display replication partners, 11
(Replication Diagnostics metadata and connections, force
Tool) replication of directory partitions,
trigger KCC
ReplMon.exe (Active ST Monitor and force replication, 11
Directory Replication display replication metadata,
Monitor) (GUI tool) topology, and domain controller
information
RPingc.exe (GUI tool), RK Test RPC connectivity between 11
and RPings.exe (RPC clients and RPC servers
Ping: Connectivity
Verification Tool)
SDCheck.exe (Security ST Verify a directory object's ACL 14
Descriptor Check Utility) inheritance and replication of the
security descriptor from one
domain controller to another
Search.vbs ST Search for a object against an 12
LDAP server
Security Administration ST Modify SIDs specified in the ACLs —
tools (SIDWalker) of files, shares, and registry keys.
Grant access rights on objects to
specified users and groups.
(Include ShowAccs.exe,
SIDWalk.exe, and SIDWalk.msc
tools.)
SublnACL.exe RK Display security descriptors for —
files, registry keys, or services.
Change security information such
as owner of an object, domain
name, or SID
UserAccount.vbs RK (RAS) Displays information on normal, —
locked out, and disabled user
accounts in a domain
Note Windows 2000 servers provide a few "traditional" utilities for administering
Windows NT 4.0 domains: Server Manager (srvmgr.exe), User Manager
(usrmgr.exe), and System Policy Editor (poledit.exe). These tools have not
been included in the current version of Windows .NET servers. The Windows
2000 Server Resource Kit also contains the Domain Monitor (dommon.exe). All
named tools are the updated versions that differ from their Windows NT 4.0
 counterparts. This may be important in some cases. Windows .NET servers do
not and, most likely, will not contain the utilities listed, but all of them can safely
run on Windows .NET-based computers within AD-based domains.

Description of the Selected Tools

Table 9.2 lists the file names of the tools as well as their "official" names; a short
description of each tool's characteristics is also given. The table is sorted by the
names of the files, because it is the filename of a tool that you will use most often. In
addition, the name of the pack that contains the tool is specified, along with the
chapter of this book that contains the most complete information about using the tool.
("ST" stands for the Windows .NET Support Tools, "RK" means the Windows 2000
Server Resource Kit, and "RAS" is the abbreviation for Remote Administration
Scripts. "Sys" means that the tool is a standard system tool. These marks are also
present in the subtitles of the following chapters.)

Important Most of the selected tools are contained in both Windows 2000 and
Windows .NET systems and can safely run on both Windows 2000- and
Windows XP/.NET-based computers. The Windows .NET versions of the
tools, as a rule, cannot run on Windows 2000-based computers, so you
need to take into account the limitations specific for each tool. See the
detailed information in the chapter specified.

A few brand-new tools are marked by an asterisk (*).

Chapter 10: Diagnosing and

Maintaining Domain Controllers
The two system tools described in this chapter treat domain controllers as
components that represent Active Directory as a distributed network service. In order
for Active Directory to function properly as a whole, all of its elements — Directory
System Agents (DSA) disposed on domain controllers — must be in good operational
condition. Therefore, an administrator must have tools that can help him or her to test
the actual state of every DC. Moreover, an administrator must have repair tools for
those emergency cases when the Active Directory database needs restoring,
cleaning up, or other "low-level" operations.

Domain Controller Diagnostic Tool (DCdiag.exe) (ST)

This utility, as a matter of fact, is a complex test (or more precisely — a set of
specialized tests) that allows an administrator to give a DC a quick "check up" and
locate any possible problems. DCdiag verifies the serviceability of a DC as well as its
relations (connectivity, trusts, replication issues, etc.) with other DCs that are the
replication partners of the selected DC. Thus, the utility primarily checks up parts of
Active Directory at a functional rather than a logical level (i.e., aspects such as data
consistency, semantic contents, etc., are not affected).
It would be a good idea to run DCdiag after and even before (see the description of
the DcPromo and RegisterInDns tests in Chapter 5, "Installing Active Directory")
installation of domain controllers. It is fairly typical — especially in small networks —
for an administrator to successfully (in his or her opinion) install Active Directory on
the first DC and consequently believe that the domain will automatically work
correctly since no faults were detected or error messages received. Problems usually
begin when the administrator adds clients to the domain or installs a second DC (in
the same or a different domain). Apparently, the first (root forest) DC was configured
incorrectly; very often this concerns DNS service (on a Windows 2000/.NET Server
or a third-party server). In such a situation, DCdiag (especially in conjunction with
Net-Diag.exe) could locate many potential problems from the beginning.

The DCdiag utility can generate a very generous output — most of all, with
enterprise-wide tests, and you should therefore use log files for subsequent analysis
of the results. The diagnostic messages are quite informative and very often plainly
specify a problem, so you need only eliminate it without any further analysis.

The Windows .NET version of DCdiag is sufficiently documented. You can use the
built-in Help (dcdiag /?) as a quick reference on all parameters. (The built-in Help
seems to be more accurate than Support Tools Help.) The Windows 2000 Server
Resource Kit contains a great deal more information on how to use this utility. We
shall discuss some of the most interesting features of DCdiag and examples of their
use.

Note For the Windows 2000 environment, it is recommended that you download the
updated version of DCdiag from
http://www.microsoft.com/downloads/release.asp?ReleaseID=22939.

You can run DCdiag from any network computer and test any DC in the forest. Some
tests can be performed under a normal user account (Replications, NetLogons, and
ObjectsReplicated cannot), but to get the full functionality of DCdiag, you must either be
logged on as an administrator (or even as an enterprise administrator) or provide an
administrator's credentials with the command.

The New Version of DCdiag

In comparison with Windows 2000, the Windows .NET version of DCdiag provides a
few new tests:

CrossRefValidation CheckSDRefDom
VerifyReplicas VerifyReferences
VerifyEnterpriseReferences

These tests are especially informative when used with /a and /e parameters that force
the testing of all DCs in the current site or in the forest, respectively. Using these
tests, you can quickly locate fault elements of the replication infrastructure — invalid
cross-references, improper security descriptors, directory partitions that are not fully
instantiated, etc. — particularly when there are many application directory partitions
deployed in your enterprise.
Standard Full Test

First, let us look at what happens if DCdiag is passed successfully. You will see from
this output how the tests are structured and which tests the DCdiag tool contains.
The Topology, CutoffServers, and OutboundSecureChannels tests are omitted by default, so
you must run them explicitly or use the /c (comprehensive) parameter.

In the Windows 2000 environment, DCdiag runs faster if you specify the DC's DNS
name rather than its NetBIOS name. (If the DC name is omitted, your current logon
server is implied.) The /a or /e parameters specified in a command allow you to run a
selected test on every DC in a site or in the forest.

If you want to retrieve the maximum possible amount of information from DCdiag, use
the /v (verbose) parameter with any test. As well, the /d parameter is equal to /v, and,
in addition, produces plenty of information (pDsInfo) on your forest configuration. With
these parameters, use the more pipe or redirect the output to a file in the current or
another folder with the /f parameter. (The pDsInfo section of tests is never redirected to
a file: use the pipe to save that information.)

Here is a typical command for testing a DC:

C:\>dcdiag /s:netdc3.net.dom [| more]

The command's output will be similar to:

Domain Controller Diagnosis

Performing initial setup:

Done gathering initial info.

Doing initial required tests

Testing server: NET-Site\NETDC3

Starting test: Connectivity
...........................NETDC3 passed test Connectivity
Doing primary tests

Testing server: NET-Site\NETDC3

Starting test: Replications
...........................NETDC3 passed test Replications
Starting test: NCSecDesc
...........................NETDC3 passed test NCSecDesc
Starting test: NetLogons
...........................NETDC3 passed test NetLogons
Starting test: Advertising
...........................NETDC3 passed test Advertising
Starting test: KnowsOfRoleHolders
...........................NETDC3 passed test KnowsOfRoleHolders
Starting test: RidManager
...........................NETDC3 passed test RidManager
Starting test: MachineAccount
...........................NETDC3 passed test MachineAccount
Starting test: Services
...........................NETDC3 passed test Services
Starting test: ObjectsReplicated
 ...........................NETDC3 passed test ObjectsReplicated
Starting test: frssysvol
...........................NETDC3 passed test frssysvol
Starting test: kccevent
...........................NETDC3 passed test kccevent
Starting test: systemlog
...........................NETDC3 passed test systemlog
Starting test: VerifyReferences
...........................NETDC3 passed test VerifyReferences
Running partition tests on : Schema
Starting test: CrossRefValidation
...........................Schema passed test CrossRefValidation
Starting test: CheckSDRefDom
...........................Schema passed test CheckSDRefDom
Running partition tests on : Configuration
Starting test: CrossRefValidation
...........................Configuration passed test CrossRefValidation
Starting test: CheckSDRefDom
...........................Configuration passed test CheckSDRefDom

Running partition tests on : net

Starting test: CrossRefValidation
...........................net passed test CrossRefValidation
Starting test: CheckSDRefDom
...........................net passed test CheckSDRefDom
Running enterprise tests on : net.dom

Starting test: Intersite

...........................net.dom passed test Intersite
Starting test: FsmoCheck
...........................net.dom passed test FsmoCheck

The first two sections — Initial setup and Initial required tests — are always executed,
even if you specify only one test. You may first run the full test to find any problems,
which may exist. Then, it's advisable to run tests selectively in verbose mode to get a
detailed diagnosis.

In practice, it is handy to run DCdiag with the /q parameter. If the DC is working

properly, DCdiag will not display any messages at all, so you do not need to worry
about anything. Otherwise, only the failed tests will be reported.

Error and diagnostic messages (in verbose mode) are very descriptive, so it is un-
necessary to give many examples.

Testing DNS Registration and Accessibility of DCs

The mandatory Connectivity test is executed on every DCdiag test run. This test
verifies the most important functionalities of a domain controller: whether all DNS
resource records are registered on the preferred DNS server, and whether DCs are
pingable and have LDAP/RPC accessibility. For example, using /a or /e parameters,
you can quickly find all DCs that are not responsible. The following output will be
displayed:

C:\>dcdiag /test:connectivity /e
...
Testing server: NET-Site\NETDC2
 Starting test: Connectivity
Server NETDC2 resolved to this IP address 192.168.0.2,
but the address couldn't be reached(pinged), so check the
network.
The error returned was: Win32 Error 11010
This error more often means that the targeted server is
shutdown or disconnected from the network
..........................NETDC2 failed test Connectivity
...

The next output sample illustrates errors with DNS registration of the selected DC:

...
Doing initial required tests

Testing server: NET-Site\NETDC1

Starting test: Connectivity

The host 02c2b1f6-e9b6-4e64-91f6-3a54b087bacc._msdcs.net.dom

could not be resolved to an IP address. Check the DNS server,
DHCP, server name, etc. Although the Guid DNS name (02c2b1f6-
e9b6-4e64-91f6-3a54b087bacc._msdcs.net.dom) couldn't be
resolved, the server name (netdc1.net.dom) resolved to the IP
address (192.168.0.1) and was pingable. Check that the IP
address is registered correctly with the DNS server.
...........................NETDC1 failed test Connectivity

Doing primary tests

Testing server: NET-Site\NETDC1

Skipping all tests, because server NETDC1 is
not responding to directory service requests
...

As you can see from the foregoing messages, none of the other tests will even be
started if there are any errors in the Connectivity section of DCdiag. You should first
eliminate any existing issues before you continue the diagnosis. To locate the
problem shown, use the netdiag /test:DNS command, and check all warnings in the
"DNS test" section of the output data.

Verifying Replication

DCdiag allows an administrator to resolve replication problems quite well. Let us

suppose that a site contains three domain controllers, one of which is refusing to
replicate with its partners. The following command will test all DCs and check
replication issues on each DC:

C:\>dcdiag /test:Replications /a /v

Only failed replication events will be included in the resulting report. The output of this
command is the following:
Domain Controller Diagnosis

Performing initial setup:

* Verifying that the local machine netdc1, is a DC.
* Connecting to directory service on server netdc1.
* Collecting site info.
* Identifying all servers.
* Identifying all NC cross-refs.
* Found 3 DC(s). Testing 3 of them.
Done gathering initial info.

Doing initial required tests

Testing server: NET-Site\NETDC1

Starting test: Connectivity
* Active Directory LDAP Services Check
* Active Directory RPC Services Check
...........................NETDC1 passed test Connectivity

Testing server: NET-Site\NETDC3

...
Testing server: NET-Site\NETDC2
...
Doing primary tests

Testing server: NET-Site\NETDC1

Starting test: Replications
* Replications Check
[Replications Check,NETDC1] A recent replication attempt failed:
From NETDC3 to NETDC1
Naming Context: DC=net,DC=dom
The replication generated an error (8456):
Win32 Error 8456
The failure occurred at 2002-05-11 20:50:59.
The last success occurred at 2002-05-11 19:48:32.
6 failures have occurred since the last success.
Replication has been explicitly disabled through the server options.
[Replications Check,NETDC1] A recent replication attempt failed:
From NETDC3 to NETDC1
Naming Context: CN=Configuration,DC=net,DC=dom
...
[Replications Check,NETDC1] A recent replication attempt failed:
From NETDC3 to NETDC1
Naming Context: CN=Schema,CN=Configuration,DC=net,DC=dom
...
*Replication Latency Check
[Information on all directory partitions stored on that DC is reported here.]
DC=ForestDnsZones,DC=net,DC=dom
Latency information for 1 entries in the vector were
ignored. 0 were retired Invocations. 1 were either:
read-only replicas and are not verifiably latent, or dc's
no longer replicating this nc. 0 had no latency
information (Win2K DC).
DC=DomainDnsZones,DC=net,DC=dom
...
CN=Schema,CN=Configuration,DC=net,DC=dom
...
CN=Configuration,DC=net,DC=dom
...
DC=net,DC=dom
 ...
DC=subdom,DC=net,DC=dom
...
...........................NETDC1 passed test Replications
...
Testing server: NET-Site\NETDC3
Starting test: Replications
* Replications Check
[Replications Check,NETDC3] Outbound replication is disabled.
To correct, run "repadmin /options NETDC3 -DISABLE_OUTBOUND_REPL"
...........................NETDC3 failed test Replications
...
Testing server: NET-Site\NETDC2
Starting test: Replications
* Replications Check
Skipping server NETDC3, because it has outbound replication disabled
Skipping server NETDC3, because it has outbound replication disabled
*Replication Latency Check
...
...........................NETDC2 passed test Replications
...

As you can see from the test output, DCdiag provides comprehensive information
about failed connections for each DC in the site and on each directory partition.

If the local DC has not received replication information from a number of DCs within
the configured latency interval (24 hours by default; see Appendix B), messages
similar to the following ones will be included in the output:

REPLICATION-RECEIVED LATENCY WARNING

NETDC1: Current time is 2002-05-10 19:24:28.
CN=Schema,CN=Configuration,DC=net,DC=dom
Last replication recieved from NETDC3 at 2002-05-09
19:16:55.
CN=Configuration,DC=net,DC=dom
Last replication recieved from NETDC2 at 2002-05-09
19:48:56.
...

To obtain additional information on replication topology, you can also use the repadmin
/showconn command that verifies whether all required connections between DCs were
created.

Testing Application Directory Partitions

Application directory partitions that appeared in Windows .NET can generate specific
replication problems, and the Windows .NET version of DCdiag offers new tests for
troubleshooting similar issues. The following example illustrates the VerifyReplicas
test that checks on whether all application partitions have replicas stored on the DCs
specified as replica servers for these partitions. The problem presented here was
caused by missing permissions for the Enterprise Domain Controllers group on the
DC=ForestDnsZones, DC=net, DC=dom partition, and could be easily detected by the
NCSecDesc test. When the proper permissions are missed, the NETDC2 and
NETDC3 domain controllers could not create the replicas of that partition and,
therefore, generate the appropriate replication connections.
 C:\>dcdiag /test:VerifyReplicas /a

Domain Controller Diagnosis

...
Doing initial required tests
...
Doing primary tests

Testing server: NET-Site\NETDC1

Starting test: VerifyReplicas
...........................NETDC1 passed test VerifyReplicas

Testing server: NET-Site\NETDC3

Starting test: VerifyReplicas
This NC (DC=ForestDnsZones,DC=net,DC=dom) is supposed to be
replicated to this server, but has not been replicated yet. This
could be because the replica set changes haven't replicated here
yet. If this problem persists, check replication of the
Configuration Partition to this server.

...........................NETDC3 failed test VerifyReplicas

Testing server: NET-Site\NETDC2

Starting test: VerifyReplicas
...
...........................NETDC2 failed test VerifyReplicas
...

Enterprise Wide Tests

Enterprise tests check on many elements that are vitally necessary in order for an
enterprise (forest) to work: intersite links, bridgehead servers, FSMO role owners and
their accessibility, etc.

It is not a good idea to run the Intersite test on one DC only, so you must include the /a
(current site) or /e (entire enterprise) parameters.

Here is a snippet of the test output for two sites (NET-Site and Remote-Site) in the forest
net.dom (some lines are in bold for clarity):

C:\>dcdiag /test:Intersite /e /v

...

Running enterprise tests on : net.dom

Starting test: Intersite

Doing intersite inbound replication test on site NET-Site:

Locating & Contacting Intersite Topology Generator (ISTG) ...

The ISTG for site NET-Site is: NETDC3.

Checking for down bridgeheads ...

Bridghead Remote-Site\NETDC2 is up and replicating fine.

 Bridghead NET-Site\NETDC1 is up and replicating fine.

Doing in depth site analysis ...

All expected sites and bridgeheads are replicating into

site NET-Site.

Doing intersite inbound replication test on site Remote-Site:

Locating & Contacting Intersite Topology Generator (ISTG) ...

The ISTG for site Remote-Site is: NETDC2.

Checking for down bridgeheads ...

Bridghead NET-Site\NETDC1 is up and replicating fine.

Bridghead Remote-Site\NETDC2 is up and replicating fine.

Doing in depth site analysis ...

All expected sites and bridgeheads are replicating into

site Remote-Site.

........................... net.dom passed test Intersite

Active Directory Diagnostic Tool (NTDSutil.exe) (Sys)

This utility is automatically installed into every domain controller (in the %System-
Roor%\system32 folder). One could hardly say that this tool is for everyday use, but
every administrator must be familiar with its features since it is used in certain
operations that are very important for Active Directory functioning, such as Active
Directory restore, offline defragmentation, FSMO role manipulating, and so on.
However, NTDSutil has become one of the major tools for deploying and maintaining
application directory partitions introduced in Windows .NET.

Some commands on the NTDSutil's main menu can only be performed when the
system is booted in the Directory Services Restore Mode (press <F8> at system
startup). (If, nevertheless, you wish to enable them, set the environmental variable
SAFEBOOT_OPTION=DSREPAIR, and restart the utility. This is, however, not advisable,
because conflicts with the running processes will not permit you to execute most of
the available operations.) The following commands are prohibited when the Active
Directory services are online:

ƒ Authoritative restore
ƒ Files
ƒ Semantic database analysis

Windows .NET version of NTDSutil has two new commands:

ƒ Configurable Settings
ƒ Set DSRM Password
The IP Deny List command, available in Windows 2000 version, might not be included
in Windows .NET.

Commands used in NTDSutil are quite long, but the utility accepts truncated syntax
(or you can easily copy-and-paste commands from the built-in help messages). For
example, the command

connect to server xxx

could be shortened to
co t s xxx

NTDSutil can be called from command files. An example of the invocation method is
the DumpFSMOs.cmd file described in the Chapter 8, "Common Administrative
Tasks".

Let's discuss the purpose and use of all NTDSutil's commands in the order in which
the corresponding menus appear in the built-in Help.

Note For presentation purposes, the command's prompts in the given dialogs are
shown in bold.

In the Windows 2000 environment, the utility connects to DCs faster if you use
the DNS rather than NetBIOS names of domain controllers.

Authoritative Restore

This menu contains commands that allow an administrator to perform an authoritative

restore of the entire Active Directory database, a selected subtree, or an object. The
commands' syntax is very simple, and it is much more difficult to understand how to
use these simple commands. Since using commands from the Authoritative Restore
menu as well as selecting the proper values for the verinc parameter is closely related
to the entire process of backing up and restoring Active Directory, all of these
commands are described in detail in Chapter 8, "Common Administrative Tasks."

Here, we will only look at the command that lists all cross-reference objects
associated with domain partitions instantiated on the local domain controller. You
cannot restore a partition if the corresponding cross-references is absent or has not
been created. The following example shows two application partitions and three basic
partitions:

ntdsutil: Authoritative restore

authoritative restore: List NC CRs

Opening DIT database... Done.

Listing locally instantiated writeable partitions and associated cross-refs:

1) Partition: DC=DomainDnsZones,DC=net,DC=dom
cross-ref: CN=352cf7f5-327d-4316-9cb7-31c922273752,
CN=Partitions,CN=Configuration,DC=net,DC=dom
2) Partition: DC=ForestDnsZones,DC=net,DC=dom
cross-ref: CN=3d9c5cba-34b5-4692-b43a-fa7a17161785,
 CN=Partitions,CN=Configuration,DC=net,DC=dom
3) Partition: CN=Configuration,DC=net,DC=dom
cross-ref: CN=Enterprise Configuration,
CN=Partitions,CN=Configuration,DC=net,DC=dom
4) Partition: CN=Schema,CN=Configuration,DC=net,DC=dom
cross-ref: CN=Enterprise Schema,
CN=Partitions,CN=Configuration,DC=net,DC=dom
5) Partition: DC=net, DC=dom
cross-ref: CN=NET,CN=Partitions,CN=Configuration,DC=net,DC=dom
Done.
authoritative restore: ...

Configurable Settings

NTDSutil allows you to tune some parameters Active Directory functioning is affected
by. In the current version, this concerns only two settings that control TTL (Time-To-
Live) values for dynamic objects (see details in Chapter 2, "Active Directory
Terminology and Concepts" and Appendix B).

The following dialog illustrates how to view the current values of these parameters
(first, you must be connected to a DC) and increase the value of DynamicObject-
MinTTL:

configurable setting: Show Values

Setting Current (New) Seconds

DynamicObjectDefaultTTL 86400 [=1 day]
DynamicObjectMinTTL 900 [=15 minutes]

configurable setting: Set DynamicObjectMinTTL to 1800

configurable setting: Commit Changes
configurable setting: ...

Domain Management

The Windows .NET version of NTDSutil contains a lot of new commands in the
Domain Management menu, since NTDSutil is the main tool for manipulating application
directory partitions (see Chapter 2, "Active Directory Terminology and Concepts").

Essentially, the process of deploying application partitions is not too complicated: you
can create and remove partitions, and add and remove the replicas of these
partitions. To verify all similar operations, use the DCdiag tool and repadmin /showconn
command.

Important See also the description of the Dnscmd.exe utility in Chapter 4, "Windows
.NET DNS Server," since only this utility can perform some important
operations with application directory partitions.

List Directory Partitions and Application Partition Replicas

First, you may wish to view all directory partitions stored on the selected DC. As you
can see from the following sample output, the partitions list contains two built-in
application partitions (DC=ForestDnsZones, DC=net, DC=dom and DC=DomainDnsZones,
DC=net, DC=dom) created by default on the first DC in the forest if the DNS server is
running on the same DC. These partitions are not specifically marked in the list.

domain management: List

Note: Directory partition names with International/Unicode characters will only display correctly if
appropriate fonts and language support are loaded
Found 6 Naming Context (s)
0 - CN=Configuration, DC=net, DC=dom
1 - DC=net, DC=dom
2 - CN=Schema, CN=Configuration, DC=net, DC=dom
3 - DC=ForestDnsZones, DC=net, DC=dom
4 - DC=DomainDnsZones, DC=net, DC=dom
5 - DC=subdom, DC=net, DC=dom
domain management: ...

The following command lists all replicas for the specified partition (the command is
applicable to application partitions only):

domain management: List NC Replicas DC=ForestDnsZones, DC=net, DC=dom

Creating and Deleting Naming Contexts (Partitions)

The following command creates a new application partition (app-part.net.dom) on the

currently connected DC (NULL is specified instead of the domain controller's DNS
name):

domain management: Create NC DC=App-Part, DC=net, DC=dom NULL

adding object DC=App-Part, DC=net, DC=dom
domain management: List
...

When you create a new partition, the appropriate DNS entries are automatically
registered on the preferred DNS server. The distinguished name (DN) of the new
partition is added to the namingContexts attribute of the RootDSE object on each DC
that stores a replica of that partition. So you can test creation or deleting naming
contexts with Ldp.exe tool.

To delete an application partition, use the following command:

domain management: Delete NC DC=App-Part, DC=net, DC=dom

The operation was successful. The partition has been marked for removal
from the enterprise. It will be removed over time in the background.

Note: Please do not create another partition with the same name until
the servers which hold this partition have had an opportunity to remove
it. This will occur when knowledge of the deletion of this partition has
replicated throughout the forest, and the servers which held the
partition have removed all the objects within that partition. Complete
removal of the partition can be verified by consulting the Directory
event log on each server.
domain management: ...
Adding and Removing Partition Replicas

To provide fault tolerance or increase the performance of an application partition, you

should create a copy of that partition on several domain controllers, i.e., add them as
partition replicas. The following command designates the NETDC2 domain controller
as a replica of the app-part.net.dom application partition:

domain management: Add NC Replica DC=App-Part, DC=net,

DC=dom netdc2.subdom.net.dom
domain management: List NC Replicas DC=App-Part, DC=net, DC=dom
The application directory partition DC=App-Part, DC=net, DC=dom's Replicas
are:
CN=NTDS Settings, CN=NETDC2, CN=Servers,
CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom
CN=NTDS Settings, CN=NETDC1, CN=Servers,
CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom
The *'ed items are currently uninstantiated replicas.
domain management:...

If the replica has been successfully created, the new context is added to the
replication connection with the specified DC. You can verify this with the
repadmin/showconn command or the Active Directory Sites and Services snap-in.
The appropriate KCC and NTDS Replication messages should appear in the
Directory Service log:

Event Type: Information

Event Source: NTDS KCC
Event Category: Knowledge Consistency Checker
Event ID: 1903
...
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: NETDC1
Description:
A replication link for the writable partition DC=App-Part, DC=net,
DC=dom from server CN=NTDS Settings, CN=NETDC2, CN=Servers,
CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom has been added.

To remove a partition replica, use a command similar to the following one:

domain management: Remove NC Replica DC=ForestDnsZones, DC=net,

DC=dom netdc3.net.dom

Verify the operation result with the List command and Event Viewer snap-in (Event
Source: NTDS KCC; Event ID: 1482):

...
The following directory partition is no longer available on the domain
controller at the following network address.
Directory partition:
DC=App-Part, DC=net, DC=dom
Domain controller:
CN=NTDS Settings, CN=NETDC2, CN=Servers, CN=NET-Site, CN=Sites,
CN=Configuration, DC=net, DC=dom
...
Creating Cross-Reference Objects

Creating a new domain or application directory partition (both represented by a cross-

reference object in the Configuration partition of the forest) requires more
administrative power than does promoting a server to domain controller or
instantiating a partition on a domain controller. You may wish to divvy up the tasks of
preparing a cross-reference and completing partition creation among employees with
different administrative rights and not grant them full administrative power. The
NTDSutil command allows you to preliminarily create a cross-reference object (in the
existing forest), which could then be used by subordinate administrators.

The following dialog shows how to create a new domain (intra.subdom.net.dom) in an

existing forest (net.dom):

C:\>ntdsutil
ntdsutil: Domain management
domain management: Connections
server connections: Connect to server netdc1
Binding to netdc1 ...
Connected to netdc1 using credentials of locally logged on user.
server connections: Quit
domain management: Precreate DC=intra, DC=subdom, DC=net, DC=dom
netdc4.intra.subdom.net.dom
adding object CN=intra, cn=Partitions, CN=Configuration, DC=net, DC=dom domain management:
List
Note: Directory partition names with International/Unicode characters will only display correctly if
appropriate fonts and language support are loaded
Found 7 Naming Context(s)
0 - CN=Configuration, DC=net, DC=dom
...
6 - DC=intra, DC=subdom, DC=net, DC=dom
domain management: ...

As you can see from the dialog, a new domain context appears after the command
has been executed. Also, note that the NETDC4 domain controller specified in the
command does not yet exist in the forest and must be promoted in future.

Files: Managing Active Directory Database Files

The commands in the Files menu allow you to perform the following operations:

ƒ Retrieve information on the state of the Active Directory (Jet) database (the
ntds.dit file) as well as the log files
ƒ Move database and/or log files to another location
ƒ Re-define paths for Active Directory files
ƒ Check up the Active Directory integrity
ƒ Perform database recovery

Attention You can move an already installed Active Directory database and/or log
files to another location (folder or disk), but it is not possible to change
the SYSVOL's location without re-installing Active Directory on a domain
controller.
Retrieving Information on Active Directory Files

The following command informs you about the size and location of all Active
Directory database files. It is advisable that you use the command (and thus verify
the presence of the log files) after you have restored Active Directory or done
maintenance operations (offline defragmentation, moving files, etc.).

file maintenance: info

Drive Information:

C:\ FAT (Fixed Drive) free(551.4 Mb) total(995.9 Mb)

...
E:\ NTFS (Fixed Drive) free(1.5 Gb) total(9.7 Gb)
DS Path Information:

Database : D:\WINDOWS\NTDS\ntds.dit - 12.1 Mb

Backup dir : D:\WINDOWS\NTDS\dsadata.bak
Working dir: D:\WINDOWS\NTDS
Log dir : D:\WINDOWS\NTDS - 40.0 Mb total
res2.log - 10.0 Mb
res1.log - 10.0 Mb
edb00001.log - 10.0 Mb
edb.log - 10.0 Mb
file maintenance: ...

Compressing the Database — Offline Defragmentation

Online defragmentation of the Active Directory database performed automatically at

predefined intervals (by default, every 12 hours; see Appendix B) does not reduce
the physical size of the database file (ntds.dit). To compact this file, you need to
perform offline defragmentation (in the Directory Services Restore Mode). Offline
defragmentation may be required when you delete a particularly large number of
objects from a DC. For example, this is the case when a GC server loses this
function and becomes a regular DC. The disk space saved in such a case may
appear to be rather significant.

In general, the procedure of offline defragmentation is as follows:

1. Boot the DC in restore mode.

2. Start the defragmentation process — the new, compact version of the Active
Directory database file will be stored in any alternative (specified) location.
3. If defragmentation is successful, copy the compacted file to its original location
and delete old log files in that location.

This entire procedure is shown below. In this scenario, the database file is packed to
a temporary C:\AD\CompactDB folder, and all log files are stored in the default
location — D:\WINDOWS\NTDS.

file maintenance: Compact to C:\AD\CompactDB

Opening database [Current].
Creating dir: C:\AD
Creating dir: C:\AD\CompactDB
Executing Command: D:\WINDOWS\system32\esentutl.exe
 /d"D:\WINDOWS\NTDS\ntds.dit" /t"C:\AD\CompactDB\ntds.dit"

/p /o

Initiating DEFRAGMENTATION mode...

Database: D:\WINDOWS\NTDS\ntds.dit
Temp. Database: C:\AD\CompactDB\ntds.dit

Defragmentation Status (% complete)

0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................
Note:
It is recommended that you immediately perform a full backup
of this database. If you restore a backup made before the
defragmentation, the database will be rolled back to the state
it was in at the time of that backup.

Operation completed successfully in 6.69 seconds.

Spawned Process Exit code 0x0(0)

If compaction was successful you need to:

copy "C:\AD\CompactDB\ntds.dit" "D:\WINDOWS\NTDS\ntds.dit"
and delete the old log files:
del D:\WINDOWS\NTDS\*.log

file maintenance: ...

Moving the Active Directory Database

You may wish to move Active Directory database files to another location due to disk
space limitations or disk volume reconfiguration. The procedure for moving the
database file requires the following steps:

1. Backup Active Directory.

2. Restart the DC and press <F8> at startup.
3. Select Directory Services Restore Mode and boot the DC.
4. Start NTDSutil from the command prompt and select the Files command. You
may run Info to determine the current locations of the Active Directory
database files.
5. Enter move DB to [drive]:\[new folder]. Run Info to verify the new configuration.
6. Quit NTDSutil and restart the DC in normal mode.

The procedure for moving log files is similar to the one described above.

Active Directory Folder Security

Security of the folder where the Active Directory database files are stored (by default
— %System Root%\NTDS) is very important for proper Active Directory functioning.
The Set default folder security command resets mistakenly changed permissions on that
folder to default values.
Database Integrity

The Files menu also contains two commands — Recover and Integrity — that can be
used to detect corruption of the Active Directory database (with respect to the ESENT
database semantics) and to perform some operations for its recovery. The Windows
2000 version of NTDSutil also contains the Repair command in the Files menu. (All of
these commands may require a lot of time to run; this primarily depends on the actual
size of the database.) The Repair command should not be run without first consulting
with service personnel, since it can result in data losses. The Recover command
should be run first, prior to the Integrity command. This command scans the log files
and ensures that all transactions are committed. The Integrity command can then
check the database file for low-level corruption. The command's output will be similar
to the following:

file maintenance: Integrity

Opening database [Current].
Executing Command: D:\WINDOWS\system32\esentutl.exe
/g"D:\WINDOWS\NTDS\ntds.dit" /o

Initiating INTEGRITY mode...

Database: D:\WINDOWS\NTDS\ntds.dit
Temp. Database: TEMPINTEG1696.EDB
Checking database integrity.

Scanning Status (% complete)

0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................

Integrity check successful.

Operation completed successfully in 4.156 seconds.

Spawned Process Exit code 0x0(0)

If integrity was successful, it is recommended

you run semantic database analysis to ensure
semantic database consistency as well.

file maintenance:...

IP Deny List

The IP Deny List command is available in the Windows 2000 version of NTDSutil, but
may not be in the Windows .NET version. If it is not, you can manually configure the
list of IP addresses using the ADSI Edit snap-in (see Appendix B).

To increase the security of a DC, an administrator can use the IP Deny List command
that is applied only to the Default-Query Policy object (see also the next section).
This list contains IP addresses, from which a domain controller will not accept LDAP
queries. A list entry can represent a single host or a subnet. For example, the
command

Add 192.168.1.1 NODE

prevents a DC from accepting queries from the host with the address 192.168.1.1.
The following command denies access from all hosts in a subnet with the address
192.168.1.0:

Add 192.168.1.0 255.255.255.0

LDAP Policies

Using the following example, let us discuss how NTDSutil allows an administrator to
work with the Default-Query Policy object (see Chapter 1, "Active Directory Concepts
and Terminology"). A dialog is shown that changes the Initial Receive Timeout from the
default value of 120 to 30 (the changed value is put in bold italics).

ntdsutil: Ldap policies

ldap policy: Connections
server connections: Connect to server netdc1.net.dom
Binding to netdc1.net.dom...
Connected to netdc1.net.dom using credentials of locally logged on user.
server connections: Quit
ldap policy: List
Supported Policies:
MaxPoolThreads
MaxDatagramRecv
MaxReceiveBuffer
InitRecvTimeout
MaxConnections
MaxConnIdleTime
MaxPageSize
MaxQueryDuration
MaxTempTableSize
MaxResultSetSize
MaxNotificationPerConn
ldap policy: Set InitRecvTimeout to 30
ldap policy: Show values

Policy Current(New)

MaxPoolThreads 4
MaxDatagramRecv 1024
MaxReceiveBuffer 10485760
InitRecvTimeout 120(30)
MaxConnections 5000
MaxConnIdleTime 900
MaxPageSize 1000
MaxQueryDuration 120
MaxTempTableSize 10000
MaxResultSetSize 262144
MaxNotificationPerConn 5

ldap policy: Commit changes

ldap policy: Quit

The Windows 2000 Server Resource Kit contains the ModifyLDAP.vbs script (which
is included in the Remote Administration Scripts). This script allows an administrator
to display policy settings, create new policies, and modify existing ones, as well as
assign policies to a DC or site. Here is the screen output for the LDAP Administrative
limits of the Default Query Policy, which is installed and used (even if not selected) by
default on all DCs:

C:\modifyldap /P /O: "Default Query Policy"

LDAP Settings for Default Query Policy
InitRecvTimeout=30
MaxReceiveBuffer=10485760
MaxDatagramRecv=1024
MaxPoolThreads=4
MaxResultSetSize=262144
MaxTempTableSize=10000
MaxQueryDuration=120
MaxPageSize=1000
MaxNotificationPerConn=5
MaxConnIdleTime=900
MaxConnections=5000
Note To select an existing LDAP policy, use the Active Directory Sites and
Services snap-in. Point to the NTDS Settings object of the necessary DC and
open the Properties window. Select a policy in the Query Policy list and click
Apply.

Metadata Cleanup: Removing Defunct Domains or Domain Controllers

Normally, the process of demoting a DC involves deleting the computer account and
cleaning up all metadata related to that DC from Active Directory. When the last DC
in a domain is deleted, all cross-references (and other information about that domain)
are also removed. There are, however, situations when a domain controller is
decommissioned incorrectly (or failed and destroyed), and orphaned metadata
remains in the directory. In such a case, you can remove information about the
retired DC and/or domains by using NTDSutil. (You must not delete any information
for existing domains and DCs!) In general, the procedure requires the following steps:

1. Connect to a working DC that holds the information about orphaned metadata.

2. Select an operation target (site, naming context, domain, and server). You
may select one or more of these targets.
3. Remove the necessary metadata.

The following dialog illustrates how you can remove a retired domain controller
(NETDC2) and a child domain (subdom.net.dom) from the forest (net.dom). (In this
example, the shortened command syntax is used; comments are in bold square
brackets. You can also learn how to select an operation target, which is used in many
commands.)

C:\>ntdsutil
ntdsutil: m c
metadata cleanup: c
[First, we must be connected to a DC:]
server connections: co t s netdc1
Binding to netdc1 ...
Connected to netdc1 using credentials of locally logged on user.
server connections: q
metadata cleanup: s o t
[Second, we must select an object to delete:]
select operation target: l si
 Found 1 site (s)
0 - CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom
select operation target: s si 0
Site - CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom
No current domain
No current server
No current Naming Context
select operation target: l d
Found 3 domain (s)
0 - DC=net, DC=dom
1 - DC=subdom, DC=net, DC=dom
2 - DC=dotnet, DC=dom
select operation target: s d l
Site - CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom
Domain - DC=subdom, DC=net, DC=dom
No current server
No current Naming Context
select operation target: l se f d i s
Found 1 server (s)
0 - CN=NETDC2, CN=Servers, CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom
select operation target: s se 0
Site - CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom
Domain - DC=subdom, DC=net, DC=dom
Server - CN=NETDC2, CN=Servers, CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom
DSA object - CN=NTDS Settings, CN=NETDC2, CN=Servers, CN=NET-Site, CN=Sites,
CN=Configuration, DC=net, DC=dom
DNS host name - netdc2.subdom.net.dom
Computer object - CN=NETDC2, OU=Domain
Controllers, DC=subdom, DC=net, DC=dom
No current Naming Context
[Now, we have selected the NETDC2 server from the subdm.net.dom domain
for subsequent operations:]
select operation target: q
metadata cleanup: r s s
[The following Server Remove Confirmation Dialog may appear - you must click Yes.]

[The Server Remove Confirmation Dialog will appear - you must click Yes.]

"CN=NETDC2, CN=Servers, CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom"

removed from server "netdc1"
[Now, we will delete the entire child domain:]
metadata cleanup: r s d
[The Domain Remove Confirmation Dialog will appear - you must click Yes.]
 "DC=subdom, DC=net, DC=dom" removed from server "netdc1"
[Verifying that the operation has been done correctly:]
metadata cleanup: s o t
select operation target: l d
Found 1 domain (s)
0 - DC=net, DC=dom
[Terminating NTDSutil]
select operation target: q
metadata cleanup: q
ntdsutil: q
Disconnecting from netdc1 ...

Now the subdom.net.dom domain has been deleted, and you can verify this by using
the Event Viewer snap-in. There are many information messages (from NTDS KCC
and NTDS Replication sources: ID 1123, 1104, 1270, 1658, 1746, etc.) that appear in
the Directory Service log (the source is NTDS KCC) and accompany removing
domain controllers, naming contexts, and replication connections. There is no need
to explain them specifically.

To verify that the operation was carried off successfully, you may also check the
domain configuration by using the following tools: Active Directory Domains and
Trusts, ADSI Edit (the Configuration container: the Partitions and Sites | Servers
nodes), and Active Directory Sites and Services snap-ins. You may also run
DCdiag.exe (as well as repadmin /showreps) to ensure that there are no replication
problems.

Attention When deleting child domains, you must also manually delete the
corresponding entries from the DNS server.

Roles: Managing FSMO Roles

NTDSutil allows an administrator to manipulate FSMO roles: to view and transfer

them. See Chapter 7, "Common Administrative Tasks," to learn how to dump names
of all FSMO role owners. In this section, we'll discuss how to designate a DC as a
role owner by using NTDSutil. You can choose either of the following options:

ƒ Seize role — this command designates the connected server as the specified
role master. The command must be used only when the DC — the current
master — has severely crashed and cannot be repaired.
ƒ Transfer role — this command "moves" the specified role from the current role
holder to the connected server (DC). You can perform the same operation by
using various administrative snap-ins (see Chapter 7). The NTDSutil.exe also
allows you to carry out the operation in batch mode (see DumpFSMOs.cmd).
Transferring a Role

If for some reason you cannot (or do not want to) use the standard administrative
snap-ins, you may use NTDSutil to transfer a role from its current owner to another
DC. The most common steps are the following:

1. Connect to the potential role owner.

2. Transfer a necessary role from the current owner to the selected server.

Note It is not advisable to seize a FSMO role if you can transfer this role. Seizing is
used only when a FSMO role owner has failed and is unrecoverable.

In the following dialog, the Schema Master role is transferred to the netdc2.
subdom.net.dom server. (This is only an example! It is neither practical nor advisable to
move the schema master role to a child domain.)

C:\>ntdsutil
ntdsutil: Roles
fsmo maintenance: Connections
server connections: connect to server netdc2.subdom.net.dom
Binding to netdc2.subdom.net.dom ...
Connected to netdc2.subdom.net.dom using credentials of locally logged on user
server connections: Quit
fsmo maintenance: Transfer schema master
[The Role Transfer Confirmation Dialog will appear - click Yes.]

Server "netdc2.subdom.net.dom" knows about 5 roles

Schema - CN=NTDS Settings,CN=NETDC2,CN=Servers,CN=NET-
Site,CN=Sites,CN=Configuration,DC=net,DC=dom
Domain - CN=NTDS Settings,CN=NETDC1,CN=Servers,CN=NET-
Site,CN=Sites,CN=Configuration,DC=net,DC=dom
PDC - CN=NTDS Settings,CN=NETDC2,CN=Servers,CN=Remote-
Site,CN=Sites,CN=Configuration,DC=net,DC=dom
RID - CN=NTDS Settings,CN=NETDC2,CN=Servers,CN=Remote-
Site,CN=Sites,CN=Configuration,DC=net,DC=dom
Infrastructure - CN=NTDS Settings,CN=NETDC2,CN=Servers,CN=Remote-
Site,CN=Sites,CN=Configuration,DC=net,DC=dom
fsmo maintenance: ...
Note Notice that the same Configuration partition contains information about servers
that may belong to different domains and sites.

Even if the connected DC already possesses the specified role, the command dialog
remains the same as shown above. You can verify the requested operation with the
Directory Service log. A message similar to the following one should appear (Event
Source: NTDS Replication; Event ID: 1458):

The operations master role represented by the following object has been
transferred to the following domain controller at the request of a user.
...
Seizing a Role

Suppose a DC that holds the Infrastructure FSMO role was destroyed, and you want
this role to be designated to another DC. The following dialog shows how to forcibly
transfer the role to a new candidate (server netdc1.net.dom) (comments are in bold
square brackets):

C:\>ntdsutil
ntdsutil: Roles
fsmo maintenance: Connections
server connections: Connect to server netdc1.net.dom
Binding to netdc1.net.dom ...
Connected to netdc1.dom using credentials of locally logged on user
server connections: Quit
fsmo maintenance: Seize infrastructure master
The Role Seizure Confirmation Dialog will appear — click Yes.]

[First, the server tries to carry out the standard role transfer
operation and fails. The same error message will appear every time you
want to perform a role transfer operation while the current master is
not operational.]
Attempting safe transfer of infrastructure FSMO before seizure.
ldap_modify_sW error 0x34 (52 (Unavailable).
Ldap extended error message is 000020AF: SvcErr: DSID-03210260, problem
5002 (UNAVAILABLE), data 1753
Win32 error returned is 0x20af(The requested FSMO operation failed. The
current FSMO holder could not be contacted.)
)
Depending on the error code this may indicate a connection,
ldap, or role transfer error.
Transfer of infrastructure FSMO failed, proceeding with seizure ...
Server "netdc1.net.dom" knows about 5 roles
...
Infrastructure - CN=NTDS Settings,CN=NETDC1,CN=Servers,
CN=Site,CN=Sites,CN=Configuration,DC=net,DC=dom
fsmo maintenance: ...

When a FSMO role is seized, the following message will appear in the Directory
Service log (Event Source: NTDS Replication; Event ID: 1837):

...
An attempt to transfer the operations master role represented by the following object failed.
...

Security Account Management

Since duplicated SIDs appear, though rarely (due to problems with the RID Master
role owners), you may wish to verify a domain for conflicting SIDs. The commands in
the Security Account Management menu will help you to solve this problem.
Semantic Database Analysis

The commands in this menu test the directory database with respect to Active
Directory (not ESENT database!) semantics. The report generated (a file named
dsdit.dmp.nnn) displays the number of active objects, including phantom and deleted
records. The log file is placed in the current folder.

Notwithstanding the fact that Microsoft does not recommend that end users run
semantic analysis commands themselves, it may be useful to check the database's
integrity in some situations, and fix possible errors. (Be careful with the Go Fixup
command — your data face a risk here!) For example, the following two consecutive
commands have detected and fixed an error with deleted reference objects:

ntdsutil: Semantic database analysis

semantic checker: Go
Fixup mode is turned off
Opening database [Current] ..... Done.

Getting record count...3112 records

Getting security descriptor count...105 security descriptors

Writing summary into log file dsdit.dmp.0

SDs scanned: 105
Records scanned: 3112
Processing records..
Error: Missing subrefs detected. [Errors are detected!]
Done.

semantic checker: Verbose on

Verbose mode enabled.
semantic checker: Go Fixup
Fixup mode is turned on

Opening DIT database...Done.

Done.

Opening database [Current].....Done.

Getting record count...3112 records
Getting security descriptor count...105 security descriptors

Writing summary into log file dsdit.dmp.1

SDs scanned: 105
Records scanned: 3112
Processing records..
Error: Missing subrefs detected.

Error: Inconsistent refcounts detected.

Done.

semantic checker: Go
Fixup mode is turned off
...
Processing records..Done. [No errors now.]

semantic checker: ...

Chapter 11: Verifying Network and
Distributed Services
Overview

All tools described in this chapter consider Active Directory to be a distributed data
base that along with serving clients must support its own integrity and consistency.
This global system task has different aspects, or problem areas, the most important
of which are the following:

ƒ Connectivity (including RPC connectivity) between domain controllers, and

between a DC and a client
ƒ Proper name resolving
ƒ Mutual authentication (existence of secure channels, or trusts, between
domains, domain controllers, and between a client and a DC)
ƒ Synchronizing Active Directory replicas (all directory partitions including Global
Catalog) stored on different domain controllers

As you can conclude from the list of problem areas, there are many sources of
possible faults, which can prevent Active Directory services from working and
responding to client queries properly. The tools described below help administrators
to test Active Directory's network infrastructure and monitor its state on different
domain controllers.

NLTest (NLtest.exe) (ST)

The NLTest tool helps administrators to manage both Windows 2000 native and
mixed mode (with Windows NT 4.0 BDCs) domains as well as Windows .NET
(version 2002) mode domains. The tool has a number of options including the
following:

ƒ Verifying and resetting secure channels (trusts)

ƒ Getting information on network topology (a list of DCs, sites, domain trusts,
etc.)
ƒ Forcing synchronization with BDCs
ƒ Forcing shutdown on a computer, and other options

NLTest is a very useful tool for troubleshooting authentication problems, since it

allows you to test the trust relationships between pairs of specific computers (e.g.,
between a DC from one domain and a DC located in another domain, or a DC and a
domain client) for which these trusts were established.

Note With most commands of the Windows 2000 version of the NLTest, it is
preferable to specify DNS rather than NetBIOS names of computers.

Some options of NLTest are similar to the options realized in the NetDom tool.
(See Chapter 12, "Manipulating Active Directory Objects.") You may choose the
tool that is the most appropriate for your specific tasks.
Verifying Secure Channels

First of all, you should not confuse transitive Kerberos trust relationships (established
in Windows 2000 and Windows .NET domains) with non-transitive secure channels
(trust links). Although you can, for example, log on to a domain that belongs to one
forest tree on a computer that has a machine account in another forest tree, this does
not mean that domain controllers from the corresponding domains have direct trust
relationships. (You can, however, manually establish such a relationship named a
shortcut trust. See Chapter 5, "Deploying Active Directory.") That is why you can only
verify secure channels directly between a child and its parent domain, or between
tree root domains.

Normally, you should get the following result on every domain computer:

C:\>nltest /query
Flags: 0
Connection Status = 0 0x0 NERR_Success
The command completed successfully

This output means that the computer has been authenticated by a domain controller,
and a secure channel exists between the client computer and the domain controller.
If a user has been logged on locally, or for some reason a network logon has not
been performed (e.g., the DC has not been found, and so on), you will see the
following message:

Connection Status = 1311 0x51f ERROR_NO_LOGON_SERVERS

The following message indicates that the Netlogon service failed to start or is not
running on the computer (since it is stopped or disabled):

I_NetLogonControl failed: Status = 1717 0x6b5 RPC_S_UNKNOWN_IF

In that case, you should open the Services snap-in and check the status of the
service.

If the domain computer account has been reset, NLTest will respond with the
message:

Connection Status = 5 0x5 ERROR_ACCESS_DENIED

If an administrator has disabled the domain computer account, NLTest reports:

Connection Status = 1787 0x6fb ERROR_NO_TRUST_SAM_ACCOUNT

If the account is re-enabled, restart the Netlogon service on the computer or run the
nltest /sc_reset command (see below).

To verify a secure channel or find the logon server, use the nltest /sc_query command,
for example:

C:\>nltest /sc_query:net.dom
Flags: 30 HAS_IP HAS_TIMESERV
 Trusted DC Name \\netdc1.net.dom
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

If the command responds

Connection Status = 1311 0x51f ERROR_NO_LOGON_SERVERS

you may try to log off and log on to the system, or to reset (re-establish) a secure
channel by using the following command:

C:\>nltest /sc_reset:net.dom

If there are multiple DCs in the domain, the client computer will establish a secure
channel with the DC that responds first.

Note For verifying and resetting secure channels, it is also possible to use the netdom
/VERIFY and netdom /RESET commands.

Now let us consider a specific scenario. Suppose you have two domains in the forest
— a child and a parent — and want to test whether the domain controller
netdc1.net.dom from the parent domain will be authenticated by the child domain
subdom.net.dom, i.e., whether the trusts between domains is in the proper state (the
child must trust the parent and vice versa). You use the following command, and for
some reason it fails:

C:\>nltest /sc_query:subdom.net.dom /server:netdc1.net.dom

Flags: 0
Trusted DC Name
Trusted DC Connection Status Status = 1311 0x51f ERROR_NO_LOGON_SERVERS
The command completed successfully

You could check this trust in another way. Run the Active Directory Domain and
Trusts snap-in, open the Properties window for the domain net.dom, and click the
Trusts tab. Select the child domain subdom.net.dom in the Domains that trust this
domain (incoming trusts) list and click Properties, and then Validate[1]. (For an
alternate way to start verification, you can: run the Active Directory Users and
Computers snap-in on a DC located in the child domain, point to the System
container, and open the Properties window for the object net.dom of the Trusted
Domain type. Then click Validate.) The system will display a window shown in Fig.
11.1. (In Windows 2000, the window, though similar, has a different design; however,
the sequence of operations will be same.)
Figure 11.1: This window informs you that the secure channel between two DCs in
related domains is broken, but you can reset it

If you select Yes, reset the trust passwords, provide the administrator's credentials,
and click OK. The system will try to reset the secure channel that failed.

The following command will help you to repair the secure channel from the command
prompt:

C:\>nltest /sc_reset:subdom.net.dom /server:netdc1.net.dom

Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \\netdc2.subdom.net.dom
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

To troubleshoot authentication issues, you can test necessary domain controllers and
clients in a similar manner and locate the source of the problems.

Viewing Trusted Domains

Using NLTest, you can display all trust relationships that have been established
between the current domain and other domains in the same or another forest.
Verbose mode allows you to view domain SIDs and GUIDs. Look at a sample output:

C:\>nltest /trusted_domains /v
List of domain trusts:
0: SUBDOM subdom.net.dom (NT 5) (Forest: 2) (Direct Outbound)
(Direct Inbound) (Attr: 0x20)
Dom Guid: 5bcbeeb3-e619-40a6-86b9-4e3d3d9647b2
Dom Sid: S-1-5-21-1193178465-209799049-3125462871
1: W2K w2k.dom (NT 5) (Direct Inbound)
Dom Sid: S-1-5-21-2025429265-113007714-1060284298
2: NET net.dom (NT 5) (Forest Tree Root) (Primary Domain) (Native)
Dom Guid: 941fecfd-d067-472b-9253-a3ce94f43b3e
Dom Sid: S-1-5-21-2033051489-2658513307-2223184096
 The command completed successfully

How should you analyze the displayed information? From these output lines, you can
conclude the following:

ƒ A Windows 2000-based domain w2k.dom has an explicit, one-way incoming

trust with the current domain (i.e., users from the current domain can access
resource in the domain w2k.dom).
ƒ A Windows .NET-based domain subdom.net.dom is in mixed mode, and belongs
to the same forest (Forest: 2) as the current domain.
ƒ The current (Primary) domain net.dom is in Windows .NET (Windows 2002)
mode, and is the forest root domain.

Note This command does not distinguish Windows 2000 domains from Windows
.NET domains and marks them both as NT 5. Also, the command cannot
discern Windows 2000 native mode from Windows .NET (Windows 2002) mode
(functional level).

Viewing Information on Network Topology

Information about the site (in a multiple site network) a client computer is connected
to is not configured on that computer in any way. (The site is selected on the basis of
client and subnet IP address data.) The following command will help you to find the
site to which the local or remote computer has been connected after it has been
booted and logged on to the domain:

C:\>nltest /dsGetSite
NET-Site
The command completed successfully

(Add /server:<computerName> for a remote computer.)

Sometimes, a domain controller can serve more than one site. (If a new site has
been created but you did not move a DC to that site, some DC from an existing site
will be selected to serve the new site. To increase network fault-tolerance, you can
also intentionally configure a DC to serve a site when the domain controllers of that
site are unavailable.) The following command lists all sites, which the DC can serve:

C:\>nltest /dsGetSiteCov /server:netdc1.net.dom

NET-Site
Remote-Site
The command completed successfully

(The /server parameter is not required if the command is performed on a domain

controller.)

Quite often, it is necessary to see the list of controllers located in a domain. A

command similar to the following allows you to view all DCs in an AD-based domain:

C:\>nltest /DClist:net.dom
Get list of DCs in domain 'net.dom' from'\\netdc1.net.dom'.
netdc1.net.dom [PDC] [DS] Site: NET-Site
 netdc4.net.dom [DS] Site: NET-Site
nt4bdc5
The command completed successfully

Servers present in this list may be offline! (Notice that the PDC is marked. To find the
PDC, you can also use the nltest /DCname:<NetBIOSDomainName> command.) Notice
also that a Windows 4.0-based BDC nt4bdc5 has no directory service and is not
connected to the site topology.

To search a domain for a DC performing a specific role (PDC, Global Catalog,

writable replica, etc.), use a command similar to the following (search for the PDC
Emulator):

C:\>nltest /dsGetDC:subdom.net.dom /PDC

DC: \\netdc2.subdom.net.dom
Address: \\192.168.0.2
Dom Guid: 5bcbeeb3-e619-40a6-86b9-4e3d3d9647b2
Dom Name: subdom.net.dom
Forest Name: net.dom
DC Site Name: Remote-Site
Flags: PDC DS LDAP KDC WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST
CLOSE_SITE
The command completed successfully

You can add the/FORCE parameter, and the command will try to find another
(different) DC with a specified property (if this is possible).

The Windows .NET version of NLTest offers a new option that performs the same
actions as the /dsGetDC parameter provides (this option uses another system call —
DsGetDcOpen):

C:\>nltest /dnsGetDc:subdom.net.dom /PDC

List of DCs in pseudo-random order taking into account SRV priorities and weights:
Non-Site specific:
netdc2.subdom.net.dom 192.168.0.2:389
The command completed successfully

Note that the command displays the TCP/IP port number (389) used for access to the
service specified.

Note To find all GC servers in the forest, use ReplMon or query the DNS server for
records in the gc._msdcs.<forestDNSname>subdomain, e.g.:
C:\>nslookup gc._msdcs.net.dom
Server: netdc1.net.dom
Address: 192.168.0.1

Name: gc._msdcs.net.dom
Addresses: 192.168.0.1, 192.168.0.2

Note that all GC servers register their IP addresses in the same DNS subdomain
regardless of which domain they belong to, and you should always search for a GC
server by specifying the DNS name of the forest root domain.

Note For discovering domain controllers you can also use the netdiag /test:DcList and
 netdiag /test:DsGetDc /v commands.

Miscellaneous Options

Forcing Shutdown on a Remote Computer

You can use NLTest as an analog to the Shutdown.exe command (from the
Resource Kit). The following command issues a warning message to the computer
netdc4.net.dom and shuts it down in 60 seconds:

C:\>nltest /shutdown:"Administrative request for shutdown" 60

/server:netdc4.net.dom
Note In contrast to Shutdown.exe, NLTest cannot reboot the computer after
shutdown.

Directory Time Conversion

Some attributes, e.g., pwdLastSet, lastLogon, or badPasswordTime, are stored in

Active Directory as Large Integers (INTEGER8 format). NLTest can convert these
values to a human-readable format. The conversion procedure is rather
cumbersome, so you may prefer to use the repadmin /showtime or w32tm /ntte commands
(see later in this chapter). Let us, for example, consider converting a time value
126679218485309520 obtained with the ADSI Edit snap-in. Copy and paste the
value in the Calculator, and convert it to a hexadecimal format. The result will be
1C20E13FA3DB050. Enter nltest /time: at the command prompt and paste in the
hexadecimal value. Then you must highlight the eight rightmost digits and place them
before the other digits. You should get the following result:

C:\>nltest /time:FA3DB050 1C20E13

fa3db050 01c20e13 = 6 /7 /2002 15:10:48
The command completed successfully

Notice that the command converts the entered value into local time rather than UTC.
[1]
In Windows 2000, the buttons have other names; however, the procedure, in
general, is the same.

Network Connectivity Tester (NetDiag.exe) (ST)

NetDiag is a powerful tool that can be used for diagnosing practically any network
problem — from physical connectivity to name resolving and authentication. To see a
complete list of NetDiag's options (tests), enter netdiag /? at the command prompt. You
can run all tests, a selected test, or all tests except those specified. The test
diagnosis messages are quite explanatory (especially in verbose and debug modes).
You should pay particular attention to the lines with [FATAL] and [WARNING] tags. All
fatal problems must be fixed, or the system will not be able to work properly. You
need to analyze the warnings and find (and maybe repair) their causes. The
warnings, however, can sometimes be safely ignored.

Two options of NetDiag have already been discussed in Chapter 5, "Installing Active
Directory." These tests (DcList and DsGetDc) can be useful for running before
promoting a server to a DC or joining a client computer (workstation or server) to a
domain. In this chapter, we will consider a successful test run (the result output that
you need to get for every domain computer to work properly) and fixing DNS issues.

Caution The original Windows 2000 version of NetDiag does not run on Windows
XP/.NET systems. The Windows .NET version of NetDiag will not run on
Windows 2000-based computers.
Note For the Windows 2000 environment, it is recommended that you download the
updated version (from July 5, 2001) of NetDiag from
http://www.microsoft.com/downloads/release.asp?ReleaseID=31169.

Running Tests

Let us look at a sample test output that has been obtained by a domain administrator
on a domain controller (netdc1.net.dom). (If a domain user runs NetDiag on his or her
computer, the results will be slightly different since a normal user does not have all
administrative rights.) Notice that the computer has no WINS settings. You may wish
to compare this output with results obtained on domain client computers and analyze
the differences. (Comments are given in bold brackets.)

C:\>netdiag
....................................
Computer Name: NETDC1
DNS Host Name: netdc1.net.dom
System info : Windows 2000 Server (Build 3621)
Processor : x86 Family 6 Model 8 Stepping 3, GenuineIntel
List of installed hotfixes :
Q147222
Netcard queries test.......: Passed

Per interface results: [All installed network adapters

will be listed below.]

Adapter : Local Area Connection

Netcard queries test...: Passed

Host Name.........: netdc1

IP Address........: 192.168.1.2 [Multiple IP
addresses and other settings can be assigned to the same
adapter. All of them will be displayed here.]
Subnet Mask........: 255.255.255.0
Default Gateway......: 192.168.1.1
Dns Servers........: 192.168.1.2

AutoConfiguration results......: Passed

Default gateway test...: Passed [This test can fail if

there is no connectivity with other subnets and if the default
gateway has not been configured.]

NetBT name test......: Passed

[WARNING] At least one of the <00> 'WorkStation Service', <03>
'Messenger Service', <20> 'WINS' names is missing.

WINS service test.....: Skipped

 There are no WINS servers configured for this interface.
Global results:

Domain membership test......: Passed

NetBT transports test.......: Passed

List of NetBt transports currently configured:
NetBT_Tcpip_{6D657D29-CED0-4322-954B-6B0167289E52}
1 NetBt transport currently configured. [This test will be
skipped if NetBIOS over TCP/IP is disabled.]

Autonet address test.......: Passed

IP loopback ping test.......: Passed

Default gateway test.......: Passed

NetBT name test..........: Passed [This test will be

skipped if NetBIOS over TCP/IP is disabled.]
[WARNING] You don't have a single interface with the <00>
'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names
defined.

Winsock test...........: Passed

DNS test.............: Passed [On client computers,
this test only reports 'Passed' or 'Failed'.]
PASS --- All the DNS entries for DC are registered on DNS server
'192.168.1.2' and other DCs also have some of the names registered.
[All warnings in this section must be carefully analyzed, since in fact,
they can represent fatal errors. See also the note below.]

Redir and Browser test......: Passed

List of NetBt transports currently bound to the Redir
NetBT_Tcpip_{6D657D29-CED0-4322-954B-6B0167289E52)
The redir is bound to 1 NetBt transport.

List of NetBt transports currently bound to the browser

NetBT_Tcpip_{6D657D29-CED0-4322-954B-6B0167289E52}
The browser is bound to 1 NetBt transport. [This test will be
skipped if NetBIOS over TCP/IP is disabled.]

DC discovery test.........: Passed

DC list test...........: Passed

Trust relationship test......: Skipped [This test is skipped on

the PDC Emulator. Otherwise, if it is 'Passed', it must report the
following:
Secure channel for domain 'NET' is to '\\netdc1.net.dom'.]

Kerberos test...........: Passed [This test will be skipped

if the user has been logged on to the computer locally.]

LDAP test.............: Passed

[You can locate any problems with LDAP by using
the netdiag /test:LDAP /v command.]

Bindings test...........: Passed

WAN configuration test......: Skipped

 No active remote access connections.

Modem diagnostics test......: Passed

IP Security test.........: Passed
Service status is: Started
Service startup is: Automatic
IPSec service is available, but no policy is assigned or active
Note: run "ipseccmd /?" for more detailed information

The command completed successfully

Attention On domain client computers, if the Register this connection's
addresses in DNS box is not checked on the DNS tab in the Advanced
TCP/IP Settings window, the DNS test can pass, even if there is no
corresponding host record for a client on the DNS server. You can test
the DNS settings separately with the netdiag /test:DNS /v command.

Refreshing DNS Resource Records Registration (/fix)

If NetDiag detects that registration of some SRV records has failed for a domain
controller, you can try to fix the problem automatically. Executing the netdiag /fix
command yields the same result as restart of the Netlogon service would. The
command looks up all DNS records in the
%SystemRoot%\system32\config\netlogon.dns file and updates the corresponding
records on the DNS server. When the command runs, strings similar to the following
will appear in the 'DNS test' section:

[FIX] re-register DC DNS entry '_ldap.tcp.36622959-3372-43e6-bbba-

8d77caa1fc46.domains._msdcs.net.dom.' on DNS server '192.168.1.2'
succeed.

The following message completes the fixing process:

FIX PASS - netdiag re-registered missing DNS entries for this DC

successfully on DNS server '192.168.1.2'.

You can analyze the command output to see which records were incorrect or absent.
After NetDiag has tried to fix the DNS issues, run it once more to be sure that all the
problems have been solved.

Attention Remember that only the ipconfig /registerdns command re-registers the
computer's A (host) record on the DNS server in both forward and reverse
zones. (On Windows XP /.NET- based computers, you can refresh DNS
registration as well as clear the DNS requestor's cache, if you open the
Local Area Connection Status window, and click Repair on the
Support tab.) Run it before NetDiag, since the netdiag /fix command only
affects SRV records.
Attention Do not forget to clear the cache on the DNS server specified as primary
after executing the netdiag /fix or ipconfig /registerdns commands! (If you don't,
you must at least manually delete the records re-registered by these
commands from the cache.) Even though the commands may have
already updated the information in dynamic zones on the authoritative
DNS server, the cache may still contain the old data for some records. As
a result, it might seem that the problems still exist, since while testing, the
 commands use the cached responses from the primary DNS server. You
may also need to clear the requester's (local) cache by using the ipconfig
/flushdns command.

RPC Ping: RPC Connectivity Verification Tool (RK)

The RPC Ping tool verifies remote procedure call (RPC) connectivity on a network.
The tool consists of the following components:

ƒ A server, which echoes to clients and produces statistics

ƒ A client, which connects, binds, and sends requests to the specific destination
RPC server

The filenames of these components and the supported systems are listed in the table
below.

Utility filename Platforms supported

Server component
Rpings.exe Windows .NET, Windows 2000, and Windows NT

Client component
Rpingc.exe (32-bit Windows .NET, Windows XP, Windows 2000, Windows
version) NT, Windows 9x /ME
Rpingc 16.exe (16-bit Windows 3.1x
version)

Server Component (RPings.exe)

The server component performs only two RPC functions: Echo and Stats. You can
run it with all available protocols or select only one protocol (-p parameter). If, for
instance, only the TCP/IP protocol is installed on the server computer, R Pings.exe
displays the following messages while starting (the names of endpoints are shown in
bold; these names will be displayed by clients later — see Fig. 11.2):
Figure 11.2: This window contains the result of a few successful pings
C:\>rpings
+endpoint \pipe\rping on protocol sequence ncacn_np is set for use.
-protocol Sequence ncacn_nb_nb not supported on this host
+endpoint rping on protocol sequence ncalrpc is set for use.
+endpoint 2256 on protocol sequence ncacn_ip_tcp is set for use.
-protocol Sequence ncacn_nb_tcp not supported on this host
-protocol Sequence ncacn_spx not supported on this host
+endpoint 2256 on protocol sequence ncadg_ip_udp is set for use.
-protocol Sequence ncadg_ipx not supported on this host
-protocol Sequence ncacn_vns_spp not supported on this host

Enter '@q' to exit rpings.

Now the server is ready to respond to RPC requests (until you stop it), and can serve
as many clients as you want.

Client Component (RPingc.exe)

The client component displays all information about the established RPC connection.
It has two modes of operation:

ƒ Ping Only (default) — can be one step or continuous (until you click Stop).
ƒ Endpoint Search — a one-time operation that allows you to find all available
(responding) endpoints on the RPC server.

Note Notice that RPingc.exe does not appear on the task pad.

An example of the RPingc's window is shown in Fig. 11.2. (I would recommend that
you specify, in turn, both the DNS and NetBIOS names of a RPC server in the
Exchange Server field. This is because the results may vary depending on the type
of specified name and type of the selected operation.)

A sample result of the Endpoint Search operation is shown below. (The settings
Protocol Sequence = ANY and Endpoint = Rping were selected.)
 Successful RPC binding using these parameters:
network address = netdc4.net.dom
endpoint = \pipe\rping
UUID =

protocol sequence = ncacn_np

...searching for uuids and endpoints...
FOUND: uuid for _Rping_ on netdc4.net.dom's protocol sequence: ncacn_np
FOUND: endpoint for _Rping_ on netdc4.net.dom's protocol sequence:
ncacn_np
...
Endpoint Search done.

The displayed "FOUND:" strings depend on the types and number of endpoints
created on the target computer by RPings.exe.

If a RPC Ping client cannot find the specified server or bind to it using the selected
protocol sequence, the following string will appear after all diagnostic messages:

Endpoint Search failed to find anything.

Some problems will cause the appearance of pop-up error windows, which may
contain the return code and the "Unknown exception" message.

To verify authenticated RPCs, check the Run with Security box. Normally, this
should not affect the results of any operations.

NTFRSutl.exe (RK)

This command-line tool is practically undocumented. You can enter its name at the
command prompt and get a list of parameters. This is all the information you have at
your disposal. NTFRSutl produces a lot of rather cryptic data. Nevertheless, this tool
may be very useful for monitoring, troubleshooting, and — to some extent —
managing the File Replication Service (FRS) that replicates the System Volume
(SYSVOL) information and Distributed File System (DFS) data. The tool can be run
on a local as well as a remote DC.

Note NTFRSutl has been included in the Windows 2000 Service Resource Kit. Some
Beta versions of Windows .NET server family have also comprised this tool.

Let us consider some of the NTFRSutl's parameters and their usage.

ƒ ntfrsutl ds and ntfrsutl sets — these commands display the FRS configuration
(replication partners, file filters, schedules, etc.). This information can be
partially viewed in the Active Directory Users and Computers snap-in (see
the File Replication Service node in the System container, and the objects of
FRS Sub-scriptions type, which every domain controller has).
ƒ ntfrsutl stage — this command displays the disk space currently being used by
replicated objects. Normally, when the configuration is stable, this space is 0
KB. Allocated space means some data have not yet been replicated. The
following two commands allow you to see which specific data are to be
replicated.
 ƒ ntfrsutl outlog and ntfrsutl inlog — these commands usually display no data. If there
are objects to be replicated, the logs contain information that can be useful to
an administrator, such as an object file name, and date and time of changes.
ƒ ntfrsutl poll /now — this command can override the current schedule and trigger
replication of staging data between the current or any specified DC and its
partners. Then, you can check logs or staging areas to make sure that all data
have been replicated.

Directory Services Utility (DsaStat.exe) (ST)

This tool is the same as it is in Windows 2000 systems; it allows an administrator to

compare full directory replicas stored on different domain controllers, or compare a
domain partition with the partial replica stored in Global Catalog. The comparison can
be purely statistical or on a per-attribute content basis.

The administrator can test either an entire directory partition or a subtree only. By
default, all objects are compared, but it is possible to use a LDAP filter and choose
only necessary types of objects. Moreover, you can test either all or only selected
attributes, or the attributes replicated to Global Catalog. Thus, DsaStat can serve as
an instrument for verifying replication between domain controllers and actual
information stored on a DC.

Tip In the Windows 2000 environment, use the servers' DNS rather than NetBIOS
names, and the tool will run faster.
Tip The tool may require quite a lot of time to run, and it is difficult to interrupt it.
Besides, it produces significant network traffic. Therefore, if you plan to use it, do
so carefully.

General Statistical Comparison

Let us first see how DsaStat compares directory replicas and produces statistical
data. In this mode, the tool only counts the directory objects and displays totals. In
the following example, the Configuration partition is verified on DCs from different
domains. (It might be necessary to specify a domain administrator's credentials.) If
the −b parameter has been omitted, all applicable partitions are compared.

C:\>dsastat -s:netdc1.net.dom;netdc2.subdom.net.dom
-b: CN=Configuration, DC=net, DC=dom
Stat-Only mode.
Unsorted mode.
Opening connections...
netdc1.net.dom...success.
Connecting to netdc1.net.dom...
reading...
**> ntMixedDomain = 0 [0 --- native mode]
reading...
**> Options = 1 [1 --- Global Catalog server]
Setting server as [netdc1.net.dom] as server to read Config Info...
netdc2.subdom.net.dom...success.
Connecting to netdc2.subdom.net.dom...
reading...
**> ntMixedDomain = 1 [1 --- mixed mode]
reading...
 **> Options = 0 [0 --- "normal" server]
[If options have not been defined, you will see the following line:
LocalException <0>: Cannot get Options <2>.]
Generation Domain List on server netdc1.net.dom...
> Searching server for GC attribute partial set on property attributeId.
> Searching server for GC attribute partial set on property
ldapDisplayName.
Retrieving statistics...
[The command can be cancelled only from this point and afterwards:]
Paged result search...
Paged result search...
50 entries processed (7 msg queued, 0 obj stored, 0 obj deleted)...
...
2650 entries processed (7 msg queued, 0 obj stored, 0 obj deleted)...
...(Terminated query to netdc1.net.dom. <No result present in message>)
...(Terminated query to netdc2.subdom.net.dom. <No result present in
message>)
2700 entries processed (6 msg queued, 0 obj stored, 0 obj deleted)...
...
2950 entries processed (6 msg queued, 0 obj stored, 0 obj deleted)...

-=>>|*** DSA Diagnostics ***|<<=-

Objects per server:

Obj /Svr netdc1.net.dom netdc2.subdom.net.dom Total

configuration 1 1 2
container 61 61 122
controlAccessRight 58 58 116
crossRef 6 6 12
crossRefContainer 1 1 2
dSUISettings 24 24 48
displaySpecifier 1296 1296 2592
foreignSecurityPrincipal 16 16 32
interSiteTransport 2 2 4
interSiteTransportContainer 1 1 2
licensingSiteSettings 1 1 2
lostAndFound 1 1 2
mSMQEnterpriseSettings 1 1 2
msPKI-Enterprise-Oid 1 1 2
nTDSConnection 4 4 8
nTDSDSA 2 2 4
nTDSService 1 1 2
nTDSSiteSettings 1 1 2
physicalLocation 1 1 2
queryPolicy 1 1 2
rRASAdministrationDictionary 1 1 2
server 2 2 4
serversContainer 1 1 2
site 1 1 2
siteLink 1 1 2
sitesContainer 1 1 2
subnetContainer 1 1 2
---
1489 1489 2978
..............
Bytes per object:

configuration 828
container 18992
 controlAccessRight 23564
crossRef 1952
crossRefContainer 322
dSUISettings 8400
displaySpecifier 469344
foreignSecurityPrincipal 6056
interSiteTransport 596
interSiteTransportContainer 408
licensingSiteSettings 436
lostAndFound 334
mSMQEnterpriseSettings 350
msPKI-Enterprise-Oid 304
nTDSConnection 1628
nTDSDSA 660
nTDSService 324
nTDSSiteSettings 396
physicalLocation 420
queryPolicy 336
rRASAdministrationDictionary 398
server 594
serverContainer 304
site 258
siteLink 312
sitesContainer 288
subnetContainer 300
..............
Bytes per server:

netdc1.net.dom 269052
netdc2.subdom.net.dom 269052
..............
Checking for missing replies...
No missing replies! INFO: Server sizes are equal.
*** Identical Directory Information Trees ***
PASS -=>>PASS <<=-
closing connections...
netdc1.net.dom; netdc2.subdom.net.dom;

As you can see, the number of objects of each type is displayed, along with the total
size of objects of a specific type.

Analyzing Differences between Partitions

Basically, there are three types of inconsistencies between directory replicas which
DsaStat can detect. Let us consider these types in the examples given below. In
each case, we will compare the results of statistical and full-content comparisons of
an OU object's replicas. For compactness, only the most interesting lines from the
DsaStat's screen output will be shown.

Different Attribute Values of the Same Object

If the values of one or more attributes of the same object are different on specified
domain controllers, statistical comparison (similar to the one shown above) only
counts total sizes and produces the following result:

Checking for missing replies...

 No missing replies!INFO: Server sizes are not equal (min= ...,
max=...).
*** Identical Directory Information Trees ***
PASS -=>> PASS <<=

You can only conclude from such an output that the replicas differ, and nothing more.

The following command performs the full-content comparison as well as detects both
a changed, albeit non-replicated directory object (a GPO) and an attribute name
(versionNumber) (notice that the −t:FALSE parameter is used):

C:\>dsastat -s:netdc1.net.dom;netdc4.net.dom -b:DC=net,DC=dom -t: FALSE

Unsorted mode.
...
FAIL Value [0] of Attr[versionNumber] did not compare on dn
[<GUID=7a8d66e928d2d94c93dd5ca95c7d5ac4>; CN={64C49D93-BBB7-
410E-B999-837B5B90422B}, CN=Policies, CN=System, DC=net, DC=dom]
Servers [netdc1.net.dom] ~ [netdc4.net.dom]
FAIL FAIL[1]: mismatch with current DIT image
...
-=>> |*** DSA Diagnostics ***|<<=-
...
Checking for missing replies...
No missing replies!INFO: Server sizes are equal.
*** Different Directory Information Trees. 1 errors (see above). ***
FAIL -=>> FAIL <<=-
closing connections...
netdc1.net.dom; netdc4.net.dom;

In this case, a GPO named {64C49D93-BBB7-410E-B999-837B5B90422B} has been

changed on a domain controller.

Thus, you can see both the number of errors and their location. The sizes of
compared trees on the specified servers can be equal as well as not equal. This
depends on the changes made with the directory objects.

Different Number of Defined Attributes of the Same Object

If the replicas of the same object have different numbers of attributes, the statistical
comparison, again, reports only that the replicas' sizes are not equal. Let us look at
the results produced by a full-content comparison.

C:\>dsastat -s:netdc1.net.dom;netdc4.net.dom -b:DC=net,DC=dom -t: FALSE

Unsorted mode.
Opening connections...
...
...(Terminated query to netdc1.net.dom. <No result present in message>)
...(Terminated query to netdc4.net.dom. <No result present in message>)
FAIL AttrCount mismatch : Attrcount[17]@Server[netdc1.net.dom] !=
Attrcount[16]@Server[netdc4.net.dom]
for Dn
'<GUID=74c87b3d85df0945bab5d2ccd5e31381>;<SID=010500000000000515000000dc
f4dc3ba837d66516c0ea3255040000>;CN=John Smith,OU=Staff,DC=net,DC=dom'
********** Dumping Attribute List **********
---------------> Server [netdc1.net.dom] <--------------
Attr[0] = cn
 Attr[1] = description
Attr[2] = displayName
Attr[3] = givenName
Attr[4] = name
Attr[5] = nTSecurityDescriptor
Attr[6] = objectCategory
Attr[7] = objectClass
Attr[8] = objectSid
Attr[9] = primaryGroupID
Attr[10] = replPropertyMetaData
Attr[11] = sAMAccountName
Attr[12] = sAMAccountType
Attr[13] = sn
Attr[14] = userAccountControl
Attr[15] = userPrincipalName
Attr[16] = whenCreated
----------------> Server [netdc4.net.dom] <---------------
Attr[0] = cn
Attr[1] = displayName
Attr[2] = givenName
Attr[3] = name
Attr[4] = nTSecurityDescriptor
Attr[5] = objectCategory
Attr[6] = objectClass
Attr[7] = objectSid
Attr[8] = primaryGroupID
Attr[9] = replPropertyMetaData
Attr[10] = sAMAccountName
Attr[11] = sAMAccountType
Attr[12] = sn
Attr[13] = userAccountControl
Attr[14] = userPrincipalName
Attr[15] = whenCreated
FAIL FAIL[1]: mismatch with current DIT image

-=>>|*** DSA Diagnostics ***|<<=-

Objects per server:
...
Bytes per object:
...
Checking for missing replies...
No missing replies!INFO: Server sizes are not equal (min=43841, max=43830).
*** Different Directory Information Trees. 1 errors (see above). ***
FAIL -=>> FAIL <<=-
closing connections...
netdc1.net.dom; netdc4.net.dom;

As you can see, the tool displays the number of attributes for each object replica,
shows the DN of the object, and then lists the attributes for each replica. The missing
attribute can be easily found.

Different Number of Objects

In the following example, a user mark and a computer Comp 1 have been deleted
from the Staff OU on one domain controller, and the changes have not yet been
replicated to another DC. In this case, both statistical and full-content comparisons
report that the test has failed, and that there has been a "Server total object count
mismatch". A full-content test, however, displays specific information about the error:
the type and name of the missing object. Look at the following sample output:

C:\>dsastat -s:netdc1.net.dom;netdc4.net.dom -b:OU=Staff,DC=net,DC=dom

-t: FALSE
Unsorted mode.
...
-=>>|*** DSA Diagnostics ***|<<=-
Objects per server:

Obj /Svr netdc1.net.dom netdc4.net.dom Total

computer 1 2 3
group 2 2 4
organizationalUnit 1 1 2
user 4 5 9
volume 1 1 2
---
9 11 20
FAIL Server total object count mismatch
...
Checking for missing replies...
Fail [2]: missing 1 replies for
'<GUID=65d29dba5ad79e4e947c4a85bdb2c774>;<SID=010500000000000515000000dc
f4dc3ba837d66516
c0ea3264040000>;CN=Comp1,OU=Staff,DC=net,DC=dom'
Fail [3] : missing 1 replies for
'<GUID=f8c1c9cf1e919a469821b7ceb67608e2>;<SID=010500000000000515000000dc
f4dc3ba837d66516
c0ea3266040000<;CN=Mark,OU=Staff,DC=net,DC=dom'
INFO: Server sizes are not equal (min=1838, max=2227).
*** Different Directory Information Trees. 3 errors (see above). ***
FAIL -=>> FAIL <<=-
closing connections...
netdc1.net.dom; netdc4.net.dom;

Replication Diagnostics Tool (RepAdmin.exe) (ST)

Replication Diagnostics Tool is the only facility that allows an administrator to view
and manage Active Directory replication topology and events from the command
prompt or batch files. This tool, coupled with DsaStat.exe, helps to troubleshoot
Active Directory consistency problems at a forest-wide level.

The Windows .NET version of RepAdmin provides about a dozen new operations (in
contrast with Windows 2000 version) as well as a few new parameters to previously
available operations (some of which are discussed below).

We will consider some of the most frequently used options of this tool. Some of these
options may seem to be too complicated. However, if you understand the Active
Directory replication model well, you will quickly learn how to use the tool in the most
effective way.

Note To use RepAdmin, you should be logged on to the network as a domain

administrator. Furthermore, some operations can only be performed on a
domain controller rather than on a client computer.
Note Essentially, the Windows 2000 and Windows .NET versions of RepAdmin work
in a similar way and slightly differ in their screen output messages as well as in
their usage of some parameters.

Monitoring Replication Topology and Events

Triggering KCC

Normally, the Knowledge Consistency Checker (KCC) periodically verifies and

automatically rebuilds the replication topology. You might want to forcibly start this
process after some topology changes (e.g., after deleting connections). Take a look
at the example:

C:\>repadmin /kcc netdc1.net.dom

Consistency check on netdc1.net.dom successful.

Viewing Replication Partners (/showreps)

The first and one of the most important steps for managing replication is to
enumerate partners (neighbors) that have connections to the specified DC and to
determine the replication topology for each naming context. (This information is used
with many other of RepAdmin's parameters.) The following example was obtained for
a forest that consists of two domains and two sites. The root domain net.dom is
located in the NET-Site and contains two DCs (NETDC1 and NETDC3A). The child
domain subdom.net.dom is located in the Remote-Site and has a single DC (NETDC2).
Let's see what kind of information RepAdmin displays for the specified DC. (In-line
comments are in bold brackets.)

C:\>repadmin /showreps netdc1.net.dom

NET-Site /NETDC1
DC Options: IS_GC [The specified DC is a Global Catalog server]
Site Options: (none)
DC object GUID: 02c2b1f6-e9b6-4e64-91f6-3a54b087bacc [By using this
GUID, you can bind to the DSA object named CN=NTDS Settings, CN=NETDC1,
CN=Servers, CN=NET-site, CN=Sites, CN=Configuration, DC=net, DC=dom.]
DC invocationID: 02c2b1f6-e9b6-4e64-91f6-3a54b087bacc

====INBOUND NEIGHBORS===================

DC=net,DC=dom [The Domain partition is only replicated among

DCs that serve the same domain.]
NET-Site\NETDC3A via RPC
DC object GUID: a10bc624-6d04-44e7-adf9-5ef4282efbb1
Last attempt @ 2002-06-02 18:13:57 was successful.
[The last replication time and the result of this operation is
displayed for each connection.]
CN=Configuration,DC=net,DC=dom [The Configuration and Schema
partitions are replicated among all DCs in the forest.]
Remote-Site\NETDC2 via RPC
DC object GUID: 8c19c6f6-1821-4ca7-97b5-c23307c5c49c
Last attempt @ 2002-06-02 16:58:51 was successful.
NET-Site\NETDC3A via RPC
DC object GUID: a10bc624-6d04-44e7-adf9-5ef4282efbb1
Last attempt @ 2002-06-02 17:57:40 was successful.
 CN=Schema,CN=Configuration,DC=net,DC=dom
Remote-Site\NETDC2 via RPC
DC object GUID: 8c19c6f6-1821-4ca7-97b5-c23307c5c49c
Last attempt @ 2002-06-02 16:58:51 was successful.
NET-Site\NETDC3A via RPC
DC object GUID: a10bc624-6d04-44e7-adf9-5ef4282efbb1
Last attempt @ 2002-06-02 17:57:40 was successful.

DC=App-Part,DC=net,DC=dom [The application directory partition

is only replicated among specifically assigned DCs.]
NET-Site\NETDC3A via RPC
DC object GUID: a10bc624-6d04-44e7-adf9-5ef4282efbb1
Last attempt @ 2002-06-02 17:57:40 was successful.

DC=subdom,DC=net,DC=dom [This domain partition is also partially

replicated to this DC, since it is a GC server.]
Remote-Site\NETDC2 via RPC
DC object GUID: 8c19c6f6-1821-4ca7-97b5-c23307c5c49c
Last attempt @ 2002-06-02 16:58:51 was successful.

To see outbound partners, add the /repsto parameter (or/all) to the previous
command. RepAdmin will append the following lines to the output:

====OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS========

DC=net, DC=dom
NET-Site\NETDC3A via RPC
DC object GUID: a10bc624-6d04-44e7-adf9-5ef4282efbb1

CN=Configuration,DC=net,DC=dom
NET-Site\NETDC3A via RPC
DC object GUID: a10bc624-6d04-44e7-adf9-5ef4282efbb1

CN=Schema,CN=Configuration,DC=net,DC=dom
NET-Site\NETDC3A via RPC
DC object GUID: a10bc624-6d04-44e7-adf9-5ef4282efbb1

DC=App-Part,DC=net,DC=dom
NET-Site\NETDC3A via RPC
DC object GUID: a10bc624-6d04-44e7-adf9-5ef4282efbb1
Note In fact, the NETDC1 and NETDC2 domain controllers are connected by the IP
transport (since these DCs are related to the different sites). However, both IP
and RPC transports are displayed as "via RPC". The /showconn operation (see
below) displays more detailed information.

To obtain more details, add the /verbose parameter to a command. Verbose mode
displays additional information; for example:

...
CN=Schema,CN=Configuration,DC=net,DC=dom
Remote-Site\NETDC2 via RPC
DC object GUID: 8c19c6f6-1821-4ca7-97b5-c23307c5c49c
Address: 8c19c6f6-1821-4ca7-97b5-c23307c5c49c._msdcs.net.dom
DC invocationID: a2043786-1d80-4ea7-b759-c5884ad6085f
DO_SCHEDULED_SYNCS WRITEABLE COMPRESS_CHANGES
NO_CHANGE_NOTIFICATIONS
USNs: 148919/OU, 148919/PU
Last attempt @ 2002-06-02 16:58:51 was successful.
 NET-Site\NETDC3A via RPC
DC object GUID: a10bc624-6d04-44e7-adf9-5ef4282efbb1
Address: a10bc624-6d04-44e7-adf9-5ef4282efbb1._msdcs.net.dom
DC invocationID: 15eaa260-364d-469c-b2aa-1fe3c74059df
SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE
USNs: 79723 /OU, 79723 /PU
Last attempt @ 2002-06-02 18:57:37 was successful.
...

Look at the highlighted flags from this output. You can conclude the following from
them:

ƒ Both inter- and intra-site replications are scheduled (but these are different
schedules!)
ƒ Inter-site replication is compressed.
ƒ There is no change notification between DCs related to different sites (this is
the default option).
ƒ DCs in the same site are synchronized upon their startup.

Viewing Connections with Replication Partners (/showconn)

To display the most comprehensive information on connections that have been

established for a DC, use the /showconn operation. You can specify:

ƒ The DNS name of the DC that will serve as the source of information
ƒ The GUID (or the NetBIOS name) of the DC you are interested in

(Without the second parameter, you will get all connections for the site where the
specified DC is located.) For example, the NETDC1 domain controller from the
sample configuration has two inbound connections:

C:\>repadmin /showconn netdc1.net.dom NETDC1

Base DN: CN=NETDC1,CN=Servers,CN=NET-
Site,CN=Sites,CN=Configuration,DC=net,DC=dom
====KCC CONNECTION OBJECTS================
Connection --- [I.]
Connection name : fcaa1598-8958-40ce-8be7-f585832d086b
Server DNS name : netdc1.net.dom
Server DN name : CN=NTDS Settings,CN=NETDC1,CN=Servers,CN=NET-
Site,CN=Sites,CN=Configuration,DC=net, DC=dom
Source: NET-Site\NETDC3A [From DC...]
No Failures.
TransportType: intrasite RPC
options: isGenerated
[1] ReplicatesNC: CN=Schema,CN=Configuration,DC=net,DC=dom
Reason: RingTopology
Replica link has been added.
[2] ReplicatesNC: DC=App-Part,DC=net,DC=dom
Reason: RingTopology
Replica link has been added.
[3] ReplicatesNC: CN=Configuration,DC=net,DC=dom
Reason: RingTopology
Replica link has been added.
[4] ReplicatesNC: DC=net, DC=dom
Reason: RingTopology
 Replica link has been added.
Connection - [II.]
Connection name : 8d7bc72b-335c-41c2-82f3-270ce2724c6c
Server DNS name : netdc1.net.dom
Server DN name : CN=NTDS Settings,CN=NETDC1,CN=Servers,CN=NET-
Site,CN=Sites,CN=Configuration,DC=net, DC=dom
Source: Remote-Site\NETDC2 [From DC...]
No Failures.
TransportType: IP
options: isGenerated
[1] ReplicatesNC: CN=Configuration,DC=net,DC=dom
Replica link has been added.
[2] ReplicatesNC: DC=subdom,DC=net,DC=dom
Replica link has been added.
2 connections found.

Notice that two different transport types — one for intra-site (intrasite RPC) and one for
inter-site replication (IP) — are displayed.

The command shown will display all fault connections (that have not been replicated
over a period of time) and the possible cause of failure.

Triggering Replication Events

By using RepAdmin, you can initiate replication events very flexibly. For a domain
controller, the following replication scenarios are available:

ƒ One directory partition is replicated from another DC.

ƒ One directory partition is replicated from all neighbors.
ƒ All directory partitions are replicated from all neighbors.
ƒ A cross-site replication of a directory partition.
ƒ Replication that will be switched from pull mode to push mode.

Let us consider them in detail.

Replication between Two Neighbors

To perform the most atomic replication operation, you must specify:

ƒ A directory context (in Windows .NET, you can also specify a single directory
object; see below)
ƒ The DNS name of the target (destination) server
ƒ The GUID of the source server (from which the changes are copied)

For example, to replicate the domain partition between two DCs, use a command
similar to:

C:\>repadmin /sync DC=net,DC=dom netdc1.net.dom a10bc624-6d04-44e7-adf9-

5ef4282efbb1
Sync from a10bc624-6d04-44e7-adf9-5ef4282efbb1 to netdc1.net.dom
completed successfully.
The following command replicates one directory object only, which allows you to
avoid excessive network traffic:

C:\>repadmin /replsingleobj netdc1.net.dom a10bc624-6d04-44e7-adf9-

5ef4282efbb1 OU=Staff,DC=net,DC=dom

You must wait until the operation is completed, or you can start the operation
asynchronically and check the replication queue to see whether the operation has
completed. To trigger a full replication of a directory context, you can, for example,
use the following command:

C:\>repadmin /sync DC=net,DC=dom netdc1.net.dom a10bc624-6d04-44e7-adf9-

5ef4282efbb1 /full /async
Successfully enqueued sync from a10bc624-6d04-44e7-adf9-5ef4282efbb1 to
netdc1.net.dom.

Then, to monitor the operation, use the command

C:\>repadmin /queue

Here is a sample output:

Queue contains 1 items.

Current task began executing at 2002-06-02 20:01:05.
Task has been executing for 0 minutes, 7 seconds.

[144] Enqueued 2002-06-02 20:01:05 at priority 250

SYNC FROM SOURCE
NC DC=net,DC=dom
DC NET-Site\NETDC3A
DC object GUID a10bc624-6d04-44e7-adf9-5ef4282effbb1
DC transport addr a10bc624-6d04-44e7-adf9-
5ef4282efbb1._msdcs.net.dom
ASYNCHRONOUS_OPERATION WRITEABLE FULL

Replication from All Partners

The /syncall parameter can be used to synchronize a directory partition between a DC

and all its partners. The /A parameter available on Windows .NET-based DCs, can
initiate replication of all partitions stored on a DC.

Sometimes, a command fails. Take a look, for example, at the following output
produced by a command:

C:\>repadmin /syncall netdc1.net.dom DC=net,DC=dom

Syncing partition: DC=net,DC=dom
CALLBACK MESSAGE: Error contacting server a10bc624-6d04-44e7-adf9-
5ef4282efbb1._msdcs.net.dom (network error):
1722 (0x6ba) :
The RPC server is unavailable.
CALLBACK MESSAGE: SyncAll Finished.

SyncAll reported the following errors:

Error contacting server a10bc624-6d04-44e7-adf9-
5ef4282efbb1._msdcs.net.dom (network error) : 1722 (0x6ba) :
 The RPC server is unavailable.

(To see a name which corresponds to the GUID shown, use repadmin /showreps.)

In Windows 2000, only an error code is displayed. You can get a text description of a
message by running RepAdmin with the /showmsg parameter and specifying the error
code.

When the command runs successfully, it reports all partners' names:

C:\>repadmin /syncall netdc1.net.dom DC=net,DC=dom

Syncing partition: DC=net,DC=dom
CALLBACK MESSAGE: The following replication is in progress:
From: a10bc624-6d04-44e7-adf9-5ef4282efbb1._msdcs.net.dom
To : 02c2b1f6-e9b6-4e64-91f6-3a54b087bacc._msdcs.net.dom
CALLBACK MESSAGE: The following replication completed successfully:
From: a10bc624-6d04-44e7-adf9-5ef4282efbb1._msdcs.net.dom
To : 02c2b1f6-e9b6-4e64-91f6-3a54b087bacc._msdcs.net.dom
CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.
Attention If you do not specify a naming context in the repadmin /syncall command,
the Configuration partition is only replicated.

Use the repadmin /syncall /h command to see help information for additional
parameters (flags), some of which are especially important:

ƒ /A — replicates all naming contexts stored on the DC. (A new option in the
Windows .NET version of RepAdmin.) For example, the following command
synchronizes all partitions on NETDC1 DC with all their replicas:
ƒ repadmin /syncall netdc1.net.dom /A
ƒ /d — changes representation of DCs in output messages, for example, instead
of:
ƒ a10bc624-6d04-44e7-adf9-5ef4282efbb1._msdcs.net.dom

you will see

CN=NTDS Settings,CN=NETDC3A,CN=Servers,CN=NET-Site,CN=Sites,
CN=Configuration,DC=net,DC=dom

ƒ /e — enables cross-site replication. You can see the difference if, for example,
you try to synchronize the Configuration partition by using a command with
this parameter, and then without it.
ƒ /P — reverses the direction of replication. When this parameter is used, the
changes are propagated from the specified server to all partners (vice versa
by default).

Failed Replications

If a replication partner is not available, or a network connection doesn't work, the

scheduled replications periodically fail. The following command allows you to see the
statistics on failed replications:

C:\>repadmin /failcache netdc1.net.dom

 ====KCC CONNECTION FAILURES===========
(none)
====KCC LINK FAILURES===========
NET-Site\NETDC3A
DC object GUID: a10bc624-6d04-44e7-adf9-5ef4282efbb1
No Failures.
Remote-Site\NETDC2
DC object GUID: 8c19c6f6-1821-4ca7-97b5-c23307c5c49c
2 consecutive failures since 2002-06-02 19:57:37.
Last error: 1722 (0x6ba):
The RPC server is unavailable.

Viewing Directory Changes

RepAdmin has a few options that can be used for monitoring the actual state of
domain controllers. You can easily determine whether changes have been made on
a DC, and whether directory partitions have been synchronized on different DCs.

Is a Domain Controller up to Date?

Suppose we want to determine whether the domain partition (DC=net, DC=dom) is

synchronized on two domain controllers — NETDC1 and NETDC4. We need to first find
the highest USN on the first DC. Use the following command:

C:\>repadmin /showvector DC=net,DC=dom netdc1.net.dom

NET-Site\NETDC1 @ USN 11785 @ Time 2002-06-07 17:11:21
NET-Site\NETDC4 @ USN 18241 @ Time 2002-06-07 17:09:41

Then we must check the value known to the second DC. We should specify: the
invocationID of the first DC (see description of the /showreps operation above), the
USN found, and the DNS name of either DC:

C:\>repadmin /propcheck DC=net,DC=dom b202a2a9-2e6b-4c9f-9e99-

ac00b873e5c2 11785 netdc1.net.dom
NET-Site\NETDC1: yes (USN 11785)
NET-Site\NETDC4: ** NO! ** (USN 11767) [11767 < 11785]

As you can see, the second DC holds an older USN. If we run the command again
after replicating changes from NETDC1 to NETDC4, the result should be the
following:

C:\>repadmin /propcheck DC=net,DC=dom b202a2a9-2e6b-4c9f-9e99-

ac00b873e5c2 11785 netdc1.net.dom
NET-Site\NETDC1: yes (USN 11785)
NET-Site\NETDC4: yes (USN 11785)

Displaying Replication Metadata

By viewing replication metadata for a directory object, you can check the consistency
between different replicas if you compare attribute versions and USN numbers on
different domain controllers. Furthermore, you can see which DC (it is considered to
be the originating DC) the attributes were last changed on. The following example
shows metadata for an OU object. (The output has been compressed horizontally to
fit the page.)
 C:\>repadmin /showmeta OU=Staff,DC=net,DC=dom netdc1.net.dom

13 entries.
Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute
======= ============== ======= ============= =============
11826 NET-Site\NETDC1 11826 2002-06-07 17:24:38 1 gPOptions
11826 NET-Site\NETDC1 11826 2002-06-07 17:24:38 1 gPLink
11767 NET-Site\NETDC1 11767 2002-06-07 17:09:11 1 objectCategory
11893 NET-Site\NETDC1 11893 2002-06-07 17:33:59 4 name
11907 NET-Site\NETDC1 11907 2002-06-07 17:34:49 3 nTSecurityDescriptor
11767 NET-Site\NETDC1 11767 2002-06-07 17:09:11 1 whenCreated
11767 NET-Site\NETDC1 11767 2002-06-07 17:09:11 1 instanceType
11817 NET-Site\NETDC4 18306 2002-06-07 17:24:17 2 description
11893 NET-Site\NETDC1 11893 2002-06-07 17:33:59 4 ou
11923 NET-Site\NETDC4 18389 2002-06-07 17:40:59 2 street
11923 NET-Site\NETDC4 18389 2002-06-07 17:40:59 2 st
11923 NET-Site\NETDC4 18389 2002-06-07 17:40:59 2 1
11767 NET-Site\NETDC1 11767 2002-06-07 17:09:11 1 objectClass

This output is easier to analyze when compared to the metadata information

produced by the Ldp.exe tool (see Fig. 12.17 in Chapter 12, "Manipulating Active
Directory Objects"). As you can see, the attribute names are displayed here in text
format.

Note If an authoritative restore is performed on a DC, the attribute version numbers

will have large values, since by default these numbers increased by a minimum
of 100,000 for each "standard" restore operation (i.e., if the verinc parameter is
not used).

Registering Changes Made on a Specific DC

It is possible to register all of the changes that have been made on a domain
controller from a specific time point. The following command analyzes the current
state of the domain partition and writes the result to a file:

C:\>repadmin /getchanges DC=net,DC=dom netdc1.net.dom /cookie:log1.txt

Using empty cookie (full sync).

==== SOURCE DC: netdc1.net.dom ====

Objects returned: 100

(0) add DC=net, DC=dom
...
Objects returned: ...
...
New cookie written to file log1.txt (132 bytes)

The command produces a very large screen output; therefore, you might prefer to
add the /statistics parameter to this command.

After some time elapses, you can re-run the command:

C:\>repadmin /getchanges DC=net,DC=dom netdc1.net.dom /cookie:log1.txt

Using cookie from file log1.txt (132 bytes)

==== SOURCE DC: netdc1.net.dom ====

 Objects returned: 3
(0) modify CN=Backup Operators,CN=Builtin,DC=net,DC=dom
1> objectGUID: c997318b-324a-4fa4-b29d-2b045904e093
1> member: CN=John Smith, OU=Staff,DC=net,DC=dom
1> instanceType: 4
(1) delete OU=Marketing\0ADEL:d43d3ee7-861b-4ea1-8b8b-
0b51c0db3de1,CN=Deleted Objects,DC=net,DC=dom
1> parentGUID: eebc28cc-c7b3-4d6f-bd5e-13aef642e30a
1> objectGUID: d43d3ee7-861b-4ea1-8b8b-0b51c0db3de1
1> instanceType: 4
1> isDeleted: TRUE
1> name: Marketing
DEL:d43d3ee7-861b-4ea1-8b8b-0b51c0db3de1
1> lastKnownParent: OU=Staff,DC=net,DC=dom
(2) modify CN=John Smith, OU=Staff, DC=net, DC=dom
1> objectGUID: 50e649bc-69f8-4313-87a6-765e4a335bdd
1> description: A test user
1> instanceType: 4
New cookie written to file log1.txt (132 bytes)

As you can see, two objects have been modified, and one object has been deleted.
The time stamp is renewed, and only new changes will be registered from that
moment.

The same information will be displayed if you run a comparison command:

C:\>repadmin /getchanges DC=net,DC=dom netdc4.net.dom b202a2a9-2e6b-

4c9f-9e99-ac00b873e5c2

Notice that the command contains the domain partition name, the DNS name of a
replication partner (in that case, this is a "reference" DC), and the GUID of a tested
domain controller (netdc1.net.dom). This command displays changes made on
NETDC1 before the replication will be performed and two directory replicas will be
synchronized. In comparison to the previous command (with a cookie file), the last
command will display the same result (the changes made) repeatedly unless the
synchronization of replicas will be carried out. You can choose either command that
is the most appropriate for your conditions.

Comparing Information on Different Domain Controllers

A command that compares the partition replicas stored on different servers must
contain the DNS name of a "reference" server and the GUID of a "source" (tested)
server. All changes made in the source server will be registered. Actually, this
command performs the same job as the DsaStat tool does. The output shown below
was obtained at the time when a great number of user objects on the NETDC1
domain controller were being removed.

C:\>repadmin /getchanges DC=net,DC=dom netdc4.net.dom b202a2a9-2e6b-

4c9f-9e99-ac00b873e5c2 /statistics
Building starting position from destination server netdc4.net.dom

Source Neighbor:
DC=net, DC=dom
NET-Site\NETDC1 via RPC
 DC object GUID: b202a2a9-2e6b-4c9f-9e99-ac00b873e5c2
Address: b202a2a9-2e6b-4c9f-9e99-ac00b873e5c2._msdcs.net.dom
DC invocationID: b202a2a9-2e6b-4c9f-9e99-ac00b873e5c2
SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE
USNs: 12769 /OU, 12769 /PU
Last attempt @ 2002-06-07 19:11:29 was successful.

Destination's up-to-date vector:

6a0cdbee-e064-449f-8c09-3f3c45b54fd6 @ USN 20291
b202a2a9-2e6b-4c9f-9e99-ac00b873e5c2 @ USN 12771

==== SOURCE DC: b202a2a9-2e6b-4c9f-9e99-ac00b873e5c2._msdcs.net.dom ====

******** Cumulative packet totals ***********

Packets: 1
Objects: 100
Object Additions: 0
Object Modifications:0
Object Deletions: 100
Object Moves: 0
Attributes: 600
Values: 600
Dn-valued Attributes:100
MaxDnVals on any attr:1
ObjectDn with maxattr:C
Attrname with maxattr:1
#dnvals 1-250 251-500 501-750 751-1000 1000+
add 0 0 0 0 0
mod 100 0 0 0 0
******************************************
...
Packets: 2
...
Packets: 3
...
**********Grand total*********************
Packets: 3
Objects: 230
Object Additions: 0
Object Modifications: 0
Object Deletions: 230
Object Moves: 0
Attributes: 1380
Values: 1380
Dn-valued Attributes: 230
MaxDnVals on any attr:1
ObjectDn with maxattr:C
Attrname with maxattr:1
#dnvals 1-250 251-500 501-750 751-1000 1000+
add 0 0 0 0 0
mod 230 0 0 0 0
******************************************

If both replicas are synchronized, the command reports

No changes

and all totals are equal to zero.

New "Inter-Site" Operations

The Windows .NET version of RepAdmin offers a number of new operations that are
especially useful in large multi-site forests. Among them are the following:

ƒ repadmin /bridgeheads — lists the bridgehead servers for sites.

ƒ repadmin /istg — lists servers that perform the role of the Inter-site Topology
Generator (ISTG) in sites.
ƒ repadmin /querysites — displays the cost of the link between specified sites.
ƒ repadmin /latency — displays replication latency between sites; this information
allows an administrator to quickly find sites that have not replicated with their
partners over a long period of time.

Auxiliary Options

Managing Replication Status (DSA Options)

Each Directory System Agent (DSA) is represented in Active Directory by an object of

the nTDSDSA class named CN=NTDS Settings that belongs to the appropriate
server object in the Configuration partition. (You can view the attributes of DSA
objects with the ADSI Edit snap-in.) DSA objects have the options attribute, which
significantly affects their state and behavior. An administrator can set the value of this
attribute by using RepAdmin with an undocumented parameter /options. Let us
discuss a few examples.

The following command detects that the specified domain controller is a Global
Catalog server:

C:\>repadmin /options netdc1.net.dom

Current DC Options: IS_GC

The options attribute is equal to 1 in this case. You can set the IS_GC flag to promote
a DC to GC server. Usually, this operation is performed with the Active Directory
Sites and Services snap-in.

The following two parameters allow you to "isolate" a DC from its replication partners
for troubleshooting or some other purpose. The next example shows that replication
from the specified DC (outbound replication) is disabled:

C:\>repadmin /options netdc4.net.dom

Current DC Options: DISABLE_OUTBOUND_REPL

The options attribute is equal to 4 (hex) in this case (if the DC is not a GC server!).

The state of inbound replication (from partners to a specified DC) is determined by

the DISABLE_INBOUND_REPL flag. (This flag corresponds to an options attribute value
equal to 2.) You can set both flags and totally disable replication for the DC.

To set a flag, specify it with a "+" (plus) sign. To clear a flag, use "-" (minus). For
example, the following command clears the flag and re-enables outbound replication
from the DC:
 C:\>repadmin /options netdc4.net.dom -DISABLE_OUTBOUND_REPL
Current DC Options: DISABLE_OUTBOUND_REPL
New DC Options: (none)

Every "disable replication" operation is registered in the Directory Service log (Event
ID 1113, 1114, 1115, and 1116). Look at the following two examples:

Event Type: Warning

Event Source: NTDS General
Event Category: Replication
Event ID: 1115
...
Computer: NETDC1
Description:
Outbound replication has been disabled by the user.

When replication is enabled, an informational event is also registered:

Event Type: Information

Event Source: NTDS General
Event Category: Replication
Event ID: 1116
...
Computer: NETDC1
Description:
Outbound replication has been enabled by the user.

Converting Directory Time (/showtime)

RepAdmin can convert time values stored in Active Directory into a readable format.
(See also NLtest description at the beginning of this chapter.) Let us convert the
same value 126679218485309520. Enter repadmin /showtime at the command prompt,
and paste the value in. Erase the seven rightmost digits and press <Enter>. The
result should be the following:

C:\>repadmin /showtime 12667921848

12667921848 =0x2f31125b8 = 02-06-07 11:10.48 UTC = 2002-06-07 15:10:48 local

You may notice that both UTC and local time are displayed.

In Windows .NET, you can obtain the same result easier — use the W32tm
command:

C:\>w32tm /ntte 126679218485309520

146619 11:10:48.5309520 --- 6 /7 /2002 3:10:48 PM (local time)

Displaying Error Description (/showmsg)

RepAdmin.exe has an option that will help you when you write and debug ADSI
scripts and application and analyze event logs, as well as in many other cases. You
can use this utility rather than searching the documentation for information on each
error. The utility provides many more options than the net helpmsg command does.
RepAdmin.exe can display error text for both Win32 error codes (including errors for
ADSI 2.5) and generic COM error codes.
You can specify an error code in either form: as a long integer (e.g., -2147016684) or
a hexadecimal value (e.g., 0x80072014; the 0x prefix is mandatory, do not forget to add
this prefix if you have copied an error's code from the Event Viewer). Short integers,
such as 8453, are also acceptable. Here is an example of how to use this parameter:

C:\repadmin /showmsg 0x80072014

-2147016684 = 0x80072014 = "The requested operation did not satisfy one
or more constraints associated with the class of the object."

Active Directory Replication Monitor (ReplMon.exe) (ST)

Active Directory Replication Monitor is a GUI tool that is exclusively intended for
monitoring and managing all kinds of replication in AD-based domains (Windows
2000 and Windows .NET domains). With this tool, you can monitor and register all
replication events, force replication, start generating replication topology, view Global
Catalog and bridgehead servers, and view trusts and replication metadata for an
Active Directory object. The list of options could be continued. The tool has a simple
and friendly user interface.

Preparation Steps and Analysis of Information

After the tool's start-up, you should create a list of monitored servers. This might be a
tiresome operation in a large domain, but you only need to perform it once. When all
necessary servers have been added to ReplMon, save the current configuration by
clicking Save Monitored List As in the File menu. The next time the tool is running,
choose the Open Script command and load the necessary configuration. A sample
screen of the ReplMon's main window is shown in Fig. 11.3.

Figure 11.3: The main window of ReplMon, where you can browse the domain tree
and see log files for selected domain partition and replication partner

ReplMon uses various icons to represent monitored servers and their replication
partners, which helps an administrator to easily determine replication status. The
icons are described in the table below.
Icon Description

Directory partition that has replication problems

Bridgehead server
Global Catalog server
Direct replication partner that has encountered replication problems
Successfully replicated direct replication partner
Transitive replication partner

Let us consider what replication topology information we can obtain from the
screenshot shown in Fig. 11.3:

ƒ The sample forest comprises two domains, two sites, and three domain
controllers.
ƒ Each site has a Global Catalog server: NETDC1 DC receives a partial replica
of the subdom.net.dom domain, whereas NETDC2 DC receives partial
information about the DC=net,DC=dom naming context. In addition, both
controllers are the bridgehead servers.
ƒ NETDC1 DC stores three application directory partitions:
DC=DomainDnsZones, DC=net,DC=dom, DC=ForestDnsZones,
DC=net,DC=dom, and DC=App-Part, DC=net, DC=dom. Only the last partition
has a replica on NETDC3A DC.
ƒ NETDC2 DC stores the domain partition (DC=subdom,DC=net,DC=dom) that
is not replicating to any other domain controllers.
ƒ Replication events for the selected pair of partners (NETDC1 and NETDC3A)
and directory context (DC=net,DC=dom) are written into a file named
netdc1.net.dom-DC=net,DC=dom-NETDC3A.log.
ƒ NETDC1 DC fails to replicate three directory contexts (domain, schema, and
configuration) from NETDC3A DC. The log selected contains the reason of
failure: "The RPC server is unavailable".
ƒ NETDC3A DC has a general problem with replication of the DC=net,DC=dom
naming context and fails to replicate data from NETDC1 DC.

As you can see, ReplMon provides an administrator with thorough replication

information.

Log Files

By default, ReplMon writes all Replication Status Logs to the My Documents folder
of the currently logged on user. The log name combines the domain controller's DNS
name, directory partition name and a replication partner down-level name.

You can assign a different location if you like. Click Options in the View menu, check
the Default Path for Replication Status Logs box, and enter the necessary path.
(To troubleshoot replication problems, you can also enable debug logging, allowing
ReplMon to register every performed operation.)

ReplMon updates the Replication Status Logs at its start-up, and you can specify a
time interval for automatic updating. If you do so, all replication activity for monitored
servers will be registered in the logs.

Managing Replication

By using ReplMon, you can initiate any replication events possible for the selected
domain controller. Most operations are started through the context menu of the
selected DC. These operations are quite simple to learn, and all the tool's features
are visible in the menu.

ReplMon has a very useful feature that allows you to view performance data usually
available through the Performance snap-in. (See the "Monitoring Replication"
section in Chapter 6, "Configuring and Troubleshooting AD-based Domains".) First,
open the Performance snap-in and choose the counters you are interested in and
write down their names. (You do not need the Performance snap-in itself!) To
simplify a task, you can add the necessary counters to the Performance snap-in's
window, click the Copy Properties button on the tool bar, and paste the text into a
document. This text will contain all counter names (see the Path parameter) in
addition to other information. Then start ReplMon, click Options on the View menu,
and select the Status Logging tab (Fig. 11.4).

Figure 11.4: Configuring counters that will comprise current performance data

Check the Performance Statistics box, click Add, and enter a counter name (e.g.,
"\NTDS\DRA Inbound Bytes Compressed (Between Sites, After Compression) Since
Boot"). Repeat this step if necessary. If you have already saved the counter names
from the Performance snap-in into a text document, you can now easily copy-and-
paste all names. Now you can select a DC and choose the Show Current
Performance Data command from the context menu. You will see all current values
of counters in the Performance Data window. The current data will be also written to
the domain controller's logs.

Also, take note of the Group Policy Objects and Display Changed Attributes
when Replication Occurs checkboxes on the Status Logging tab. The former
checkbox will allow you to verify consistency of GPOs (AD and SysVol versions) with
the Show Group Policy Object Status command. The latter checkbox turns on the
logging of changed attributes: you will see their names as well as the names of
corresponding directory objects in the logs. This will allow you to trace all changes in
the directory more precisely.

Chapter 12: Manipulating Active

Directory Objects
In this chapter, we will discuss Active Directory modification tools in detail. These
tools allow administrators to find necessary directory objects and edit their attribute
values; manipulate various domain objects (computer account, domain trusts, secure
channels, etc.); export specified objects to a file, and import (create) objects from a
file in the same or another domain. All listed operations can be performed with either
a single directory object or a number of objects.

Finding Information in Active Directory

Since Active Directory may contain a huge number of directory objects and have a
complex domain structure, it is necessary to have the ability to locate, or pick out the
necessary objects quickly and view (edit) their attributes. You can use for that
purpose the following facilities.

GUI Tools

ƒ The search option of Active Directory client software (built-in features of

Windows 2000/XP/.NET, or the Active Directory Client Extension, DSClient).
DSClient can be installed on any Windows platform. The Find window allows
you to look for standard objects (users, groups, computers, etc.) as well as to
use the common and custom queries. (See the "Configuring Search Option on
a Client Computer" section in Chapter 8, "Common Administrative Tasks.")
ƒ Active Directory Users and Computers snap-in — this snap-in has a Filter
option that allows you to narrow the scope of viewed objects. The Find option
allows you to locate and select objects for manipulating within a domain as
well as in the entire forest (since it is able to work with Global Catalog).
Moreover, the Windows.NET version of that snap-in introduces Saved Queries
that allows the administrator to work with defined sets of selected directory
objects. (The snap-in was discussed in Chapter 7, "Domain Manipulation
Tools.")
ƒ AdsVw.exe and Ldp.exe (ADSI SDK and Support Tools) — these powerful
tools allow you to compose complex queries and apply them to a domain as
 well as to the entire forest. AdsVw.exe can open a number of query windows
simultaneously. (Both of these tools are described later in this chapter.)

Command-line Tools

ƒ DsQuery.exe and DsGet.exe — the standard Windows .NET tools (they do not
work on Windows 2000 systems!) that use the LDAP protocol (therefore, they
can query both Windows 2000- and Windows .NET-based domains) and can
find directory objects of various types as well as display their attributes.
Search operations can be performed within a single domain or entire forest.
ƒ Search.vbs — a script from the Support Tools pack. Can search within a
single domain and work with the LDAP provider only.
ƒ Windows Domain Manager (NetDom.exe) (Support Tools) — can display
specific information about domains (FSMO role owners, trusts, etc.) as well as
perform modifications.

Active Directory Search Tool (Search.vbs) (ST)

The Search.vbs script is a simple, handy tool that allows you to retrieve the attributes
of the specified objects. By default, the script displays the Ads Paths of the children
of the object specified by its distinguished name. These children objects may be of
any type.

Administrators or any other users may use the script on any Windows platform,
provided that the Windows Scripting Host (WSH) is installed. This is a unique
instrument, since the other search tools require Windows 2000/XP/.NET.

Caution The Search.vbs script does not display certain object attributes, such as
objectGUID, objectSID, lastLogon (these are attributes of "complex" types,
such as OctetString, Largelnteger, etc.), and some others. What is worse,
the script has an internal bug, which sometimes produces an erroneous
output when such attributes are included in the returned parameters list (for
instance, search for a user's objectSID, lastLogon, and cn attributes).

Analyzing the listing of the script will help you to better understand the
methods of retrieving data of various types (see also Chapter 16, "Active
Directory Service Interfaces (ADSI)") while composing your own scripts.

Output Data Format

The script outputs the data found as a sequence of lines in the following format:

attributeName object# [=]

propertyValue

If the script cannot display a property value, it outputs only the first two components,
e.g., objectSID 1. If a property has an empty value or is not defined, the "=" character is
added, e.g., description 1 =.

A few examples of using Search.vbs are presented below.

Example 1. Searching for an Object Using Its GUID

Suppose you want to verify whether a known GUID really belongs to a directory
object, or you want to check the name of this object. You may use the following
command:

C:\>search
"LDAP://<GUID=075f1790071a854d82ee5556c3a11d64>"/S:base

The resulting output will be similar to:

<LDAP://<GUID=075f1790071a854d82ee5556c3a11d64>>;
(ObjectCategory=*); ADsPath; base Finished the query. Found 1
objects. ADsPath
1 = LDAP://OU=Staff, DC=net, DC=dom

You may also widen the scope of the search (i.e., use the /s:oneLevel or /S:subTree
parameter and get the base object's children names), or specify output of additional
attributes.

Note If the object's name is all you want to know, you may also use the Guid2obj.exe
utility from the Windows 2000 Resource Kit. You should provide the object
GUID as a parameter, and the tool will retrieve the distinguished name of the
object from the nearest global catalog server.

Example 2. Finding All Policies in a Domain

Sometimes, it is necessary to know what policies (GPOs) exist in a domain, and

which names they go by in administrative snap-ins. You could look up the value of
the display Name attribute for each policy object in the CN=Policies, CN=System
subtree of a domain container. However, it is much faster to use Search.vbs. The
query might look like this:

search "LDAP://DC=net, DC=dom"/C:

(objectClass=GroupPolicyContainer) /S:subtree
/P: cn, displayName

Possible resulting output:

<LDAP://DC=net, DC=dom>; ((objectClass=GroupPolicyContainer));

cn,
displayName; subtree Finished the query. Found 5 objects. cn 1 =
{31B2F340-016D-11D2-945F-00C04FB984F9} displayName 1 =
Default Domain Policy cn 2 =
{6AC1786C-016F-11D2-945F-00C04fB984F9} displayName 2 =
Default Domain Controllers Policy cn 3 =
{9EFADC61-8833-4970-9CE3-AF705E197908} displayName 3 = NET-
Site GPO cn 4 =
{3DE99CCC-C0F6-4F21-BE9C-E6D3F7EB6370} displayName 4 =
ADMINs OU's GPO cn 5 =
{55EAC8BC-D3C7-4B11-AA00-ECB7620A7FB9} displayName 5 =
COMPs OU's GPO
As you can see, there are three additional GPOs (one for the site and 2 for OUs) in
the domain, besides the default ones.

The same operation could be done using the following command:

dsquery * -filter
objectClass=GroupPolicyContainer -attr cn
displayName

Browsing and Editing Active Directory Objects

There are three basic "standard" tools that can be used for browsing Active Directory
and editing the properties of directory objects.

ƒ ADSI Edit snap-in — from the Support Tools or Windows Administration Tools
packs. This snap-in was discussed in Chapter 7, "Domain Manipulation Tools".
It does not display all directory objects and attributes, but has a simple user
interface and a flexible mechanism of custom query views. It provides you with
access to all Active Directory partitions (including application partitions) as well
as Global Catalog and offers a standard way of working with permissions on
objects. Works with the LDAP protocol only.
ƒ Active Directory Browser (AdsVw.exe) — from the Active Directory Service
Interfaces Software Development Kit (ADSI SDK). The only tool that is able to
work with both the LDAP and WinNT protocols. It therefore allows you to work
with AD- and Windows NT-based domains simultaneously. It is not well-
documented and requires a solid understanding of Active Directory. Works
with security descriptors.
ƒ Active Directory Administration Tool (Ldp.exe) — from the Support Tools. The
most sophisticated tool for manipulating directory objects with the LDAP
protocol. It requires extensive knowledge of LDAP basics (naming, queries,
etc.) as well as Active Directory architecture. Works with security descriptors
and Active Directory replication metadata.

These utilities can be regarded as "mandatory" tools set for troubleshooting various
directory problems, and especially for composing your own administrative scripts or
designing Active Directory-oriented applications.

In addition, Windows .NET-based domain controllers offer two powerful command-

line utilities — DsGet.exe and DsMod.exe — that are useful for batch modifications of
directory objects.

Note Unfortunately, among the above-mentioned tools, only the ADSI Edit snap-in
works with non-Latin Unicode names of objects without any problems. The
limitations of the other two tools are discussed in the appropriate sections.

If you need to work with objects' GUIDs (the objectGUID attribute), use Ldp.exe
or DsQuery.exe, since the other two tools (AdsVw.exe and ADSI Edit) display a
GUID as a binary value (octet string), which cannot be used for binding,
referring, etc.
Active Directory Browser (AdsVw.exe) (ADSI SDK)

The Active Directory Browser is included in the ADSI SDK (also known as Active
Directory SDK) that you can download from the Microsoft website (see links in
Appendix A).

The main peculiarity of the Active Directory Browser is its ability to work with both
Windows NT 4.0 and AD-based (Windows 2000 and Windows .NET) domains (see
Figs. 12.1 and 12.2). Moreover, this is the only browsing tool that has multiple-
document interface (MDI), which allows you to open separate windows for different
objects or queries, organize them in the main window, and, therefore, simultaneously
work with many directory objects, either in the same domain or in a few domains.

Fig. 12.1: Browsing the flat directory object namespace of a Windows NT 4.0 domain

Fig. 12.2: Browsing the object tree of a AD-based domain

Unfortunately, this tool is not documented. That is why we will consider some basic
features in detail, since many of the tool's options are not obvious.

Note When AdsVw.exe runs on Windows 2000-based computers, it displays a non-

 Latin Unicode name as a sequence of the question (?) characters. If the LDAP
provider is used, distinguished names as well as RDNs with non-Latin coding
are also displayed as strings made up of "?". On Windows .NET-based
computers, AdsVw.exe works properly within both Windows 2000 and Windows
.NET domains.

The tool provides child windows of two types.

ƒ ObjectViewer — a two-pane window, in which you can navigate the object

tree and view/edit their values (see Figs. 12.1 and 12.2). If the current user
doesn't have permissions to access a property, the "???" string is displayed
instead of the property's value.
ƒ Query — a table form (see Fig. 12.5) that consists of the selected attributes
for the objects found in accordance with the specified query string (an LDAP
filter or SQL query).

Fig. 12.5: A sample query

To open a new browsing window, press the <Ctrl>+<N> keys, select ObjectViewer
in the opened window, and fill in the Enter ADs path field (Fig. 12.3). (Remember
that you can include the name of a specific server in the directory path.)

Fig. 12.3: Basic information for a new browsing session

To use credentials different from those of the last connected user, check the Use
OpenObject and Secure Authentication boxes, and fill in the Open As and
Password fields.
Some attributes, such as primaryGroupToken, can be viewed only if you have
checked the Use Extended Syntax box.

Note The mandatory attributes of an object are shown first in the Properties list (see
Figs. 12.1 and 12.2) and are followed by the optional attributes in alphabetical
order.

The results of a sample query are shown in Fig. 12.5. To start a query, press the
<Ctrl>+<N+ keys, select Query in the opened window, and fill in all fields in the Edit
Query window (Fig. 12.4). All attribute names must be explicitly specified. Click OK.
You may leave all fields in the next window (Set Search Preferences) empty. (You
will understand the meaning of the parameters presented in this window better if you
read the section about the Ldp.exe tool later in this chapter, and about searching
Active Directory in Chapter 16, "Active Directory Service Interfaces (ADSI).")

Fig. 12.4: Preparing a sample query: finding all OUs in the domain
Note You may use the privileges of the currently logged user when browsing
directory objects (using either protocol), but you must always provide valid
credentials while creating a new query. Otherwise the query will be
unauthenticated (and therefore very restricted), and the result set will most
probably be empty.

The window with the result set for the sample query is shown in Fig. 12.5.

If the result set does not fit the window, you must scroll down all lines (using the
down arrow button) to see the entire set for the first time.

Active Directory Administration Tool (Ldp.exe) (ST)

Active Directory Administration Tool (Ldp.exe) is a GUI tool, which allows you to
query, browse, and modify LDAP-compliant directories (servers) via the LDAP
protocol. The tool allows an administrator to access information that cannot be
derived with the help of other tools, as well as to compose sophisticated and powerful
queries with various scopes.

Note The Windows .NET version of Ldp.exe works properly within both Windows
 2000- and Windows .NET-based domains, but cannot run on Windows 2000
systems. The Windows 2000 version of Ldp.exe fails to display Unicode names
in non-Latin coding and the contents of directory containers with similar names.
Both in tree-browsing mode and when search operations are performed,
Ldp.exe always displays all non-Latin Unicode values of attributes in string
format in the form of <ldp: Binary blob>.

Connecting and Binding

To work with an LDAP server, the user must perform two primary operations —
connecting and binding. (Connectionless operations and operations without binding
(authenticating) are extremely restricted.) The information necessary for both
operations is shown in Fig. 12.6.

Fig. 12.6: Connecting and binding to a LDAP server

The Server field in the Connect window can contain a server's DNS name or IP
address as well as a domain DNS name. By default, port 389 is used for the LDAP
protocol, and port 3268 is designated for Global Catalog. If you leave the Server field
blank when working on an AD-based domain client computer, a connection is made
to your logon DC (LOGONSERVER). (To work with Ldp.exe in an AD-based
environment, you must be logged onto a forest.) If the User and Password fields in
the Bind window are left blank, the credentials of the user who is currently logged on
are used.

If the connection is successful, the information about the RootDSE object — base
DSA information — is displayed. After binding, you can make queries and/or browse
the object tree (click Tree in the View menu) (Fig. 12.7).

Fig. 12.7: Connecting to an Active Directory server (Windows 2000- or Windows

.NET-based domain controller) and viewing the object tree of the domain
As shown in Fig. 12.7, the tool's window is divided into two panes: the tree pane (left)
and the result pane (right). To explode a node in the object tree, simply click on it
twice. Which objects are displayed in the result pane depends on the privileges of the
user whose credentials you entered while binding to the server.

General Options

The tool's basic options are defined in the General Options window. To open it, click
General in the Options menu (Fig. 12.8).

Fig. 12.8: Default general options

Value Parsing

In some specific cases, you may want the values of found attributes to be displayed
in binary format. Select the Binary switch and, instead of the default string
representation of an attribute, you will get its "low-level" value. For instance, the
string format may look like:

1>
whenCreated: 3/15/2002 8:38:45 Central Standard Time
Central Daylight Time;

The binary format will be:

1>
whenCreated: 32 30 30 32 30 33 31 35 31 34 33 38 34 35
2e 30 20020315143845.0
5a Z

LDAP Version
You can select the version of LDAP protocol only before the connection is made.
After this, both switches in the LDAP Version group are grayed.

Auto Default NC Query

Checking this box enables the display of the RootDSE information when connecting
to a LDAP server. Besides, if this box is checked, the current domain context name is
automatically used as the base DN when the tree view is selected. Otherwise, you
must always specify a DN of a container.

Virtual List View (VLV)

Virtual List View is a new feature of Windows .NET systems that support a pair of
appropriate LDAP controls (namely, 2.16.840.1.113730.3.4.9 and
2.16.840.1.113730.3.4.10). The feature is designed for retrieving information from
queries that produce very large result sets. The user can only obtain a predefined
number of sorted rows produced by a query rather than the entire result set that can
count thousands of rows. Depending on the data received, the user can re-define the
query and repeat the search until the necessary information will be obtained. In the
Ldp tool, this feature is realized as a special window that can be opened either
automatically (if you check the Auto VLV browse when box) or manually (if you
select the Virtual List View command in the Browse menu). In the former case, the
Virtual List View window opens when you try to view (in tree mode) contents of a
directory object that comprises more child objects than is specified (by default, 100).
The methods of working with this window do not depend on how it is opened. An
example of the window is shown in Fig. 12.9.

Fig. 12.9: An example view of the Virtual List View window

The Virtual List View window resembles the Search window except for the data
pane that displays specified attributes of found objects in a tabular form. The new
portions of data will be requested as you scroll down the table rows. The Type Name
or Select from List field allows you to enter an object name, which the requested
server will try to find within the defined query. A few rows before that object and a few
rows after that object will only be sent to the client and displayed in the table. To see
the children of a found object, click twice on the corresponding row. You can right
click on an object and select for it a standard LDAP operation in the context menu
(see Fig. 12.9).

DN Processing

In the DN Processing group you can indicate how the tool will display the
distinguished names of the objects found. All options are listed below with sample
strings.

ƒ None (default)
ƒ >> Dn:
ƒ CN=Administrator, OU=ADMINs,
DC=net, DC=dom >> Dn: CN=Certificate
ƒ Templates, CN=Public Key Services,
CN=Services, CN=Configuration, DC=net,
DC=dom

ƒ Explode
ƒ >> Dn: CN=Administrator;
OU=ADMINs; DC=net; DC=dom; >> Dn:
ƒ CN=Certificate Templates; CN=Public
Key Services; CN=Services;
CN=Configuration; DC=net; DC=dom;

ƒ No type
ƒ >> Dn: Administrator; ADMINs; net;
dom; >> Dn: Certificate
ƒ Templates; Public Key Services;
Services; Configration; net; dom;

ƒ Ufn
ƒ >> Dn: CN=Administrator,
OU=ADMINs, DC=net, DC=dom >> Dn:
ƒ CN=CertificateTemplates,
CN=PublicKeyServices, CN=Services, CN=Configuration,
DC=net, DC=dom

Notice that in the last case there are no spaces in RDNs.

Buffer Size

The Number of lines parameter sets the number of rows displayed in the result pane
before wrapping begins. Do not forget that you cannot obtain more rows in a query
than the MaxPageSize value in the query policy permits.

The Chars per line parameter sets the maximum number of characters displayed in
a line. Lines whose length exceeds this value are truncated!

Referrals and Their Effect on Search Results

In practice, referrals are very important in search operations, as they may greatly
influence the results. The Chase referrals box in the Search Options window (see
Fig. 12.12, left) determines whether or not the server generates LDAP referrals when
trying to find objects. (By default, the box is not checked, since this improves the
performance of the search.) However, in some cases, if this box is checked, an error
can occur:

Error: Search: Referral.

<10> Result <10>: 0000202B: RefErr: ...

Some other scenarios in which you may get an unexpected result are also possible.
Therefore, it is necessary to select the status of this checkbox carefully. Let us
discuss this issue using two examples.

Suppose you are logged onto a computer joined to a child domain, and want to
search the parent domain (or a domain from another domain tree) by entering its DN
as the base of the search. You must either make an LDAP connection to a DC in the
parent domain or enable chasing referrals. (Otherwise, the referral error will be
reported.) Why referrals should help in such a situation will become clear a bit later.
(Maybe you already understand what happens.)

Let us go to the second example. Suppose, for instance, you are searching your own
domain for referrals objects or DSA objects. The (objectClass=crossRef) or (cn=NTDS
Settings) filter strings, respectively, can be used for this purpose. The domain DN is
specified as the base of the search.

Without the Chase referrals box checked, you will get an empty result set. Maybe
you have forgotten, or did not initially know, that required objects are stored in the
Configuration namespace (directory partition). Furthermore, remember that the
search is performed in one namespace only unless you enable generating referrals.
The above-described search operation will be successful if you have done one of the
following: either directly specified the appropriate name context as the base of the
search or enabled generation of referrals.

If the Chase referrals box is checked, the search is performed:

ƒ Within all partitions stored on a server

ƒ Within the domain partitions of all child domains, to which the referrals are
directed

(There are also other search options, but it is more difficult to configure them. You
can find additional information in the MSDN Library — look for "Extended Controls".)

Turning to the first example, it is clear now that if a server finds an object that refers
to another domain and cannot (is not allowed to) connect to the server that stores the
corresponding partition, it will generate a referral error message.

Note The problem of cross-domain (cross-partition, and cross-tree) searching can

also be resolved by using a connection over the Global Catalog (3268) port.
This might even be a more appropriate way. Do not forget, however, that not all
attributes are replicated to GC.
Paged Search

Sometimes, a requested server can return a number of rows that exceed the
MaxPageSize value. (Do not confuse the number of rows returned by a server on a
request and the number of rows that the tool can display in the result pane — the
Number of lines parameter.) The following error will be reported:

Error: Search: Size Limit

Exceeded. <4> Result <4>: [null]

In such a case, it is necessary to use paging search results. You can request the
results in pages of a specific size. Open the Search Options window (see Fig. 12.12;
left) and select the Paged switch in the Search Call Type group. The Page size
value defines the length of the page. Now you will get the results of a search
operation in 16- row pages (by default):

Result <0>: Matched DNs:

Getting 16 entries: ... -=>> 'Run' for more, 'Close' to abandon
<<=-

Fig. 12.12: Configuring the search options for deleted objects

You can continue searching by clicking Run, or you can terminate the operation at
any moment. When paging is used, you need not worry about how long the result of
a search is.

Retrieving Information about Errors

The Windows .NET version of Ldp.exe has a new option that allows you to obtain
additional information about some LDAP operation errors. Suppose you try to
connect to a DC and see the following messages:

1d =
ldap_open("netdc2.net.dom", 389); Error <0x51>: Fail to
connect to
netdc2.net.dom.

If you select the GetLastError command in the Browse menu, the tool will display the
message:

0x51=LdapGetLastError ()
Server Down
Sometimes this additional information can be valuable for understanding an error that
has occurred.

Saving Results

To clear the result pane before a new operation, click New on the Connection menu
or press <Ctrl>+<N+ keys. Any information displayed in this pane can be copied-
and-pasted.

At any moment, you may save the contents of the result pane by selecting Save or
Save As from the Connection menu. (You need not close the Search window.) The
latter option always asks you for a file name. The former option allows you to save
information in the current output file, and asks for a file name only after the tool starts
or a New command has been performed.

The Forest View

You may look up all domains and DCs in the forest in tree form. Click Enterprise
Configuration in the View menu. Click Refresh in the window that is open. After
some time, the actual configuration of your enterprise will be displayed in the window
(Fig. 12.10). You can get the configuration only after binding to a DC.

Fig. 12.10: In this window, you can see the entire domain structure (the forest) and
the state of all DCs

As Fig. 12.10 shows, two DCs (NETDC2, NETDC3) in the forest are online, and one
DC (NETDC1) is offline. Knowledge of the network's real state will help you to select
servers for connecting and making queries.
Searching Directory

For clarity and simplicity, we will discuss the procedure involved in finding objects in
Active Directory (or any other LDAP-compatible directory) using a few specific
scenarios.

Note Remember that every DC in a domain stores, at minimum, three Active

Directory partitions (see the RootDSE object's information when a connection is
established). Although these partitions (including application partitions) have
contiguous DNS names — and this may seem a little confusing — they are
absolutely different namespaces when it comes to performing a search.

Example 1. Finding Deleted Objects

Deleted Active Directory objects (so called tombstones) are stored in a hidden
Deleted Objects container for a pre-configured period of time, and then permanently
purged during garbage collection. This container cannot be accessed by using
standard snap-ins. The Show Deleted Object control (controlType =
1.2.840.113556.1.4.417) and search command allow you to retrieve the tombstones.
(You must have administrative privileges.)

Start Ldp.exe and carry out the following operations:

1. Connect to a DC, and bind to it using the credentials of an administrator.

2. Click Search in the Browse menu, and enter the distinguished name of the
domain and the filter string (isDeleted=*). Select the Subtree switch and click
Options (Fig. 12.11).

Fig. 12.11: Primary search parameters

3. Click Extended in the Search Call Type group, and enter the attributes of the
deleted objects that you wish to view (see Fig. 12.12, left). (You may also
need to increase the default Timeout (s) from zero to a bigger number. The
value can be determined by experimenting.) Click Controls.

Note If you receive the following error message, increase the timeout value:

Error: Search: Timeout.

<85> Error<94>: ldap_parse_result failed:
No result present in
message Getting 0 entries:
 4. You can enter the type of the control directly into the Object Identifier field
and click Check in (make sure that the Server switch in the Control Type
group is selected), or simply select the Return deleted objects option in the
Load Predefined list (see Fig. 12.12, right). To delete (deactivate) a control,
select it in the Active Controls window and click Check Out.

Note You can combine a number of various controls in the same query.

To view and activate/deactivate the controls, you can open the Controls
window at any moment by clicking Controls in the Options menu.

5. Close the Controls and Search Options windows.

6. Click Run and execute the search.

Example 2. Searching for Object GUIDs

As you know, the name (e.g., the cn attribute) of a directory object can be changed
by a rename object operation. If, for instance, an application uses the name for
referring to the object, it will "lose" this object after its renaming. A more appropriate
way would be to use the object GUID, which remains the same throughout the entire
lifetime of the object.

The question is thus how to find the object GUID. You might search the directory for
the object and specify the objectGUID attribute in the Search Options window.
However, it is possible to get the GUID of each object found in a search operation
immediately or to get it while browsing the directory tree. You need to activate the
Return Extended Distinguished Names LDAP control (controlType = =
1.2.840.113556.1.4.529).

Note It is also possible to get the GUID of an object by using the ADSI Edit snap-in.
However, that may be inconvenient, since the objectGUID attribute (as well as
objectSID) is in Octet-String format (e.g., "0x73 0xa5 0xe1 0xdd …" — 16 bytes
in all). You cannot directly substitute such a string in a search or bind
command. The Dsquery.exe utility would be a better choice.

The GUID search preparation steps are similar to those for deleted objects described
above. Let us find the GUIDs of the OUs that are contained in a domain. Enter the
following information:

ƒ Base DN — domain DN
ƒ Filter — (ou=*)
ƒ Subtree scope
ƒ Search Call Type —Extended
ƒ Attributes — ADsPath
ƒ Active Controls — 1.2.840.113556.1.4.529 (the Extended DN option in the
Load Predefined list)

You will get a list of OUs in a format similar to the following:

Dn:
 <GUID=079760441fb9d948afdeacab994997cb>;
OU=Domain Controllers, DC=net, DC=dom

The new component (marked here in bold) appears in the distinguished name. The
found GUID can be verified by using Search.vbs (see "Searching for an Object using
its GUID" at the beginning of this chapter), or you may use the entire string (between
and including the angle brackets) in a script in a bind operation.

For directory objects that represent security principals (user, group, and computer
accounts) output strings also contain object SIDs, for example:

Dn:
<GUID=a6ead32063e11a40924e57f9107a14ec>;

<SID=0105000000000005150000002fd5ec6ddde8e41c8aa7323feb030000>;
CN=NETDC1, OU=Domain Controllers, DC=net, DC=dom

Example 3. Sorting Search Results

You might notice that the result sets of search operations contain rows in a quite
random order. To obtain sorted results, you can use the Return Sorted Results LDAP
control (controlType = 1.2.840.113556.1.4.473). To obtain sorted results in any
search operations, perform the following steps:

1. Add the "1.2.840.113556.1.4.473" value to the Active Controls list (see Fig.
12.12; right).
2. Click Options | Sort Keys.
3. In the Sort Keys window (Fig. 12.13), enter OID of a sort key in the Attribute
Type field and click Check In and OK. You can obtain the attribute's OID
using the Active Directory Schema Manager snap-in. The name attribute
(1.2.840.113556.1.4.1) has been selected in our example.

Fig. 12.13: Sorting search results on the name attribute

4. Select all search parameters and click Extended in the Search Call Type
group in the Search Options window (see Fig. 12.12; left).
After all this, any search operations will produce sorted result sets unless the select
Sync in the Search Call Type group or delete the Return Sorted Results control from
the list of LDAP controls.

Updating Attributes

The LDAP update operations include the following: Add, Modify, Modify RDN, and
Delete. On the one hand (regarding the user interface), they are quite simple and
obvious; on the other hand, they require a rather keen understanding of Active
Directory architecture (particularly the schema, classes, and attributes). That is why
other tools, such as administrative snap-ins (ADSI Edit, Active Directory Users and
Computers, and so on), are more suitable for modifying Active Directory objects. In
an example below, we will discuss the most common steps involved in using Ldp.exe
for this purpose.

Note The Modify RDN operation is equivalent to renaming or moving an object. The
Cross Domain Move LDAP control (1.2.840.113556.1.4.521) enables you to
perform move operations over domain boundaries.

Modifying an Attribute

Let us change a user's UPN. First, click Modify in the Browse menu. In the opened
window, enter the user's DN, the attribute name, and its new value. Then select
Replace from the Operation group (because the attribute already exists), and click
Enter to add the data to the Entry List. No checks are performed at this time, so be
careful. You may correct the entered data by clicking Edit (and then editing the
information) or Remove. A sample window is shown in Fig. 12.14.

Fig. 12.14: The information necessary to change the UPN of a user

When everything is ready, click Run. The server will verify all entered data (syntax
rules, acceptable values, etc.), and perform the operation if all requirements have
been met. The result message may be similar to the following:

***Call
Modify... ldap_modify_s(ld, 'CN=John Smith, OU=Staff,
DC=net, DC=dom', [1]
attrs); Modified "CN=John Smith, OU=Staff, DC=net,
DC=dom".

If an error occurs while at some step of executing an operation, the tool reports an
error message, which is determined by the kind of error (such as a syntax error in the
entered data, or an error with the directory database, etc.). The message contains a
description of the error.

For example:

***Call
Modify... ldap_modify_s(ld, 'CN=John Smith, OU=Staff,
DC=net, DC=dom', [1]
attrs); Error: Modify: No Such Object. <32>

Deleting Objects

The delete operation is also fairly obvious and simple. However, a problem may arise
when you want to delete an object that has one or more child objects, for example,
an OU with user accounts. The following error may be reported:

Error: Delete: Not allowed on

Non-leaf. <66>

To perform such an operation, you must use the Tree Delete LDAP control
(controlType = 1.2.840.113556.1.4.805). This control allows you to delete an entire
subtree, if you have sufficient permissions.

To delete a non-leaf object (i.e., a container), perform the following operations:

1. Add the Tree Delete control to the list of active controls (select the Subtree
Delete option in the Load Predefined list — see Fig. 12.12; right).
2. Click Delete in the Browse menu.
3. In the Delete window, enter the distinguished name of the container and check
the Extended box. (An example window is shown in Fig. 12.15.)
 Fig. 12.15: Deleting a non-empty container (an OU in this case)

4. Click OK.

Caution Be extremely careful when deleting an entire container! No warnings are

generated.

Viewing the Security Descriptors

Ldp.exe allows you to view the security descriptor of any directory object. This
feature is intended for solving problems related to the accounts' permissions on
directory objects (e.g., when moving the security principals to another domain) and
can be especially useful when you are debugging scripts or applications that work
with security descriptors (see Chapter 17, "Scripting Administrative Tasks"). Using
this feature requires a sound understanding of the Active Directory security model
(access control lists (ACL) and access control elements (ACE), their inheritance,
etc.).

To view the security descriptor for a directory object, select the Security | Security
Descriptor command from the Browse menu and specify the distinguished name of
the object. If you want to see the directly specified or inherited audit settings (the
system ACLs) of this object, check the SACL box. A sample output produced by this
command is shown in Fig. 12.16. The command also displays the descriptor in the
SDDL (Security Descriptor Definition Language) string format (not shown in the
figure). As Fig. 12.16 shows, you can see all the information about the descriptor
(some of its elements are circled in the figure). That information includes, in
particular, control flags, the owner of the object, the number of ACEs, and elements
of each ACE, such as the ACE's type, the access mask, and the name and SID of
the security principal that was granted this right. You can retrieve all described
information from a descriptor by using a script (Chapter 17, "Scripting Administrative
Tasks", contains an example of such a script). You can also programmatically
manipulate the ACEs, i.e., grant or revoke permissions on directory objects.
Fig. 12.16: A fragment of a security descriptor shown by using Ldp.exe

Viewing Replication Metadata

Ldp.exe can display the directory object's metadata information (the replProperty-
MetaData attribute) that is used in replication. You can also view this information by
using the RepAdmin.exe command with the /showmeta parameter (see Chapter 11,
"Verifying Network and Distributed Services").

To view the metadata for an object, select the Replication | View Metadata
command from the Browse menu and enter the object's distinguished name. A
sample output is presented in Fig. 12.17.

Fig. 12.17: Viewing the replication metadata for a directory object

When troubleshooting replication issues, you can connect to various domain

controllers and compare the metadata for the stored replicas of the desired object.

Windows .NET Search and Modification Tools

Windows .NET-based domain controllers have a set of very useful and powerful
utilities that help administrators perform a number of operations with Active Directory
objects from the command prompt. In addition, these utilities can be used for batch
operations. For that purpose the results from a query command can be piped as input
to one of the other commands.

All these utilities (listed below) use the LDAP protocol and can query both Windows
2000 and Windows .NET domains. However, they can run on Windows XP/.NET-
based computers only.

There are a huge number of parameters of every utility, and you can view their
description in the Help and Support Center or in the built-in help feature. Do not
forget to use quotation marks around a parameter's string value.

DsQuery and DsGet

The DsQuery.exe utility can find directory objects of any type or objects of a specific
type. The DsGet.exe utility displays the specified attributes (a limited set of attributes)
of specific type objects. These specific types are:

computer contact subnet

group OU site
server user

For example, the following command displays ADsPaths and GUIDs of the user
accounts in the User container:

C:\>dsquery * CN=Users, DC=net, DC=dom

-filter objectClass=user
-attr ADsPath objectGUID

The most universal dsquery * command can find objects of any type and display any
attributes of these objects.

To find all users in the domain, use the command:

C:\>dsquery user

The following two commands display the first and last names of all users in the
domain:

C:>dsquery user | dsget user -fn -ln

The base and scope of search operations can be specified as domainroot (default
option), forestroot

Renaming of an object:

C:\>dsmove CN=Sam, OU=Staff, DC=net, DC=dom -newname Samuel dsmove succeeded:

CN=Sam, OU=Staff,
DC=net, DC=dom
DsRm

The DsRm.exe utility deletes one or more directory objects. You can also delete an
entire object subtree.

The following command immediately (without any prompt) removes all child objects in
the Staff OU, but keeps (do not delete) the OU object itself:

C:\>dsrm OU=Staff, DC=net, DC=dom

-noprompt -subtree -exclude dsrm succeeded:
OU=Staff, DC=net, DC=dom

Importing and Exporting Modifying Directory Objects

By default, every Windows 2000- or Windows .NET-based domain controller contains

two utilities installed — LDIF Directory Exchange (LDIFDE.exe) and CSV Directory
Exchange (CSVDE.exe) — that are primarily intended for bulk operations. Unlike Ds*
family tools (DsQuery.exe, DsAdd.exe, DsMod.exe, etc.), these utilities can save
results in a file for consequent operations and read data from a file. You can use
these utilities to:

ƒ Export Active Directory information to a text file (in LDIF or CSV format) that
can be easily viewed or/and edited. The retrieved information can be used for:
ƒ Composing documentation on directory objects
ƒ Performing bulk editing operations that cannot be carried out using the
standard administrative snap-ins
ƒ Creating templates for new users (if the standard option of copying user
accounts is not convenient for you)
ƒ Migrating directory objects between domains into the same or another
domain forest
ƒ Backing up the existing domain configuration (for safety or for re-
installation of domain controllers)
ƒ Import Active Directory information from a file. This means creating new
objects or modifying the attributes of existing ones in batch mode. Besides the
already mentioned export operations that imply import — bulk editing,
migrating, backing up, and creating user templates — the import into Active
Directory can be carried out for:
ƒ Deploying a pre-configured domain configuration (by the way, import is
performed when a domain controller is promoted — the CSVDE utility is
used for creating the "default" Active Directory structure)
ƒ Deploying Active Directory-based applications (extending the schema is
also possible)

Note Normally, the standard Backup utility is used for backing up and
restoring Active Directory. However, in some cases, export/import may
be a preferable choice for preserving domain configuration.

You can select either of these utilities for your tasks so long as you keep in mind the
two main differences between LDIFDE and CSVDE for a user.
 ƒ Data format — LDIFDE uses files that respond to the LDIF standard, whereas
CSVDE supports the CSV format (see the appropriate section on each tool).
ƒ Possible operations — CSVDE can only export and import (create) data;
LDIFDE also allows you to modify attributes and delete objects.

The book contains a few examples of how to use LDIFDE and CSVDE. These
examples can be tested with either utility, depending on your specific requirements.

All of the tasks listed can also be fulfilled (and often, more effectively!) with custom
ADSI scripts. Knowing the possibilities and restrictions of all the tools permits you to
save time and select the appropriate tool for a specific task.

Basic information on the LDIFDE and CSVDE utilities is contained in the Help and
Support Center (search for "LDIFDE CSVDE"). (The -u parameter is missing in the
Help!) You can also run the utilities without parameters and get help information.

Error Logs Both utilities create an error log file (csvde.err or ldif.err) and a log for
completed operations (csvde.log or ldif.log). By default, these files are
stored in the current folder, and the logs' location is configured.

Parameters

Table 12.1 lists some of the most frequently used parameters of both utilities –
LDIFDE and CSVDE.

Table 12.1: Some Parameters of the LDIFDE and CSVDE Utilities

Meaning (or value) if the
Parameter Description and comments parameter is
omitted(default)

Common parameters
−f Input or output filename. "−f con" can be used No
for output to the console. Required parameter
−s DC name The name of the DC the
user is currently logged on
to
−t Port number. The Global Catalog port (3268) 389 (LDAP)
can also be used
−u Use Unicode format ANSI format is used

Parameters for export operations

−d Search base Domain naming context
−c Replace all occurrences of string 1 with string 2. No
Very helpful for copying data from one domain
to another
 Table 12.1: Some Parameters of the LDIFDE and CSVDE Utilities
Meaning (or value) if the
Parameter Description and comments parameter is
omitted(default)

−r Search filter (objectClass=*)

−p Search scope Subtree
−l Selection. A list of attributes. "1.1" or empty All attributes
string can be used with the meaning of "no
attributes returned" (if you need only a list of
objects)
−o The list of attributes omitted during an export No
operation

Parameters for import operations

−i Specifies import mode Export mode
−k Skip errors. If some objects were successfully No
imported to the directory and others weren't,
you may correct errors in the import file and
continue its processing

Note Do not forget about the omitted parameters (which have default values), or you
may obtain an undesirable or unpredictable result. Compare, for example,
cases when you only want to export OU objects and when you need to export
an entire OU subtree (default).

Exporting and Re-Importing Objects

Export operations are usually successful. (The worst-case scenario is when an export
file does not contain all the objects you expect it to contain.) You need only take into
consideration the following: when you specify a list of attributes (by using the −l
parameter) in the export command, LDIFDE and CSVDE do not include any
information about non-defined attributes in the output file. Therefore, you might need
to manually include the attributes' names (if you need them) in the import file and as-
sign the appropriate values.

Note It is not possible to export security descriptors (or group policies — for domains
and/or OUs). You must also be careful about built-in and default groups, such
as Domain Users.

In the exported file, you may see a list of members different from the one that
the Active Directory Users and Computers snap-in displays.

The (givenName=*) filter allows you to choose only accounts of newly created
users, with the exception of built-in accounts. Built-in users (administrator,
guest, etc.) do not have given names.

While exporting information from Global Catalog (using the 3268 port), do not
 forget that GC contains a restricted set of attributes. For example, 40-50
attributes (a very modest value, since the minimum is about 30 attributes and
maximum is about two hundred) are exported for a user object by default.
When GC is used, only 20-30 attributes are exported.

The number and type of the objects exported depend on a combination of the search
base and the LDAP filter (described in detail in Chapter 1, "LDAP Basics"). You can
export either a single directory object or all Active Directory objects. The choice of the
appropriate search base and filter is not a challenge unless you do not use both or
you have forgotten about the default values. The following two commands might
seem equivalent since either can export a computer account (provided that the
computer's cn attribute has a unique value in the domain):

ldifde -f Export. ldf -d "CN=Comp1, OU=Staff, DC=net, DC=dom"

ldifde -f Export.ldf -r "(&(objectCategory=computer) (cn=Comp1))

In fact, the first command can export a few objects, and the second exports strictly
one object. In both cases, the omitted −p parameter (the scope of the search) means
that the search will be conducted in the subtree. Since the computer object is a
container and can have child objects, the first command exports the entire "family".
The second command finds the specified computer in the domain and exports it
alone (since there is no computer with such a name in the domain).

After a little practice with search base and filters, you will learn how select only the
necessary objects from Active Directory in the most effective and precise way. (See
more examples of command string in this chapter.)

Note I prefer to specify objectCategory in filters rather than objectClass. Both

attributes are replicated in Global Catalog. However, the former attribute is
indexed, and the latter is not. As a result, filters with objectCategory are more
effective.

There is, however, a pitfall to such an approach. (objectCategory=Person) defines

users as well as contacts. Consequently, you need to add the objectClass
attribute in the filter. Test your filters carefully before using them in real
conditions.

Errors are more frequent when import operations are performed. There are three
main sources of errors.

ƒ Read-only attributes, which only the system can change. A typical error
message: ‘Unwilling To Perform. The server side error is "Access to the
attribute is not permitted because the attribute is owned by the Security
Accounts Manager (SAM)."’ You cannot include such attributes as objectSID,
objectGUID, etc., in the import files and must always use the −m parameter
while exporting objects if a consequent import is planned. When the −m
parameter is specified, all of the SAM attributes are ignored (see also
"Working with User Objects" later in this chapter).
ƒ Missed mandatory attributes. Refer to Table 12.2 to see which attributes must
be defined in import files when new directory objects are created. The
 objectSID attribute is shown in bold to remind you that, notwithstanding the
fact that it is a mandatory attribute, it must not be used in import.

Table 12.2: Some Important Object Classes and Their Mandatory Attributes
Object class (category) Mandatory attributes

computer (Computer) cn, instanceType, objectCategory, objectClass,

objectSIDsA-MAccountName
group (Group) cn, group Type, instanceType, objectCategory,
objectClass, objectSID, sAMAccountName
organizationalUnit instanceType, objectCategory, objectClass, ou
(Organizational-Unit)
printQueue (Print- cn, instanceType, objectCategory, objectClass,
Queue) printerName, serverName, shortServerName,
uNCName, versionNumber
user (Person) cn, instanceType, objectCategory, objectClass,
objectSID, sAMAccountName
volume (Volume) cn, instanceType, objectCategory, objectClass,
uNCName

ƒ Violations of syntax rules, inconsistency of attribute values, values of wrong

types, or values out of range. For example, using the −c parameter may result
in incorrect values of naming attributes (see later in the chapter). If you are
creating new objects from scratch, carefully verify attribute types and values,
and refer to the abstract schema and schema container if needed (see also
the schema description in Chapter 16, "Active Directory Service Interfaces
(ADSI)").

When directory objects are copied (exported and imported) from one domain to
another, it is helpful to use the −c parameter.

Unicode Support

LDFIDE and CSVDE have some problems with support of Unicode (namely, with
non-Latin localized string values). You should take this into consideration if non-Latin
values are stored in your Active Directory. Test your installation before starting the
bulk import/export operations. Since such values aren't written in the output file in
plain text format, it is hard to edit them. Encoding restrictions of the utilities are listed
below.

LDIFDE

ƒ Unless the −u parameter is specified, LDIFDE exports non-Latin Unicode

values as Base64-encoded (e.g., cn:: 0JLQsNGB0Y=). (Notice that the colon
character is doubled in such lines. Binary values are always encoded.) If non-
 Latin characters are included in the distinguished name of a directory object,
the entire line (dn) name is coded. You can safely reimport all these values.
ƒ LDIFDE correctly imports non-Latin string values in an input file if only this file
is saved as Unicode-encoded. Use common format with one colon!

CSVDE

ƒ Regardless of the presence of the −u parameter, CSVDE exports non-Latin

Unicode (and binary) values (except for dn) in the following format:
X'8c39…c3bc'. You can safely reimport these values. CSVDE fails to export
directory objects that have non-Latin characters in their names if the −u
parameter has been omitted.
ƒ CSVDE imports the non-Latin string values in an input file (in usual format) if
this file is saved both as Unicode- and ANSI-encoded. Windows 2000-version
of CSVDE accepts only Unicode-encoded files.

LDIF Directory Exchange Utility (LDIFDE) (Sys)

LDIFDE, a command-line utility that is installed by default on every DC, can be used
for adding, modifying, renaming, and deleting directory objects. This utility uses
LDAP Data Interchange Format (LDIF) — an Internet standard that defines a file
format to perform batch operations for LDAP-accessible directories. LDIFDE is also a
preferred tool for extending the Active Directory schema.

Examples of LDIF files are shown below. LDIFDE can be run on any Windows
2000/XP/.NET-based client, provided you have supplied appropriate domain
credentials.

Working with User Objects

Table 12.3 is a snippet of an export file and lists all attributes of an exported user
object in LDIF format. Notice attributes in bold face, which are not exported when the
−m parameter is specified, and should not be imported. Notice also that the
objectGUID and objectSID are exported as binary values (this is marked with a
double colon). A few additional remarks are placed at the end of the table. These are
not all of the possible attributes, only a typical minimal set. The names of some
attributes as they are presented in the Active Directory Users and Computers
snap-in's UI are specified in bold square brackets. The relative DN (RDN) is also
specified, although it is not presented in the UI and cannot be directly modified. The
mandatory attributes are show in italics.

Table 12.3: Influence of −m Parameter on the Resulting Attribute List

Exported attributes and their values

dn:
CN=John Smith, OU=Staff, DC=net,
DC=dom changetype: add accountExpires:
 Table 12.3: Influence of −m Parameter on the Resulting Attribute List
Exported attributes and their values

9223372036854775807
badPasswordTime: 0
badPwdCount: 0
[**]
cn: John Smith codePage: 0
countryCode: 0 displayName: John
Smith [Display
name] distinguishedName: CN=John
Smith, OU=Staff, DC=net, DC=dom
givenName: John [First name]
homeDirectory:
\\netdc1\UsersData\jsmith homeDrive:
W:
[**]
instanceType: 4
lastLogoff: 0 lastLogon: 0
logonCount: 0 memberOf:
CN=Account Operators, CN=Builtin,
DC=net, DC=dom memberOf: CN=Server Operators, CN=Builtin, DC=net,
DC=dom name: John Smith
[**]
objectCategory: CN=Person,
CN=Schema, CN=Configuration,
DC=net, DC=dom
[*]
objectClass:
organizationalPerson [*]objectClass:
person
[*]
objectClass: top
[*]
objectClass: user
objectGUID::
pME9k/0HNk+lz9/kJBpp3g==
[**]
objectSid::

AQUAAAAAAAVAAAAL9Xsbd3o5ByKpzI/UgQAAA== primaryGroupID: 513 profilePath:

\\netdc1\Profiles\jsmith pwdLastSet:
126609470367623296
[*]
sAMAccountName: JSmith
[User logon name (pre-Windows
2000]
sAMAccountType: 805306368
scriptPath:
Users\Logons.vbs sn: Smith [Last
name]
[***]
userAccountControl: 512
userPrincipalName: JSmith@net [User
logon
name]
[****]
uSNChanged: 5950
[****]
uSNCreated: 4194
[****]
whenChanged:
20020320164127.0Z [****]whenCreated:
20020318174356.0Z

[**]
these attributes are mandatory for a user object, but are not required for an import
operation since the system itself creates the corresponding values.
[*]
these attributes are required for importing (creating) objects. To create a new user,
 Table 12.3: Influence of −m Parameter on the Resulting Attribute List
Exported attributes and their values

it is sufficient to specify the objectClass and sAMAccountName attributes. Other

objects will require some additional attributes (see Table 12.2).
[***]
if this string is included in an import file, the new user will have to change his or her
password at first logon; otherwise the new account will be disabled.
[****]
these attributes are exported, too, with the −m parameter, but it makes absolutely
no sense to import them.

Here is a sample command string that allows you to export the specified attributes of
all users (except for built-in accounts) from your current domain:

ldifde -f
ExportedUSERs.ldf -r
"(&(objectCategory=Person) (objectClass=user)
(givenName=*))" -l
"cn, givenName, objectClass, sAMAccountName"

Working with Container Objects (Domains and OUs)

When working with container objects, you must always remember that the
combination of the search base and the LDAP filter defines the result of the
operation: either you export only container objects of the specified type, or you export
an entire container.

Compare, for example, the following two commands. The first command exports all
OU objects from the current domain (remember the default values for the omitted −l,
−d, and −p parameters):

ldifde -f ExportedOUs.ldf -r "objectCategory=OrganizationalUnit" -v

The second command exports an entire subtree, i.e., all objects (of any type), from
the specified OU:

ldifde
-f ExportedOU.ldf -d "OU=Staff,
DC=net, DC=dom" -v

Extending the Schema

LDIFDE is the tool recommended by Microsoft for extending the schema (however,
using CSVDE is also possible). (The requirements of the schema extension are
described in Chapter 16, "Active Directory Service Interfaces (ADSI).") Remember
that you must generate the base OID for your own attributes and classes before
executing a similar command. The following is an example of an LDIF import file,
which creates a string attribute with stringAttribute LDAP display name:
dn:
CN=String Attribute, CN=Schema, CN=Configuration, DC=net,
DC=dom changetype: add attributeID: 1.2.840.113556.1.4. ... .1
attributeSyntax:
2.5.5.12 cn: String Attribute isSingleValued: TRUE objectCategory:
CN=Attribute-Schema, CN=Schema, CN=Configuration, DC=net,
DC=dom objectClass:
attributeSchema oMSyntax: 64

A successful command output is similar to the following (netdc1.net.dom is the name of

the DC that is the schema master):

C:\>ldifde -i -f AddStrAttr.ldf Connecting to

"netdc1.net.dom" Logging in as current user using SSPI Importing
directory from file
"AddStrAttr.ldf" Loading entries.. 1 entry modified successfully.
The command has completed successfully

Modifying Attribute Values. Deleting Objects

Only the LDIFDE utility can be used for batch modifying Active Directory objects from
a command file. (Remember also the DsMod.exe utility!) To change (or set) one or
more attribute values of an object (or a number of objects) use the following
procedure:

1. Export the necessary object(s) to a file. Use the appropriate filters. You may
export all attributes or specific ones only. This step is optional — you may
create the import file manually from scratch.
2. Edit the export file. Delete the entries for unnecessary (unchanged) attributes.
Change changetype from add to modify. Replace each attribute entry with the
following lines:
3. replace: <attributeName> <attributeName>:
<newValue>

If the second line is omitted, the attribute value will be cleared. The "−" (minus)
character must follow the lines for each attribute (including the last one). An
empty line must precede each attribute's distinguished name (excluding the
first one). Let us illustrate these requirements with an example. The sample
import file is used for modifying attributes of two user objects (the comments in
bold square brackets are not really included in the file!).

dn: CN=user3, OU=Staff,

DC=net, DC=dom changetype: modify
replace: description description: A test user
- replace: scriptPath scriptPath:
Users\Logons.vbs - [This empty line is
mandatory] dn: CN=user4, OU=Staff, DC=net, DC=dom
changetype: modify replace: description
description: A user - [All "-" characters are
mandatory]

4. Import the edited file. The import is performed until the first error, but you can
safely repeat it as many times as you wish while correcting errors.
By modifying attribute values, you can also change membership in a group(s). To
add a user to a group, use lines similar to the following:

dn: CN=GroupName, OU=Staff,

DC=net, DC=dom changetype: modify
replace: member member: CN=user2, OU=Staff,
DC=net, DC=dom
Note If LDIFDE.exe does not meet your specific needs, write a custom script (see
Chapter 17, "Scripting Administrative Tasks"). This (if you are familiar with ADSI
scripting) will not take more time than editing a file. In addition, the scripts are
much more flexible as well as reusable. For example, you need to re-do the
export and/or edit the export-import file each time a user is added (deleted),
whereas the same script can modify the specified attributes for any number of
users in a container.

To delete a leaf object, it is sufficient to include the following two lines into the import
file:

dn: CN=user2, OU=Staff, DC=net,

DC=dom changetype: delete

You cannot delete a container if it has child objects. The LDAP protocol, actually,
allows you to delete a subtree (see the Ldp.exe tool description earlier in this
chapter), but LDIFDE does not permit one to perform such an operation.

CSV Directory Exchange Utility (Sys)

CSVDE uses the Comma-Separated Value (CSV) file format (with a .csv extension).
Files in this format can easily be viewed (imported) or prepared (edited and exported)
by using various applications, including Microsoft Excel. The first line in such files
contains the names of attributes, separated by a comma. The next lines contain the
values of attributes, one line per object. An example of such a file is shown in the
next section.

Working with Unicode String Values

Let us discuss the problem of Unicode support in an example with the CSVDE utility.
The following command exports the minimal set of OUs' attributes that allow you to
import the OU structure to another domain:

csvde -f ExportedOUs.csv -r "(objectCategory=OrganizationalUnit)" -1

"objectClass, ou" -v -u

Note If all attributes are to be exported (no −l parameter used), add the −m parameter
to the command.

On the screen, the command produces an output (thanks to the verbose mode)
similar to the following:

Connecting to "(null)" Logging

in as current user using SSPI Exporting directory to file
ExportedOUs.csv
 Searching for entries ... Writing out entries Exporting entry:
"OU=Domain
Controllers, DC=net, DC=dom" ... Exporting entry: "OU=∏epcoHaΠ,
DC=net,
DC=dom" Export Completed. Post-processing in progress... 7 entries
exported The
command has completed successfully

Notice the non-Latin string in an OU's name (OU=∏epcoHaΠ,…). If the −u parameter

has not been specified, the command results in an error (which is also written to the
csv.err file):

Error writing
to file. This error happens when the entry cannot be written, it can be
caused
by writing a Unicode value to a non-unicode file. An error has occurred
in the
program

Here is the exported CSV-file produced by the command (the first line contains the
attributes' names):

DN,
objectClass, ou "OU=Domain Controllers, DC=net, DC=dom",
organizationalUnit,
Domain Controllers ... "OU=OU=∏epcoHaΠ, DC=net, DC=dom",
organizationalUnit,
X'd09fd0b5d180d18 1d0bed0bdd0b0d0bb'

Notice that the last line contains a coded value for the ou attribute.

Caution If you create an import file with non-Latin Unicode values from scratch, do
not forget to save it in Unicode format (not in ANSI) and use the -u parameter
when importing the file.

Exporting Information for Successive Import

As mentioned before, some attributes that are present or incorrectly (inconsistently)

specified in an import file may cause an error. Here are two frequently encountered
errors that are reported on in import operations:

Add error on
line 2: Unwilling To Perform The server side error is "The modification
was not
permitted for security reasons." 0 entries modified successfully. An
error has
occurred in the program

The following error specifies that you want to import an attribute(s) that only the
system can change:

Add error on
line 3: Constraint Violation The server side error is "Access to the
attribute
 is not permitted because the attribute is owned by the Security
Accounts
Manager (SAM)."

If you encounter such an error, use the −m parameter for export, and if the error still
exists, check the import file for consistency. Try to get rid of "unnecessary" attributes
when doing export. Let us look at a situation where you yourself produce a critical
error by using the −c parameter.

The scenario is the following. Suppose that you want to copy an entire OU from one
domain (net.dom) to another (subdom.net.dom) and rename the OU at the same
time. You use the −c OU=Personnel OU=Staff, DC=subdom parameter to change the
source DN OU=Personnel,DC=net,DC=dom to the destination DN
OU=Staff,DC=subdom,DC=net,DC=dom. The problem is that the ou attribute will not
be changed by such a replace operation, and will remain the same. As a result, an
inconsistency in the dn and ou attributes has occurred. You can only solve the
problem by omitting the ou attribute when exporting. The sIDHistory attribute
presented in the import file will also prevent you from successfully importing. The
following command meets all requirements and may perform the desired action:

csvde -f Subtree.csv -d
OU=Personnel,DC=net,DC=dom -c OU=Personnel
OU=Staff,DC=subdom -o ou, sidhistory -m -v

If the OU being copied contains computer accounts, you can copy them by using the
following command (or add the primaryGroupID attribute in the list of omitted
attributes in the previous command):

csvde -f Comp.csv -d OU=Personnel,DC=net,DC=dom -r

"objectCategory=Computer" -c
OU=Personnel OU=Staff, DC=subdom -o primaryGroupID -m -v
Caution Note that the memberOf attribute is not exported, so you may need to verify
(and reestablish) all group memberships of the imported accounts. To add
users to a group(s), you can use the AddUsers.exe command from Windows
2000 Resource Kit or Windows .NET system utility DsMod.exe (see Chapter
8, "Common Administrative Tasks").

Windows Domain Manager (NetDom.exe) (ST)

Windows Domain Manager is a command-line tool that has some unique features,
such as moving computer accounts between domains, as well as joining computers
to a domain and renaming domain controllers or computer accounts. The tool allows
you to:

ƒ Retrieve diverse information about domains

ƒ Add, join, and move computers to a domain (these operations are "OU-
aware"), as well as remove computers from a domain
ƒ Rename domain controllers and computers
ƒ Reset and verify computer secure channels
ƒ Verify, establish, reset, break, and change domain trusts (including Kerberos
trusts)
Caution Be careful, the documentation on this tool is slightly inconsistent. There are
quite a few divergences between parameters' description in the Support
Tools Help and the built-in help feature.

Windows .NET version of NetDom.exe cannot run on Windows 2000

systems.

Let us discuss some interesting features of NetDom.exe with some examples. To see
detailed information on how an operation is performed, you may use the /Verbose
parameter with any command. Many tool's commands accept the DNS name of
computers and domains, but sometimes the NetBIOS names are preferable.

Querying Domains

NetDom.exe is one of the tools that allow you to view FSMO roles' owners in the
forest. For example, the following command shows that the server NETDC2 holds all
roles in its domain, whereas all forest-wide roles are owned by the server NETDC4 in
the root domain:

C:\>netdom QUERY /D:subdom.net.dom FSMO Schema owner netdc1.net.dom Domain role owner
netdc1.net.dom PDC role netdc2.subdom.net.dom RID pool manager
netdc2.subdom.net.dom Infrastructure owner netdc2.subdom.net.dom The
command
completed successfully.

The following command displays all domains that have direct trusts with the specified
domain (the trusts may be also verified by using the netdom TRUST command; see
later); notice that the net.dom and NT4DOM domains are connected with a one-way
trust:

C:\>netdom QUERY /D:net.dom TRUST

/Direct Direction Trusted\Trusting domain Trust type =========
======================= ========== <-> subdom.net.dom Direct <-
NT4DOM
Direct <-> dotnet.dom Direct

The netdom QUERY command can also verify and/or reset (the /Reset parameter)
domain trusts. The following command checks trusts between the parent (current)
domain and a child (the command is executed in the parent domain; the credentials
of the child's administrator must be provided):

C:\>netdom QUERY /D:subdom.net.dom

TRUST /UD:administrator /PD:*
/Verify Type the password associated with the
domain user: Direction Trusted\Trusting domain Trust type Status =========
======================= ========== ====== <-> net.dom Direct Verified
The
command completed successfully.

When you delegate control over some OUs to a user (jsmith is our example), you
might want to quickly verify administrative power of that user (you must know the
user password). The following command may help you to do this task:
 C:\>netdom QUERY /D:net.dom
OU /UD:jsmith /PD:* Type the password
associated with the domain user: List of Organizational Units within which the
specified user can create a machine account: OU=Staff, DC=net, DC=dom
OU=Sales,
OU=Marketing, DC=net, DC=dom The command completed successfully.

Compare this output with the results received for an administrative account.

Managing Computer Accounts

The command shown below creates a computer account in the domain (but doesn't
join a computer to the domain). Note that you can specify a target OU for that
account. Remember that if you are working on a computer and join it to a domain
using a newly created account, this account by default is added to the Computer
container. You may use the command for pre-creating accounts in the necessary
OUs (domains) before actually joining the computers to the forest.

C:\>netdom ADD compName /D:net.dom

/OU:OU=Staff,DC=net,DC=dom The command completed successfully.

NetDom.exe can be used for migrating computer accounts from Windows NT

resource domains to an AD-based domain or between AD-based domains. All
commands - ADD, JOIN, MOVE, and REMOVE - are "OU-aware", so you can
manipulate accounts according to the OU structure of your domains.

To move a computer (compName in the example) from the current domain to a

destination domain (you must be logged on to the current domain as an administrator
and provide an administrator's credentials in the destination domain), use a
command similar to:

C:\>netdom MOVE compName /D:subdom.net.dom

/OU:OU=Personnel, DC=subdom, DC=net, DC=dom /UD:administrator /PD:*

Caution The computer being moved must be online and accessible, otherwise the
command generates the "The network path was not found" error.

Verifying and Resetting Secure Channels

NetDom.exe can verify and reset the secure channels that exist between each
computer in a domain and a domain controller. To verify that the computer COMP3
has an actual secure channel with its net.dom domain, it is possible to use the
following command (the command's output is also shown):

C:\>netdom VERIFY comp3.net.dom /D:net.dom

The secure channel from COMP3.NET.DOM to the domain NET.DOM has been
verified.
The connection is with the machine \\NETDC1.NET.DOM. The command
completed
successfully
The same operation can also be performed using the NLtest tool:

C:\>n1test /sc_query:net.dom
/server:comp3.net.dom Flags: 30 HAS_IP HAS_TIMESERV Trusted DC Name
\\netdc1.net.dom Trusted DC Connection Status Status = 0 0x0 NERR_Success
The
command completed successfully

To reset the broken secure channel, use the following command

C:\>netdom RESET comp3.net.dom /D:net.dom

The secure channel from COMP3.NET.DOM to the domain NET.DOM has been
reset. The
connection is with the machine \\NETDC1.NET.DOM. The command completed
successfully

The NLtest tool can also be used for that purpose:

C:\>n1test /sc_reset:net.dom /server:comp3.net.dom Flags: 30 HAS_IP HAS_TIMESERV

Trusted DC Name \\netdc1.net.dom Trusted DC Connection Status Status = 0
0x0
NERR_Success The command completed successfully

Managing Domain Trusts

NetDom.exe allows you to verify domain trusts issues (including those that use
Kerberos v5 authentication protocol). For example, the following command checks
the Kerberos trusts between two domains in the forest (both domain administrators'
credentials must be specified!):

C:\>netdom TRUST subdom.net.dom /D:net.dom

/Kerberos /UD:administrator /PD:*
/UO:administrator /PO:* /Verify Type the password associated with the domain
user:
Type the password associated with the object user: The trust between
subdom.net.dom and net.dom has been successfully verified The command
completed
successfully

To reset domain trusts, enter the command:

C:\>netdom TRUST subdom.net.dom /D:net.dom

/UD:administrator /PD:* /UO:administrator
/PO:* /Reset

Successful output should be similar to:

Resetting the
trust passwords between subdom.net.dom and net.dom The trust between
subdom.net.dom and net.dom has been successfully reset and verified The
command
completed successfully
If trust relationship issues exist, you can try to isolate the problem and use the netdom
VERIFY or n1test /sc_query commands to check trusts between pairs of domain
controllers.

Note For verifying and resetting trusts, the Active Directory Domains and Trusts
snap-in (see Chapter 7, "Domain Manipulation Tools") can also be used.

NetDom.exe allows you to remove information (including cross reference and trusted
domain objects) about a non-existing (defunct) domain, which doesn't contain domain
controllers, from Active Directory. The netdom TRUST /Remove /Force command can be
used for that purpose, for example:

netdom
TRUST dotnet.dom /D:net.dom
/Remove /Force

Chapter 13: Migration and Directory

Reorganization Tools
Overview

Moving Active Directory objects within a domain is a rather simple operation. You
only need to open the Active Directory Users and Computers snap-in, point to the
object, and select a target container for the Move operation. Moving objects between
domains is a more complicated task, requiring specific tools. When the domains
belong to different forests, then you should talk about migrating rather than moving
objects.

This chapter describes utilities that allow an administrator to reconfigure domains as

well as to migrate (copy) the user, group, and other directory objects from one AD-
based forest (or a Windows NT 4.0-based domain) to another forest:

ƒ MoveTree.exe moves the user, group, and OU objects within an AD-based

forest (intra-forest migration); the user accounts retain their passwords after
moving.
ƒ ClonePrincipal duplicates (clones) the user and group objects between
different AD-based forests or from an Windows NT 4.0 domain to an AD-
based domain (inter-forest migration); does not maintain users' passwords.
ƒ Active Directory Migration Tool version 2.0 (ADMT) can work as both
MoveTree (within AD-based forests) and ClonePrincipal (between forests or
Windows NT 4.0 domains and AD-based forest); creates new passwords or
migrates existing passwords.

The first two utilities have been included in the Support Tools pack, whereas ADMT
can be downloaded freely from the Microsoft website (see Appendix A).

The main difference between these utilities is that MoveTree operates only in intra-
forest scenarios, and ClonePrincipal only provides inter-forest operations. Besides,
MoveTree destroys the source object (assigning its GUID to the new object), and
ClonePrincipal creates a copy of the object, leaving the source intact. ADMT 2.0 can
provide both migration scenarios. All of the utilities add the original objects' SIDs to
the sIDHistory attribute of target objects.

Adventures of the ObjectSID Attribute

Alteration of an Active Directory object's domain membership results in the changing

of the object security identifier (SID). Windows 2000-based native mode domains as
well as Windows .NET-based Windows 2000 native and Windows .NET (version
2002) functional level domains have a mechanism permitting users and other security
principals to retain access to network resources after they have been moved to
another location in the domain structure. Let us discuss this mechanism in an
example using ClonePrincipal.

Every security principal object in non-Windows 2000 mixed mode domains has a
multi-valued sIDHistory attribute. This attribute, as well as the object SID (the
objectSid attribute), is used in an object's access token for granting access to
network resources. If any SID value is presented in the ACL of a network resource,
the object is granted access to this resource (provided that the granted access
permission is Allow rather than Deny). This process is outlined in Fig. 13.1.

Fig. 13.1: The sIDHistory attribute allows a new object to retain the access
permissions granted to the source object

After either ClonePrincipal or MoveTree creates a new object, it adds the source
object's SID value to the new object's sIDHistory list. As a result, the new object will
have access to all resources available to the source object (Fig. 13.2).

Fig. 13.2: The cloned (or moved) object inherits the access rights of the source object
In addition, the sIDHistory list of the source object — if the list is not empty — is
added to the sIDHistory of the target object.

Active Directory Object Manager (MoveTree.exe) (ST)

MoveTree is the main tool (and the only standard one, if you exclude the Active
Directory Migration Tool) that allows administrators to reconstruct AD-based domains
which belong to the same forest. This tool can move both single Active Directory
objects and entire containers (OU) from one domain to another. The following objects
are supported:

ƒ Users (the passwords are preserved)

ƒ Empty domain local and global groups
ƒ Universal groups (all members are preserved)
ƒ Organizational units (with or without contents)

You cannot use MoveTree to move computer accounts, system objects, or domain
controllers.

Note If you prefer GUI tools, try the Active Directory Migration Tool (ADMT), which
has many additional options when compared to MoveTree. ADMT version 2.0
can be controlled from scripts.
Important The documentation on MoveTree in the Support Tools Help fails to
mention the most important restriction of the tool: the target domain must
be in native mode. Only native-mode domains support the slDHistory
attribute (updateable by the tool) for the security principals. You may not
consider this fact to be a limitation, but do not forget about it while
working with mixed mode domains!

Revise data (such as user profiles, logon scripts, etc.) associated with
user objects being moved. These data are not moved, although the user
objects preserve all settings. You might need to re-create shared volumes
or copy user data, such as logon scripts, before users will be able to
successfully log on to the new domain.

The syntax of MoveTree is quite simple: you must specify the source and destination
of an operation, as well as the operation's type. Practically all parameters are
mandatory. MoveTree has two "modes":

ƒ The test mode that checks many conditions without really moving any object
ƒ The working mode that initiates or continues a move operation

Moving an OU Subtree

Moving OUs with all their child objects is arguably the most attractive feature of
MoveTree. You must take into consideration the fact that when an OU is moved, it
retains all links with Group Policy Objects (GPOs) assigned to this OU. It is
necessary to re-create these GPOs in the new domain, and break the links with
GPOs from the old domain.
Suppoce, for example, we would like to move the Personnel OU from the net.dom
domain to the subdom.net.dom domain and rename it Staff. You must have
appropriate privileges in both source and target domains. The following "test mode"
command checks whether this operation is carried out correctly (you might also need
to provide administrative credentials for the destination domain):

C:\>movetree /check /s netdc1.net.dom /d netdc2.subdom.net.dom

/sdn OU=Personnel, DC=net, DC=dom
/ddn OU=Staff, DC=subdom, D=net, DC=dom

Notice that the destination OU name differs from the source OU name. Suppose you
got the following messages:

MOVETREE PRE-CHECK FINISHED.

MOVETREE DETECTED THERE ARE SOME OBJECTS CAN NOT BE MOVED.
PLEASE CLEAN THEM UP FIRST BEFORE TRYING TO START THE MOVE TREE OPERATION.
READ movetree.chk FOR DETAILS.

The movetree.chk file (in the same folder where the command has been executed)
always contains diagnostics messages for each step of the command execution
(successful operations have the "0x0" code). This file is generated for each check or
successful move operation. (You may also specify the /verbose parameter with the
command, and all detailed diagnostics will be displayed on the console.) You can
easily locate the problem and source of an error (marked here in bold), for example:

ReturnCode: 0x0 The operation completed successfully.MoveTree check

destination RDN conflict for object: OU=Personnel,DC=net,DC=dom
ReturnCode: 0x0 The operation completed successfully.MoveTree cross
domain move check for object: OU=Personnel,DC=net,DC=dom
...
ReturnCode: 0x212d Can't move objects with memberships across domain
boundaries as once moved, this would violate the membership conditions
of the account group. Remove the object from any account group
memberships and retry.MoveTree cross domain move check for object:
CN=Dan,OU=Personnel, DC=net, DC=dom
...
Note With the Windows 2000 version of MoveTree, you will get the 0x212d error if
you try to move a computer account (a single account or an account included in
an OU). The Windows .NET version of MoveTree reports the 0x2081 error just
when a move operation is really performed. Use NetDom or ADMT for moving
computers.

If you delete the reported user object (cn=Dan) from any domain local or global
security group (excluding universal groups and the primary group — Domain Users)
and repeat the command, you will get the following result:

MOVETREE PRE-CHECK FINISHED.

MOVETREE IS READY TO START THE MOVE OPERATION.

The movetree.err file will be empty in this case.

This means that the command has found no errors, and the move operation has a
chance to succeed. Now you can complete the move operation by replacing the
/check parameter with either the /startnocheck or /start parameter. All diagnostic
messages are always written to the movetree.log file located in the current folder.

Attention The "test mode" (with the /check parameter) does not guarantee that the
operation will not fail. For example, the following error ("Insufficient
access rights to perform the operation") may appear only in the "working
mode":

MOVETREE FAILED. 0x2098

READ movetree.err FOR DETAILS.
Note After directory objects have been moved, force replication or wait until
replication is completed. The Infrastructure operations master and Global
Catalog must be updated. Otherwise, some changes in the domains may not be
"understood" in the forest.

If for some reason a move operation fails to complete, any remaining objects are
placed to the LostAndFound container in the source domain. For example, in the
Windows .NET environment, such a situation can occur if you try to move an OU
containing computer accounts. To solve this problem, view the operation log, delete
or move conflicting objects from the LostAndFound container, and restart the
operation using the /continue parameter. When the move operation is successfully
completed, this container will be empty (if there are no failed operations that move
other directory objects).

Moving User and Group Accounts

The destination container must already exist before a user or group account is
moved. The object can be renamed when moving; you only need to specify the
appropriate distinguished names along with the /sdn and /ddn parameters.

Local and global groups must be empty when moved. (Only universal groups retain
all their members when moved.) Otherwise, a message similar to the following will
appear in the movetree.chk file:

ERROR: 0x2132 Cross-domain move of non-empty account groups is not

allowed. MoveTree object CN=GlobalGroup,OU=Staff,DC=net,DC=dom failed
the Cross Domain Move Check

or

ERROR: 0x2133 Cross-domain move of non-empty resource groups is not

allowed. MoveTree object CN=LocalGroup,OU=Staff,DC=net,DC=dom failed
the Cross Domain Move Check

Cloning Security Principals (ClonePrincipal) (ST)

ClonePrincipal is not really a utility or command, but a set of scripts that allows
administrators to perform inter-forest migration, primarily to incrementally migrate
(copy) accounts from an existing Windows NT 4.0-based domain to a new Active
Directory domain (based on domain controllers running Windows 2000 or Windows
.NET). (In contrast to MoveTree, ClonePrincipal does not affect the source objects.)
ClonePrincipal can also be used for reorganizing AD-based forests. This tool and its
GUI counterpart — the Active Directory Migration Tool (ADMT) — are the only
facilities used for upgrading existing Windows NT 4.0-based domains in cases when
users can preserve continuous access to network shared resources and
administrators can fulfill fallback in case of an emergency.

Note ADMT is a more powerful and user-friendly tool than ClonePrincipal. ADMT has
many additional features, for example, it also supports intra-forest operations,
and can migrate user profiles, computers, and trusts. ClonePrincipal and ADMT
have quite a few similar features. However, they differ internally, and Microsoft
does not recommend that you mix these tools for migration operations. If you
learn ClonePrincipal's basics (especially the environmental requirements and
mechanism of SID migration), you will be able to master ADMT without any
problems.

Well-Known SIDs and RIDs

Let us first clarify some terms used below.

A unique Security Identifier (SID) of a security principal (i.e., user, computer, or group
account) is used to grant access rights to shared network resources to a principal.
The SID is composed of two parts: a unique "domain part", which is the same for all
principals within the domain where they reside, and a Relative Identifier (RID), which
uniquely identifies the principal in the domain.

Note Windows .NET domains offer a new security principle — class inetOrgPerson.
You can use objects of that class in the same way as the user objects and
assign them permissions on shared resources and directory objects.

An account with a well-known RID has an SID composed of an RID that is identical in
every domain, and a "domain part" that is unique for each domain. Such an account
can only be cloned onto an account with the same RID. Here are accounts with well-
known RIDs:

ƒ Administrator
ƒ Domain Admins
ƒ Domain Guests
ƒ Domain Users
ƒ Guest

An account with a well-known SID cannot be cloned, since its SID is identical in every
domain. (Therefore, it doesn't make sense to copy an account whose SID already
exists in the target domain.) Here are accounts with well-known SIDs:

ƒ Account Operators
ƒ Administrators
ƒ Backup Operators
ƒ Guests
ƒ Power Users
ƒ Print Operators
 ƒ Replicator
ƒ Server Operators
ƒ Users

Supported Object Types

With ClonePrincipal, you can clone the following objects:

ƒ User accounts
ƒ Security group accounts:
ƒ Local groups (from Windows NT 4.0 or Windows 2000 mixed mode
domains)
ƒ Global groups
ƒ Domain local groups (from at least Windows 2000 native mode Active
Directory domains)
ƒ Universal groups (from at least Windows 2000 native mode Active
Directory domains)

ClonePrincipal does not support the following objects:

ƒ Computer accounts (workstations or domain controllers)

ƒ Inter-domain trusts
ƒ Accounts with well-known SIDs (for example, Administrators or Users local
groups)

ClonePrincipal Components

ClonePrincipal consists of the following files:

ƒ Clonepr.dll—a COM server that implements all functions.

ƒ Clonepr.vbs—the script that clones a single security principal (user account;
global, universal, or domain local group), creating the target principal if
necessary.
ƒ Clonelg.vbs—the script that clones all local (except built-in) or domain local
groups in a domain.
ƒ Clonegg.vbs—the script that clones all global and universal groups in a
domain.
ƒ Cloneggu.vbs—this script clones all users and global groups (user, global
group, and universal group accounts) in a domain, including well-known global
groups such as Domain Admins, Domain Users, and Domain Guests.
ƒ SIDHist.vbs—the script that copies (adds) the value of the objectSID attribute
of a source principal to the sIDHistory attribute of a target principal.

Use of these scripts is discussed in the following sections.

Configuring Migration Environment

One of the most important requirements for ClonePrincipal (as well as for ADMT) to
work well is the proper configuration of both source and target domains. If you are
also planning to use ADMT, see also the additional requirements below.
ClonePrincipal will fail if any of the requirements have not been met.

Here are some general considerations:

ƒ If ClonePrincipal was installed separately from the Support Tools, make sure
that the Clonepr.dll has been registered on the target DC.
ƒ All ClonePrincipal scripts must be run on the PDC Emulator (the FSMO role
master) of the target domain.
ƒ You must log on to the DC as a member of the Domain Admins group of the
target domain.

Registry Settings (TcpipClientSupport)

In the source domain running Windows NT 4.0 (with Service Pack 4 or later) or
Windows 2000/.NET, create the registry REG_DWORD:0x1 value named
TcpipClientSupport on the PDC (or the PDC Emulator) under the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Reboot the PDC.

This setting is not necessary if you use ADMT for intra-forest migration.

Audit Settings

It is necessary to set auditing, both in the source and target domains. Use the
procedure described below.

For Windows 2000 and Windows .NET domains (both the source and target):

1. Open the Group Policy Object (GPO) for the Domain Controller OU. (Use
either the Domain Controller Security Policy or the Active Directory Users
and Computers snap-in.)
2. Open the Security Settings | Local Policies | Audit Policy node.
3. Double-click the Audit account management policy and check both the
Success and Failure boxes. Click OK. A sample screen is shown in Fig. 13.3.
Refresh the computer policy or wait for the updates to take place.
 Fig. 13.3: Setting audit on the Windows 2000-based domain controllers

For a Windows NT 4.0-based source domain:

1. In User Manager for Domains, click Audit in the Policies menu.

2. Select Audit These Events and check the Success and Failure boxes for
User and Group Management (Fig. 13.4).

Fig. 13.4: Setting audit on a Windows NT 4.0-based domain controller

Creating the Audit Group

In either a Windows NT 4.0- or AD-based source domain, you must create a special
domain local group that is used for auditing cloning operations. The name of the
group is composed of the source domain NetBIOS (pre-Windows 2000) name
appended with three dollar signs, for example, NT4DOM$$$. The group must be
empty. Without this group, you will not be able to transfer SIDs between forests and
update the sIDHistory attribute of target objects.

This group is not required if you use ADMT for intra-forest migration.