Some background
A new breed of configuration management tools has been created to manage the platforms, applications, and infrastructure of the cloud, and keep the cloud running with high availability. The need for these new tools and infrastructure comes from the increase in scale, rapid rate of change, and complexity of the cloud. But existing tools have limited support for Windows.
Windows PowerShell Desired State Configuration (DSC) provides a configuration platform built into Windows that is based on open standards. DSC is flexible enough to function reliably and consistently in each stage of the deployment lifecycle (development, test, pre-production, production), as well as during scale-out, which is required in the cloud world.
What it is
DSC gives you a powerful and easy wayto manage your Windows infrastructure, both on-premise and in the cloud. It does this by introducing a very simple declarative syntax into the PowerShell language, and a built-in engine that receives and applies the configuration. You describe the desired state of your environment by using this new declarative syntax, and then distribute it to each target node in your environment where it is made so. After the configuration is delivered and applied, it can be used to correct configuration drift when it occurs, or just report on configuration drift, so that you know that it has occurred.
How it is different
You might be thinking, “I can already use PowerShell to manage my infrastructure, why would I want to use DSC?” First of all, as mentioned above, the DSC syntax is declarative, which makes authoring and maintaining the configuration much easier. For example, the DSC configuration below makes sure that Web Server (IIS) and ASP are installed on Server1 and Server2:
ConfigurationIISWebsite
{
Node Server1, Server2
{
WindowsFeature IIS
{
Ensure =“Present”
Name =“Web-Server”
}
WindowsFeature ASP
{
Ensure =“Present”
Name =“Web-Asp-Net45”
}
}
}
As you can see with this new syntax, you can simply declare the state you want your target devices to be in, instead of writing instructions for how to put them in that state. This makes it much less costly for you to learn, adopt, implement, and maintain configuration through DSC.
Something else that you might have noticed in the above example is the lack of error handling. There is no need to complicate your DSC scripts with error handling, because errors are caught, reported and logged by the DSC infrastructure automatically. This makes your DSC scripts much more readable than typical PowerShell scripts.
A key concept of DSC that you cannot see in the above example is that it is inherently idempotent. Idempotent configurations ensure that the desired state will be reached by applying the entire configuration, regardless of the current state. This means that without adding convoluted logic to your script, you can make and deploy incremental changes to your configuration over time without fear of putting your systems into a bad state. PowerShell scripts can also be written in an idempotent way, but cannot be enforced; with PowerShell scripts, it’s also more difficult to get it right, especially when you’re trying to ensure that your scripts will remain readable and maintainable.
Like PowerShell scripts, DSC configurations can be pushed to target nodes, but this has complications in many environments, like allowing the incoming connections through firewall ports. To get around this, DSC has a built-in feature that allows configurations to be pulled from a central location over standard web protocols. The built-in “pull” functionality means that opening new firewall ports is not required. An additional benefit of pulling configurations is that required Windows PowerShell modules can also be pulled from the central location using same web protocols. This means that modules that are required by a configuration do not need to be on the target before you deploy a configuration, because they are pulled down on demand.
More to come
DSC is an exciting new addition to PowerShell, and we have only touched on very high-level concepts in this post; but I hope it has piqued your interest in learning more about DSC. We will be publishing many more posts over the coming days and weeks that will dig into the details of DSC, so stay tuned. In the meantime, I invite you to dig into DSC and see what it can do for you.
DSC is available as part of Windows 8.1 and Windows Server 2012 R2; you can start building configuration files in Windows PowerShell ISE if you’re running either of those new operating systems. If you’re running Windows 7, Windows Server 2008 R2, or Windows Server 2012, install Windows Management Framework 4.0 to get the benefits of DSC. Learn more about how to get started from the DSC documentation on Microsoft TechNet.
Enjoy!
Mark Gray
Senior Program Manager
Microsoft
A new breed of configuration management tools has been created to manage the platforms, applications, and infrastructure of the cloud, and keep the cloud running with high availability. The need for these new tools and infrastructure comes from the increase in scale, rapid rate of change, and complexity of the cloud. But existing tools have limited support for Windows.
Windows PowerShell Desired State Configuration (DSC) provides a configuration platform built into Windows that is based on open standards. DSC is flexible enough to function reliably and consistently in each stage of the deployment lifecycle (development, test, pre-production, production), as well as during scale-out, which is required in the cloud world.
What it is
DSC gives you a powerful and easy wayto manage your Windows infrastructure, both on-premise and in the cloud. It does this by introducing a very simple declarative syntax into the PowerShell language, and a built-in engine that receives and applies the configuration. You describe the desired state of your environment by using this new declarative syntax, and then distribute it to each target node in your environment where it is made so. After the configuration is delivered and applied, it can be used to correct configuration drift when it occurs, or just report on configuration drift, so that you know that it has occurred.
How it is different
You might be thinking, “I can already use PowerShell to manage my infrastructure, why would I want to use DSC?” First of all, as mentioned above, the DSC syntax is declarative, which makes authoring and maintaining the configuration much easier. For example, the DSC configuration below makes sure that Web Server (IIS) and ASP are installed on Server1 and Server2:
ConfigurationIISWebsite
{
Node Server1, Server2
{
WindowsFeature IIS
{
Ensure =“Present”
Name =“Web-Server”
}
WindowsFeature ASP
{
Ensure =“Present”
Name =“Web-Asp-Net45”
}
}
}
As you can see with this new syntax, you can simply declare the state you want your target devices to be in, instead of writing instructions for how to put them in that state. This makes it much less costly for you to learn, adopt, implement, and maintain configuration through DSC.
Something else that you might have noticed in the above example is the lack of error handling. There is no need to complicate your DSC scripts with error handling, because errors are caught, reported and logged by the DSC infrastructure automatically. This makes your DSC scripts much more readable than typical PowerShell scripts.
A key concept of DSC that you cannot see in the above example is that it is inherently idempotent. Idempotent configurations ensure that the desired state will be reached by applying the entire configuration, regardless of the current state. This means that without adding convoluted logic to your script, you can make and deploy incremental changes to your configuration over time without fear of putting your systems into a bad state. PowerShell scripts can also be written in an idempotent way, but cannot be enforced; with PowerShell scripts, it’s also more difficult to get it right, especially when you’re trying to ensure that your scripts will remain readable and maintainable.
Like PowerShell scripts, DSC configurations can be pushed to target nodes, but this has complications in many environments, like allowing the incoming connections through firewall ports. To get around this, DSC has a built-in feature that allows configurations to be pulled from a central location over standard web protocols. The built-in “pull” functionality means that opening new firewall ports is not required. An additional benefit of pulling configurations is that required Windows PowerShell modules can also be pulled from the central location using same web protocols. This means that modules that are required by a configuration do not need to be on the target before you deploy a configuration, because they are pulled down on demand.
More to come
DSC is an exciting new addition to PowerShell, and we have only touched on very high-level concepts in this post; but I hope it has piqued your interest in learning more about DSC. We will be publishing many more posts over the coming days and weeks that will dig into the details of DSC, so stay tuned. In the meantime, I invite you to dig into DSC and see what it can do for you.
DSC is available as part of Windows 8.1 and Windows Server 2012 R2; you can start building configuration files in Windows PowerShell ISE if you’re running either of those new operating systems. If you’re running Windows 7, Windows Server 2008 R2, or Windows Server 2012, install Windows Management Framework 4.0 to get the benefits of DSC. Learn more about how to get started from the DSC documentation on Microsoft TechNet.
Enjoy!
Mark Gray
Senior Program Manager
Microsoft