Desired State Configuration (DSC) is a management platform within Windows Server, and is implemented with Windows PowerShell. DSC enables you to define a computer's desired state declaratively and have PowerShell ensure that the computer is configured accordingly, and that it remains so. This is simpler than writing complex scripts to configure a particular computer.

With DSC, you define a configuration that describes the details of how a given node (computer) is to be configured. The configuration defines a series of resources to be invoked on the node and how these resources should be configured.

A DSC resource is a PowerShell module that is instructed to configure a given object residing on a node. If you are planning on using a specific DSC resource, you need the related PowerShell module on the computer on which you author the DSC configurations and on the target node.

As an example, you could define a node and specify that the WindowsFeature resource should be configured to ensure that the Web-Server feature (a subset of the full installation of Internet Information Service (IIS)) is installed. You could also use the DSC File resource to ensure that a set of files—which are available from somewhere in your network or the internet—are present on the target node. This could dramatically simplify the process of configuring a web farm and ensure that it stays configured properly.

Resources come from a variety of sources. Microsoft has a few resources built in to PowerShell, and these ship inside Windows Server 2019. But you can also get additional DSC resources from the internet, or you can develop your own DSC resources. For more information on developing DSC resources, refer to https://docs.microsoft.com/en-us/powershell/dsc/resources/authoringResource.

The first step with DSC is defining a configuration statement. A configuration statement, which is not dissimilar to a function, defines the desired state of a node. It states how you wish certain resources on the target node to be configured.

The next step is to execute the configuration statement. This is a lot like functions in PowerShell. When you execute your function, you are compiling it and creating a managed object format (MOF) file as output.

You can parameterize configuration statements to make it simple to create different MOF files based on the parameter values. For example, a configuration statement could take a node name and the name of a Windows feature that should be present on the node. When you run the configuration, you specify values for the node name (for example, DC1), and the name of the Windows feature you want loaded (for example, Web-Server). The generated MOF file instructs DSC to ensure that the Web-Server feature is present on DC1.

When you run the configuration statement, PowerShell compiles the DSC configuration into a PowerShell function. When you invoke this generated function, PowerShell creates a MOF file based on the specified configuration. A MOF file tells PowerShell precisely how the resource is to be configured on a specific node.

Microsoft chose to use the MOF file in addition to the configuration statement to define the configuration. MOF is standardized and well supported, although it is more complex in terms of syntax and content. Separating the specification of the configuration from the details involved in deploying it can feel like additional overhead (create the PowerShell configuration statement, then create and deploy the MOF file).

Microsoft thought that someone could create a DSC-workbench-type product that enabled you to use a GUI and define the configuration graphically. Then, at the click of a button, this as-yet unbuilt tool would generate the necessary MOF file and deploy it automatically. Even though this GUI has never been built, the approach does allow you to define security boundaries between defining a configuration and deploying it.

Once you have generated the MOF files, you deploy the configuration. DSC uses the MOF file to ensure that the specified DSC resources are correctly configured on the target node. Subsequently, you can check that the node is correctly configured, with the service and files in place, and remedy any unapproved changes to the target node, referred to as configuration drift.

You can also use DSC to have a node pull configuration details from a centralized pull server. The pull server is a server that makes DSC configuration files (that is, the MOF files) and the resources available to target nodes. A target node is set up to regularly contact the pull server and pull configuration information (and any required resources) from the pull server. You can have two types of pull server—a web pull server or an SMB pull server. The latter is simpler to set up.

With a pull server, you configure the target node's local configuration manager (LCM) with a GUID and the location of the pull server. The LCM uses that GUID to locate the configuration information that you want to be applied to the node on the pull server. This enables you to configure multiple servers—for example a multinode web farm—identically by just giving them the same GUID.

A DSC partial configuration is a configuration statement that defines part of a node's overall configuration. This enables you to combine different configuration statements and have DSC add them together as it configures the node. In larger organizations, different teams can determine a part of a node's configuration independently. Partial configurations allow you to deploy the partial configurations from the different teams to the relevant nodes.

In this chapter, you first look at the built-in resources and the basics of DSC deployment. Then you learn how to get more resources, how to set up a pull server, and finally, how to implement partial configurations.