Table of Contents
Last Gasp for AzureAD PowerShell Retirement as Deadline Approaches
Updated 2 April 2024
Microsoft’s original announcement about the deprecation of the AzureAD 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. They subsequently deferred the deprecation for a further nine months to March 30, 2024. The time for the AzureAD PowerShell retirement is now rapidly approaching.
This was the only sensible course of action. The Graph APIs for dealing with many Entra ID user account interactions, especially license assignments, were sadly undocumented. The suggestion of using cmdlets from the Microsoft Graph PowerShell SDK ran into difficulties because some of the cmdlets didn’t work as expected. Allied to that, the documentation for the SDK cmdlets remains poor and inscrutable at times. These issues have largely been addressed.
Microsoft Graph PowerShell SDK Improved Over Time
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 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 Entra ID user accounts using the SDK, and here’s another covering how to create a license report for Entra ID user accounts.
What Will Happen Between Now and the Final AzureAD PowerShell Retirement
But time eventually runs out and we are now at the point where Microsoft will soon retire the AzureAD and MSOL modules. Here’s my understanding of the situation:
- The licensing cmdlets from the AzureAD 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 Entra ID user accounts.
- For all tenants, March 30, 2024 is the official deprecation date for the licensing cmdlets in the AzureAD and MSOL modules.
- Apart from the cmdlets that assign or work with licenses, deprecation doesn’t mean “stop working.” Microsoft blocks the cmdlets that to Entra ID user accounts. 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)
- After March 30, 2024, the AzureAD and MSOL modules are deprecated and unsupported apart from security fixes. With the notable exception of the licensing cmdlets, Microsoft says that the modules will continue to function until March 30, 2025. At that point, Microsoft will retire the AzureAD and MSOL modules. Cmdlets from the two modules might still run, but no guarantees exist that they will be successful. In other words, scripts might fail without warning.
The Bottom Line About the AzureAD PowerShell Retirement
The AzureAD 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 are migrated to run using the SDK cmdlets before March 30, 2024.
The Office 365 for IT Pros eBook includes hundreds of examples of working with Microsoft 365 through PowerShell. We explain how to run Microsoft Graph API queries through PowerShell and how to use the cmdlets from the Microsoft Graph PowerShell SDK in a very practical and approachable manner.
Have you figured out how to reset a user’s password and NOT force a password reset on first signon?
Sure. Use the setting in the password profile used as the input to the Update-MgUser cmdlet to avoid resetting the password.
$NewPassword[“Password”]= “!NewYorkCity2022?”
$NewPassword[“ForceChangePasswordNextSignIn”] = $false
Update-MgUser -UserId $UserId -PasswordProfile $NewPassword
For more details on the password profile see https://learn.microsoft.com/en-us/graph/api/resources/passwordprofile?view=graph-rest-1.0
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.
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.
Never mind I found it needed this as well:
Directory.AccessAsUser.All
I think that Directory.ReadWrite.All is a better permission to uss. Directory.AccessAsUser.All is accessing the directory as a user and you’d imagine that the Directory.ReadWrite.All is more appropriate because it’s an admin activity. https://graphpermissions.merill.net/permission/Directory.AccessAsUser.All. In any case, you have a solution…
What is the equivalent of Start-ADSyncSyncCycle Delta?
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.
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 …
The solution is to use the Microsoft Graph PowerShell SDK to apply licenses. https://practical365.com/microsoft-365-license-graph-sdk/
Any example of Excel sheet ?
What kind of Excel sheet with what data?
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).
As a Microsoft person might say: “thank you for your feedback…”
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
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.