CAR: DRS option bits
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
CAR: DRS option bits
by tridge@samba.org
::
Rate this Message:
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@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: DRS option bits
by Edgar Olougouna
::
Rate this Message:
Good morning Tridge,
Thanks for your question regarding DRS option bits. I have created the case number SRX091013600034 for this inquiry. One of my colleagues will take ownership of the case and contact you soon. Best regards, Edgar -----Original Message----- From: tridge@... [mailto:tridge@...] Sent: Tuesday, October 13, 2009 6:23 AM To: Interoperability Documentation Help Cc: cifs-protocol@...; pfif@... 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@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: DRS option bits
by Hongwei Sun
::
Rate this Message:
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@... [mailto:tridge@...] Sent: Tuesday, October 13, 2009 6:23 AM To: Interoperability Documentation Help Cc: cifs-protocol@...; pfif@... 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@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: DRS option bits
by Hongwei Sun
::
Rate this Message:
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@...'; Interoperability Documentation Help Cc: cifs-protocol@...; pfif@... 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@... [mailto:tridge@...] Sent: Tuesday, October 13, 2009 6:23 AM To: Interoperability Documentation Help Cc: cifs-protocol@...; pfif@... 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@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: DRS option bits
by Sebastian Canevari
::
Rate this Message:
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@... -----Original Message----- From: cifs-protocol-bounces@... [mailto:cifs-protocol-bounces@...] On Behalf Of Hongwei Sun Sent: Thursday, October 22, 2009 5:09 PM To: tridge@... Cc: pfif@...; cifs-protocol@... 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@...'; Interoperability Documentation Help Cc: cifs-protocol@...; pfif@... 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@... [mailto:tridge@...] Sent: Tuesday, October 13, 2009 6:23 AM To: Interoperability Documentation Help Cc: cifs-protocol@...; pfif@... 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@... https://lists.samba.org/mailman/listinfo/cifs-protocol _______________________________________________ cifs-protocol mailing list cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: DRS option bits
by tridge@samba.org
::
Rate this Message:
Hi Hongwei,
> PE (DRS_PREEMPTED): Replication attempt is preempted by a higher priority replication request. I'm getting errors about pre-emption in the logs sometimes, so I'd like to understand this better. I don't see any mention of 'preemption' in the DRSR doc. Could you explain it please? I suspect it is related to a DC doing two DRS replications in parallel (as it seems to happen when I see a 2nd replication happen while a first cycle is not complete). Can you tell me if parallel replications with the same DsBind handle are actually allowed? If they are, then it seems a bit ambiguous, as I can't see how I would tell whether a particular request is a continuation of an existing replication or a new one (assuming they are on the same NC). At the moment I've added code in our DRS server to refuse a 2nd replication with the same DsBind handle if a previous cycle is not complete. Is that what the Microsoft replication client expects? Cheers, Tridge _______________________________________________ cifs-protocol mailing list cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
|
|
|
Re: DRS option bits
by Hongwei Sun
::
Rate this Message:
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@...] Sent: Friday, October 23, 2009 3:51 AM To: Hongwei Sun; tridge@... Cc: pfif@...; cifs-protocol@... 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@... http://repo.or.cz/w/Samba/kamenim.git ------------------------------------- CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ > -----Original Message----- > From: cifs-protocol-bounces@... [mailto:cifs-protocol- > bounces@...] On Behalf Of Hongwei Sun > Sent: Friday, October 23, 2009 1:09 AM > To: tridge@... > Cc: pfif@...; cifs-protocol@... > 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@...'; Interoperability Documentation Help > Cc: cifs-protocol@...; pfif@... > 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@... [mailto:tridge@...] > Sent: Tuesday, October 13, 2009 6:23 AM > To: Interoperability Documentation Help > Cc: cifs-protocol@...; pfif@... > 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@... > https://lists.samba.org/mailman/listinfo/cifs-protocol _______________________________________________ cifs-protocol mailing list cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: DRS option bits
by Hongwei Sun
::
Rate this Message:
Tridge,
The Flag DRS_PREEMPTED is used by the replication client DC to manage its own replicationQueue(5.154 in MS-DRSR), and it is not used between two DCs for replication. The flag indicates that a particular replication operation was interrupted and re-enqueued. The ReplicationQueue stores a sequence of replication operations to be processed by the DC. An implementation can choose its own way to process the queue, including determining when to preempt an operation. Please let us know if you need more information regarding this issue. Thanks! Hongwei -----Original Message----- From: tridge@... [mailto:tridge@...] Sent: Friday, October 23, 2009 2:05 AM To: Hongwei Sun Cc: cifs-protocol@...; pfif@... Subject: RE: DRS option bits Hi Hongwei, > PE (DRS_PREEMPTED): Replication attempt is preempted by a higher priority replication request. I'm getting errors about pre-emption in the logs sometimes, so I'd like to understand this better. I don't see any mention of 'preemption' in the DRSR doc. Could you explain it please? I suspect it is related to a DC doing two DRS replications in parallel (as it seems to happen when I see a 2nd replication happen while a first cycle is not complete). Can you tell me if parallel replications with the same DsBind handle are actually allowed? If they are, then it seems a bit ambiguous, as I can't see how I would tell whether a particular request is a continuation of an existing replication or a new one (assuming they are on the same NC). At the moment I've added code in our DRS server to refuse a 2nd replication with the same DsBind handle if a previous cycle is not complete. Is that what the Microsoft replication client expects? Cheers, Tridge _______________________________________________ cifs-protocol mailing list cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
| Free embeddable forum powered by Nabble | Forum Help |
