joeware - never stop exploring... :)

I responded to an ActiveDir Org post that was talking about finding the DCs that are not doing well when you see an Event ID 1864 like so

Event Type:    Error
Event Source:    NTDS Replication
Event Category:    Replication
Event ID:    1864
Date:        10/2/2009
Time:        12:32:57 AM
User:        NT AUTHORITY\ANONYMOUS LOGON
Computer:    DC1
Description:
This is the replication status for the following directory partition
on the local domain controller.

Directory partition:
DC=root,DC=corp

The local domain controller has not recently received replication
information from a number of domain controllers.   The count of domain
controllers is shown, divided into the following intervals.

More than 24 hours:
1
More than a week:
1
More than one month:
1
More than two months:
1
More than a tombstone lifetime:
1
Tombstone lifetime (days):
60
Domain controllers that do not replicate in a timely manner may
encounter errors. It may miss password changes and be unable to
authenticate. A DC that has not replicated in a tombstone lifetime may
have missed the deletion of some objects, and may be automatically
blocked from future replication until it is reconciled.

To identify the domain controllers by name, install the support tools
included on the installation  CD and run dcdiag.exe.
You can also use the support tool repadmin.exe to display the
replication latencies of the domain controllers in the forest.   The
command is "repadmin /showvector /latency <partition-dn>".

with an AdFind command and got a few emails back along the lines of “What in the world is that command doing???”.

So here is the “biggest” command of the bunch, understand this will help you understand any of the other commands in the posting.

adfind -h DCName -config -s base msDS-NCReplCursors;binary -metasort lastsync -mvnotfilter msDS-NCReplCursors=deleteddsa

The output from this command looks like…

AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009

Using server: JOEWARE-DC1.joeware.local:389
Directory: Windows Server 2003
Base DN: CN=Configuration,DC=joeware,DC=local

dn:CN=Configuration,DC=joeware,DC=local
>msDS-NCReplCursors;binary:     214151 2009/10/02-16:55:51      Default-First-Site-Name\JOEWARE-DC2
>msDS-NCReplCursors;binary:     540610 2009/10/02-17:28:14      Default-First-Site-Name\JOEWARE-DC1

1 Objects returned

though you will most likely see more servers listed. If you only have two DCs, you really don’t need something like this to tell you whether you are replicating or well or not.

So anyway… on to the explanation of what is going on…

At its core, AdFind is a “simple” LDAP query tool. Every LDAP query comes down to a couple of basic components

Host and port to query

Search Base

Search Scope

Search Filter

Then from there you move into modifiers… What attributes to return and what session options to use and how AdFind should manipulate the output. These will impact how the query runs (like showing deleted objects) or what info is returned (like specifying you only want the displayName attribute) and how it is outputted by the tool. AdFind allows you to tweak most of that with switches. If you know what you are looking for, you can usually find it. The problem comes in if you aren’t familiar with what AD can do and then you just see a bunch of switches doing stuff that you don’t have a clue about. Heck even some attributes people don’t have a clue about… Like msDS-NCReplCursors, most people haven’t a clue what a replication cursor is or that the info was even available through LDAP queries. You can get a little info from MSDN but even that isn’t too awesome.

In terms of the points above combined with the adfind command in question…

First the basic LDAP stuff…

• Host|Port —- -h DCName – Port isn’t specified but defaults to 389 for query. As for the host, if this isn’t specified, the system will ask the Windows LDAP Library to use the “default” DC for the machine the tool is running on.
• Search Base —- -config – this is a shortcut for the search base. When the tool connects to the DC, it enumerates the rootdse and pulls out the configuration context NC and adds that to the query as if you specified it with the –b switch.
• Search Scope —- -s base – this is the BASE type search, i.e. give me the exact object and only that object that I specified as the search base.
• Search Filter —- This isn’t specified in this query because I am asking for the BASE object. I don’t have to specify what I want in a filter because I already did with the combination of the scope and the search base. However, AdFind will send along objectclass=* which will match any object.

So now after the basics, you have attributes and session options from an LDAP standpoint…

• You are specifying a specific attribute – msDS-NCReplCursors and you are doing a little LDAP RFC trick called specifying the encoding option. This encoding specified by ;binary is telling AD that I want the data back in binary regardless of the default format to return that attribute. The default happens to be an XML stream. I prefer binary because the DC doesn’t have to work to marshall (i.e. convert) the binary (which it uses internally) to XML to pass it over the wire to me. That saves on DC time for both the marshaling work but also the amount of data it has to push over the network. And it saves my client from having to take in all that network traffic and to unmarshall the stream into something I can consume. This encoding option doesn’t do something for all attributes, but it can be very useful where it does. There is a massive savings on the wire by getting this data in binary versus XML.

The rest of the switches are modifiers to tell AdFind how to handle the output. These have nothing to do with what is sent to the DC, it is all handled locally.

• -metasort lastsync – this tells AdFind to sort the data in the Cursor attribute by the lastsync time. You can read more at adfind /meta?
• -mvnotfilter msDS-NCReplCursors=deleteddsa – tells AdFind that for the multi-value attribute msDS-NCReplCursors, it should filter out (NOT filter) and lines that have deleteddsa in the attribute value. If you wanted to see all of the deleteddsa’s then you could reverse this and use -mvfilter msDS-NCReplCursors=deleteddsa which says that it should filter the multi-value attribute and only show values with that string.

Everything you can do with AdFind and AdMod break down like this. It is simply basic LDAP queries that are tweaked by whatever methods the OS allows and then filtered or decoded in whatever ways I can dream up to be useful.

    joe