Dual DC DSFR Replication Issues

Question

Running Windows Server 2025 (DC01, VM, PDC Emulator) and Windows Server 2023 (SERVER2023, physical, secondary DC). DFSR replication showing zero active connections.

Investigation found:

• DFSR migration state is Eliminated on both DCs
• Both DCs registered as msDFSR-Member objects in AD
• No SYSVOL Subscription objects exist under either member object
• Get-DfsrMembership returns empty
• Get-DfsReplicatedFolder returns empty
• dfsrdiag replicationstate shows zero connections
• DFSR service running on both DCs
• AD replication healthy between both DCs
• Time sync healthy on both DCs

Issue likely started after DC role swap — SERVER2023 was original primary, DC01 promoted as new primary PDC Emulator, DC01 experienced downtime earlier this year.

Looking for safe procedure to rebuild SYSVOL Subscription objects without data loss.

Answer 1

Hi Henry DiNapoli

What you’re seeing is a DFSR setup that’s lost its SYSVOL subscriptions, so replication is dead in the water even though the service is running fine. Since both DCs show “Eliminated” state and no replicated folders, you’re essentially in a post-migration state where DFSR isn’t holding any active memberships. That’s why Get-DfsrMembership and Get-DfsReplicatedFolder come back empty.

The safe way forward is to rebuild the SYSVOL subscriptions without touching the actual data. The usual approach is to run through the DFSR reinitialization process: stop DFSR, clear out the memberships, and then re-add the SYSVOL replicated folder via ADSIEdit or PowerShell. Once you’ve got the subscription objects recreated, you can set one DC (usually the PDC Emulator) as authoritative with dfsrdiag pollad and dfsrdiag syncnow. That ensures the existing SYSVOL data is treated as the master copy, so you don’t lose anything.

It’s important not to manually delete or overwrite SYSVOL contents let DFSR handle the sync once the subscriptions are back. Also, double-check AD replication health after you rebuild, because DFSR relies on AD to push those membership objects. If you want to be extra cautious, take a backup of SYSVOL before starting, just so you’ve got a rollback option.

So in short: rebuild the subscription objects, set DC01 as authoritative, and let DFSR resync. That’ll get your SYSVOL replication back online without data loss. If this clears things up for you, please hit “accept answer” so we know it helped.

Answer 2

The safest supported way to rebuild SYSVOL DFSR membership and subscription objects without data loss is to follow the documented DFSR SYSVOL recovery process rather than trying to hand‑create the objects.

Given the symptoms (no SYSVOL subscription objects, DFSR state Eliminated, no active connections), treat this as a missing/failed SYSVOL/NETLOGON share scenario and reinitialize DFSR for SYSVOL using the authoritative/non‑authoritative procedure.

High‑level, safe approach:

1. Back up SYSVOL on both DCs
   • On each DC, take a full backup of the current SYSVOL tree (typically C:\Windows\SYSVOL), including Policies and Scripts. This protects against accidental data loss during reinitialization.
2. Evaluate DFSR state and SYSVOL share on both DCs
   • Confirm which DC (likely DC01, the PDC Emulator) has the most correct and up‑to‑date SYSVOL contents.
   • Check whether SYSVOL is actually shared on either DC using:

          net view \\DC01 | find "SYSVOL"
          net view \\SERVER2023 | find "SYSVOL"
     

   • If SYSVOL is not shared anywhere, follow the missing SYSVOL guidance below after backups are taken.
3. Use the supported DFSR SYSVOL recovery procedure
   • Follow the guidance in How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS) as referenced in the troubleshooting articles:
     • Choose one DC (typically the PDC Emulator with the best SYSVOL) as authoritative.
     • Configure the other DC as nonauthoritative.
   • The referenced article describes how to:
     • Disable DFSR membership on the nonauthoritative DC(s) so they discard their local DFSR state for SYSVOL.
     • Mark the authoritative DC so its SYSVOL becomes the source of truth.
     • Re-enable membership so DFSR automatically recreates the replication group, memberships, and SYSVOL subscription objects in AD.
4. If SYSVOL/NETLOGON are missing, follow the missing‑share workflow
   • The missing SYSVOL/NETLOGON troubleshooting guidance recommends:
     1. Back up SYSVOL (already done).
     2. Set affected DCs as nonauthoritative by disabling DFSR membership as described in the authoritative/non‑authoritative article.
     3. From a healthy DC (authoritative), fan out recovery to partners, ensuring replication topology is respected.
     4. Wait for DFSR events 4614 and 4604 on recovered DCs, indicating initial sync and SYSVOL initialization are complete.
   • If content freshness (event 4012) or dirty shutdown (event 2213) is involved, use the same authoritative/non‑authoritative procedure instead of deleting the DFSR database.
5. Do not manually create DFSR SYSVOL subscription objects
   • The guidance explicitly discourages manual database or object manipulation:
     • Deleting the DFSR database or manually recreating objects is not required and is discouraged because it forces DFSR to treat all local data as nonauthoritative and can cause data loss.
   • Let DFSR rebuild its own membership and subscription objects via the supported recovery steps.
6. Validate after recovery
   • After the authoritative/non‑authoritative procedure completes:
     • Confirm DFSR state for SYSVOL is Normal (state 4) on both DCs using the documented WMI query.
     • Confirm SYSVOL and NETLOGON shares exist on both DCs (net view \\DC01, net view \\SERVER2023).
     • Confirm DFSR logs show 2212, 2218, then 2214 (for resumed replication) or 4614 and 4604 (for initial sync/initialization) as appropriate.
     • Verify Group Policy objects and scripts exist and match on both DCs; restore any missing items from the backup or from the PreExisting / Conflict and Deleted folders as described.
7. Only use authoritative recovery in the specific supported scenario
   • The documentation stresses that setting a DFSR server as authoritative for SYSVOL is only appropriate when:
     • There is a clear, single DC with the most up‑to‑date SYSVOL contents, and
     • Other DCs are in error or blocked by content freshness.
   • In all other cases, use nonauthoritative recovery on affected DCs and let DFSR converge.

Following this process allows DFSR to recreate the SYSVOL replication group, memberships, and subscription objects in AD in a supported way, while minimizing risk of data loss by backing up SYSVOL first and designating a single authoritative source.

---

References:

• How to troubleshoot missing SYSVOL and Netlogon shares
• DFSR SYSVOL fails to migrate or replicate, SYSVOL not shared, Event IDs 8028 or 6016