## 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
```text
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