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.
ansible.windows.win_dsc resource SqlPermission Not found
Hi I am trying to do SQL (SQL Server 2022) Automation along with Always_ON and failover Cluster setup using Ansible on Azure VM (Windows 2019 Server) . Since SQL VM do not have internet connectivity , I tried to install below module manually by downloading respective nupkg files. PowershellGet SqlServerDsc When we are trying to configure SQL Server Permission using below Ansible task, we receive following error messages ("msg": "Resource 'SqlPermission' not found.") - name: configure SQL server permissions ansible.windows.win_dsc: resource_name: SqlPermission ServerName: 'LocalHost' InstanceName: '{{ sql_server_instance_name }}' Name: '{{ item }}' PermissionToInclude: - State: Grant Permission: - 'AlterAnyAvailabilityGroup' - 'ViewServerState' - 'AlterAnyEndPoint' - 'ConnectSql' Credential_username: '{{ mssql_username }}' Credential_password: '{{ mssql_password }}' loop: "{{ [sql_server_svc_account, sql_server_agt_svc_account] | unique }}" Error Received failed: [<hostname>.<domain_name>] (item=<domain_name>\<Serviceaccount>) => { "ansible_loop_var": "item", "changed": false, "item": "<domain_name>\\<service_account>", "msg": "Resource 'SqlPermission' not found." } [<hostname>.<domain_name>] TASK: set_alwayson_perm : configure SQL server permissions (debug)> User interrupted execution. When we execute command Get-DscResource – Name SqlPermission, It errors out. I believe I am missing on some steps or configuration while doing DSC Module SQLServerDsc Please support.
New-M365DSCDeltaReport is not working as expected
Hello, I'm trying to use New-M365DSCDeltaReport to compare DSC exported configurations. But I wanted only different fields to show up in the output, so I used New-M365DSCDeltaReport -DriftOnly $true. Despite this I still get a full report with similar and different fields. Does anyone have an idea why this is happening?Azure Powershell DSC vs Ansible
Hey Guys, I just want to find out what are you using for Desired State Configuration on Azure. Do you use built in Powershell DSC or you are using Ansible with DSC enabled for Windows Machines? I am in the process of deciding which solution should the best for us. Also I would like to automate on-prem infrastructure. Which solution do you use? Regards, WojciechPowrshell DSC for Secondary/Additional IP
Hi Everyone, I am creating a Powershell script to deploy the configuration to the remote server using Desired State Configuration ( without Pull Server) for Adding the additional/Secondary IP to the server NIC but the module which I am using (xNetworking) is written such a way that It is removing the existing IP from the target Machine and then set the new IPs , which is making the server out of network. So can anyone help me to solve this in such a way it will only add the additional IPs and not change the exiting one. P. S. it needs to be done without Pull server only pushing the configuration is required.DSC error(s) deploying session hosts - Resolved
I had several issues with DSC Configuration failures , conflicts, client cannot connect to the destination specified etc. Was occurring with the Microsoft catalog and my own images. The last bit was after my firewall guys were certain it was not them. "VM has reported a failure when processing extension 'dscextension'. Error message: \\\"DSC Configuration 'AddSessionHost' completed with error(s). Following are the first few: The client cannot connect to the destination specified in the request." This is the workaround for me. Waiting on Microsoft support to weigh in see if it a bug etc. Test this in your lower environments! 🙂 Create a new VM from your disk template. I suggest you create a separate RG for workspaces. Disable IPv6 on nontunnel interfaces (except the loopback) and on IPv6 tunnel interface https://support.microsoft.com/en-us/help/929852/guidance-for-configuring-ipv6-in-windows-for-advanced-users use the fix it. Sysprep , genralize, OBE, shutdown. Convert the VHD to an Image (your mojo) $disk = Get-AzDisk -ResourceGroupName 'your-rg' -DiskName 'your-disk' $location = 'South Central US' $imageName = 'golden-image-name-ipv6-disabled' $rgName = 'your-rg' $imageConfig = New-AzImageConfig ` -Location $location $imageConfig = Set-AzImageOsDisk ` -Image $imageConfig ` -OsState Generalized ` -OsType Windows ` -ManagedDiskId $disk.Id $image = New-AzImage ` -ImageName $imageName ` -ResourceGroupName $rgName ` -Image $imageConfig Deploy new Host pool and Session hosts with the new imagePreview 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...
