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

Microsoft - You guys do a good job of trying to keep everyone up to date and to try to not break things.  But things are constantly breaking\deprecated.  I know it's the nature of the beast.  But the deadlines keep changing and the notifications and details keep changing. And there are so many acronyms\terms and changing dates, it is easy to lose track of what is going on and "when" "what" might (or might not) be deprecated. 

And if writing code on these platforms\modules is only a part of an IT staff user's job responsibilities then they likely won't be tracking or understanding the changes and notifications as much as someone fully immersed in it (like you guys at Microsoft).  I am sure it is all very clear for Microsoft Engineers who are neck deep in this stuff every day.  But, for a lot of us, we have other responsibilities besides development on these platforms\modules.  And it is hard to keep track of it all.  Not an easy problem for Microsoft or their user community.

But I have a general idea\suggestion and then a few specific ideas.  Something like this seems do-able.  I hope you give it some consideration.

Wild General Idea

In addition to publishing detailed (later to be outdated) articles and notifications, would it be possible to communicate deprecation dates through the SDK, platform, app, or module itself?  Here are some ideas below. I offer these as ideas\suggestions that I hope might help, everyone.

Wild Idea #1 

Implement a mechanism in which we (Developers\Admins) are required to add or provide contact information (work email address\phone-texts?) within the 365 platform, SDK, app, or module, etc. itself.  Using Microsoft PowerShell Graph module as an example, maybe the Connect-MgGraph could require that a "Module Lifespan Notification Email" value already exist within a designated field in the 365 admin console.  If there is no value there, then Connect-MgGraph would not connect and then tell the user\developer why.  Or it could require the value as a parameter upon calling the Connect-MgGraph command.  Maybe something like: PS> Connect-MgGraph -LifespanNotificationEmail "email address removed for privacy reasons” And\or maybe offer text message to a phone number.  Something like: PS> Connect-MgGraph -LifespanNotificationTextPhone "xxx-xxx-xxxx".    If you offer both we could select both (or just one).  Using both would be something like:  

PS> Connect-MgGraph -LifespanNotificationEmail "email address removed for privacy reasons" -LifespanNotificationTextPhone "xxx-xxx-xxxx"

If we don't want to get notification every single time, add a parameter of -LifespanNotificationFrequency "Daily\Weekly\Monthly\Quarterly” value.

And if we want a repeated (same) notification to stop sending after a number of times: -LifespanNotificationsRepeatsStopAfter {integer value}

Then you guys could post a new deprecation or "Lifespan" date and notification that would be queried from this and then emailed and\or texted to the email address\phone from Microsoft.  Now this idea puts load on Microsoft for having to send out the notifications.  I think idea #2 is better.

Wild Idea #2

Create a command within the MgGraph module platform Like: Get-MgGraph-DeprecationDate and Get-MgGraph-DeprecationNotice.  These commands would query the date and notification that you guys update as they change (date gets moved back).  Then at least we could use these commands in our code\scripts to monitor the situation EVERY TIME THE CODE RUNS if we choose to.  Then, if the Get-MgGraph-DeprecationDate returns a date that is within a minimum number of days (a minimum that we set for ourselves in our code) we can have the code then call Get-MgGraph-DeprecationNotice and use that notification (and the date) to notify ourselves in whatever manner we want to.  We can code it to send us an email, send a text message, fire a flare off in the office (not recommended), zap us with an electric dog collar (also not recommended), or an automated cattle prod in our chair (also not recommended).  Whatever works for us.

Wild Idea #3

You could use Connect-MgGraph from idea #1 above like Get-MgGraph-DeprecationDate from #2 above.  What if Connect-MgGraph always returned an MgGraph-DeprecationDate?  Doing this forces IT developers to at least recognize and (if they are smart) check that date value for what it is.  Then their code could check that date and if it is within a certain timeframe then the code could call Get-MgGraph-DeprecationNotice to get more information.  Then we can use that information to notify ourselves however we want (see recommended and non-recommended notification methods in #2 above).

...

Note: Ideas #2 and #3 could even be written and released in production code to provide notification when the situation is detected.

Summary

In summary, I think it would help everyone (including Microsoft) if DeprecationDate and DepreciationNotification could be monitored as needed within the code itself for that platform\module\etc.  I think forcing the information back to the calling code like in idea #3 above is worth consideration also.  Thank you.

-Todd Albers

wturner123 LockTar The statement is correct, however, We will give customers ample time to migrate from Powershell. We are working on an extension period of AAD graph API usage to allow Powershell to continue working. More details to be communicated soon on migration documentation and tools.
.

Excellent question wturner123! The module can be around but if the cmdlets won't work, what is the point of it...

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?

Can I suggest that an appropriate banner/disclaimer/etc. be placed on the Azure-AD documentation so that psuedo-admins (i.e. those that are NOT following this space as closely) are alerted to this guidance/recommendation without having to comb through articles/blogs?  Or perhaps at least on the most commonly accessed docs pages, such as perhaps Connect-AzureAD?  https://docs.microsoft.com/en-us/powershell/module/azuread/connect-azuread?view=azureadps-2.0 

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.

I recently looked at the various PowerShell offerings for integrating with AzureAD, having previously used both MSOL and AzureAD integrations. I looked at the Microsoft Graph PowerShell SDK but at the time it was not suitable for me (I can't recall why, but I needed to create/update/delete AAD users, retrieve/restore deleted users, so probably in this area), so I wrote my own MSGraph PowerShell class instead. This works really well and I can extend it really easily for extra functions (like Groups, etc.) as I need to. The only thing missing is Exchange Online management in MS Graph (like adding/removing email addresses to/from users). I'd be very interested to hear when this is going to come onboard.

Happy to share my PowerShell MS Graph class if anyone wants it.

BTW I am managing 500,000 users in AzureAD using PowerShell, using MSOL (project initiated at the time only v1 of the PowerShell CmdLets were available).

I am now also managing 100,000 users in AzureAD using PowerShell using MSGraph (project initiated end of 2020).

When embarking on these projects I looked at the various offerings (SDK, modules, etc.) and currently MSGraph with a custom PowerShell class is the only way I can:

• Create/update/delete users
• Access the recycle bin (and restore users)
• Update custom attributes (schema extension) and Extension Attributes
• But still no Exchange Online functionality, e.g. add/remove email addresses

Ability to get/set default authentication method for MFA, please!  We can currently manipulate auth methods but can't change the default one, which makes it hard to migrate away from phone-based MFA to Authenticator.  Or a way to force delete the default.  Thanks!

I sincerely appreciate the hard work that developers do. That said, it is a shame that this is the 3r iteration of a API to interact with Azure, AzureAD and O365. I also hope that the data returned by MSOL CMDLETS makes it to this new API as many attributes of that data did not make it to the AzureAD powershell module (for example). 

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.