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
