PowerShell / Advanced: remote boundaries, security, desired state, and reliability / Lesson 15

Distinguish DSC generations and desired-state contracts

Separate PowerShell language features, Windows DSC/LCM, modern DSC CLI/resources, test/get/set behavior, and application acceptance.

About 4 min readContent reviewed 2026-10-26

On this page

Lesson goals

Explain why DSC versions and resource ecosystems are not interchangeable.
Distinguish state testing from enforcement and health.
Review resources as executable dependencies without running them.

DSC is not one feature identical in every PowerShell edition

Windows PowerShell 5.1’s DSC environment, its Local Configuration Manager model, and newer DSC tooling have different runtime and resource contracts. Modern Microsoft DSC is a separate command-line application with declarative JSON/YAML documents and resource interfaces; installing PowerShell 7 does not automatically install or configure every DSC generation. Do not copy an old Configuration/MOF/LCM tutorial into a cross-platform 7 workflow without checking support. Identify the exact DSC tool, resource version, adapter, platform, and execution mode. This lesson uses official modern DSC documentation conceptually and runs no DSC command or resource.

Get, Test, and Set answer different questions

A resource can expose observed state, test whether desired state holds, and enforce state through supported operations. A successful Test is scoped to the resource’s properties and implementation, not every application invariant. A Set can have real host or external effects and requires authorization even when the document looks declarative. Idempotence depends on stable inputs, truthful detection, resource correctness, and the environment. A resource that always reports drift can repeatedly apply effects; a resource that hides drift can leave a system misconfigured. Keep state comparison, enforcement, and application readiness independently verifiable.

A resource is executable content, not passive schema

Review resource provenance, version, supported platform, input schema, privileges, and failure behavior. Resource discovery or Get/Test implementations can perform work and should not be assumed harmless merely because they sound observational. Dependencies and adapters can change where code runs and which runtime is required. A JSON document that parses does not prove its resource types exist or are supported. Keep a reproducible execution environment and a separately reviewed effect boundary. This course neither installs DSC resources nor queries a machine’s desired state; the document below is explicitly only a teaching contract, not a deployable DSC schema.

json Non-deployable desired-state teaching document

{"model":"synthetic-desired-state","resource":"Lab.Report","desired":{"enabled":true,"workers":2},"effect":"not-executed"}

This JSON is not presented as a valid DSC configuration schema. Its syntax is checked offline only; no dsc CLI, resource discovery, Get, Test, or Set operation runs.

Declarative state still needs rollout and recovery

A configuration change can affect dependent services, data compatibility, permissions, and recovery access. Plan preconditions, validation, activation order, stop conditions, and rollback compatibility before enforcement. A failed Set can leave partial effects, and reverting a desired-state document is not automatically data recovery. Coordinate with application-level checks and preserve evidence of what changed. Do not disable security or synchronization to make a resource report success. The same principles apply whether a resource is invoked directly or through another automation system: ownership and observed postconditions matter beyond a successful tool exit.

Model drift without claiming a DSC engine test

An offline dictionary comparison can illustrate observed versus desired properties and a stable second comparison. It is not a resource implementation or a proof of idempotent Set. Real tests must exercise the pinned resource on authorized disposable state, validate its exact detection and error behavior, and verify useful application outcomes. Include already-correct, drifted, malformed, unsupported-platform, and partial-failure cases. Keep the environment and output evidence explicit. The course checks only the following synthetic model and JSON syntax, with no PowerShell, DSC, host service, remote endpoint, or administrative execution.

python Check declared desired-state comparisons offline

desired = {'enabled': True, 'workers': 2}
observed = {'enabled': False, 'workers': 2}
print('synthetic_drift=' + str(observed != desired))
converged_fixture = desired.copy()
print('stable_fixture=' + str(converged_fixture == desired))
print('Set=not-executed')

Expected output

synthetic_drift=True
stable_fixture=True
Set=not-executed

The model compares Python dictionaries only. It performs no enforcement and cannot certify any DSC resource’s drift detection or convergence behavior.

Common errors and fixes

PowerShell 7 installation is called complete DSC setup

Why it happens: Tool and resource generations were conflated.
How to fix it: Identify and pin the actual DSC runtime and resources.
Prevent it next time: Keep a generation/platform compatibility matrix.

Valid JSON is called a valid installed resource

Why it happens: Data syntax was confused with executable capability.
How to fix it: Validate the actual schema, resource, and adapter separately.
Prevent it next time: Report parser evidence at its real boundary.

Test success is called complete application health

Why it happens: Resource properties were generalized to all invariants.
How to fix it: Verify application readiness and recovery independently.
Prevent it next time: Document Get/Test/Set postconditions precisely.

Check your understanding

1. Why does reverting a DSC document not necessarily undo a migration?

Show worked solution

Enforcement may have changed durable data or compatibility beyond the document’s current property values. Recovery needs an application-aware plan, known-good state, and verified postconditions rather than merely restoring old text.

2. What does the offline drift fixture prove?