Active Directory / Advanced / Lesson 17
Controlled changes and functional-level planning
Make directory changes reviewable through scope, prerequisites, evidence, and rollback limits instead of treating administrative access as permission to experiment.
On this page
Lesson goals
- Distinguish object, policy, schema, topology, and functional-level changes.
- Require compatibility, health, recovery, and approval evidence.
- Define validation and rollback before implementation.
Name exactly what will change
A group membership edit, GPO link adjustment, OU move, controller replacement, schema extension, and functional-level change have different scope and recovery implications. Record the target, current state, proposed state, business reason, owner, expected effects, and exclusions. Possessing a privileged account does not establish organizational approval. Keep the change request separate from an incident hypothesis so a speculative repair does not become an undocumented deployment. This lesson creates only planning fixtures and local evidence-set checks. It performs no directory edits, schema changes, controller operations, policy application, or account management.
Check the evidence gate without pretending to execute the change
The complete Python fixture defines four required evidence categories for a synthetic high-impact change and reports the missing one. Set inclusion makes the review gate explicit but does not validate the documents behind each label. An approval record must be current, scoped, attributable, and applicable to the exact target. A backup label without a tested supported recovery path is not sufficient evidence. The model also cannot determine a production environment’s actual replication health or consumer compatibility. It is a planning completeness check, not an administrative automation tool or authority to proceed.
required = {"compatibility", "replication_health", "recovery_evidence", "approval"}
available = {"compatibility", "replication_health", "approval"}
missing = sorted(required - available)
print(missing)
print("ready_for_review" if not missing else "blocked_in_model")
['recovery_evidence']
blocked_in_model
The missing category is recovery_evidence and the model reports blocked_in_model. No change is approved or executed by this result.
Review each version and feature dimension separately
Controller OS, domain/forest functional levels, schema, optional features, client applications, and management tooling are separate compatibility dimensions. Current Microsoft guidance includes a Windows Server 2025 functional level, while 2019/2022 use the 2016 level as their newest named level. A compatible OS list does not prove every schema-dependent application is supported. Some changes have limited or feature-specific rollback options, so never promise a universal downgrade. Consult the exact applicable documentation and vendor support before approval. A level change is not a substitute for fixing DNS, replication, or an isolated authentication failure. Preserve healthy prerequisites before planning an upgrade.
Write measurable success and stopping conditions
The contextual record defines an owner, review stage, prerequisite evidence, positive/negative validation, and rollback limits. It is not a domain configuration or a script. A real plan should distinguish a reversible setting from a schema or data transformation that cannot be casually undone. Identify who can halt the change and how service owners will evaluate side effects. Scope pilots carefully and preserve sanitized before/after artifacts. Do not copy real secrets into a change ticket. A proposed “temporary” broad permission exception needs an expiry and accountable removal path, not merely a comment promising future cleanup.
{"change":"synthetic-directory-capability-review","owner":"identity-change-owner","stage":"planning","gates":["compatibility","replication_health","recovery_evidence","approval"],"validation":["intended_success","intended_denial","consumer_regression"],"rollback":"must_be_supported_for_exact_change"}
The record states review gates and tests, not a live implementation sequence. It changes no functional level, schema, policy, or permission.
Confirm the new state and its unintended effects
A successful administrative tool exit is not full validation. Verify the required directory state, convergence, policy delivery, authentication, resource denial, and dependent application behavior according to the approved change scope. Record actual outcomes and unresolved exceptions. Drift review should compare declared policy with authorized observed configuration without automatically overwriting the environment. When rollback is needed, distinguish code/configuration reversal from data restoration and the trustworthiness of the resulting state. This course tests only evidence-label arithmetic. Real implementation and recovery remain separate approved activities, and no offline planning result authorizes them.
Common errors and fixes
One successful command is reported as full change validation.
- Why it happens
- Tool completion was confused with service and security outcomes.
- How to fix it
- Verify the approved positive and negative acceptance criteria.
- Prevent it next time
- Write measurable outcomes before implementation.
A schema change is assigned a casual rollback promise.
- Why it happens
- Change-specific support limits were ignored.
- How to fix it
- Review the exact supported recovery and reversal options.
- Prevent it next time
- Require recovery evidence for high-impact changes.
A temporary privilege exception has no removal owner.
- Why it happens
- Approval and lifecycle were not part of the plan.
- How to fix it
- Assign scope, expiry, accountable owner, and verification.
- Prevent it next time
- Review exceptions as explicit tracked changes.
Check your understanding
1. Add recovery_evidence to the available set. Does ready_for_review mean the real change can now be executed?
Show worked solution
No. It means the model’s four labels are present. The evidence must still be genuine, current, applicable, and accepted by the authorized change process, and the exact implementation needs its own supported procedure. A set membership result cannot validate a backup, prove a replica healthy, or delegate administrative authority. Keep those facts outside the model’s claim.
2. An application fails after an OU move and a simultaneous GPO edit. Why does combining both changes weaken diagnosis and rollback?
Show worked solution
Two independent policy/placement effects changed at once, making causal attribution and safe reversal harder. Record both exact changes and compare intended scope, resulting policy evidence, delegation, and application dependencies. Prefer separately reviewable changes with clear acceptance criteria when practical. Do not automatically reverse both or reset accounts without identifying the failing contract.
Key takeaways
- Classify the exact change and its blast radius.
- Evidence labels are not evidence validation.
- Define success, denial, and rollback before implementation.