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.

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.

(find-dscresource).count

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:

Azure Fridays – Azure State Configuration experience

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