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