[JeffreySnover]

That's not quite right. We have always focused on CUSTOMER success.

You are right that there is self interest in that (as Satya likes to say - it is hard to be successful if your customers aren't succeeding) but the PowerShell team has NEVER been confused about what the high order bit is.

Without going down the rabbit hole, I'll just point to the fact that our launch partners for PS Core were: - AWS - GCE - VMWARE

Jeffrey Snover [MSFT]

[jiggawatts]

Meanwhile PowerShell 6 was basically useless for Windows automation. Even PS7 has open issues for Windows or backwards-compat with PS5. A random example: https://github.com/PowerShell/PowerShell/issues/12027

Generally the impression I have is that PowerShell development effort after v5.1 was 100% cloud-focused, and all Windows-native development stopped dead in the water. All videos and examples of PS6+ I saw were about cloud automation and Linux support.

If you would like to dispel my misconception, answer me this: Why has the PowerShell team not fixed any of the long-standing bugs in the Windows Server modules?

For example:

    Get-ADUser 'nonexistent' -ErrorAction:SilentlyContinue

has been broken since like... forever.

While we're here, how about the fun fact that "Set-Mailbox" doesn't have -WhatIf support, because who needs safety, anyway!? Or how if the very same command fails to find the specified mailbox it helpfully applies the change to the first 1000 users in your organisation instead. Clearly I wanted everyone to have the same surname with no rollback other than a full D/R restore. Fun times.

[SteveL-MSFT]

The PowerShell team doesn't own most of the modules that are shipped in Windows Server. Windows Server is a big project that takes many teams to work together to produce. In your specific example, the AD team owns that module. Set-Mailbox issues need to be sent to the Exchange team. I know you may not like that answer, but it's not feasible for a single team to own so many cmdlets that require different domain expertise.

[jiggawatts]

Excuses.

Nothing stops the PowerShell team from validating module behaviour against a set of standards and best-practices. Just because a module was authored elsewhere in Microsoft doesn't mean that you can't create issue tickets to get everything up to a baseline level.

I don't mean write their code for them. But it would be huge step up in perceived end-user quality of PowerShell in general if simply all Microsoft modules correctly supported -ErrorAction and -WhatIf. Similarly, support for PowerShell Core should have been fixed for all major modules long ago.

Microsoft created PowerShell and Microsoft created the Windows Server modules. From our perspective on the outside there is only Microsoft. We don't care about your internal politics. We do care about 1K mailboxes being irreversibly damaged.

Our perception is that third-party ISVs do a better job at writing PowerShell modules than Microsoft. Half the time I spend teaching PowerShell to customers is listing the many, many ways Microsoft violates their own rules and all the fiddly little workarounds required.

Meanwhile I just tested Pwsh 7 to see how well it works, and my first experience is that Connect-AzureAd fails because it uses the non-core SHA256Cng class instead of SHA256, so it can't connect unless I use a "preview" version from outside the PowerShell gallery. Nobody in their right mind would use preview code from a non-standard source to manage thousands of accounts in production. See: https://github.com/PowerShell/PowerShell/issues/10473#issuec...

I can't do "Microsoft things" with the "Microsoft shell", which renders Pwsh 7 useless to me and my customers. As far as I'm concerned, Pwsh 6, 6.1, 7, and most like 7.1 exist only to enable Linux and Mac users to automate Azure Resource Manager. Outside of that, most "Microsoft" things do not seem to work...