Time Running Out for Azure AD and MSOL PowerShell Modules

Posted on by Tony Redmond

Last Gasp for Azure AD PowerShell Deprecation as June Deadline Approaches

Updated 16 June 2023

Microsoft’s original announcement about the deprecation of the Azure AD and Microsoft Online Services (MSOL) PowerShell modules goes back to 26 August, 2021. At that time, Microsoft wanted to have the retirement done by June 30, 2022. Customer pushback duly ensued and Microsoft decided to push the dates out another year to allow customers more time to upgrade their scripts.

Update: Microsoft has pushed the retirement out a further nine months to March 30, 2024.

This was the only sensible course of action. The Graph APIs for dealing with many Azure AD account interactions, especially license assignments, were sadly undocumented. The suggestion of using cmdlets from the Microsoft Graph PowerShell SDK ran into difficulties because the production version (V1.0) of cmdlets like Get-MgUser didn’t return license information. Allied to that, the documentation for the SDK cmdlets remains poor and inscrutable at times.

Time Helped Improve the Situation

Time is a great healer and allows for improvements to be made. The Graph Explorer works better and the Graph X-Ray tool reveals details about how Microsoft uses Graph calls in places like the Azure AD admin center (or rather, the Microsoft Entra admin center).

In addition, Microsoft developed documentation to help people migrate scripts, including a cmdlet map to translate old cmdlets to new. The important thing to realize here is that automatic translation from one set of cmdlets to the other is difficult. People code in PowerShell in different ways and it’s not always clear how to translate code to a new cmdlet. Some community-based projects do exist (here’s a new one that is spinning up), but any attempt to covert to SDK cmdlets must take the SDK foibles into consideration, like its fundamental disregard for the PowerShell pipeline.

But mostly time allowed people to share their knowledge about how to use SDK cmdlets to automate administrative tasks like user and group management. For instance, here’s a writeup I did about license management for Azure AD accounts using the SDK, and here’s another covering how to create a license report for Azure AD accounts.

What Will Happen Between Now and March 30, 2024

But time eventually runs out and we are now at the point where Microsoft is progressing the retirement of the Azure AD and MSOL modules. Here’s my understanding of the situation based on some discussions with Microsoft:

  • The licensing cmdlets from the Azure AD and MSOL modules do not work for tenants created after November 1, 2022. These tenants must use Graph APIs or SDK cmdlets to manage license assignments for Azure AD accounts.
  • For all tenants, March 31, 2023, marked the official retirement date for the licensing cmdlets in the Azure AD and MSOL modules.
  • Retirement doesn’t mean “stop working.” Instead, Microsoft now throttles cmdlets that assign licenses to Azure AD accounts so that they’re not as responsive as before. This is in line with the warning posted on July 29, 2022, that “Customers may notice performance delays as we approach the retirement deadline,” The affected cmdlets are:
    • Set-MsolUserLicenseSet-AzureADUserLicense
    • New-MsolUser (where the creation of an account includes a license assignment)
The Set-AzureADUserLicense cmdlet will stop working before June 30, 2023 Azure AD PowerShell deprecation
Figure 1: The Set-AzureADUserLicense cmdlet will stop working before June 30, 2023
  • From now on, Microsoft will increase the throttling rate to make the licensing cmdlets less attractive. Shortly, Microsoft will initiate short outages to gauge the effect of stopping the cmdlets completely. Doing this allows Microsoft to understand if any major pain is caused to customers.
  • Before or on June 30, 2023, the licensing cmdlets “will no longer receive a successful response.” In other words, no throttling, no short delays, just nothing. The exact date when the shut-off happens depends on the information Microsoft gains about customer usage. What’s for sure is that the licensing cmdlets in the Azure AD and MSOL modules will stop working soon.
  • After June 30, 2023, the Azure AD and MSOL modules are unsupported. Cmdlets may still run, but no guarantees exist that they will be successful. Given that the modules have been around for many years, you could anticipate that the cmdlets that don’t interact with the Microsoft 365 licensing platform will be OK. You might be right, but you don’t know how long that state will last because the modules are officially retired.

The Bottom Line About Azure AD PowerShell Deprecation

The Azure AD and MSOL modules are now on borrowed time. If you haven’t already started to upgrade scripts to use the Graph APIs or the Microsoft Graph PowerShell SDK, scripts that use these modules could encounter an unpleasant failure very soon. It’s time to get busy to make sure that all scripts can run after June 30, 2023.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

18 Replies to “Time Running Out for Azure AD and MSOL PowerShell Modules”

  1. Have you figured out how to reset a user’s password and NOT force a password reset on first signon?

    Reply

      1. What you sent didn’t work on PowerShell 5.1. But it led me to another article that worked:
        https://learn.microsoft.com/en-us/graph/api/user-update?view=graph-rest-1.0&tabs=powershell#example-3-update-the-passwordprofile-of-a-user-to-reset-their-password

        $PasswordProfile = @{
        ForceChangePasswordNextSignIn = $false
        Password = “riverD@0404”
        }
        Update-MgUser -UserId $UserId -PasswordProfile $PasswordProfile

        Do you know why this worked better? I’m getting a permission error and the scopes I have should provide everything. User.ManageIdentities.All, User.EnableDisableAccount.All, User.ReadWrite.All, Directory.ReadWrite.All

        Not sure how to get the permissions to test this.

      2. The Microsoft documentation says (for using a password profile):

        In delegated access, the calling app must be assigned the Directory.AccessAsUser.All delegated permission on behalf of the signed-in user. In application-only access, the calling app must be assigned the User.ReadWrite.All application permission and at least the User Administrator Azure AD role.

        Are you doing this interactively or using a program (delegated or application)? That might account for the difference.

  2. Pingback: April 8, 2023 - Red-N Security

    1. There isn’t one yet. But that’s OK because Start-ADSyncSyncCycle doesn’t do anything with licenses, which is the first problem that people will run into. A replacement will come in due course.

      Reply

  4. Hi, Any solution for this ? I tried to apply license for all users in bulk in exchange, but its returning with error

    Set-MsolUserLicense : You have exceeded the maximum number of allowable transactions. Please try again later.
    At line:1 char:60
    + … | foreach {Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalNa …

    Reply

  5. I find myself *very* conflicted about Microsoft’s push to retire the Azure AD module and move to the Microsoft Graph modules. On the one hand, there are a few places where the Mg module solves major headaches with the Azure AD modules. On the other hand, the number of Mg modules that are still missing functionality (or force you to fall back to essentially interacting directly with the Graph API via PowerShell) are really frustrating. Multiple Mg modules are still basically unusable. . . and that’s without getting into the abysmal state of the documentation.

    It kinda feels like Microsoft is saying, “Helo! We’re going to take away some of your most useful tools shortly. However, don’t worry, we’re going to replace them with “new” tools, and the new tools will have features your current tools don’t have! Admittedly, many of those features don’t exist or don’t work yet. Also, some of the new tools aren’t actually usable tools yet, they’re just pictures of tools we’ll give you later. Probably. And, some of the tools are missing important pieces. Don’t worry, though; a hammer can still be useful, even if it doesn’t have a handle yet. And this drill will amaze you once we add the battery and drill bits! Also, we only have 12 pages out of the 500 page instruction manual written right now. You have until next week to stop using your existing tools (date subject to change at our whim).

    Reply

  6. Hi Sir, i was using this script for assign bulk user license but its now not working : —
    ====================================
    $AccountSkuId = “EXAMPLE:DESKLESSPACK”
    $UsageLocation = “GB”
    $Users = Import-Csv C:\Users\girin\OneDrive\Desktop\UPN.csv -delimiter “,”
    $Users | ForEach-Object {
    $_.UserPrincipalname
    Set-MsolUser -UserPrincipalName $_.UserPrincipalName -UsageLocation $UsageLocation
    Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -AddLicenses $AccountSkuId
    }

    ====================================

    Please can you help me to correct this script and share it back

    thanks

    Reply

    1. I imagine that you can do a search for “assign licenses with Microsoft Graph PowerShell SDK” and find articles to explain how to do what you want, including articles that I have written.

      Reply
  7. Pingback: Publishing Technical Web Sites Requires Editorial Oversight - RSSFeedsCloud

Leave a Reply

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