Follow up on "The Goodness that is Repadmin.exe"

[Alex Simons (AZURE)]

First published on CloudBlogs on Jun, 15 2006

I had some really good questions after the previous post and so I wanted to post the replies so all could see.  Also, stay tuned for next week's post on the usage of /SHOWREPL before we move on to other topics.

Thanks to Matheeshta and IanCurtis for these questions.

************

1. How do I provide multiple dcnames in the dclist option seperated by spaces.

This is described by the "repadmin /listhelp" switch.  Here is the information that gives:

DC_LIST = { <DC_NAME> | * | <part_server_name>* | site:<SITE_NAME> | gc: | fsmo_<FSMO_TYPE>:<FSMO_DN> }

Examples:

"*" = All DCs in the enterprise.

"part_server_name*" = would pick "part_server_name_dc_01" and "part_server_name_dc_02"

but not server "part_server_diff_name".

"site:east_site1" = All DCs in site "east_site1".

"gc:" = All GCs in the enterprise.

"fsmo_pdc:DC=my-corp-dom,DC=com" - repadmin runs against the PDC in the NC "DC=my-corp-dom,DC=com"

"fsmo_istg:east_site1" would pick the ISTG for the east_site1 site.

I get the error - unknown option "secondDC" when I use something like "repadmin /bind firstDC secondDC". Any pointers?

That’s one of the generic errors you can get when it parses the DC_LIST parameter and there is a problem, so the reason is not obvious.   Could you try a wildcard, like *DC and see if that works?

2. Is repadmin /checkprop used for checking the properties of an object across all DCs that have a replica of the NC the object is in? I assume I only have to provide one DC for dclist. As I have to know the NC, originating DC's invocation GUID and the Originating USN to create/modify the object all at once, I assume this can be used to check if a newly created/modified object's status across the domain. Like when a new user has been created.

Yes, that is correct.

3. Does the /async option in repadmin /kcc mean the command will return control to the user quicker or will it also initiate an async replication command on the destination?

The “/async” option let’s the replication on the newly added replication connection take place at a later time rather than immediately.

4. Does repadmin /notifyopt only show notification timings for intersite replication or does it show intrasite replication notification defaults?

It looks to the values for msDS-Replication-Notify-First-DSA-Delay and msDS-Replication-Notify-Subsequent-DSA-Delay in the CrossRef object for the partition specified.

5. Does repadmin /replicate's /full switch ask for the whole NC or does it follow the High Watermark vector tables and the Uptodateness vector tables when asking for changes? Does the /async option mean all NCs are replicated simultaneously?

The /replicate /full sync is starting from scratch (i.e., at the first USN) for that NC.  T he /async option means that the replication does not need to happen immediately.

6. Please explain the repadmin /checkprop option. How is this different from the uptodateness vector table? Why is the originating USN specified? As long as the value I specify is lower than the current local USN for the DC invocation ID supplied, the output is the same.

The difference is that the up-to-dateness vector table is constructed of replica partners if the specified DC, whereas the /checkprop looks to all writables for that NC.  The USN is required for comparison purposes, so it makes sense that you see the output the same for USNs which are lower than the current local one.

And finally, IanCurtis' question:

Looking at your blog, can I use this to see where a user account was deleted.  I've got doubts about my office in Papeete.

The REPADMIN /SHOWOBJMETA switch may be your best bet unless you have the USN of the deletion, but even this will fall short.  What this info will give you is what DCs have not received the deletion update yet-all others (those that have marked the object deleted) will give the generic object not found error mentioned in the post.

The best method to determine who did the deletion and when is to use auditing.  This is the by design method-that's why it's there.  In the absence of that auditing being enabled beforehand there is one other thing which comes to mind.

You could dump the Active Directory databases from the DCs involved using LDP.EXE, as outlined in the KB article:

http://support.microsoft.com/kb/315098/?sd=RMVP&fr=1

The above technique gives you a .DMP file from each DC you run it on.  In that file, you can locate that object.  Once found you can look at the delTime field, which will identify the deleted time for that object locally.  Given that time must be pretty well in sync to begin with you can make the reasonable assumption that the DC whose .DMP file has the earliest deletion time is the one the original change was done one (or against if it was via an Adminpacked workstation).  This doesn't do nearly as well as having auditing in place, but it can be useful.