Table of Contents
Problem Found in Microsoft Graph PowerShell SDK V2.13.1 Worsens in V2.14 – But Now We Have V2.15 So All is Well
Usually, I recommend that people upgrade their workstations when new versions of the Microsoft Graph PowerShell SDK appear. I cannot do this for Version 2.14, which Microsoft released on February 17, 2024. The reason is that V2.14 makes a problem that appeared in V2.13.1 (Figure 1) even worse. The problem is described here. It only affects SDK cmdlets and does not impact regular Graph queries.

According to Microsoft, they are working on a fix to make response headers optional. From the wording of the GitHub report, it seems like Microsoft introduced the issue by making a change for cmdlets to output response headers without thinking about how this might affect customers. No date is given when the fix might be available.
Update: Microsoft has released V2.14.1 of the Microsoft Graph PowerShell SDK to fix the reported problems. After downloading and installing V2.14.1 for both interactive and background (Azure Automation) use, it appears that the issue with cmdlets returning spurious output is fixed.
According to the PowerShell Gallery statistics, 22,936 people downloaded the flawed V2.14 and 105,907 downloaded the problematic 2.13.1. Let’s hope that their scripts were not affected by the bug.
Microsoft obviously has a problem testing the SDK before release. In addition to 2.14.1, they have issued four other point releases to fix problems discovered soon after releasing a new version (2,13.1, 2.11.1, 2.9.1, and 2.6.1). This is not evidence of high-quality software engineering. The developers need to improve testing and not rush new versions into production without ensuring that new software will impact customers.
Update (22 February 2024): Microsoft has released V2.15 of the SDK. They say that this release includes fixes two specific bugs that they wanted to close. Details are posted here. Although it’s laudable to close bugs, issuing a succession of new releases and point updates doesn’t create the impression of stability and robustness that the SDK should project.
The Case of the Unwanted ResponseHeaders Object
In a nutshell, instead of returning a single object when cmdlets like Get-MgUser and Get-MgGroup use a valid identifier to find an object, the cmdlets return an array containing an unwanted ‘ResponseHeaders’ object. Here’s an example:
Get-MgUser -UserId Terry.Hegarty@office365itpros.com DisplayName Id Mail UserPrincipalName ----------- -- ---- ----------------- Terry Hegarty 75ba0efb-aed5-4c0b-a5de-be5b65187c08 Terry.Hegarty@office365itpros.com Terry.Hegarty@office365itpros.c… ResponseHeaders : {0bde6f40-9291-4457-9da8-59484710f11a}
You might not notice this problem if you format the output, but there is an extra line in the output:
Get-MgUser -UserId Terry.Hegarty@office365itpros.com | Format-Table DisplayName, userPrincipalName DisplayName UserPrincipalName ----------- ----------------- Terry Hegarty Terry.Hegarty@office365itpros.com
Examining what is returned, we see that it is an array with two items:
$User = Get-MgUser -UserId Terry.Hegarty@office365itpros.com $User.GetType() IsPublic IsSerial Name BaseType -------- -------- ---- -------- True True Object[] System.Array $User.count 2
The problem doesn’t appear if you use a filter to find objects. Only a lookup against the object identifier is affected:
Get-MgUser -Filter "displayname eq 'Terry Hegarty'" DisplayName Id Mail UserPrincipalName ----------- -- ---- ----------------- Terry Hegarty 75ba0efb-aed5-4c0b-a5de-be5b65187c08 Terry.Hegarty@office365itpros.com Terry.Hegarty@office365itpros.c…
The same behavior is observed with other cmdlets. Here’s an example with the Get-MgGroup cmdlet:
Get-MgGroup -GroupId '78b47932-b35f-4b26-94c2-3228cb234b07' DisplayName Id MailNickname Description GroupTypes ----------- -- ------------ ----------- ---------- PL Test Group 78b47932-b35f-4b26-94c2-3228cb234b07 pltestgroup Preservation Lock Test {Unified} ResponseHeaders : {5eec6516-3352-4c98-a7de-f4231a2b0c4d} Get-MgGroup -filter "Displayname eq 'PL Test Group'" DisplayName Id MailNickname Description GroupTypes ----------- -- ------------ ----------- ---------- PL Test Group 78b47932-b35f-4b26-94c2-3228cb234b07 pltestgroup Preservation Lock Test {Unified}
The problem is significantly worse in V2.14 because the cmdlets now return a hash table containing what appears to be debug information (you see the same information if you run Get-MgUser or Get-MgGroup with the -Debug switch). Here’s an extract of some of the information returned.
Date {Mon, 19 Feb 2024 11:37:26 GMT} Strict-Transport-Security {max-age=31536000} OData-Version {4.0} x-ms-ags-diagnostic {{"ServerInfo":{"DataCenter":"North Europe ","Slice":"E","Ring":"5","ScaleUnit":"002… Cache-Control {no-cache} Transfer-Encoding {chunked}
The issue occurs in many other SDK cmdlets. I focus on the user and group cmdlets here because they are possibly the highest-profile cmdlets in the SDK.
Don’t Upgrade for Now
The bottom line is that you should not update to a new version of the Microsoft Graph PowerShell SDK until Microsoft fixes the problem and removes the spurious output from cmdlets. The last good version of the SDK is V2.12. If you do upgrade to a newer version, be prepared to check scripts to make sure that code runs as normal.
In saying this, I note that the problem has not affected any script that I have worked on since installing V2.13.1 about ten days ago. The reason is probably that most of my scripts use filters to fetch user or group objects for processing. However, some scripts do run Get-MgUser or Get-MgGroup to process individual objects and that’s where the problem will arise.
Final Countdown for MSOL and AzureAD Modules
This problem happened at a sensitive time for the Microsoft 365 PowerShell community. On March 30, 2024, Microsoft will finally retire the old AzureAD and MSOL modules. This process has been ongoing for quite some time and Microsoft has already disabled the cmdlets that deal with license management assignments.
With 38 days to go (at the time of publication) before the old modules retire, the Microsoft Graph PowerShell SDK should be in good health and ready to accommodate everyone who needs to upgrade scripts. Introducing a flaw affecting the cmdlets that access user and group objects which are likely targets for conversion from old scripts is not good news. Let’s hope the fix arrives soon and Microsoft is more careful about making changes to the SDK that could break customer scripts in the future.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.
I haven’t upgraded since 2.0.0. When I tried a newer version, I was getting weird breakage happening that couldn’t be explained
What a mess. Too many versions.
https://blog.icewolf.ch/archive/2024/02/20/microsoft-graph-powershell-modules-2-14-1-released/ Version 2.14.1 is out which should fix the issue
I hate when someone says that an update “should” fix an issue.
Microsoft has released V2.14.1 of the Microsoft Graph PowerShell SDK to fix the reported problems. After downloading and installing V2.14.1 for both interactive and background (Azure Automation) use, it appears that the issue with cmdlets returning spurious output is fixed.
According to the PowerShell Gallery statistics, 22,936 people downloaded the flawed V2.14 and 105,907 downloaded the flawed 2.13.1. Let’s hope that their scripts were not affected by the bug.
Microsoft obviously has a problem testing the SDK before release. In addition to 2.14.1, they have issued four other point releases to fix problems discovered soon after release of a new version (2,13.1, 2.11.1, 2.9.1, and 2.6.1). This is not evidence of high-quality software engineering. The developers need to improve testing and not rush new versions into production without ensuring that new software will impact customers.
Yes, that’s not what I want to say but so many day 1 patches after releasing a new version last few months 🧐
Updating modules used to be so easy and straightforward. Now, I’m always scared to do this as something always breaks! I’m starting to regret having multiple scheduled scripts in one Azure Automation Account as every time I update the modules, a few scripts fail…