IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Platforms PFE Dan Cuomo here to have a heart-to-heart about Desired State Configuration; a platform so valuable (how valuable is it, you ask?) if DSC had a utility belt, I’d label it a “borderline superhero.” Then again, if DSC is already part of your IT arsenal, perhaps you are the superhero.
Either way, DSC is an important skill to have – it allows you to declaratively define configurations, implement them in an idempotent manner, and remediate configuration drift. Did I mention that it’s extensible with PowerShell?!
Of course, if you’ve done any research on DSC you’ve no doubt heard a similar description a bajillion times; the “What” of DSC is certainly well documented but the “Why” is the most important part. So in this article, we’ll talk about what declarative, idempotent, remediable, and extensible means and why these characteristics are important.
As important as DSC is, we haven’t talked much about it on ASK PFE Plat. So in addition to the “why” we also included a training montage of favorite resources (training links, not DSC resources ;-). Next week we’ll have another post on some interesting ways to use configuration data, so stay tuned!
What’s all the hub·bub about?
Declarative Configurations: A declarative configuration takes the form of “this” equals “something.” This simplifies configuration and lessens the likelihood of errors. Take the following example
Name = ‘XPS-Viewer’
Ensure = ‘Present’
Very simply, the WindowsFeature resource is given two parameters – Name and Ensure. We are “declaring” that the Name and Ensure parameters passed into the underlying PowerShell are ‘XPS-Viewer’ and ‘Present’ respectively. The WindowsFeature resource uses these parameters to run powershell on the local system and in this case, ensure that the XPS-Viewer feature is installed (present) on the target system. By declaring what the configuration will be, you don’t have to worry about the PowerShell underpinnings, such as error handling. Instead you focus just on what you want it to be and the resources implement the desired state.
As an Aside…
By the by, you can easily find out which resources are available on the local system with Get-DSCResource
You can also find out the resources’ available parameters by using the Get-DSCResource -Name ResourceName –Syntax
In the example, the Name parameter is a “Key” parameter and must be entered. The Ensure parameter accepts only two string values ‘Absent’ or ‘Present’ and the IncludeAllSubFeature parameter requires a boolean ($true or $false).
Idempotent: The conceptual help on DSC states that “if you use DSC to enact the same configuration more than once, the resulting configuration state will always be the same.” This means that you can run the same configuration all day long and the result will be the same.
Consider a script that increments settings A through Z. The “desired state” for each setting should be a value of ‘1’ – Simple enough right? Thanks to those excellent PowerShell MVA videos you watched (here and here), you whip up a quick script and kick-off the foreach ($Setting in $AllSettings). You watch as the blue ocean waves of PowerShell scripting goodness rolls through each setting. #SipsCoffee #NeedARaise.
Crashing through your imaginary office window comes your extremely panicked boss. “Quick! Undo whatever you just did! Everything is down!!!” In a panic, you quickly stop the script and look to see how settings were applied. You go back through your script, setting by setting, to undo what you just did. In your triage of the situation you find that some of the settings had already been set to 1. Because you added one to each setting, some became a 2. 2’s mean trouble for your service…
Instead, DSC is idempotent and declares a state for the setting. For example, ‘XPS-Viewer’ is ‘Present’ or A = 1, B=1, C=1. There’s no chance of those values becoming 2’s no matter what the original value was and no matter how many times you run the configuration A through Z will always be the intended value.
Remediation: One of the most common problems in any environment is configuration drift. Once DSC configures a setting it has the power to keep it that way. If someone (co-worker) or something (system agent) changes a setting that shouldn’t be modified, DSC will put the configuration back into the “desired state.”
Some of you represent 100% of your company’s IT work force. You control every software installation, every group policy object, registry change, PowerShell script, share and NTFS permission. You’re the Enterprise Admin, Domain Admin, and Schema Admin in the environment. You’re not only the Microsoft Jedi, but a Cisco, EMC, Brocade, NetApp, HP, and Dell master as well.
In contrast, there are others who work in an enterprise behemoth. You’re one member of a team that controls your stove-piped solution. In your environment there are disparate organizations that “own” architectural, engineering, and operational efforts. You’re further divided into separate teams across virtualization, storage, networking, SQL, SharePoint, Exchange, SCCM, etc. In your environment you granularly assign permissions and user rights assignments. There are countless agents running on your system – many of them run with the “Great and Powerful Oz”-like System account.
In either scenario, you’re bound to experience unexpected configuration drift. Whether it’s your own fault, or another team that accidentally forced some changes without going through the appropriate approvals, Desired State Configuration can help alleviate the pain. DSC is not only a great configuration tool but can turn a RGE (Resume Generating Event) into a mere blip.
The more variables in your environment, the more self-remediation is needed and DSC is here to help.
Extensible: DSC resources are the “worker-bees” that implement changes on a system. One of the strengths of DSC is the ability to create new resources with a language as simple and powerful as PowerShell. There are in-box resources for Windows and resources for Linux available with Windows Management Framework 4 and 5 but if you need something outside of these built-in resources, you can easily whip up your own resource(s) using PowerShell. No need for an advanced computer science degree (but you should definitely sharpen up your PowerShell).
Now before you sit down and buildout your own custom resource **cracks knuckles** you should take a gander at the PowerShell Gallery which might have a resource already built by a community member. The easiest way to search the gallery for a module is by (wait for it…) using PowerShell. In the example below, I’m searching the PowerShell gallery for any resource that was tagged as part of the DSC Resource Kit which included a variety of modules for configuring different Microsoft applications such as Exchange, SharePoint, SQL, Hyper-V, and many more.
|Find-DSCResource -Tag DSCResourceKit|
The PowerShell gallery is a NuGet repository and as such you’ll get prompted to install the NuGet Provider. NuGet is a package manager for the Microsoft development platform.
This is just a few of the resources that are returned from the PowerShell Gallery
To install the modules and resources, you use the install-module cmdlet. In the following example, I pipe the list returned from the Find-DSCResource cmdlet containing the DSC Resource Kit modules to the Install-Module cmdlet. The -Force parameter bypasses the confirmation screen.
|Find-DSCResource -Tag DSCResourceKit | Install-Module -Force|
The modules start downloading and soon are stored on my local system and ready for use!
Of course if you don’t find a resource that suits your needs and decide to build a custom resource of your own, it’s likely someone else will come looking for it one day so please consider publishing your custom resource into the gallery.
I hope by now you see the value of Desired State Configuration (if you hadn’t already!). DSC is a declarative, idempotent, remediable, and extensible configuration management tool. It can make configurations easier to deploy, less error-prone, and automatically fix changes that drift from the defined baseline. It’s also a skill that is valuable whether on premises or in the cloud with Azure Automation.
So you’re ready for more? Game-on!
Here is a smorgasbord of training resources available. Most of the links below have a number of articles or resources contained within them.
Don’t forget, next week we’ll have another post on some interesting ways to use configuration data, so stay tuned! As always, we’d love to hear your feedback in the comments or by email.
|Official DSC Documentation||MSDN Documentation||Link|
|Windows Server 2012 R2 – Windows PowerShell DSC||TechNet Virtual Lab||Link|
|PowerShell Team||Team Blog||Link|
|Building Clouds Team||Team Blog||Link|
|Getting Started with PowerShell DSC||MVA – Video Series||Link|
|Advanced PowerShell DSC and Custom Resources||MVA – Video Series||Link|
|Building Your Datacenter One DSC Resource at a Time||MVA – Video Series||Link|
|Azure Automation DSC Documentation||Azure Documentation||Link|
|Windows Management Framework 5.0 Production Preview||Microsoft Download Center||Link|
|Premier Education as a Service (Workshop Library on Demand)
– Description of the Training
– How to sign up for Current Premier customers
– How to become Premier Customer
|Microsoft Premier Customers||
|Goatee PFE (Ashley McGlone)||TechNet Blog||Link|
|Package Management for PowerShell Modules with PowerShellGet||MSDN Blog Article||Link|
|NuGet Package Management||NuGet Homepage||Link|
|Open-source DSC Resource Kit||GitHub Resource Repository||Link|
|PowerShell Gallery||Resource Repository||Link|
|PowerShell language support for Visual Studio Code and more!||Tools Blog Article||Link|
|Validate features of PowerShell DSC||PowerShell Team Blog||Link|
See you next week!
Dan ‘Mater, you know like Auto-Mater’ Cuomo