This post will cover PowerShell Desired State Configuration (DSC) Architecture, which is a PowerShell based configuration management system. PowerShell DSC can be used to specify the desired state of computer resources and configurations within an organization.
This post covers the basics of PowerShell DSC architecture, including what it does, how it works, where you should use PowerShell DSC in your environment, and some best practices for using PowerShell DSC with Windows Server 2012 R2.
PowerShell DSC is a PowerShell based configuration management system that can be used to specify the desired state of computer resources and configurations within an organization. PowerShell DSC was introduced in Windows Server 2012 as part of the PowerShell v.Next release and has been updated with each new version of Windows Server.
PowerShell DSC enables administrators to declaratively specify the configuration of their servers, using PowerShell scripts. In addition to specifying the desired state of server resources, PowerShell DSC can also be used to deploy and manage software applications.
DSC works by configuring a set of nodes (computers) that will execute the DSC configuration. The DSC configuration is written as a PowerShell script, and PowerShell DSC can be used to deploy the PowerShell script on a set of computers.
When PowerShell DSC is run, it will evaluate each resource in the configuration script (node), against its current state; if any resources are out-of-state then PowerShell DSC attempts to bring them into compliance with the desired state specified by the configuration script.
PowerShell DSC uses the Windows Remote Management (WinRM) PowerShell remoting protocol to communicate with nodes, and also relies on a local or Domain-based PowerShell configuration for execution policy.