Using PowerShell Desired State Configuration (DSC) to Manage Windows Registry

Recently I was working on a XenApp project where I noticed an issue with the server builds when trying to deliver App-V packages. The issue was that 8dot3 naming (a requirement for App-V package delivery) had been disabled. This setting is easily changed with a simple fsutil command or change to registry.

Enter Desired State Configuration

While there are numerous ways we can address configuration in our environment across multiple end points, DSC offers some compelling benefits:

• Reduced reliance on complex build scripts
• Transparent storage of configuration
• Easy to read and update
• DevOps friendly framework
• Prevents configuration drift
• Declares a required state rather than how to put something in a required state (traditional scripting)

The first step is to actually create the configuration. DSC has a very simple syntax which is quite similar to standard PowerShell function constructs. As mentioned 8dot3 naming restrictions can be influenced via registry which is one of the built-in Resources for DSC. You can get the out the box list by running:

Get-DscResource | select Name,Properties

This will list the standard resources available:

There is a DSC Resource Kit if you need more resources beyond this. However as I am only interested in registry we can get going without anything else!

First of all am going to use the mandatory Configuration term followed by a friendly name which describes my configuration:

Configuration XenApp

After this I can optionally specify any parameters I want to leverage in this configuration. In this case I am specifying a parameter that defaults to localhost:

   param([string[]]$ComputerName="localhost")

Next I use another key term Node to specify which machine(s) to deploy this configuration to. In this case I have configured it to use the aforementioned parameter:

    Node $ComputerName

Finally I then specify the resource name along with the desired configuration in accordance with the properties that are available to manipulate:

        Registry 8dot3
        {
        Ensure      = "Present"
        Key         = "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\"
        ValueType   = 'Dword'
        ValueName   = "NtfsDisable8dot3NameCreation"
        ValueData   = "0"
        }

As you can see from the above the configuration simply leverages stored properties and associates them to a desired state.

Ensure – Dictates whether a key/value exists. To ensure it does we can set this to Present or alternatively to ensure it is not set we can use Absent

Key, ValueType , ValueName and ValueData – Are all self explanatory and allow us to enforce as above.

There are also other properties you can use with the registry resource, check out a full list here.

So, to zoom out the configuration script looks like this:

Configuration XenApp
{
   param([string[]]$ComputerName="localhost")

    Node $ComputerName
    {
        Registry 8dot3
        {
        Ensure      = "Present"
        Key         = "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\"
        ValueType   = 'Dword'
        ValueName   = "NtfsDisable8dot3NameCreation"
        ValueData   = "0"
        }
     }
}

As mentioned earlier, notice how the configuration reads more like a set of rules to action rather than a traditional script which explicitly executes specific actions.

The next step is to take this configuration forward and actually apply it to an end point. To do this I need to call my configuration like I would a function, I can also use the parameter I declared to specify a machine to run against:

XenApp -ComputerName 'server01'

While some might assume this runs the configuration file against Server01 it infact does not. All it does is goes ahead and creates a .MOF file in your working directory ready for eventual deployment. These will be named by node name so if you have passed multiple machine names into the -ComputerName argument above then it will create a .MOF per value:

When looking closer at the .MOF file you will find a humanly readable description of the configuration:

Deployment

When you have your .MOF ready you now have two options to deploy the configurations; push or pull.

Push deployments are the most simple approach in that it requires no server setup, however it is a manual operation. Pull works by setting up a single server to hold configurations and configuring other servers to periodically apply (pull) them, this does require setting up a server, certificates etc. however the benefit of this approach is that it automated after that.

For the purpose of simplicity in this case I will just use the push approach, however you can read more about pull servers here.

To push your configuration you need to run the following command specifying the directory that your configurations reside within:

Start-DscConfiguration -Wait -verbose -Path "Path to folder containing .MOF configuration files"

This will process all the configuration files in the directory and give you an output similar to this:

From the above you can see how the check was made for the registry key and it was identified that it was not set to the value required. The value was then subsequently changed to be in accordance with the desired configuration. On the remote server this change happens instantly and without any notifications:

The great thing with this approach it that you can run this periodically to ensure overtime your various servers stay in accordance with your server standards. With a pull server, configuration ‘drift’ can be further addressed in automated fashion. So there you have it, a quick run down on how you can use Power Desired State Configuration to enforce and regulate registry values on server estate!