Top 10 Common Causes of Slow Replication with DFSR

Makale
10/05/2007

Hi, Ned again. Today I’d like to talk about troubleshooting DFS Replication (i.e. the DFSR service included with Windows Server 2003 R2, not to be confused with the File Replication Service). Specifically, I’ll cover the most common causes of slow replication and what you can do about them.

Update: Make sure you also read this much newer post to avoid common mistakes that can lead to instability or poor performance: https://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx

Let’s start with ‘slow’. This loaded word is largely a matter of perception. Maybe DFSR was once much faster and you see it degrading over time? Has it always been too slow for your needs and now you’ve just gotten fed up? What will you consider acceptable performance so that you know when you’ve gotten it fixed? There are some methods that we can use to quantify what ‘slow’ really means:

· DFSMGMT.MSC Health Reports

We can use the DFSR Diagnostic Reports to see how big the backlog is between servers and if that indicates a slowdown problem:

The generated report will tell you sending and receiving backlogs in an easy to read HTML format.

· DFSRDIAG.EXE BACKLOG command

If you’re into the command-line you can use the DFSRDIAG BACKLOG command (with options) to see how behind servers are in replication and if that indicates a slow down. Dfsrdiag is installed when you install DFSR on the server. So for example:

dfsrdiag backlog /rgname:slowrepro /rfname:slowrf /sendingmember:2003srv13 /receivingmember:2003srv17

Member <2003srv17> Backlog File Count: 10
Backlog File Names (first 10 files)
1. File name: UPDINI.EXE
2. File name: win2000
3. File name: setupcl.exe
4. File name: sysprep.exe
5. File name: sysprep.inf.pro
6. File name: sysprep.inf.srv
7. File name: sysprep_pro.cmd
8. File name: sysprep_srv.cmd
9. File name: win2003
10. File name: setupcl.exe

This command shows up to the first 100 file names, and also gives an accurate snapshot count. Running it a few times over an hour and give you some basic trends. Note that hotfix 925377 resolves an error you may receive when continuously querying backlog, although you may want to consider installing the more current DFSR.EXE hotfix which is 931685. Review the recommended hotfix list for more information.

· Performance Monitor with DFSR Counters enabled

DFSR updates the Perfmon counters on your R2 servers to include three new objects:

DFS Replicated Folders
DFS Replication Connections
DFS Replication Service Volumes

Using these allows you to see historical and real-time statistics on your replication performance, including things like total files received, staging bytes cleaned up, and file installs retried – all useful in determining what true performance is as opposed to end user perception. Check out the Windows Server 2003 Technical Reference for plenty of detail on Perfmon and visit our sister AskPerf blog.

· DFSRDIAG.EXE PropagationTest and PropagationReport

By running DFSRDIAG.EXE you can create test files then measure their replication times in a very granular way. So for example, here I have three DFSR servers – 2003SRV13, 2003SRV16, and 2003SRV17. I can execute from a CMD line:

dfsrdiag propagationtest /rgname:slowrepro /rfname:slowrf /testfile:canarytest2

(wait a few minutes)

dfsrdiag propagationreport /rgname:slowrepro /rfname:slowrf /testfile:canarytest2
/reportfile:c:\proprep.xml

PROCESSING MEMBER 2003SRV17 [1 OUT OF 3]
PROCESSING MEMBER 2003SRV13 [2 OUT OF 3]
PROCESSING MEMBER 2003SRV16 [3 OUT OF 3]

Total number of members : 3
Number of disabled members : 0
Number of unsubscribed members : 0
Number of invalid AD member objects: 0
Test file access failures : 0
WMI access failures : 0
ID record search failures : 0
Test file mismatches : 0
Members with valid test file : 3

This generates an XML file with time stamps for when a file was created on 2003SRV13 and when it was replicated to the other two nodes.

The time stamp is in FILETIME format which we can convert with the W32tm tool included in Windows Server 2003.

w32tm /ntte 128357420888794190
148561 19:54:48.8794190 - 10/1/2007 3:54:48 PM (local time)

C:\>w32tm /ntte 128357422068608450
148561 19:56:46.8608450 - 10/1/2007 3:56:46 PM (local time)

So around two minutes later our file showed up. Incidentally, this is something you can do in the GUI on Windows Server 2008 and it even gives you the replication time in a format designed for human beings!

Based on the above steps, let’s say we’re seeing a significant backlog and slower than expected replication of files. Let’s break down the most common causes as seen by MS Support:

1. Missing Windows Server 2003 Network QFE Hotfixes or Service Pack 2

Over the course of its lifetime there have been a few hotfixes for Windows Server 2003 that resolved intermittent issues with network connectivity. Those issues generally affected RPC and led to DFSR (which relies heavily on RPC) to be a casualty. To close these loops you can install KB938751 and KB922972 if you are on Service Pack 1 or 2. I highly recommend (in fact, I pretty much demand!) that you also install KB950224 to prevent a variety of DFSR issues - in fact, this hotfix should be on every Win2003 computer in your company.

2. Missing DFSR Service’s latest binary

The most recent version of DFSR.EXE always contains updates that not only fix bugs but also generally improve replication performance. We now have a KB article that we are keeping up to date with the latest files we recommend running for DFSR:

KB 958802 - List of currently available hotfixes for Distributed File System (DFS) technologies in Windows Server 2003 R2
KB 968429 - List of currently available hotfixes for Distributed File System (DFS) technologies in Windows Server 2008 and in Windows Server 2008 R2

3. Out-of-date Network Card and Storage drivers

You would never run Windows Server 2003 with no Service Packs and no security updates, right? So why run it without updated NIC and storage drivers? A large number of performance issues can be resolved by making sure that you keep your drivers current. Trust me when I say that vendors don’t release new binaries at heavy cost to themselves unless there’s a reason for them. Check your vendor web pages at least once a quarter and test test test.

Important note: If you are in the middle of an initial sync, you should not be rebooting your server! All of the above fixes will require reboots. Wait it out, or assume the risk that you may need to run through initial sync again.

4. DFSR Staging directory is too small for the amount of data being modified

DFSR lives and dies by its inbound/outbound Staging directory (stored under <your replicated folder>\dfsrprivate\staging in R2). By default, it has a 4GB elastic quota set that controls the size of files stored there for further replication. Why elastic? Because experience with FRS showed us having a hard-limit quota that prevented replication was A Bad Idea™.

Why is this quota so important? Because if Staging is below quota - 90% by default - it will replicate at the maximum rate of 9 files (5 outbound, 4 inbound) for the entire server. If the staging quota of a replicated folder is exceeded then depending on the number of files currently being replicated for that replicated folder, DFSR may end up slowing replication for the entire server until the staging quota of the replicated folder drops below the low water mark, which is computed by multiplying the staging quota by the low water mark in percent (default is 60%).

If the staging quota of a replicated folder is exceeded and the current number of inbound replicated files in progress for that replicated folder exceeds 3 (15 in Win2008) then one task is used by staging cleanup and the three (15 in Win2008) remaining tasks are waiting for staging cleanup to complete. Since there is a maximum of four (15 in Win2008) concurrent tasks, no further inbound replication can take place for the entire system.

If the staging quota of a replicated folder is exceeded and the current number of outbound replicated files in progress for that replicated folder exceeds 5 (16 in Win2008) then the RPC server cannot serve anymore RPC requests, the maximum number of RPC requests being processed at the same time being five (16 in Win2008) and all five (16 in Win2008) requests waiting for staging cleanup to complete.

You will see DFS replication 4202, 4204, 4206 and 4208 events about this activity and if happens often (multiple times per day) your quota is too small. See the section Optimize the staging folder quota and replication throughput in the Designing Distributed File Systems guidelines for tuning this correctly. You can change the quota using the DFSR Management MMC (dfsmgmt.msc). Select Replication in the left pane, then the Memberships tab in the right pane. Double-click a replicated folder and select the Advanced tab to view or change the Quota (in megabytes) setting. Your event will look like:

Event Type: Warning
Event Source: DFSR
Event Category: None
Event ID: 4202
Date: 10/1/2007
Time: 10:51:59 PM
User: N/A
Computer: 2003SRV17
Description:
The DFS Replication service has detected that the staging space in use for the
replicated folder at local path D:\Data\General is above the high watermark. The
service will attempt to delete the oldest staging files. Performance may be
affected.

Additional Information:
Staging Folder:
D:\Data\General\DfsrPrivate\Staging\ContentSet{9430D589-0BE2-400C-B39B-D0F2B6CC972E}
-{A84AAD19-3BE2-4932-B438-D770B54B8216}
Configured Size: 4096 MB
Space in Use: 3691 MB
High Watermark: 90%

Low Watermark: 60%

Replicated Folder Name: general
Replicated Folder ID: 9430D589-0BE2-400C-B39B-D0F2B6CC972E
Replication Group Name: General
Replication Group ID: 0FC153F9-CC91-47D0-94AD-65AA0FB6AB3D
Member ID: A84AAD19-3BE2-4932-B438-D770B54B8216

5. Bandwidth Throttling or Schedule windows are too aggressive

If your replication schedule on the Replication Group or the Connections is set to not replicate from 9-5, you can bet replication will appear slow! If you’ve artificially throttled the bandwidth to 16Kbps on a T3 line things will get pokey. You would be surprised at the number of cases we’ve gotten here where one administrator called about slow replication and it turned out that one of his colleagues had made this change and not told him. You can view and adjust these in DFSMGMT.MSC.

You can also use the Dfsradmin.exe tool to export the schedule to a text file from the command-line. Like Dfsrdiag.exe, Dfsradmin is installed when you install DFSR on a server.

Dfsradmin rg export sched /rgname:testrg /file:rgschedule.txt

You can also export the connection-specific schedules:

Dfsradmin conn export sched /rgname:testrg /sendmem:fabrikam\2003srv16 /recvmem:fabrikam\2003srv17
/file:connschedule.txt

The output is concise but can be un-intuitive. Each row represents a day of the week. Each column represents an hour in the day. A hex value (0-F) represents the bandwidth usage for each 15 min. interval in an hour. F =Full, E=256M, D=128M, C=64M, B=32M, A=16M, 9=8M, 8=4M, 7=2M, 6=1M, 5=512K, 4=256K, 3=128K, 2=64K, 1=16K, 0=No replication. The values are either in megabits per second (M) or kilobits per second (K).

And a bit more about throttling - DFS Replication does not perform bandwidth sensing. You can configure DFS Replication to use a limited amount of bandwidth on a per-connection basis, and DFS Replication can saturate the link for short periods of time. Also, the bandwidth throttling is not perfectly accurate though it maybe “close enough.” This is because we are trying to throttle bandwidth by throttling our RPC calls. Since DFSR is as high as you can get in the network stack, we are at the mercy of various buffers in lower levels of the stack, including RPC. The net result is that if one analyzes the raw network traffic, it will tend to be extremely ‘bursty’.

6. Large amounts of sharing violations

Sharing violations are a fact of life in a distributed network - users open files and gain exclusive WRITE locks in order to modify their data. Periodically those changes are written within NTFS by the application and the USN Change Journal is updated. DFSR Monitors that journal and will attempt to replicate the file, only to find that it cannot because the file is still open. This is a good thing – we wouldn’t want to replicate a file that’s still being modified, naturally.

With enough sharing violations though, DFSR can start spending more time retrying locked files than it does replicating unlocked ones, to the detriment of performance. If you see a considerable amount of DFS Replication event log entries for 4302 and 4304 like below, you may want to start examining how files are being used.

Event ID: 4302 Source DFSR Type Warning
Description
The DFS Replication service has been repeatedly prevented from replicating a file due to consistent sharing violations encountered on the file. A local sharing violation occurs when the service fails to receive an updated file because the local file is currently in use.

Additional Information:
File Path: <drive letter path to folder\subfolder>
Replicated Folder Root: <drive letter path to folder>
File ID: {<guid>}-v<version>
Replicated Folder Name: <folder>
Replicated Folder ID: <guid2>
Replication Group Name: <dfs path to folder>
Replication Group ID: <guid3>
Member ID: <guid4>

Many applications can create a large number of spurious sharing violations, because they create temporary files that shouldn’t be replicated. If they have a predictable extension, you can prevent DFSR from trying to replicate them by setting and exception in DFSMGMT.MSC. The default file filter excludes file extensions ~* , *.bak, and *.tmp, so for example the Microsoft Office temporary files ( ~* ) are excluded by default.

Some applications will allow you to specify an alternate location for temporary and working files, or will simply follow the working path as specified in their shortcuts. But sometimes, this type of behavior may be unavoidable, and you will be forced to live with it or stop storing that type of data in a DFSR-replicated location. This is why our recommendation is that DFSR be used to store primarily static data, and not highly dynamic files like Roaming Profiles, Redirected Folders, Home Directories, and the like. This also helps with conflict resolution scenarios where the same or multiple users update files on two servers in between replication, and one set of changes is lost.

7. RDC has been disabled over a WAN link.

Remote Differential Compression is DFSR’s coolest feature – instead of replicating an entire file like FRS did, it replicates only the changed portions. This means your 20MB spreadsheet that had one row modified might only replicate a few KB over the wire. If you disable RDC though, changing any portion of a files data will cause the entire file to replicate, and if the connection is bandwidth-constrained this can lead to much slower performance. You can set this in DFSMGMT.MSC.

As a side note, in an extremely high bandwidth (Gigabit+) scenario where files are changed significantly, it may actually be faster to turn RDC off. Computing RDC signatures and staging that data is computationally expensive, and the CPU time needed to calculate everything may actually be slower than just moving the whole file in that scenario. You really need to test in your environment to see what works for you, using the PerfMon objects and counters included for DFSR.

8. Incompatible Anti-Virus software or other file system filter drivers

It’s a problem that goes back to FRS and Windows 2000 in 1999 – some anti-virus applications were simply not written with the concept of file replication in mind. If an AV product uses its own alternate data streams to store ‘this file is scanned and safe’ information, for example, it can cause that file to replicate out even though to an end-user it is completely unchanged. AV software may also quarantine or reanimate files so that older versions reappear and replicate out. Older open-file Backup solutions that don’t use VSS-compliant methods also have filter drivers that can cause this. When you have a few hundred thousand files doing this, replication can definitely slow down!

You can use Auditing to see if the originating change is coming from the SYSTEM account and not an end user. Be careful here – auditing can be expensive for performance. Also make sure that you are looking at the original change, not the downstream replication change result (which will always come from SYSTEM, since that’s the account running the DFSR service).

There are only a couple things you can do about this if you find that your AV/Backup software filter drivers are at fault:

Don’t scan your Replicated Folders (not a recommended option except for troubleshooting your slow performance).
Take a hard line with your vendor about getting this fixed for that particular version. They have often done so in the past, but issues can creep back in over time and newer versions.

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

So insidious! FSRM is another component that shipped with R2 that can be used to block file types from being copied to a server, or limit the quantity of files. It has no real tie-in to DFSR though, so it’s possible to configure DFSR to replicate all files and FSRM to prevent certain files from being replicated in. Since DFSR keeps retrying, it can lead to backlogs and situations where too much time is spent retrying backlogged files that can never move and slowing up files that could move as a consequence.

When this is happening, debug logs (%systemroot%\debug\dfsr*.*) will show entries like:

20070605 09:33:36.440 5456 MEET 1243 <Meet::Install> -> WAIT Error processing update. updateName:teenagersfrommars.mp3 uid:{3806F08C-5D57-41E9-85FF-99924DD0438F}-v333459
gvsn:{3806F08C-5D57-41E9-85FF-99924DD0438F}-v333459
connId:{6040D1AC-184D-49DF-8464-35F43218DB78} csName:Users
csId:{C86E5BCE-7EBF-4F89-8D1D-387EDAE33002} code:5 Error:
+ [Error:5(0x5) <Meet::InstallRename> meet.cpp:2244 5456 W66 Access is denied.]

Here we can see that teenagersfrommars.mp3 is supposed to be replicated in, but it failed with an Access Denied. If we run the following from CMD on that server:

filescrn.exe screen list

We see that…

File screens on machine 2003SRV17:

File Screen Path: C:\sharedrf
Source Template: Block Audio and Video Files (Matches template)
File Groups: Audio and Video Files (Block)
Notifications: E-mail, Event Log

… someone has configured FSRM using the default Audio/Video template which blocks MP3 files and it happens to be against our c:\sharedrf folder we are replicating. To fix this we can do one or more of the following:

Make the DFSR filters match the FSRM filters
Delete any files that cannot be replicated due to the FSRM rules.
Prevent FSRM from actually blocking by switching it from "Active Screening" to “Passive Screening” by using its snap-in. This will generate events and email warnings to the administrator, but not prevent the files from being moved in.

10. Un-staged or improperly pre-staged data leading to slow initial replication.

Wake up, this is the last one!

Sometimes replication is only slow in the initial sync phase. This can have a number of causes:

Users are modifying files while initial replication is going on – ideally, you should set up your replication over a change control window like a weekend or overnight.
You don’t have the latest DFSR.EXE from #2 above.
You have not pre-staged data, or you’ve done it in a way that actually alters the files, forcing the most of or the entire file to replicate initially.

Here are the recommendations for pre-staging data that will give you the best bang for your buck, so that initial sync flies by and replication can start doing its real day-to-day job:

(Make sure you have latest DFSR.EXE installed on all nodes before starting!)

ROBOCOPY.EXE - works fine as long as you follow the rules in this blog post.
XCOPY.EXE - Xcopy with the /X switch will copy the ACL correctly and not modify the files in any way.
Windows Backup (NTBACKUP) - The Windows Backup tool by default will restore the ACLs correctly (unless you uncheck the Advanced Restore Option for Restore security setting, which is checked by default) and not modify the files in any way. [Ned - if using NTBACKUP, please examine guidance here]

I prefer NTBACKUP because it also compresses the data and is less synchronous than XCOPY or ROBOCOPY [Ned - see above]. Some people ask ‘why should I pre-stage, shouldn’t DFSR just take care of all this for me?’. The answer is yes and no: DFSR can handle this, but when you add in all the overhead of effectively every file being ‘modified’ in the database (they are new files as far as DFSR is concerned), a huge volume of data may lead to slow initial replication times. If you take all the heavy lifting out and let DFSR just maintain, things may go far faster for you.

As always, we welcome your comments and questions,

- Ned Pyle

Comments

Anonymous
October 10, 2007
The comment has been removed
Anonymous
October 10, 2007
The comment has been removed
Anonymous
October 18, 2007
The comment has been removed
Anonymous
October 18, 2007
The comment has been removed
Anonymous
October 18, 2007
Also, regarding the ConflictAndDeleted folder, I was assuming you had tried this but I'll mention it anyway. If you double-click the folder on the Memberships tab in dfsmgmt.msc, go to the Advanced tab, you can reduce the Conflict And Deleted quota to as low as 10 megabytes. So another way to purge is to set that to 10 and restart the service, and it will purge down to the low water mark of 60% of 10 mb. So that is a GUI method, but it appeared as if a service restart was needed for that to take effect immediately, although I imagine if I waited long enough it would run the cleanup thread and take into account the new 10 mb quota. But the CleanupConflictDirectory WMI method works instantly.
Anonymous
October 25, 2007
Excellent article! Answered a lot of questions I had on DFSR. I had been pre-staging using Robocopy but thought I'd try the Windows Backup instead having read the blog. However I now have a major problem with Event id 1108. I have eventually found an article on this but there are no solutions (apart from log a support call with MS for £250)http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows%20Operating%20System&ProdVer=5.2.3790.1830&EvtID=1108&EvtSrc=DFSR&LCID=1033 Do you have any suggestions on what I can try as nothing is replicating at the moment at all. Thanks.
Anonymous
October 25, 2007
The comment has been removed
Anonymous
October 25, 2007
The comment has been removed
Anonymous
November 14, 2007
The comment has been removed
Anonymous
November 14, 2007
The comment has been removed
Anonymous
November 14, 2007
The comment has been removed
Anonymous
November 15, 2007
The comment has been removed
Anonymous
November 28, 2007
The comment has been removed
Anonymous
November 28, 2007
The comment has been removed
Anonymous
November 30, 2007
The comment has been removed
Anonymous
November 30, 2007
The comment has been removed
Anonymous
December 03, 2007
The comment has been removed
Anonymous
February 20, 2008
Have you ever felt your DFSR infrastructure wasn’t quite replicating up to your expectations, but didn’t
Anonymous
February 28, 2008
If you're using DFS-R, which is included with Server 2003 R2, the Microsoft Directory Services Team has put together an excellent post explaining the top 10 reasons why replication may be slow. In short, the top 10 are: Missing Windows Server 2003 Network
Anonymous
March 25, 2008
Hi, I just found this link, and I wanted to ask something about DFSR if possible. I'm replicating files between 2 sites, and in one way, it goes just fine, but when I start replicating in different direction, it starts replications, and in one moment is completely stuck. Staging Area is enough big. When I run BACKLOG in one of the replication group, there is onely 1 text file there, and doesn't go. We have enough bandwidth 4 Mbps, and is almost empty. Servers in both sides are completely updated, even with DFSR.exe fix. I one side is Windows 2003 R2 Ent 64 bit, and in other side Windows 2003 R2 Std 32 bit (this is server that doesn't replicate. When I run Diagnostics report, it says everything is OK, and no single error in DFS Log. Thank you Agim
Anonymous
March 25, 2008
The comment has been removed
Anonymous
April 27, 2008
Many papers and KB articles have been posted about the "old-style" SYSVOL replication, or FRS,
Anonymous
June 13, 2008
The comment has been removed
Anonymous
June 13, 2008
Hi Tom, I'm afraid it cannot be changed (even by hacking in ADSIEDIT - if you change it from the default it will simply be ignored and the path constructed from the root RF).
Anonymous
June 16, 2008
What is the impact on DFS-R or RDC if "SMB signing" is used?
Anonymous
June 16, 2008
Hi DanPan, There's no impact - DFSR uses RPC for all replication work, SMB is not used in any way (not even named pipes).
Anonymous
June 16, 2008
The comment has been removed
Anonymous
June 16, 2008
The comment has been removed
Anonymous
June 16, 2008
The comment has been removed
Anonymous
June 16, 2008
Yessir, that is correct.
Anonymous
June 16, 2008
So, from a Best Practice Perspective, if you had to choose between keeping the staging directories in their default location or moving them to a new location (since each will need its own staging directory after all), which one would you recommend? Thanks
Anonymous
June 16, 2008
My recommendation would just be based on the environment - if you need more space, definitely move it to another drive. If not, don't. We always want you to allocate as much staging space is possible, so if that means having to move it - go for it.
Anonymous
June 17, 2008
I'm currently replacing branch office file servers and at the same time starting to use DFS-R for getting data back to a central site. Historically we've used Roboocopy to move data from the old server to the new server (security and all) because of the /mir capability. That works nicely because you can re-sync prior to the swap out, very quickly. BTW, we're going to Server 2008. I came across this post that says that Robocopy has a bug that causes you not to be able to copy security. I'm going to open a ticket with MS, but thought I would post here with my 2 cents. You recommend using xcopy... Robocopy is now built in (finally) to the OS in Vista and 2008. I just type xcopy /? at a cmd prompt and what appear... "NOTE: Xcopy is now deprecated, please use Robocopy." Sounds like someone needs to fix the bug in Robocopy.
Anonymous
June 17, 2008
The comment has been removed
Anonymous
June 18, 2008
We do indeed have a premier contract so I figure it is worth a quick low priority web ticket to let Microsoft know that it affects customers. I tried using Robocopy and it works fine, the only bad thing is it spams the log with conflict file messages (for every file). For migrating file servers, it's hard to beat robocopy with a /mir command so that you sync the bulk of the data prior to a switch out and then run it one more time once you take access away. Xcopy just doesn't fit the bill for that type of operation. Thanks for the great article and response. DFS-R is a quite impressive technology.
Anonymous
June 30, 2008
Hi

IS it possible to View files in replication queue or being replicated ?? Any free tools on the market?
A deleted folder in the DFSPrivateConflictAndDeleted folder, is it possible to know who originally deleted it in the share.
Is there a software or built in tool to know the history of use of a shared folder/File, Ex: User Action Path/File Time/date user_x modified file_x @ time user_z moved file_w @ time user_j Deleted file_w @ time Reead.

Anonymous
June 30, 2008
The comment has been removed
Anonymous
July 10, 2008
The comment has been removed
Anonymous
July 10, 2008
Please open a case with us in support, your issues will require much deeper analysis/data collection than this blog is capable of handling.
Anonymous
July 10, 2008
The comment has been removed
Anonymous
July 10, 2008
No worries. I'd expect to see:

Backlogged receiving transactions
Backlogged sending transactions if there were preexisting files and they had been staged incorrectly or modified in some manner prior to initial sync.

Anonymous
July 10, 2008
Excellent, thank you. These were robocopied with a /copyall so yes they were modified. We learned our lesson with Robocopy a little too late for this migration project. Getting all my facts together now to call support. Thanks again.
Anonymous
July 18, 2008
I thought I would pass along something that occurred to me a little to late to help my situation very much. Branch office to central server collection group. I robocopied the data with /copyall and thus inadvertantly changed all the files. You can still use the files to stage, but it will spam your logs with conflict messages and fill up your dfsprivate with conflict files. Instead of pointing your replication group to those files, as prestaged files, simply copy your data to the same volume but do not point to them in your replication group (assuming you have enough space). Doing it this way, dfsr will still use those files to as seeds to populate the replication group (and thus still not copy all the data acros) but will not spam your log or dfsprivate area. I believe this approach assumes you have enterprise on one end or the other so you get that nice cross file whatchamacallit thing goin' on.
Anonymous
July 30, 2008
Above listed the most common causes for replication problems. Regarding #6, I have a situation where I one of the servers is no longer receiving updates and the debug.log has a large number of the following entires: 0080730 11:20:58.135 520 MEET 4279 Meet::CheckInSync -> WAIT Related record not in sync with file system. relatedRecordUid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v67 updateName:wmsfdwn4.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v67 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169616 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS csId:{A2AF821E-A258-4E83-BD5D-B2A82519A1E3} 20080730 11:20:58.135 520 MEET 1190 Meet::Install Retries:53 updateName:wmsfdwn2.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v65 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169614 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS 20080730 11:20:58.135 520 MEET 4279 Meet::CheckInSync -> WAIT Related record not in sync with file system. relatedRecordUid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v65 updateName:wmsfdwn2.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v65 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169614 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS csId:{A2AF821E-A258-4E83-BD5D-B2A82519A1E3} 20080730 11:20:58.151 2024 MEET 1190 Meet::Install Retries:53 updateName:wmsf_obj.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v70 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169619 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS 20080730 11:20:58.151 2024 MEET 4279 Meet::CheckInSync -> WAIT Related record not in sync with file system. relatedRecordUid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v70 updateName:wmsf_obj.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v70 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169619 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS csId:{A2AF821E-A258-4E83-BD5D-B2A82519A1E3} 20080730 11:20:58.151 2024 MEET 1190 Meet::Install Retries:53 updateName:wmsf_dwn.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v69 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169618 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS 20080730 11:20:58.151 2024 MEET 4279 Meet::CheckInSync -> WAIT Related record not in sync with file system. relatedRecordUid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v69 updateName:wmsf_dwn.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v69 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169618 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS csId:{A2AF821E-A258-4E83-BD5D-B2A82519A1E3} 20080730 11:20:58.151 2024 MEET 1190 Meet::Install Retries:53 updateName:wms_main.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v74 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169623 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS 20080730 11:20:58.151 2024 MEET 4279 Meet::CheckInSync -> WAIT Related record not in sync with file system. relatedRecordUid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v74 updateName:wms_main.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v74 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169623 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS csId:{A2AF821E-A258-4E83-BD5D-B2A82519A1E3} 20080730 11:20:58.151 2024 MEET 1190 Meet::Install Retries:53 updateName:wmsrptap.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v72 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169621 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS 20080730 11:20:58.151 2024 MEET 4279 Meet::CheckInSync -> WAIT Related record not in sync with file system. relatedRecordUid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v72 updateName:wmsrptap.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v72 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169621 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS csId:{A2AF821E-A258-4E83-BD5D-B2A82519A1E3} 20080730 11:20:58.166 1228 MEET 1190 Meet::Install Retries:53 updateName:wmsdwsrv.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v63 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169612 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS 20080730 11:20:58.166 1228 MEET 4279 Meet::CheckInSync -> WAIT Related record not in sync with file system. relatedRecordUid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v63 updateName:wmsdwsrv.pbd uid:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v63 gvsn:{1F1D1518-7BDD-49B2-BD6D-99E8306F497B}-v169612 connId:{E28E47C2-F919-4122-92C8-567F79009683} csName:PROGS csId:{A2AF821E-A258-4E83-BD5D-B2A82519A1E3} Does this mean there is a sharing violation that may be preventing replication? I checked the event log and I am only seeing one Event ID 4302. Thanks for your help!
Anonymous
July 30, 2008
The comment has been removed
Anonymous
July 31, 2008
The comment has been removed
Anonymous
July 31, 2008
The comment has been removed
Anonymous
August 04, 2008
Thank you for your help! It turns out that the Sharing Violiatons were causing replication to become backlogged. I excluded the directory that contained all the files that were constantly locked and replication caught up shortly thereafter. One thing to note, these files were considered "Locked" by the OS because they weren't open for writing, however, the Application was locking these files which most likely prevent the event 4302 from being logged.
Anonymous
August 08, 2008
The comment has been removed
Anonymous
August 11, 2008
The comment has been removed
Anonymous
August 11, 2008
Meh - that URL got wonky. Just copy and paste the whole thing.
Anonymous
August 11, 2008
The comment has been removed
Anonymous
August 12, 2008
The comment has been removed
Anonymous
August 12, 2008
The comment has been removed
Anonymous
August 12, 2008
The comment has been removed
Anonymous
August 21, 2008
The comment has been removed
Anonymous
August 21, 2008
The comment has been removed
Anonymous
August 21, 2008
The comment has been removed
Anonymous
August 21, 2008
The comment has been removed
Anonymous
August 22, 2008
The comment has been removed
Anonymous
August 25, 2008
The comment has been removed
Anonymous
August 26, 2008
The comment has been removed
Anonymous
August 26, 2008
The comment has been removed
Anonymous
August 27, 2008
Wait a minute. Are you suggesting the implementation of the GPO is changing the security metadata each time the GPO is applied to the server even if no actual changes have occurred ? Did Microsoft develop Group Policy and DFS-R each in a bubble ? How could it be that Group Policy provides a very nice ability in which to manage file system security and yet this same ability will cause DFS-R to thrash for days ? The reason we have gone to an automated approach for file system security is to bring control to this very difficult to control environment. For large orgs with lots of file servers, this is a very daunting task. Regardless of where NTFS permissions are initiated, this seems like it will always be a big deal for DFS-R. If we applied the same change on both sides, would the results be different ? Thanks, Tom
Anonymous
August 27, 2008
I am suggesting no such thing. If you have configured GPO and powershell (you give no details here) to reapply security by re-writing the security arbitrarily (i.e. removing the security - that's a change, setting security - that's a change), then DFSR will react to whatever the USN journal tells it to. I suggest you carefully reproduce your scenario in a test environment both with and without your powershell scripts or GPO, whatever those are. We don't have 1000 customers a day calling us about this issue, so you are likely in a corner case because of how you are implementing things.
Anonymous
August 27, 2008
The comment has been removed
Anonymous
August 27, 2008
The comment has been removed
Anonymous
August 30, 2008
The comment has been removed
Anonymous
September 02, 2008
The comment has been removed
Anonymous
September 02, 2008
Hi, Is there a way to delete unwanted files from the 'Pre-Existing' folder? I don't seem to have (or be able to give the administrator) sufficient permission to delete them? Thanks Huw
Anonymous
September 02, 2008
The comment has been removed
Anonymous
September 03, 2008
The comment has been removed
Anonymous
September 03, 2008
By default, it's SYSTEM only for the System Volume Information folder(s) on Win2008. That was done intentionally, as we saw a lot of customers accidently deleting/damaging security in Win2003 R2 in that folder. You will just need to make Administrators own that folder, then add ADministrators full control to its contents. There is also a special folder/file protection for SVI in Win2008. So if you go through Explorer and try to delete files, they will... not delete. You will need to go through a CMD prompt.
Anonymous
September 30, 2008
The comment has been removed
Anonymous
September 30, 2008
The comment has been removed
Anonymous
October 10, 2008
The comment has been removed
Anonymous
October 16, 2008
The comment has been removed
Anonymous
October 20, 2008
The comment has been removed
Anonymous
October 20, 2008
The comment has been removed
Anonymous
October 20, 2008
Forgot - dskprobe.exe is included with the 2003 Support Tools - download latest ones from microsoft.com
Anonymous
October 20, 2008
First of All thank you for the great info Above. Can you possibly help me with the problems I am having below I have a couple of questions regarding DFS-R I have Two 2008 Core 64bit File Serves using DFS-R How do I know if Initial Syncronization finished ? How do I know if bandwith is an issue of slow replication ? I have it setup up to constantly replicate. I have about 10 replication groups, some of them are up to date all the time, others have around 150 backlogged transactions, but I can't determine the reason for it. It takes a couple of hours to sync one single file (less than a meg) My Staging folder actual size is using 3 Gigs out of 4. Should I double it to 8 Gigs. ? I read that VSS is supported with DFS-R. But is this only the case if VSS snapshots sit on the same drive you are replicating ? How about if the Snapshots are located on a different storage ? Can you have VSS running at both targets independently ?
Anonymous
October 21, 2008
The comment has been removed
Anonymous
October 21, 2008
Thanks for the quick response.

Great, I verified all my 16 Groups finished initail sync
No Antivirus installed on these servers Yet. Planning to do it soon. Should I exclude the DFSrPrivateStaging folders or any other folders once I do it ? On Group A, I have about 3 files with sharing viloations for at around 6 days now. And about 170 files total (receiving/sending) that are backed logged. Could these 3 files be causing these large back log and making a file take 1 1/2 hours to replicate ?. Also the files with sharing violations are not the same that are being backlogged. These sharing files are not same that are on the backlog Also one of the servers is not being accessed by anybody now since I have not enabled the dfs link on it and I am waiting to fix this slow replication issue first, however, this server has a backlog of 145 files pending to be sent. Shouldn't it be ZERO, since there are no changes on any files at this server. And if I run the backlog report on the other server as the sending server where files are actually bieng changed, the backlog is actually lower, 31 Files. Same Goes for Group B, sending backlog is 667 where data is not being changed and where the data is being changed, the backlog is 95. Backlog Files seem to be the same for the past hour, I'll keep an eye on them for the next few hours On Group B, I have about about 47 files with sharing violations of which 7 have been there for one day and about 760 files files total (receiving/sending) that are backed logged. Backlog Files seem to be the same for the past hour, I'll keep an eye on them for the next few hours the bandwith between the location is 6Mbps, I have the replication set to use 4Mbps in each of the 16 Groups I have setup.
Event 4202 was constantly poping up during intial sync which is expected, but after this finished, it comes up once every 2 or 3 days in 2 of my groups which is taking a long time to sync. I don't believe this is the case of slow sync but I will increase, it won't hurt right ?
Thanks, so to confirm, I should be able to have VSS enabled for Drive 1 on Server A, have VSS snapshots located on drive 2 on Server A, then replicate data on from Drive 1 on Server A to Drive 3 to Server B, and have enable VSS on on Drive 3 on Server B, and have VSS snapshots located on drive 4 on Server B.

Anonymous
October 21, 2008

Cool.
Yes, we recommend you disablew AV scanning of dfsrprivate (and will have an official document on this releasing at some point). Let me know what you see on that backlog after a few hours, sounds like it's not to do with the handful of sharing violations.
Correct, it will not hurt.
Correct.

Anonymous
October 21, 2008
The comment has been removed
Anonymous
October 21, 2008
Hmmm... starting to wonder if your issue is related to Scalable Network Pack, based on your symptoms and errors above. If you are running Windows Server 2003 SP2, I would highly recommend you install the following on all servers (and not just the DFSR servers): 950224 A Scalable Networking Pack (SNP) hotfix rollup package is available for Windows Server 2003 http://support.microsoft.com/default.aspx?scid=kb;EN-US;950224

As far as a backlog where nothing is being changed - that's not possible. Something is changing files, even if it's not an expected change. :) You could use Process Monitor or Object Access Auditing to see who and what it is.

Anonymous
October 21, 2008
I am running Windows 2008 Core x64bit. I'll dig deeper and see why there is a sending backlog on the server where nothing is being changed that I know of. I staged this files using windows backup, could that be part of the issue since I see you crossed that part out in your article ? At this point nothing seems to be replicating on some groups or its taking extremely long time to do so. Almost like if there were limitations on the scheduling. It looks like it starts by taking a long time then stopping all together. I will give it a couple of more hours tonight and If I see no change, I'll restart the service and see if that makes any difference.
Anonymous
October 21, 2008
It appears that all of the Files that are backloged on the sending member where nothing has changed are located on the DFSPrivatePreExisting Folder. and not anywhere else. My understanding is that this data is not replicated and put aside. I am confused :@
Anonymous
October 21, 2008
Dang, I forgot you said 2008. Do you use HP Gigabit network cards in these machines? If so, you will need to go into the proerties of those NICs and turn off HPs built in scalable network pack pieces, as they are on by default (and our SNP is off by default in 2008). Ehhh... in the preexisting folder. that's bad. That folder is not replicated and DFSR will not replicate that folder. Are you sure that these are the files? That backlog report does not provide paths, so there may be multiple copies. You can definitely always move the contents of the pre-existing folder out of the RF. Unless you want to actually restore those files...
Anonymous
October 22, 2008
It is actually a Dell 1855 Blade Server. I am pretty sure those are the files, since I did a search on the file name on both servers and it only showed up on the server (which was where I staged my data) with the sending backlog (where nothing is being changed) on the preexisting folder, . My next step is to delete the contents of the preexisting folder. So, since there was still a backlog and it was growing this morning, I decided to restart the DFRS service on the Sending Server, where data is being changed and guess what ? the groups I was having problems with, seems to be working now, the backlog is now decreasing. However there is still a backlog on the server where nothing is being changed. It will probably go away once I delete the contents of the preexisting folder So, it looks like we have 2 problems here

We have a server with pre-staged data trying to sync data on the prexisting folder but failing
We have 16 groups on a server, most of them working but something happens all of a sudden and stops replication for certain groups, no errors reported, and replication picks up again once the service is restarted. :(

Anonymous
October 22, 2008
Hmmm... if you are still having problems after restarting the DFSR service, at this point we've probably reached the end of effectively troubleshooting we can do in a blog comment post. :) I'd recommend you open a case with us at that point so we can do deeper data analysis.
Anonymous
October 22, 2008
Restaring the service fixed the issue, but I have a feeling it will come back. but At least I have an understanding of what the problem is and how to fix it temporarily. As far as the preexisting folder, after I deleted the contents and restarted the DFSR service, guess what ? no more back log. Another verification that there is something messed up with DFSR and it was trying to do something with those files. If I decide to open a case with Microsoft, and find anything interesting, I'll post it here. Thanks again for your assitance.
Anonymous
October 28, 2008
Fantastic Blog....... Help.... I am trying to run DFSRdiag backlog to view files not replicating. However l keep recieving this error message... [ERROR] Replicated folder <dfs_fbv> not found. Err: -2147217406 (0x80041002) I have installed the latest hotfixes as requested by the Microsoft KB but still no joy... Please can anyone help????? :-(
Anonymous
October 28, 2008
Can you first use DFSRADMIN RF LIST <options> to dump the list of replicated folders for that RG and verify it exists, the spelling, etc?
Anonymous
October 28, 2008
thanks for the post.... I ran the command above and results are below. D:>dfsradmin rf List /RgName:DFS_FBV RfName RfDfsPath DFS-FBV Command completed successfully. On this domain we have 4 sites with 2 servers on each site, l do have the DFSRdiag Backlog running fine on one site and was trying to implement the same script on each of the others however l get the error message posted earlier i am using the command below editing for the DFS on each site.. Again thanks for any ideas you come up with.. dfsrdiag backlog /ReceivingMember:SERVERNAME /SendingMember:SERVERNAME /rgname:DFS_FBV /RFName:"DFS_FBV" >> d:DFSLOGDFS%datefile% dfsrdiag backlog /ReceivingMember:SERVERNAME /SendingMember:SERVERNAME /rgname:Users_FBV /RFName:"Users_FBV" >> d:DFSLOGUser%datefile%
Anonymous
October 28, 2008
It looks like you are using an underscore for the RF name instead of a dash, which is what is your true RF name is above (your RG is DFS_FBV, and your RF name is DFS-FBV). So this: dfsrdiag backlog /ReceivingMember:SERVERNAME /SendingMember:SERVERNAME /rgname:DFS_FBV /RFName:"DFS_FBV" >> d:DFSLOGDFS%datefile% should be this: dfsrdiag backlog /ReceivingMember:SERVERNAME /SendingMember:SERVERNAME /rgname:DFS_FBV /RFName:"DFS-FBV" >> d:DFSLOGDFS%datefile% May be the same with the other one that's not working.
Anonymous
October 29, 2008
Perfect!!!! Thanks for your help on this... Thanks
Anonymous
October 31, 2008
The comment has been removed
Anonymous
October 31, 2008
The comment has been removed
Anonymous
November 03, 2008
The comment has been removed
Anonymous
November 16, 2008
The comment has been removed
Anonymous
November 16, 2008
The comment has been removed
Anonymous
November 19, 2008
I have configured DFSR beetween servers. Since there where too much files and problems with replications i used robocopy to copy all files on the other side. I got errors and warnings like "file has been changed on multiple servers" and i know that is normal becaose of robocopy. However another thing happened on the old server (server that had updated files innitially). After all was finished (since files where replicating in both ways), DFSRPRIVATE folder became big big. first i didn't worry about it, since i thought i have to wait for all of the things to finish, but now i have only 40GB left on that partition. After analyzing I found out that STAGING folder is 40Giga and PREEXISTING folder is 250GIGa. I read somewhere that after using updated dfsr.exe (which i have installed from the time that i started experiencing problmes ) some of the people experience this. Interesting fact is that those files do exist on the server (i havent checked them all). What do i do with them. do i delete or what? I am sure that my organisation was not so productive to create 250Giga of data in a month. I suppose that they are all somehow copy of somthink. Another important fact is that they have a stamp modified 10/11/2008 (which i guess coreespodents to the time i worked on the replication a month ago). I would delete them but i read this article http://www.eggheadcafe.com/software/aspnet/30863354/this-member-is-waiting-fo.aspx As far as i know users where not complaining about lost files or something the last thing: DFS ROOT is in other server and initial replication was to get the files from the old server to the new one (DFS ROOT)
Anonymous
November 19, 2008
Hi, The staging folder is as big as you configured the quota - so by default that's 4GB per replicated folder. The pre-existing folder only contains files that were not present on teh upstream when you set up replication - since the data is not accessible to end users, I suggest you back it up, verify the backup is good, and delete preexisting data.
Anonymous
November 19, 2008
We’ve been at this for over a year (since August 2007), with more than 100 posts (127 to be exact), so
Anonymous
November 19, 2008
The comment has been removed
Anonymous
November 19, 2008
Ah, now I understand you better - sorry about that. yes, that is very intersting. It's possible that something went very wrong during initial sync (or initial sync has never exited, but still with something gone wrong causing a loop) and data was being continuously recreated in pre-existing. I can say that I have never seen this before! I recommend that you open a support case with us and have some deeper investigation. This is going to require a lot of data analysis that won't be easy to do through the blog.
Anonymous
December 02, 2008
The comment has been removed
Anonymous
January 15, 2009
The comment has been removed
Anonymous
January 15, 2009
The comment has been removed
Anonymous
January 15, 2009
The comment has been removed
Anonymous
January 19, 2009
The comment has been removed
Anonymous
January 19, 2009
The comment has been removed
Anonymous
January 20, 2009
The comment has been removed
Anonymous
January 20, 2009
It's not possible to change the whole base folder path, it always lives in the RF (on 2003) or in the System Volume Information folder (in 2008/2008R2, via a junction point). It is possible to change the staging path though: http://technet.microsoft.com/en-us/library/cc773238.aspx#BKMK_012. That's the part people usually want to manipulate anyways since the other folders are very small, especially if the Conflict And Deleted quota is reduced in size.
Anonymous
January 21, 2009
The comment has been removed
Anonymous
January 21, 2009
No, if you are completely removing the RG's and making one big RG from scratch, that would just work.
Anonymous
January 26, 2009
On a server that has a directory that primarily receives replicated files from a branch office, I find a folder under DfsrPrivateStaging called ContentSet{71bf...etc.. Explorer claims that there are 100 folders containing about 6.85GB of data. DFSRDIAG BACKLOG says that everything is up-to-date in both directions. Is this space actually in use and what is it? There is a similar set of folders on the other server. I thought that perhaps this is where RDC did it's magic, but you refer to a similarity table located somewhere else. Can this space be freed up? Thanks!
Anonymous
January 27, 2009
The staging folder contains all of your staged files - so everything under ContentSet{GUIDGOO} is the actual files that are currently staged for replication. These hold the RDC signatures.
Anonymous
January 30, 2009
The comment has been removed
Anonymous
January 30, 2009
The best way is to add the new server, get it replicating and and in sync, then change your replicaiton topology to make him the hub, then remove the old server - using DFSMGMT.MSC.
Anonymous
February 01, 2009
The comment has been removed
Anonymous
February 04, 2009
The comment has been removed
Anonymous
February 04, 2009
Are they temporary files? Named .TMP? .BAK? Etc? there are lots of reasons - the fact that initial synx finished means that either:

they did not exist when initial sync was being done.
They are not considered valid for replication.

Anonymous
February 04, 2009
The comment has been removed
Anonymous
February 04, 2009
The comment has been removed
Anonymous
February 04, 2009
Also, when I say temporary files, I mean do they have the temporary file attribute set. The archive bit doesn't matter.
Anonymous
February 04, 2009
The comment has been removed
Anonymous
February 04, 2009
Just removing the temporary bit will not cause them to replicate - they need to be 'touched' in some meaningful way afterwards to trigger a USN update. A content modification, a security change, a rename, moved out and back in to the replicated folder, etc.
Anonymous
February 04, 2009
The comment has been removed
Anonymous
February 04, 2009
You will need to examine the DFSR debug logs then. Make a change to a file, verify that it did not replicate, then open the %systemroot%debugdfsr*.log file on that server. Find the reference to that file, and see what details it is providing about why the file is not being replicated. If not copmfortable doing this, I;d advise opening a a support case with us.
Anonymous
February 06, 2009
The comment has been removed
Anonymous
February 06, 2009
The comment has been removed
Anonymous
February 08, 2009
The comment has been removed
Anonymous
February 09, 2009
Hi Hockeman, Lookee lookee: http://technet.microsoft.com/en-us/library/cc794759.aspx It turns out we do have steps. Neither I nor the developers I spoke to were aware of this doc, but one of our tech writers chimed in and that shook the cobwebs free. Even though these steps are for DC's running DFSR for sysvol, the same steps would apply for custom (with different paths, naturally). So there you go.
Anonymous
February 09, 2009
Hi Chau, 1st question: http://support.microsoft.com/default.aspx/kb/958802 2nd question: Yes, using robocopy with very particular steps. This is documented in another bloh post here under 'pre-seeding'.
Anonymous
February 09, 2009
The comment has been removed
Anonymous
February 11, 2009
The comment has been removed
Anonymous
February 12, 2009
Hi Hockeman - are you using BackupExec for your backup software? Hi Chau - this is more of a DFS Namespace question than DFSR. Since the subnets are both defined on the same AD logical site, there is nothing you can do to control the DFS target priority for those branch users. Your IP subnetting needs to match your logical sites,as DFS doesn't know anything about the physical network.
Anonymous
February 12, 2009
Yes. Backupexec 12.5 latest and greatest patches.
Anonymous
February 12, 2009
Can you check to see if the following has happened? BE sets this key that can get us into some trouble: Look at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDfsrRestore. There will be a sub key named year-date-time the restore was done with two values. One of those values will be the network name that was used to perform the remote restore. Backup and delete the restore subkey, then restart DFSR. The service will most likley hang on shut down but it will stop and restart. After the reg value is removed the service start and stop will be normal The key was deprecated in 2008.
Anonymous
February 12, 2009
You say the key was depreciated in 2008. Does that mean that if we are running server 2008 that we are in the clear for this key? Also, we do not have the key on the DFSR server.
Anonymous
February 12, 2009
I would then say open up a support case with us for further troubleshooting. There are a lot of little one-offs that can cause that issue and it will require a bunch of data to see what's going on.
Anonymous
February 20, 2009
The comment has been removed
Anonymous
March 17, 2009
The comment has been removed
Anonymous
March 17, 2009
The comment has been removed
Anonymous
March 24, 2009
The comment has been removed
Anonymous
March 24, 2009
The comment has been removed
Anonymous
April 22, 2009
The comment has been removed
Anonymous
April 22, 2009
The comment has been removed
Anonymous
April 30, 2009
The comment has been removed
Anonymous
April 30, 2009
The comment has been removed
Anonymous
April 30, 2009
The comment has been removed
Anonymous
May 01, 2009
Are there any new dfsr.exes for 2008? Thanks. Jason
Anonymous
May 01, 2009
Yes. 967326 Data loss occurs after you use the Dfsrmig.exe tool to migrate the SYSVOL share from the FRS to the DFSR service in a Windows Server 2008-based domain http://support.microsoft.com/default.aspx?scid=kb;EN-US;967326 968733 The SYSVOL share migration from FRS to DFSR fails on Windows Server 2008 R2 Beta-based servers if a disjoint namespace is configured http://support.microsoft.com/default.aspx?scid=kb;EN-US;968733 962969 Error message when you run Dfsradmin.exe to set membership properties in Windows Server 2008: "The property MemberSubscriptionReadOnly cannot be used" http://support.microsoft.com/default.aspx?scid=kb;EN-US;962969 We are working on getting the master KB article released for 2008 as well, but the publishing timeline is not under my control unfortunately..
Anonymous
May 01, 2009
The comment has been removed
Anonymous
May 04, 2009
Should I call about my problem?
Anonymous
May 04, 2009
Yes.
Anonymous
May 07, 2009
The comment has been removed
Anonymous
May 07, 2009
I have no idea what that script is. :-/ Where did you get it?
Anonymous
May 07, 2009
The comment has been removed
Anonymous
May 07, 2009
Do you have the same problem using the WMIC.EXE tool against those three DfsrReplicatedFolderConfig, DfsrReplicatedFolderInfo, and DfsrReplicationGroupConfig classes? Just to completely rule the script out once and for all, I mean.
Anonymous
May 07, 2009
The comment has been removed
Anonymous
May 07, 2009
Could be in AD (under the computer dfsr-localsettings objects or the System dfsr-globalsettings objects), could be in the XML files cached locally on the server in the system volume informationdfsrconfig folders on each drive, could be registry under the dfsrparameters key, or could be in the WMI repository itself (which is totally opaque - hence the need to use the WMIC.EXE tool to confirm).
Anonymous
May 14, 2009
OK, this explains the problem I'm having: http://support.microsoft.com/?kbid=967357 Except it's with Native 2008 DFS rather than 2003R2... Any solutions for 2008 out there? Thanks, Jason
Anonymous
May 14, 2009
Here's the version of dfsrs.exe we're using: 6.0.6001.18000. This problem is making me cry... Thanks, Jason
Anonymous
May 18, 2009
The comment has been removed
Anonymous
May 19, 2009
Got this error on after DFSR started back up: The DFS Replication service failed to recover from an internal database error on volume E:. Replication has been stopped for all replicated folders on this volume. Additional Information: Error: 9209 (The database resource was not found (-1601)) Volume: 47A2C3EC-2EAA-442D-8AFA-10EEE88AF9DE Database: E:System Volume InformationDFSR However, it looks like an initial replication started on its own. Should I take any further steps? Thanks, Jason
Anonymous
May 19, 2009
Hi turg77, For your first question: that is normal. Your backup software is stopping DFSR in order to run backups. If you don't want that error you will need to speak to Legato about changing their software, or invest in a different backup product. For your second issue, there was a database problem that DFSR fixed automatically. There is no reason to do anything further there.
Anonymous
May 25, 2009
Hi NedPyle, I would like to thank you for posting all this info. I currently managed 30x DFSR servers with about 3TB's of data all across WAN links. I've applied those 2 patches you recommend on every single server. I must say the DFS replication is running much better between the servers now. This blog is my DFS Bible :P My question: I upgraded a RAID array of about 1TB of data by doing the following.

ROBOCOPY /COPYALL... to another location
Expand RAID arrray
ROBOCOPY /COPYALL... to original location I wish I had found this blog before I did that. /COPYALL = evil!! DFSR is now trying to replicate every single file (1.7 million files). I get the following error... "The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder." Please could tell us what exact parmeters I should be using with ROBOCOPY to copy DFS data back and forth. I was thinking of something like "robocopy <source> <dest> /E /SEC /W:3 /R:2 /DCOPY:T" Your recommendation please! :)

Anonymous
May 26, 2009
The comment has been removed
Anonymous
May 26, 2009
The comment has been removed
Anonymous
May 26, 2009
So is that one folder an actual replicated folder root, or just a subfolder inside some RF and the rest of the data in that RF works without issues??
Anonymous
May 27, 2009
I'm reposting a response because I'm not sure if my last one got sent... The folder in question is a root folder. It is directly under \xxxxroot.
Anonymous
May 27, 2009
The comment has been removed
Anonymous
May 27, 2009
The comment has been removed
Anonymous
May 27, 2009
Whoops! We have a KB article for 2008 and 2008 R2 now that tracks those, but I completely failed to update the above #2 with its link. It's there now, and here: KB 968429 - List of currently available hotfixes for Distributed File System (DFS) technologies in Windows Server 2008 and in Windows Server 2008 R2
Anonymous
June 02, 2009
The comment has been removed
Anonymous
June 02, 2009
The comment has been removed
Anonymous
June 15, 2009
The comment has been removed
Anonymous
June 19, 2009
The comment has been removed
Anonymous
June 19, 2009
What OS - 2003R2 or 2008? My steps will change, depending on the answer.
Anonymous
June 24, 2009
Well, I got another problem... One of our departments has noticed xls files being renamed to odd names without xls extentions, i.e. AE8A8100. Recently updated both 2008 DFS servers to SP2. If you can offer anything, I'd greatly appreciate it Thanks, Jason (missing my 2003 R2 DFS)
Anonymous
June 24, 2009
That is how Excel 2003 and older works, as I recall - you will see that even without DFSR (run Process Monitor on your local computer and make some changes in an Excel doc locally). It does this sort of swappy rename behavior behavior. I don't have Excel 2003 running to confiurm this though. If it's ending up with the wrong file we'd need to investigate the debug logs to see where things are going south. Please open a support case for troubleshooting on that, it will be worth your time.
Anonymous
June 24, 2009
Wow ! Just read this whole thread, and I'm feeling enlightened. Thanks for the great info. I wanted to ask a little more about the Staging folder size configuration for larger files. I did read the perf guide on Technet, etc., but I'm still curious on a simple scenario. Here's what I'm trying to tune: Two Win2003 R2 SP2 servers using DFSR for only the purpose of backup data replication to a remote site for DR. I have a single replication group with both servers included, and have configured the schedule, etc. It seems to work fine, but I have alot of staging folder cleanup event entries, which raised my concern about the performance, etc. On Friday evening, we add approx 200GB of backup images to one of the members (ServerA). This 200GB is spread across appprox 14 files (Backup Exec Server Recovery BESR backup files). We then replicate all weekend to the remote site (ServerB). On Mon-Thurs, we have nightly approx 3GB of image files spread across approx 14 files per day. Each day, the files have a different name. We have the Replication group schedule open FULL overnight to allow for replication during non-business hours. Data is always originated on ServerA (after backups are done) and replicated out to ServerB. How do I best configure the size of the staging folder for ServerA, and ServerB. Since there are only two members, and each day, the files to replicate have different file names? I am confused about the 9 files at a time, down to 1 file at time when staging is over 100%, etc. I initially thought to follow the info above about ensuring the staging size is greater than the largest files, but I was not sure if I should set a 200+GB staging value. I was concerned at how this might affect free space on the server volume where the replicated folders exist. Dazed and confused on how to best proceed. Thank you for any advice you can offer.
Anonymous
June 24, 2009
The comment has been removed
Anonymous
June 24, 2009
We're having an issue between two DFSR members across a WAN link, where beginning about the middle of the day the backlog in one direction (from the hub to the spoke) begins climbing. It only clears out after the workday has finished. I think this may be related to cause #6 of this blog post, with sharing violations. We do receive a large amount of sharing violation warnings on both members, mostly from AutoCAD DWG files as our users work directly off the server. The functional mode is Server 2000, so only 4 files can be transferred at a time correct? If so, will DFSR keep retrying the same 4 locked files, until it is able to pass them through, or will it move onto other backlogged files? If not, can this be tweaked at all; for example, how long to skip the locked files?
Anonymous
June 24, 2009
The comment has been removed
Anonymous
June 24, 2009
Thanks for that info. We are moving to upgrade the namespaces to Win2008 (I had emailed you previously about that), so maybe this will accelerrate it. I'll have to turn on the EnableAudit function of DFSR to be sure, but I don't think too many files are getting through. Today the backlog has risen from 4 files at 9AM to 600 files at 2PM to 900 files, now currently 4:30PM.
Anonymous
June 25, 2009
Well, I guess we'll have to breakdown and open a support ticket with Microsoft... However, for informational purposes, we've had nothing but problems since "upgrading" our Win2003R2 DFSR to Win2008 DFSR. Clean installs across the board. It seems muitple times daily we get calls about missing files which turnout to be in the ConflictAndDeleted folder. It's seems the conflict resolution algorithm thinks nothing is a winning file... Ugh! Perhaps Win2008R2 will bring happiness, but SP2 didn't.
Anonymous
June 25, 2009
The comment has been removed
Anonymous
June 25, 2009
Oh, DSFR also likes to make whole directories disappear!
Anonymous
June 25, 2009
The comment has been removed
Anonymous
June 25, 2009
The comment has been removed
Anonymous
June 25, 2009
One was document management software. The other was a specialty app that handled the proprietary files directly.
Anonymous
June 26, 2009
The comment has been removed
Anonymous
June 26, 2009
It uses the NTFS USN Journal.
Anonymous
June 26, 2009
The comment has been removed
Anonymous
June 26, 2009
Ouch. There is only one method - using a VSS writer. If you backup software doesn't use that, it's unsupported. Journal loss == bad bad bad. 99.% of the time, that is due to failing hardware.
Anonymous
June 26, 2009
The comment has been removed
Anonymous
June 26, 2009
For the 1% - was the DFSR service off for several hours/days and a ton of files modified in the meantime?
Anonymous
June 26, 2009
The comment has been removed
Anonymous
June 26, 2009
I've been put in the call back queue for the your team... Thanks.
Anonymous
July 01, 2009
The comment has been removed
Anonymous
July 02, 2009
Is the ConflictAndDeleted folder dynamic? While monitoring it on one of my servers in the DFSR group, I see files go in and out of it. Support wasn't able to answer the question.
Anonymous
July 02, 2009
Absolutely. It has a quota just like staging.
Anonymous
July 02, 2009
I guess I should have clarified, my quota is set to 200GB (I increased it so I wouldn't lose any files), and I'm only talking about four or five files in there at a time and then it's empty.
Anonymous
July 02, 2009
If you already have a support case opened, please get it escalated. That is not normal behavior unless the files actually add up to 90% of 200GB.
Anonymous
July 06, 2009
The comment has been removed
Anonymous
July 07, 2009
The comment has been removed
Anonymous
July 07, 2009
What does one do when there are a few files stuck in the backlog, when you're sure that they're not currently open? We have 3 files in backlog for a replication group. The server pushing out the updates has been restarted multiple times since we've seen the backlog. These files won't replicate to multiple partners, both in the LAN and WAN.
Anonymous
July 13, 2009
The comment has been removed
Anonymous
August 17, 2009
The comment has been removed
Anonymous
August 18, 2009
Hi, Yes, that is an indictor of WMI issues. Try fixing it with:

Logon as an administrator and open an (elevated, if 2008/R2) CMD prompt.
CD to %systemroot%system32wbem
Run: MOFCOMP.EXE dfsrprov.mof (and if it exists) MOFCOMP.EXE dfsrprov.mfl
Restart the DFSR service (heck, restart the server if you can).
See if it works now.

Anonymous
August 19, 2009
The comment has been removed
Anonymous
August 19, 2009
OK, try the hammer and anvil approach: In a CMD prompt: cd /d %windir%system32wbem for /f %s in ('dir /b *.dll') do regsvr32 /s %s for /f %s in ('dir /b *.mof *.mfl') do mofcomp %s If still not working, open a Support case with us for further analysis.
Anonymous
August 19, 2009
The comment has been removed
Anonymous
August 19, 2009
Cool. :)
Anonymous
January 05, 2010
The comment has been removed
Anonymous
January 05, 2010
Not precisely - back in 2003 R2 there were a number of issues that could be cause initial sync to not restart at all and be only partially completed. In 2008 this issue is removed. This blog post is extremely old...
Anonymous
January 14, 2010
The comment has been removed
Anonymous
February 14, 2010
The comment has been removed
Anonymous
February 14, 2010
The comment has been removed
Anonymous
February 14, 2010
The comment has been removed
Anonymous
February 15, 2010
@ Basheer: I sounds like there is a database issue. If you don;t want to use that workaround, you will need to open a support case so that the environment can be examined in detail. @ Artem: Yep. Don't worry, several updates to that KB are on the way. The whip got cracked on this a week ago, your timing is excellent. :)
Anonymous
February 17, 2010
The comment has been removed
Anonymous
February 17, 2010
Hi Ned, That woraround of moving file did not work. Again after sometime it cleared all these folder from the two partners server1 and server2, now I mam not sure how to proceed, can you please suggest how to proceed. Please see the logs 20100217 17:00:47.662 440 MEET 3634 Meet::InstallTombstone -> DONE Install Tombstone complete updateName:S1489.blc uid:{067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3571314 gvsn:{067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3736252 connId:{5C5A3D52-82A6-418E-B687-4FAFACB27876} csName:Commercial csId:{3585D669-4F22-42AA-903F-195D9E481AC2} 20100217 17:00:47.662 3976 MEET 3634 Meet::InstallTombstone -> DONE Install Tombstone complete updateName:S1488.blc uid:{067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3571313 gvsn:{067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3736251 connId:{5C5A3D52-82A6-418E-B687-4FAFACB27876} csName:Commercial csId:{3585D669-4F22-42AA-903F-195D9E481AC2} 20100217 17:00:47.662 440 INCO 4378 InConnection::UpdateProcessed Received Update. updatesLeft:216 processed:23743 sessionId:3 open:1 updateType:0 processStatus:0 connId:{5C5A3D52-82A6-418E-B687-4FAFACB27876} csId:{3585D669-4F22-42AA-903F-195D9E481AC2} csName:Commercial update:

present 0
nameConflict 0
attributes 0x80
gvsn {067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3736252
uid {067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3571314
parent {067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3568542
fence 16010101 00:00:00.000
clock 20100217 11:42:09.875
createTime 20070926 11:27:49.500 GMT
csId {3585D669-4F22-42AA-903F-195D9E481AC2}
hash 00000000-00000000-00000000-00000000
similarity 00000000-00000000-00000000-00000000
name S1489.blc

20100217 17:00:47.662 440 MEET 1190 Meet::Install Retries:0 updateName:S149.blc uid:{067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3571315 gvsn:{067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3736253 connId:{5C5A3D52-82A6-418E-B687-4FAFACB27876} csName:Commercial 20100217 17:00:47.662 3976 INCO 4378 InConnection::UpdateProcessed Received Update. updatesLeft:215 processed:23744 sessionId:3 open:1 updateType:0 processStatus:0 connId:{5C5A3D52-82A6-418E-B687-4FAFACB27876} csId:{3585D669-4F22-42AA-903F-195D9E481AC2} csName:Commercial update:

present 0
nameConflict 0
attributes 0x80
gvsn {067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3736251
uid {067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3571313
parent {067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3568542
fence 16010101 00:00:00.000
clock 20100217 11:42:09.875
createTime 20070926 11:27:49.500 GMT
csId {3585D669-4F22-42AA-903F-195D9E481AC2}
hash 00000000-00000000-00000000-00000000
similarity 00000000-00000000-00000000-00000000
name S1488.blc

20100217 17:00:47.662 3976 MEET 1190 Meet::Install Retries:0 updateName:S1490.blc uid:{067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3571316 gvsn:{067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3736254 connId:{5C5A3D52-82A6-418E-B687-4FAFACB27876} csName:Commercial 20100217 17:00:47.662 440 MEET 3699 Meet::MoveOut Moving contents and children out of replica. newName:S149.blc-{067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3571315 updateName:S149.blc uid:{067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3571315 gvsn:{067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3736253 connId:{5C5A3D52-82A6-418E-B687-4FAFACB27876} csName:Commercialrecord:

fid 0x1100000002C79F
usn 0x2616edd30
uidVisible 1
filtered 0
journalWrapped 0
slowRecoverCheck 0
pendingTombstone 0
recUpdateTime 20100214 18:01:46.725 GMT
present 1
nameConflict 0
attributes 0x80
gvsn {067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3571315
uid {067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3571315
parent {067B5647-7D78-45D0-8A8C-579BF10F96BD}-v3568542
fence 16010101 00:00:00.000
clock 20100104 04:22:02.187
createTime 20070926 11:27:49.500 GMT
csId {3585D669-4F22-42AA-903F-195D9E481AC2}
hash 8B6CA9F0-E5AAF6A5-86D17334-BF7FBFD9
similarity 00000000-00000000-00000000-00000000
name S149.blc

Anonymous
February 17, 2010
Open a support case.
Anonymous
February 23, 2010
The comment has been removed
Anonymous
March 04, 2010
The comment has been removed
Anonymous
March 04, 2010
What direction is the data primarily flowing - from the 100 spokes towards the 1 primary? The 3 regional hubs could be overloaded by 30+ spokes if the regional was inbound replicating. With 2003 R2 it could only handle 4 files at a time. With 2008/R2, 16 files by default, and the option to tune up more. If this was all 2008/R2, doubling the layer of regional servers could potentially double replication performance. I will be creating a new DFSR tuning blog post in the next few weeks BTW way, it covers more about this.
Anonymous
March 05, 2010
The comment has been removed
Anonymous
April 03, 2010
The comment has been removed
Anonymous
April 08, 2010
The comment has been removed
Anonymous
April 09, 2010
The comment has been removed
Anonymous
April 13, 2010
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.
Anonymous
April 13, 2010
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?
Anonymous
April 13, 2010
The comment has been removed
Anonymous
April 13, 2010
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. :)
Anonymous
April 22, 2010
The comment has been removed
Anonymous
April 23, 2010
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.
Anonymous
June 05, 2014
Warren here again. This is a quick reference guide on how to calculate the minimum staging area needed
Anonymous
June 12, 2014
Pingback from DFS – Logs de eventos 4202, 4204, 4206, 4208 e 4212.
Anonymous
August 10, 2014
My name is Bryan Zink and I am a Microsoft Premier Field Engineer focused on supporting Windows Server
Anonymous
August 10, 2014
My name is Bryan Zink and I am a Microsoft Premier Field Engineer focused on supporting Windows Server
Anonymous
September 19, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
September 23, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
October 02, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
October 04, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
October 10, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
October 12, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
October 29, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
October 30, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
October 30, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
November 06, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
November 06, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
November 16, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
November 17, 2014
Top 10 Common Causes of Slow Replication with DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
April 28, 2015
This is a collection of the top Microsoft Support solutions for the most common issues experienced when
Anonymous
May 15, 2015
This is a collection of the top Microsoft Support solutions for the most common issues experienced when
Anonymous
May 15, 2015
This is a collection of the top Microsoft Support solutions for the most common issues experienced when

Aracılığıyla paylaş

Top 10 Common Causes of Slow Replication with DFSR

Comments

Ek kaynaklar