PowerShell Core and DSC
PowerShell is open sourced and moving over to .Net Standard 2.0 for the reasons outlined in Jeffrey’s blog post. Like PowerShell, PowerShell Desired State configuration (DSC) needs to meet customers in this multi-platform, multi-cloud, multi-OS world where they live. In Joey’s blog post, he outlined what this means to the future of PowerShell. What does all of this mean for DSC going forward?
In this post, we will discuss what direction we plan to take DSC including:
- The DSC engine / local configuration manager (LCM)
- DSC cmdlets
- DSC Azure Extension
- On-prem DSC pull server
Editions
Windows PowerShell Desired State Configuration is included as part of Windows PowerShell
- Requires WMI
- Ships as part of Windows and Windows Management Framework (WMF)
- Requires Windows PowerShell 4.0, 5.0, 5.1
- Supports resources written in native C (WMI based) and PowerShell
- Cmdlets use WinRM or CIM for remote connections
DSC on Linux is open source version for Linux SKUs
- Requires OMI
- Supports resources written in native C and Python
- Is not at feature parity with Windows DSC
- Is separate open source code base
Desired State Configuration Core (DSC Core) is a soon to be released version of DSC that aligns with PowerShell Core
- No dependency on WMI
- No dependency on WMF
- Xcopy-able package
- Supports resources written in native C/C++ (no WMI), Python and PowerShell
- Runs on Windows and Linux
- Required (includes in package) PowerShell Core and .NET Core
Note: The above descriptions are based on current plans and implementation and may change slightly upon release
Philosophy for DSC Core
Our goals with DSC Core are to minimize dependencies on other technologies, provided a single DSC for all platforms, and position it better for cloud scale configuration while maintaining compatibility with Windows PowerShell Desired State Configuration.
As noted above, Windows PowerShell Desired State Configuration has dependencies on a number of other technologies. As a Windows component, this made sense since most if not all of these components were already part of Windows. The side effects of these dependencies (ex. WMF), however, include larger package sizes, upgrade complications due to other product’s use of these components, reboots required during installation, etc. For these reasons and more, DSC Core will reduce its dependencies on other technologies as much as possible.
What does this mean for compatibility?
- DSC Resources: There will be support for native C resources, PowerShell 6 and Python (on Linux) supported resources. All existing and new DSC resources that use supported.NET standard 2.0 commands will work with DSC Core.
- Cmdlets: The existing cmdlets will not work with DSC Core. A new set of cmdlets will be provided for use with DSC Core. We will do our best to maintain backward compatibility of these new cmdlets with Windows PowerShell DSC as well as maintaining script compatibility (ie. cmdlets will have same names and parameters). We are looking for feedback from the community on how important having backwards compatibility in these cmdlets is so, if you have an opinion, please add your comment to this post.
- Azure DSC Extension: A new Azure extension will be provided that uses DSC Core.
- Pull Server: The existing protocol that DSC uses to communicate with the Pull Server will be supported by DSC Core so existing Pull Server as well as Azure Automation DSC(AA DSC) will be compatible with DSC Core.
- Configurations: Configuration scripts will be fully supported and will require no changes. They will just need to be compiled in PowerShell 6.
Note: The above compatibility is based on current plans and implementation. Since this is still a work in progress some things may change slightly upon release.
Although DSC exists for Windows and Linux currently, they are separate projects. They each have, for example, their own code base, features and defaults, etc. DSC Core will be a single project for all platforms. This means that features and functionality will be common whether you are using Windows or Linux. And more importantly, going forward new features, fixes, etc. will be available for both Windows and Linux.
Lastly, key portions of DSC Core are being rearchitected to better support cloud scale configuration. As an example, our intent is to support multiple versions of DSC Core side by side while retaining the DSC promise of a known end state. This enable scenarios like having some configuration that are “Autocorrected” every 15 min while other configurations are “Monitored” every 6 hours. This type of flexibility combined with a small xcopy-able package will make DSC Core much more flexible and scalable in the cloud world.
WMF version of DSC
What happens to Windows PowerShell Desired State Configuration when DSC Core is released? As a Windows product, Windows PowerShell Desired State Configuration will continue to be supported and security fixes will be released for it but all new features and functionality will be driven in and release in DSC Core.
You will be able to run Windows PowerShell Desired State Configuration and DSC Core side by side but in order to prevent undetectable conflicts between the two agent’s configurations, this should be treated as a migration scenario with the goal of eventually moving to DSC Core and disabling Windows PowerShell Desired State Configuration.
Pull Server
On-prem
The on-prem pull server is the Windows feature that ships with Windows since 2012 R2 and is included in WMF. There are three versions: 4.0, 5.0 and 5.1.
I am sure you have noticed that we did not discuss the Pull server in many of the above sections. There are a couple of reasons for this. First, since it is an extremely important but separate part of DSC, it deserves its own section. Second, we are still working on what the future of this looks like.
That said, we are committed to supporting and fixing critical security and performance issues with the on-prem pull server while we lock down on our plan for providing solutions for all of our customers whether you are in the Hybrid cloud, moving from on-prem to the cloud or staying on-prem. We want to be transparent with you so that we can ensure that we are going down the right path with this and all things DSC so expect an update on this in the coming months.
Azure Configuration Management (Azure Automation DSC)
Azure Automation DSC is the recommended pull server solution for enterprise and cloud environments. It supports both Windows PowerShell Desired State Configuration and will support DSC Core. It is and will remain our premium managed service. This provides the functionality of the in-box DSC Pull server and much, much more. Some of the additional goodies that you get with Azure Automation DSC are as follows:
- Hosted Service (no infrastructure for you to manage)
- Highly scalable pull service
- Configuration status reporting
- Central management that supports Azure Portal, PowerShell, Azure CLI, and Rest API iteration
- Highly extensible through close integration with Automation Runbooks
- Fast release cycle so you get new features and fixes faster
Timeline
There is a ton of work that we want to do here, much of which is already in flight. Instead of holding everything until we are done, we will enable specific scenarios and then release. Our first release will be focused on Azure scenarios and will be release through the Azure DSC extension. The first release is expected to be around the end of the calendar year. From there we will be taking advantage of the faster release cadence available in the cloud to push new features and functionality first through the Azure DSC extension and then we will release as a downloadable package. ETA for this package is not yet determined, but we will publish a roadmap that we will keep updated here.
We are really looking forward to getting your feedback and sharing all of the work that we have been putting into DSC Core with you so don’t touch that dial.
Mark Gray, DSC Program Manager
Indhu Sivaramakrishnan, DSC Software Engineering Manager