Azure AD: Change Management Simplified

As mentioned before, it's quite frustrating that the automation interfaces for Azure and Microsoft 365 are in a constant state of flux. As something to bear in mind, system administrators are not developers. We don't expect API calls etc to change every 5 minutes. In the past, Windows tools such as cmd.exe, VBScript and other automation instances have worked across all versions of Windows, with backwards compatibility a priority. When it comes to Microsoft 365 / Azure, we've been through four incomplete iterations:

• The MSOnline module, which is *still* required for stable access to MFA (support under Microsoft Graph is still in beta - I'm sorry, but having used beta endpoints in the past, they are subject to change at any point, so there's no point investing time in updating scripts until they are released to general availability.)
• The AzureAD module, which is buggy and often doesn't seem to support pipelining properly (try piping things into Get-AzureADUser, for example).
• The AzureAD module cmdlets which are identical to existing ones but use MS Graph (e.g. Get-AzureADMSGroup) and are necessary to get all functionality
• Now the plethora of MS Graph modules

Why do we have to keep updating our scripts to keep existing functionality working? Why can't you improve and evolve rather than continuously trying to reinvent the wheel?

We all know that it would be possible (although a fair amount of work) to ensure backwards compatibility for these modules - keep the modules the same, but update the back end to use Microsoft Graph. In the past this would have been Microsoft's approach (read Raymond Chen's 'The Old New Thing' for how much work Microsoft used to put in to avoid these kinds of issues in previous Windows releases). Not ensuring backwards compatibility is one of the mistakes that led to the huge backlash for products like Microsoft Vista. Indeed it seems that the Windows team still understand this - when will Microsoft's cloud services teams learn? By all means progress with new technologies like Microsoft Graph - but don't forget the backwards compatibility religion. It's why many of us continue to choose Microsoft products - but if that benefit is taken away, why should we remain?

dkimani Thanks for replying. I don't think you've really addressed my point about backwards compatibility - this will be a rare occasion when Microsoft completely breaks an automation process which was previously offered to system administrators to administer a system, breaking many scripts. I can't remember the last time you did this.

 'As part of the parity work, we are looking at both the MSOL (MSOnline) and Azure AD libraries of Azure AD cmdlets and mapping the functionality onto the MS Graph PowerShell SDK, to make sure that all scenarios are available. We have started working on a cmdlet map for MSOL vs Microsoft Graph PowerShell, and Azure AD Graph PowerShell vs Microsoft Graph PowerShell, as part of the migration documentation.'

Again, if Microsoft was following the route that it has followed in the past, and which happy and repeat customers have come to expect, you would be using that information to update MSOL and Azure AD libraries to keep them working with MS Graph in the background.

'Microsoft Graph cmdlets are autogenerated from the Microsoft Graph API schema. The process has many advantages, for example, providing a rich set of cmdlets that cover the whole API landscape. The disadvantage is that the resultant cmdlets may not be as user friendly, when compared to human authored cmdlets. Consequently, we are actively working on usability improvements of MS PS SDK cmdlets docs and examples and more tools on migration.'

This just shows that you've lost sight of the 80/20 rule. What you had before made it easy to use the 20% of functionality that 80% of PowerShell users actually need - and what you're doing now will make life harder for those 80% of people - your 'gain' being complete API coverage for the 20% minority who need the remaining functionality. Come on guys. PowerShell is a sysadmin tool first and foremost, and most sysadmins only need to use a tiny subset of MS Graph functionality (managing users, groups, licenses, MFA) which is already covered by relatively easy-to-use MSOL and AzureAD modules. You should be maintaining those modules, and only expecting the minority who need the full functionality of MS Graph to use the new cmdlets - which in your own words are 'rich' but 'not as user friendly'. Extra hint - most of that minority will be developers, who don't access Graph via PowerShell anyway. This is basic stuff.

Further to my comment above, announcing the deprecation of the MSOL and Azure modules in December 2022 when there are still known limitations and key functionality still in beta, and you haven't even written the guidance and tools for migrating existing scripts to the product intended to replace them, is just disrespectful to your customer's patience and time.

> the planned deprecation of the two PowerShell

> modules (MSOL & AAD) after December 2022

Does this mean we will finally be able to access default MFA method through other means besides the MSOL module sometime soon? The most recent update that I've seen was a change to the docs that indicates the MSOL module is the only way to get/set this info.

Rapid change is a growing reality in cloud services. In Azure AD alone, we are making hundreds of changes every year including new feature releases, changes to existing features, as well as deprecations and retirements. We’ve heard from our customers that managing these changes is becoming increasingly difficult so, starting today, we are simplifying change management for Azure AD.

If your customers are telling you your change rate is becoming increasingly difficult, why continue with the same path?  Arrogance?  Delaying a change does not simplify the change.  

You, Microsoft, are not making my job easier.  In fact, you're making it more difficult.  I often feel like it's a one step forward, two steps back type of situation.  Sure, some improvements are made that should help me.  However, those improvements are then nullified with changes such as the planned deprecation of MSOL, when you don't have full functionality in the planned replacement.  How can you expect anything other than criticism from those of us who depend on that which you plan to deprecate when you don't have a viable solution available?  Arrogance?

I don't think you understand the constraints many of us have.  I don't have staff to try to keep pace with the change rate Microsoft seems to believe is acceptable in what I think is core functionality.  If I don't have staff for that, I certainly don't have it to keep checking if you've finally made necessary functionality available in Microsoft Graph PowerShell.  So, I'll most likely experience a negative impact once you make it impossible for me to use MSOL.

Your software should make my job easier.  Your business practices should do the same.

Microsoft,

• Please do not deprecate any PowerShell module until a full functional bug free replacement solution is available.
• Additionally, while the cmdlets mapping list mentioned by dkimani helps, I would expect a full automated script conversion tool to be released by Microsoft for System Administrators (load script > run > outputs new script ready to go); expecting us to code again such a large number of PS scripts running in production (Automation Accounts runbooks, Azure Functions, Power Automate, etc.) is unrealistic, very frustrating, and will end up breaking a lot of your customers production environments. 
• "deprecation of the two PowerShell modules (MSOL & AAD) after December 2022."  - Does it mean it will stop working or just stop being supported and updated?
• What about the Az modules?

Thank you.

Retiring a functional module and replacing it with a new module without the same functionality is a step backwards. I am frequently encountering this mindset. And, when I try to report the problem, support doesn't know how to find the right person to help me with the issue (no personal experience with graph. Yet). When we do eventually find someone who claims to be the right person the give a curt, "that is by design"

What does by design mean?

Microsoft knows it's an issue and does not plan to fix it?

That's not by design, that's a bug tagged as "won't fix"

You don't think it's an issue and the feature is working as intended?

That's not by design, that's removing a feature between versions without notification.

You don't want to talk to me, and this is the quickest way to get me to close the ticket?

That's not by design, that's not doing your job.

Sometimes I'm not sure if Microsoft's idea is to drive regular administrators into madness and then make MS admins irreplaceable when no others are left. Or more realistic reason behind of this could also be, they do have many different teams and management has forced teams to fight against each others. When one team lose, the backward compatibility is lost as that team is not needed anymore.

If you read this change and then read (+ comments) what they have planned to do on Exchange Online: Change in naming convention of user’s Name parameter you can see very similar behavior. Suddenly someone though to reassign one attribute to other use. And once more thousands of admins are forced to look if their scripts are depended to that attribute. Attribute name is "Name", so you can believe it could be widely used.

More and more all of this start look like, nobody is pulling the van to the same direction. Everybody is just trying to get glory to their own only.

Sometimes I have also asked from myself, do we actually have administrators who are managing O365/Azure services using PS after 5-10 years? How does Google, Apple or Amazon do this, as they have no PS modules(?). Are we the last once? 

Would be nice to have an option to disable the Azure AD Graph API in an environment and if needed enable it again. So we can make shure we don't mis anything and if so can use the time to correct it and try/disable the API again.

Hi Team

Shouldn't this: "We will enable combined MFA and SSPR security information registration for enabled tenants created before Aug 2020. More information on this experience can be found here: " actually read "We will enable combined MFA and SSPR security information registration for all non-enabled tenants created before Aug 2020. More information on this experience can be found here" 

I'm assuming that this statement is meant to mean that all tenants created before Aug 2020 will have the feature enabled automatically by Microsoft on the backend. Or do I have it wrong.?