DsReplicaUpdateRefs after Client calls DsGetNCChanges causes last_successful and last_attempt of repsTo to stay at 0

voidswitch voidswitch at gmail.com
Mon Apr 25 17:34:59 UTC 2016


Hi,

After investigating a problem with samba-tool drs showrepl and dcdiag on windows with DsReplInfo, where the timestamps for outbound replication are 0, it seems DsReplicaUpdateRefs is called too often. 

The Problem:

$ samba-tool drs showrepl
site/dc
DSA Options: 0x00000001
DSA Object GUID: ...
...

==== INBOUND NEIGHBORS ====

DC=DomainDnsZones,DC=<domain>
    site/dc via RPC
    DSA object GUID: ....
    Last attempt @ Mon Apr 25 19:12:10 2016 CEST was successful
    0 consecutive failure(s).
    Last success @ Mon Apr 25 19:12:10 2016 CEST
...

==== OUTBOUND NEIGHBORS ====

DC=DomainDnsZones,DC=<domain>
    site/dc via RPC
    DSA object GUID: ....
    Last attempt @ NTTIME(0) was successful
    0 consecutive failure(s).
    Last success @ NTTIME(0)
...

==== ...

With higher loglevel DsReplicaGetInfo shows 

  last_success             : NTTIME(0)
  last_attempt             : NTTIME(0)

indicating that repsTo on the server contains 0 for these fields. Using dcdiag on Windows says that the remote dc was updated 1970 (0 timestamp -> 1970-01-01).

As far as I understand, the code in source4/dsdb/repl/drepl_out_helpers.c applies changes it requested via GetNCChanges. If I did not get it completly wrong, it means also, after each change it applied, DsUpdateRefs is called, which effectively resets repsTo on the server. Since no update on repsTo is done afterwards, its fields last_success and last_attempt stay at 0. 

looking through MS Documentation and GetNCChanges Code, it seems, the update to repsTo could also be achieved, if the request for GetNCChanges contains DRS_ADD_REF. This would not reset repsTo (as it does only add), and keep repsTo fresh I guess. 

Maybe I overlooked something, as I could not test it. Anyways, before I further look into it, I thought it would be better to ask someone who has more insight.

Regards
Dirk



More information about the samba-technical mailing list