Learning Powershell DSC

Chapter 1. Introduction to PowerShell DSC

	"Begin at the beginning," the King said, very gravely, "and go on till you come to the end: then stop."
	--Lewis Carroll, Alice in Wonderland

	"Don't Panic."
	--Douglas Adams, The Hitchhiker's Guide to the Galaxy

Welcome to PowerShell Desired State Configuration (DSC), the new configuration management platform from Microsoft. We begin with a quote from Alice in Wonderland. Besides pertinent advice for the author, it is apropos of what DSC is at its very core. DSC, by the very simplest definition, allows you to write down the beginning, the middle, and the end of your deployment story. The second quote we see is from The Hitchhiker's Guide to the Galaxy, and is something to remember throughout reading this book. We will cover a lot of new concepts, some old concepts with new importance, and a lot of PowerShell. Don't panic; we'll get through fine.

This book will begin with the basics of PowerShell DSC, covering its architecture and many components. It will familiarize you with the set of Windows PowerShell language extensions and new Windows PowerShell commands that comprise DSC. Then, it will help you create DSC custom resources and work with DSC configurations with the help of practical examples. Finally, it will describe how to deploy a configuration data set using PowerShell DSC.

By the end of this book, you will be able to deploy a real-world application end to end.

In this chapter, we will cover:

What is PowerShell DSC?
Why do we need Configuration Management and what is DevOps?
How does DSC help me?
A high level overview of DSC
DSC requirements
DSC versions

What is PowerShell DSC?

Have some software that needs to be installed in a certain order? With special configuration steps? Some security policies that must be applied to every server? How about ensuring that a set of services are never enabled to start? Have you ever written scripts to handle this kind of work, but found them brittle because of changes in software from release to release? Needed to make these changes on dozens or hundreds of servers repeatedly on schedule? Ever had someone change something and have your script break because the state is not what you expected? These and many more scenarios are handled by DSC.

PowerShell DSC is a new management platform in Windows PowerShell that enables the deploying and managing of configuration data for systems and software services and the managing of the environment in which these services run. DSC allows you to define the current state of a machine and ensure that the machine is always in that state.

What we mean by state here is everything that is on that machine, including the operating system and software installed, all the configuration settings for the OS and software, and any file or process that needs to be present or set with specific content; the list goes on. Whether you considered this before or not, all this makes up the configuration of your system. DSC is designed to help you deal with all this configuration data and execute it consistently and repeatedly.

What is PowerShell?

While we assume in this book that the reader has a basic understanding of PowerShell command-line use and scripting, before we get too much into DSC, it is helpful to describe what PowerShell is compared to PowerShell DSC.

First released in 2006, PowerShell is a scripting language and command-line shell built on the .NET Framework. PowerShell provides full access to COM, WMI, and .NET, and also provides a large set of commands called Cmdlets to perform administrative tasks on both local and remote systems.

PowerShell can execute PowerShell scripts, PowerShell Cmdlets, and standalone executable programs or other language files. PowerShell also provides a hosting API that allows programs to run PowerShell natively inside their program, enabling scripting or automation scenarios. Being both a shell language and a scripting language allows it to be both quick and terse on the command line as well as verbose and consistent in scripts.

Over the years, PowerShell has become the de facto way to administer and automate Windows OS and software. As computing environments grow larger and engineering teams smaller, it is paramount in automating processes and procedures that used to be done by hand. PowerShell provides a consistent command-line language for automating the administration of a large number of scenarios, which is growing every day and was previously not available on Windows. Because of PowerShell's hosting API, applications such as Exchange have enabled a command-line first, GUI second mode of development, which enables quick deployment and management using automated tools.

PowerShell not only enables automation at the single system level, but also scales out to the multi-node environment. Being able to automate your system from the command line or script is fine, but if you have to manually run that on every system in your environment by hand, then we still have a bottleneck on efficiency. Using an industry standard protocol, PowerShell provides PowerShell Remoting as a way of running commands or scripts on any number of remote hosts in parallel. Thousands of computers can be managed at the same time, consistently, and in a repeatable and automated manner.

Consistent repeatable automation is important, but PowerShell is also extensible, which is not only essential, but leads us into DSC. PowerShell is both a typed and a dynamic scripting language, which means that it supports both static typed objects (System.IO.FileInfo) and objects with methods and properties that are defined at runtime (PSCustomObject and Add-Member). This enables PowerShell to be extended to suit the needs of the user. You do this every day to an extent, by creating functions and scripts to wrap common operations into reusable components or modules. Taking this a step further, PowerShell can be extended to support specific scenarios that were not envisioned when the product was made. DSC is such an extension, as it builds on the existing PowerShell language and infrastructure to enable new uses of the program.

On to PowerShell DSC

PowerShell DSC is released as a feature of PowerShell, so it comes bundled with specific versions of PowerShell that are part of the Windows Management Framework (WMF). The PowerShell DSC versions section goes into greater detail about the versions of PowerShell and PowerShell DSC and the available features in each, so we won't go into too much detail here.

The WMF release notes describe DSC in this way:

Windows PowerShell DSC helps ensure that the resources in your datacenter are correctly configured. DSC is a set of Windows PowerShell language extensions and providers that enable declarative, autonomous, and idempotent (repeatable) deployment, configuration, and conformity of datacenter resources. DSC enables an IT Pro, developer, or fabric administrator to define the configuration of target nodes (computers or devices) and prevent configuration inconsistencies or drift.

DSC provides a set of Windows PowerShell language extensions, new Windows PowerShell Cmdlets, and resources that you can use to declaratively specify how you want your operating system and software environment to be configured. It also provides a means to maintain and manage existing configurations. It supports both an interactive push model, where configurations are executed on target nodes on demand, and a pull model, where a central server manages and distributes configurations.

We won't delve into too much architecture talk here. (The next chapter discusses the architecture and inner workings of DSC in detail.) For now, it is sufficient to say DSC is comprised of both a data file and configuration file that are translated into a text file following the Managed Object Format (MOF). This file is then parsed and executed on the target server, using DSC features that know how to configure the system.

That was a lot of information in a short space, so don't worry if it is a lot to take in at once. We will go over each part as we move on. You don't have to know right away what MOF is or how DSC executes the configuration to use DSC. DSC abstracts all the details away for you. When you get to the point that you need to know these details, DSC still exposes them so you can tweak under the hood or find out what is really going on.

At a high level, DSC work isn't programming work; it's listing how you want a server to look in a special format. The execution of this list is abstracted from the listing, allowing the how to work separately from the why. This is an important concept, and really the key to understanding the importance of DSC. Jeffery Snover, the architect and inventor of PowerShell, explained it best using Star Trek. Captain Picard often used the line Make it so, and Commander Riker had to figure out how to actually make what the Captain wanted to happen, happen. Captain Picard knew what needed to be done, but didn't particularly care how it got done. Commander Riker knew how to get things done, but did not concern himself (most of the time) with deciding when and what to do. This separation allowed both officers to be good at their jobs without interfering with each other.

It may be useful to see the following short, complete example of an entire DSC configuration:

configuration BaseServerConfiguration
{    
    File ExampleTextFile
    {
        Ensure          = 'Present'
        Type            = 'File'
        DestinationPath = 'D:\FooProduct\foo.txt'
        Contents        = "this is an example text"
    }

    WindowsFeature DotNet
    {
        Ensure = 'Present'
        Name   = 'NET-Framework-45-Core'
    }
}

That's it! Sure, there is more to understand and cover, but as we can see here, this is plain PowerShell code that is as readable as any script you've written before, and all it does is list what should be on a system. What this DSC configuration does is ensure that a file is created in the D:\FooProduct folder called foo.txt, with the contents this is an example text. It then ensures that the .NET Framework v4.5 is installed. Yes, .NET 4.5 is most likely already there, but the point of DSC is to describe the state of the target node, regardless of what you think might be there. This way, if someone removes .NET 4.5, DSC will ensure that it is installed, thereby maintaining the known good state of the target node.

We will go into this further later, but now you may be asking why it is important to manage the configuration of your systems this way. Read on.

Why do we need Configuration Management?

Whether you manage a few servers or several thousand, the traditional methods of server and software installation and deployment are failing to address your current needs. These methods treat servers as special singular entities that have to be protected and taken care of, with special configurations that may or may not be documented, and if they go down, they take the business with it.

For a long while, this has worked out. But as the number of servers and applications grow, and the number of configuration points grows, it becomes untenable to keep it all in your head, or consistently documented by a set of people. New patches are released, feature sets changed, employee turnover, poorly documented software; all these reasons introduce variance and change into the system. If not accounted for and handled, these "special" servers become ticking time bombs that will explode the moment a detail is missed.

Written installation or configuration specifications that have to be performed by humans error-free time and time again on numerous servers are increasingly self-evident as brittle and error prone affairs. To further complicate things, despite the obvious interdependence of software development and other IT-related departments, software developers are often isolated from the realities faced by IT professionals during the deployment and maintenance of the software.

The answer to this is automation: defining a repeatable process that configures servers the right way, every time. Servers move from being special snowflakes to being disposable numbers on a list that can be created and destroyed without requiring someone to remember the specific incantation to make it work. Instead of a golden image that has to be kept up-to-date with all the complexities of image storage and distribution, there is instead a set of steps to bring all servers to compliance regardless of whether they are a fresh installation or a number of years old.

What is being described is Configuration Management (CM). CM ensures that the current design and build state of a system is a known good state. It ensures trust by not relying on the knowledge of one person or a team of people; it's an objective truth that can be verified at any time. It also provides a historical record of what was changed, which is useful not only for reporting purposes (like for management), but also for troubleshooting purposes (this file used to be there, now it's not…). CM detects variance between builds, so changes to the environment are both easily apparent and well known to all who work on the system. It allows anyone to see what the given state of the system is at any time, at any granularity, whether on one system or over the span of thousands. If a target system fails, it's a matter of re-running the CM build on a fresh installation to bring the system back to a steady state.

CM is part of a set of ideas called Infrastructure as code. It requires that every step in provisioning an environment is automated and written down in files that can be run any time to bring the environment to a known good state. While CM is infrastructure automation (replicating steps multiple times on any amount of target nodes), Infrastructure as code takes things one step further and codifies every step required to get an entire environment running. It encompasses the knowledge of server provisioning, server configuration, and server deployment into a format that is readable by sysadmins, developers, and other technology staff. Like CM, Infrastructure as code uses existing best practices from software development such as source control, automated code testing, and continuous integration to ensure a redundant and repeatable process.

The approaches being described are not that new and are part of a larger movement that has been slowly accepted among companies as the optimal way of managing servers and software, called DevOps.

What is DevOps?

The set of concepts we have been describing is collectively termed DevOps and is a part of a larger process called "continuous delivery". DevOps is a shortened form of development operations and describes a close working relationship between the development of software and the deployment and operation of that software. Continuous delivery is a set of practices that enable software to be developed and continuously deployed to production systems on a frequent basis, usually in an automatic fashion that happens multiple times a week or day.

Each year, a company called Puppet Labs surveys over 4,000 IT operations professionals and developers about their operations procedures. Of those surveyed companies that have implemented DevOps practices report improved software deployment quality and more frequent software releases. Their report states that these companies shipped code 30 times faster and completed those deployments 8,000 times faster than their peers. They had 50% fewer failures and restored service 12 times faster than their peers.

Results like the ones shown in the Puppet Labs survey show that organizations that adopt DevOps are up to five times more likely to be high-performing than those who have not. It's a cumulative effect; the longer you practice, the greater the results from adoption and the easier it is to continue doing so. How DevOps enables high performance centers around deployment frequency.

To define and explain the entirety of DevOps and continuous delivery is out of the scope of this book, but for the purposes of this book, the goals can be summarized as the following: to improve the deployment frequency, to lower the failure rate of new releases, and to shorten the recovery time if a new release is faulty. Even though the term implies strict developer and operations roles as the only ones involved, the concept really applies to any person or department involved in the development, deployment, and maintenance of the product and the servers it runs on.

These goals work toward one end: minimizing the risk of software deployment by making changes safe through automation. The root cause of poor quality is variation, whether that be in the system, software settings, or in the processes performing actions on the system or software. The solution to variation is repeatability. By figuring out how to perform an action repeatedly, you have removed the variation from the process and can continually make small changes to the process without causing unforeseen problems.

A high level overview of DSC

We will go into DSC architecture in much greater detail in the next chapter, but it is useful to show a quick overview of how all the concepts we just covered fit together. DSC has several steps that can be bucketed together into three large phases.

As we mentioned earlier, DSC can manage more platforms than just Windows, but for the purposes of this book, we will stick to Windows configurations. The DSC Resources for Linux and other platforms are in the early stages, so there will be significant changes as these implementations mature; it would be too hard to account for these changes in the space we have in this book.

The authoring phase

You begin with DSC by writing a configuration script in PowerShell. The script itself doesn't actually do anything. You can run the script interactively all you want; it won't change a thing. Since the configuration script is the DSL we were talking about earlier, it's only a list of things to do, not the things that actually execute the list. Because there can only be one MOF per target host, and each configuration script is translated to a MOF, this means there is usually only one configuration script you write, which handles all the variances in your environment. This sounds like it will get complicated and be difficult to manage quickly, but there are DSC patterns to follow to manage this. We will cover these in Chapter 3, DSC Configuration Files.

The next step is to translate the configuration script into a MOF file. The translation, or compiling, happens only once—when you deploy the MOF file to the target node or to the DSC Pull Server. The configuration script is often kept in a version control system and only compiles and deploys the MOF file when the configuration script changes.

The staging phase

The next step is to get it over to the target computer. The deployment of the MOF happens in two ways: push and pull. A push method is when you execute the Start-DSCConfiguration Cmdlet, which compiles the MOF and copies over to the target system. The pull method involves putting the MOF file on the DSC Pull Server, which handles distributing it to all the target hosts.

The execution phase

Whether an MOF file was pushed (using Start-DSCConfiguration) or pulled (using a DSC Pull Server), the next step is the actual execution of the MOF file. If pushed, the execution happens interactively or in a PowerShell job, depending on how you called the Cmdlet. If pulled, the Local Configuration Manager (LCM) schedules and executes the MOF file without user input or oversight.

LCM is part of the DSC system installed on the target node and is responsible for receiving, coordinating, and executing configurations on target nodes. LCM itself is configurable using DSC and is flexible enough to allow multiple types of deployments.

The phases described earlier will be covered in much more detail in the coming chapters, so do not worry if some of it does not make sense.

Why all the abstraction?

It seems like we are writing scripts just to have them turned into another format altogether, which in turn is converted into something else. Why all the indirection and abstraction? Why don't we write the final result ourselves, the first time? The primary reasons are readability and flexibility.

DSC configuration files are written in PowerShell syntax, which we already established as being consistent and readable. When the configuration is human-readable, it's understandable to the whole team and not just the implementer. It's written down in textual format, so it can be controlled in a source control system such as Git, Subversion (SVN), or Team Foundation Server. Deployment processes (sets of instructions on how to complete a task) are automatically saved and backed up by the source control system, and available to the whole team instead of one person's desktop.

Readability serves more than just the implementer and the team. Written configuration files codify the deployment process in a historical record. In that record, we can see the progression of the system by comparing the text files between releases, thereby monitoring drift and variation.

This increases flexibility by enabling a variety of tools to produce the output DSC can execute. You may have noticed that we keep referring to the compiling to MOF, that the DSC engine reads MOF, and that there is only one MOF per target host. There's a good reason that the end format is MOF and not something else like a PowerShell script.

The MOF was defined by the Distributed Management Task Force (DMTF), which is a vendor-neutral organization that works toward standardized interoperation between platforms. You may not be aware of it, but you have been using their work for quite some time if you have been using Windows Management Instrumentation (WMI). WMI is an implementation of Common Information Model (CIM), which is a DMTF standard that defines a structured way to describe a system and its properties. The Microsoft Developer Network (MSDN) site: https://msdn.microsoft.com/en-us/library/aa389234.aspx explains that WMI can use CIM on target nodes. The Wikipedia site: https://en.wikipedia.org/wiki/Common_Information_Model_(computing) goes into more information about the history and open standards of CIM.

The DMTF defined the MOF syntax and format so that any vendor or system can implement it. Microsoft happens to be the largest implementer so far, but other tooling companies use it as well. Since any vendor can implement the standard, it means several important things can happen.

If all DSC needs to function is the MOF file, you don't necessarily need PowerShell to produce the MOF file. Any third-party tool can implement the specification and provide their own (possibly improved) way of compiling MOF files. An open market for tooling gives options to the user. For example, there are many different text editors to write your scripts in; each has its benefits and compromises that you can evaluate and choose between. This enables third-party vendors to compete and provide solutions that suit a given user's needs. Companies such as Puppet and Chef can implement their own or extend what Microsoft has already done.

The most exciting thing is that since the MOF standard is platform independent, the configuration scripts you write can run on multiple operating systems. At the time of writing, Microsoft is currently completing work to support running PowerShell DSC on many Linux distributions, as announced here: https://blogs.msdn.com/b/powershell/archive/2015/05/06/powershell-dsc-for-linux-is-now-available.aspx. So, whether you run Windows or Linux or both, you can manage the configuration of your systems with PowerShell DSC using a single standard consistent syntax.

How does DSC help me?

PowerShell DSC enables a DevOps structure by providing a consistent, standardized configuration of operating systems and software as part of a continuous deployment pipeline. It increases the rate at which you can deploy by reducing the variation and drift from your existing configurations.

In simpler terms, DSC separates the who from the what and how. This separation of the what and how is the core of DSC. Because they are separated, you can continually change the data points of your systems without touching the parts that actually set the system to the desired state.

The who

Band name jokes aside, the who DSC refers to is any target node. Why the separation and distinction? Well, as explained in the MOF earlier, we aren't dealing with just Windows servers. We could possibly be dealing with network switches, Linux servers, storage devices, and so on; the list potentially includes any device in your environment. By setting target node definitions in a structured way, we can describe the nodes in ways that make sense to anyone reading the configurations and also to the computers processing the configurations.

The what

The DSC Domain Specific Language (DSL) defines a standardized way of describing the expected configuration of a target system, whether that is one system or several thousand systems. It describes the what of the target node.

A DSL is a specialized set of language extensions and grammar that makes it easier to codify a specific set of problems. Whereas a product like PowerShell is a general purpose language, DSLs are specifically built to address a specific set of problems.

You may wonder why we are bothering to define and discuss DSL here. You may think it's an advanced topic or something only developers need to know, but you would be wrong to discount it. DSLs are all around you and you use them every day. For example, HTML is a human readable DSL for web browsers to display content. The actual content is binary, but the HTML specification allows humans to write in a language they understand, yet also have the computer understand it.

In the case of DSC, the DSL is oriented at expressing all the different ways you can describe the expected state of a system in an easy-to-read manner. If you can read PowerShell code, then the DSC DSL is no different than reading a function declaration with a set of parameters. Most importantly, this easy-to-read structure for you is also easy for the DSC parser to read and turn into an MOF file. This abstraction of an abstraction allows you to write configurations in a language you understand and for that to be translated into a language the system understands.

For example, the target system should have a list of software installed, several settings modified, some services that should be enabled and started, some users to be created and then added to a local group, and several files to be created and have content added to them. It reads like a grocery list to you, but the computer can understand and execute it the same way every time it runs.

The how

The DSC language extensions, Cmdlets, and resources provide a standardized way of testing whether that expected state is present on a target system.

This allows the different aspects of the actual execution of configuring a system to be codified away from the information deciding what settings to change or software to install. Whereas the what dealt with writing down the expected state, the how is concerned with how to make it that way. Or, as Captain Picard would say, how to Make it so.

This separation is important because it is expected that the list of things to do on a target computer will change, but it is not expected that how to execute that setting will change frequently. For example, there will be many types of files that you will create on many filesystems, but there are only a few ways to create those files. By separating the listing of the what, it allows the how to reduce variation by employing the idempotent DSC Resources, an important part of a DevOps workflow.

To summarize the preceding content, we can say:

The DSC DSL defines a standardized way of describing the expected configuration of a target system, whether that is one system or several thousand systems
The DSC set of language extensions, Cmdlets, and resources provide a standardized way of testing whether that expected state is present on the target system(s)
The DSC engine provides a structured way of executing this expected state in an idempotent manner

We have seen the word idempotent in several places in this chapter so far, yet we haven't really defined it or covered why it is important. Let's clarify exactly what idempotence means.

Idempotence

Idempotence is an important concept, sometimes confusing, that we will touch on many times throughout this book. Idempotence is defined as an operation that has no additional effect if it is called more than once with the same input. Put another way, it is an operation that can be executed as many times as desired, and it will only change the system state if and only if it is not what the desired state is. For example, a PowerShell function looks for the x state and guarantees that it will only change the state of the system if it is not x.

It may seem silly to state something as obvious as this. If you feel this way, think of an MSI installer that installs version 1.1.1.0 of an imaginary software product. When you run the MSI, it only ever installs the software if it isn't already present on the system or if the version present is older than the current version. No matter how many times you execute the MSI, it will only change the system if version 1.1.1.0 is not on the system. This is idempotency. The MSI will only ever change the system state if it is not the desired state, no matter how many times you run it.

Idempontent operations are often used in network protocols or API design between dependent systems, and are used in DSC by DSC Resources. DSC Resources are required to be idempotent, in that they do not change the system if the system is in the state that the resource expects it to be in. For example, a DSC resource that operates on Windows Services will only try to start a given service if it is stopped, not if it is started. Another example is the DSC file resource, as that will change a file only if the contents do not match the expected string. By requiring idempotency, DSC Resources can be run as many times as you want, without ever performing an unexpected change.

When you install a piece of software on a machine that already has that software installed on it, you don't want there to be two copies of the software after you're done. You want the installer to be smart enough to detect the version of the currently installed software and then examine the version that you're attempting to install, and ultimately decide that the versions match and no installation needs to be done. That is idempotency in a nutshell.

Isn't this Group Policy or SCCM?

At this point, you may be wondering if DSC isn't a re-implementation of Group Policy (GPO) or System Center Configuration Manager (SCCM). It's a valid question, as there are some overlaps in these technologies.

Group Policy is similar in that it is also a system of configuring operating systems, applications, and user settings in an environment. However, Group Policy is tied to Active Directory (AD) and has a lot of configuration overhead, a complex and sometimes confusing deployment methodology, and is very inflexible. This is not to say that GPO is bad; some of these apparent limitations are by design. GPO has been around since the Windows 2000 days and has had to deal with several decades of different approaches to software and server management.

In comparison, DSC is not tied to AD or a specific operating system platform. It is, by design, very flexible. As we have covered, it is designed to be responsive to the frequently changing technology and dynamic business environments we have today. Instead of obtuse schedules, DSC deployments are declarative and up front about what exactly will happen and when it will happen. GPO has rudimentary tooling that writes binary files for its configuration that can't be read by a human and can't be version controlled. DSC has human readable configuration files that are version controllable.

SCCM is also a configuration management system and is a huge piece of software that requires several servers and many hours to set up and maintain. It is not a small expense to purchase and continue to run, and it is clearly designed for a large enterprise that not only manages servers but user devices such as desktops and laptops as well. It is definitely an all-purpose tool that tries to encompass any need. Managing servers or without, comes free with PowerShell, and requires little setup time to use. While clearly designed toward server management, some desktop management scenarios are supported. It is definitely a fine-honed tool for specific purposes.

DSC features

At this point, we have covered what PowerShell DSC is, how it relates to DevOps and configuration management, and lightly stepped through how it is structured and how it compares to other solutions out there.

We will now cover the requirements and available versions of PowerShell DSC.

DSC requirements

In order to use DSC, both the computer you author the configuration files on (more on this later) and the target computers must have PowerShell 4 or greater installed. This means that at least WMF 4 is installed on all target hosts and the computer on which you are making your configuration files.

PowerShell DSC comes as part of PowerShell 4 and 5. PowerShell 4 will already be present on the following operating systems and no further action is needed to enable PowerShell v4:

Windows Server 2012 R2
Windows 8.1

PowerShell 4 will have to be installed on the following operating systems:

Windows Server 2012
Windows 7 SP1
Windows Server 2008 R2 SP1

PowerShell 5 supports installation on all the preceding operating systems.

Note

Windows 8.1 and Windows Server 2012 R2, DSC requires an update to function correctly. The Windows update KB2883200 (also known as the GA Update Rollup) is required.

While it may already be installed depending on your patching process, you can check whether it is or not by running the following command:

[PS]> Get-HotFix -Id KB2883200
Source        Description      HotFixID      InstalledBy          InstalledOn              
------        -----------      --------      -----------          -----------              
HOSTNAME      Update           KB2883200     HOSTNAME\Admini...   9/30/2013 12:00:00 AM

The only dependency PowerShell has is on the .NET Framework. PowerShell v4 and v5 require .NET Framework v4.5. If you have Windows 2008 R2, please read the release notes at: https://www.microsoft.com/en-US/download/details.aspx?id=40855 carefully, because the WMF 4 installer will not alert you that .NET 4.5 is not already installed.

Some functions of DSC do not work on the client operating systems, as either the features needed aren't present on the client OSes, or due to various other reasons like licensing or software availability. Where applicable, we'll call out these differences as we come to them. Something to note is that some DSC Resources, such as the ones provided by the community or the xDscResource project (more on that later in Chapter 4, DSC Resources), do not work on Windows 2008. You will have to check the release notes for each DSC resource to determine what operating systems it is compatible with.

DSC versions

In the next chapter, we will delve into the details and inner workings of the DSC architecture. Before we do, it will help to have an overview of the Cmdlets and tools at your disposal when working with DSC. Some terms and concepts may be fuzzy here, but will be explained in much more detail in further chapters. We can also use this section as a reference while authoring our own DSC configurations and resources.

PowerShell DSC is released as a feature of PowerShell, so its versioning scheme follows that of PowerShell. PowerShell is distributed as part of the WMF. When referring to the installed version of DSC, we use the version of PowerShell that is installed to denote which version of DSC is currently running.

PowerShell v5, at the time of publication, has not been released yet and is still in production preview status, but we will still cover both v4 and v5 in this book. This will make things somewhat more complex to explain, as we will have to list, compare, contrast, and cover all the similarities and differences between the two versions as we move along. However, it is important to cover these because we fully expect you to have to deal with both PowerShell v4 and v5 deployed in your environments at the same time. The final version of PowerShell v5 is slated to be released in late 2015, so realistically, you will have PowerShell v4 on your production systems for quite a while before moving to v5.

PowerShell v4 DSC

PowerShell v4 was released as part of WMF 4 on October 24, 2013, and contained the first released version of DSC. Even though this was the first release of DSC, it is still referred to as being version 4 of DSC. While confusing at first, this is largely something you can ignore, as the versioning of DSC Resources is a more frequent point of variance.

As the first release, this version of DSC largely focuses on bringing a minimally viable product to market for Microsoft. Microsoft is a little late to the DevOps game with DSC, as there are several toolsets out there that have been in use for many years. Puppet and Chef are the most notable, but there are many others. What sets DSC apart here is that it is not an add-on or separate product; it's a core part of the Windows OS and can be used by other tools as much as it can be used by itself.

The first version contains most features needed out of the gate to start automating your deployment process, but only the built in DSC Resources were available and they were lacking in addressing commonly used products such as IIS, SQL, or Exchange. In the early days, Microsoft relied heavily on the community to expand its DSC resource list, which resulted in mixed success. Microsoft released a set of DSC Resources it authored to the community in batches to address the gap. The combination of community and Microsoft contributions has greatly expanded the reach of DSC, and it has been expanding ever since.

v4 DSC language extensions

DSC adds three new functions as language extensions to support declaring the expected state of a machine:

Configuration: The configuration keyword is a DSC function that declares a set of operations to perform on a target system.
Node: The node configuration keyword is a DSC function that declares the target host to perform operations on.
Import-DscResource: It looks like a PowerShell Cmdlet but is really a keyword. It locates the DSC Resources needed to parse and compile the DSC configuration script.

v4 DSC base resources

The following table lists the DSC base resources of v4:

Base resource	Description
`Service`	The `Service` DSC resource performs operations against Windows services. It can start or stop a service or configure the account it runs under and the startup type of the service. This resource cannot install services; it operates only on services that are already present. See the `xService` resource for additional functionality.
`Script`	The `Script` resource is a versatile generic resource. It allows specifying an arbitrary block of code to be executed on the target host. There are some restrictions like variable expansion and access to some system resources. Generally, this should be used for short term or one-off situations that are not handled by an existing DSC resource, as error handling and proper idempotency is difficult to achieve in the limited space you have.
`User`	The `User` DSC resource performs operations on local users on the target system. It allows the creation or deletion of users and setting passwords and password policies, as well as the basic attributes of the user.
`WindowsProcess`	The `WindowsProcess` DSC resource performs operations on processes on the target system. This is commonly used to execute arbitrary executables with specific parameters that are not handled by an existing DSC resource.
`WindowsFeature`	The `WindowsFeature` DSC resource adds or removes features of the Windows operating system. This uses the built-in Deployment Image Servicing and Management (DISM) infrastructure of the Windows Server platform; some features are not operable using this resource on a client OS.
`Registry`	The `Registry` DSC resource adds, removes, or modifies registry entries in the target system. Support for the full range of registry keys and values is present.
`Environment`	The `Environment` DSC resource adds, removes, or modifies environment variables on the target system.
`Archive`	The `Archive` DSC resource performs operations on compressed files.
`Group`	The `Group` DSC resource performs operations on local groups on the target system. It can add, remove, or modify membership on local groups.
`Package`	The `Package` DSC resource installs software bundled in MSI or EXE formats. In the case of MSI, it can also remove software if all the necessary options are provided to the MSI command line. Please see the MSI documentation for more information about this.
`Log`	The `Log` DSC resource writes messages to the DSC operational log. This is useful for troubleshooting or diagnostic purposes.

v4 DSC Cmdlets

Cmdlet	Description
`Get-DSCConfiguration`	This Cmdlet returns the current DSC configuration status of the node, if the configuration exists. If it does not, this will throw an error. This can also be run on remote systems.
`Get-DSCLocalConfigurationManager`	This returns the current settings, or meta-configuration, of the LCM on the system, if the settings exist. This can be run on remote systems and is useful for troubleshooting DSC deployments that use DSC Pull Servers.
`Get-DSCResource`	This Cmdlet returns a list of all DSC Resources on the system. This is vital in troubleshooting and authoring DSC Resources, as it helps show what resources are present on the system. If the resource you are authoring is not present, then DSC cannot read the resource.
`New-DSCCheckSum`	This Cmdlet returns a hash from the DSC configuration MOF file. This is used to deploy MOF files to pull servers.
`Remove-DSCConfigurationDocument`	This Cmdlet removes the compiled MOF from the target node, along with additional cleanup tasks. This Cmdlet is available only as part of the November 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2: http://support.microsoft.com/en-us/kb/3000850 from the Microsoft support library. Before you use this Cmdlet, review the information in What's New in Windows PowerShell: http://technet.microsoft.com/library/hh857339.aspx in the TechNet library.
`Restore-DSCConfiguration`	This Cmdlet restores the previous configuration for the target node, if a previous successful configuration exists on the target node.
`Stop-DSCConfiguration`	This Cmdlet stops a currently running configuration on a target node. This is useful in aborting interactive configuration runs initiated using `Start-DSCConfiguration`. This Cmdlet is available only as part of the November 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2: http://support.microsoft.com/en-us/kb/3000850 from the Microsoft Support library. Before you use this Cmdlet, review the information in What's New in Windows PowerShell: http://technet.microsoft.com/library/hh857339.aspx in the TechNet library.
`Test-DSCConfiguration`	This Cmdlet runs the specified configuration against a target node, but does not execute it. It compares the current state of the system to the expected configuration, and reports back if they match. No changes are made to the system using this Cmdlet.
`Set-DSCLocalConfigurationManager`	This Cmdlet is used to change the settings, or meta-configuration, on the LCM on the target computer. This is most often used in Pull Server scenarios.
`Start-DSCConfiguration`	This Cmdlet executes the specified MOF file against the target computer. This is the Cmdlet you will use the most, as it's helpful in both authoring and troubleshooting DSC configurations and DSC Resources.
`Import-DscResource`	This Cmdlet is really a dynamic function that is only available at runtime. It specifies which DSC Resources need to be loaded to parse and compile the DSC configuration script.

The v4 DSC Pull Server

The DSC Pull Server is the management server that the DSC agents on target nodes pull DSC configurations and DSC Resources from. This will be explained in greater detail in Chapter 6, Pulling DSC Configurations.

PowerShell v5 DSC

PowerShell v5 is currently in production preview status: http://blogs.msdn.com/b/powershell/archive/2015/08/06/windows-management-framework-wmf-5-0-roadmap.aspx and contains the next version of DSC. The current version available at the time of writing is Windows Management Framework 5.0 Preview August 2015, and the release is deployed with Windows 10. Please see the preceding blog post for more information about the version differences and support contracts. The latest release allows installation on Windows 2008 R2 SP1 and Windows 7 SP1, as well as Windows 2012 and Windows 8.1.

The PowerShell team provides an excellent list of stable and unstable features on their blog and on their connect website; you can see the progress of the available features as they are worked on.

New DSC specific features focus on improving upon the existing functionality provided by DSC in PowerShell 4, while introducing new ways to organize and execute configurations on target hosts.

v5 DSC language extensions

DSC v5 brings several new language extensions that are explained in the following v5 improvements section. It would be redundant to list them in both places, so we will only cover them later.

v5 DSC base resources

The built-in DSC resource list has not expanded, but the existing Microsoft-released community DSC resource project has provided over a hundred new DSC Resources to use, and is now available on GitHub with an open issue page and source.

v5 DSC Cmdlets

Several new Cmdlets have been added or improved upon in the DSC v5 release. Listed here are the most interesting ones for the purpose of our book:

Cmdlet	Description
`Get-DSCConfigurationStatus`	This Cmdlet reports the high-level status of the configuration on the target node. You can obtain the last status or all statuses of all configurations run.
`Compare-DSCConfiguration`	This Cmdlet compares a specified configuration against the actual state of a target node. This is useful to determine configuration drift interactively and compare differences between the actual and expected states of your systems.
`Publish-DSCConfiguration`	This Cmdlet copies the configuration to the target node, but does not perform the initial execution of the configuration on the target node. The configuration will be applied on the next consistency pass or when you run `Update-DSCConfiguration`.
`Update-DSCConfiguration`	This Cmdlet forces the configuration to be processed when the Cmdlet is executed. If the target node is attached to a DSC Pull Server, the agent will pull the configuration from the Pull Server before applying it.

v5 improvements

The v5 improvements are meant to call out certain aspects of the new release. It would be both futile and redundant to just list the release notes here, not to mention a waste of time. Instead, certain features are called out and explained in short detail to help the reader evaluate what is to come.

The PowerShell ISE

The PowerShell Integrated Scripting Environment (ISE) has been improved for authoring DSC configuration files. Intellisense and inline help on demand increase the usability and discoverability of DSC Resources.

The PowerShell ISE intellisense allows the dynamic discovery of all the DSC Resources inside a DSC configuration block by entering Ctrl + Spacebar. Automatic completion of DSC resource names, property name and type, and enum is now supported. Automatically completing the value for DependsOn is a huge time saver when completing long dependency graphs.

Partial configurations and dependencies

DSC partial configurations allow you to deliver configurations in fragments to nodes. This is potentially a great feature to break up the large configuration documents you may have, or help stagger deployment of some distributed applications.

Support for cross-computer dependencies has also been added. This provides node to node synchronization without external input by using CIM session connections between nodes. This means one configuration can wait for another to finish executing before executing itself. For example, a member server can wait to execute until the configuration on a domain controller has finished creating the domain the member server has to join.

Additional support for the DSC RefreshModes has been added to partial configurations. This allows specifying whether a configuration is supposed to be pulled or pushed on an individual configuration level.

This feature is still in the experimental status at the time of publication, so we are unable to accurately cover the feature in this book.

Class-based DSC Resources

Instead of PowerShell module folders and supporting module files, DSC Resources have been simplified to one file using class-based code.

Note

We will cover how to make DSC Resources in Chapter 4, DSC Resources for both PowerShell v4 and v5, but will briefly mention here the improvements v5 brings. If this is confusing at this point, don't worry; we will go into more detail in Chapter 5, Pushing DSC Configurations.

Each file has the get, set, and test functions declared as methods to a single class, which DSC knows how to parse and execute. This is a huge feature in and of itself, and leads to several exciting possibilities, not least of which is class inheritance, which reduces some of the duplication necessary in DSC v4.

The concepts of software classes, functions, and methods may sound more like programming than you want to know, but it is not as scary as it sounds, and this will be further explained in the Class-based DSC Resources section in this chapter.

DSC built-in support for help

DSC configuration blocks now support adding PowerShell standard comment-based help text. This is a real improvement regarding documenting your configuration scripts, as the help text added here will show up in the PS ISE intellisense or by using the Get-Help Cmdlet.

DSC run as credential support

In DSC v5, you can now specify a credential that DSC will use to execute the DSC resource under.

In DSC v4, all configurations were run under the LocalSystem account. This means care must be taken when executing commands or DSC Resources and expecting them to be able to do things such as network access or other normal user actions.

DSC resource side-by-side installation

In DSC v4, you can only have one version of a DSC resource installed. DSC v5 detects versions of DSC Resources now, which allows more than one version to be present on the filesystem. Different DSC configurations can now rely on different versions of DSC Resources and not affect each other.

Currently, class-based DSC Resources do not allow more than one version of a DSC resource on a target node. This most likely will be fixed by the time of release, as what is currently available is only in preview. We mention it here as a warning while using the preview releases and expect it not to matter when the final version is released.

DSC resource script debugging

With DSC v5, you can debug DSC Resources as they run on target nodes. This uses the remote debugging enhancements introduced by PowerShell v5 that allow attaching to remote PowerShell runspaces and interacting with running code. This is hugely helpful, as often the remote system is different than the system you are authoring the DSC Resources on.

The separation of node and configuration IDs

In DSC v4, the ID of the specific DSC configuration applied to a given node uniquely represented the actual configuration and node that it was run on. In DSC v5, this has been separated into a configuration name and agent ID. The configuration name identifies the configuration on a target node, and the agent ID uniquely identifies a node.

This allows you to track both the configuration and node status independently and in relation to the other, giving a holistic picture of the coverage deployment of the whole environment.

DSC LCM MetaConfig updates

Since configuration names have friendly names instead of unique IDs, anyone can set them. This is mitigated by adding a registration step for the target node before the node can start requesting configurations to apply. This registration uses a shard secret that both the DSC Pull Server and the target node know already, as well as the name of the configuration it will request.

DSC LCM rich state information

The amount of detail about the LCM state has been improved to include the status of the DSC configuration on the machine. It will report whether the LCM is Idle, Busy, PendingReboot, or PendingConfiguration.

This is very useful in determining the status of your target nodes as time moves on when using DSC.

DSC LCM RefreshMode values

DSC v5 introduces a new RefreshMode value, Disabled. The LCM will not manage the configuration documents on the system and any third-party can invoke DSC Resources directly by using the Invoke-DSCResource Cmdlet. This is yet another addition to allow outside vendors to take advantage of the consistent common tooling provided by DSC.

DSC status from a central location

This is very much an experimental feature, but an important one in viewing DSC as an entire replacement for existing products in this space such as Puppet or Chef. As of DSC v4, there is no way to report the status of configurations centrally or at a granular level. Terse information describes the current state, with very little information of what went wrong or right. Information is available on a per Pull Server basis.

In DSC v5, this information is improved with more detail and can be forwarded to a central DSC Pull Server. A high-level status can be sent to a central server running the DSC service, which is then stored in a database. A new OData endpoint is created when the DSC service is installed, which exposes the information stored and can be queried by any tool able to make HTTP calls.

Filter reviews by

All

Amazon verified reviews

JimM Dec 22, 2015

Great book and welcome reference.

Amazon Verified review

VenuG Dec 01, 2017

very good book to start and work with DSC

Ron Davis Aug 23, 2016

This guy does a great job. I would buy the other one also as it gives a slightly different perspective.

John Matlock Oct 01, 2016

This book does an excellent job of getting you all or most of the information you need to hit the ground running with DSC. The author does an excellent job of breaking each topic down and then stringing all of the information together in a clear and understandable way. Kudos.

Lindsay Castillo Nov 12, 2015

Perfect Intro to Proficient book. I've seen training videos and followed along but this book was the home run. Not only did I learn about all the moving parts in a logical manner, I also enjoyed the nuggets of what a experiences DSC IT pro is thinking as he goes through the process of learning DSC.The author was very keen on making sure that he was aware of the tripping points that a new comer would have in taking up DSC and pointed out all of the potential stumbling blocks along the way.

Learning Powershell DSC: Get started with the fundamentals of PowerShell DSC and utilize its power to automate deployment and configuration of your servers

What do you get with Print?

Contact Details

Shipping Address

Billing Address

What is PowerShell?

On to PowerShell DSC

The PowerShell ISE

Partial configurations and dependencies

Class-based DSC Resources

DSC built-in support for help

DSC run as credential support

DSC resource side-by-side installation

DSC resource script debugging

The separation of node and configuration IDs

DSC LCM MetaConfig updates

DSC LCM rich state information

DSC LCM RefreshMode values

DSC status from a central location

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

About the author

FAQs