Solving DSC Problems on Windows 10 & Writing PowerShell Code that writes PowerShell Code for you

I recently ran into a problem with DSC on Windows 10 when trying to create MOF files with DSC configurations that work on other operating systems. An error is generated when the friendly name for a DSC resource contains a dash and that friendly name is specified as a dependency for another resource. I know that only certain characters are allowed in the name that’s specified for DependsOn and I’ve run into similar problems with things such as IP addresses due to the dot or period, but the dash works in other operating systems at least with the production preview of PowerShell version 5, but not with the version of PowerShell version 5 that ships with Windows 10:


Test-DependsOn : The format of the resource reference ‘[WindowsFeature]Net-Framework-Core’ in the Requires list for
resource ‘[xSqlServerInstall]InstallSQLEngine’ is not valid. A required resource name should be in the format
‘[<typename>]<name>’, with no spaces.
At line:117 char:13
+ Test-DependsOn
+ ~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Write-Error], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : GetBadlyFormedRequiredResourceId,Test-DependsOn

Errors occurred while processing configuration ‘ConfigureSQLServer’.
+ throw $ErrorRecord
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (ConfigureSQLServer:String) [], InvalidOperationException
+ FullyQualifiedErrorId : FailToProcessConfiguration

Modifying the configuration to fix the problem for this example isn’t difficult since only one feature is specified:


This becomes a bigger problem when lots of Windows Features are added to the configuration. Maybe I’m building an additional SQL Server and I want to install all of the features that are currently installed on an existing SQL Server.

Note: This would only be a problem if they had dependencies set in the configuration, but maybe I want to be proactive and eliminate the dashes to prevent problems moving forward and not each time that I add a dependency.


That existing SQL Server currently has 14 roles that are enabled. That would require a lot of manual tweaking to remove all of the dashes as demonstrated in the previous example. What I can do though is to use PowerShell to generate the code for that portion of the configuration and paste it in instead of having to write it all manually:

Although this configuration is valid, it contains a lot of somewhat static code to maintain. There has to be a better way, but if you’re going to do it this way you might as well at least have PowerShell write some of the code for you.


Let’s try separating the environmental configuration from the structural configuration to see if that reduces the amount of what seems to be redundant code. The structural configuration is very concise:

For the environmental configuration, we’ll need to create a hash table for each of the Windows Features that we want to install. We’ll use PowerShell again to write all of those hash tables for us:

Then simply paste that portion of the code instead of having to manually type it all in manually:


That’s still an enormous amount of somewhat redundant code to have to maintain. There must be a better way than having so many lines of code for each feature so let’s try going another route. We’ll add a small amount of complexity to our configuration so the dash (-) can be stripped out on the fly using the replace operator. The replace method could also be used. I generally prefer to use the replace operator instead of the replace method since the replace method is case sensitive and the replace operator is not but it doesn’t matter in this scenario.

Let’s use PowerShell to generate a comma separated list of Windows Features based on the ones that are enabled on SQL04. I’ve seen people write an enormous amount of code to accomplish something like this which is simple to do:

I’ll use that comma separated list to create a new more simplistic environmental configuration:


You could also place code to generate the list of features directly inside the environmental configuration as long as you’re storing the hash table in a variable:


If you’re going to store the hash table for the environmental configuration in a PSD1 file, you can’t use PowerShell code such as what’s shown in the previous example. The hash table has to be static when it’s saved in a PSD1 file.


Create the MOF file using the configuration data stored in a PSD1 file:


Mark Twain once said “I didn’t have time to write a short letter, so I wrote a long one instead.” That’s similar to how writing DSC configurations work.

A quick and dirty DSC configuration is often long and complicated because making them short and simple requires a little more time and effort. That additional time and effort will pay off big time in the long run though by saving your sanity when you have to revisit or troubleshoot it in the future.



  1. Peter

    Hello Mike, Thank you for sharing this, i was having the problem with the dashes in the friendlynames and removing the dashes fixed it :). As a bonus i also optimized my code using your suggestions. Cheers!


Leave a Reply

%d bloggers like this: