Microsoft Lays Out Future for Azure AD PowerShell Module

Microsoft Graph PowerShell SDK is the Future

For anyone who’s ever used the Azure AD or Microsoft Online Services (MSOL) PowerShell modules to write PowerShell code to automate some aspect of tenant administration, Microsoft’s June 2 announcement about their future direction for Azure AD PowerShell was big news. In a nutshell, Microsoft is focusing on the Graph APIs for identity management. As a consequence, any software which leverages the Azure AD Graph API, like the Azure AD module, is on the runway to deprecation.

Important Points for the Next Year

Last year, Microsoft announced that they would no longer support or provide security updates for the Azure AD Graph API after 30 June 2022. Now they are being more specific about what this end of support decision means for customers. The following points are important:

  • Microsoft’s future investments for identity management are focused on the Microsoft Graph SDK for PowerShell. This is a wrapper around the Graph APIs and is already in use for purposes like setting tenant privacy options for the Insights API.
  • The Azure AD and MSOL modules will not be supported for PowerShell 7.
  • New identity APIs will be available through the Microsoft Graph PowerShell SDK (Figure 1).
  • Microsoft’s investments will center on user, group, and application management, plus role-based access control (RBAC), which is important in terms of making sure that administrators don’t need all-powerful permissions to get work done. Microsoft 365 uses an increasing number of role groups to assign administrative work to different accounts.
  • Microsoft also says that they will invest in usability for the Microsoft Graph PowerShell SDK, which is a good thing because the SDK cmdlets aren’t quite as approachable as those in other modules. The documentation is not in good shape either. See my articles covering basic Azure AD user account management and group management for details.

 Connecting to the Microsoft Graph PowerShell SDK
Figure 1: Connecting to the Microsoft Graph PowerShell SDK

Microsoft says that their goal is that “every Azure AD feature has an API in Microsoft Graph so you can administer Azure AD through the Microsoft Graph API or Microsoft Graph SDK for PowerShell.” They don’t say that every feature will be accessible through the Microsoft Graph PowerShell SDK. In some cases, you’ll need to run pure Graph API calls, but that’s easily done using PowerShell (for an example, see this article on accessing Azure AD access reviews from PowerShell.

Update August 1, 2022: Microsoft has pushed out the previously announced retirement date for the license management cmdlets in the Azure AD and MSOL modules (August 26, 2022) to March 31, 2023. They have delayed the retirement of the Azure AD Graph API until the end of 2022 to give customers extra time to adjust.

It’s Different With the Graph

The net takeaway is that tenants need to review any PowerShell scripts which use the Azure AD or MSOL modules to prepare plans to upgrade scripts to use the Microsoft Graph PowerShell SDK or Graph API calls in the future. Given the number of Office 365 tenants, the pervasive use of PowerShell to automate operations, and the core position of Azure AD in those operations, it’s likely that millions of scripts will need upgrades. I know that I have a bunch of scripts to review and will discuss how the upgrade process proceeds in future articles. Already, I know it won’t be simply a case of replacing all occurrences of Azure AD cmdlets with equivalent Graph SDK calls, like replacing Get-AzureADUser with Get-MgUser. Parameters and output are likely to be different and code will need to be adjusted to cope.

While upgrading scripts is a big job, each script is a one-time activity. Interactive access is another issue. Today, it’s easy to run Connect-AzureAD to connect to Azure AD and then run whatever cmdlets you need to interrogate the directory. The equivalent actions with the SDK are:

First, you connect to the Graph and set the scope (permissions) needed to interact with Azure AD. Unless a suitable access token is available, this starts a device authentication sequence.

Connect-MgGraph -Scopes "User.Read.All","Group.ReadWrite.All"
To sign in, use a web browser to open the page and enter the code D7DPGD3WL to authenticate.

Opening a web page and inputting the code causes another dialog to appear to confirm consent for the operation (Figure 2).

App consent required to use the Microsoft Graph PowerShell SDK
Figure 2: App consent required to use the Microsoft Graph PowerShell SDK

After consent is granted, you can then go ahead and issue commands. For example, here’s how to fetch a list of guest accounts:

$Guests = Get-MgUser -Filter "UserType eq 'Guest'"

Like most Graph commands, the amount of data returned is constrained to 100 items, so if you want more, you need to specify the All parameter.

The bottom line is that some more up-front thought is needed (to set permissions) before connecting to the Graph SDK and that the authentication flow is not as seamless as it is when running Connect-AzureAD. No doubt this is an area where Microsoft might look at to remove some rough edges.

Time to Prepare Upgrades

Losing support for the Azure AD and MSOL modules sometime in 2022 is a concern, but we’ve seen other instances when Microsoft has extended support to allow customers extra time to get work done, and anyway, losing support doesn’t mean that code will suddenly stop working. Scripts will continue to run. You just won’t be able to ask Microsoft to fix bugs.

One thing you can guarantee in the cloud is that change happens. This is just another example of how that change occurs.

The Office 365 for IT Pros team will document our learning with upgrading PowerShell scripts from the Azure AD module to use the Microsoft Graph PowerShell SDK in the months ago. It should be fun… Subscribe now to make sure that you stay abreast of developments.

12 Replies to “Microsoft Lays Out Future for Azure AD PowerShell Module”

  1. I am admittedly not an expert here, however I am finding some contradictory evidence to the statement “As a consequence, any software which leverages the Azure AD Graph API, like the Azure AD module, is on the runway to deprecation.”. Does the AzureAD powershell library definitely use the Graph library under the hood? This other reference is saying that the pure powershell library is not being deprecated and eludes to some confusion over the deprecation of the Powershell Graph API instead. It then references this post on the Azure AD powershell github page that tells us that AzureAD powershell is not abandonware

    1. I don’t think Microsoft will abandon the Azure AD PowerShell module. Instead, I think they will put it into maintenance mode and eventually deprecate it.

      The first obvious change will happen in late June 2022 when the cmdlets which deal with licenses stop working. This is because Microsoft is moving to a new license management platform (see The new license management capabilities will be available through the Microsoft Graph SDK for PowerShell, as per the statement made by Alex Simon in He also says there that the Azure AD module won’t work on PowerShell 7.

      Microsoft Azure AD development is putting its weight being the SDK. That’s not abandonment of the current module. It’s more like favoring one child over another.

  2. According to:

    The picture seems much more dire than an eventual depreciation – sounds like all AzureAD-Graph-dependant code will stop working after June 30, 2022, and doesn’t the AzureAD powershell module use the AzureAD Graph API?

    “Azure Active Directory (Azure AD) Graph is deprecated. To avoid loss of functionality, migrate your applications to Microsoft Graph before June 30, 2022 when Azure AD Graph API endpoints will stop responding to requests.

    Microsoft will continue technical support and apply security fixes for Azure AD Graph until June 30, 2022 when all functionality and support will end. If you fail to migrate your applications to Microsoft Graph before June 30, 2022, you put their functionality and stability at risk.”

    1. I imagine that things will be a little less serious than that… I imagine that everything (except license management) will continue working for quite a while after the deprecation. But that’s no excuse to avoid the necessity to upgrade scripts before the axe descends.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.