[cifs-protocol] DRS option bits
Hongwei Sun
hongweis at microsoft.com
Fri Oct 23 16:34:21 MDT 2009
Kamen,
Currently MS-DRSR is only available in the WSPP document set. The MS-DRDM (Directory Replication and Data Management (DRDM) Remote Protocol Specification, which will be a part of MCPP document set, contains the similar information as MS-DRSR. This document will be available in the future release on MSDN.
Thanks!
Hongwei
-----Original Message-----
From: Kamen Mazdrashki [mailto:kamen.mazdrashki at postpath.com]
Sent: Friday, October 23, 2009 3:51 AM
To: Hongwei Sun; tridge at samba.org
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: [cifs-protocol] DRS option bits
Hi Hongwei,
What is this MS-DRDM document for?
Is it something to be released in near future or we can downloaded it right now?
Thanks,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
> -----Original Message-----
> From: cifs-protocol-bounces at cifs.org [mailto:cifs-protocol-
> bounces at cifs.org] On Behalf Of Hongwei Sun
> Sent: Friday, October 23, 2009 1:09 AM
> To: tridge at samba.org
> Cc: pfif at tridgell.net; cifs-protocol at samba.org
> Subject: Re: [cifs-protocol] DRS option bits
>
> Tridge,
>
> 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.
>
>
> Thanks!
>
> Hongwei
>
>
>
> -----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
>
> Tridge,
>
> 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.
>
> Thanks!
>
> Hongwei
>
>
>
> -----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
>
> Hi,
>
> 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_SPECIAL_SECRET_PROCESSING = 0x00800000,
> DRSUAPI_DRS_SYNC_FORCED = 0x02000000,
> DRSUAPI_DRS_DISABLE_AUTO_SYNC = 0x04000000,
> DRSUAPI_DRS_DISABLE_PERIODIC_SYNC = 0x08000000,
> DRSUAPI_DRS_USE_COMPRESSION = 0x10000000,
> DRSUAPI_DRS_NEVER_NOTIFY = 0x20000000,
> DRSUAPI_DRS_SYNC_PAS = 0x40000000,
> DRSUAPI_DRS_GET_ALL_GROUP_MEMBERSHIP = 0x80000000
>
> 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:
>
> http://samba.org/ftp/unpacked/junkcode/wspp_bits.c
>
> 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
> https://lists.samba.org/mailman/listinfo/cifs-protocol
More information about the cifs-protocol
mailing list