There are quite a few schedules for Active Directory replication – some of which we are very aware and some of which are better hidden and oft forgotten. Let’s start by looking at the connection object schedules.
Connection Objects
Connection objects are created for replication partners with schedules which vary by whether the partner is intrasite or intersite. Schedules for intersite partners are generated from the site link on the transport – a mix of the schedule and the replication interval. Schedules for intrasite partners are generated from the NTDS Site Settings object.
Connection objects can have schedules unique from their parent objects. The schedule can be modified through ADSIEdit or LDP and the connection object will remain managed by the KCC. However, the next time that the KCC runs, it will reset the schedule to that of the parent object. You can modify the schedule via AD Sites and Services and the schedule will stick but note that it will also take management of the connection object away from the KCC and put its ownership and management into your hands. Since manual connection objects are generally discouraged, so is modifying the connection object schedule because of the influence of that change. If you want to change a connection object schedule, the recommended method is to make changes to the parent object that determines the schedule.
Intrasite Connection Objects
We know that intrasite partners use change notification to inform their partners of adjustments to the directory service for whatever partition is modified. This replication model does well to cover those partitions that have frequent changes such as the Domain NC or DNS application partitions. How does it work for those partitions that have infrequent changes such as the Schema or Configuration NCs?
Network connectivity has improved greatly over the past few years to where many organizations can follow a true hub-and-spoke topology which often more closely matches their organizational model. It has also allowed replication intervals to be lowered to the 15 minute minimum. In these organizations, we find that the largest replication delta is with our intrasite partners – up to an hour. This catches us off guard for a minute. That doesn’t make sense? Intrasite replication should be the fastest and our in-site partners should always be up-to-date with us, right? Oh yea, change notification is for changes only and we don’t make a lot of changes to the Schema or Config NC. In fact, the last change that I made to the schema was about 10 months ago so why isn’t my largest delta something more like 10 months?
Here’s where intrasite schedules become important. Replication partners shouldn’t be 10 months out of sync on any partition so a schedule is used to set up a pulse interval. Intrasite connection objects are set to pulse on an hourly basis by default. The schedule for these connection objects comes from the NTDS Site Settings Object in the site itself. One thing to note is that both the intrasite connection object and the parent NTDS Site Settings Object each have a replication schedule – a calendar showing the actual interval at which replication will occur. This will be slightly different with intersite replication.
Intersite Connection Objects
For the sake of this entry, we’re going to limit discussion of intersite replication to the IP transport. That’ll work well for me since I don’t really know much about the SMTP transport anyhow.
Intersite connection objects are created by the KCC with a schedule that is derived from the replication availability and replication interval of the site link which has a partner available which shares partitions over the cheapest cost path. While there is quite a bit to dig into there, I want to focus on the replication availability and replication interval.
If you look at the replication schedule on an intersite connection object, you’ll notice that there isn’t a replication availability schedule and a replication interval like there is on the parent IP site link. The schedule on the intersite connection object is the marriage of these two configurations:
- Availability, which tells us when replication windows should be opened.
- Interval, which tells us how often we should pull changes from our partner during that window.
It took me a long time to come to understand this simple principle. Here’s how it finally dawned on me. I think of replication like a city tour company. Our company offers tours which start every 45 minutes (our interval). Of course, that doesn’t mean that we can go to the tour company at 3:45 in the morning and expect to catch a tour. There’s another piece of information that we need – the tour company hours of operation (our availability). If i overlay those two, I can get an idea of when the tours run exactly. And that’s all we’re really doing when we configure the schedule and interval on an IP site link.
Why not just have a schedule on the site link like we do on the NTDS Site Settings object and that can be inherited by intersite connection objects just like it is for intrasite connection objects? Well, I wasn’t there when it was conceptualized so I can’t say for sure but it seems to me that the idea is just to make configuring the replication schedule a little bit easier. It takes much less time to configure a schedule by combining availability and interval than it does to select each 15-minute block individually.
I suppose that you could say that the knock is that it isn’t as granular. I can understand and accept that. In my humble experience as a consultant, I have never had that concern come into play. However, if it is truly an insurmountable concern for you I would say that this is one of those times where a manual connection object may be the organizational best practice.