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.
Preview Build 17639 "DSC-Service" Feature: required DLL missing from WinSxS
Short Version: Build 17639, both the LTSC and Semi-Annual versions, is missing the following DLL in the WinSxS folder: Microsoft.Powershell.DesiredStateConfiguration.Service.resources.dll It is normally located here: C:\Windows\WinSxS\msil_microsoft.powershel..r.managed.resources_31bf3856ad364e35_10.0.14393.0_en-us_a944edf580471efa Long Version: I'm testing build 17639 of Windows Server to try out the new SQL Server support for the local pull server feature of DSC. I was trying to use the xDscWebService resource within the xPSDesiredStateConfiguration module (version 8.1.0.0), which is the "usual" way of installing a pull server, but I manually ran "Add-WindowsFeature Dsc-Service" before running the script with the xDscWebService configuration. Mostly, I did this just to check out the files, compare versions, etc. But once I ran the script, it failed with an error: PowerShell DSC resource MSFT_xDSCWebService failed to execute Set-TargetResource functionality with error message: ERROR: C:\Windows\System32\WindowsPowerShell\v1.0\modules\PSDesiredStateConfiguration\PullServer\en\Microsoft.Powershell.DesiredStateConfiguration.Service.Resources.dll does not exist This DLL is copied from WinSxS into the path in the error above when you install the Dsc-Service feature. I then compared this to a GA version of Server 2016 (non-Core but I don't think it matters), and that file does exist in WinSxS: I did check the build 17639 system and that DLL is nowhere to be found in WinSxS, or anywhere else, on that server. I created the "en" directory as described in the error, copied the DLL over from the build 14393 server shown in the picture above into that "en" directory, and the resource was then able to create the pull server successfully. Additionally, it actually functions and writes to SQL Server as promised; bonus! This post may be light on the info, sorry, but really it's just one bug report: that DLL is missing from WinSxS and is therefore not added during the installation of the Dsc-Service feature.Preview Build 17639: "DSC-Service" feature missing a DLL in WinSxS
Short Version: Build 17639, both the LTSC and Semi-Annual versions, is missing the following DLL in the WinSxS folder: Microsoft.Powershell.DesiredStateConfiguration.Service.resources.dll It is normally located here: C:\Windows\WinSxS\msil_microsoft.powershel..r.managed.resources_31bf3856ad364e35_10.0.14393.0_en-us_a944edf580471efa Long Version: I'm testing build 17639 of Windows Server to try out the new SQL Server support for the local pull server feature of DSC. I was trying to use the xDscWebService resource within the xPSDesiredStateConfiguration module (version 8.1.0.0), which is the "usual" way of installing a pull server, but I manually ran "Add-WindowsFeature Dsc-Service" before running the script with the xDscWebService configuration. Mostly, I did this just to check out the files, compare versions, etc. But once I ran the script, it failed with an error: PowerShell DSC resource MSFT_xDSCWebService failed to execute Set-TargetResource functionality with error message: ERROR: C:\Windows\System32\WindowsPowerShell\v1.0\modules\PSDesiredStateConfiguration\PullServer\en\Microsoft.Powershell.DesiredStateConfiguration.Service.Resources.dll does not exist This DLL is copied from WinSxS into the path in the error above when you install the Dsc-Service feature. I then compared this to a GA version of Server 2016 (non-Core but I don't think it matters), and that file does exist in WinSxS: I did check the build 17639 system and that DLL is nowhere to be found in WinSxS, or anywhere else, on that server. I created the "en" directory as described in the error, copied the DLL over from the build 14393 server shown in the picture above into that "en" directory, and the resource was then able to create the pull server successfully. Additionally, it actually functions and writes to SQL Server as promised; bonus! This post may be light on the info, sorry, but really it's just one bug report: that DLL is missing from WinSxS and is therefore not added during the installation of the Dsc-Service feature. Edit: Sorry, had the wrong PowerShell window capture in there...
