Active Directory / Editorial solution guide

Separate directory replication from SYSVOL evidence

Name the affected partition and direction, preserve the two policy components, and avoid treating a stale snapshot as authority to force synchronization or restore a controller.

About 3 min readContent reviewed

Read-only knowledge base · No public comments

Recognize the symptoms

One controller appears to have a recent directory object while policy files or client behavior differ elsewhere. Another incident can show missing SYSVOL/NETLOGON shares or a replication error category without proving every partition failed. Record which object/component, source, destination, and time each observation concerns. “Replication is broken” hides those distinctions.

Successful authentication through a controller does not prove its SYSVOL content is current. Conversely, matching policy files do not prove all directory partitions, service identities, or network paths are healthy.

Understand the likely causes

  • Directory metadata and SYSVOL files replicate through different mechanisms with their own state and dependencies. AD replication is directional and partition-specific. Raw local sequence numbers are not a universal cross-controller version clock, and file modification times are not a complete consistency proof.
  • DNS, topology, connectivity, authentication, paused/initializing file replication, content-freshness protection, or unsupported restore history can require different investigation. None is established merely by a stale model label. Authoritative recovery changes propagation authority and must follow an approved known-good recovery design, not an ad hoc retry.

Classify component and evidence state separately

The complete Python fixture holds three synthetic normalized observations and lists unknown separately from contradicted. It performs no replication, share access, event-channel query, or Windows API call. supported means only the fixture author supplied that label; it does not validate the underlying observation. The distinction prevents an unmeasured SYSVOL state from silently becoming a proven directory failure. A real handoff also needs the exact partition/direction and approved timestamps for every record.

python Complete offline component-evidence classifier 
observations = [
    {"controller": "dc-b", "component": "directory", "state": "supported"},
    {"controller": "dc-b", "component": "SYSVOL", "state": "unknown"},
    {"controller": "dc-c", "component": "directory", "state": "contradicted"},
]
for category in ["unknown", "contradicted"]:
    labels = sorted(item["controller"] + ":" + item["component"] for item in observations if item["state"] == category)
    print(category, labels)
Expected output
unknown ['dc-b:SYSVOL']
contradicted ['dc-c:directory']

The model prints unknown dc-b:SYSVOL and contradicted dc-c:directory in their separate lists. No real status is discovered.

Do not manufacture an authoritative source from one symptom

Preserve authorized last-success and error context, component identity, selected controller, topology, and any relevant recovery history. A missing share can mean incomplete initialization or protected content state; manually sharing a folder can expose an invalid replica. A more recent copy can contain an unwanted change. Do not force synchronization, restart replication, alter attributes, seize roles, or reconnect an old restored controller to test a guess. The responsible operational owner must select the applicable official diagnostic or recovery procedure after establishing the cause and trusted state.

Hand off a precise question instead of a repair command

The contextual record below asks for AD and SYSVOL evidence independently and preserves an explicit recovery approval gate. It is not a supported diagnostic script or restore plan. Include what changed recently and the client symptom, but do not assume every difference is caused by that change. The intended next action is an authorized evidence review. Sensitive backup details and recovery access belong in the protected operational process, not a public course example.

json Non-runnable consistency escalation record 
{"incident":"synthetic-consistency-case","partition":"domain:ad.example.test","direction":"dc-a-to-dc-c","separate_evidence":["directory_metadata","SYSVOL_content","client_outcome"],"authoritative_recovery":"requires_separate_approved_runbook","live_action":"none"}

The record specifies a directional question only. It designates no authoritative controller and performs no replication or recovery operation.

Verify the fix

Run the local classifier and confirm both lists. Change one synthetic state to supported and verify only that category disappears. Do not interpret that edit as repairing a controller or validating the evidence behind the label.

An approved real repair must verify the relevant directory partition, SYSVOL files/readability, expected shares, and client outcome across representative affected contexts. Preserve known-good content and recovery limits. A successful administrative exit code or one matching file is not enough to declare a forest recovered.

Keep it from recurring

  • Monitor directory and file replication separately, document site/partition expectations, maintain tested supported recovery evidence, and keep authoritative actions behind a dedicated approval and runbook boundary.

Official references