Windows Server OSConfig and DSCv3
Introduction I wanted to formalize putting a post out here to get some discussion going on the attempts at modernization of Windows configuration, and importantly, infrastructure-as-code. Hopefully this is a healthy discussion that others can engage in. Much of what I'm going to try and post about is stuff we already are aware of, but I want to highlight how this is an ongoing concern with the Windows Server platform that makes it difficult to encourage people to even consider Windows in their environment other than for extremely legacy purposes. I want Windows Server to be the best it can be, and I encourage others to join in on the conversation! Problem Statement Windows Server needs a modernized configuration-as-code system. Must be capable of orchestrating without cloud tools (offline orchestration) Must provide for regular validation and attestation Ideally should be easily available to 3rd party configuration tools. Since Microsoft appears to have little interest in building their own modernized system that isn't Azure-based, this means that this MUST be orchestrated easily and securely by 3rd party tools. Should be as robust as GPO at maintaining and enforcing state. Security configurations in Windows are a right pain to manage with any 3rd party tooling, with the closest coming to it being the SecurityDSC module which wraps secedit.exe and security policy INFs. Why is OSConfig not the answer? OSConfig doesn't provide for me, as an engineer, to clearly define what the state of my machines are based on my company's business requirements. While the built-in Microsoft policy recommendations are great, there are reasons to deviate from these policies in a predictable and idempotent manner. Applying an OSConfig Baseline -> Then changing settings as-needed with special PowerShell commands This is not the answer. This is a bunch of imperative code that serves nobody. And it makes implementing this feature extremely challenging in today's modern world of Kubernetes, Docker, etc. I encourage the Windows Server team to engage with the PowerShell team on DSC 3.0. I think that team has it right, but they are a small group of people and do not have the resources to implement everything that would make DSC 3.0 a first-class configuration as code platform on Windows. And this is where the Windows team should come in. Steve Lee and crew have done a bangup job working on DSC 3.0, including taking feedback from folks to leverage Azure Bicep language for configuration. Security Policy Challenge The way to access security policies need to change. Even if I were to take DSC 3.0 I'd end up having to create a similar security policy INF file to import into Windows. It just seems so silly to me to have to write all of that out when Windows really should just provide an interface for doing this. In fact, security policy remains to be one of the largest problems to getting a good platform stood up. Windows Firewall Policy and GPO - The reason why host-based firewalling is painful to manage at scale in a Windows environment. GPO is definitely not the right place to be managing Windows firewall policy at scale. Particularly when you often have a core set of management rules you want to implement and application-specific needs. Making robust changes becomes a challenge since each policy is separate, preventing you from doing things like inheriting rules for higher level policies. While this is an inherent limitation of Group Policy, it highlights the need to get off of GPO as the core policy configuration tool for Windows. My recommendations I'd like for the Windows team to implement DSC 3.0-compatible resources for managing all core functionality of Windows. If you can do it in a GPO, you should be able to do it with Configuration as Code. Please stop relying on the community to make this work. All of this should be first party to the platform itself. Furthermore, I'd like to recommend that Microsoft either work with 3rd party configuration systems (Chef, Ansible, Puppet, Octopus, etc.) OR to also provide a way to hit the ground running. Perhaps something that integrates visually into Windows Admin Center would be nice. Conclusion This is a huge problem in the Windows world and continues to seem to fall on some deaf ears somewhere in the organization. While I no doubt am confident that the engineers on all of these teams very well know these issues and maybe even have discussed fixing them, clearly there's a breakdown somewhere.
VM DSC Extension - Repository doesn't match Reality
Hi, I am provisioning VMs as session hosts for AVD, using Entra ID for login. During the deployment process, one of the resources is Microsoft.Compute/virtualMachines/extensions/Microsoft.PowerShell.DSC. Based on the deployment information, the artifacts (scripts) that are being used come from this path: https://wvdportalstorageblob.blob.core.windows.net/galleryartifacts/Configuration_1.0.02893.601.zip The confusing part is that when I view those files, they are a bit different than the ones stored in the Azure GitHub repo here: https://github.com/Azure/RDS-Templates/tree/master/ARM-wvd-templates/DSC Is the GitHub repo just out of date or need review? I have questions on the implementation of the scripts, but it seems like figuring this out is the necessary first step.