On 27/09/2011 19:06, Edgar Olougouna wrote:
Matthieu,
Question 3:
The documentation didn't explain very well or I didn't understand how to find
the parent of a replicated object, after my investigation it seems that the
objectGUID of replicated object is the same on all the replica and a downstream
partner use this information when it needs to compare 2 files/folders for
modifications or when it needs to find where to store/change/delete a file or
folder.
It seems also that for the sysvol replica, it's the GUID of the NTDS object
that is used as GUID of the frsRootPath.
Can you confirm or precise the correct information about this ?
Response:
Please let me know whether the following answers Question #3, otherwise please
further detail your clarification request and provide references in MS-FRS1.
There are Guid details of a replicated object that propagate in a change order.
Details of FileGuid, OldParentGuid and NewParentGuid are documented in MS-FRS1
Sections 3.3.4.4.6 CMD_REMOTE_CO and 3.3.4.4.7 CMD_SEND_STAGE (see
references).
References:
MS-FRS1
3.3.4.4.6 COMM_COMMAND Is CMD_REMOTE_CO
http://msdn.microsoft.com/en-us/library/714aa502-fbaa-4a03-a386-28dbb607080e(v=PROT.13)
Both CMD_REMOTE_CO_DONE and CMD_SEND_STAGE MUST include a change order in their
packets. Following are common details for those change orders (these details
are not listed in sections 3.3.4.4.6.1 and 3.3.4.4.6.2).
…
FileGuid: MUST be CO_IN.FileGuid.
OldParentGuid: MUST be the local replica tree root GUID if the parent is the
replica tree root; otherwise, set it to CO_IN.OldParentGuid.
NewParentGuid: MUST be the local replica tree root GUID if the parent is the
replica tree root; otherwise, set it to CO_IN.NewParentGuid.
3.3.4.4.7 COMM_COMMAND Is CMD_SEND_STAGE
http://msdn.microsoft.com/en-us/library/dd340857(v=PROT.13).aspx
ChangeOrderCommand MUST be copied from the CMD_SEND_STAGE, except for
the following fields:
…
• COMM_REMOTE_CO.OldParentGuid MUST be set to the local replica tree
rootGUID if the parent is the replica tree root; otherwise, keep the original
value from the CMD_REMOTE_CO packet received.
• COMM_REMOTE_CO.NewParentGuid MUST be set to the local replica tree root
GUID if the parent is the replica tree root; otherwise, keep the original value
from the CMD_REMOTE_CO packet received.
3.1.1.5 IDTable
http://msdn.microsoft.com/en-us/library/dd358590(PROT.13).aspx
Object ID: GUID assigned to each file or folder. The Object ID uniquely
identifies the file or folder within the replica set and across all members of
the replica set.
Parent Object ID: Object ID of the folder that contains this object.
Version Number: Identifies the version of the file or folder. The file version number
is a monotonically increasing unsigned long that gets incremented each time the file
or folder has changed and is replicated. The file version number is updated each time
the file is closed after being modified. The server uniquely identifies the files on
the local file system. If NTFS is being used, the server uses the reference number as
the unique key to identify the files. If this protocol is being implemented on a
different file system, the vendor is free to choose a way to uniquely identify a file
in a file system.<31>
3.1.1.3 Member Object (Replica Member Object)
http://msdn.microsoft.com/en-us/library/dd358146(v=PROT.13).aspx
Replica Tree Root GUID: Object ID for the replica tree root in the IDTable.
1.1 Glossary
http://msdn.microsoft.com/en-us/library/2e457199-2dc1-46c3-8aa6-b2d8e016f95c(v=PROT.13)#file_guid
File GUID: An identifying property of a file or folder in a replica tree. FRS
creates and manages fileGUIDs, which, along with the file version number and
file event time, are stored in the IDTable. Each file and folder stores its
file GUID as part of its attributes; therefore, corresponding files and folders
across all replica set members have the same file GUID.
Yes presented like this it's more obvious.
Thanks.
Matthieu.
Regards,
Edgar
-----Original Message-----
From: Edgar Olougouna
Sent: Thursday, September 22, 2011 9:57 AM
To: '[email protected]'; '[email protected]'; '[email protected]'
Subject: RE: Precisions for FRSRPC
Matthieu,
Question 2:
In paragraph "2.3.1.2 NTFRS Replica Set Object" msFRS-Topology-Pref:
Attribute not used by FRS.
It seems that it's as when you create a replication of a DFS replica this
attribute is set and changing the value in the interface has changed the value
stored in the AD database.
Does this mean that what ever the topology is set to the replication scheme is
always the same ? If so can you clarify it or point me to the place of the
documentation where it's specified ? Is it the same for FRS replication of DFS
replica and for SYSVOL ?
Answer:
As a result of our investigation on this inquiry, a future release of MS-FRS1
will be updated to reflect the following description. First, let’s me answer
your questions, and then I will provide more details.
Q 2.a) Does this mean that whatever the topology is set to the replication
scheme is always the same ?
Ans. msFRS-Topology-Pref attribute of NTFRS Replica Set Object is used by FRS
in Windows Server 2003 (W2K3) and not beyond that, and it is used to decide
what connection to establish (see details).
Q 2.b) If so can you clarify it or point me to the place of the documentation
where it's specified ?
Ans. We will update MS-FRS1 as necessary to clarify the use of attribute
msFRS-Topology-Pref in W2k3.
Q 2.c) Is it the same for FRS replication of DFS replica and for SYSVOL?
Ans. Yes, there is no related specific behavior for DFS replication and SYSVOL
replication.
Details on ms-FRS-Topology-Pref Attribute in Windows Server 2003
------------------------------------------------------------------------------------------
The ms-FRS-Topology-Pref attribute is a setting used for NTFRS topology
selection. When an FRS member gets added to - or deleted from - the replica
set, this attribute is referred, and adjustments are made to the connections
between the existing FRS members in the replica set.
The possible values and their meaning can be described as follows:
Value Description
1 FRS_RSTOPOLOGYPREF_RING
FRS sorts members based on their ‘site’, such that members on the same site are
neighbors. Then, for any two neighbors N1 and N2, it establishes a connection
from N1 to N2, and from N2 to N1.
2 FRS_RSTOPOLOGYPREF_HUBSPOKE
The msFRS-Hub-Member attribute identifies a special node called a ‘hub’ node
(let’s denote this node H). In this replication topology, for each member M
such that M is not a hub node, there is a connection established between M and
H, and between H and M.
NOTE: The msFRS-Hub-Member attribute will be updated in the protocol document.
It is currently described as ‘Attribute not used by FRS’, similarly to
ms-FRS-Topology-Pref.
3 FRS_RSTOPOLOGYPREF_FULLMESH
Connections are established between all pairs of nodes.
4 FRS_RSTOPOLOGYPREF_CUSTOM
The user chooses the connections through the UI.
Let me known whether this helps.
Thanks,
Edgar
-----Original Message-----
From: Edgar Olougouna
Sent: Wednesday, September 14, 2011 4:22 PM
To: '[email protected]'; [email protected]; [email protected]
Subject: RE: Precisions for FRSRPC
Matthieu,
Please find my update as follows.
Question 1:
In paragraph "2.2.3.9 DATA_EXTENSION_RETRY_TIMEOUT" we have information about
FirstTryTime and Count related to REMOTE_CO command, but it seems that it's not explained
how the client should use this information nor when the server should increase the Count
attribute.
Answer:
Upon investigation, I have filed a technical document bug on this. The
following logic will reflect in a future release of the MS-FRS1 document.
The following describes the retry timeout processing rules of FirstTryTime and
Count when handling change orders, from client and server sides.
At the client side(downstream partner) the FirstTryTime and Count fields are
used when the downstream has a CO (let us call it X) which it is not able to
install because the CO corresponding to its parent folder has not arrived/has
not been installed. In this case, it checks the following conditions:
a. (X->Count> MaxRetryCount)
b. (CurrentTime - X->FirstTryTime> MaxRetryTimeOut)
If either of a. or b. is true, then we abort installing X, remove the ID table
entry created for the file/folder corresponding to it (if any), and remove the
pre-install file/folder corresponding to it (if any).
At the server side(upstream partner), for every CO X in the outbound log such that X
has finished installing on that machine and X is not a Directed CO (where the
Directed CO flag is defined in 2.2.3.2 Change_Order_Command), if CurrentTime -
X->FirstTryTime> OutlogChangeHistoryTime (this is defined in 3.1.1 Abstract
Data Model) , then X is removed from the outbound log and it’s corresponding staging
file is deleted. If the GVSN of X is not present in the Version Vector object (where
the Version Vector object is defined in the glossary), then it is added it to it.
Question 2:
In paragraph "2.3.1.2 NTFRS Replica Set Object" msFRS-Topology-Pref:
Attribute not used by FRS. It seems that it's as when you create a replication
of a DFS replica this attribute is set and changing the value in the interface
has changed the value stored in the AD database.
Does this mean that what ever the topology is set to the replication scheme is
always the same ? If so can you clarify it or point me to the place of the
documentation where it's specified ? Is it the same for FRS replication of DFS
replica and for SYSVOL ?
Update:
I have investigated this issue and filed a technical document bug. I am working
with the product team and will update you as soon as I have news.
Question 3:
The documentation didn't explain very well or I didn't understand how to find
the parent of a replicated object, after my investigation it seems that the
objectGUID of replicated object is the same on all the replica and a downstream
partner use this information when it needs to compare 2 files/folders for
modifications or when it needs to find where to store/change/delete a file or
folder.
It seems also that for the sysvol replica, it's the GUID of the NTDS object
that is used as GUID of the frsRootPath.
Can you confirm or precise the correct information about this ?
Update:
I am still investigating this and will update you soon.
Regards,
Edgar
-----Original Message-----
From: Matthieu Patou [mailto:[email protected]]
Sent: Friday, September 02, 2011 6:13 PM
To: Interoperability Documentation Help; [email protected];
[email protected]
Subject: Precisions for FRSRPC
Hello Dochelp,
In paragraph "2.2.3.9 DATA_EXTENSION_RETRY_TIMEOUT" we have information about
FirstTryTime and Count related to REMOTE_CO command, but it seems that it's not explained
how the client should use this information nor when the server should increase the Count
attribute.
In paragraph "2.3.1.2 NTFRS Replica Set Object" msFRS-Topology-Pref:
Attribute not used by FRS. It seems that it's as when you create a replication
of a DFS replica this attribute is set and changing the value in the interface
has changed the value stored in the AD database.
Does this mean that what ever the topology is set to the replication scheme is
always the same ? If so can you clarify it or point me to the place of the
documentation where it's specified ? Is it the same for FRS replication of DFS
replica and for SYSVOL ?
The documentation didn't explain very well or I didn't understand how to find
the parent of a replicated object, after my investigation it seems that the
objectGUID of replicated object is the same on all the replica and a downstream
partner use this information when it needs to compare 2 files/folders for
modifications or when it needs to find where to store/change/delete a file or
folder.
It seems also that for the sysvol replica, it's the GUID of the NTDS object
that is used as GUID of the frsRootPath.
Can you confirm or precise the correct information about this ?
Thanks.
Matthieu.
--
Matthieu Patou
Samba Teamhttp://samba.org
Private repohttp://git.samba.org/?p=mat/samba.git;a=summary
--
Matthieu Patou
Samba Team
http://samba.org
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
