Understanding File Date/Time behavior in DFSR Replication (and better ways of knowing that a file has replicated)

Understanding File Date/Time behavior in DFSR Replication

Understanding File Date/Time behavior in DFSR Replication — Thu, 18 Dec 2008 12:32:06 GMT

PingBack from http://www.ditii.com/2008/12/18/understanding-file-datetime-behavior-in-dfsr-replication/

re: Understanding File Date/Time behavior in DFSR Replication (and better ways of knowing that a file has replicated)

xxdcmast — Tue, 30 Dec 2008 22:18:02 GMT

HI Ned let me just start off by saying that all of your articles have been a real big help in learning about the innter workings of DFS. Do you know if there is an MS Press or other book dealing solely with DFS setup, maintenance, troubleshooting etc.

This article was great in explaining the DFS debug log as it can be a little cryptic. I was hoping you might be able to shed some light on an issue I am seeing. I have yet to be able to find any other info on this online so hopefully you can help.

The other day our hub server used to collect data basically just stopped getting DFS data. Everything in the health check says it is fine but the data stopped replicating and is stuck in the middle of initial replication. The data size has not increased since that day.

I took a look in the debug log and found the following entries on the sending memeber which appear troublesome to me.

20081230 01:18:42.859 2804 DOWN 3671 [ERROR] DownstreamTransport::EstablishSession Failed on connId:{6C9858E7-3728-4439-A51F-6A41DB207805} csId:{C59F70A0-3000-4520-B499-FB400C273CE2} Error:

+ [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:3664 2804 C784 A failure was reported by the remote partner]

+ [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:3664 2804 C783 The content set is not ready]

20081230 01:18:42.859 2804 INCO 2588 InConnection::RestartSession Retrying establish contentset session. connId:{6C9858E7-3728-4439-A51F-6A41DB207805} csId:{C59F70A0-3000-4520-B499-FB400C273CE2} csName:Mandarin_Shared

20081230 01:18:42.859 2804 INCO 563 [WARN] SessionTask::Step (Ignored) Failed, should have already been processed. Error:

+ [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:3664 2804 C784 A failure was reported by the remote partner]

+ [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:3664 2804 C783 The content set is not ready]

As I said I have not been able to find anything online about these messages so Im hoping you can help shed some light on this or at least point me in the right direction.

Thanks

re: Understanding File Date/Time behavior in DFSR Replication (and better ways of knowing that a file has replicated)

NedPyle — Tue, 30 Dec 2008 22:58:43 GMT

Hi,

Thanks. :) There's no book that I know of, but I have written a 200-page whitepaper on DFSR troubleshooting via the debug logs that I plan on releasing through this blog someday (at least as a series of articles). It's in review currently. Maybe that will meet your needs?

I have seen that a few times in the past when something has happened during initial sync (not sure what - we've not been able to easily reproduce the issue here), and the new content set has lost track of who the Primary server is. To fix this, you can:

1. Make sure you have good backups of the data everywhere.

2. Reset the IsPrimary flag to true on the server you want to be the initial sync master with:

Dfsradmin Membership Set /RGName:<replication group name> /RFName:<replicated folder name> /MemName:<member you want to be primary> /IsPrimary:True

For example, assume you want NA-DC-01 to be primary for the replicated folder DATA in the replication group RG1:

Dfsradmin Membership Set /RGName:RG1 /RFName:DATA /MemName:NA-DC-01 /IsPrimary:True

Run "Dfsrdiag Pollad" against all the members to force them to pick up this change as soon as possible. You can run "Dfsrdiag Pollad /Member:<member name>" to force a poll on a remote member.

- Ned

re: Understanding File Date/Time behavior in DFSR Replication (and better ways of knowing that a file has replicated)

xxdcmast — Tue, 30 Dec 2008 23:52:39 GMT

Thanks for the quick response. The book is definitely somethign i will be looking for. In the meantime I have your blog bookmarked.... lots of good DFS info here.

As far as the issue occurring during the initial sync I am not sure if that is the true problem. When the replication originally failed we removed the replication group. Deleted the data on the second server and then recreated the replication group with a completely different name.

As far as im thinking this should make DFS think that it is a completely new replication group with the correct primary server designated. I let it run overnight and came in the next day but we were still receiving these same error messages.

Could this possibly be caused by some type of error with the receiving member of the DFS replication group. One thing I noticed is that the event log on the receiving member doesnt have the event descriptions available but rather

"The description for Event ID ( 5004 ) in Source ( DFSR ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer"

The only way that I can think of to resolve this would be to uninstall DFS reboot and then reinstall from add/remove windows components. The only fear that I have doing this is that it may break the replication groups. Do you have any experience on wether removing, rebooting, reinstalling DFS will cause any undesired side effects?

re: Understanding File Date/Time behavior in DFSR Replication (and better ways of knowing that a file has replicated)

NedPyle — Wed, 31 Dec 2008 00:06:51 GMT

Mmph. You're right, if you recreated the RG, you;ve already done the IsPrimary step (and much much more).

The event's not being found does make the entire DFSR server component very suspect. If you uninstall DFSR from this server it will no longer be participating in DFSR, but the topology itself will remain because that is stored in AD.

This is wacky enough though I would recommend opening a support case with us rather than me winging it in a blog comment. It would be useful for our engineers to look through all the data and see what exactly is going on here.

re: Understanding File Date/Time behavior in DFSR Replication (and better ways of knowing that a file has replicated)

maweeras — Sat, 20 Jun 2009 13:44:34 GMT

Hi Ned

Logparser is definitely good. But I prefer fciv.exe (http://support.microsoft.com/kb/841290) for calculating md5 hash.

Somehow the following seems far simpler to me :D

fciv.exe \\server1\rf\goo.txt

Cheers

M "I have no middlename" W