Active Directory / Advanced / Lesson 18

Systematic directory troubleshooting

Build a bounded evidence chain across discovery, authentication, permission, policy, and replication rather than applying broad administrative changes to an unexplained symptom.

About 5 min readContent reviewed 2026-10-26

On this page

Lesson goals

State scope, timeline, actor, target, and expected outcome.
Separate contradicted, supported, and unknown hypotheses.
Design a synthetic capstone and safe escalation record.

A useful incident starts with a precise failed contract

“Active Directory is down” is not a sufficient problem statement. Record what operation failed, for which user and computer, against which resource/controller, at what time, and compared with which expected behavior. Identify whether one site, one controller, one application, or many clients are affected. Preserve recent approved changes without assuming correlation proves causation. A successful website lookup, ticket, or policy editor view each covers only part of the path. The course investigates synthetic evidence only and performs no live directory, DNS, LDAP, Windows, PowerShell, credential, or replication operation.

Unknown is not the same as failed

The complete Python fixture contains supported discovery/authentication evidence, contradicted policy scope, and unknown file-delivery evidence. It reports the contradicted gate and the remaining unknown category. This is an evidence organizer, not a diagnostic expert system or proof that policy scope is the only root cause. Multiple failures can coexist and an observation can be inaccurate. The model avoids silently turning missing data into False or declaring a whole forest healthy from one passing stage. Keep every conclusion linked to an authorized source, observation time, and stated limitation before proposing any change.

python Offline three-state troubleshooting evidence model

evidence = {
    "discovery": "supported",
    "authentication": "supported",
    "policy_scope": "contradicted",
    "policy_file_delivery": "unknown",
}
print(sorted(name for name, state in evidence.items() if state == "contradicted"))
print(sorted(name for name, state in evidence.items() if state == "unknown"))

Expected output

['policy_scope']
['policy_file_delivery']

The model lists policy_scope as contradicted and policy_file_delivery as unknown. It neither diagnoses a live system nor authorizes a repair.

Test the smallest distinction that changes the next decision

For discovery, compare resolver and locator context; for authentication, identify the protocol stage, time, and service identity; for permission, examine the target action and entitlement. For policy, separate scope/filtering from AD/SYSVOL retrieval and client processing. For replication, name the direction and partition rather than forcing a global refresh. Use already-authorized sanitized evidence and official guidance to choose the next observation. Do not broaden a group, disable a protection, restart a service, or rejoin a device as an exploratory shortcut. A repair must follow an established cause, approved ownership, and a rollback/verification plan appropriate to its risk.

Integrate the course into one reviewable synthetic case

The capstone describes a learner who authenticates but misses a computer policy in one site after a placement change. The contextual record keeps identity, target, timeline, evidence gaps, and allowed next steps separate. It is not a support script or operational checklist. A complete written solution should compare old/new containment, computer versus user policy side, filters, selected controller, AD/SYSVOL state, and client outcome. Resource access should remain a separate question if it is not the reported failure. A plausible narrative is not enough: every asserted fact needs synthetic fixture evidence or a clearly labeled unknown.

json Non-runnable bounded incident record

{"incident":"synthetic-policy-case","actor":"learner-17","computer":"workstation-17","site":"East","reported_failure":"computer-policy-not-observed","recent_change":"placement-review","next_step":"review-authorized-scope-and-delivery-evidence","live_action":"none"}

The record organizes a case and explicitly requests evidence review only. It starts no investigation tool, network request, or administrative repair.

A repair is complete only when the intended outcome is verified

An approved operational owner should verify the original symptom, intended denied cases, service dependencies, and side effects after any real repair. A successful tool exit or one controller observation is insufficient. Record what changed, why, which evidence supports the cause, what was tested, and what remains unknown. Escalate recovery-sensitive conditions rather than improvising authoritative state or reconnecting stale controllers. Keep sensitive identity data minimized in handoffs. The final course artifacts validate local models only; no Windows engine, domain policy, authentication, trust, replication, backup, or restore behavior is claimed executed. This clear boundary lets learners practice reasoning without confusing classroom evidence with production authority.

Common errors and fixes

A missing observation is treated as a proven failure.

Why it happens: Unknown and contradicted states were collapsed.
How to fix it: Record evidence status explicitly and gather the next authorized distinction.
Prevent it next time: Require a source and time for every asserted fact.

A broad administrative repair is tried before the failure layer is known.

Why it happens: Action replaced hypothesis-driven diagnosis.
How to fix it: Identify the narrow failing contract and approved owner first.
Prevent it next time: Separate observation plans from change authorization.

One passing client closes a multi-site incident.

Why it happens: Validation scope was smaller than the reported impact.
How to fix it: Verify representative affected contexts and intended denials.
Prevent it next time: Write acceptance criteria matching the incident scope.

Check your understanding

1. Set policy_file_delivery to supported. What uncertainty changes and what conclusion still needs actual client evidence?

Show worked solution

The model’s unknown list becomes empty, while policy_scope remains contradicted. This still does not prove the client applied the setting or that changing scope is authorized. Review the exact eligibility cause, expected setting, client processing, and approved change/verification path. A complete set of labels can be based on incomplete or incorrect observations, so evidence quality remains a separate obligation.

2. The same learner has correct policy in West but not East. List the comparisons that make the next investigation bounded.