DFS/Ntrfs replication delays

Tech-Archive recommends: Fix windows errors by optimizing your registry



I am attempting to setup dfs/ntrfs in windows 2003 server sp1 to replicate
between to servers. Under normal conditions, I require a replication delay of
1 minute or less, however, I am periodically encountering replication delays
on 1 hour or more.

Here are the details of the setup:
1 Domain in the AD Forest, domain and forest level: Windows 2000
2 Domain controllers running Windows 2000 SP 4
2 Member servers running Windows 2003 SP 1 hosting a domain dfs root

All servers are in the same AD site, however, one of the 2003 member servers
is in a remote physical location connected to the primary location by a
1.54mbps T1 circuit.

The replication topology is full mesh, but the dfs utility lists it as
custom. I assume its listed as custom because there are only 2 members in the
replica set.

The replication schedule is set to be always available and the override
schedule box is checked for both connections.

The replicate set contains ~2.1 GB data and ~80,000 files. I have increased
the size of the staging directory to 5 GB in the registry. I left the usn
change log size at
the default (512 mb i believe) since the documentation recommends 128 mb for
each 100,000 files.

The routers between the two physical sites are setup to garuantee a minimum
of 256kbps bandwidth between the 2 member servers, but will allow the entire
1.54mbps to be used if it is available.

As expected the initial synchronization takes several hours to complete,
however, the traffic graphs from the routers traffic bewtween the two servers
show the following:

1. Not all available bandwidth is used, it only uses ~1mbps even though
~300kbps is unutilized

2. ~3-4 hours in the the synchronization process, data stops being
replicated for ~1 hour and the resumes. 1 hour pauses in replication continue
to repeat after each hour of sychronization until synchronization is complete

After snychronization is complete and ntfrs has removed all files from the
frs-staging directories, replication still pauses for ~ 1 hour several times
during the day. At other times, changes are replicated within seconds.

Normally there are only ~50 to 100 changes per hour which consistis of
deleting files, creating files, and creating directories which is part of an
automated process. Most of the new files are less than ~100Kb except 1 which
is typically ~500kb.

The Dfsdiag and ultrasound utilities do not show any problems, except that
ultrasound will confirms that changes are back logged. The new/updated files
that are backlogged appear in the frs-staging directory on the server where
the were created.

As far as I can tell, there is no reason for backlog. Plenty of cpu, memory,
and disk space are available on both servers and there is more than adequate
bandwidth to transmit the changes as they occur.

Any suggestions to fix this will be appreciated.

I've also taken a look at DFS-R which is included with Windows 2003 Server
R2. Would I have to upgrade my domain controllers to Windows 2003 R2 to be
able to use DFS-R on the two member servers? I'd rather not, since it I would
mean that have to upgrade all of the Windows Server CALs for the domain and
only a small number of users access the dfs-root member servers which are
licensed in per server mode.
.



Relevant Pages

  • Re: Upgrading 32-bit AD to 64-bit - FSMO problem
    ... Ethernet adapter PUBLIC: ... regarding EX-DC3 replication look interesting...anyway, ... Performing downstream analysis. ... These servers can't get changes from home server EX-DC1: ...
    (microsoft.public.windows.server.active_directory)
  • W32time NET ID 50, Help PLEASE!!
    ... story) with about 30 Windows 2003 Member servers. ... The time service is no longer synchronized and cannot provide the ...
    (microsoft.public.windows.server.general)
  • Re: Upgrading 32-bit AD to 64-bit - FSMO problem
    ... regarding EX-DC3 replication look interesting...anyway, ... Performing downstream analysis. ... These servers can't get changes from home server EX-DC1: ...
    (microsoft.public.windows.server.active_directory)
  • Re: Upgrading 32-bit AD to 64-bit - FSMO problem
    ... DC's should NOT be multihomed, this creates lot's of problems, especially with replication. ... Performing downstream analysis. ... These servers can't get changes from home server EX-DC1: ...
    (microsoft.public.windows.server.active_directory)
  • Re: machine account password replication not working
    ... This is checking FRS replication. ... > Install the Support Tools on each Domain Controller and on each Member ... Run netdiag /v on all servers. ... The member servers reported access denied ...
    (microsoft.public.win2000.active_directory)