Under the Hood of DSC

The LCM and MOF Files

In our previous posts, we’ve seen how PowerShell Desired State Configuration (DSC) lets you define a server’s state declaratively. You write a Configuration script that acts as a blueprint. But what happens next? How does that blueprint turn into a configured server?

The magic happens through two key components: the MOF file and the Local Configuration Manager (LCM). Let’s pull back the curtain and see how they work together.

The MOF File: The Compiled Plan

When you run a DSC Configuration block, you’re not actually configuring anything yet. You are executing a PowerShell function that compiles your declarative script into a standard, platform-agnostic format. The result is a Managed Object Format (.mof) file.

Think of it this way:

• Your Configuration script is the architectural blueprint.
• The .mof file is the detailed, step-by-step construction plan derived from that blueprint.

This MOF file contains all the information about the resources you defined, their properties, and their dependencies. It’s a static document that describes the “desired state” in a way that any machine with a configuration manager can understand.

When you run EnsureWebServer -OutputPath C:\DSC_Configs, you are telling PowerShell to compile the EnsureWebServer configuration and place the resulting WebServer01.mof file into the C:\DSC_Configs directory.

The Local Configuration Manager (LCM): The Engine

The Local Configuration Manager (LCM) is the engine of DSC. It’s a component built into Windows that lives on every target node you want to manage. Its job is to read the MOF file and “make it so.”

The LCM is responsible for:

1. Enacting Configurations: The LCM calls the appropriate DSC resources (e.g., the Service resource, the File resource) to put the system into the state defined in the MOF file.
2. Monitoring for Drift: The LCM doesn’t just run once. It periodically checks the system’s current state against the desired state in the MOF file. This is called the “consistency check.”
3. Correcting Drift: If the LCM finds that the system has “drifted” from the desired state (e.g., a service that should be running has stopped), it will automatically re-run the necessary resources to bring the system back into compliance.

LCM Modes: Push vs. Pull

The LCM can operate in two primary modes, which determine how it receives its configuration (the MOF file).

Push Mode

This is the mode we’ve been using. In Push mode, an administrator actively “pushes” a MOF file to a target node and manually triggers the LCM to apply it.

# You are in control, pushing the configuration to the node.
Start-DscConfiguration -Path C:\DSC_Configs -Wait -Verbose

Push mode is great for initial server builds, one-off configurations, or environments where you want direct control over when changes are applied.

Pull Mode

In Pull mode, the roles are reversed. You set up a central “DSC Pull Server” (which is just a specific kind of web server). You then configure the LCM on each target node to periodically check in with this Pull Server.

If the LCM finds a new or updated configuration assigned to it on the Pull Server, it will download the MOF file and any required DSC resources, and then apply the configuration.

Pull mode is incredibly powerful for managing a large fleet of servers. It allows you to manage your configurations from a central location and have your nodes automatically update themselves, ensuring consistency across your entire infrastructure.

Conclusion

Understanding these components clarifies the entire DSC workflow:

1. You write a Configuration script (the blueprint).
2. You compile it into a .mof file (the plan).
3. The LCM on the target node (the engine) reads the plan and does the work, continuously ensuring the system matches the desired state.

By separating the “what” (the Configuration) from the “how” (the LCM and its resources), DSC provides a robust and scalable framework for true infrastructure automation.