Windows Server OSConfig and DSCv3

Sorry to pile on the replies here, but my thought process is this:

• Many teams want cloud-agnostic tooling
• Azure is not the primary cloud of a lot of bleeding edge, software-dev first environments
• The one space Azure has a really solid lock on is US Government, because the Azure US Gov team goes through great lengths to get all of the necessary certifications for the cloud stack.
• Just by the nature of how bullet point 3 works above, it means that there's a good chance that Azure-first systems (the orchestration behind something like DSCv3) will have quite a bit of delay.

Therefore, with all those constraints, I feel like some of the teams at MS (whichever team it is, Windows probably?) needs a different strategy than "Azure first"--just like the PowerShell and .NET teams moved away from "Windows first/Windows Only" mindset.

A lightweight orchestration system included with the OS, enough to do some get/set/test of Config as Code with module and configuration distribution would be nice. Integrate portions of it (reporting/visibility) into Windows Admin Center.

This allows these features to be rolled out almost immediately across every scenario, including compliance scenarios (like ITAR, CUI environments, disconnected environments).

Meanwhile, if the Azure team wants to separately build their own system (such as Azure Machine config), they can do so. Maybe theirs is more robust, I dunno. Maybe they build in some wider automatic integrations.

I think it's a win/win all around, to be fair. It brings DSCv3 to the forefront, it encourages resource migration from PowerShell DSC to DSCv3 resources, it could integrate across a variety of environments: from disconnected ones, compliant environments, multiple clouds, and the Azure and/or Windows teams can work independently of each other.

I think what Steve and team did with DSCv3 is great, and I think helming that knowing they have a small team and little adoption takes a lot of....personal might. I also like how they listen to end users/customers (such as bicep language support).

Just need to get the rest of the Windows org to do the same.

I actually have a very practical reason for bringing it up, though. For $DayJob I work out of Azure Government and M365 GCC High, and pretty much anything Azure in that environment lags behind the commercial environment.

Hot patch for Azure Arc servers, for example, doesn't yet exist in the Azure US Government environment. This environment can sometimes lag the commercial Microsoft cloud services by quite a bit. As an example, I'm still missing some Intune functionality and it's been 6 years since I started working in that stack.

Thankfully, it DOES look like Azure Machine Configuration does exist in USGov (I just looked), which is nice. But it looks like on Windows that's still using PowerShell v2 and not v3. It seems it's using v3 for Linux, however.

So I worry the switch from v2 to v3 in USGov could be at least 12 months out on Windows, if not longer. It'll take however long for them to roll it out as a preview, then it has to hit GA, and then there's a multi-month lag time for it to hit the Azure Government environment.

So even using Microsoft tooling I'm stuck between a rock and a hard place.

I mean it is the reality of the world we live in :)