Hi obaid,
it looks ok but I didn't received the pdf.
On 13/05/2010 19:13, Obaid Farooqi wrote:
Hi Matthieu:
Please let me know if the following answers your question. If it does, I'll
consider this issue resolved.
Regards,
Obaid Farooqi
Sr. Support Escalation Engineer | Microsoft
-----Original Message-----
From: Obaid Farooqi
Sent: Monday, May 10, 2010 3:31 PM
To: 'Matthieu Patou'
Cc: MSSolve Case Email; '[email protected]'; '[email protected]'
Subject: RE: [REG: 210050354365053001 ] more ms-dfsc.pdf questions
Hi Matthieu:
We have finished our investigation on your question regarding domain name and
expanded name. A future version of MS-DFSC will incorporate the modification as
follows:
Section 2.2.2
-----------------
DC referral: The path MUST be "\<domain>" or"<domain>", where<domain> is a
domain name that MUST be in either NetBIOS or fully qualified domain name forms.
Section 2.2.4.3.2
-----------------------
SpecialNameOffset (2 bytes): A 16-bit integer indicating the offset, in bytes, from the beginning of the
referral entry to a domain name. The domain name MUST be of the form "\<domain>". For a
domain referral response, this<domain> MUST be the domain name that corresponds to the referral
entry. For a DC referral response, this<domain> MUST be the domain name that is specified in the DC
referral request. The domain name MUST be a null-terminated string.
ExpandedNameOffset (2 bytes): A 16-bit integer indicating the offset, in bytes, from the
beginning of this referral entry to the first DC name string returned in response to a DC
referral request. If multiple DC name strings are being returned in response to a DC
referral request, the first DC name string must be followed immediately by the additional
DC name strings. The total number of consecutive name strings MUST be equal to the value
of the NumberOfExpandedNames field. This field MUST be set to 0 for a domain referral
response. Each DC name MUST be a null-terminated string and MUST be prefixed with
"\".
I have also attached a PDF file to this email that includes color highlighting
to mark the changes.
Please let me know if this answers your question. If it does, I'll consider
this issue resolved.
I am still working on your question regarding the effects of site on sorting
order of DC names and will be in touch as soon as I have an answer.
Regards,
Obaid Farooqi
Sr. Support Escalation Engineer | Microsoft
________________________________________
From: Matthieu Patou [[email protected]]
Sent: Sunday, May 02, 2010 5:16 AM
To: Interoperability Documentation Help; [email protected];
[email protected]
Subject: more ms-dfsc.pdf questions
Dear dochelp,
The paragraph "2.2.1.3 Domain Name"
define domain name as
" Unless specified otherwise, a domain name MUST be a null-terminated Unicode
character string
consisting of the name of a domain. This can be either a NetBIOS name or a
fully qualified domain
name (FQDN), as specified in [MS-ADTS]."
So when we have in "3.3.5.3 Receiving a DC Referral Request"
" The domain name in the referral request MUST be either a domain in the
current forest or a domain
in a trusted forest. The server MUST fail DC referral requests for other
domain names with a
STATUS_INVALID_PARAMETER (0xC000000D) return code."
We expect the client to request either FOOBAR (netbios domain) or
foobar.demo.com (fqdn).
But it turns out that windows XP at least is requesting \FOOBAR and
\foobar.demo.com when w7 and w2k8 are requestion FOOBAR and
foobar.demo.com
Also in the same paragraph "The SpecialNameOffset field MUST be set to the offset in
bytes from the beginning of the referral entry to the string that contains the domain
name for the referral response."
It let me think that this field should contain FOOBAR or foobar.demo.com but it
turns out that it's \FOOBAR or \foobar.demo.com that is returned (the example
in the mails out dfs questions from Bill Wesse was also showing this).
The same remark apply the ExpandedName that also present a '\'.
In this paragraph it stated that:
"The ExpandedNameOffset field MUST be set to the offset in bytes from the
beginning of the referral entry to the first null-terminated DC Unicode string. Each
DC name immediately follows its null-terminated predecessor without any padding. An
implementation MUST use the value in the NumberOfExpandedNames field to determine
how many names are present in the list at ExpandedNameOffset.
"
but in this doc:
"http://technet.microsoft.com/ru-ru/library/cc782417%28WS.10%29.aspx";
this point:
"The client checks its domain cache for an existing domain controller referral for
the Contoso.com domain. If this referral is in the cache, the client proceeds to step 5.
If no domain controller referral is in the domain cache, the client connects to the IPC$
shared folder of the active domain controller in the context of the LocalSystem account
and sends a domain controller referral request containing the appropriate domain name
(Contoso.com). The domain controller returns the list of domain controllers in the
Contoso.com domain. The domain controllers in the clients site are at the top of the
list. If least-expensive target selection is enabled, domain controllers outside of the
targets site are sorted by lowest cost. If same-site target selection is enabled, DFS
ignores this setting and lists the remaining domain controllers in random order."
Tells us that the same-site target or other parameters have an influence.
Maybe the MS-DFSC needs to be updated ? Also where those parameters (same-site
target, least-expensive, ...) are stored (in the DS or somewhere else).
The next paragraph sates: "From the IP address of the client, determine the site of
the client" what should happen is the client is not in a site (for instance if it
has a static ip and the admin forgot to declare this subnet in one site) ?
Regards.
Matthieu.
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
