2018 has been the most active year ever for the DSC community. The DSC team is taking on major new areas of work in Azure, and we have made significant progress in development of the new DSC platform.
Applies To: Windows PowerShell 4.0, Windows PowerShell 5.0. DSC is a management platform in PowerShell that enables you to manage your IT and development infrastructure with configuration as code. For an overview of the business benefits of using DSC, see Desired State Configuration Overview for Decision Makers. Jun 12, 2017 Applies To: Windows PowerShell 4.0, Windows PowerShell 5.0. DSC is a management platform in PowerShell that enables you to manage your IT and development infrastructure with configuration as code. For an overview of the business benefits of using DSC, see Desired State Configuration Overview for Decision Makers. Jan 05, 2017 Working on automating virtual machine build configuration with DSC one thing I really wanted was a DSC resource to allow any outstanding Windows Server Update Services (WSUS) patches to apply once the VM was deployed.
In this Planning Update for DSC, I want to cover these topics in detail and share major changes to the timing of our Open Source plans for the DSC platform.
Increase in DSC Community contributions
Since January 1st, across modules that are linked from the DscResources repo, over 475 Pull Requests have been merged to accept community contributions and over 300 issues have been closed. The number of DSC Resources in the PowerShell Gallery almost doubled over the course of the summer. We now have over 1300! You can verify this by running the following command.
This represents a new level of activity from the DSC community. Thank you to all of the community contributors and maintainers who made this possible. I would encourage you to visit the Maintainers list and pass on gratitude via Twitter if their work is making you successful.
I would especially like to thank Johan Ljunggren who has been assisting the PowerShell team with this effort and providing us with thoughts and guidance on how we can continue supporting the community effort.
If you are interested in getting involved but not sure where to start, you are welcome to joining the monthly Community Call for DSC.
Expanding the use of DSC in Azure
As part of joining the Azure Compute organization, the DSC engineering team has taken on significant new responsibilities. This is a really positive and healthy journey for the DSC platform. Much of this work is happening “behind the scenes” but I am optimistic that these investments in DSC at cloud scale will result in a more optimized platform in the future.
New Azure State Configuration interface generally available
Earlier this year we received feedback that when managing many thousands VM’s from Azure Automation, the interface was not optimized for finding and using information. As a result we have completely revised the experience in the Azure portal. The previous items in the Table of Contents including Nodes, Configurations, and Node Configurations, have been consolidated in to a single tabbed view that pages. The information is interactive and can be navigated by right-clicking rows to filter for correlation such as other nodes using the same configuration. The new interface is now generally available and enabled by default.
You will also find a new authoring experience from the Configurations tab. From here you can select among composite resources, either built-in or any that you have added as modules in Azure Automation. This is designed to help new users of DSC understand configuration authoring without the need to start from a ‘blank page’ in an editor. As always, configurations generated by this experience can be saved locally and added to source control.
Starting this week, we now have a preview that extends this experience to the Virtual Machine page in Azure. You will find a new item, “State configuration (Preview)” listed under “Operations”. This makes it much easier to onboard to the DSC solution. You will find features like the new reporting and authoring experiences are also available from this single-VM view. The intent of this effort is to make it easier for anyone new to get started with configuration as code. Note that based on feedback we will soon be renaming this item on the VM table of contents to “Configuration management”.
You can learn more in the following video:
Thank you to everyone that has provided feedback and helped us to improve. If you have thoughts and opinions to share please create a new item in on our feedback page. You can also mention @powershell_team on Twitter or post to the DSC forum on PowerShell.org.
Improving integration between Azure Automation and VSTS
Very soon you will see tasks available in the Visual Studio Team Services marketplace to provide integration with Azure Automation. This includes tasks for Build and Release Management phases to publish runbooks, modules, and configurations to an Azure Automation account, and to assign configurations to registered nodes.
This is the first of multiple steps we are planning to reduce the complexity of getting started with release pipeline (CI/CD) scenarios.
Guest Configuration feature coming to Azure Policy
Very soon we will be releasing a new feature for Azure Policy that will help people to audit settings inside Linux and Windows servers. Much like the services for Inventory, Change Tracking, Update Management, and Security, this new capability includes features built on the DSC v2 platform.
I have heard the following question times:
I am using Group Policy to manage Windows Server in my private datacenter.Now I have application owners deploying to servers in the cloud.If the servers are not domain members and they are re-deployed frequently,what does Microsoft recommend I use to verify the servers meet our security requirements?”
If you are facing this challenge, Azure Policy Guest Configuration is the path to success.
The new feature will focus on auditing servers after they are deployed. To deploy servers with the correct operational and security settings, customers can use their existing configuration management tools such as DSC, Chef, Puppet, Ansible, Salt, etc.
Over the next couple of months we will be providing more information. I look forward to hearing feedback to help shape future work in this area.
New features for DSC coming in Server 2019
Some of the top requests for DSC will ship as new features in Server 2019.
- Servers registered to Azure Automation State Configuration will automatically rotate certificates without requiring re-registration
- To further increase security, during the process of applying configurations no temporary files will be written to disk -A new mode will be available to monitor DSC configurations without applying settings (the full list of modes will be MonitorOnly, ApplyOnly, ApplyandMonitor, ApplyandAutoCorrect)
- ESENT database settings in Windows Pull Server will be configurable including max length of download file
- To further increase security when Device Guard is enabled in Windows, DSC will no longer allow the built-in Script resource (MSFT_ScriptResource)
- Windows Pull Server will support using SQL as a database
Unfortunately these will not be back-ported to previous versions of DSC that shipped with Windows. We are taking this in to consideration for future releases of the DSC platform.
Security update for DSC in Windows
As part of the September 2018 updates for Windows (server and workstation) we have released an update that applies to all existing versions of DSC in Windows. This addresses a concern where in rare situations the configuration would remain in the system temp folder after it is applied. The risk is mitigated by multiple factors.
Once this update has been applied, DSC will no longer write any temp files during the process of applying a configuration. The update is included in KB4457128.
Changes to timing for next DSC platform to be Open Source
At the PowerShell and DevOps Global Summit and PowerShell Conference EU, I presented on future plans for the DSC platform including our intention to publish a new version of DSC as an Open Source project. At the time I hoped that the project would be published by late summer. I also said that we would not begin the project until we could be responsible project maintainers, and that I am not interested in simply “sharing code”. I insist that when we make DSC a public project we must be ready to manage incoming contributions from the community to show respect for their time and effort in helping us to make the solution the best it can be.
Soon after those events our team took on additional responsibility. We determined it would not be feasible for engineering to meet these new commitments if, during the same time, we delivered on our plans to maintain a new Open Source project. So, we had to change our plans.
We still expect to make the new DSC platform an Open Source project. The codebase is already in use across services in Azure and will be part of new services we introduce this year. Our long term goal is to have a single DSC platform in use everywhere. Our plans for features of the next generation of the DSC platform were given in the last planning update post.
Just to make a clear distinction, this new DSC platform is where we are making future investments and we want it to be available for configuring both Windows and Linux in the future. We will also continue to support the existing version of DSC following the Windows Server support lifecycle.
Unfortunately I am not ready to set a new date on when the project can become public. To set a date now would be premature and would risk needing to make changes again in the future. In the meantime, I hope to publish RFC (Request for Comments) and continue our commitment to the DSC open source community for Resources, Configurations, and Tooling. As soon as our engineering schedule allows us to maintain the project as a public repo, I will follow up here with more information.
Thank you!
Michael Greene
Principal Program Manager
Azure Security & Management Services
@migreene
PowerShell Core and DSC
PowerShell is open sourced and moving over to .Net Standard 2.0 for the reasons outlined inJeffrey’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. InJoey’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 Configurationis 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 Linuxis 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 asAzure 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
Dsc Windows Update
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)
Windows Update Assistant
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:
Dsc Windows Update Windows 10
- 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 updatedhere.
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.
Using Dsc On Windows 10
Mark Gray, DSC Program Manager
Indhu Sivaramakrishnan, DSC Software Engineering Manager