Fix 0X00000A79 DFS Error: Data Identical

This error means DFS thinks the data you're trying to sync is already the same. Usually a naming or folder structure mismatch. Quick fix: check the folder names.

Quick answer: Recreate the DFS replication group with exact folder names, or use dfsrdiag PollNow to force resync.

I know this error is infuriating. It shows up when you're trying to set up DFS replication (DFSR) between two Windows Servers, and Windows tells you the data is already identical — but it's not. The real trigger is often a tiny mismatch between folder names or a stale DC cache. I ran into this on Server 2016 while migrating a file share. Here's the fix.

Why This Happens

DFS uses a database to track changes. If it thinks the data is identical, it refuses to sync. This can happen when:

The folder names on both servers don't match exactly (case sensitivity matters on some systems).
The replication topology is misconfigured (one-way vs two-way).
The DFSR database is stale or corrupted.
You're using DFS Namespaces but the target folders point to different paths.

Fix Steps (Main Fix)

Check folder names exactly. Open File Explorer on both servers. Go to the shared folders. Make sure the folder names are identical — same letters, same numbers, no extra spaces. For example, if you have \\server1\shares\Data, then \\server2\shares\Data must be named Data, not data or Data (copy).
Restart the DFS Replication service. On both servers, open PowerShell as Admin and run:
```
Restart-Service DFSR
```
Wait 30 seconds, then check the event log for ID 2214 (success).
Force a poll. Run this command on both servers:
```
dfsrdiag PollNow
```
This tells DFS to check for changes immediately.
Check replication topology. Open DFS Management console. Go to Replication > your group. Right-click the connection between servers and choose Edit. Make sure it's set to two-way, not one-way.
Disable and re-enable replication. In DFS Management, right-click the replication group and select Disable. Wait 5 minutes, then enable it again. This clears the internal state.

Alternative Fixes If The Main One Fails

Use dfsrdiag to reset the database. This is more aggressive but works when the database is corrupt. Run on each server separately:
```
dfsrdiag Backlog /RGname:"your group name" /RFname:"your replication folder name" /SendingMember:server1 /ReceivingMember:server2
```
If backlog shows enormous numbers, stop DFSR service, delete the folder C:\Windows\System32\DFSR\Config, then restart service and run PollNow again.
Recreate the replication group from scratch. This is painful but reliable. In DFS Management, delete the replication group. Create a new one with the same folders. When you add both servers, make sure the local paths point to the exact same folder names. This fixes most naming mismatches.
Check AD replication. Error 0X00000A79 can be caused by stale Active Directory data about the replication group. Run on a Domain Controller:
```
repadmin /syncall /AdeP
```
Then restart DFSR on both file servers.

Prevention Tips

Always use the same folder names on both servers. I write them down before configuring.
Before setting up DFSR, use robocopy with the /MIR flag to pre-seed data. This avoids initial sync issues.
Keep your Windows Server patched. I've seen this error fixed by KB5001401 (Server 2019) and similar updates.
Don't rely on the Data is identical message — it's often wrong. Force a poll first.

If none of this works, check the DFSR event logs (ID 2114, 2212, 2213) for more clues. But 9 times out of 10, it's a folder name mismatch or a stale database. Good luck — you'll beat this.