Configuring the Active Directory Lightweight Directory Services (Part 7)

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

This article continues the discussion of the Active Directory Lightweight Directory Services by discussing site link objects, inter-site replication, and some considerations for disaster recovery planning.

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

Introduciton

In my previous article in this series, I showed you how to create AD LDS site objects. In this article, I want to conclude the series by showing you how to create site link objects and how to configure inter-site replication.

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.

Conclusion

In many ways, AD LDS behaves similarly to the Active Directory database. As such, you can plan for an AD LDS implementation in much the same way that you would plan for an Active Directory deployment.

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

Advertisement

Featured Links