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

Reply via email to