Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Windows 2000 Active Directory

Windows 2000 Active Directory

by Alistair G. Lowe-Norris, Robert Denn (Editor)

The most important change in Windows 2000 is the inclusion of Active Directory, a fully qualified directory service. It's so important that if you're a systems administrator, you're likely to find coming to grips with Active Directory to be one of your biggest headaches. But it doesn't have to be that way, thanks to Windows 2000 Active Directory.



The most important change in Windows 2000 is the inclusion of Active Directory, a fully qualified directory service. It's so important that if you're a systems administrator, you're likely to find coming to grips with Active Directory to be one of your biggest headaches. But it doesn't have to be that way, thanks to Windows 2000 Active Directory.

Written by a participant in the Windows 2000 Rapid Deployment Program, Windows 2000 Active Directory delivers the practical, hands-on information you need to manage your site. Instead of filling pages with a screen-by-screen description of the graphical user interface, it focuses on the tasks you need to perform to manage your organization's directory effectively. The heavy emphasis on scripting with the ADSI will help you automate tasks to achieve greater reliability and save time.

Windows 2000 Active Directory is divided into three sections:

  • The Basics, which provides an overview of the Active Directory technology and a detailed introduction to AD features.
  • Design, which describes mapping your organization's typology into the Active Directory schema; specific topics include the AD namespace and DNS, AD objects such as sites and domains, replication, group policies, and migration issues.
  • Scripting, which covers the powerful capabilities of the Active Directory Services Interface (ADSI), including ADSI's use with ActiveX Data Objects (ADO), Active Server Pages (ASP), and Visual Basic (VB).

Windows 2000 Active Directory is a practical guide to the new technology for the overworked system or network administrator. Whether you're working regularly in the Windows 2000 environment or just evaluating Windows 2000 in order to understand the design issues involved, this book builds the solid foundation you need to understand Active Directory and use it effectively.

Editorial Reviews

A guide for system administrators to designing a reliable, scalable, and manageable Active Directory on the software for any size organization. Rather than describing the graphical user interface screen by screen, Lowe-Norris, who was part of the Windows 2000 Rapid Deployment Program, focuses on the tasks needed to manage an organization's directory effectively, heavily emphasizing scripting with the ADSI for automation. There is no index. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Product Details

O'Reilly Media, Incorporated
Publication date:
Edition description:
Older Edition
Product dimensions:
7.10(w) x 9.25(h) x 1.22(d)

Read an Excerpt

Chapter 7: Sites and Replication Topologies

As I mentioned in Chapter 4, Active Directory Replication, 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
I covered the former in Chapter 4, and I'll cover the latter here, leading to an explanation of how to properly design a representation of your organization's physical infrastructure within Active Directory.

Intrasite and Intersite Topologies

Two distinct types of replication links exist with Windows 2000 sites: intrasite (within sites) and intersite (between sites). A Windows 2000 service known as the Knowledge Consistency Checker (KCC) is responsible for automatically generating the replication links between intrasite DCs. The KCC will create intersite links automatically for you but only when an administrator has specified that two sites should be connected. Every aspect of the KCC and the links that are created is configurable, so you can manipulate what has been automatically created and what will be automatically created via manipulation of the various options. You can even disable the KCC if you wish and manually create all links.

Note that there is a large distinction between the KCC (the process that runs every 15 minutes and creates the replication topology) and the replication process itself. The KCC is not involved in the regular work of replicating the actual data in any way. Intrasite replication along the links created by the KCC uses a notification process to announce that changes have occurred. If no changes occur at all within a six-hour period the replication process is kicked off automatically anyway just to make sure. Intersite replication on the other hand does not use a notification process. Instead it uses a replication schedule to transfer updates, using compression to reduce the total traffic size.

The KCC uses a fairly simple algorithm to create the topologies, and the topologies it creates work well in their default configurations. However, I don't think as a Windows 2000 administrator you should just accept the topologies it creates without examining them in detail. You should investigate and understand what has been done by the KCC. If you then look over the topology and are happy with it, you have actively, rather than passively, accepted what has been done. While letting the KCC do its own thing is fine, every organization is different, and you may have requirements for the site and link design that it is not aware of and cannot build automatically.

Other administrators will want to delve into the internals of Active Directory and turn off the KCC entirely, doing everything by hand, This approach is valid, as long as you know what you're doing, but I prefer to let the KCC do its work, helping it along with a guiding hand every now and then. I cover all these options in the design section later.


DCs within sites have links created between them by the KCC. These links use the DC's GUID as the unique identifier. These links exist in Active Directory as connection objects and only use the Directory Service Remote Procedure Call (DSRPQ transport to replicate with one another. No other replication transport mechanism is available. However, when you need to connect two sites, you manually create a site link via the Sites and Services Manager (SSM) and specify a replication transport to use. When you do this, intersite link connection objects are automatically created by the KCC in Active Directory. There are two replication transports to choose from: standard DS-RPC or Inter-Site Mechanism Simple Mail Transport Protocol (ISM-SMTP). The latter means sending updates via the mail system using certificates and encryption for security.

There are two reasons that the KCC cannot automatically create links between two sites. First, the KCC has no idea which sites you will want to connect. Second, the KCC does not know which replication transport protocol you will want to use.

The KCC runs locally every 15 minutes on each DC. The default time period can be changed, and it can be started manually on demand if required. If I create two servers in a new domain called Server A and Server B, the KCC will run on each server to create links. Each KCC is tasked with creating a link to define incoming replication only. The KCC on Server A will define an incoming link from Server B, and Server B's KCC will define an incoming link from Server A. The KCC creates only one incoming link per replication partner, so Server A will never have two incoming links from Server B, for example.

The KCC does not create one topology for all NCs, nor one topology per NC. The Configuration and Schema NCs share one replication topology, so the KCC creates a topology for these two together. The KCC also creates another topology on a per-domain basis. Because the Schema and Configuration are enterprise wide in scope, the KCC needs to replicate changes to these items across site links. The KCC needs to maintain a forest-wide topology spanning all domains for these two NCs together. However, unless a domain is set up to span multiple sites, the topology for a particular domain will be made up of only intrasite connections. If the domain does span sites, then the KCC needs to create a replication topology across those sites.

The GC is not a Naming Context in its own right, and so it can't really have its own replication topology. As the GC is formed from a selection of attributes on those servers that host the GC in each domain, the GC replication becomes part of the replication for each domain. As two partners replicate a domain NC, the GC is replicated as well. There is no replication of the GC between different domains.

Automatic Intrasite Topology Generation by the KCC

For each NC, the KCC builds a bidirectional ring of links between the DCs in a site. However, while upstream and downstream links are created between partners around a ring, the KCC creates links across the ring as well. It does this to make sure that it stays within the following guidelines:

  • Every DC must be within three hops from any other DC. This is known as the three-hop rule.
  • The default latency (maximum time for replication between any two DCs) for replication is five minutes.
  • The maximum convergence (maximum time for an update to reach all DCs) is 15 minutes.
Technically speaking, due to the three-hop rule, when you put in your eighth DC the KCC will start adding branches across the circular ring.

Assuming you have five servers in a ring and you add a sixth, the other servers around the ring add and delete connection objects in order to accommodate the newcomer. So if Server C and Server D are linked and Server F interposes itself between them, Server C and Server D delete their interconnections and create connections to Server F instead. Server F also creates connections to Server C and Server D. Let's now take a look at this process in more detail...

Meet the Author

Alistair G. Lowe-Norris is an Architectural Enterprise Strategy Consultant for Microsoft UK. He worked for Leicester University as the project manager and technical lead of the Rapid Deployment Program for Windows 2000, responsible for rolling out one of the world's largest deployments of Windows 2000 preceding release of the final product. Since 1998 he has been the technical editor and a monthly columnist for the Windows Scripting Solutions magazine and a technical editor and author for Windows & .NET Magazine (previously Windows NT Magazine and Windows 2000 Magazine).

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews