Share via

DFS Replication issue after Disk replacement

Researcher 51 Reputation points
2025-09-25T06:15:05.4833333+00:00

Hello everyone,

We have configured DFS-Replication for two Windows Server 2019 PCs in a test environment. These two servers have identical HDDs with three partitions , one for the OS drive ( say C:) and two paritions for general use data ( D: and E:). We had configured DFS replication for these servers such that the first sever, say PC-1 is the primary server in this replication partnership and PC-2 is the secondary server, with read-only replication for PC-2 only. We had configured replication only for the shared folder D: , which is the partition itself for both the servers. Once we switched off PC-1 to simulate a failure, and moved its HDD to PC-2 and then renamed this PC-2 to PC-1 and reconfigured DFS replication, we noticed that the data between the D: drives is ceased to replicate. The data was being replicated before the failover simulation, but not after we moved its HDD back and forth. ( For info as to why we are moving the disks, please refer these forum posts

Further, if we configure the DFS replication for a new partition , say E:, then its data is being replicated properly without any issues. For the original drive D:, we are not seeing any error messages and the replication connections is showing success. Are there any reasons as to why the replication for original drive of the primary server ( which is D: in our case) does not work after the HDD from original disk is moved back after connecting to the secondary server?

Sequence followed:

  1. Switched off the primary server , say PC-1
  2. Removed the HDD from this PC-1 and connected to PC-2, along with the original HDD of PC-2.
  3. Stopped the DFS Replication from the secondary ( now active) server, which is PC-2 "4.Declare the original primary server as failed in Active Directory in the domain controller, and ran below command Remove-DfsrMember -GroupName ““Replication”” -ComputerName ““PC-1"””
  4. Cleared any DNS records that were present in the primary failed server’s name, including in the Forward Zones and A-records
  5. Renamed the secondary server from PC-2 to the new name ‘PC-1’
  6. Rebuilt the replication group

Troubleshooting steps tried: 1.Removed all replication groups and checked 2.Removed the DFS namespace and DFS Role itself and checked 3.Enabled replication to a new partition (E:) and then checked whether will work for D: as well, but not worked

We have noticed that the Folder permissions are modified for the original D: partition after connected back to the primary server

Specifications: “Windows Server 2019 OS Version 1809 and Build number 17763.6532, 4-Logical Processors, 4 Core 64-bit OS and x64-based processor” Processor: Intel Core i5-7400 CPU @ 3.00 GHz HDD: Seagate Barracuda Model ST1000DM010-2EP102 Size 931.51 GB No RAID configured, ‘Simple’ Volume RAM: 32 GB BIOS Version : American Megatrends Inc 3402 (5 Jul 2017)

Thanks in advance.

Windows for business | Windows Server | Storage high availability | Clustering and high availability
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Briston Capital 160 Reputation points
    2025-09-25T07:06:50.6366667+00:00

    Hm, it’s likely that the folder permissions on the original D: drive were altered during the disk reassignment, which can silently block DFS replication even if the connection shows success. I recommend verifying that the replicated folder has the correct NTFS permissions and that the DFS Replication service account retains full access. Also, ensure the DFS Replication database isn’t referencing stale metadata from the previous configuration.

  2. Henry Mai 6,425 Reputation points Independent Advisor
    2025-09-25T07:10:21.2133333+00:00

    Hello Researcher, I am Henry and I want to share my insight about your issue.

    Based on your description, the issue is not with your overall DFS configuration but is isolated to the D: drive itself. When you moved the physical disk between servers, the hidden metadata in the System Volume Information folder became inconsistent with the new replication partnership. DFS-R sees the old database, assumes the content is up-to-date, and fails to sync silently.

    You can refer this solution is to force DFS-R to re-initialize the database for the D: drive, treating it as a new replication target.

    Perform these steps on the primary server (PC-1).

    1. Stop the DFS Replication Service: Open an administrative PowerShell or Command Prompt and run: net stop DFSR
    2. Reset the DFS-R Database for Drive D: You must delete the hidden database folder. This requires taking ownership of it first.
      • Run the following commands in order from your administrative prompt:
        • takeown /f "D:\System Volume Information\DFSR" /r /d y
        • icacls "D:\System Volume Information\DFSR" /grant administrators:F /t
        • rd /s /q "D:\System Volume Information\DFSR"
    3. Restart the DFS Replication Service: net start DFSR
    4. Force Replication and Verify: The service will now perform an initial sync for the D: drive. You can force an immediate poll and check the status.
      • Force polling: dfsrdiag pollad
      • Check the replication backlog (it should start high and then decrease to 0): dfsrdiag replicationstate

    This procedure forces DFS-R to build a clean database for the D: volume and will re-establish replication.

    Online Documentation

    • DFSRDIAG Command-Line Tool: This is the official Microsoft reference for the diagnostic tool used to force polling and check replication status.
    • DFS-R Initial Sync Process: This documentation explains the initial sync behavior, which is what you are manually triggering by following the steps above.

    I hope this information and these keywords help point you in the right direction for your research. Let me know how it goes, and if this answer helps, feel free to hit “Accept Answer” so others can benefit too

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.