Fix Printer Replication Error 0X000021BF

When Does This Error Hit You?

Picture this: you're setting up a shared printer on a Windows Server 2019 box. You delete the old printer object in Active Directory because the model changed. Then you immediately create a new one with the same name. Next thing you know, other domain controllers throw error 0X000021BF – ERROR_DS_DRA_RECYCLED_TARGET. The replication engine gets confused because the target object it's trying to sync is in the recycling bin (or tombstone) state.

I had a client last month whose entire print queue died because of this. Their IT guy did a quick printer swap without thinking about AD replication delays. Took me an hour to figure out what happened.

Root Cause – Why This Happens

Active Directory has a recycle bin feature (since Server 2008 R2). When you delete a printer object, it goes there first. If you re-create an object with the same name (or link value) before the recycle bin clears it, the replication system finds two objects with conflicting states. The error says: "I can't replicate because the target is recycled."

This also pops up if you use Group Policy to deploy printers and the GPO references a deleted printer. The domain controller tries to replicate the stale link and fails.

The Fix – Step By Step

Check if the printer object is in the recycle bin. Open Active Directory Administrative Center. Look under the Deleted Objects container. If you see the old printer object there, restore it. Right-click and choose Restore. This usually clears the replication conflict.
If you can't restore, force AD replication cleanup. On the affected domain controller, run this command as admin:
```
repadmin /syncall /AdeP
```
This forces replication of all partitions and removes stale links. Wait 5-10 minutes.
Remove the broken link manually. If the error still shows in Event Viewer, the link value (like a printer's GUID) might be stuck. Use ADSI Edit to find the printer object's distinguishedName. Then delete the orphaned reference in the msExchOmaAdminObjectLink attribute (if present) or just remove and re-add the printer in the Print Management console.
Wait for the tombstone lifetime to expire. This is a pain, but sometimes you just need to wait. Default tombstone lifetime in modern AD is 180 days. Check your value with:
```
repadmin /showattr . "cn=tombstonelifetime,cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=yourdomain,dc=com"
```
If it's still high, you can lower it (not recommended for production) or use the repadmin trick above.

What to Check If It Still Fails

If the fix didn't work, look at these three things:

Replication latency. Run repadmin /replsummary. If you see high failure counts between specific domain controllers, fix those first. The printer error might be a side effect.
Group Policy conflicts. Open Group Policy Management, find any policies deploying printers. Check if they reference the deleted printer's UNC path. Remove or update those policies.
Third-party print solutions. Some print management software creates AD objects under the hood. If you're using PaperCut or PrinterLogic, check their logs. One of them might have triggered the re-creation.

Bottom line: stop deleting and re-creating printer objects quickly. Use the Rename option in Print Management instead. It avoids this whole mess. Your domain controllers will thank you.