Automate and manage Azure AD tasks at scale with the Microsoft Graph PowerShell SDK

Hmm... it's quite frustrating that you never quite finish the job?

• We all started out writing PowerShell for the MSOL modules, and some stuff *still* requires that (like managing MFA)
• Then we all switched to the Azure AD modules, then the Azure AD modules which use MS Graph (like Get-AzureADMSGroup etc)
• Now we all have to switch to dedicated MS Graph modules...

Since each of these changes involves rewriting automation scripts, how long will it be until you decide to change everything again? My colleagues and I are quite tired of updating scripts to keep existing functionality when the previous modules work just fine...

Building on ChrisAtMaf 's comment above—how does your team plan to avoid history repeating itself with this endeavor quickly losing momentum and getting abandoned, where for example the Graph PowerShell SDK plateaus at ~90% of the functionality of the AzureAD module, and the AzureAD module with ~90% of the functionality of the MSOL module, leaving us in a position where we require all three modules long-term? The AzureAD module also had good intentions to replace the MSOL module, but that momentum died very quickly.

The AzureAD module has been neglected for quite some time, while all along still being considered the current and future module, with no comment on PowerShell 7 support, new releases but the release notes page now one year out of date despite multiple people flagging that issue and receiving acknowledgement, etc. Just being put on life support long before this post that acknowledges its end-of-life, and us being left with a poorly supported module for over a year with no ownership from Microsoft.

There also seems to be significant issues in how the Graph PowerShell SDK is structured, with some native API functionality being broken in the PowerShell SDK due to "translation layer" issues, and subsequent finger-pointing between teams for over six months. Example: Missing cmdlet: Remove-MgGroupMember. Curious how these underlying issues plan to be addressed—as this is exactly the kind of thing that would lead to that future where the Graph PowerShell SDK plateaus at ~90% and has to get put out of its misery a few years later.

Thank you for taking the time to publish and clarify the current roadmap.

Specifically in regards to users of the AzureAD module (clarify if I am wrong):

1. Their stated roadmap is to migrate to the Microsoft Graph SDK, there will not be an equivalent "AzureAD" module that will be rewritten to use MS Graph SDK
2. Some commandlets in Az are expected to be the "friendly" cmdlets, however today as far as I can tell these still use the legacy AzureAD Graph API, will these be updated to use MS Graph SDK? These will also be very limited compared to what is currently offered in the AzureAD module.
3. There will be no other development of "friendly" cmdlets, the Graph SDK will primarily be the autogenerated cmdlets, with guidance coming in the form of documentation and examples.

My concern is that the Graph SDK has been stated to be just that, a software SDK for powershell developers to develop against the graph SDK. This leaves "normal" administrators in a difficult position. Is Microsoft expecting that the "Az" small friendly command set is all that will be invested in making the SDK available to bridge the gap for these administrators?

If so, then is Microsoft expecting there to be community led efforts to build modules that translate the SDK direct calls into more "friendly" commands normally associated with the AzureAD module? If so then that may be a major problem, as a standard AzureAD administrator-level user will look at the new graph SDK commands, consider them extremely difficult to use or unintuitive, and stay on the AzureAD module or bail entirely to use a different solution.

ChrisAtMaf  JGrote  Petri-X ians-uleth chriswest-jnctn We acknowledge the inconsistencies across our PowerShell offering. Our platform has gone through significant changes, all aimed at offering more to our customers. With the advent of MS graph, we have invested more in customer experience. Currently, there is an ongoing effort to migrate the missing cmdlets and functionality in MSOL and AAD onto the MS graph PowerShell Module. For AzAD cmdlets they will be updated to work with MS Graph API. AAD will continue to be around for at least two more years, but with no more upgrades, i.e., to PowerShell 7, as the focus will be the Ms graph module. We are working on migration documentation that maps cmdlets in MSOL and AAD against the MS graph module to assist in migration. We will also introduce tools that will help in the migration, and we will communicate in a follow-up blog post soon.

dkimani Are you able to clarify the below point for me please? 

"AAD will continue to be around for at least two more years, but with no more upgrades, i.e., to PowerShell 7, as the focus will be the Ms graph module."

The article Azure Active Directory (Azure AD) Graph to Microsoft Graph migration FAQ - Microsoft Graph | Microsoft Docs states that "Azure AD Graph has been on a deprecation path since June 30, 2020, and will be retired on June 30, 2022. After June 30, 2022, your apps will no longer receive responses from the Azure AD Graph endpoint."

Surely this means that the AzureAd module will be unusable from this date, as the AAD Graph endpoint will no longer respond to any requests?

JGrote  #3 is incorrect.  The Identity engineering team is committed to continuing to invest in improving the "friendliness" of cmdlets available for managing AzureAD through the MS Graph SDK module. We want to ensure the community can participate and contribute in this effort, but that doesn't preclude our continued ownership for the end user experience.

I share your concern that if we don't do a good job here of making the MS Graph SDK module an experience at least as good as the AzureAD module (and hopefully better), we're doing a disservice to our customers.  I don't think we get to great overnight, but I believe we have a sustainable framework in place for continuous improvement.

Can you please reconcile these incongruent statements:
"Last year, we announced end of support plans for Azure Active Directory (Azure AD) Graph API in favor of Microsoft Graph."

"While we recommend that you use the Microsoft Graph PowerShell SDK for your Azure AD needs, the Azure PowerShell Module does support a small set of cmdlets to help manage identity features such as AzADUser, AzADGroup and AzADApplication."

Get-AzAdUser uses the legacy AzureAD API, you can see this if you turn on debugging stream output, you can clearly see it makes graph.windows.net calls. Will the AzAD cmdlets be updated to graph.microsoft.com?

dkimani thank you so very much, this kind of pointed clarification is exactly what we were hoping the initial blog post would be. We look forward to the follow-up blog post with the specific planned roadmap and thank you again for your hard work, we are aware it is no easy undertaking with such a vast api surface but nevertheless it is a necessity to ensure the PowerShell community can continue to be a first class citizen in the Azure and O365 space.

Many good comments here, including the 'roadmap' of how we will manage the environment, and the critical comments about abandoned efforts with MSOL and AzureAD.

My perspective is that Microsoft is chasing another "shiny ball" to create a new tool: MS Graph (well, a newer version of this tool).   It seems like new leader was hired, came in, and stopped work on (older/existing) projects, and moved onto their own project - of which, MS Graph is the most recent??   I get it - technology changes and we adapt; but as a system admin for 25 years, I can attest to the avalanche of changes that have come, and most all have definitely been welcomed and a huge benefit for the user population as a whole. 

However, it is not only frustrating and very annoying to know that this 3rd iteration has left a degree of 'incomplete solutions' in it's wake (aka, MSOL and Azure AD).  There is little confidence gained by some in this community, that we will see MS Graph completed before it is replaced by the next 'shiny ball' - and then we (as admins) will have a handful of different tools that are necessary to execute our jobs.  

So in short, I would like to emphasize that Graph should not be an API/SDK for developers.  Everyday admins are not developers and we just need a complete set of tools that manages the environment that WE THE CUSTOMER are buying from Microsoft.   I apologize for raining on this announcement - but it is hard to evangelize the next great thing, when the historical perspective tells us you will not finish before you move on to something else.   But good luck - we really are counting on you.

RicLewisIdentity Thank you for the response!

Since the MS Graph SDK modules are generally autogenerated with AutoRest, will there be a roadmap or vision for this plan? For instance, will these be enhancing the autorest commands with a bunch of extra "calculated parameters" that do friendlier things, or will it be a new "overlay" set of commands that use the "raw" commands on the backend? Will these be bundled into separate modules (e.g. Microsoft.Graph.AzureADFriendlyCommands) to deliniate their "bespoke" crafting so people know what's been "made with love" vs what's a raw SDK API autogeneration?

A follow-up blog post on what to at least tacitly expect here would be welcome, so the community can provide feedback. Again thank you for all the hard work that the identity team performs, the graph Powershell SDK has been very useful to provide a solid type system against which to perform graph tasks.