Group:  English: Windows Server ยป microsoft.public.windows.server.dfs_frs
Thread: Waiting for replication

DotNetBag
.NET Development Newsgroups

HTVi
TV Discussion Newsgroups

Our Hot Pick: Rising Antivirus 2006 - Certified by TUV & Checkmark! Get 10% discount by entering this coupon code: ONDISCOUNT10
Rising Antivirus 2006

Waiting for replication
"Guus Ellenkamp" <Ellenkamp_Guus[ at ]hotmail.com> 05.07.2007 14:29:42
I have setup replication for two folders on two computers. It seems like for
weeks one of them is waiting for initial replication. I already deleted one
of the folders from the replication group and added it again. No result for
more than one week now. No errors in the log. No problems reported with the
diagnostic report. What's going on?


Re: Waiting for replication
"Ned Pyle [MSFT]" <nedpyle[ at ]online.microsoft.com> 05.07.2007 23:24:14
Some typical places to start ( I assume you meant DFSR-based replication, by
the way):

============

# Cause 1:

Potentially missing network hotfixes that are causing failing or
unreliable replication

# Resolution 1:

1. You should install KB908521 - this is mentioned in every DFSR Health
Check
Report - while the fix was originally for Office 2003, it updates RPC to
resolve a
bug that can break replication.

2. You should install KB931685 - this hotfix brings DFSR service to latest
pre-SP2 or pre-SP3 versions and resolves a number of issues with RDC
performance,
especially involving cross-file RDC. We've seen massive performance
increases,
especially in initial sync/initial replication scenarios.

3. You should install KB917953 or KB913446 or KB898060 - these resolve the
known issues with TCPIP.SYS and SP1 that cause RPC failures .

4. If neither of these fix the issue, it may be necessary to install
KB905700 which
also stops RPC Too Busy issues.

Installing Windows Server 2003 SP2 means you'd have all of the above except
931685.

=============

# Cause 2:

Incorrectly sized staging directory

# Resolution 2:

Verify that staging is correctly sized (there should be no
DFSR Event 4202 or 4208 events).

"If Staging is below 100% of quota, it will replicate at the maximum rate of
9
files (5 outbound, 4 inbound). If quota is met this is arbitrarily dropped
to a
single outbound thread until staging quota goes below 90%. It is recommended
that
the 9 largest files in a replicated folder do not exceed 10% of the staging
quota,
in order to avoid potential backlogs."

============

# Cause 3:

Bandwidth Throttling or Schedule windows are too aggressive

# Resolution 3:

Verify that you has not artificially lowered the bandwidth throttling and
accidently created an issue.

Also confirm that the replication schedules for the RG and the connections
are
actually allowing replication to occur.

============

# Cause 4:

Large amounts of sharing violations (DFSR event 4302, 4304)

# Resolution 4:

Use the DFSRDEBUG logs to get a better idea of which files are being locked.
Can also use handle.exe or Process
Monitor(http://www.microsoft.com/sysinternals ) to see
which apps have files open.
Can also use NET FILES or PSFILES (sysinternals) to see who has files open
if
coming from off box.
If MS Office-related files (especially PST) there are documented
workarounds.

Close the handles to resolve the issue.

============

# Cause 5:

RDC has been disabled over a WAN link.

# Resolution 5:

Turn RDC back on.
There are times when shutting off RDC can be a good idea (100/1000Mbit
connections
that have already done initial sync and finished replicating, and the file
compositions are not showing much benefit from RDC).
Usually though, all but the fastest WAN's are still very slow and turning
off RDC
will slow replication down to FRS-like speeds.

============

# Cause 6:

Older NIC drivers.
Older Storage drivers or firmware

# Resolution 6:

Update drivers from Microsoft Update, KB or 3rd Party Vendors.
Update firmware (backplane, RAID controller) from 3rd party vendors.

============

# Cause 7:

Anti-virus software and other file system filter drivers.

# Resolution 7:

Turn off, block scanning, or uninstall AV software to test.
Update or replace AV software with newer or compatible versions.
We have seen this with Trend Micro 7, Etrust 8, Symantec 9 and 10,

============

# Cause 8:

DFSR Service (dfsr.exe) at 100% CPU utilization.

# Resolution 8:

In MS experience, always a 3rd party application.
Primarily so far been seen with various Symantec applications.
Use MSCONFIG to clean boot and isolate the issue.
Can also go for a usermode dump of the DFSR service or a kernel mode dump,
if
you're comfortable with debugging
============

# Cause 9:

File Server Resource Manager (FSRM) configured with quotas/screens that
block
replication.

# Resolution 9:

FSRM can be configured in such a way that many types of files are blocked
from
replicating.
When the DFSR filters are not set to match FSRM screens by extension and the
files
exist on the server before screening, this can lead to degraded DFSR
performance
due to endless 'access is denied' retries for files that will never
replicate.
To six, remove screening, reconfigure screening, remove files
by extension, or set a comparable DFSR filter rule to prevent replication
attempts.

============


--

Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.


"Guus Ellenkamp" <Ellenkamp_Guus[ at ]hotmail.com> wrote in message
news:OFwMoDxvHHA.484[ at ]TK2MSFTNGP06.phx.gbl...
[Quoted Text]
>I have setup replication for two folders on two computers. It seems like
>for weeks one of them is waiting for initial replication. I already deleted
>one of the folders from the replication group and added it again. No result
>for more than one week now. No errors in the log. No problems reported with
>the diagnostic report. What's going on?
>

Home | Search | Terms | Imprint | Contact
Newsgroups Reader - provided by WiredBox.Net