Windows Server 2016 release broadens reach across IT spectrum
A comprehensive collection of articles, videos and more, hand-picked by our editors
Microsoft introduced PowerShell Desired State Configuration with Windows Server 2012 R2 to help administrators...
configure, manage and deploy systems. The configuration management system requires admins to use PowerShell to build scripts with cmdlets to keep settings from drifting.
Recent changes to Windows PowerShell DSC in Windows Server 2016 can help admins establish comprehensive control over a server's configuration. Microsoft also designed these configurations to be portable; the building blocks of those configurations can be reused, thereby making Windows PowerShell DSC more effective than the previous version.
Windows PowerShell DSC lets administrators define a desired state and then apply that state to other systems to ensure they comply with organizational policies. This is useful for both new server deployments and for remediating servers that suffer from configuration drift.
Issues with Windows PowerShell DSC in Windows Server 2012 R2
While many administrators found the Windows Server 2012 R2 version of Windows PowerShell DSC useful, it was somewhat cumbersome and nonintuitive to use because it did not follow the customary PowerShell format. Microsoft designed PowerShell to be uniform with cmdlets comprised of verb-noun combinations. But Windows PowerShell DSC in Windows Server 2012 R2 did not follow this model.
Using Windows PowerShell DSC required two steps. First, admins must write a PowerShell script such as the one below:
Import-DscResource –ModuleName 'PSDesiredStateConfiguration'
This script checks that Hyper-V is installed on a server; however, the script cannot run on the server of choice. With Windows Server 2012 R2, administrators run this script to produce a .MOF file. To apply the .MOF file to the server, the administrator uses the Start-DscConfiguration command and provides a set of credentials -- the computer name and the path where the .MOF file resides. The process won't work if the .MOF filename does not match the specified computer name.
In Windows Server 2016, Microsoft attempted to make Windows PowerShell DSC easier to use. For example, it eliminated the .MOF file requirement. In doing this, Microsoft allows a definition of classes within PowerShell; developers can produce a series of reusable DSC building blocks and stitch them together to form a DSC configuration, which requires a minimal amount of coding.
Microsoft introduces PowerShell testing tools
To help developers and administrators test their code, Microsoft added an open source tool called Pester to Windows PowerShell. Pester is a testing framework that can validate PowerShell scripts -- including Windows PowerShell DSC code. Previously, a standard code test tool did not exist for PowerShell.
Additionally, Microsoft built a debugger into PowerShell ISE and provides a Best Practices Analyzer module for PowerShell to help people to write better PowerShell scripts.
Updated Windows PowerShell DSC removes uncertainty
Windows PowerShell DSC can help administrators who want to ensure that systems use a configuration that adheres to corporate security policies. As an added benefit, the updates to Windows PowerShell DSC in Windows Server 2016 can help make applications run more predictably.
Developers in enterprise-class organizations create and test applications on lab hardware; however, when the app moves into production, it may or may not work depending on how closely production settings mimic the development environment. Microsoft touts Windows PowerShell DSC's configuration as code capabilities, which enable developers to also program server settings, such as networking and registry keys. That way, developers make certain that the application will work because they have also tailored the server configuration for that application.
Server configuration aids with not only development but also provisioning. Because developers can code the server configuration, they can modify it to meet their needs during the development process. For example, a developer might change a line of code to modify a server's network configuration. Once the configuration and the associated application are complete, an administrator uses the configuration file to provision the production server automatically.
Avoid configuration drift with DSC
Push out a DSC Pull Server
Connect to DSC Pull Server to keep servers in line