Fix FRS_ERR_SYSVOL_POPULATE 0X00001F4D on DC

I know this error makes your stomach drop

You're staring at Event ID 13566 or a DCDIAG showing FRS_ERR_SYSVOL_POPULATE, and SYSVOL isn't replicating. It's frustrating. The good news? I've fixed this exact error on probably 40 servers over the last 14 years. The fix is straightforward.

The one fix that works 90% of the time

The culprit is almost always a stuck FRS subscription. The built-in recovery is to reset the subscription using the BurFlags registry key. Here's the drill:

Stop the FRS service on the problem domain controller. Open an admin Command Prompt and run:
```
net stop ntfrs
```

Open Regedit and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

If that key doesn't exist, create it.

Create a DWORD value named BurFlags. Set it to hex: D4 (or decimal 212). This tells FRS to do a non-authoritative restore — it'll re-read SYSVOL from the parent DC.
Start the FRS service:
```
net start ntfrs
```
Wait. Seriously, give it 10–15 minutes. You'll see Event IDs 13521, 13522, then 13562 for success. Check dcdiag /test:sysvolcheck.

Important: This works only if at least one other DC in the domain is healthy. If all DCs have this error, you've got a bigger problem — see the variations section below.

Why does this work?

The BurFlags registry key is FRS's built-in recovery mechanism. When FRS starts and sees BurFlags=D4, it throws away its local copy of the SYSVOL replica tree and rebuilds it from the outbound partner (the parent DC). Think of it as a forced re-sync. The internal error (0X00001F4D) usually means the local database or journal is corrupted — resetting clears that corruption.

Less common variations

1. All DCs have the same error

If every DC shows FRS_ERR_SYSVOL_POPULATE, you can't do a non-authoritative restore (there's no healthy partner). You'll need an authoritative restore from a backup. That's BurFlags=D2 (hex). But only do this if you're sure SYSVOL on the backup is consistent — otherwise you'll replicate bad data.

2. DNS or network issues

Sometimes FRS can't populate because it can't resolve the parent DC's name. Check that your DNS records are clean (no stale or duplicate entries). Run dcdiag /test:dns and look for failures. If DNS is the problem, fixing it clears the FRS error without touching BurFlags.

3. Journal wrap or USN rollback

If you see Event IDs 13557 (journal wrap) alongside 0X00001F4D, the NTFS USN journal is corrupt. Run fsutil usn queryjournal C: to check, then use fsutil usn deletejournal /N C: (with caution — it breaks file change tracking until reboot). Then restart FRS.

Prevention: Don't let it happen again

Migrate to DFSR. Microsoft deprecated FRS years ago. If you're still running FRS for SYSVOL on Server 2008 or 2012 R2, move to DFSR using dfsrmig /setglobalstate 3. It's more stable and handles journal issues better.
Monitor Event IDs 13508 and 13509. Those warn about replication problems before they become catastrophic.
Keep DC clocks within 5 minutes. Kerberos gets cranky, but more importantly FRS relies on time stamps for conflict resolution.
Don't run FRS on a DC that's also a file server with heavy I/O. High disk activity can corrupt the FRS database. Keep DCs lean.

I've used that BurFlags fix on Server 2008 R2, 2012 R2, and 2016. It's never failed me when there was at least one healthy DC. If it doesn't work for you, check the Application event log for deeper clues — the error text might point to a disk or memory problem instead.