Desired State Configuration and Hyper-V Part 4: Pushing Configurations

We’re back this week, continuing our series on Microsoft Desired State Configuration and Hyper-V!

After a long hiatus, today we’ll be covering how to push our DSC configs to a specified node (or nodes).

Thus far we’ve covered several pieces of the DSC process. We reviewed in part 1, what the benefits and requirements of DSC are and how they apply to system admins. We then covered the concept of DSC resources in part 2 and the fact that DSC resources can help us extend DSC’s capabilities to new products and services. Finally in part 3 we looked at the procedure for generating a MOF file, which is a unified file standard for DSC across several industry platforms and services. DSC works on Microsoft OSs, Linux OSs, and more, making it a robust and flexible solution for system administration.

As stated earlier, we’re going to be covering MOF deployment in this post. While MOF deployment can be done via two methods (push or pull), this post will focus primarily on the push method.

One question or comment that is commonly heard is: “Why would I do a push operation over pull?” This question is quite valid. Especially when the key advantage of using a pull method is the fact that it adds additional automation to the process, plus the pull server will act as a central repository for your DSC needs, which creates more value-add.

While significantly simpler and not as feature rich, there are still some key use cases for conducting a push deployment of a DSC configuration. Push deployments are useful in a scenario where you may be deploying a one-time configuration. Or, maybe you’re testing a deployment prior to configuring a DSC pull server deployment for a more far-reaching deployment.

Whatever the case, DSC push deployments are useful in the right situation, and are the least complicated of the two deployment options. Thus, we’ll be covering the push method prior to moving on to the pull method of deployment later in this series in part 5.

Requirements for Pushing Configurations

Before we can push our DSC configurations we need to have our house in order first.

The first major hurdle to overcome is the availability of DSC resources. While some systems will have the default DSC resources available, if you’re using any of the experimental or custom DSC resources that were mentioned in part 2, you’ll have to take steps to insure that those same resources are available on the target systems should your MOF file be referencing those resources.

This could be completed with some simple scripting and file copies. Please see part 2 of this series if you need a refresher on the proper location to copy said DSC resources too.

Another item that is needed prior to being able to push configurations is PowerShell Remoting. PS-Remoting is required as PowerShell is the mechanism that is getting the configuration to the target node. Without the ability to execute PS scripts on a remote system, we will be unable to push a DSC config to that remote system.

A great resource for PowerShell Remoting configuration can be found HERE.

“Pushing” your MOF file

Once the above mentioned requirements have been fulfilled, it’s now a simple matter of running a single command that references the folder we created in part 3.

[PS] Start-DSCConfiguration –Path <path to folder containing MOF file>

DSC will process the MOF file and use Powershell remoting to target any node mentioned by a MOF file in that folder. You may have one MOF file, you may have several. It all depends on how you scoped the configuration that was used to generate the MOF files (More on this in part 3). This is part of DSCs strength, in that it has the flexibility to target one or many nodes for a particular operation.

One other thing to note about using the Start-DSCConfiguration cmdlet shown above is if you require additional output from the CLI for troubleshooting purposes, it can be useful to issue the –Verbose flag, which will list each step of the process as it’s happening amongst the various target nodes.

Wrap-Up

That’s all there is to pushing configurations. Once your house is in order, and you have all the proper pieces in place, it’s really just a matter of issuing a single command, which going forward will be a great method for deploying those one-off configs, and for testing configs prior to further deployment with a pull server.

Stayed tuned for part 5, where we’ll be covering the setup and use of the mentioned DSC pull server for further MOF deployment options.

Also, coming up in part 6, we’ll cover what the differences are between DSC and Group Policy in Windows Server. This is a very common question as the two technologies do a lot of the same things, and are similar from a sys-admin perspective.

Until next time, thanks for reading!