Desired State Configuration and Hyper-V – Part 3: Generating MOF files

Hello all, and welcome back to part 3 of our series on Microsoft’s new technology: PowerShell Desired State Configuration!

Part one in this series introduced the concept of Desired State Configuration (or DSC for short) and why you should be using it inside your environment. Part two covered the concept of DSC resources. These resources determine what aspects of the target system DSC is able to modify and control.

Part 1 – DSC Intro and Requirements | Part 2 – DSC Resources

High Level Overview

In today’s post we’re going to take those resources and we’re going to use them to generate a MOF file that we can use to push the DSC config to our target nodes. Before I start explaining the concept of generating MOF files, I think it’s important to view the entire DSC process at a high level…..

As you can see in the above image, it really boils down to a five step process. The first two sections were covered in parts 1 and 2 of this series respectively, so I won’t bother you with those details again. This particular post will focus on the 3rd and 4th section of this process. The first thing we’re going to do is generate a basic configuration file. We’ll then execute that file and the DSC logic built into PowerShell will spit out a MOF file that we can use to target specific changes or configurations on our target nodes.

Let’s get started with the configuration Script and you’ll see how this comes together.

Configuration Script Generation

As I stated in a previous post, people who have some pre-working knowledge of Windows PowerShell can leverage that knowledge to make the following configuration files as complex or as simple as they would like to complete the specific tasks at hand, but as the possibilities are essentially endless, it becomes nearly impossible to cover every possible outcome. This series really serves as an introduction to DSC in that it shows you enough to get started making your own MOF files. With that said, I’ll be demoing a very basic configuration that should be easy to follow, even for the folks with little PowerShell experience.

If you are interested in deeper resources on this subject, the team over at PowerShell.org has a great forum on this subject, and it can be referenced for more advanced configurations as needed.

Now that we have that out of the way, let’s look at a basic DSC configuration that will insure that the Hyper-V and Failover Clustering roles/features are installed on a target node. You are reading this on a Hyper-V blog after all!

So in order to generate the MOF file necessary to enforce those needs, we need to create a configuration file using PowerShell. As you’ll see in the below script I’ve generated, we really have a couple of key sections that are needed in order for the MOF file to generate properly.

Configuration HVHostRoles
{
        Node ANDO-HV01.andonet.lcl
        {
            WindowsFeature HyperVRole
                {
                     Name = "Hyper-V"
                     Ensure = "Present"
                     LogPath = "C:\DSCLog_HyperV.txt"
                }
            WindowsFeature FailoverClusterRole
                {
                    Name = "Failover-Clustering"
                    Ensure = "Present"
                    LogPath = "C:\DSCLog_FailoverClustering.txt"
                }
        }
}
HVHostRoles

The very top section is the “Configuration” section. This is the general container for everything contained within the config. In addition, the string HVHostRoles, is completely changeable. It’s just a name for you’re configuration. In this case “HVHostRoles”.

The next section of note you’ll see is the “Node” Section. You’ll see that in this particular example, I’m targeting the “ANDO-HV01.andonet.lcl” host specifically. You can work some PowerShell magic here if you’d like and put in some parameterization of the hostname so you can define multiple nodes in the script, but for the sake of simplicity in this example, I’ve decided to target a specific machine.

Finally you’ll see the section mentioning “WindowsFeature”. This is the section that defines what the configuration is going to be modifying. This is where the DSC Resources from part 2 of this series come in. In this example I’ve called out the WindowsFeature DSC Resource specifically as I want to ensure that the Hyper-V role and the Failover-Clustering features are installed and present on these machines at all times. Much like the configuration section listed above, you can see some modifiable strings for naming purposes in this area of the script. In this case I’ve labeled each section with the Windows role/feature that it’s working with.

Contained within this section, you’ll need to define the proper syntax for each DSC Resource in use. The syntax for each configuration item can be pulled by utilizing the Get-DscResource cmdlet in PowerShell as mentioned in part 2.

In this case the syntax for the WindowsFeature DSC Resource can be determined by issuing the below command.

As you can see I’ve pulled the pieces that I needed out of the syntax. I’ve told DSC that I want it to look at the “Hyper-V” role and the “Failover-Clustering” feature. I then told it that it needs to Ensure that those items are “Present”.

Really those are the only two options that are needed, but I took an extra step in defining a log path as well. This log path is not going to be used by the role/feature installer for logging purposes, but it will be used by DSC itself at the time of use. This allows us to troubleshoot any DSC related issues that may arise in the future.

Should you want to utilize any other DSC Resource in your own custom scripts, you only need to replace the “WindowsFeature” sections with the applicable DSC Resource and the appropriate syntax.

Finally the last line of the configuration is exactly the same string of text as we used for the configuration name on the very first line. What this last line is doing, is executing the configuration defined above, which in turn, will generate a MOF file and place it in a subfolder in whatever directory the configuration script was executed from.

Finishing Up

Once your script is complete, save it, and execute it using PowerShell.

Congrats! You’ve just generated your first MOF file!

At this point, we have a MOF file that we can apply to a target node that will enforce the configuration we’ve defined. Upcoming part 4 will discuss how we deploy this MOF file to the target node.

Stay tuned for more and as always, thanks for reading!