We are in a precarious position in writing about DSC. In order to explain any one concept, we tend to have to explain a couple more before we get to it. We are going to start out here with some terms and examples of configuration files, DSC settings, and workflow models, but for the most part, the words and actions used will not be clear at first. They are explained in the chapters ahead in greater detail. Remember the previous chapter? Don't panic! If you find yourself getting confused as to why something is important, it may become clear as we move from the explanation to putting it into practice. So for now, look at them and get a feel for the flow of operations and then come back to them as we touch each step in the operations process in later chapters.

DSC enables you to ensure that the components of your server environment have the correct state and configuration...

First and foremost, you must understand how DSC gets the information required to configure a target node from the place it's currently stored to the target node. This may sound counter-intuitive; you may be thinking we should be covering syntax or the different file formats in use first. Before we get to where we're going, we have to know how we are getting there.

The more established CM products available on the market have coalesced into two approaches: push and pull. Push and pull refer to the directions and methods used to move information from the place where it is stored to the target nodes. It also describes the direction commands being sent to or received by the target nodes.

Most CM products primarily use the pull method, which means they rely on agents to schedule, distribute, and rectify configurations on target nodes but have a central...

In Chapter 1, Introducing PowerShell DSC, we covered a high-level overview of DSC and introduced the three phases of DSC use. We also covered the MOF file and its importance in the grand scheme of DSC usage. Since we have already established the "why" of these concepts, we will now dive into the details of each phase.

What follows won't be a step-by-step process; this will be handled in Chapter 3, DSC Configuration Files. Instead, what we discuss here will be more explanatory and might make you move around a bit. Concepts that are introduced may not be fully explained until later, when supporting concepts are fleshed out. DSC is a very modular product, each module a separate entity that is also interdependent with other entities. This makes explaining some concepts a chicken and egg scenario, so we will try our best to reference other sections...

At this point, a simple example of the workflow you will use will be helpful to explain what we just covered. We will first create an example DSC configuration file. Then, we will compile it to an MOF file and show an example execution using the push deployment model.

A short note about composing configuration files: if you use the built-in PowerShell Integrated Script Environment (ISE), then you will have IntelliSense provided as you type. This is useful as you start learning; the pop-up information can help you as you type things without having to look back at the documentation. The PowerShell ISE also provides on-demand syntax checking and will look for errors as you type.

The following text would be saved as a TestExample.ps1 file. You will notice that this is a standalone file and contains no configuration data. Let's look at the following code snippet...

Now that we have covered how deployments work (push and pull) in DSC and covered the workflow (authoring, staging, and execution) for using DSC, we will pause here for a moment to discuss the differences between configuration files and configuration data.

It is important to understand the concept of the separation of the what from the where that we covered in Chapter 1, Introducing PowerShell DSC, when considering how to deploy servers, applications, and environments using DSC.

The DSC configuration blocks contain the entirety of the expected state of the target node. The DSL syntax used to describe the state is expressed in one configuration file in almost a grocery list format. It expresses all configuration points of the target system and is able to express dependencies between configuration points.

DSC configuration data is separated from DSC configuration...

Now that we have covered how deployments work (push and pull) in DSC and the workflow (authoring, staging, and execution) for DSC, we will talk about how the execution happens on a target node.

The Local Configuration Manager (LCM) is the PowerShell DSC engine. It is the heart and soul of DSC. It runs on all target nodes and controls the execution of DSC configurations and DSC resources whether you are using a push or pull deployment model. It is a Windows service that is part of the WMI service host, so there is no direct service named LCM for you to look at.

The LCM has a large range of settings that control everything from the scheduling of executions to how the LCM handles configuration drift. LCM settings are configurable by DSC itself although using a slightly different syntax. This allows the LCM settings to be deployed just like DSC configurations...

The DSC pull server is your one-stop central solution for managing a large environment using DSC. In the beginning of this chapter, we talked about the two deployment modes of DSC: push and pull. A DSC pull server operates with target nodes configured to be in the pull deployment mode. We covered the DSC pull server superficially in Chapter 1, Introducing PowerShell DSC, and we will cover it again in Chapter 6, Pulling DSC Configurations, concerning specific deployment topics. In this section, we will describe it in depth from an architectural standpoint.

A DSC pull server is an IIS website that exposes an OData endpoint that responds to requests from the LCM configured on each...

By this point, we have covered the architecture and the two different ways that we can deploy DSC in your environment. When choosing the deployment method, you should be aware of some additional considerations and observations that have come through experience using DSC in production.

You will generally use the DSC push mode deployments to test new configurations or perform one-off configurations of servers. While you can use the push mode against several servers at once, you lose the benefits of the pull server.

Setting up a DSC pull server is the best option for a large set of nodes or environments that frequently build and destroy servers. It does have a significant learning...

In this chapter, we identified the three phases of DSC use and two different deployment models. We then covered how the phases and models work together to comprise the architecture of DSC. And lastly, we covered how the LCM and pull server work separately and together.

In the next chapter, you will learn about the syntax of DSC configuration scripts and data files, how to debug and troubleshoot authoring them, and their general best practices.