The push management model

DSC offers a push-based approach that is controlled by a user workstation initiating an execution on agents on target nodes, but there isn't a central server orchestrating things. Push management is very much an interactive process, where the user directly initiates and executes a specified configuration.

The following diagram shows the Push Deployment model:

This diagram shows the steps to perform a Push Deployment. The next section discusses the DSC workflow, where these steps will be covered, but for now, we see that a push deployment is comprised of three steps:

• Authoring a configuration file
• Compiling the file to an MOF file
• Executing the MOF on the target node

DSC operates in a push scenario when configurations are manually pushed to target nodes using the Start-DscConfiguration cmdlet. It can be executed interactively, where the configuration is executed and the status is reported back to the user as it is running. It can also be initiated in a fire and forget manner as a job on the target node, where the configuration will be executed without reporting the status back to the user directly, but is logged to the DSC event log instead.

Pushing configurations allows a great deal of flexibility. It's the primary way you will test your configurations. Run interactively with the Verbose and Wait parameter; the Start-DscConfiguration cmdlet shows you a log of every step taken by the LCM, the DSC resources it executes, and the entire DSC configuration run. A push-based approach also gives you an absolute time when the target node will have a configuration applied instead of waiting on a schedule. This is useful in server environments when servers are set up once and stay around for a long time.

This is the easiest to set up and the most flexible of the two DSC methods but is the hardest to maintain in large quantities and over the long term.