Windows 2000 Active Directory

Content preview·Buy reprint rights for this chapter

Windows 2000 Active Directory is Microsoft's entry into the directory services arena and provides administrators with the ability to manage enterprise-wide network objects efficiently from a central location. Information about users and groups, computers and printers, applications and files—once specified in Active Directory—is available for use throughout the network. The structure of the information matches the structure of your organization, and your users can query Active Directory to find the location of a printer or the email address of a colleague.

This book is an introduction to Active Directory, but an introduction with a difference. Instead of presenting the information inside out and feature by feature, Active Directory is viewed here from two outside-in perspectives. Part II of the book focuses on the various design issues and methodologies to enable you to map your organization's business requirements into Active Directory hierarchy. Getting the design right is critical to a successful implementation. The second perspective, presented in Part III, is a discussion of how to set up and manage Active Directory programmatically through Active Directory Services Interfaces (ADSI) scripts. If you understand how to create efficient designs and how to carry out those design decisions in scripts, you will be well on your way to building and managing a directory structure populated with the right objects at the right levels of the hierarchy.

Before turning to the details of designing and scripting, however, Part I introduces Active Directory at the conceptual level.

Active Directory extends the Windows NT 4 domain model to provide a more efficient approach, and it provides a number of important new features as well. Of particular interest are the following:

New domain model: Domains in Windows were flat structures limited to about 40,000 objects, and this had some unfortunate consequences. For one thing, the assigning of privileges tended to be an all-or-nothing matter at the domain level; there was no delegation or inheritance within the domain. For another, the resource limitation often meant that the number of domains in an organization would grow into an unmanageable network over time. Active Directory domains are hierarchical and virtually without resource limitation. This means that administrators can delegate authority within a smaller number of more manageable domains.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Active Directory extends the Windows NT 4 domain model to provide a more efficient approach, and it provides a number of important new features as well. Of particular interest are the following:

New domain model: Domains in Windows were flat structures limited to about 40,000 objects, and this had some unfortunate consequences. For one thing, the assigning of privileges tended to be an all-or-nothing matter at the domain level; there was no delegation or inheritance within the domain. For another, the resource limitation often meant that the number of domains in an organization would grow into an unmanageable network over time. Active Directory domains are hierarchical and virtually without resource limitation. This means that administrators can delegate authority within a smaller number of more manageable domains.
Transitive trusts: Under Windows NT 4, managing trust relationships could easily become a nightmare. All trusts were manual and unidirectional, and they had to be individually specified. If domain A trusted domain B, it was still necessary to separately specify that domain B trusted domain A, if that was your desire. Moreover, if A trusted B and B trusted C, A did not trust C without a separate specification. Active Directory domains include automatic bidirectional trusts and transitive trusts to rationalize and simplify trust management.
Group policies: Using new group policies, you can specify roles complete with configuration information within the domain hierarchy. This means that you can define things so that, whenever you add a new user to a group, you can trigger automatic configuration and software installation for that user.
Multimaster replication: Each domain controller automatically propagates all the objects defined on it to every other participating domain controller. Because each controller contains all the data for the domain, Active Directory access will continue should one domain controller fail.
Global catalog: To facilitate efficient searching of Active Directory, all the objects and their frequently used attributes are stored in a partial replica of each Windows 2000 domain in a directory. This is the Global Catalog, and it is built automatically during Active Directory replication.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

When you create objects in Active Directory, you create them in a hierarchical structure you have control over. The structure is made up of two types of objects: containers and noncontainers, or leaves. A series of containers branch downward from a root container, just as the roots of a tree do. Each container may contain noncontainers or further containers. A noncontainer, however, may not contain any other objects.

Consider the parent-child relationships of the containers and leaves in Figure 1.1. The root of this tree has two children, Finance and Sales. Both of these are containers of other objects. Sales has two children of its own, Presales and Postsales. Only the Presales container is shown as containing child leaf objects. The Presales container holds user, group, and computer objects as an example. Each of these noncontainers is said to have the Presales container as its parent.

Figure 1.1: A hierarchy of objects

Figure 1.1 is what is known in Windows 2000 as a domain .

The most common type of container you will create in your Active Directory is the Organizational Unit , but there are others as well, such as DomainDNS and even one called Container. Each of these has its place, as I'll show later, but the one that you will be using most frequently is the Organizational Unit.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

When you are potentially storing millions of objects in Active Directory, each object has to be uniquely locatable and identifiable. To that end, objects have a Globally Unique Identifier (GUID) assigned to them by the system at creation. This 128-bit number is guaranteed to be unique by Microsoft. However, there is another way to reference an object: the AdsPath.

Hierarchical paths in Active Directory are known as ADsPaths and can be used to uniquely reference an object. In fact, ADsPath is a slightly more general term, and is used by Microsoft to apply to any path to any of the major directories: Windows 2000's Active Directory, Windows NT, Novell's NDS, Netscape's Commerce Server, and many others.

ADsPaths to Active Directory are normally represented using the syntax and rules defined in the LDAP standards. Let's take a look at how a path to the root of Figure 1.1 looks:

LDAP://dc=mycorp,dc=com

Here you can see that the path starts with a progID of LDAP followed by a colon (:) and a double forward slash (//). All LDAP paths start this way.

You probably noted that I said that an ADsPath is normally represented by an LDAP path; that isn't always the case. ADsPaths to other directories can use other progIDs. I go into these other progIDs in more depth in Chapter 14.

In the previous ADsPath, after the progID, you represent the domain root, mycorp.com, by separating each part by a comma and prefixing each part with the letters dc. If the domain had been called mydomain.windows.mycorp.com, the ADsPath would have looked like this:

LDAP://dc=mydomain,dc=windows,dc=mycorp,dc=com

DC stands for Domain Component; dc is used only when specifying domain roots.

A Distinguished Name (DN) is the name used to uniquely reference an object in an entire Directory Information Tree (DIT ). A Relative Distinguished Name (RDN) is the name used to uniquely reference an object within its parent container in a DIT. For example, this is the ADsPath for the default Administrator account in the Users Container in the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

This chapter has been a brief introduction to Active Directory and to this book. The chapters in Part I will complete the conceptual introduction to Active Directory's technology and equip you to get the most out of Part II and Part III.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

This chapter aims to bring everyone up to speed on the terminology and functionality surrounding Active Directory. I cannot stress enough how important it is that you understand the parlance of Microsoft's terminology and how each component of Active Directory fits into the whole before considering a design; if you do not know what the component items of a design do, you cannot design properly with them.

Let's start off with a simple look at how an Active Directory namespace is structured in terms of domains, trees, forests, and Organizational Units.

Windows 2000's logical structure is built around the concept of domains introduced by Windows NT 3.x and 4.x. However, in Windows 2000, the term domain has been updated somewhat. A domain is now made up of the following components:

An X.500-based hierarchical structure of containers and objects
A DNS domain name as a unique identifier; DNS names have taken over from NetBIOS names in Windows 2000, and NetBIOS is not necessary in a pure Windows 2000 environment
A security boundary run by a security service and managed by an administrator of that domain, which authenticates any access to resources via accounts in the domain or trusts with other domains
One or more policies that dictate how functionality is restricted for users or machines within that domain

A domain is the smallest component of Active Directory that can be reproduced on a single domain controller (DC). For example, Mycorp Company has already been allocated a DNS domain name for their company called mycorp.com, so they decide that the first Windows 2000 domain that they are going to build is to be named mycorp.com. However, this is only the first domain in a series that needs to be created, and mycorp.com is in fact the root of a domain tree.

The mycorp.com domain itself, ignoring its contents, is automatically created as the root node of a hierarchical structure called a

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Let's start off with a simple look at how an Active Directory namespace is structured in terms of domains, trees, forests, and Organizational Units.

Windows 2000's logical structure is built around the concept of domains introduced by Windows NT 3.x and 4.x. However, in Windows 2000, the term domain has been updated somewhat. A domain is now made up of the following components:

An X.500-based hierarchical structure of containers and objects
A DNS domain name as a unique identifier; DNS names have taken over from NetBIOS names in Windows 2000, and NetBIOS is not necessary in a pure Windows 2000 environment
A security boundary run by a security service and managed by an administrator of that domain, which authenticates any access to resources via accounts in the domain or trusts with other domains
One or more policies that dictate how functionality is restricted for users or machines within that domain

A domain is the smallest component of Active Directory that can be reproduced on a single domain controller (DC). For example, Mycorp Company has already been allocated a DNS domain name for their company called mycorp.com, so they decide that the first Windows 2000 domain that they are going to build is to be named mycorp.com. However, this is only the first domain in a series that needs to be created, and mycorp.com is in fact the root of a domain tree.

The mycorp.com domain itself, ignoring its contents, is automatically created as the root node of a hierarchical structure called a domain tree. This is literally a series of domains connected together in a hierarchical fashion, all using a contiguous naming scheme. So, when Finance, Marketing, and Sales each wants its own domain, the names become finance.mycorp.com, marketing.mycorp.com, and sales.mycorp.com. Each domain tree is called by the name given to the root of the tree; hence, this domain tree is known as the mycorp.com tree; this is illustrated in Figure 2.1. You can also see that I have added further domains below sales, for presales and postsales work.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Having introduced the four major components of a Windows 2000 network, let me now drill down into these concepts further.

There are three building blocks that make up Active Directory itself:

Domain Naming Contexts
Configuration Naming Context
Schema Naming Context

Active Directory is split into a number of parts, which Microsoft calls Partitions or Naming Contexts (NCs). Each of these parts represents a different aspect of Active Directory. One NC is known as the Configuration and holds data representing the entire configuration of the forest, e.g., the list of NCs, how the physical network of sites and servers are configured, and so on. Another NC is known as the Schema and is responsible for maintaining data on the entire set of object and attribute types that can be created in Active Directory. The rest of the NCs are known as domain NCs, as one NC exists for each domain in the forest.

Section 2.2.1.1: Domain Naming Contexts

The domain NCs are the part of Active Directory that hold the information on users, groups, and Organizational Units for a domain. The NCs are considered separate for the purposes of replication. However, while they are considered separate, in order to be able to reference and manipulate data in all the NCs, Active Directory joins them together into one complete structure so that you can use LDAP to reference any naming context from a tree. Active Directory is a contiguous hierarchical structure that has certain parts that, while they are joined under the hierarchy and can be accessed in the same manner as any other part of Active Directory, are in fact considered as separately replicating parts of it. In a forest, there is never but one Schema NC and one Configuration NC, but you can have as many domain NCs as you like.

Section 2.2.1.2: Configuration Naming Context

The Configuration is a Naming Context whose name is:

LDAP://cn=Configuration, dc=forest-root-domain, dc=domain-component, . . .

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Those of you who have been Windows NT administrators will already have noticed many differences between Windows 2000's Active Directory and Windows NT's SAM. Table 2.8 briefly covers the major differences.

Table 2.8: A Comparison Between Windows NT and Windows 2000
Windows NT	Windows 2000
Single-master replication is used via PDCs and BDCs.	Multimaster replication is used via DCs.
Domain is the smallest unit of partitioning.	Domain is the smallest unit of partitioning.
Domain is the smallest unit of authentication.	OU is the smallest unit of authentication.
Domain is the smallest unit of policy (system policies).	OU is the smallest unit of policy (group policy objects).
Domain is the smallest unit of security delegation/administration.	A property of an object is the smallest unit of security delegation/administration.
NetBIOS broadcasts as primary browsing and connection mechanism.	TCP/IP connections to Active Directory as primary browsing and connection mechanism.
WINS or LMHOSTS required for effective browsing.	DNS and Active Directory required for effective browsing WINS required for older clients.
Object is the smallest unit of replication.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In this chapter, I've gone over the groundwork for some of the main internals of Active Directory. While I started by going over the easier domains, trees, forests, and Organizational Units, I soon moved on to some of the more detailed parts of how Active Directory works, notably the structuring of Active Directory in terms of Naming Contexts. I also covered the use of the Global Catalog and the roles of the Flexible Single Master Operators. All of these items should give you a better understanding of how Active Directory functions.

Finally, I took some time to cover how Windows NT's interoperability affects Active Directory, by explaining the two different modes that a domain can exist in. I went through some fundamental differences and delved heavily into group objects; these are the objects most affected by the two different modes.

With this information under our belts, let's now take a look at the blueprint that defines all the objects in Active Directory.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Active Directory Schema is the blueprint for all classes, attributes, and syntaxes that can potentially be stored in Active Directory. Each object in Active Directory is an instance of one or more classes in the Schema. The user cn=LeeFlight, for example, exists as an instance of the User class. Schema attributes define the pieces of information that a class, and thus an instance of that class, can hold. Syntaxes define the type of data that can be placed into an attribute. If an attribute is defined with a syntax of Boolean, it can store True and False data.

Microsoft designed Active Directory to hold the most common objects and attributes that users of a server system would require. It was understood that any good schema would never hold every class of object or every specific attribute (languages spoken, professional qualifications) that a company would like, so it was designed to be extensible. In fact, extending the schema is not a difficult task at all; it is more difficult to design the changes that you would like to incorporate. Design issues are covered in Chapter 11; in this chapter, we're concerned only with how the schema operates.

The Schema Naming Context (NC) is contained in Active Directory under the Configuration NC. You can look at the contents directly by pointing a raw Active Directory viewer like ADSIEDIT or LDP at the container and viewing the contents. However, it is much easier to view the contents using the built-in Active Directory Schema Manager MMC snap-in. The MMC snap-in separates the classes and attributes for you, whereas in reality all the objects are held together within the single Schema container; that is how the raw tools will actually view the data.

The Schema itself is made up of two types of Active Directory objects: Classes and Attributes. In Active Directory, these are respectively known as Class-Schema/classSchema and Attribute-Schema/attributeSchema objects. The two distinct forms of the same names result from the fact that the Common-Name/cn attribute of a class contains the hyphenated easy-to-read name of the class, and the LDAP-Display-Name/lDAPDisplayName attribute of a class contains the concatenated string format that we're used to using when querying Active Directory with ADSI. In the Schema, the lDAPDisplayName attributes of each object are

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The Schema Naming Context (NC) is contained in Active Directory under the Configuration NC. You can look at the contents directly by pointing a raw Active Directory viewer like ADSIEDIT or LDP at the container and viewing the contents. However, it is much easier to view the contents using the built-in Active Directory Schema Manager MMC snap-in. The MMC snap-in separates the classes and attributes for you, whereas in reality all the objects are held together within the single Schema container; that is how the raw tools will actually view the data.

The Schema itself is made up of two types of Active Directory objects: Classes and Attributes. In Active Directory, these are respectively known as Class-Schema/classSchema and Attribute-Schema/attributeSchema objects. The two distinct forms of the same names result from the fact that the Common-Name/cn attribute of a class contains the hyphenated easy-to-read name of the class, and the LDAP-Display-Name/lDAPDisplayName attribute of a class contains the concatenated string format that we're used to using when querying Active Directory with ADSI. In the Schema, the lDAPDisplayName attributes of each object are normally made by capitalizing the first letter of each word in the Common-Name and then removing the hyphens and concatenating all the words together. Finally, the first letter is made lowercase. This creates simple names like user, as well as the more unusual sAMAccountName and lDAPDisplayName. I'll use the Common-Name version from now on, as it is easier on the eyes.

Whenever you need to create new types of objects in the Schema, you must first create a Class-Schema object defining that class of object. Once the class is properly designed and added to the Schema, Active Directory extended so that objects of that type can be stored. Alternatively, if you want to add a new type of attribute to a particular class of object in the Schema, then you must first create the Attribute-Schema object in the Schema and then associate that attribute with whatever object classes were to use it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Just as object class information is stored in Active Directory as instances of the class called Class-Schema, attributes are represented by instances of the object class called Attribute-Schema. When defining a new attribute, you are effectively defining a new instance of the Attribute-Schema object. As with all objects, this one has a number of attributes that can be set. The Attribute-Schema object inherits attributes from the class called Top. However, most of the Top attributes are not really relevant here. Table 3.1 shows the defining attributes of an instance of the Attribute-Schema object (i.e., an attribute) that can be set.

The syntax of an attribute indicates the type of data that it holds, which I'll cover in a moment. The mandatory column indicates whether the attribute must be set when initially creating the object. Attributes that are not mandatory do not have to be set when creating the object and can be defined later, if they are needed at all. From here you can see that quite a few attributes must be set when initially defining a new attribute. The fourth column indicates whether this particular attribute can accept an array of values or whether it accepts only a single value; there are no multivalued attributes here.

The tables in this chapter have been assembled by examining the Schema.

Table 3.1: The Defining Attributes of an Attribute-Schema Object Instance
Attribute	Syntax	Mandatory	Multi-valued	Description
Attribute-Id	OID	Yes	No	The OID that uniquely identifies this attribute.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Microsoft defines the syntax of an attribute as meaning the kind of data it can hold; everyone else in computing calls it a datatype. In Windows 2000, Microsoft decided not to include the actual 18 provided syntaxes in Active Directory as objects. Instead, Microsoft has coded these syntaxes internally into Active Directory itself. Consequently, you cannot extend the Schema by defining your own syntaxes for the attributes of objects you create. This is a limitation on Active Directory, but extending Active Directory with user-designed syntaxes is likely to be on the list of modifications to go into the next release after Windows 2000.

Whenever you create a new attribute, you must specify its syntax. To uniquely identify the syntax among the total set of 21 syntaxes, you must specify two pieces of information: the OID and a so-called OM-Syntax. This pair of values must be set together and correctly correlate with Table 3.3. More than one syntax has the same OID, which may seem strange, and in order to distinguish between different syntaxes uniquely, you thus need a second identifier. This is the result of Microsoft requiring some syntaxes that X.500 could not provide. Table 3.3 shows the 21 expanded syntaxes, including the X.500 name of the syntax with any special Microsoft-chosen name following it in parentheses.

Table 3.3: Syntax Definitions
Syntax	OID	OM-Syntax	Description
Undefined	2.5.5.0	Not applicable	Not a valid syntax
Distinguished Name	2.5.5.1

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

All classes of objects are instances of the Class-Schema object, which is a subclass of Top. Table 3.4 shows the most-used attributes that you may wish to set, from both the Top and User classes, when defining a new class.

Table 3.4: The Defining Attributes of a Class-Schema Object Instance
Attribute	Syntax	Mandatory	Multi- valued	Description
Common-Name	Unicode	Yes	No	The descriptive Relative Distinguished Name (RDN).
Governs-Id	OID	Yes	No	The OID that uniquely identifies objects of this class.
LDAP-Display-Name	Unicode	No	No	The name by which LDAP clients identify this class.
Schema-ID-GUID	Octet string	Yes	No	Globally Unique Identifier (GUID) to uniquely identify this class.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In this chapter I've introduced you to how the internal blueprint for all objects in Active Directory, known as the Schema, was derived from the X.500 directory service. I explained that X.500 classes and attributes do exist in the schema and that the OID numbering system is still followed. I then detailed how an attribute and its syntax was structured in the Schema, as Attribute-Schema objects, using the User-Principal-Name of the User object as an example. I then showed how attributes are added to classes by detailing how classes are stored in the Schema as instances of Class-Schema objects. To make this clearer, I dug into the details of the User class to see how it was constructed.

Chapter 11 builds on what you've learned here to see how you would design changes in an enterprise environment.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

This chapter introduces a major feature of Windows 2000: replication of the data in Active Directory. There are two aspects to replication:

How data gets replicated around an existing network of links between DCs
How the Knowledge Consistency Checker (KCC) generates and maintains the replication links between servers, both intrasite and intersite

This chapter looks at the former, how a number of servers with already existing links replicate data among themselves. I'll defer discussion of how the links are created and managed until Chapter 7. That describes the physical infrastructure of a network layout using sites, how the KCC sets up and manages the site links, and then details how to effectively design and tailor sites, site links, and replication in Active Directory.

Windows 2000 uses the term site to mean a collection of machines (servers, workstations, or both) that coexist on a fast network, i.e., a physical network in a particular location with good connectivity between all sections of that network. In TCP/IP terms, this would be a collection of well-connected IP subnets. Windows 2000 uses sites to replicate the logical namespace around the physical network.

Windows 2000 replication is very efficient. Only changed properties, rather than entire objects, are replicated, as was the case in Windows NT. Replication also can take place over multiple TCP/IP transports, so that you can find a replication protocol to suit the environment a particular site requires.

The recommended minimum speed for a well-connected network is 1.5MBps (i.e., a T1 link). You will see this actual value vary from article to article and book to book, as different people will find that their network will run fine over a slower connection speed. We'll cover this later, but the absolute true minimum is around 128KBps of available replication bandwidth out of a 256KBps total available bandwidth. Your mileage may vary; you would need to do your own testing to see for yourself. Microsoft's final recommendations should be the main arbiter here.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Windows 2000 uses the term site to mean a collection of machines (servers, workstations, or both) that coexist on a fast network, i.e., a physical network in a particular location with good connectivity between all sections of that network. In TCP/IP terms, this would be a collection of well-connected IP subnets. Windows 2000 uses sites to replicate the logical namespace around the physical network.

Windows 2000 replication is very efficient. Only changed properties, rather than entire objects, are replicated, as was the case in Windows NT. Replication also can take place over multiple TCP/IP transports, so that you can find a replication protocol to suit the environment a particular site requires.

The recommended minimum speed for a well-connected network is 1.5MBps (i.e., a T1 link). You will see this actual value vary from article to article and book to book, as different people will find that their network will run fine over a slower connection speed. We'll cover this later, but the absolute true minimum is around 128KBps of available replication bandwidth out of a 256KBps total available bandwidth. Your mileage may vary; you would need to do your own testing to see for yourself. Microsoft's final recommendations should be the main arbiter here.

Administrators do the actual creation of sites, as the process is not automatic. Once you've set up a site, a Windows 2000 process automatically creates and dynamically manages a replication schedule and a set of intrasite replication links among DCs in the site. As you add more DCs, more intrasite links are added automatically. If you were to do nothing more, data would be effectively replicated by Windows 2000 around your site. When you add your second site, the same automatic intrasite creation mechanisms spring into action creating links and a replication schedule among the various DCs in this second site. The algorithm that is used adapts as more sites and DCs are added so that certain built-in criteria are never breached; this assures that the network is always properly replicated. Note, however, that creating a second site does

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Microsoft has introduced a number of new terms for Windows 2000 replication, and most of them will be completely unfamiliar to anyone new to Active Directory. In order to properly design replication, you need to understand how replication works, but more to the point you need to understand how replication works using these new terms, which are used throughout both Microsoft's documentation and its management tools. Here is the list of the terms that you'll encounter as I explain replication. These definitions will make more sense later.

Naming Context (NC): The objects replicated within Active Directory.
Update Sequence Number (USN): This 64-bit value, which is assigned to each object, increments every time a change takes place.
Originating write/update and replicated write/update: A change made to an object on a specific DC is an originating write; replication of that change to all other DCs is a replicated write.
High-Watermark Vector: This USN represents the maximum number of changes ever to occur on a particular NC.
Up-to-date vector: This is the USN on a specific server that represents the last originating write for an NC on that server.
Tombstone: Because of the complex replication available in Windows 2000 and Active Directory, simply deleting an object potentially would result in it being re-created at the next replication interval. So deleted objects are tombstoned instead. This basically marks them as deleted. Objects marked as tombstoned are actually deleted 60 days after their original tombstone status setting; however, this time can be changed by modifying the tombstonelifetime property of cn=DirectoryServices,cn=WindowsNT,cn=Services,cn=Configuration,dc=mycorp,dc=com.
Property version number: This number indicates how often this particular property has been updated.
Timestamp: This time and date are stored on an object for comparison checking.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Table of Contents

Section 2.2.1.1: Domain Naming Contexts

Section 2.2.1.2: Configuration Naming Context