DSC Planning Update – June 2019
It has been almost a year since the last DSC Planning update. There has been a lot going on, many decisions being made, and it just didn’t make sense to post earlier in this calendar year. In this post we will review what has been shipped and the high-level direction we are heading.
I am accompanying this post with write-ups that are for the more technical audience. In two parts, I would like to explain the implementation of the Guest Configuration client/service and exactly how the new DSC engine functions.
If you take nothing else away, here are the top-level items:
- The new implementation of DSC is Azure Policy Guest Configuration
- The solution is GA for built-in content and is moving towards a preview for custom content
- Your skill set and your DSC scripts/modules can be used in a new way
Azure Policy Guest Configuration
Previously we have referred to the new DSC codebase under different names. “DSC Core” and “the new LCM”. We also disclosed that the platform would be used in Azure Policy Guest Configuration.
What have we shipped?
The DSC codebase we have been working on is now fully GA as Azure Policy Guest Configuration but this is not the DSC you have known up to this point. It is best to think of Azure Policy Guest Configuration as based on the DSC syntax but functionally a new platform.
The intention for this service is to build confidence so application developers/owners are free to deploy servers when they need them without putting the organization at risk. Building this platform on a tool that was designed with operations in mind helps us to look beyond the types of settings that we thought about in platforms such as Group Policy. We can include operational requirements such as making sure all servers have a healthy monitoring agent, logging configuration, and the correct certificates in place to function in an enterprise environment.
DSC has been the basis for other Azure solutions such as the Azure DSC Extension and Azure Automation State Configuration, that help you to configure virtual machines. Azure Policy Guest Configuration currently provides an audit platform to validate settings inside virtual machines.
The full documentation for this service is available at the following short url.
If you would like to continue reading about how this service is technically implemented, the two technical write-ups are published to accompany this post.
Azure Policy Guest Configuration – Service
Azure Policy Guest Configuration – Client
High level direction forward
For the next semester (the second half of 2019 calendar year) we are focused on iterating upon our first release of this solution, introducing the ability for you to use your own content for auditing machines, and to enable you to also enforce settings inside virtual machines using Azure Policy.
It is important for many people to understand what the options will be to use DSC in disconnected scenarios going forward. We are considering our options in this area and taking the feedback seriously. I hope to have more to share on this area in the future.
Iterating upon our first release of the solution includes multiple areas where we believe we can make life easier for customers. One of the patterns we have observed is customers assigning an audit policy but forgetting to assign the policy that handles automatically onboarding servers. In the future we believe we can make this simpler. We have also heard from customers that they would like to have the option to bulk export data about virtual machine compliance so it can be used in other tools, and that they would like to use the solution to audit servers running outside of Azure.
We hope to enable customers to use their own content, and the tools of their choice, when auditing settings inside virtual machines. As an example, we have heard from Chef customers that they would like to be able to use InSpec to audit Windows Servers. As a result, we announced in our session at Chef Conference that we will be co-maintaining a Guest Configuration provider for InSpec as a collaborative open source project that customers can use in Azure Policy Guest Configuration. More information can be found here.
We are investing in getting the user experience right for developing custom content, cross platform for the developer workstation, and having a validation and troubleshooting experience that improves on lessons we learned with DSC. We will soon be moving into a public preview of custom content. In the meantime, you are welcome to give us feedback in our “request for comments” public GitHub repo here.
Finally, we are investigating the right approaches for enforcing settings inside virtual machines using Azure Policy. With this scope in mind, I would like to invite you to respond to a (an anonymous) survey to provide feedback on your top requirements.
Thank you! Michael Greene Principal Program Manger Microsoft Azure @migreene
Light
Dark
13 comments
What does this means for people who don’t want to use Azure? Should we forget about DSC and move into other tools like Ansible?
If you are not happy with the current state of DSC, Michael needs your feedback. Microsoft is using customer feedback more and more to prioritize deliverables, so the more you and I submit feedback, the more data that team has to justify continued investment.
And it is worth pointing out that Microsoft invested in a new platform that is built directly in top of DSC. This doesn’t take away from what we have today. In fact, you can build new resources that are usable in both DSC and policy manager. Look at this as an extention of DSC and not the replacement for it.
Kevin, Is there any update on this? Is there going to be an on-prem version. We have many situations where we cannot be open to the internet but want these capabilities.
what is DSC? Could you use the full name the first time? Also with link.
(This post pops up to my browser homepage. Maybe I have searched PowerShell.)
Desired State Configuration -> https://docs.microsoft.com/en-us/powershell/dsc/overview/overview
How will it affect on-premises Windows Server DSC functionality? DSC should be treated now as deprecated feature?
I initially delved into DSC a few years back and created a number of configuration scripts for on-prem VMs. Since then our company adopted Chef and I moved into using this tool over DSC due to it’s established platform. Working with Chef for over a year or two now, I haven’t been following the changes in DSC. We use Chef with AWS platform. Will the future of DSC support this platform (or any other cloud platform) or is it just Azure only? Why would I use the “new” DSC over Chef? There seems to be a lot of “catching-up” to do compared to established tools on the market. Don’t get me wrong, I enjoyed using DSC at the time but I need solid examples what the new DSC has to offer before investing any more time in the tool.
This statement is somewhat confusing: “The new implementation of DSC is Azure Policy Guest Configuration ”
Are you saying that Azure Policy Guest Configuration is A new thing, and it’s based on DSC … Or is Azure Policy Guest Configuration THE only thing going foward and essentially replacing DSC?
The latter would be very concerning to me. I’ve built our entire production infrastructure using DSC. We’re mostly a Windows shop, but we also operate 100% in public cloud, most of which isn’t Azure. I’ve also been using DSC for more than machine management (i.e. cloud automations).
I really hope I’m reading into this incorrectly. If DSC (i.e. the LCM) is not going to be a core feature in PowerShell 7 that can be used anywhere (e.g. local, not dependant on internet access / cloud-agnostic ) then I’m going to have to start moving away from it immediately.
Please tell me that’s not the case.
What is happening with support for on-premise physical hardware? We use DSC to ensure all our desktop clients are configured, prevent drift and the settings are applied from local configuration stores, this doesn’t seem to support our use case at all?
Lots of good questions here, but no response after a month. I appreciate the effort to provide information around DSC planning, but all of us need answers so that we can determine how to proceed so that we can take care of our organizations and/or clients.
It looks like Microsoft is in the process of killing the onprem DSC and moving this entirely to an Azure-based service:
https://docs.microsoft.com/en-us/powershell/dsc/pull-server/pullserver
The Pull Server (Windows Feature DSC-Service) is a supported component of Windows Server however there are no plans to offer new features or capabilities. It is recommended to begin transitioning managed clients to Azure Automation DSC
The irony is a statement like this: The Azure service can manage nodes on-premises in private datacenters, or in public clouds such as Azure and AWS. For private environments where servers cannot directly connect to the Internet, consider limiting outbound traffic to only the published Azure IP range (see Azure Datacenter IP Ranges).
That means those serves CAN directly connect to the Internet…
I’ll echo questions previously posted here — what are the actual plans for using DSC in scenarios where you don’t have Internet access and aren’t deploying resources in Azure? Should we just continue using Windows PowerShell DSC as provided in-box and any modules we use to enact configurations?
I know the organizations I work with are “behind the times” somewhat, but I don’t think everyone has gone 100% cloud and abandoned on-premises hardware and Windows Server 2019 yet. My plan was to use DSC for the full config automation of our large Windows Server fleet that resides on a closed network with no Internet or Azure access. Should I abandon these plans? The goal here was to leverage a tool that was already shipped in the box with Windows, doesn’t require agents or learning another configuration language and doesn’t require Linux or Windows Subsystem for Linux.
Also the other tools like Chef, Puppet and Ansible use DSC under the hood to perform some of the tasks defined in their higher-level abstraction. Something tells me these aren’t being abandoned, so can Microsoft please clarify what the plans are?
Since Microsoft seems 100% feedback-driven now, how do I submit some feedback reminding them that some people are running Windows Server outside of Azure in disconnected environments?
What Im reading here is that DSC is migrating from a framework/model to a solution, which is basically a monlithic mistake and against everything DevOps is right now.Ideally DSC should be taking its idempotent roots and framing itself like Ansible: you put a definition together and it apply it, either locally or to a targeted system. No compiling which would make it tougher to integrate, Just read/apply at runtime. Doing this would allow the Microsoft community to leverage the DSC framework in “Azure Policy”, in Terraform, reuse modules in CAPS easily … anywhere. That way it can work with a pull server, with Azure services, or with anything else for that matter. Instead the cynic in me reads that its becoming useless outside Azure Policy. All value adds will belong under a paid umbrella, and the core service will still likely require compiling making it basically useless in any ad-hoc pipeline.Sorry for being cynical, but this is very disapointing