|
|
|
|
|
|
by SteveL-MSFT
2299 days ago
|
|
|
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. |
|
|
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...