Table of Contents
MVP Finds Solution for Long-Running Microsoft Graph PowerShell SDK Problem
On September 30, 2026, Microsoft released V2.41 of the Microsoft Graph PowerShell SDK (available from the PowerShell Gallery and for the first time in a usable form in the Microsoft Artifact Registry). The big news in V2.41 is a fix for the infamous assembly clash problems with delegated interactive sessions which have afflicted Microsoft 365 PowerShell modules over the last 18 months. This is important because Microsoft 365 administrators can once again reasonably expect major Microsoft PowerShell modules to coexist in the same PowerShell session.
Interestingly, the solution to the assembly clash problem came in a pull request authored by Stephan van Rooij, a Microsoft MVP from the Netherlands. The request reworked how the Microsoft.Graph.Authentication module handles and loads dependencies to avoid conflicts with other PowerShell modules. It was quickly snapped up by the Graph SDK development team.
A Win for the Technical Community
Although fixing the assembly clash problem is a great example of the power of a functioning technical community at work, it does beg the question why a collection of Microsoft development groups couldn’t fix the problem. Sometimes it takes someone new to look at a problem before the solution becomes apparent. The episode also demonstrates the value of transparent engineering discussions. The community and Microsoft engineers were able to discuss the problem openly through GitHub issues and pull requests before arriving at a solution.
Perhaps seeing how fresh external eyes can deliver great contributions will make those responsible for Microsoft Learn reconsider their decision to make most GitHub repositories for documentation private. Certainly, having the community and developers discuss and dissect the problem in issues reported through GitHub (here’s an example) was useful in understanding the root cause and contributed to the solution.
Checking if Annoying Assembly Clashes Are No More
To check whether everything works as planned, I installed the latest versions of the Exchange Online, Teams, and Microsoft Graph PowerShell SDK on PowerShell 7.6.6 and ran the following commands:
Connect-ExchangeOnline -ShowBanner:$false Connect-MgGraph -NoWelcome Connect-MicrosoftTeams Account Environment Tenant TenantId ------- ----------- ------ -------- Tony.Redmond@office365itpros.com AzureCloud a662313f-14fc-43a2-9a7a-d2e27f4f3478 a662313f-14fc-43a2-9a7a-d2e27f4f34… Get-Module | Format-Table Name, Version Name Version ---- ------- ExchangeOnlineManagement 3.10.1 Microsoft.Graph.Authentication 2.41.0 Microsoft.PowerShell.Management 7.0.0.0 Microsoft.PowerShell.Utility 7.0.0.0 MicrosoftTeams 8.0.0 PSReadLine 2.4.5 tmpEXO_lnvyjv2k.vvc 0.0.1
Everything looks good. Most importantly, all three modules can establish delegated connections in the same PowerShell session without triggering the assembly-loading conflicts that plagued earlier releases.
A known issue (the fix is already available) exists in that removing and reimporting the Microsoft.Graph.Authentication module in the same PowerShell session can leave dependency resolution broken. This shouldn’t affect many people because I imagine that most import needed modules at the start of a session, leaving the modules in place for the remainder of the session.
I used V3.10.1 of the Exchange Online Management module for my test. Message center notification MC1483974 (30 September 2026) warns that strict enforcement of sign-ins begins on March 30, 2027, specifically affecting sign-ins when Web Account Manager is disabled in PowerShell 7 sessions. It’s a good idea to update now to avoid any potential issues in the future.
The .NET Conundrum and Azure Automation Woes
Microsoft Graph PowerShell SDK V2.41 supports Windows PowerShell 5.1 (.NET Framework 4.7.2 or later) and modern PowerShell releases. Soon after the release of V2.41, an issue was posted reporting a problem loading the assembly “.Net 9 System.Text.Json, Version=10.0.0.0.”
The person who reported the problem used PowerShell 7.5.5, which runs on .NET 9. The issue appears to be related to dependency resolution for System.Text.Json version 10.0.0.0 introduced in V2.41. I used PowerShell 7.6.6 in my tests and did not experience the problem. Whether the difference is due to the runtime environment or some other dependency-resolution factor remains unclear until Microsoft publishes a root-cause analysis.
The same problem affects Azure Automation runbooks which use the PowerShell 7.2 and 7.4 runtime environments. I used this script to update the SDK modules installed in one of my 7.4 custom runtime environments and hit the problem when runbooks attempted to run Connect-MgGraph with a managed identity (Figure 2).
If you have a runtime environment which uses a previous version of the SDK modules, you can switch the runbooks to that environment. Another possible workaround is to use a PowerShell 5.1 runtime environment. It’s a messy but easily resolved problem, which proves once again that when a software update solves a problem in a new release, it might create an issue somewhere else.
Future Upgrade Coming
Some administrators stay on a known-good version of the Microsoft Graph PowerShell SDK because they fear that an upgrade might break production automation. It’s certainly a reasonable tactic to pursue, especially when updates might break important automation processes.
However, in August 2026, Microsoft flagged a forthcoming change that they plan to make to how delegated interactive sessions work with the default Microsoft Graph Command Line Tools app. In a nutshell, all such sessions will be forced to use the Web Account Manager (WAM). Microsoft will implement the change in the backend rather than in a particular version of the Microsoft Graph PowerShell SDK, so it will apply to all versions. Be prepared!
One Problem Fixed, Now onto the Next
So far, V2.41 seems to be stable for interactive delegated and app-only sessions. All my Graph SDK scripts work as before on V2.39 and V2.40. The big problem is with Azure Automation, and that issue points to a lack of testing against all environments supported by the Microsoft Graph PowerShell SDK.
Before upgrading, it’s a good idea to check the current set of known issues to make sure that nothing has been reported which will be a block for your tenant. It’s also a good idea to check a newly-installed version of the Microsoft Graph PowerShell SDK by running some test scripts which reflect your use of SDK cmdlets. V2.41 appears to finally resolve one of the most persistent irritations in Microsoft 365 PowerShell administration. That’s good news, even if a few dependency issues still need ironing out.
The nice thing about generative AI tools is that they can generate information based on what’s gone before. The bad thing about generative AI tools is that they can’t create new thinking or insights about how technology works (or doesn’t). When we write the Microsoft 365 for IT Pros eBooks, we depend on hundreds of years of real-world experience, knowledge, and intuition to analyze and explain how Microsoft 365 really works. If you understand the basic principles about Entra ID, Exchange Online, SharePoint Online, Teams, the Microsoft Graph, and more, you’ll be able to figure out the value of new features as Microsoft adds them to the platform. All for less than ten copies of black coffee.