Connect-MgGraph fails after Connect-ExchangeOnline

[OtterKring]

Describe the bug

I don't know, if this is related to the ExchangeOnlineManagement module (my suspicison) or to Microsoft.Graph, but you should know; too, I guess:

I updated Microsoft.Graph from 2.29.1. to 2.30.0 yesterday and ExchangeOnlineManagement from 3.8.0 to 3.9.0. After the update I found that when I run Connect-ExchangeOnline before Connect-MgGraph, the latter fails with the following error:

Connect-MgGraph: ClientCertificateCredential authentication failed: Method not found: '!0 Microsoft.Identity.Client.BaseAbstractApplicationBuilder`1.WithLogging(Microsoft.IdentityModel.Abstractions.IIdentityLogger, Boolean)'.

When I run Connect-MgGraph first and then Connect-ExchangeOnline, it works.

Expected behavior

IMO it should not matter, which command is run first.

How to reproduce

• On Powershell 7.5.2 ...
• Install Microsoft.Graph 2.30.0
• Install ExchangeOnlineManagement 3.9.0
• First run Connect-ExchangeOnline. ( I used certificate authentication )
• Second run Connect-MgGraph. It does not matter if user or certificate authentication. I tried both
• You should get the error described above

SDK Version

2.30.0

Latest version known to work for scenario above?

2.29.1 together with ExchangeOnlineManagement 3.8.0

Known Workarounds

1. First run Connect-MgGraph
2. Then run Connect-ExchangeOnline

Debug output

Click to expand log

```

DEBUG: ClientCertificateCredential.GetToken invoked. Scopes: [ https://graph.microsoft.com/.default ] ParentRequestId: DEBUG: ClientCertificateCredential.GetToken was unable to retrieve an access token. Scopes: [ https://graph.microsoft.com/.default ] ParentRequestId: Exception: Azure.Identity.AuthenticationFailedException (0x80131500): ClientCertificateCredential authentication failed: Method not found: '!0 Microsoft.Identity.Client.BaseAbstractApplicationBuilder1.WithLogging(Microsoft.IdentityModel.Abstractions.IIdentityLogger, Boolean)'. ---> System.MissingMethodException (0x80131513): Method not found: '!0 Microsoft.Identity.Client.BaseAbstractApplicationBuilder1.WithLogging(Microsoft.IdentityModel.Abstractions.IIdentityLogger, Boolean)'. Connect-MgGraph: ClientCertificateCredential authentication failed: Method not found: '!0 Microsoft.Identity.Client.BaseAbstractApplicationBuilder`1.WithLogging(Microsoft.IdentityModel.Abstractions.IIdentityLogger, Boolean)'.

</details>


### Configuration

Name Value

---

PSVersion 7.5.2 PSEdition Core GitCommitId 7.5.2 OS Microsoft Windows 10.0.26100 Platform Win32NT PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…} PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 WSManStackVersion 3.0

Architecture: x64

### Other information

_No response_

[FabienTschanz]

The issue is with the assembly context of the module. Microsoft does not implement the assembly loading context properly, leading to those assemblies being loaded globally instead of only in the application context it belongs to. This is something that occurs again and again and they don't fix it... Guess we have to wait until the next release fixes it (for another couple of months until the next one)...

[robinmalik]

This has been an issue for years now as I remember having to inform colleagues to avoid doing this. Given that the Exchange team released a PowerShell snap-in just a few years ago despite modules being favoured since 2010, I'm not convinced they will be working collaboratively with more modern teams within Microsoft to help resolve this. I hope I'm wrong though.

[KevinPinel]

This does work in PS5. It doesn't help when scripts also rely on PS7 only modules

[gavinbarron]

We are working with the EXO team to resolve this issue and ensure it should not happen again.

In the meantime if you reverse the order in which the Connect-* cmdlets are called the cmdlets work as expected based on out testing

[Skaldhor]

@gavinbarron Is there any update regarding this issue? It took more than a month to acknowledge the bug and now another month passed without a fix. Since these are enterprise tools we need to manage our M365 services, I think there should be some kind of higher priority, rollback to working versions or some kind of communication at least. I think there's no M365 admin center service incident, no message on the Exchange techcommunity Blog etc.

[mognify]

lol, pretty insane that it's fixed by importing ExchangeOnlineManagement before importing any Microsoft.Graph.* modules but it works... very satisfying fix tbh... simple, straight-forward, reproducible with minimal effort...

I wonder what goes on that causes it to have issues if the Graph modules are imported first

[gavinbarron]

@Skaldhor we're trying to work with the EXO team on a comprehensive fix.

I apologize that this is taking too long, but the reality here is that we have limited resources and the EXO team hasn't been willing to collaborate on a proper fix. So, while we could ship a fix that addresses this for the current versions without their collaboration, we'll wind up in the same broken state again when they ship again.

[Skaldhor]

@gavinbarron I understand there are internal collaboration issues at Microsoft and appreciate you being open about it and trying to achieve a future proof solution.

However, from a customer/consumer point of view: This is a bug/issue in enterprise management tools we need and pay for (indirectly). I would expect this to be fixed "relatively" timely, especially since you already seem to know the issue, cause and (potential) fix. Even without the EXO team you could publish a working version for now and work on a future proof solution with them in the background.