agent's ad lookup returned stale data URIs domain controller replication lag

TL;DR

The agent queried a DC that had not yet received the replication. Target the primary DC for writes and fresh reads, wait for or force replication, then re-read before acting.

The query

agent's ad lookup returned stale data URIs domain controller replication lag

Use this when

• the agent sees old group memberships or attributes
• a change made in one tool is invisible in another
• the data is right in one console and wrong in another

Not for

• LDAP query syntax errors
• permission denied on reads
• attributes that never replicate by design

Steps

1. Confirm staleness by comparing the attribute on two different DCs. Expected output: the lagging DC is identified.
2. Point the agent's write and immediate-read operations at the PDC emulator. Expected output: reads reflect the latest writes.
3. If waiting is acceptable, pause for the replication interval, then re-read. Expected output: the data converges.
4. For urgent cases, trigger replication and re-read before the agent acts. Expected output: fresh data confirmed.
5. Add a freshness check on critical attributes before destructive actions. Expected output: the agent never acts on stale data.

Applies to

Active Directory replication, multi-DC environments, helpdesk agents querying AD.

Variant phrasings

Stale data only across sites

Site link replication schedules are the cause; check the schedule, not the agent.

Attribute never converges

Some attributes do not replicate; read them from the authoritative DC always.

Why it happens

AD is eventually consistent across DCs. Agents that read from any DC and act immediately race replication and lose.

Edge cases

• Password changes replicate urgently; group membership may not.
• Log which DC served each read; without it, staleness is undebuggable.
• Urgent replication triggers need admin rights; grant them narrowly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DYAjhSn3L9PgsjGybJSJLg