[cifs-protocol] [REG:111072877629207] - Windows DC returning WERR_DS_DRA_NO_REPLICA when Samba DC wants to send replica
Obaid Farooqi
obaidf at microsoft.com
Mon Aug 8 10:49:50 MDT 2011
Hi Matthieu:
I am still waiting for network traces for this behavior.
Regards,
Obaid Farooqi
Escalation Engineer | Microsoft
Exceeding your expectations is my highest priority. If you would like to provide feedback on your case you may contact my manager at allisong at microsoft.com
-----Original Message-----
From: Obaid Farooqi
Sent: Monday, August 08, 2011 11:49 AM
To: "mat at samba.org" <mat at samba.org>
Cc: "MSSolve Case Email" <casemail at microsoft.com>; "cifs-protocol at samba.org" <cifs-protocol at samba.org>; "pfif at tridgell.net" <pfif at tridgell.net>
Subject: [REG:111072877629207] - Windows DC returning WERR_DS_DRA_NO_REPLICA when Samba DC wants to send replica
Hi Matthieu:
We may need to do time travel tracing but I want to look at network traces first. I looked at the original email and I don't see any traces attached to it.
Can you please send the network traces?
Regards,
Obaid Farooqi
Escalation Engineer | Microsoft
Exceeding your expectations is my highest priority. If you would like to provide feedback on your case you may contact my manager at allisong at microsoft.com
-----Original Message-----
From: Matthieu Patou [mailto:mat at samba.org]
Sent: Monday, August 01, 2011 4:23 PM
To: Obaid Farooqi
Cc: MSSolve Case Email; cifs-protocol at samba.org; pfif at tridgell.net
Subject: RE:[REG:111072877629207] - Windows DC returning WERR_DS_DRA_NO_REPLICA when Samba DC wants to send replica
Hello Obaid,
On 02/08/2011 00:22, Obaid Farooqi wrote:
> Hi Matthieu:
> In the response from DC, I see the following
>
> result_last_attempt : WERR_OK
>
> Whereas the title of your email says that "Windows DC returning
WERR_DS_DRA_NO_REPLICA..."
That's because I got fooled by the logs, as between the DsReplicaRequest and the DsReplicaResponse there was a GetNcChange response.
But look at the capture, every time samba sends a DsReplica we get a DS_DRA_NO_REPLICA answer.
What are the causes of this behavior ? Do you want me to timetrace (not too convenient).
Matthieu.
>
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
>
> Exceeding your expectations is my highest priority. If you would like
> to provide feedback on your case you may contact my manager at
> allisong at microsoft.com
>
>
> -----Original Message-----
> From: Obaid Farooqi
> Sent: Monday, August 01, 2011 3:18 PM
> To: "'mat at samba.org' (mat at samba.org)"<mat at samba.org>
> Cc: "MSSolve Case Email"<casemail at microsoft.com>;
> "cifs-protocol at samba.org"<cifs-protocol at samba.org>;
> "pfif at tridgell.net"<pfif at tridgell.net>
> Subject: [REG:111072877629207] - Windows DC returning
> WERR_DS_DRA_NO_REPLICA when Samba DC wants to send replica
>
> Hi Matthieu:
> I'll help you with this issue and will be in touch as soon as I have
an answer.
>
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
>
> Exceeding your expectations is my highest priority. If you would like
> to provide feedback on your case you may contact my manager at
> allisong at microsoft.com
>
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat at samba.org]
> Sent: Thursday, July 28, 2011 4:30 PM
> To: Interoperability Documentation Help; cifs-protocol at samba.org;
> pfif at tridgell.net
> Subject: Windows DC returning WERR_DS_DRA_NO_REPLICA when Samba DC
> wants to send replica
>
> Hello Dochelp team,
>
>
> I'm prolonging my tests with s4 DC and Windows DC, and I've discovered
another interesting situation:
>
> My Samba DC is sending a DsReplicaSync call to a Windows 2003r2 DC:
>
> drsuapi_DsReplicaSync: struct drsuapi_DsReplicaSync
> in: struct drsuapi_DsReplicaSync
> bind_handle : *
> bind_handle: struct policy_handle
> handle_type : 0x00000000 (0)
> uuid :
> 475694da-a2c9-49d7-8979-127fe2bf53c2
> level : 0x00000001 (1)
> req : *
> req : union
> drsuapi_DsReplicaSyncRequest(case 1)
> req1: struct drsuapi_DsReplicaSyncRequest1
> naming_context : *
> naming_context: struct
drsuapi_DsReplicaObjectIdentifier
> __ndr_size : 0x00000060
> (96)
> __ndr_size_sid : 0x00000018
> (24)
> guid :
> e1c9fcb8-d491-4529-862d-814844073d80
> sid :
> S-1-5-21-2292624160-2068466659-3617568066
> __ndr_size_dn : 0x00000013
> (19)
> dn :
> 'DC=domain,DC=tld'
> source_dsa_guid :
> f091b72b-4307-40d0-be64-ab697f35f106
> source_dsa_dns : NULL
> options : 0x00080013 (524307)
> 1: DRSUAPI_DRS_ASYNC_OP
> 1: DRSUAPI_DRS_GETCHG_CHECK
> 1: DRSUAPI_DRS_UPDATE_NOTIFICATION
> 0: DRSUAPI_DRS_ADD_REF
> 0: DRSUAPI_DRS_SYNC_ALL
> 0: DRSUAPI_DRS_DEL_REF
> 1: DRSUAPI_DRS_WRIT_REP
> 0: DRSUAPI_DRS_INIT_SYNC
> 0: DRSUAPI_DRS_PER_SYNC
> 0: DRSUAPI_DRS_MAIL_REP
> 0: DRSUAPI_DRS_ASYNC_REP
> 0: DRSUAPI_DRS_IGNORE_ERROR
> 0: DRSUAPI_DRS_TWOWAY_SYNC
> 0: DRSUAPI_DRS_CRITICAL_ONLY
> 0: DRSUAPI_DRS_GET_ANC
> 0: DRSUAPI_DRS_GET_NC_SIZE
> 0: DRSUAPI_DRS_LOCAL_ONLY
> 0: DRSUAPI_DRS_NONGC_RO_REP
> 0: DRSUAPI_DRS_SYNC_BYNAME
> 0: DRSUAPI_DRS_REF_OK
> 0: DRSUAPI_DRS_FULL_SYNC_NOW
> 0: DRSUAPI_DRS_NO_SOURCE
> 0: DRSUAPI_DRS_FULL_SYNC_IN_PROGRESS
> 0: DRSUAPI_DRS_FULL_SYNC_PACKET
> 0: DRSUAPI_DRS_SYNC_REQUEUE
> 1: DRSUAPI_DRS_SYNC_URGENT
> 0: DRSUAPI_DRS_REF_GCSPN
> 0: DRSUAPI_DRS_NO_DISCARD
> 0: DRSUAPI_DRS_NEVER_SYNCED
> 0:
DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING
> 0: DRSUAPI_DRS_INIT_SYNC_NOW
> 0: DRSUAPI_DRS_PREEMPTED
> 0: DRSUAPI_DRS_SYNC_FORCED
> 0: DRSUAPI_DRS_DISABLE_AUTO_SYNC
> 0: DRSUAPI_DRS_DISABLE_PERIODIC_SYNC
> 0: DRSUAPI_DRS_USE_COMPRESSION
> 0: DRSUAPI_DRS_NEVER_NOTIFY
> 0: DRSUAPI_DRS_SYNC_PAS
> 0: DRSUAPI_DRS_GET_ALL_GROUP_MEMBERSHIP
>
> The repsfrom of the DC (windows) is:
> decode_repsFromTo: struct decode_repsFromTo
> in: struct decode_repsFromTo
> blob: struct repsFromToBlob
> version : 0x00000001 (1)
> reserved : 0x00000000 (0)
> ctr : union repsFromTo(case 1)
> ctr1: struct repsFromTo1
> blobsize : 0x00000116 (278)
> consecutive_sync_failures: 0x00000000 (0)
> last_success : jeu. juil. 28
22:54:17
> 2011 MSD
> last_attempt : jeu. juil. 28
22:54:17
> 2011 MSD
> result_last_attempt : WERR_OK
> other_info : *
> other_info: struct repsFromTo1OtherInfo
> __dns_name_size : 0x0000003a
(58)
> dns_name :
> 'f091b72b-4307-40d0-be64-ab697f35f106._msdcs.domain.tld'
> other_info_length : 0x0000003e (62)
> replica_flags : 0x30000050
(805306448)
> 0: DRSUAPI_DRS_ASYNC_OP
> 0: DRSUAPI_DRS_GETCHG_CHECK
> 0: DRSUAPI_DRS_UPDATE_NOTIFICATION
> 0: DRSUAPI_DRS_ADD_REF
> 0: DRSUAPI_DRS_SYNC_ALL
> 0: DRSUAPI_DRS_DEL_REF
> 1: DRSUAPI_DRS_WRIT_REP
> 0: DRSUAPI_DRS_INIT_SYNC
> 1: DRSUAPI_DRS_PER_SYNC
> 0: DRSUAPI_DRS_MAIL_REP
> 0: DRSUAPI_DRS_ASYNC_REP
> 0: DRSUAPI_DRS_IGNORE_ERROR
> 0: DRSUAPI_DRS_TWOWAY_SYNC
> 0: DRSUAPI_DRS_CRITICAL_ONLY
> 0: DRSUAPI_DRS_GET_ANC
> 0: DRSUAPI_DRS_GET_NC_SIZE
> 0: DRSUAPI_DRS_LOCAL_ONLY
> 0: DRSUAPI_DRS_NONGC_RO_REP
> 0: DRSUAPI_DRS_SYNC_BYNAME
> 0: DRSUAPI_DRS_REF_OK
> 0: DRSUAPI_DRS_FULL_SYNC_NOW
> 0: DRSUAPI_DRS_NO_SOURCE
> 0: DRSUAPI_DRS_FULL_SYNC_IN_PROGRESS
> 0: DRSUAPI_DRS_FULL_SYNC_PACKET
> 0: DRSUAPI_DRS_SYNC_REQUEUE
> 0: DRSUAPI_DRS_SYNC_URGENT
> 0: DRSUAPI_DRS_REF_GCSPN
> 0: DRSUAPI_DRS_NO_DISCARD
> 0: DRSUAPI_DRS_NEVER_SYNCED
> 0: DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING
> 0: DRSUAPI_DRS_INIT_SYNC_NOW
> 0: DRSUAPI_DRS_PREEMPTED
> 0: DRSUAPI_DRS_SYNC_FORCED
> 0: DRSUAPI_DRS_DISABLE_AUTO_SYNC
> 0: DRSUAPI_DRS_DISABLE_PERIODIC_SYNC
> 1: DRSUAPI_DRS_USE_COMPRESSION
> 1: DRSUAPI_DRS_NEVER_NOTIFY
> 0: DRSUAPI_DRS_SYNC_PAS
> 0: DRSUAPI_DRS_GET_ALL_GROUP_MEMBERSHIP
> schedule :
> 1001001001001001001001001001001001001001001001001001001001001001001001
> 00
> 1001001001001001001001001001001001001001001001001001001001001001001001
> 00
> 100100100100100100100100
>
> reserved : 0x00000000 (0)
> highwatermark: struct
drsuapi_DsReplicaHighWaterMark
> tmp_highest_usn :
0x0000000000073a7b
> (473723)
> reserved_usn :
0x0000000000000000
> (0)
> highest_usn :
0x0000000000073a7b
> (473723)
> source_dsa_obj_guid :
> f091b72b-4307-40d0-be64-ab697f35f106
> source_dsa_invocation_id :
> transport_guid :
> 00000000-0000-0000-0000-000000000000
>
>
> If I read correctly the paragraph 4.1.23 IDL_DRSReplicaSync (Opnum 2)
> the receiving server should return DS_DRA_NO_REPLICA if
>
> rf := select all v in nc!repsFrom
> where DRS_SYNC_ALL in options
> or (DRS_SYNC_BYNAME in options
> and v.naDsa = msgIn.pszDsaSrc)
> or (not DRS_SYNC_BYNAME in options
> and v.uuidDsa = msgIn.uuidDsaSrc)
> returns no rf.
>
> In my case option has not DRS_SYNC_ALL nor DRS_SYNC_BYNAME but it
seems that the uuidDSA (source_dsa_invocation_id in samba) is equal to the uuidDsaSrc (source_dsa_guid in samba).
>
> Is there something that I'm missing or misinterpreting ?
>
> Thanks for your help.
>
> Matthieu.
>
> --
> Matthieu Patou
> Samba Team http://samba.org
> Private repo http://git.samba.org/?p=mat/samba.git;a=summary
>
>
>
>
> Microsoft is committed to protecting your privacy. Please read the
> Microsoft Privacy Statement for more information.The above is an email
> for a support case from Microsoft Corp.REPLY ALL TO THIS MESSAGE or
> INCLUDE casemail at microsoft.com IN YOUR REPLY if you want your response
> added to the case automatically. For technical assistance, please
> include the Support Engineer on the TO: line. Thank you.
>
--
Matthieu Patou
Samba Team http://samba.org
Private repo http://git.samba.org/?p=mat/samba.git;a=summary
More information about the cifs-protocol
mailing list