Introducing the Microsoft Entra PowerShell module

Well, something had to change given how well the transition to the Graph SDK was going. So I am glad to see some real improvements, though this is... unexpected, and confusing.

I would guess that one thing most administrators will be looking to see resolved is SDK-API finger pointing scenarios to come to an end. As in, the SDK not properly supporting a feature from the API, the SDK team pointing the finger at the API team, while the API team points the finger back at the SDK team, in an infinite loop while the SDK feature remains broken for months (or longer!) This doesn't seem to have the potential to address that, as it relies on the same imperfect API translation layer?

Will Microsoft Entra PowerShell use a pre-consented app like AzureAD or MSOnline modules?

No. Microsoft Entra PowerShell permissions aren't preauthorized, and users must request the specific app permissions needed. This granularity ensures that the application has only the necessary permissions, providing granular control over resource management.

I don't really buy this argument, not when you had the opportunity to do something better in this module. You developed a module with the understanding that the developer-focused modules were not meeting needs, and I would argue this was not tackled simply due to time or resources, and you fail to own up to that (further emphasized by the fact that you still require the API's parameter of TenantId.) Many administrators will simply connect with scope Organization.ReadWrite.All, and we all know it, so the granular permissions argument, in my mind, holds little water given the intention and target audience of this specific module. This is just lazy.

Also, cmdlets such as Get-EntraUser still use parameters with names like ObjectId, versus something more "human-readable" as you said would be the case like UserPrincipalName.

My final thought is why continue pushing this API translation layer so hard, when other Microsoft 365 teams continue not to go down this road? If it has proven to be this problematic, why write a new module that still incorporates most of what has failed? For example, the Teams and Exchange Online teams have PowerShell modules that do not rely on such a translation layer, and those modules work well, and are well received.

I mean, I get that you can't please everybody, but this is your solution? You should have just invested this time into improving the existing Graph SDK modules and their documentation, instead of just confusing everybody even more.