Configuring the Active Directory Lightweight Directory Services (Part 5)

by [Published on 31 March 2011 / Last Updated on 31 March 2011]

This article continues the discussion of the Active Directory Lightweight Directory Services (AD LDS) by examining the logical structure of an AD LDS instance and discussing how that structure plays into the replication process.

If you would like to read the other parts in this article series please go to:

Introduction

In the previous article in this series, I showed you how to create a second instance of an AD LDS partition. Even so, I haven’t really spent much time talking about how the replication process works in an AD LDS environment. That being the case, I want to take this opportunity to discuss AD LDS replication in more detail.

Before I Begin

Before I get started, I want to point out that AD LDS replication works very similarly to the way that Active Directory replication works. Of course this shouldn’t come as any big surprise since the “AD” in LD LDS stands for Active Directory. If you are already familiar with Active Directory replication then you will find that the biggest difference between Active Directory replication and AD LDS replication is that some of the terminology is a bit different.

Instances and Partitions

Before I begin explaining how the replication process works, I need to clarify the relationship between instances and partitions within an AD LDS environment. Even though Microsoft probably has some more elaborate definitions, I think that the easiest way to explain the relationship between instances and partitions is to tell you to think of an instance as a collection of related directory partitions. In other words, each instance contains multiple directory partitions.

In many ways, an instance is like a domain controller. In an Active Directory environment, each domain controller contains three directory partitions. These partitions include:

  • Configuration – The configuration container stores configuration information related to the forest in which the domain controller exists. The Configuration container stores configuration objects related to things such as sites, services, and directory partitions.
  • Schema – The schema partition works similarly to any other database schema. It defines the classes and attributes for every possible object in the entire Active Directory.
  • Domain – The Domain partition stores objects that are specific to the domain. This includes things like users, computers, and groups.

Although the Active Directory makes use of three separate partitions, AD LDS instances include two built in partitions. These partitions include:

  • Configuration Directory Partition
  • Schema Directory Partition

These partitions perform essentially the same tasks as their Active Directory counterparts.

You will notice that AD LDS does not use a Domain partition like the Active Directory does. The reason for this is because AD LDS is not a domain environment, so there is no need for the instance to have a partition filled with domain specific objects such as users and computers.

That isn’t to say that AD LDS does not make use of a third partition like the Active Directory does. It’s just that AD LDS uses an Application Directory Partition rather than a domain partition.

If you think back to the article in which I first showed you how to deploy AD LDS, you will recall that there was a screen which asked you whether you wanted the wizard to create an application directory partition or if the application that would be making use of the AD LDS instance that you are creating would create the partition instead. You can see what that screen looks like in Figure A.


Figure A: An AD LDS instance makes use of an application directory partition.

An application directory partition works similarly to a domain partition except that rather than store domain specific information, an application directory partition stores the data that is used by the application for which you are creating the AD LDS instance.

Configuration Sets

As you will recall, the previous article in this series demonstrated a technique for creating a replica of an AD LDS instance. What I didn’t mention though was that when you create a replica of an existing instance, you also create a logical structure called a configuration set. Simply put, a configuration set consists of two or more replicas of the same AD LDS instance.

The easiest way that I can think of to explain a configuration set is to tell you to think of a configuration set like an Active Directory domain. Earlier I said that you could think of an AD LDS instance as being similar to a domain controller. As I’m sure you know, most Active Directory domains contain multiple domain controllers. In the same way, an AD LDS configuration set contains multiple AD LDS instances.

The analogy goes a little bit further than that though. Like an Active Directory domain, the instances within a configuration set all share a common schema directory partition and a common configuration directory partition.

AD LDS also uses a similar multi master replication model to what an Active Directory domain uses. Updates can be made to a partition on any AD LDS instance, and those changes will be automatically replicated to all of the other instances within the configuration set.

The Site Topology

The AD LDS replication process is completely automatic so long as all of the instances within a configuration set reside within a common site. Like an Active Directory domain however, it is possible for an AD LDS configuration set to span multiple sites.

In case you are not familiar with sites, sites are a mechanism that is often used to adapt an Active Directory forest to a network that spans a large geographic area. For example, if an organization has offices in multiple cities then they might create a separate site for each city.

Sites are sometimes used in smaller geographic regions as well though. For instance, I recently did a project for an organization that had two offices that were about fifteen miles apart. Because these two offices were linked with an expensive leased line, the organization created two separate sites as a way of reducing the amount of Active Directory traffic that flowed across the WAN link.

Whenever a change is made to the domain partition on a domain controller, that change is replicated to the other domain controllers in the site almost immediately. However, the replication process works a bit differently for domain controllers that exist in other sites. Rather than replicating the change to the domain controllers in other sites, the Active Directory makes use of bridgehead servers.

A bridgehead server is a domain controller to which a site link has been joined. The bridgehead server pushes the updates to the bridgehead server on the other side of the site link according to a replication schedule. The remote bridgehead server receives the update and pushes it to all of the domain controllers in the remote site. That way, the update only has to be sent across the lite link (which usually corresponds to a WAN link) one time, as opposed to once for each domain controller in the remote site.

These same basic concepts also apply to AD LDS environments. I will show you how to create AD LDS sites in Part 6.

Conclusion

In my next article, I want to build on the concepts that I have discussed in this article by showing you how to create sites in an AD LDS environment. My plan is to conclude this series in Part 7 by showing you how you can configure replication across site boundaries.

If you would like to read the other parts in this article series please go to:

Featured Links