Top 10 Common Causes of Slow Replication with DFSR

re: Top 10 Common Causes of Slow Replication with DFSR

NedPyle [MSFT] — Fri, 23 Apr 2010 18:21:03 GMT

scorchtoggs, I deleted your post. Don't be alarmed, it's only becasue you posted your case # in there. You should treat that like a social security number and never post it publically - other people could use it to get support and you will get the bill.

Please continue working with your support folks. You can also ask them for escalation if you are not making progress.

re: Top 10 Common Causes of Slow Replication with DFSR

scorchtoggs — Thu, 22 Apr 2010 23:34:08 GMT

Hi Ned,

I am having some issues with my DFSR environment. We are running Windows 2003 Server R2 SP2 on all of the servers. We have NOT applied all of relevant DFS hotfixes and patches per KB article 958802. There are about 11 patches on that list, of which I have only applied KB933061. We are running into a problem where several hundred file/folders are NOT replicating for some reason and they are being dumped into the Deleted and Conflicted folder with Event ID 4302. Here is the information from the DFSReport.

"Due to ongoing sharing violations, DFS Replication cannot replicate files in the replicated folders listed above. This problem is affecting 332 files in 1 replicated folders. Event ID: 4302

Last occurred: Thursday, April 22, 2010 at 2:54:08 PM (GMT-8:00)

Suggested action: Verify that the files you want to replicate are closed and have no open handles to them. For information about troubleshooting sharing violations, see The Microsoft Web Site"

We are planning on applying any of the relevant hotfixes tonight but I wanted to see if you have any thoughts about the issue. Any help would be very much appreciated. Thank you, Mike

re: Top 10 Common Causes of Slow Replication with DFSR

NedPyle [MSFT] — Tue, 13 Apr 2010 19:05:49 GMT

Ah. I am able to reproduce this, when running the new DFSRDIAG against *non-2008 R2* servers. If the smem/rmem are 2008 R2, it works fine.

There were a bunch of changes in 2008 R2 to make the backlog command work faster/better, it looks like this new version of dfsrdiag is not fully backwards compatible. I'll look into this a bit more to see what's up.

Nice catch, thanks. :)

re: Top 10 Common Causes of Slow Replication with DFSR

mclegg — Tue, 13 Apr 2010 13:41:46 GMT

Hi Ned, thans for the response.

It only seems to fail when I run dfsrdiag on a W7 or 2008 R2 machine. The rmem/smem are a combination of 2008, 2008R2 and 2003.

As a specific example.

smem 2008 (x64 non-R2)

rmem 2003 (x64 R2)

No file list is produced when running dfsrdiag on W7, or 2008R2, but running the same command on 2008 (non-R2) or 2003 is fine.

For info, dfsrdiag.exe is vesion 6.1.7600.16385

re: Top 10 Common Causes of Slow Replication with DFSR

NedPyle [MSFT] — Tue, 13 Apr 2010 13:19:21 GMT

This works fine when I run it on 2008 R2 - please be more specific in your repro steps. Are you saying it only doesn't work when the dfsrdiag backlog is run on a 2008 R2 server and is pointing rmem/smem to a 2008 NON-R2 server?

re: Top 10 Common Causes of Slow Replication with DFSR

mclegg — Tue, 13 Apr 2010 11:57:24 GMT

Hi.

We're trying to use the dfsrdiag backlog command to gather some trends about our replication topology, and find that the backlog filenames are not listed if we run the dfsrdiag backlog command under Windows 7 or 2008 R2. It works fine under straight 2008.

All we get is something along the lines of...

Member <server> Backlog File Count: 4

Backlog File Names (first 4 files)

but no filenames.

I know it's only a trivial thing, but it is irritating having to RDP to 2008 server to get the file list when we should be able to do this from a local client.

re: Top 10 Common Causes of Slow Replication with DFSR

Jonathan Stephens, MSFT — Fri, 09 Apr 2010 14:42:59 GMT

Hi Marcus -

Ned's out watching the Cubs beat the Braves.

Can clarify what you mean by "mirrored replication"? Do you mean you're replicating the data with DFSR or using SAN replication?

The most effective thing that can be done to improve the initial replication times is pre-seeding the data on the downstream server. The second most effective thing is to tune DFSR if applicable. Both of these points are covered in good detail with performance numbers in the blog post http://blogs.technet.com/askds/archive/2010/03/31/tuning-replication-performance-in-dfsr-especially-on-win2008-r2.aspx.

To mitigate DB failure/recovery, in addition to following http://support.microsoft.com/default.aspx?scid=kb;EN-US;822158 which you are already doing, you can:

1) Adjust the amount of time that DFSR has to commit the logs and close the DB on shutdown: http://support.microsoft.com/default.aspx?scid=kb;EN-US;977518.

2) Make sure that storage is functioning as expected and that all firmware and drivers are up-to-date.

Thanks for following our blog!

--Jonathan

re: Top 10 Common Causes of Slow Replication with DFSR

marcuscurley — Thu, 08 Apr 2010 17:24:20 GMT

Hey Ned,

We're just getting into the business of using DFS in our environment. We're all upgraded to the latest and greatest, 2008 domain and using 2008 R2 servers for our DFS hosts.

Here's my question. We are hosting quite a bit of data (700+ GB, 6,000,000+ Files, in 3,000,000 Folders). Now I've looked at the documentation, which is telling me that 2008 DFS doesn't have any limits and to only watch performance. All of this data is in 1 replication group. The reason for doing this is that we are using group policy redirection, which points to the sub folders within this location. So if we broke the namespace up into sub letter target folders instead of 1 massive target folder, we wouldn't easily be able to continue to use these policies. And to let you know, both of these servers are in the same location and we aren't ever going to use another across a WAN or in a remote location.

With all of that being said, obviously initial replication takes a while along with some massive data copies as we are mirroring our production environment to keep the data fresh. I was wondering if there is any way to make replication go any faster during these massive file copies? Especially because we aren't concerned with bandwidth usage, we'd prefer that they go near 100% if they could.

And do you have any recommendations for our DFS design? The good part is when initial and mirrored replication is done however, it does replicate smaller changes very quickly.

With the huge amount in the replication group, I've also seen the servers take a long time to rebuild their databases if one becomes corrupt in some way. Do you have any recommendations besides keeping A/V away from them, to keep them safe?

Thanks!

Marcus

re: Top 10 Common Causes of Slow Replication with DFSR

nadarajg — Sat, 03 Apr 2010 15:54:56 GMT

HI,

In my organization DFSR is configured with root server & 68 replicated partner server.

DFS replication is working fine , but when in the DFSR health report i can see that around 14 servers getting error "Cannot connect to reporting DCOM server"

I have checked the permission, ports are open, reinstall the DFS service, but still the same.

We need to remove this errors.

On root server i am getting following events for which the servers haveing reporting issue.

Event Type: Error

Event Source: DCOM

Event Category: None

Event ID: 10006

Date: 3.4.2010

Time: 17:24:59

User: N/A

Computer: Root server name

Description:

DCOM got error "General access denied error " from the computer "repicated partner server name" when attempting to activate the server:

{3B35075C-01ED-45BC-9999-DC2BBDEAC171}

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

On repliacted partnet getting follown events.

Event Type: Error

Event Source: DFSR

Event Category: None

Event ID: 5002

Date: 3.4.2010

Time: 16:25:29

User: N/A

Computer: replicated partner

Description:

The DFS Replication service encountered an error communicating with partner "root server" for replication group IUBDATA.

Partner DNS address: root server

Optional data if available:

Partner WINS Address: root server

Partner IP Address: Ip address

The service will retry the connection periodically.

Additional Information:

Error: 1753 (There are no more endpoints available from the endpoint mapper.)

Connection ID: 80396848-A4A9-4C42-A446-BFD6C6E73F24

Replication Group ID: EC982F82-9B4A-4895-9275-4A13A12BC465

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Error

Event Source: DFSR

Event Category: None

Event ID: 6104

Date: 2.4.2010

Time: 16:13:40

User: N/A

Computer: repliacted partner

Description:

The DFS Replication service failed to register the WMI providers. Replication is disabled until the problem is resolved.

Additional Information:

Error: 2147749902 (100e)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

we are going to install the patches mentiomed in below artical to all the servers

http://support.microsoft.com/default.aspx?scid=kb%3bEN-US%3b958802

Could you please chekc & help us some solution to resolve this issue.

Thanks in advance.

Regards.

nadarajg

re: Top 10 Common Causes of Slow Replication with DFSR

sweech — Fri, 05 Mar 2010 10:01:34 GMT

Hi Ned,

Thanks for your feedback. So the flow is from world primary towards spokes (through regionals). Files/folders are only updated on the world primary server and replicated to spokes. the purpose is to speed up replication from this server to others. All servers are 2003 R2. Well, correct me if i am wrong but the approach to add supplementary hubs is not the good one according to you? What would you recommand?

Thanks again!