Yes and no. Having used DSC and powershell remoting extensively, these create as many problems as they solve. Nothing works smoothly. Not a thing.

The saving grace here will be SSH because then at least we can drive all our kit across both platforms from Ansible and be done with the entire MSFT management stack.

At the moment we use Ansible but it runs over WinRM which is completely unreliable due to some architectural problems with how WinRM works.

Really, automation on Windows is extremely costly compared to Linux. I've got to the point I never want to run Windows infrastructure again.

Before anyone says "it's getting better". That has been the case from 10 years and it only got different.

> Really, automation on Windows is extremely costly compared to Linux

I'd disagree. I've been managing fleets of Windows machines since NT 3.51 (and fleets of Linux servers since 2003). It's all about knowing the tools well.

Whilst I've been using Linux since around 1995 (Slackware!), and prior to that various Unix and Xenix(!) boxes had popped in and out of my IT life, I'd never managed more than one or two machines. That was until 2003'ish when I went to work for a shared hoster. It took me a while to become as proficient at managing all these new Linux boxes that entered into my life as I was with Windows. I had the learn the tools.

I'm not suggesting you weren't properly trained, but most of the complaints I hear about Windows being a devil to manage is usually because admins haven't learned how to use the tools and generally haven't a clue what they're doing.

I've been in this since Netware for MSDOS. Your last point is valid in most circumstances but the issues are technical and not with staffing or skill level. I'll outline some of the technical issues I have, with my skill set which covers large scale deployments:

1. Remote management is totally unreliable. If I point DSC at 20 nodes via WinRM, 25% of the time it will fail on one of the nodes.

2. Everything takes glacial amounts of time to happen, from deployment and provisioning to simple cases like restarting processes. This is because Windows is simply so damn large.

3. There are so many edge cases and bits of tribal knowledge dotted all over stackoverflow which is sometimes the only way of finding out what the hell is going on, it's impossible to cover all of them through automation and nigh on impossible to document the rationale behind them.

4. Literally everything is stateful and state is difficult to synchronise and reload.

5. The disparity between major platform releases makes it extremely difficult to develop automation that isn't brittle and can span major windows versions. And because everything has all of the other concerns from coupling to bugs it's impossible to chop big chunks of your infrastructure over to new windows server versions. So you end up in permanent migration mode.

6. The sheer amount of bugs in some of the larger products like SCCM and SCVMM are just unbearable. SCVMM client for linux is a pile of shit and I'm being polite there.

All of these cost immense amount of wall clock time and staff attention which far outweighs the cost benefit of using the platform to start with at least from an application server business.

On the desktop, things are slightly better as it's the least bad desktop platform for corporates but that's changing. Even Microsoft know that which is why they are forcing people down the cloud route and selling subscriptions.

For managing desktops and not servers, Group Policy is still unbeaten. I have yet to see a unified strategy on Linux of being able to say, mount these drives on logon, show these applications, don't allow them to do x, change the background to y etc.

Sure, managing linux servers is a doddle, but desktop environments are miles harder to get right.

Having managed desktop windows deployments, I sort of agree. They work pretty well up to a point and that point stops when you have to introduce change control. Eventually all the little hacks, GPO scripts and stuff piles up and up and up and then there's a task like "migrate one AD node to 2016" and this turns into a 2 month project unpicking all the hell.

That is what every single Windows environment I've seen turns into, including the SCCM powered and Microsoft direct consultancy managed ones.

You mean something like https://fleet-commander.org/ ?

>I've got to the point I never want to run Windows infrastructure again. Before anyone says "it's getting better". That has been the case from 10 years and it only got different.

i know what you mean. It's part of the reason I'm on the cusp of discarding my 20ish years of MS SQL Server experience and going full Postie for the rest of my life. Windows IT infrastructure in most enterprises is a pile of lies. It's particularly galling in academia and non-profit because they can't afford to keep up with all the Microsoftia and yet still the management dreams of using Microsoft StudlyWare which would require 10x the IT cost they could ever dream of, let alone get.

It is lies. Exactly that. The thing that gets me is that a lot of it blatantly just doesn't work. You walk in, are sold an ideal, walk out, get to work and find out you're suddenly wading in shit.

But people are totally 100% happy with that in some circumstances. They are happy with lower mediocrity because simply the vendor in question has got away with it for so many years that it is now the status quo.

If I bought a Tesla and it behaved like the average windows machine I'd drive it back through the fucking dealer's window.

Simply I demand better and I demand what I paid for.

Desired State Configuration is not supported by PowerShell Core v6, even on Windows. DSC is only supported by PowerShell v5 and earlier. This suggests to me that DSC has been abandoned

In contrast, .NET Core supports various old Windows-only features, such as COM and soon WinForms.