Active Directory Light Directory Service (ADLDS)

ACTIVE DIRECTORY LIGHTWEIGHT DIRECTORY SERVICE: Introduction The Lightweight Directory Service is useful for situations in which applications need access to a directory service, but you do not want to risk compromising your Active Directory database. In this article, you will be introduced to the Lightweight Directory Services, its uses, and capabilities. When Microsoft introduced the Active Directory with Windows 2000, it didn’t take long before people began to realize that the Active Directory was really little more than a centralized database, and that the Active Directory could be used for purposes for which it was never intended. For a while, it seemed as though almost every software vendor was designing their wares to be Active Directory integrated. Many such applications stored their configuration information in the Active Directory, and some even whet so far as to actually treat the Active Directory as an alternative to a SQL database and store actual application data in the Active Directory database. Today, most of the third party software publishers seem to take less invasive approach to the way that they interface with the Active Directory. Many applications read Active Directory data, but not nearly as many applications seem to store data within the Active Directory as did a few years back. Although I can only speculate on the reasons for this, I suspect that it has something to do with the fact that the Active Directory has become a critical component of the network infrastructure, and many administrators are reluctant to perform unnecessary schema extensions (which are almost always necessary to support applications that store data within the Active Directory). Even though software publishers may not use the Active Directory to quite the extent that they once did, I think that it is safe to say that the Active Directory can be very useful for supporting various applications. To show you what I mean, consider the fact that Microsoft still designs many of their server applications with a high degree of Active Directory integration. Exchange Server 2007 and Exchange Server 2010 for example, are designed in such a way that all of the server configuration information is stored in the Active Directory, rather than being stored locally on the server. The advantage to doing so is that it makes it possible to regenerate a failed server on the fly. Suppose for instance that you had a catastrophic hard disk failure on an Exchange 2010 server that was hosting the Hub Transport Server Role. Because of the way that Exchange stores its configuration information in the Active Directory, you wouldn’t even have to restore a backup in order to fix the problem. Instead, you would start out by resetting the Computer account for the failed server within the Active Directory. You would then install Windows and any applicable service packs onto a new server. Next, you would assign that server the same computer name as your failed server had used, and join the new server to the Active Directory. Because you reset the Active Directory computer account, the new server is able to use it. From there, fixing the problem is as simple as running Exchange Server’s Setup program with a special switch. Setup installs the necessary binaries, and then configures the server according to the configuration information found in the Active Directory. The new server can be up and running in less than an hour, and without ever restoring a backup. My point is that the Active Directory can be very useful for application support, but that many software publishers are reluctant to use it to the extent that Microsoft does, because of the stigma that’s attached to making Active Directory schema extensions. Another reason why you don’t see more software publishers storing a lot of data in the Active Directory has to do with Active Directory replication. Generally speaking, any data that is stored in the Active Directory

must be replicated to all of the domain controllers in the domain (possibly even all of the domain controllers in the forest). As such, if an application were to store a large volume of data in the Active Directory, that data could impact the speed of the normal replication process - especially if that data changes frequently. In spite of these challenges, there is a way to reap the benefits of Active Directory integration, without impacting your Active Directory database in the process. Windows Server 2008 and Windows Server 2008 R2 include a service called the Active Directory Lightweight Directory Service, or AD LDS. A similar service also exists in Windows Server 2003, but goes by the name Active Directory Application Mode (or ADAM). In case you are not familiar with AD LDS, it provides you with an environment that is very similar to, but completely separate from, the Active Directory. AD LDS is a standalone service that has no dependency on the Active Directory Directory Service. In fact, it is common to deploy AD LDS in environments in which no Active Directory domains exist. A perfect example of such a situation is Microsoft Exchange Server. Earlier I said that Exchange Server 2007 and 2010 are both designed to store all of their configuration information in the Active Directory database. There is one big exception to this however. Exchange Server defines a series of roles that dictate how an Exchange Server is configured, and what tasks the server performs. All but one of the server roles are designed to store the server configuration in the Active Directory. The server role that does not use the Active Directory is known as the Edge Transport Server Role. The Edge Transport Server is designed to reside at the network perimeter and keep the other Exchange Servers from being directly exposed to the Internet. Because the Edge Transport Server is exposed to various Internet based threats, making it a member of an Active Directory domain could be a potential security risk. If someone were able to compromise the edge transport server, they may be able to use it to gain information about the Active Directory. To keep this from happening, the Edge Transport Server cannot be a domain member, and it cannot host any other Exchange Server roles. Even so, the Edge Transport Server does require access to a minimal amount of Active Directory information so that it can do its job. Rather than provide the server with direct access to the Active Directory, Microsoft has designed the Edge Transport Server role to use AD LDS. One of the backend Exchange Servers reads the required information from the Active Directory, and sends the information to the AD LDS partition on the Edge Transport Server. That way, the Edge Transport Server has access to the information that it needs, without being able to access the Active Directory. Incidentally, the Edge Transport Server also stores its own configuration information in the AD LDS partition, just as other Exchange Server roles store configuration information in the Active Directory.

The Planning Process Planning for the deployment of AD LDS can actually be something of a trial and error experience because Microsoft really doesn’t give you a lot to go on. If you look at Microsoft’s AD LDS Overview on TechNet, you can see that the Hardware and Software Considerations section consists of a block of text telling you to “Use performance counters, testing in the lab, data from existing hardware in a production environment, and pilot roll outs to determine the capacity needs of your server.” So what is Microsoft really saying here? Well, I think that the statement in the paragraph above can best be summarized like this:

In order to deploy AD LDS, one needs only to have a server that is capable of running Windows Server 2008. However, depending on how AD LDS is being used the server may have to support a considerable workload. It is therefore necessary to take measures to ensure that your server hardware is up to the job. If this statement is true, then the most logical approach to AD LDS planning is to take a look at the types of resources AD LDS consumes, and base any capacity planning efforts on those types of resource consumption. Being that Microsoft doesn’t seem to provide a lot of clear guidelines for AD LDS capacity planning, I tend to think that one of the best approaches is to treat the capacity planning process similarly to the capacity planning process that you would use for domain controllers. After all, an AD LDS server is very similar to a domain controller. Both AD LDS servers and domain controllers host nearly identical directory services. Of course there are differences that you have to keep in mind. Active Directory capacity planning usually takes the number of users into account, while AD LDS capacity planning is usually more about anticipating the number of LDAP requests that will be made against the server. However, both Active Directory and AD LDS capacity planning often require you to plan for things like topology and replication.

The Differences between Domain Controllers and AD LDS Servers Of course even though domain controllers and AD LDS servers are very similar at the architectural level, the simple fact that domain controllers are used to authenticate logins and implement Windows security policies means that there are some aspects of domain controller planning that simply will not apply to the planning process for AD LDS. One such difference is that AD LDS does not use the concept of forests like the Windows Active Directory does. In an Active Directory environment, a forest is a collection of domains. Every forest is completely independent, although forests can be joined together through the use of federated trusts. AD LDS does not use the concept of forests and domains like Windows domain controllers do. Instead, the primary structural element used by AD LDS is that of a service instance (which Microsoft often refers to as an instance). An instance refers to a single AD LDS partition. Each instance has its own individual service name, directory data store, and service description. As I’m sure you probably already know, a Windows domain controller can only service a single domain. In contrast, a single server running AD LDS can host multiple instances. This means that a single AD LDS server can contain multiple directories. Of course this raises an interesting question. In an Active Directory environment, clients communicate with domain controllers using the Lightweight Directory Access Protocol (LDAP). Like most other protocols, LDAP is designed to use specific port numbers. For example, LDAP typically uses port 389 for directory queries. If LDAP communications need to be encrypted then port 636 is uses instead. Domain controllers that are functioning as global catalog servers use ports 3268 and 3269 for global catalog related functions. With all of this in mind, you may be wondering which ports AD LDS uses. Well, AD LDS does not have to worry about performing any global catalog functions, so we can rule out the use of ports 3268 and 3269 right off the bat. AD LDS does however make use of ports 389 and 636 in exactly the same way that a domain controller would. So what happens if a server is hosting multiple AD LDS instances? Typically, the first instance to be created would be assigned to use ports 389 and 636. When the second instance is created, Windows sees that these ports are in use, and begins scanning for unused ports beginning with port 50,000. Assuming that port 50,000 is available it will be used for standard LDAP communications with the second AD LDS instance. Port 50,001 will be used for SSL encrypted LDAP communications with the second AD LDS instance.

If you were to create a third AD LDS instance on the server, then Windows would see that ports 389 and 636 were in use, so it would begin looking for unused ports starting with 50,000. Since ports 50,000 and 50,001 have already been assigned, the third LDAP partition will be assigned to ports 50,002 and 50,003.

DNS Requirements Another difference between the Active Directory and AD LDS is that the Active Directory is totally dependent on DNS servers. Without DNS, the Active Directory cannot function. AD LDS on the other hand does not require DNS. In some ways this makes sense. The Active Directory uses DNS as a mechanism for maintaining the domain hierarchy. There is no domain hierarchy associated with AD LDS, so DNS is unnecessary.

Installing the Active Directory Lightweight Directory Service Installing AD LDS is actually a very simple process. To do so, open the Server Manager, and then click on the Add Roles link. When you do, Windows will launch the Add Roles Wizard. Click Next to bypass the wizard’s welcome screen and you will be taken to a screen that displays all of the available server roles. Select the Active Directory Lightweight Directory Services check box, as shown in Figure A.

Figure A: Active Directory Lightweight Directory Service. Click Next, and you will see an introductory screen that explains what the AD LDS is and what it does. Click Next and Windows will display a confirmation message indicating that the AD LDS server role is about to be installed. Click theInstall button to begin the installation process.

The entire installation process usually only takes about 30 seconds to complete. After the server role finishes installing, click the Close button to complete the installation process. Unlike some of the Windows 2008 server roles, installing the AD LDS role does not require you to reboot the server. The concept of an instance is unique to AD LDS (as opposed to the Active Directory). As I mentioned in a previous article, a single Windows 2008 server can host multiple directories. Each of these directories is referred to as an instance. You must assign a name to each instance that you create. The name that you choose is used as a mechanism for uniquely identifying the instance on the server. In addition to assigning the instance a name, you will also have to assign the instance a port number. Normally, LDAP communications take place over port 389 and SSL encrypted LDAP communications take place over port 636. You can use these port numbers for AD LDS, but only if you do not plan to install the Active Directory Directory Services on the server. One thing to keep in mind is that each AD LDS instance requires a unique port number. Of course this holds true only when there are multiple AD LDS instances present on a single server. If you have a dedicated server for each AD LDS instance, then each instance will be able to use Ports 389 and 636 (assuming that the server isn’t also acting as a domain controller). Finally, each AD LDS instance has a corresponding application directory partition. When you create an application directory partition, you will be required to provide it with a name. The name that you use can be in either X.500 format or it can be in FQDN format. Now that I have explained what elements are required for creating an AD LDS instance, let’s go ahead and create one. Begin the process by opening the Active Directory Lightweight Directory Services Setup Wizard. You can find a shortcut to this wizard on the server’s Administrative Tools menu. When the Active Directory Lightweight Directory Services Setup Wizard starts, click Next to bypass the wizard’s Welcome screen. At this point, you will see a screen similar to the one shown in Figure 1, asking if you want to create a unique instance or a replica of an existing instance. Since we are setting up a new instance, choose the A Unique Instance option. I will be discussing replica instances in Part 4.

Figure 1: Tell Windows that you want to create a unique instance. Click Next and you will be promoted to provide a name and an optional description for the instance that you are creating, as shown in Figure 2. For the sake of demonstration I will be using the default instance name (which is Instance1). In the real world however, I recommend using a more descriptive name.

Figure 2: You must provide a name and an optional description for the instance that you are creating. When you click Next, you will be taken to the screen shown in Figure 3. As you can see in the figure, Windows defaults to using port number 50,000 for LDAP communications with the new instance, and port number 50,001 for SSL encrypted LDAP communications. You can change these port numbers to anything that you want (including 389 and 636) so long as those port numbers are not already in use on the server and you do not plan to make the server a domain controller.

Figure 3: Windows defaults to using ports 50,000 and 50,001 for use with the new AD LDS instance. Click Next, and you will be taken to the screen shown in Figure 4. As you can see in the figure, this screen asks you if you want to create an application directory partition. The application directory partition is essentially a directory enabled repository that you can use for storing application data.

Figure 4: You will almost always want to go ahead and create an application directory partition. Since the whole point of creating an AD LDS instance is to allow for application data to be stored in a directory partition, you will almost always choose the option that creates a new application directory partition. There are really only two situations in which you would not want to create an application directory partition. You would obviously not want to create an application directory partition if you wanted to manually create the partition later on. The other situation in which you wouldn’t want to create an application directory partition would be when you plan to install an application that automatically creates the necessary partition itself. As I explained earlier, you must provide a name for the application directory partition. You must enter this name as a distinguished name. According to TechNet “AD LDS supports both X.500 style and Domain Name System (DNS) - style distinguished names for top level directory partitions”. Having said that, I have to tell you that I have never seen a DNS style distinguished name used for an application directory partition in the real world. If you look back at Figure 4, you can see that even Microsoft seems to give preference to X.500 style distinguished names because the example distinguished name shown in the screen capture is in X.500 style format. Regardless of the type of distinguished name that you choose to enter, it is important to get the name right on the first try. Otherwise, Windows will allow you to get all the way to the end of the wizard before giving you an error. After you have provided a distinguished name for the partition that you are creating, click Next and you will be prompted to specify a path beneath which to store the data files and the data recovery files that are to be used with the AD LDS instance. This portion of the wizard, which you can see in Figure 5, should seem familiar to anyone who has ever set up an Active Directory domain controller.

Figure 5: You must provide a path to be used by the AD LDS database. In an Active Directory environment, it is usually acceptable to use the default path. When it comes to AD LDS however, you may want to redirect the data files and the data recovery files to a high speed or fault tolerant array, depending on how extensively the AD LDS instance will be used. After providing the necessary paths, click Next and you will be prompted to provide a service account for use with the AD LDS instance. You can use a network service account, or you can provide a domain service account. Of course servers that host AD LDS instances are not always domain members, so in some cases you may be forced to use network service accounts. Click Next, and you will be prompted to specify the name of a user or a group who should have administrative access to the partition that you are creating. By default, Windows will use the account that you are logged on with when you create the account, as shown in Figure 6, but you are usually going to be better off manually specifying an administrative group.

Figure 6: Specify the name of the user or group that should have administrative control over the AD LDS instance. After clicking Next, you should see a screen asking you which LDIF files you want to import. The LDIF files that you select will establish the schema for the instance. You are free to select any of the LDIF files or any combination of the files. The documentation for the application that will be making use of the AD LDS instance should provide you with guidance as to which LDIF files to import. When you click Next, you should see a summary of the options that you have selected throughout the wizard. Assuming that everything appears to be correct, click Next and the AD LDS instance will be created. When the process completes, click Finish to close the wizard.

Deploying the Active Directory Lightweight Directory Service Role Before you can create a replica of your AD LDS instance, you must install the Active Directory Lightweight Directory Service Role onto the server that will host the replica that you are creating. The procedure for doing so is similar to the procedure that you used when you created your first AD LDS instance, but I will go ahead and provide you with a brief set of instructions so that you don’t have to go back and look at the previous article. To install the AD LDS role, open the Server Manager and then select the Roles container and click the Add Roles link. When you do, Windows will launch the Add Roles Wizard. Click Next to bypass the wizard’s Welcome screen and you will be taken to a screen that asks you which roles you would like to install. Select Active Directory Lightweight Directory Services check box. At this point, you should see a dialog box similar to the one shown in Figure A, telling you that some additional role services are required. Simply click the Add Required Role Services button to install the required role services.

Figure A: Click Add Required Features and then click Next. Click Next, and the wizard will display a screen introducing you to the Active Directory Lightweight Directory Services. Go ahead and click Next to bypass this screen. You should now see a confirmation screen which asks you to verify that you do indeed want to install the AD LDS role. Assuming that the information displayed on the confirmation screen is correct, go ahead and click Install. Windows will now install the AD LDS role service. When process completes, click Close.

Creating the Replica So far we have installed the AD LDS role, but we have not yet created a replica of our previously existing AD LDS instance. To begin creating the desired replica, open the Active Directory Lightweight Directory Services Console, which is located on the Administrative Tools menu. When the console opens, Windows will launch the Active Directory Lightweight Directory Services Setup Wizard. Click Next to bypass the wizard’s welcome screen. You should now see a screen similar to the one shown in Figure B, asking you if you want to create a unique instance or a replica of an existing instance. Select the A Replica of an Existing Instance option and click Next.

Figure B: Select the Replica of an Existing Instance option and click Next. At this point, you will be taken to the screen shown in Figure C. As you can see in the figure, the wizard asks you for an instance name. The name that you enter should match the name of the instance that you want to replicate. Depending on what you called your instance, this dialog box may be filled in automatically.

Figure C: Specify the name of the instance that you want to replicate, and then click Next. Click Next and you will be taken to the screen shown in Figure D, which asks you to specify the port numbers that the instance will use. If possible, you should try to use the same port numbers as are being used by the original copy of the instance. Of course this may be impossible if the server hosting the replica has other instances installed on it, or if the server is also functioning as a domain controller.

Figure D: You must tell Windows which ports you want to use with the replica that you are creating. The next screen that you will encounter tells you that you must join a configuration set. A configuration set is nothing more than a group of instances that all share a common configuration and schema. In this case, the configuration set will be composed of the original instance and the replica that you are creating. Therefore, all you have to do is to provide the full DNS name of the server hosting the instance that you will be replicating, along with the LDAP port number that the instance is using. You can see an example of this in Figure E.

Figure E: You must provide the FQDN of the server hosting the instance that you are replicating. The next screen that you will encounter asks you to provide a set of credentials that have administrative permissions for the configuration set. Just enter a set of administrative credentials as shown in Figure F, and click Next.

Figure F: You must provide a set of administrative credentials for the configuration set. At this point, you should see a screen similar to the one shown in Figure G. As you can see in the figure, you must select the check box corresponding to the partitions that you want to replicate.

Figure G: Select the check boxes corresponding to the partitions that you want to replicate. Click Next and you will be taken to a screen which asks you for the path in which the data files and data recovery files should be stored. You can click Next to accept the defaults (which are shown in Figure H) or you can provide alternate paths.

Figure H: You must tell Windows where the AD LDS data should be stored. You must now provide the wizard with a service account that it can use for AD LDS operations. As you can see in Figure I, you can either use a network service account or you can specify a specific account.

Figure I: You must provide the wizard with a service account to be used for AD LDS operations. Finally, you will have to grant either a user or group administrative privileges for the AD LDS instance. As you can see in Figure J, the wizard allows you to either use the current user or to manually specify a specific user or group name.

Figure J: You must delegate administrative privileges for the instance. When you click Next, Windows will display a summary screen containing all of the configuration options that you have entered, as shown in Figure K. Take the time to read over this summary screen to make sure that everything is correct. Assuming that all is well, click Next and Windows will begin configuring the AD LDS instance. When the process completes, click Close to close the wizard.

Figure K: Take the time to read the summary screen to verify that the server will be correctly configured.

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.

Defining an AD LDS Site As strange as it may sound, the tool that you will use to create an AD LDS site is the Active Directory Sites and Services console. Even though this utility is primarily used for managing Active Directory environments, it can be used to manage Ad LDS sites almost as easily. Begin the process by opening the Active Directory Sites and Services console. When the console opens, right click on the Active Directory Sites and Services container and select the Change Domain Controller command from the resulting shortcut menu. If you are performing this action from a domain controller then you will see a screen similar to the one that is shown in Figure A, which lists all of the known domain

controllers. If you look carefully though, you will notice that the Change To section of the dialog box contains an option labeled This Domain Controller or AD LDS Instance.

Figure A: You will have to use the Active Directory Sites and Services console to create an AD LDS site structure. At this point, you must select the This Domain Controller or AD LDS Instance option. You will notice that when you do this, nothing changes. The dialog box still displays the same list of domain controllers. However, if you look at the figure above, you will notice that just above the first domain controller is a line that says Type a Directory Server Name [:port] Here. You must click on this line and then type the Fully Qualified Domain Name (FQDN) of your AD LDS server followed by a colon and the port number that has been assigned to the instance that you want to connect to. As you may recall, when you first created the instance, you were required to provide a name for the instance as well as an LDAP port number and an SSL port number, as shown in Figure B.

Figure B: The AD LDS Setup Wizard required you to assign a port number to the instance. If you used the default settings then the first instance is named Instance1 and is assigned port number 50000, as shown above. If you create additional instances (and use the default settings) then you can figure out the port number by adding two to the port number for each instance that you create. For example, Instance2 would use a default port number of 50002 and Instance 3 would use 50004. For right now, we must type the server’s fully qualified domain name (not the instance name), and the port number that has been assigned to the instance that you want to connect to. For example, I installed AD LDS onto a domain controller named Lab-DC2 in a domain named lab.com. Therefore, if I wanted to connect to the default instance (using the default port number), I would type: Lab-dc2.lab.com:50000 When you click OK, you will see a message similar to the one shown in Figure C, asking you if you want to use a different forest rooted domain. Even though we aren’t technically connecting to an Active Directory domain, go ahead and click Yes. You will now be connected to the AD LDS instance.

Figure C: You must click Yes to connect to the AD LDS instance.

Creating AD LDS Sites Now that we have connected to the AD LDS instance, it is time to define a site topology. Generally speaking, the site structure that you create should mimic your network topology, with each site link corresponding to a WAN link. If there is high speed (LAN) connectivity between two AD LDS instances then those instances should be placed within a common site. To create a site, just right click on the Sites container in the Active Directory Sites and Services console, and choose the New Site command from the resulting shortcut menu. When you do, you will be prompted to specify a name for the site that you are creating. You will also be prompted to select a site link for the site to use to connect to other sites, as shown in Figure D. Microsoft provides you with a default site link (which is named DEFAULTSITELINK), but you have the option of creating additional site links if you choose.

Figure D: You must provide Windows with a site name and choose a site link to associate with the site. When you click OK, the site will be created. However, you will see a message telling you that you have some more work to do. As you can see in Figure E, you must still link the site to some other sites, and associate one or more subnets with the site. The dialog box also tells you that you must install or move one or more domain controllers into the site. However, this message is incorrect. The message is displayed because AD LDS assumes that you are working in an Active Directory environment. Since we are working with AD LDS, domain controllers are not technically required. You must however, move your AD LDS instances into sites.

Figure E: You still have some configuration work to do.

Assigning Subnets

As I explained earlier, each Active Directory site should correspond to a different subnet. To provide AD LDS with the subnet information for you network, expand the Sites container and then right click on the Subnets container and choose the New Subnet option from the shortcut menu. You must enter a subnet prefix, as shown in Figure F. The Prefix that you enter will also be listed as the Prefix Name in Active Directory Domain Services, but in reality it will be limited to the Configuration Set. Finally, you must choose a site to associate with the IP address prefix, as shown in the figure below.

Figure F: You must assign an IP address prefix to each site.

Moving a Server to a Different Site By default, each of your AD LDS servers are placed into a site named Default-First-Site-Name. If you are going to be using a multi-site configuration then you will need to move the servers from the default site and into the appropriate site. For example, you saw in the previous figure that I named my sites after various American cities, which represent the geographic locations of the AD LDS servers. Therefore, the next step would be to move my AD LDS instances from the default location and into the site that corresponds with the appropriate city.

To move a server, simply expand the site container and select the Servers container beneath it. Right click on the listing for the server and choose the Move command from the shortcut menu. When you do, you will see a dialog box asking you which site you want to move the instance into, as shown in Figure G. Make your selection and click OK to move the instance.

Figure G: Select the site that you want to move the instance into, and click OK.

Site Link Objects Site link objects are logical AD LDS structures that mimic your network topology. Suppose for instance that we created AD LDS sites in three different cities – Miami, Las Vegas, and New Orleans. Now, let’s pretend that both Miami and New Orleans are connected to Las Vegas by a WAN link, but that there is no WAN link between Miami and New Orleans. You would take this topology into account when creating your site links. As a general rule, each site link should represent a network connection (usually a WAN connection).

Defining Site Link Objects Creating a site link object is simple. To do so, open the Active Directory Sites and Services console and then right click on the Active Directory Sites and Services container and select the Change Domain Controller command from the resulting shortcut menu. When prompted, specify the name and the port number of your AD LDS server instance. Once you have established connectivity to an AD LDS instance, navigate through the console tree to Active Directory Sites and Services | Sites | Inter-Site Transports | IP. Upon selecting the IP container, you should see the default IP site link (DEAULTIPSITELINK), as shown in Figure A.

Figure A: Navigate through the console tree to Active Directory Sites and Services | Sites | Inter-Site Transports | IP. If you want to create a new site link, then right click on the IP container and choose the New Site Link command from the shortcut menu. When you do, you will be prompted to provide a name for the site link that you are creating. Over time it is possible that you may accumulate several different site links as your organization grows. That being the case, I recommend using a descriptive name for your site link. As you define the site link, you will be asked to specify which sites should be included within the site link, as shown in Figure B. Remember that a site link should mimic a WAN connection, and should therefore serve as a logical link between two sites.

Figure B: You must provide a name for the new site link and tell Windows which sites the site link joins. When you click OK, the new site link will be created. By default this new site link uses a cost of 100 default replication interval of 180. However, site links are fully customizable.

Managing Inter-site Replication Now that you have created a site link connector, I want to show you how inter-site replication works in an AD LDS environment. As I mentioned before, replication occurs over the site link every 180 minutes by default. However, you can create a custom replication schedule that better meets your needs. To do so, right click on the site link that you just created and choose the Properties command from the resulting shortcut menu. Upon doing so, Windows will display the properties sheet for the site link. As you can see in Figure C, the properties sheet's General tab provides an option for changing the replication frequency.

Figure C: You have the option of changing the replication frequency to meet your needs. As you look at the figure above, you will notice that the properties sheet also contains a Change Schedule button. When you click this button, Windows displays a calendar view of the replication schedule, as shown in Figure D. You can use this calendar view to control when replication does and does not occur. For example, if you experience a lot of WAN congestion during peak hours, then you might configure the replication schedule so that sites only replicate during off peak hours.

Figure D: Windows Server 2008 allows you to define a custom replication schedule.

As you look at the calendar view shown in the figure above, one of the things that you will notice is that the calendar view only allows you to enable or disable replication during a particular time of the day. The calendar does not give you the option of changing the replication frequency. The replication frequency is controlled on a global basis (for the site link) on the site link’s properties sheet. As such, no option exists for configuring a site to replicate more frequently during some parts of the day and less frequently during other parts of the day.

Disaster Recovery Considerations Throughout this article series, I have discussed the Active Directory Lightweight Directory Services from an introductory standpoint. If you have made it this far into the series though, I am guessing that you are eventually planning on deploying at least one real world AD LDS instance if you have not already. As such, I wanted to conclude the series by talking about some disaster recovery considerations. The first thing that I want to explain is that although I have spent the last couple of articles talking about replicating the Active Directory Lightweight Directory Services instances that you have created, creating replicas is no substitute for creating backups. Suppose for a moment that you had several replicas of an AD LDS instance. If one of those replicas experienced a hard drive failure then you wouldn't have any loss of functionality because the other replicas remain in a functional state. However, suppose that some bad data was accidentally added to one of your AD LDS replicas. That bad data would be replicated to all of the other replicas. The only way to revert the data to its previous state would be to restore a backup. Backup planning for the Active Directory Lightweight Directory Services is actually very easy. You can backup an AD LDS instance in exactly the same way as you would backup a domain controller. Virtually any backup application can be used to back up an AD LDS instance, including Windows Server Backup. Most of your backup planning efforts should go into capacity planning and determining the appropriate backup frequency. Depending on how heavily an AD LDS instance is used (and depending what it is used for), the instance can accumulate data very quickly. As such, you may determine that performing a traditional nightly backup of the instance is too risky because if a failure were to occur, you could potentially lose any data that has accumulated since the time that the last backup was made. If the potential for data loss is of concern to you then you might consider implementing a Continuous Data Protection solution, such as Microsoft’s System Center Data Protection Manager. System Center Data Protection Manager can be configured to backup data every fifteen minutes rather than once every twenty four hours like a traditional nightly backup does. Whatever backup solution you choose though, you must ensure that it can accommodate the ever growing size of your AD LDS instance.