Configure the Lightweight Directory Service service - Part 5

Network Administration - In this part 5, we will show you the logical structure of the AD LDS instance and the role of that structure in the replication process .

Instance and Partition

Before introducing how to create a working copy, we need to clarify the relationship between instance and partition inside AD LDS environment. Although Microsoft certainly has more definitions, we can understand in a simple way of clicking on this relationship: an instance is a set of related directory partitions. In other words, each instance will have multiple partition directories.

In many cases, an instance can be a domain controller. In an Active Directory environment, each domain controller contains three partition directories. These partitions include:

1. Configuration - The configuration section stores configuration information related to the forest in which the domain controller exists. The configuration item stores configuration objects related to things like location, service and directory directory.
2. Schema - This partition works like other database schemas. It defines classes and attributes for all possible objects in the entire Active Directory.
3. Domain - This partition stores specific objects for the domain. These objects include things like user, computer and group.

Although Active Directory uses three separate partitions, the AD LDS instance only has two associated partitions. These partitions include:

1. Configuration Directory Partition
2. Directory Directory Schema

These partitions basically perform the same tasks as their Active Directory replicas.

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

However, this does not say that AD LDS does not allow the use of the third partition like the Active Directory to use, but AD LDS uses the Application Directory Partition instead of the domain partition.

If you have a look at the section on how to deploy AD LDS, you will see a screen asking you if you want the wizard to create an application or application directory partition using the AD LDS instance you are creating. partition. You can see the figure shown in Figure A below.

Figure A: AD LDS instance uses the application directory partition

The application directory partition works just like the domain partition except for saving domain information, the application directory partition stores the data used by the application you are creating the AD LDS instance for.

Configuration set

In the previous part of this series, we introduced a technique for creating AD LDS instance replicas. However, there are still things we have not mentioned in that section when creating a copy for an existing instance, you will also create the logical structure, which is called the configuration file. Very simply, the configuration set consists of two or more copies of the same AD LDS instance.

The simplest way to explain a configuration file is to think of it as an Active Directory domain. Previously, we said that you could treat an AD LDS instance like a domain controller. And since most Active Directory contains multiple domain controllers, an AD LDS configuration set also includes multiple AD LDS instances.

Just like an Active Directory domain, instances within the configuration set share a directory schema partition and directory configuration partition.

AD LDS also uses the master replica mode just like what the Active Directory domain still uses. Updates can be made to the partition on any AD LDS instance, changes will automatically be replicated to all other instances within the configuration set.

Topo of the site

The AD LDS replication process is completely automated as long as all instances within a configuration set reside within a site. However, like an Active Directory domain, an AD LDS configuration set can be fully extended to multiple sites.

In case you are still not familiar with the site concept, we can explain here that a site is a mechanism used to adapt an Active Directory forest to a network that is expanded to a geographical extent. For example, if an organization has multiple offices located in many different cities, they can create a separate site for each city.

The site is sometimes also used in small areas. For example, you can make a project for an organization with two offices located not far away. The two offices are interconnected by embroidery with cost-based cost, the organization can create two separate sites to reduce the amount of Active Directory data traffic transmitted in the WAN link.

Whenever a change occurs to the domain partition on a domain controller, that change will be replicated to other domain controllers in the site immediately. However, the working copy process is quite different from the domain controllers that exist in other sites. Creating a replica will change domain controllers in another site, but the Active Directory uses bridgehead servers.

The bridgehead server is a domain controller that has a linked site link. This server will push updates to the bridgehead server on the other end of the site link according to the replication scheme. The remote bridgehead server will receive the upgrade and push it to all domain controllers in the remote site. In this way, the upgrade is only sent via the site link (usually a WAN link) once, unlike the domain controller's case in each remote site.

These basic concepts are also applicable to AD LDS environments. We will show you how to create an AD LDS site in Part 6.

Conclude

In the next part of this series, we will explore some of the concepts discussed in this section by creating sites in an AD LDS environment.