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. 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 _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
