Hi, Tridge,
The root cause of the error is that the container
CN=Configuration,DC=v2,DC=tridgell,DC=net, where the added DN is located, was
never successfully replicated to Windows DC. Windows DC keeps a timer since
the DSA is started and then compare it to the timeLastSuccess in REPS_FROM.
If timeLastSuccess is larger, then it indicates that the partition has been
replicated. The following are the values in REPS_FROM for the partition
container.
The time since the restart of DSA is 0n12960016491
There are two entries in REPS_FROM on the Configuration NC.
1. The first value in REPS_FROM for source DC
:4687aacd-c709-4ccb-a874-67c2d8cf7676 . Is this Samba DC ?
cb : 0x1fc
cConsecutiveFailures : 6
timeLastSuccess : 0n12960013829 <-- value checked against
timeLastAttempt : 0n12960368203
ulResultLastAttempt : 0x6ba
cbOtherDraOffset : 0xd8
cbOtherDra : 0x124
ulReplicaFlags : 0x70
rtSchedule : _repltimes
usnvec : _USN_VECTOR
uuidDsaObj : _GUID {4687aacd-c709-4ccb-a874-67c2d8cf7676}
uuidInvocId : _GUID {cfb4f043-e01b-48c9-b304-a0c852fbc4f6}
uuidTransportObj : _GUID {00000000-0000-0000-0000-000000000000}
2. The second value in REPS_FROM is for source DC:
efd7d2b2-8152-4d81-aa3c-5334a3a44ad5,
cb : 0x1fc
cConsecutiveFailures : 0xf
timeLastSuccess : 0n12959766031 <-- value checked against
timeLastAttempt : 0n12960368224
ulResultLastAttempt : 0x6ba
bOtherDraOffset : 0xd8
cbOtherDra : 0x124
ulReplicaFlags : 0x70
rtSchedule : _repltimes
usnvec : _USN_VECTOR
uuidDsaObj : _GUID {efd7d2b2-8152-4d81-aa3c-5334a3a44ad5}
uuidInvocId : _GUID {50947971-6d86-4654-8403-b2905e3581b2}
uidTransportObj : _GUID {00000000-0000-0000-0000-000000000000}
dwReserved1 : 0
cbPASDataOffset : 0
Based on the logic, it is obvious that replications with both source DCs
have never been successful since restart of Windows DC.
I understand that you have done a replication first. Now we have to find
out why the replication failed or if it succeeded, why timeLastSuccess in
REPS_FROM is not updated. Could you check to see if you can see anything?
Meanwhile , I will look back to see if there was replication attempted and the
status of the replication.
Thanks!
Hongwei
-----Original Message-----
From: tri...@samba.org [mailto:tri...@samba.org]
Sent: Tuesday, September 13, 2011 2:01 AM
To: Hongwei Sun
Cc: 'Andrew Bartlett'; cifs-protocol@cifs.org
Subject: RE: Errors when doing a DsAddEntry
Hi Hongwei,
We're still having problems with the DsAddEntry call in a subdomain join. Even
if we do a replication first, we're currently getting DS_ROLE_NOT_VERIFIED. The
really frustrating thing is that the error we get and how far we get through
the join seems to change without us understanding why. For example, we got past
the DsAddEntry on Friday, but now the same calls fails. If we try to reuse the
domain name we used on Friday we now get WERR_DUP_DOMAINNAME instead. So now we
also need to know how to cleanly remove a subdomain we've half-added (all the
'remove' buttons in the windows GUI are greyed out, and doing the remove via
lsa/drs/ldap doesn't seem to be sufficient).
We've created a ttt trace of doing a subdomain join of a new domain
's4.v2.tridgell.net' to a existing windows 2008r2 (build 7600) hosted domain
'v2.tridgell.net'. The trace fails with DS_ROLE_NOT_VERIFIED. As I hope you can
see in the trace, we have done the replication of the configuration and schema
partitions before we do the DsAddEntry.
The trace is available here:
http://www.samba.org/tridge/ttt/join-s4.zip
it also includes a network capture of the join, and a text copy of the decoded
DsAddEntry we are doing.
If you could give us some pointers on why this join fails that would be great!
Cheers, Tridge
_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
