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 about 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. It enables declarative, autonomous, and idempotent deployment, as well as configuration and conformance of standards...

First and foremost, you must understand how DSC gets the information needed to configure a target node from the place it's currently stored to the target node. This may sound counterintuitive; you may be thinking that 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 that they rely on agents to schedule, distribute, and rectify configurations on target nodes, but have a central server that holds configuration information and data. The server maintains the current state of all the target nodes...

In Chapter 1, Introduction to 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; that will be handled in Chapter 3, DSC Configuration Files. Instead, what we discuss here will be more explanatory and might jump 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 on other entities. This makes explaining some concepts a chicken and egg scenario, so we will try our best to reference other sections as they apply.

The following diagram shows the authoring, staging, and execution phases of the DSC workflow. You will notice that it does...

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 a 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 popup information can help you as you type things without you 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 this is a standalone file and contains no configuration data. Let's look at the following code snippet, which is a complete example of a DSC configuration file:

# First we declare the configuration
Configuration TestExample...