[cifs-protocol] Errors when doing a DsAddEntry

Hongwei Sun hongweis at microsoft.com
Tue Sep 13 17:06:33 MDT 2011

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.



-----Original Message-----
From: tridge at samba.org [mailto:tridge at samba.org] 
Sent: Tuesday, September 13, 2011 2:01 AM
To: Hongwei Sun
Cc: 'Andrew Bartlett'; cifs-protocol at 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:


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

More information about the cifs-protocol mailing list