[Webinar] Streamline your web hosting managementRegister Today

x
?
Solved

DFSR comparing files but not replicating them

Posted on 2010-03-30
3
Medium Priority
?
1,125 Views
Last Modified: 2012-05-09
Hello all,

I have a rather unique issue here.  Firstly, my DFSR design.

I have a full mesh topology with 2 servers and 2 different replication groups.  We'll call them server1, server2, group1, and group2

Secondly, my issue,

Server1 Group1 replicates successfully
Server2 Group1 replicates successfully
Server1 Group 2 replicates sucessfully
Server2 Group 2 will not replicate.

In looking at the debug logs on Server2, I can change a file and it will compare to Server1 to see which one "wins". This is as far as it goes.  It does not copy.  There are no errors in the event log nor the debug log.  It appears to just simply sits in the backlog waiting to copy.  It was functioning normally this morning and stopped mid-day.

In looking at the debug logs on Server1, the file is not mentioned anywhere.

This has been running without issue for months so there shouldn't be a configuration issue.

I will be restarting server2 when I can get a small windows of downtime, but it will be a while.  I currently have about 12K files backlogged at the moment.  

Attached snipped is from the dfsr log file.

Any help is appreciated.  Thanks!

--Nate
##ADDING THE FILE TO THE REPLICATED FOLDER##

20100330 17:22:57.209  400 LDBX  3548 Ldb::Insert Inserting idRecord:
+	fid               0x13000000074EEB
+	usn               0x208f20000
+	uidVisible        0
+	filtered          0
+	journalWrapped    0
+	slowRecoverCheck  0
+	pendingTombstone  0
+	recUpdateTime     16010101 00:00:00.000 GMT
+	present           1
+	nameConflict      0
+	attributes        0x20
+	gvsn              {D9809A24-8DBC-4127-944C-05352E2DDB7F}-v1388548
+	uid               {D9809A24-8DBC-4127-944C-05352E2DDB7F}-v1388548
+	parent            {FBF35F2F-C712-4083-86A3-4F37D2375DD2}-v1
+	fence             16010101 00:00:00.000 
+	clock             20100330 22:22:57.209
+	createTime        20100330 22:22:57.209 GMT
+	csId              {FBF35F2F-C712-4083-86A3-4F37D2375DD2}
+	hash              00000000-00000000-00000000-00000000
+	similarity        00000000-00000000-00000000-00000000
+	name              eetest2.txt
+	
20100330 17:22:57.209  400 USNC  2448 UsnConsumer::CreateNewRecord ID record created from USN_RECORD:
+	USN_RECORD:
+	RecordLength:        88
+	MajorVersion:        2
+	MinorVersion:        0
+	FileRefNumber:       0x13000000074eeb
+	ParentFileRefNumber: 0x100000000001e
+	USN:                 0x208f20000
+	TimeStamp:           20100330 17:22:57.209 Central Standard Time
+	Reason:              Basic Info Change Close File Create 
+	SourceInfo:          0x0
+	SecurityId:          0x47f
+	FileAttributes:      0x20
+	FileNameLength:      22
+	FileNameOffset:      60
+	FileName:            eetest2.txt
+

##ALTERING THE CONTENTS TO TRIGGER COMPARISON##
20100330 17:30:08.319  400 LDBX  3665 Ldb::Update Updating idRecord:
+	fid               0x13000000074EEB
+	usn               0x20901d2a8
+	uidVisible        0
+	filtered          0
+	journalWrapped    0
+	slowRecoverCheck  0
+	pendingTombstone  0
+	recUpdateTime     20100330 22:30:05.084 GMT
+	present           1
+	nameConflict      0
+	attributes        0x20
+	gvsn              {D9809A24-8DBC-4127-944C-05352E2DDB7F}-v1388578
+	uid               {D9809A24-8DBC-4127-944C-05352E2DDB7F}-v1388548
+	parent            {FBF35F2F-C712-4083-86A3-4F37D2375DD2}-v1
+	fence             16010101 00:00:00.000 
+	clock             20100330 22:30:08.319
+	createTime        20100330 22:22:57.209 GMT
+	csId              {FBF35F2F-C712-4083-86A3-4F37D2375DD2}
+	hash              00000000-00000000-00000000-00000000
+	similarity        00000000-00000000-00000000-00000000
+	name              eetest2.txt
+	
20100330 17:30:08.319  400 USNC  2202 UsnConsumer::UpdateIdRecord ID record updated from USN_RECORD:
+	USN_RECORD:
+	RecordLength:        88
+	MajorVersion:        2
+	MinorVersion:        0
+	FileRefNumber:       0x13000000074eeb
+	ParentFileRefNumber: 0x100000000001e
+	USN:                 0x20901d2a8
+	TimeStamp:           20100330 17:30:08.319 Central Standard Time
+	Reason:              Close Data Extend 
+	SourceInfo:          0x0
+	SecurityId:          0x47f
+	FileAttributes:      0x20
+	FileNameLength:      22
+	FileNameOffset:      60
+	FileName:            eetest2.txt
+

Open in new window

0
Comment
Question by:NateWilliams
  • 2
3 Comments
 

Author Comment

by:NateWilliams
ID: 29149045
Well, as most things Microsoft, it seems to suddenly begin functioning again.  I suspect it may have something to do with the staging folder being above the "high watermark".  In the event log, there was an information  notice stating that successfully deleted old staging files for the replication folder within the share that I was having issues with.

If anyone has experienced this or have some knowledge they would like to share, I will still award points if information can be provided that would be relevant to my issue.
0
 
LVL 31

Accepted Solution

by:
Justin Owens earned 750 total points
ID: 29908590
We have about 200 Terabytes in a DFS replica (which is WAY out of scope for what DFS was designed).  We typically have about 80% of our files in good replica status and about 20% in a backlog.  The 20% that stays backlogged are generally in one of two categories: either the entire filename is too long (more than 256 characters including path) or the permissions have been changed.  Ours is unique in that each site has complete administrative control of everything below the ROOT share of their DFS structure.  As a result, they occasionally remove SYSTEM and Administrators from permissions.  
When file that normally replicate, stop, and then restart on their own, we generally chalk it up to the fact that we are so far out of scope we need to expect some discrepancies.  Without looking at your hidden replica system folders, your log files, and your event viewer, it would be almost impossible to tell you why those errors are happening.  If memory serves correctly, MS doesn't support more than 20 terabytes, with individual file size needing to be considered as well.  Here are a couple of links on general DFS size considerations:
I hope that helps.
Justin
0
 

Author Closing Comment

by:NateWilliams
ID: 32161467
Helpful information, unfortunately the root cause of the issue was not definitely determined.  The solution given could possibly provide better prevention methods for other users.
0

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Setting up a Microsoft WSUS update system is free relatively speaking if you have hard disk space and processor capacity.   However, WSUS can be a blessing and a curse. For example, there is nothing worse than approving updates and they just have…
Restoring deleted objects in Active Directory has been a standard feature in Active Directory for many years, yet some admins may not know what is available.
Kernel Data Recovery is a renowned Data Recovery solution provider which offers wide range of softwares for both enterprise and home users with its cost-effective solutions. Let's have a quick overview of the journey and data recovery tools range he…
The video provides a quick and easy steps to migrate MBOX file to well known Outlook PST and Office 365. Besides this, it also supports and migrates more than 20 email clients of MBOX which include AppleMail, Opera, Thunderbird and SeaMonkey effortl…

590 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question