Skip to content

Resources and Configurations

Desired State Configuration (DSC) is built around two fundamental building blocks: resources and configurations. These two elements work together to define, apply, and maintain the desired state of a system. Understanding them is essential for using DSC effectively in real‑world automation.


1. What DSC Resources Are

A DSC resource is a PowerShell component that knows how to manage a specific part of a system.

Each resource defines:

  • What it can control (for example, a file, a service, a Windows feature)
  • How to check the current state
  • How to bring the system into compliance

Resources are the “vocabulary” of DSC. When you write a configuration, you use resources to describe the desired state.

Common built‑in DSC resources

Resource Purpose
File Ensures a file or directory exists with specific content or attributes
Service Ensures a Windows service is running, stopped, or disabled
WindowsFeature Installs or removes Windows Server roles and features
Registry Manages registry keys and values
Package Installs software packages

Each resource exposes a set of properties that define the desired state.

For example, the Service resource includes properties such as Name, State, and StartupType.


2. How Resources Work Internally

Every DSC resource implements three core methods:

  1. Get — retrieves the current state
  2. Test — determines whether the system matches the desired state
  3. Set — applies changes to enforce the desired state

This structure allows DSC to:

  • Detect configuration drift
  • Apply changes only when needed
  • Reapply configurations safely and idempotently

You never call these methods directly; the DSC engine calls them automatically.


3. What a DSC Configuration Is

A configuration is a PowerShell script block that uses DSC resources to declare the desired state of one or more nodes (machines).

It is declarative, meaning it describes what the system should look like, not how to configure it.

A configuration:

  • Defines target nodes
  • Uses resources to describe the desired state
  • Produces a MOF file (Managed Object Format) for each node
  • Is applied by the Local Configuration Manager (LCM)

4. Example: A Simple DSC Configuration

Below is a minimal configuration that installs the Web‑Server feature and ensures the W3SVC service is running.

Configuration WebServerConfig {

    Node "Server01" {

        WindowsFeature WebServer {
            Name   = "Web-Server"
            Ensure = "Present"
        }

        Service W3SVC {
            Name        = "W3SVC"
            State       = "Running"
            StartupType = "Automatic"
        }
    }
}

Explanation

  • Configuration defines a DSC configuration block.
  • Node specifies the target machine.
  • WindowsFeature is a resource that manages Windows Server features.
    • Ensure = "Present" declares that the feature must be installed.
  • Service is a resource that manages Windows services.
    • State = "Running" declares that the service must be running.

This configuration does not contain procedural commands.

It simply declares the desired state.


5. Compiling the Configuration

A configuration must be compiled into a MOF file before it can be applied.

WebServerConfig

This command generates:

.\WebServerConfig\Server01.mof

The MOF file is what the LCM reads and enforces.


6. Applying the Configuration

To apply the configuration to the target node:

Start-DscConfiguration -Path .\WebServerConfig -Wait -Verbose

Explanation

  • Path specifies the folder containing the MOF file.
  • Wait keeps the console open until the configuration is applied.
  • Verbose shows detailed output.

The LCM reads the MOF file and ensures the system matches the declared state.


7. How Resources and Configurations Work Together

The relationship between resources and configurations is straightforward:

  • Resources define what can be managed.
  • Configurations define how those resources should be configured.
  • The LCM enforces the configuration using the resource logic.

This separation of responsibilities makes DSC modular, extensible, and predictable.


8. Extending DSC with Custom Resources

If built‑in resources are not enough, you can create:

  • Script‑based resources
  • Class‑based resources
  • Composite resources

Custom resources allow organizations to standardize internal configuration logic and enforce consistent practices across environments.


9. Summary

Resources and configurations are the foundation of DSC:

  • Resources provide the building blocks for managing system components.
  • Configurations declare the desired state using those resources.
  • The LCM applies and maintains that state.

This model enables scalable, repeatable, and reliable configuration management across large environments.