If you're staring at 0X000021A9 in your event logs or repadmin output, you're probably annoyed because replication just stopped for no obvious reason. Let's get it running again.
The Immediate Fix
Open Active Directory Sites and Services. Drill down to the specific site, server, and NTDS Settings for the destination domain controller. Find the connection object pointing to the source DC that's failing. Right-click it, choose Properties, then go to the Schedule tab.
You'll see a grid of hours and days. If it's mostly white (unavailable), that's your problem. Click and drag to select all cells, then click Replication Available. Apply and OK.
Then run repadmin /syncall /AdeP from an elevated command prompt on the destination DC. It should complete without the 0X000021A9 error.
Why This Works
What's actually happening here is that AD replication uses a schedule on each connection object to control when inbound replication from a specific source is allowed. By default, new connection objects have a schedule that's fully available (all blue). But if an administrator or a script modified it, or if you're using custom replication windows (common in large organizations to control WAN traffic), the schedule might be completely blocked or only open at certain times.
The error code 0X000021A9 translates to ERROR_DS_DRA_OUT_SCHEDULE_WINDOW — the destination server is trying to pull changes, but the schedule says it shouldn't be talking to that source right now. The fix makes the schedule permissive, so replication can happen at any time. The reason step 3 works is that the connection object's schedule is the gatekeeper for inbound replication; opening it lets the KCC and replication engine sync freely.
Less Common Variations
Sometimes the schedule isn't the actual culprit but a symptom of a deeper issue:
- Corrupted connection object: If the schedule looks normal but replication still fails, delete the connection object and let the Knowledge Consistency Checker (KCC) recreate it. Right-click NTDS Settings, choose Check Replication Topology, then right-click again and Replicate Now.
- Firewall or RPC port blocking: The error can also appear if the destination DC can't reach the source DC's RPC endpoint mapper (port 135) or the dynamic ports (49152–65535 on newer Windows). Check with
Test-NetConnection SourceDC -Port 135from PowerShell. - Time skew between DCs: If the clocks differ by more than 5 minutes, Kerberos fails and replication can't start even if the schedule is open. Sync time on both DCs:
w32tm /resync /nowait. - Read-only Domain Controller (RODC) issues: RODCs have their own schedule quirks. If the source is an RODC and the destination is a writable DC, the schedule might be set incorrectly on the RODC's partial replication connection. Check the same schedule tab on the connection object under the RODC's NTDS Settings.
Preventing This in the Future
Don't manually mess with connection schedules unless you absolutely have to. If you need to control replication windows, do it at the site link level instead — that's the intended place. Open AD Sites and Services, expand Inter-Site Transports, pick IP, right-click the site link, choose Properties, and set the schedule there. Site link schedules apply to all replication between sites, not individual DCs. If a third-party backup tool or management script is changing connection schedules, audit that code and disable the schedule manipulation.
Also, monitor replication health daily with repadmin /replsummary. That command catches schedule issues early, before they turn into full replication failures. Set up a scheduled task or a monitoring tool (like PRTG or Zabbix) to alert on any repadmin output that includes 0X000021A9. The moment you see it, you know a connection schedule got misconfigured.