2

There are lots of articles out there describing how to architect your replication toplogy, and all the reasons why, and they all boil down to conserving bandwidth, and achieving a convergence time that is acceptable for your organizaiton.

In my mind, AD replication is a tiny amount of data, and I think I would like to tweak the replication frequency to absolute maximum speed. (Which is 4 times per hour within a site, and once every 15 minutes inter-site, whereas the default is 1 time per hour within a site, and once every 180 minutes inter-site.)

I browsed around and found a list of ports & protocols used in AD replication, and there are a ton. LDAP, Kerberos, Ping (ICMP Echo), RPC, etc. Sure I can create a wireshark capture to view that traffic, but it would be a huge massive capture filter, very complex.

So my question is:

Does anybody know any way to measure the bandwidth used by AD replication? I am looking to test my assumption that it's a tiny amount of traffic, basically irrelevant in the modern age where the slowest connection is 3 Mbit.

Edward Ned Harvey
  • 512
  • 3
  • 6
  • 14
  • 1
    How big of a topology are you trying to monitor? The reason for the focus is because when you try to scale out AD, it becomes a bigger concern. Depending on how you setup trusts and/or forest, the AD traffic can be significantly larger. Most networks don't have infinite bandwidth. Even if it is only .5% that can be a big deal in large scale networks. – lmickh Mar 12 '13 at 23:00

1 Answers1

2

There's no one single performance counter that represents the "total" bandwidth used by Active Directory. Active Directory is comprised of a lot of individual services. And while there are many combinations of performance counters that measure network traffic that are relevant to AD, those counters could be combined in a lot of different ways to come up with many different views of "how much bandwidth is AD using?" For instance, do you want to include DNS queries and responses or not? Replication of DNS zones? Do you want to include DFS replication of sysvol or not?

However you're right. I've worked in a production domain where the inter-site replication schedule was cranked all the way down to 15 minutes and everything worked just fine. As long as you have the bandwidth to support it there is nothing technically wrong with doing that. (For the record it was a domain of 3 sites with dedicated WAN links, putting the 3 sites in a full-mesh configuration, of about 50-100 computers per site and 250 users total. So a small domain.) And yes I think your assumption is correct in that bandwidth was a lot more scarce when AD was first designed, and these days we typically have much faster links, and so AD is not typically a burden at all on our networks - not even over a WAN or VPN connection.

In addition to perfmon, you can also use Resource Monitor (resmon) and get a pretty good idea of the kind of network bytes being transferred by various important processes on a domain controller, such as lsass.exe, dns.exe, dfsrs.exe, etc.

Or if your domain controller is just a domain controller and not hosting a bunch of non AD related services too, just look at the total bytes transferred over the NIC and you'll have a pretty good idea of how much bandwidth your DC uses.

Edit: Just to keep going on this topic, another thing that makes it difficult is that many of these perfmon counters come and go, such as \DFS Replication Connections\Bytes Received Per Second." The instances of this object appear and disappear as new connection objects are made, often dynamically.

Edit #2: Here's a pretty decent article about AD bandwidth, and even some good perfmon counters to look at. Notice that it's pretty old, however, bandwidth concerns were more important back then than they are now so it's still relevant to this question: http://technet.microsoft.com/en-us/library/bb742457.aspx

Please keep in mind that replication has gotten more efficient since Windows 2000 with advancements such as linked value replication.

Ryan Ries
  • 55,481
  • 10
  • 142
  • 199
  • Thanks for that article. They have a section "How to Measure Replication Traffic," which mostly re-states the problem in this question. But they also recommend some specific metrics in perfmon, that relate to replication. The NTDS / DRA objects. They also have measured how many bytes per object type, so we know a ballpark expectation. 1 User replicated, 13K bytes (13,019). 1 password change, 10,805 bytes. I'll go look at the NTDS / DRA objects and see if that amounts to an actual answer. – Edward Ned Harvey Mar 13 '13 at 11:50
  • Yup, this is looking good. By using perfmon to measure NTDS DRA bytes, I see, 7k traffic to replicate when nothing changed, 8k + 2k up and 1300 bytes * 3 down to replicate user creation, 7k to replicate a single password reset. This is definitely useful. – Edward Ned Harvey Mar 13 '13 at 12:18