For those of you who read my blog, you’ll know that I am a big fan of the Desired State Configuration feature Microsoft introduced in PowerShell v4. For more information, you can see my early walkthrough of DSC and a comparison of Group Policy vs. DSC. And while I think DSC adoption is still pretty “early-days”, I do think this technology presents a lot of important capabilities for the future of configuration management from Microsoft. In fact, I’ll be presenting a session on DSC at the upcoming IT/Connections conference in Las Vegas next month, so if you plan to attend, definitely consider my session.
That said, one area that I’ve considered quite a bit, is how DSC can help in a Group Policy world today. Certainly DSC’s sweet spot is in configuration management of Windows Server in Continuous Integration/Continuous Deployment (CI/CD) environments, where DevOps folks have the need to quickly and frequently roll out new versions of software to Windows Server in rapid fashion. And to be sure, as I’ve mentioned in my blog postings, DSC contains configuration capabilities not found in Group Policy and vice-versa. So, the question comes up, “how might I leverage DSC’s capabilities within Group Policy?”. Well, natively there is no happy union there between the two technologies. GP doesn’t natively support consuming and deploying DSC configuration documents. However, Group Policy has some flexibility to it that makes it amenable to leveraging DSC for certain scenarios. What I am presenting here might be considered fitting a square peg into a round hole, because DSC really stands alone from GP today. However, if one needed a quick and dirty way to take advantage of some of the configuration capabilities in DSC, but wanted to leverage the Group Policy delivery and reporting infrastructure they already have, then theapproach I’m going to present meets those goals.
The Scenario
The scenario I’m going to test with is the following. I’m going to create a DSC configuration document that installs a Windows Feature and then sets a registry value. Neither of these tasks are impossible to do with Group Policy today. You could use a startup script to run the Add-WindowsFeature cmdlet against your Windows servers and of course, GP does registry values in its sleep. The point here is that you can leverage the DSC declarative language, delivery mechanisms and reporting to provide additional features to Group Policy that you can’t easily get out of the box. And, given that DSC is infinitely extensible by creating custom resources, it means that this method provides a way to add to GP’s configuration capabilities easily by leveraging DSC.
The following is the configuration document we’re going to use for this scenario:
[codebox lang=”ps”]
Configuration GPDemo
{
Node ‘localhost’
{
WindowsFeature RSAT-AD
{
Ensure = ‘Present’
Name = ‘RSAT-AD-PowerShell’
}
Registry RegVal
{
Ensure = ‘Present’
Key = “HKEY_LOCAL_MACHINE\SOFTWARE\MYCOMPANY”
ValueName = “ADPosh”
ValueData = “Installed”
}
}
}
GPDemo
[/codebox]
Note that the node statement in this document refers to ‘localhost’. This is important, because once we execute this configuration document, it’s going to create a MOF file that references localhost, and will allow any node that runs this configuration to apply it to itself. So when I run this script, a file called localhost.mof is created. This is the file that needs to be accessible to my computer processing GP. I could copy this file to all the servers where I want to use it, or I could put it on a UNC share, accessible to my computers. In either case, once the file is accessible, the next step is to create a one-line PowerShell Startup Script in my target GPO that looks like this:
[codebox lang=”ps”]
Start-DscConfiguration -Path c:\windows\temp\gpdemo
[/codebox]
And then reference that script in the GPO, as follows:
Adding a DSC script to a GPO
Once the system restarts, the GP-based startup script is executed, the DSC configuration is performed and the server has a new Windows Feature and a registry value!
Now of course, there are other ways you could execute this PowerShell Start-DSCConfiguration command. You could create a Scheduled Task in GP Preferences to run it. You could even use a logon script, assuming what you are doing in the DSC document is capable of successfully running as the logged on user. This, in fact, is an example of how you could use DSC to deliver per-user configurations, even though its not really optimized for that.
And of course, once the DSC configuration is deployed, you can use all the normal DSC tools to check on the configuration’s status on the target nodes, including the Test-DSCConfiguration and Get-DSCConfiguration cmdlets.
The Caveats
So, there are of course, a couple of caveats with this approach. The first is that, this mechanism doesn’t do anything to change the default behavior in DSC. Namely, you can still only have one configuration document apply to a given system at a time. That means that if you were to deploy multiple configuration documents to a given server or workstation using multiple GPO startup scripts, it’s only the last one that will be considered THE configuration, for the purposes of reporting. In addition, deploying DSC configurations this way could be considered sort of redundant to the whole purpose of DSC, since natively DSC already has Pull and Push mechanisms that can be used to deploy these configurations. That said, if you don’t want to stand up a full deployment of DSC, but are looking to leverage some of it’s configuration management features in GP, this approach is workable and can provide a quick and dirty way to get some pretty easy access to the wide range of DSC’s configuration capabilities.
Darren