Why You Should Not Upgrade to Microsoft Graph PowerShell SDK V2.14

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.