[cifs-protocol] DRS option bits

Sebastian Canevari Sebastian.Canevari at microsoft.com
Thu Oct 22 16:10:56 MDT 2009

Big G! :)

Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: +1 469 775 7849
e-mail: sebastc at microsoft.com

-----Original Message-----
From: cifs-protocol-bounces at cifs.org [mailto:cifs-protocol-bounces at cifs.org] On Behalf Of Hongwei Sun
Sent: Thursday, October 22, 2009 5:09 PM
To: tridge at samba.org
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: Re: [cifs-protocol] DRS option bits


   After a further review, we identified two more bits that could be observed on wire.
   DRS_INIT_SYNC_NOW  0x00800000  
   DRS_PREEMPTED      0x01000000

   A description of these two bits and the DRSUAPI_DRS_NEVER_SYNCED bit you mentioned is shown as below.      

      NSY (DRS_NEVER_SYNCED): There is no successfully completed replication from this source server.
      ISN (DRS_INIT_SYNC_NOW): Perform initial replication now.
      PE (DRS_PREEMPTED): Replication attempt is preempted by a higher priority replication request.

   The information above has been added to 5.39 of MS-DRSR and 5.29 of MS-DRDM. The position of DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING bit in bit table has also been corrected.  The changes will appear in the future release of the documents.  

   The documentation team also confirmed that it is possible that the section numbers will change when any new content is added to MS-DRSR and MS-DRDM in the future. Section titles would probably work much better than section numbers.

   If you have any more questions regarding this issue, please let us know. 



-----Original Message-----
From: Hongwei Sun
Sent: Tuesday, October 13, 2009 4:49 PM
To: 'tridge at samba.org'; Interoperability Documentation Help
Cc: cifs-protocol at samba.org; pfif at tridgell.net
Subject: RE: DRS option bits


   I checked the definitions of these bit fields ,comparing with the MS-DRSR document.  The following is what I found.

   1.  0x00200000 is  DRSUAPI_DRS_NEVER_SYNCED , which means that sync is never completed successfully.  This bit is observed on wire, but not defined in the bit table in 5.39 DRS_OPTIONS.   I will file a request to add this bit to the document.

   2. DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING should be  0x00400000, instead of 0x00800000 as indicated in your definition as well as the bit table. Bit SS should be in bit field #22.   I will also file a request to get this corrected in the document. 

   3.  There is one field defined in the bit table in the document but it is not shown in your definition. Please check it.   
		DRSUAPI_DRS_SYNC_URGENT    = 0x00080000         (Bit SU   field #19) 
   I will also forward your question regarding the numbering of the sections to the documentation team.  I will let you know their response.  



-----Original Message-----
From: tridge at samba.org [mailto:tridge at samba.org]
Sent: Tuesday, October 13, 2009 6:23 AM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org; pfif at tridgell.net
Subject: CAR: DRS option bits


I'm still working on our DRSR DsGetNCChanges implementation. One puzzle I've hit is related to MS-DRSR 5.39 DRS Options. I'm receiving replication requests from a w2k8-R2 machine with the replication flags
(ulFlags) set to 0x00200074. The bit 0x00200000 is one of the 'X' bits in section 5.39, so I guess it is either an undocumented bit or the bitfield is incorrectly labelled in the docs.

Given the complexity of decoding WSPP bitfields, here is my decode of it for you to check:

		DRSUAPI_DRS_ASYNC_OP                  = 0x00000001,
		DRSUAPI_DRS_GETCHG_CHECK              = 0x00000002,
		DRSUAPI_DRS_ADD_REF                   = 0x00000004,
		DRSUAPI_DRS_SYNC_ALL                  = 0x00000008,
		DRSUAPI_DRS_DEL_REF                   = 0x00000008,
		DRSUAPI_DRS_WRIT_REP                  = 0x00000010,
		DRSUAPI_DRS_INIT_SYNC                 = 0x00000020,
		DRSUAPI_DRS_PER_SYNC                  = 0x00000040,
		DRSUAPI_DRS_MAIL_REP                  = 0x00000080,
		DRSUAPI_DRS_ASYNC_REP                 = 0x00000100,
		DRSUAPI_DRS_IGNORE_ERROR              = 0x00000100,
		DRSUAPI_DRS_TWOWAY_SYNC               = 0x00000200,
		DRSUAPI_DRS_CRITICAL_ONLY             = 0x00000400,
		DRSUAPI_DRS_GET_ANC                   = 0x00000800,
		DRSUAPI_DRS_GET_NC_SIZE               = 0x00001000,
		DRSUAPI_DRS_LOCAL_ONLY                = 0x00001000,
		DRSUAPI_DRS_SYNC_BYNAME               = 0x00004000,
		DRSUAPI_DRS_REF_OK                    = 0x00004000,
		DRSUAPI_DRS_FULL_SYNC_NOW             = 0x00008000,
		DRSUAPI_DRS_NO_SOURCE                 = 0x00008000,
		DRSUAPI_DRS_FULL_SYNC_PACKET          = 0x00020000,
		DRSUAPI_DRS_REF_GCSPN                 = 0x00100000,
		DRSUAPI_DRS_SYNC_FORCED               = 0x02000000,
		DRSUAPI_DRS_DISABLE_AUTO_SYNC         = 0x04000000,
		DRSUAPI_DRS_USE_COMPRESSION           = 0x10000000,
		DRSUAPI_DRS_NEVER_NOTIFY              = 0x20000000,
		DRSUAPI_DRS_SYNC_PAS                  = 0x40000000,

as you can see, 0x00200000 doesn't seem to exist. Can you please let me know what this bit means? Can you also please check the other bits to make sure they are right?

btw, I notice that MS-DRSR 5.37 got renumbered to 5.39 between the August and September docs. Is this sort of renumbering going to be frequent? We're putting comments in our code referring to section numbers, and that is not much use if they change frequently. Perhaps we should use section names?

Cheers, Tridge

PS: In case anyone is curious, the program I use to decode WSPP bitfields is available here:


it is very rough, but it's somewhat better than being poked in the eye by a horrendous bitmap every time you open a WSPP doc

cifs-protocol mailing list
cifs-protocol at cifs.org

More information about the cifs-protocol mailing list