PowerShell V5 was released on February 24, 2016, and contains the next version of DSC.

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

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 the deployment of some distributed applications.

Support for cross-computer dependencies has also been added. This provides node-to-node synchronization without external input 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 you to specify whether a configuration is supposed to be pulled or pushed on an individual configuration level.

This feature is still in an experimental status at the time of writing this, 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.

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 the least of which is class inheritance, which reduces some of the duplication required in DSC V4.

The concept of software classes, functions, and methods may sound more like programming than what you want to know, but it is not as scary as it sounds, and it will be further explained in the PowerShell class-base DSC resource section in this book.

DSC configuration blocks now support the addition of 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 help text added here will show up in the PS ISE IntelliSense or 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 like 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 you to have more than one version 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 will most likely 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 you to attach to remote PowerShell runspaces and interact with the running code. This is hugely helpful, as often, the remote system is different from 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 shared 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 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 it is an important one in viewing DSC as an entire replacement of 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 on 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. 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.