Quick answer: The File Replication Service (FRS, service name NtFrs) is the old Windows Server service that copied the SYSVOL folder (Group Policy files and logon scripts) between domain controllers. It is deprecated and has been removed from newer Windows Server versions, so you can’t add a Windows Server 2019 or later domain controller to a domain that still uses it. Run dfsrmig /getglobalstate on a domain controller: if it says migration hasn’t been initialized, you’re still on FRS and should migrate SYSVOL to DFS Replication (DFSR) with dfsrmig.
Applies to: Active Directory domains with domain controllers running Windows Server. Run the commands in an elevated Command Prompt or PowerShell on a domain controller, signed in as a Domain Admin.
In this guide

What the File Replication Service is
Every domain controller keeps a copy of SYSVOL, a shared folder that holds Group Policy templates and logon scripts. When you edit a Group Policy Object in the Group Policy Management Console, the change is written to one domain controller’s SYSVOL and has to be copied to all the others. In Windows 2000 and Windows Server 2003 domains, FRS did that copying.
Windows Server 2008 introduced DFS Replication (DFSR), which is faster, copies only the changed parts of files and recovers from problems much better. Domains created at the Windows Server 2008 domain functional level or later use DFSR from the start, but domains that were upgraded from older versions often still use FRS for SYSVOL because the switch is never automatic.
Check whether your domain still uses FRS
On any domain controller, run:
dfsrmig /getglobalstate
- DFSR migration has not yet initialized: the domain still replicates SYSVOL with FRS.
- Current DFSR global state: ‘Eliminated’: migration is complete and FRS is no longer used for SYSVOL.
- ‘Prepared’ or ‘Redirected’: a migration was started and not finished. Finish it (see below) rather than leaving it half-done.
Two other quick signs: net share shows the SYSVOL share under C:\Windows\SYSVOL\sysvol with FRS, but under C:\Windows\SYSVOL_DFSR\sysvol after migration, and Event Viewer has an active Applications and Services Logs > File Replication Service log with recent SYSVOL events while FRS is in use.
Why you need to move off FRS
- Microsoft deprecated FRS for SYSVOL starting with Windows Server 2008 R2 and removed it in Windows Server version 1709. Windows Server 2019 and later can’t replicate SYSVOL with FRS.
- If you try to promote a Windows Server 2019 or later server to a domain controller in an FRS domain, promotion stops with a message saying the domain is still using FRS to replicate SYSVOL and that FRS is deprecated.
- Upgrading an existing domain controller in place to Windows Server 2019 while the domain still uses FRS can leave SYSVOL unshared and break replication. Migrate first, then upgrade.
- FRS gets no fixes and is prone to problems such as journal wrap, which can stop SYSVOL replication silently.
Before you migrate

The migration is safe on a healthy domain, but it copies SYSVOL from FRS’s current state. If FRS or Active Directory replication is already broken, fix that first, or you’ll carry the problem over.
- Make sure the domain functional level is at least Windows Server 2008.
dfsrmigdoesn’t work below it. Check it in Active Directory Domains and Trusts (right-click the domain and choose Properties). - Check that every domain controller replicates Active Directory without errors:
repadmin /replsummaryshould show 0 fails. - Run
dcdiag /e /test:sysvolcheck /test:advertisingand fix any domain controller that fails. - Make sure the DFS Replication service is running and set to Automatic on every domain controller.
- Take a system state backup of at least one domain controller, and note which domain controller holds the PDC emulator role (
netdom query fsmo). Run the migration commands there.
If a workstation can’t contact the domain during this work, it’s usually unrelated to SYSVOL; see the trust relationship between this workstation and the primary domain failed for that error.
Migrate SYSVOL from FRS to DFSR
The migration has four states: 0 Start, 1 Prepared, 2 Redirected and 3 Eliminated. Move one state at a time and wait until every domain controller has reached it before going to the next.
- Prepared: run
dfsrmig /setglobalstate 1. Each domain controller copies SYSVOL into a newSYSVOL_DFSRfolder and starts DFSR, while FRS keeps serving clients. - Check progress with
dfsrmig /getmigrationstate. Repeat until it says all domain controllers have migrated successfully to the global state (‘Prepared’). To speed things up, force Active Directory replication withrepadmin /syncall /AdeP. - Redirected: run
dfsrmig /setglobalstate 2. TheSYSVOLshare now points toSYSVOL_DFSR, so DFSR copies are what clients use. Check withdfsrmig /getmigrationstateagain, then test: edit a Group Policy Object, confirm the change reaches another domain controller, and rungpupdate /forceon a client. - Eliminated: run
dfsrmig /setglobalstate 3only when everything works in the Redirected state. Domain controllers stop and disable FRS for SYSVOL and remove the old folder. Wait fordfsrmig /getmigrationstateto report every domain controller as Eliminated.
Important: you can go back from Prepared or Redirected (set a lower state), but Eliminated can’t be undone. After it, net share should show SYSVOL under C:\Windows\SYSVOL_DFSR\sysvol and dfsrmig /getglobalstate should report Eliminated. Once that’s true on every domain controller, you can add Windows Server 2019 or later domain controllers.
Common FRS errors and what they mean

- Event ID 13508: FRS can’t replicate with a partner domain controller. Usually DNS, the network, or Active Directory replication between those two domain controllers is the cause. Check name resolution and
repadmin /showreplon both. - Event ID 13568 (journal wrap): FRS lost track of changes on the volume and stopped replicating. Older guides fix this with BurFlags registry restores; on any modern domain the better fix is to get the domain healthy and finish the migration to DFSR.
- Event ID 13559: the replica root path was moved, for example after restoring or moving SYSVOL. FRS stops until you confirm the new location, as the event text explains.
- Promotion blocked on Windows Server 2019 or later: the domain still uses FRS. Migrate as above from an existing domain controller, then promote the new server.
If FRS replication is badly broken and you’re unsure, don’t start forcing restores on several domain controllers at once; fix one partner pair at a time or ask your Microsoft support channel.
Related guides
- Group Policy Management Console on Windows 11: how to install and open it
- “The trust relationship between this workstation and the primary domain failed”: how to fix it
- “The Active Directory Domain Services Is Currently Unavailable”: How to Fix It
Official sources: for more detail, see Microsoft’s own pages:
- Microsoft Learn: Migrate SYSVOL replication to DFS Replication
- Microsoft Learn: FRS deprecation blocks installation of a replica domain controller
- Microsoft Learn: SYSVOL DFSR migration fails after an in-place upgrade
Frequently asked questions
Can I just disable the File Replication Service?
Not while the domain uses it for SYSVOL: Group Policy changes would stop reaching other domain controllers. Finish the DFSR migration and Windows disables FRS for SYSVOL for you in the Eliminated state.
Does the migration cause downtime?
No. Clients keep using SYSVOL throughout; the switch happens at the Redirected step. Plan it outside busy hours anyway and avoid editing Group Policy while it runs.
How long does the migration take?
In a small domain with healthy replication, each state can complete within minutes. Large domains or slow links take longer because each domain controller has to pick up the new state through Active Directory replication.
Is FRS the same as DFS Replication?
No. DFS Replication (DFSR) is the newer replacement. It’s also used for DFS Namespaces folder replication, which is separate from SYSVOL; migrating SYSVOL with dfsrmig doesn’t change those.
Leave a Reply