Why DFSR silently refused to replicate my PST files

by | Jul 19, 2026 | Tutorials | 0 comments

Two file servers replicate a shared folder with DFS Replication. Everything was in sync except a handful of very large PST files, which existed on one server and not the other. No errors in the DFSR event log, no backlog, nothing in the health report. They were simply never sent. The cause is a documented but obscure DFSR rule, and it comes with two bonus lessons about disk space.

DFSR ignores files with the Temporary attribute

By design, DFS Replication skips any file that has the FILE_ATTRIBUTE_TEMPORARY flag set. The idea is that temporary files are not worth replicating. Outlook, and some copy tools, set that attribute on files they create and do not always clear it. The PST files had it, so DFSR considered them not worth shipping and said nothing.

Find them:

Get-ChildItem -Path D:\Shares\Mail -Recurse -File |
    Where-Object { $_.Attributes -band [IO.FileAttributes]::Temporary } |
    Select FullName, Length, Attributes

Clear the attribute, and DFSR picks the file up on the next change notification:

Get-ChildItem -Path D:\Shares\Mail -Recurse -File |
    Where-Object { $_.Attributes -band [IO.FileAttributes]::Temporary } |
    ForEach-Object { $_.Attributes = $_.Attributes -bxor [IO.FileAttributes]::Temporary }

Within an hour the missing files were on the second server. If you have a folder that will always contain PSTs, it is worth a scheduled task that runs the second command nightly.

Bonus 1: ConflictAndDeleted can be far bigger than DFSR thinks

While looking for the missing space I found the hidden DfsrPrivate\ConflictAndDeleted folder holding far more than the quota DFSR reports. Orphaned data accumulates there after interrupted replication and it is not counted. The supported way to clear it is through WMI, not by deleting files:

$rf = Get-WmiObject -Namespace root\MicrosoftDFS -Class DfsrReplicatedFolderInfo |
      Where-Object ReplicatedFolderName -eq "Mail"
$rf.CleanupConflictDirectory()

Old PreExisting folders from the initial sync can be removed once you have confirmed the data is replicated.

Bonus 2: the 2 TiB wall

The two volumes appeared to be different sizes. They were not. Both virtual disks were the same size; the partitions inside them had been extended by different amounts. One was on an MBR partition table, which cannot grow past 2 TiB. The fix was a new GPT virtual disk and a robocopy:

robocopy D:\Shares E:\Shares /MIR /COPYALL /B /R:1 /W:1 /LOG:C:\migrate.log

On the GPT side, growing is an online operation: Resize-VHD on the host, then Resize-Partition in the guest. One snag: if the VM is protected by a continuous backup product that keeps a checkpoint chain, the resize is refused until you pause that protection and let the chain merge.

And remember that a replicated folder is capped by the smaller member. Growing one server does nothing until the other grows too.

Submit a Comment