DSC offers a pull-based approach that is controlled by agents on target nodes, but there is a central server providing configuration files. This is a marked difference from the push models offered by other CM products.

The following diagram shows the Pull Deployment model. The diagram shows the steps in a Pull Deployment and also shows how the status is reported for the compliance server. Refer to the following diagram; we will cover pull servers later on in this chapter:

DSC operates in a pull scenario when configurations are stored on a DSC pull server and pulled by LCM on each target node. The pull server is the harder of the two DSC methods to set up, but the easiest to maintain in large node quantities and in the long term.

Pull management works great in server environments that have a lot of transient machines, such as cloud or data center environments. These kinds of servers are created and destroyed frequently, and DSC will apply on a triggered basis. Pull servers are also more scalable, as they can work against thousands of hosts in parallel. This seems counterintuitive, as with most pull servers, we have a central point of drift detection, scheduling, and so on. This isn't the case with a DSC pull server; however, it does not detect drift, compile MOFs, or other high-cost actions. Compilation and the like happen on the author workstation or Converged Infrastructure (CI), and the drift detection and scheduling happen on the agent, so the load is distributed across agents and not on the pull server. We will cover more benefits of pull servers at the end of this chapter and at the end of this book in Chapter 6, Pulling DSC Configurations.