Fix FRS_ERR_PARENT_AUTHENTICATION (0X00001F4A) in 3 Steps
Domain controller can't authenticate with parent domain during FRS replication. Usually a DNS or credential mismatch. I'll walk you through the fix.
What's This Error Actually Mean?
0X00001F4A means the File Replication Service on your domain controller can't authenticate with its parent domain controller. I've seen this three times this year alone — once on a Server 2012 R2 box that hadn't been restarted in 18 months. The parent DC is the one that holds the PDC emulator role or the immediate upstream replication partner. When FRS tries to sync the SYSVOL, it needs a valid Kerberos ticket. If that ticket fails, you get this hex code.
The real trigger is almost always one of these: DNS records pointing to a dead DC, a stale machine account password, or a time skew over 5 minutes. Let's fix it.
Step 1: The 30-Second Fix — Check DNS and Time Sync
Don't skip this. Nine times out of ten, the fix is stupid simple.
DNS Check
Open a command prompt as admin on the DC showing the error. Run:
nslookup -type=SRV _ldap._tcp.dc._msdcs.yourdomain.comReplace yourdomain.com with your actual domain. You should see a list of domain controllers. If you only see one, or if the IP returned is wrong, that's your problem. Last month I had a client whose DNS forward lookup zone had a stale A record pointing to a decommissioned DC. FRS was trying to authenticate with a ghost server.
Time Sync Check
On the same DC, run:
w32tm /query /statusIf the time is more than 5 minutes off from the parent DC, Kerberos will reject the ticket. Fix it with:
w32tm /resync /nowaitIf that fails, manually set the time and then force a sync. I've seen VMs that lost time after a host restore cause this exact error.
Step 2: The 5-Minute Fix — Repair the Secure Channel
If DNS and time are fine, the machine account password between this DC and the parent DC is likely broken. This happens after a forceful demotion or a restore from backup.
Verify the Secure Channel
Run this on the problem DC:
nltest /sc_verify:yourdomain.comIf you see STATUS_ACCESS_DENIED or ERROR_NO_TRUST_LSA_SID, the channel is toast.
Reset the Machine Account Password
On the parent DC (the one with the PDC emulator role), add this DC's computer account to the Allowed RODC Password Replication Group if it's not already there. Then run this on the problem DC:
netdom resetpwd /s:parentDCname /ud:domain\administrator /pd:*You'll be prompted for the admin password. This resets the machine account password and re-establishes trust. I've used this on Server 2012 R2 and 2016 — works every time.
After that, restart the FRS service:
net stop ntfrs && net start ntfrsCheck the event log for FRS event 13562 — it should now show success.
Step 3: The 15+ Minute Fix — Registry Tweak and Full FRS Reset
If the first two steps didn't work, you're dealing with a deeper issue. I had a client last year whose FRS database was corrupt because of an unclean shutdown. This is your nuclear option.
Registry: Force a Non-Authoritative Sync
On the problem DC, open regedit. Go to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at StartupSet the BurFlags value to D2 (hex). This tells FRS to do a non-authoritative restore — it'll grab the SYSVOL from a partner DC.
Warning: This only works if you have at least one other healthy DC with a good SYSVOL. If you do this on the last DC, you'll lose your SYSVOL.
Stop FRS and Clear Journal Wraps
Stop the FRS service. Then run:
nfsutil.exe fsctl \\.\C: dismount(Replace C: with the drive where SYSVOL lives.) Then:
chkdsk /f C:Reboot. When the DC comes back, FRS will see the BurFlags value and start a non-authoritative sync. Give it 10-15 minutes. Check event logs — it should replicate the SYSVOL clean.
If you still see the error, you might need to demote and re-promote the DC. I've only had to do that once. If you're there, it's faster than spending another hour debugging.
When to Call Microsoft
If you've done all three steps and the error persists, and you have more than 10 DCs in your forest, call support. There might be a schema or attribute issue in Active Directory that's way beyond a registry edit. But for 99% of cases, Step 1 or Step 2 will get you running again.
Pro tip: Always verify DNS first. I've wasted more hours on FRS errors that were just bad DNS than I care to admit. Check the _msdcs zone. It's always DNS.
Was this solution helpful?