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