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.
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.
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.
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:
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 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.
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.
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 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.
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.
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.
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.
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.
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.
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 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.
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.