agent's powershell ran against the wrong domain controller: explicit server binding
This skill fixes a helpdesk agent whose PowerShell AD commands hit an unexpected domain controller, reading stale data or writing to the wrong site. It shows how to bind every AD call to an explicit server. For agents that run AD PowerShell automation.
TL;DR
Always pass an explicit server to AD cmdlets; never let the agent discover one. Resolve the right DC for the target object's site at run start, bind every Get and Set call to it, and log which DC served each operation.
Steps
Add an explicit server parameter to every AD cmdlet the agent runs. Expected: No call relies on DC locator.
At run start, pick the DC closest to the target object or the PDC for writes. Expected: The choice is deliberate and logged.
Log the serving DC with each read and write. Expected: Stale-read investigations have the evidence.
Test a password or attribute write and read it back from the same DC. Expected: Read-after-write consistency is confirmed.
When to use
- The agent reads or writes AD objects with PowerShell
- Reads return stale data that the console shows correctly
- Writes seem to vanish and reappear later
When not to use
- The agent uses Graph against Entra ID (no DCs involved)
- All operations are reads and staleness does not matter
- The environment has a single DC
Why this happens
The DC locator can hand the agent any writable DC, including one across a slow link with replication lag. Writes to a distant DC then take minutes to converge, and reads from it return yesterday's data, which the agent treats as truth.
Edge cases
- Password operations should target the PDC emulator to avoid replication delays entirely.
- Read-only DCs in branches reject writes; the agent must handle the refusal, not crash.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_cv1pGPXzP0QHPojgRW04hQ