Microsoft Sets March 2025 Date for Retirement of Old Azure AD PowerShell Modules

Yet Another Extension to Allow Customers to Convert Scripts

In September 2022, Microsoft set a new retirement schedule for the AzureAD, AzureADPreview, and Microsoft Online Services (MSOL) PowerShell modules. 30 June 2023 seemed to allow sufficient time for customers to migrate scripts from using these modules to the Microsoft Graph PowerShell SDK or Graph APIs.

June 2023 wasn’t the original date chosen by Microsoft. In their original June 2020 announcement about the retirement, they had set a target of June 30, 2022, later adjusted to the end of December 2022.

Now, Microsoft is really serious about retiring these modules. According to a Microsoft Technical Community blog posted on June 15, the new deprecation date for the three modules is March 30, 2024. The exception is for cmdlets that assign licenses to Azure AD accounts, like Set-AzureADUserLicense and Set-MsolUserLicense. These cmdlets are retired and unavailable in tenants created after November 2022. An exception exists for some customers who negotiated an extension with Microsoft to the end of September 2023. There have been many reports of these cmdlets becoming unreliable or non-functional due to Microsoft throttling to underline the point that this code is on the way out. Microsoft will finally retire the MSOL, AzureAD, and AzureADPreview modules on March 30, 2025.

To avoid the potential of cmdlet failure, scripts that depend on license assignment, such as the creation of new Azure AD user accounts, should now use the licensing cmdlets from the Microsoft Graph PowerShell SDK.

Challenges Moving to the Graph

Much as I like the Microsoft Graph PowerShell SDK and my hard-won semi-proficient knowledge of the Microsoft Graph, it’s unsurprising that Microsoft has extended the retirement date by another nine months. The simple fact is that migration to use the SDK cmdlets is not automatic and requires effort to identify, recode, and test scripts. Properties and methods have changed, filtering is different, and it’s not always easy to decide how to upgrade code.

Permissions are another aspect that developers and administrators need to wrap their minds around. When you run the Connect-AzureAD cmdlet to connect to Azure AD, the permissions and roles held by the signed-in account apply. If the account is a tenant administrator, they can do anything. The same doesn’t apply when working with the Graph. A granular permissions model exists, and a script must have consent to use the exact permissions necessary to access whatever data it needs to work with. It’s further complicated by the differences between delegate permissions (acting as a signed-in user) and application permissions (background processes and similar). Figuring out what permissions to request can take time.

A further complication exists in the difference between interactive and application access for scripts using cmdlets from the Microsoft Graph PowerShell SDK. All Graph apps, including those like the very useful Graph Explorer, use service principals to hold permissions. Used interactively, the service principal for the Graph SDK tends to accrue permissions over time to become a highly permissioned app. That’s something to watch for.

V2.0 of the Microsoft PowerShell Graph SDK

Another issue is the plans Microsoft has for V2.0 of the Microsoft Graph PowerShell SDK. Although many useful and welcome improvements are included, the current plan is to split cmdlets into two sets: one to interact with the Graph V1.0 endpoint, the other to interact with the beta endpoint. In the V1 SDK, the cmdlet names don’t change as switching endpoints is done with the Select-MgProfile cmdlet. The proposal is that the set of cmdlets for each endpoint will have different names, which obviously poses another migration challenge to find scripts that use the beta endpoint and update the cmdlet names.

You might not think that the beta cmdlets are used much, but they are. The change to the SDK means that you need to check every script created using the SDK cmdlets to make sure that code will run smoothly after the changeover.

Heading to March 2024

Will Microsoft succeed in retiring the AzureAD, AzureADPreview, and MSOL modules next March? I think so. Nine months seems achievable. The constant rescheduling of the retirement date is becoming embarrassing and some parts, like the cmdlets for license assignment, are already retired. But, as we’ve seen already, customer pressure can force change.

The upside about the delay is the chance to develop even more community resources to help people make the transition. The issues working with the Microsoft Graph PowerShell SDK cmdlets are well-known and many articles, blogs, and forums are available to help people understand how to interact with the Graph. Shared knowledge and experience are critical factors to help people convert old scripts to embrace the Graph.

On the downside, it’s bemusing to see that some sites continue to publish outdated information (here’s an example) which might convince people to make the wrong decisions. The authors of those articles must not have received the memo about the module deprecation. Maybe they’ll realize what’s happening now.