In today’s PowerShell Powerbit, we are going to look at the Desired State Configuration (DSC) foundational technologies in more detail. When learning anything new, like PowerShell or DSC, defining and understanding the foundational technologies and acronyms are essential.
If you are still fuzzy on what DSC is still all about, I have found in one of the modules “Just Enough Administration” (JEA) a nice paragraph that explains DSC.
Windows PowerShell Desired State Configuration (DSC) provides a method of using script files to apply, monitor, and/or maintain a configuration in declarative language. DSC scripts packaged as Windows PowerShell modules ready to be consumed are named DSC resources. A DSC resource consists of idempotent functions, meaning the script defines a configuration in such a way that it can be run multiple times on the same machine without error or undesired outcome.
For me the above paragraph is at the heart of the DSC; “idempotent functions”, “defines a configuration”, “run multiple times” and most of all, “without error or undesired outcome”.
It is also at the core of configuration management, DevOps, sustainable quality standards and Lean practices.
As the customer features cycles increase, integration and infrastructure demands increase as well.
Having quick access to on-the-fly testing environments like Azure and keeping the “known system baseline” of core setting and applications is critical for teams that want to become or stay Agile.
The bottleneck that I do see very often is the speed in which the teams (development thru operations, yes everyone) can create a “known system baselines” for a set of systems. A build machine is a prime example.
OK enough on this rant; let us get to the goodies that will address the problems.
What I will be covering in this post:
The foundation of DSC terms and core technologies. I will be providing a brief explanation on the foundational technologies CIM, WinRM and MOF that DSC uses.
What I will not be covered in this post:
Since each of the core technologies are their own vast topic. It would be impossible to cover anyone of them in detail.
Goal of the post:
The direction of this post is to gain a better understanding of the different acronyms and the core technologies that DSC uses.
The info:
Let us take a step back and first explain what Just Enough Administration (JEA) is, and since I referenced it at the start, it does deserve a quick mention.
• Just Enough Administration (JEA) is delivered using built in capabilities in the Windows PowerShell scripting language. The functionality is delivered as a PowerShell Desired State Configuration resource so no new binaries are required to be installed. Although this solution is implemented in Windows, through the use of standards based management the technology can be applied to non-Windows systems as well.
• JEA is currently delivered as a Desired State Configuration Resource Kit module (xJEA) and required the Windows Management Framework (WMF) V5 Preview which only runs on the latest version of Windows client and server. This version will evolve rapidly based upon community feedback and no backward compatibility is guaranteed. The toolkit will be made available on previous versions of Windows concurrent with the availability of WMF V5 on those platforms.
• JEA consists of Windows PowerShell Desired State Configuration resources and configuration scripts that together provide a simplified method of constructing and managing constrained endpoints adhering to prescribed boundaries.
• Windows PowerShell Constrained Endpoints offer rich functionality that could be considered complex to configure and implement, especially at scale. JEA simplifies constrained endpoints to make the concept easier to implement and manage using the concept of toolkits. In order to better understand how JEA works, first understand the core constructs that Windows PowerShell leverages to create the JEA environment.
More information on JEA is in the resource section at the bottom of the post.
Jumping back to DSC and the foundational technologies, the question I hear when explaining DSC foundational technologies is, why are the foundational technologies important to DSC?
Below is a sentence that I found from the “Windows PowerShell Desired State Configuration Revealed” book that explains:
• DSC feature is built on the Common Information Model (CIM) standard developed by the Desktop Management Task Force (DMTF) and used by Windows Remote Management (WinRM) technologies as a communication mechanism.
Since the CIM is at the heart of the DSC, it’s a great place to start understanding DSC foundational technologies. Here is a brief explanation of CIM:
CIM standard is a part of Web-Based Enterprise Management (WBEM) technologies for system management. Here a sentence from the Microsoft Developer Network site on CIM:
“The Common Information Model (CIM) is an extensible, object-oriented data model that contains information about different parts of an enterprise. Through WMI, a developer can use the CIM to create classes that represent hard disk drives, applications, network routers, or even user-defined technologies, such as a networked air conditioner.”
The WinRM is equally important to understand since most of the action will be calling a remote server or sessions. This is where I see most of the errors and problems. Make sure that the communication between the host and target sever is established at the beginning so it reduces the time of troubleshooting any issues.
WinRM – WinRM is a web service for management (WS-Management) protocol specification and describes a protocol based on the Simple Object Access protocol (SOAP) for exchanging control information and data between capable devices.
In most cases the WinRm is enabled by a service called wimrm, except for the AD domains joined Windows 2012 and 2012R2 systems. This is disabled by default. We can check the status by running the following:
Get-Service –ComputerName Localhost –Name WinRM ### this command is very handy!
For more on remoting, here is a great article that dives into this topic in more detail: http://www.powershellmagazine.com/2014/04/01/desired-state-configuration-and-the-remoting-myth/
Next is the Managed Object Format. Why this MOF important? DSC heavily leverages the MOF format to define configuration.
MOF – Managed Object Format (MOF) is the language that the CIM standard used to define managed elements. It is not the Microsoft Operations Framework. To see a .mof file run the following:
([wmiclass] “Win32_CurrentTime”).GetText(“mof”)
As you dive deeper into DSC, you will see how the .MOF files work. At this point just understanding that it’s part of the three foundational technologies is enough. As you start working with DSC, the .MOF files will make more sense as to why there are there and how they work.
Conclusion:
The CIM, WinRM and the MOF are the three foundational corner stones for DSC and for PowerShell in general. Having a brief knowledge of foundational technologies will assist in understanding and working with PowerShell and DSC to create a “known system baseline” that can be accessed and managed by the DevOPs team.
Resources:
Just Enough Administration, Step by Step
Desired State Configuration in Windows Server 2012 R2 PowerShell
Next up:
How does DSC fit into the agile practice and why every company needs to have DSC in their Configuration Management and Release Management practices.
Originally published at Northwest Cadence by ALM Consultant Bryon Root.
