FRS_ERR_SERVICE_COMM (0X00001F46): File Replication Service Won't Start
This error means the File Replication Service can't talk to other domain controllers. Nine times out of ten it's a broken NTDS connection or a stuck FRS journal wrap.
The 30-Second Fix: Check If FRS Is Actually Running
Open Services.msc, look for File Replication Service. If it's stopped, right-click and start it. If it starts but throws this error again within minutes, skip to the next section.
The 5-Minute Fix: Kill Stale NTDS Connections
The real culprit here is almost always a broken NTDS connection on the target domain controller. Here's what you do:
- Open Active Directory Sites and Services
- Expand your site, then Servers, then the DC showing the error
- Click NTDS Settings
- In the right pane, right-click each connection and select Delete (yes, all of them – they'll rebuild automatically)
- Right-click NTDS Settings and choose Check Replication Topology
- Wait 5 minutes, then restart the File Replication Service
Don't bother checking DNS or firewall rules first – it's rarely that. FRS is old and fragile. If the NTDS connections are stale, FRS won't even try to contact its partners.
The 15-Minute (Guaranteed) Fix: BurFlags Registry Fix
If the above doesn't work, you're dealing with a journal wrap. FRS has a limited set of journal records. On a busy DC, it can fill up fast. Once it wraps, FRS gives up.
Step 1: Stop FRS and Set BurFlags
net stop ntfrs
Open Regedit, go to:
HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
Set the value to DWORD 2 (this is the BurFlags value for a non-authoritative restore). It tells FRS to grab SYSVOL content from a partner.
Step 2: Clean the FRS staging directory
del /q /s C:\Windows\NtFrs\Staging\Area\*
Also delete everything in:
C:\Windows\NtFrs\Jet\Ntfrs.jdb
Don't worry – that's just the FRS database. It'll be rebuilt from the partner.
Step 3: Start FRS and Check Event Logs
net start ntfrs
Wait 10 minutes. Look in Event Viewer under File Replication Service for event ID 13562 (successful restore). If you see event ID 13508 or 13509, your partner DC has the same issue – repeat this fix on the partner DC first.
When None of This Works: Migrate to DFSR
If you're still stuck after 30 minutes, you're on Server 2008 R2 or later. Migrate SYSVOL from FRS to DFSR. Microsoft dropped FRS support in Server 2008 R2 for a reason – it's a dumpster fire.
Run these commands on a domain controller with Schema Admin rights:
dcdiag /test:frssysvol /test:dfsrsysvol
dfsrmig /getglobalstate
If the state is "start" or "prepared", you're already partway there. Push it to "redirected" and never look back:
dfsrmig /setglobalstate 2
dfsrmig /getmigrationstate
FRS errors like 0X00001F46 are a sign from the universe – it's time to move on.
Quick Table of BurFlags Values
| Value | Meaning |
|---|---|
| 0 | Normal startup (default) |
| 2 | Non-authoritative restore (grab from partner) |
| 4 | Authoritative restore (become the master – use only if partner is dead) |
Don't use DWORD 4 unless you know what you're doing. It forces all other DCs to copy from the one you set it on. Wrong DC = broken SYSVOL everywhere.
One last thing: if this DC is the last surviving one in the domain, you can't fix FRS by talking to a partner that doesn't exist. You'll need to do an authoritative restore (BurFlags 4) or rebuild SYSVOL from scratch. That's a separate article.
Was this solution helpful?