I’m the “PowerShell guru” at work and I really want to get into DSC, but there’s always some basic product issue holding me back.
What worries me is that Microsoft is pushing DSC as an alternative to Group Policy but this is like saying C# is an alternative to Excel. Sure, technically you can sum up tabular data with both but the user experience is not even remotely the same.
Everything I have found in the past related to DSC boiled down to “you can write your own things using this baroque nonstandard system” which doesn’t appeal to me. I’d rather write a script or tick a checkbox in a GPO. The in between space occupied by DSC doesn’t feel like a good fit for anyone.
Worse, DSC was always a half-baked solution made by a tiny team. This new version seems extra underfunded. There’s no documentation to speak of! I can’t even find what operating systems they support, for example.
I want declarative state configuration as a concept, but I don’t think PowerShell DSC can deliver this. The industry has moved on to container images, scale set images, and monolithic executables as produced by dotnet and go.
Yep, DSC is cool, if it fits exactly your use case its very cool, and generally it seems like a huge PITA to manage on any level and nobody uses it but very expert level powershell people doing DoD stuff or similar.
The exact use case is if you have to deploy slightly customized windows installs on a daily basis.
You know you need it when you have a document that details all the steps in setting up windows itself and a couple of common softwares. Then someone ham fists something every once in a while and causes confusion for everyone.
The Alternatives MS provides to Group Policy are SCCM compliance, intune compliance and Settings Catalog via Intune. GP sucks and I think anything else is better, especially with it's weird double negatives in setting descriptions and names.
1. I'm loosely following the development for DSC (v3 or v2-tooling) and never have I heard Steve Lee, Michael Greene or Michael Lombardi advocate DSC as an alternative to GPOs.
2. How do you get to the conclusion that DSC is a non-standard system. What's your point of reference with that statement? I am not aware of any standard out there, but I'd love to be educated. I have the same question about the baroque-statement. Yes, DSC is old, but so are Chef and Puppet.
3. Why do you say DSC is half-baked? It was never intended to be an Alternative to Chef and Puppet, if that is what you're comparing it to. It's intended as a foundation for tools like Chef and Puppet.
3a. You want declarative state as a concept and that is exactly what DSC delivers.
4. The industry has not moved on to container images. These are two separate "movements" and there still is very much a need for bare-metal services. And this is still very prevalent with Microsoft services like AD, Exchange, SharePoint, SQL, or other Software like Veeam, ... I don't understand once more what your point of reference is with this statement.
The only part where I agree is that DSC is underfunded. That is factually true with v2, where in fact it wasn't funded at all for a decade. I believe DSC v3 is backed by Microsoft with a small budget, but it still isn't clear to me what the end goal is.
I think it is a good decision to remove the need to compile into MOF, which simplifies a lot of the process. At the same time I wonder why they would remove the LCM, which complicates the entire process of having state re+applied to a machine when it deviates locally.
And then of course, DSC v3 still doesn't do much if there's no tooling around it. Azure has configuration management based on DSC, but it is a pain to learn and to configure in my experience. I really, really wish Microsoft would have a holistic approach, but my impression is that they don't and just fiddle around individual components, without a clear picture of the desired end result.
> DSCv3 doesn't depend on PowerShell. You can use DSCv3 without PowerShell installed
So what's the point of PowerShell if most new CLI tools from Microsoft aren't PS modules and can't take advantage of the .NET object model, even on Windows (see also winget)? Why is DSCv3 under the powershell organisation if it's just a regular Rust CLI?
I see now that not all the PS files are for tests, there's one adapter PS module for compatibility.
But that's still damning: If Microsoft themselves are building their PS modules as ConvertTo/From-Json wrappers for native CLIs (or being shipped at all, like winget's PS module), instead of shipping C# cmdlets and a domain model for .NET, then PowerShell is superfluous and we should be dropping it, even on Windows, for a JSON-aware shell or a more common shell with tools like jq.
PSConf EU happened a few weeks ago, and Steve Lee the project manager for PowerShell, DSC, Windows OpenSSH, gave a talk on DSC v3 which is available on YouTube:
When our team moved to Office 365, we wanted something declarative, and the only option was [Microsoft365DSC](https://microsoft365dsc.com/).
We of course tried it, but the experience is subpar, went through hoops to set it up on Windows (no Linux, Mac support) and the output was a mix of imperative code and declarative specs, with GUI tool to help you manage.
Seriously hope some Microsoft expert will create a Terraform provider for Microsoft 365. currently we have to use the Office 365 sluggish admin dashboards.
Nice, very nice... I'm glad this exists, given Microsoft's bullish attitude towards migrating everyone to their cloud. I think projects like this one will help those of us who will remain off their cloud as long as possible. I think this software would go well deployed to on-prem installations of netboot.xyz.
No, it's a configuration management tool (similar to Salt, Puppet & Chef) where you declare what you want the end result to be and it takes care of the rest. I used v1 a long time ago, but moved to Salt shortly after and now we do everything in Terraform.
The thing is, Chef and friends aren't declarative at all. They're imperative scripts cosplaying in declarative-ish syntax. The more you use it, the more it begins to look like a complex bash script with way too many levels of indirection.
The previous iteration got killed right when it could have started gaining traction due to Microsoft's shift to "cross platform" and PowerShell Core.
The previous iteration of the Local Configuration Manager for Linux was written Python while the Windows version was a distinct codebase entirely.
But even regardless of that I have zero confidence that Microsoft can break into this space and that the Windows culture would shift in this direction. The mentality is just not there with the typical (majority of) admins.
I use a Chef setup based on how Airbnb did config management in 2013. It ain’t broke, and Ruby is an amazing language for DSLs like system configuration. I never got along with Puppet because I’m annoyed I can’t use Ruby for everything.
DSC has a really really wide variety of windows modules and unfortunately there isn't really anything comparable, Puppet and Ansible do have interfaces to DSC modules but it's kind of janky compared to just using DSC.
What worries me is that Microsoft is pushing DSC as an alternative to Group Policy but this is like saying C# is an alternative to Excel. Sure, technically you can sum up tabular data with both but the user experience is not even remotely the same.
Everything I have found in the past related to DSC boiled down to “you can write your own things using this baroque nonstandard system” which doesn’t appeal to me. I’d rather write a script or tick a checkbox in a GPO. The in between space occupied by DSC doesn’t feel like a good fit for anyone.
Worse, DSC was always a half-baked solution made by a tiny team. This new version seems extra underfunded. There’s no documentation to speak of! I can’t even find what operating systems they support, for example.
I want declarative state configuration as a concept, but I don’t think PowerShell DSC can deliver this. The industry has moved on to container images, scale set images, and monolithic executables as produced by dotnet and go.