Microsoft.Graph.Authentication no compatible with ExchangeOnlineManagement

[iserrano76]

Describe the bug

I am working in a script on PowerShell 5.1 with ExchangeOnlineManagement and Microsoft.Graph.Authentication and if I try to connect to Graph after connect to Exchange Online I received an error message:

In the troubleshooting I found that the issue appear as well just importing the modules in the same order:

In case that I run in verbose mode
Import-Module ExchangeOnlineManagement -Verbose
Import-Module Microsoft.Graph.Authentication -Verbose

If I look for the error:

It looks it is trying to look for Azure.Core on ExchangeOnlineManagement module.

if I change the order all works fine:

Expected behavior

Be able to work with both modules, without errors and could use any order in the request.

How to reproduce

Connect-ExchangeOnline -ShowBanner:$false
Connect-MgGraph -NoWelcome

Import-Module ExchangeOnlineManagement
Import-Module Microsoft.Graph.Authentication

Import-Module ExchangeOnlineManagement -Verbose
Import-Module Microsoft.Graph.Authentication -Verbose

SDK Version

2.19.0

Latest version known to work for scenario above?

No response

Known Workarounds

It works with PowerShell 7 or with ExchangeOnlineManagement 3.4.0

Debug output

Click to expand log

```

VERBOSE: Cannot verify the Microsoft .NET Framework version 4.7.2 because it is not included in the list of permitted versions.
VERBOSE: Loading 'FormatsToProcess' from path 'C:\Users\xxxxx\WindowsPowerShell\Modules\Microsoft.Graph.Authentication\2.19.0\Microsoft.Graph.Authentication.format.ps1xml'.
VERBOSE: Populating RepositorySourceLocation property for module Microsoft.Graph.Authentication.
VERBOSE: Loading module from path 'C:\Users\xxxxx\WindowsPowerShell\Modules\Microsoft.Graph.Authentication\2.19.0\Microsoft.Graph.Authentication.dll'.
VERBOSE: Importing cmdlet 'Get-ModuleCmdlet'.
VERBOSE: Importing cmdlet 'Get-ScriptCmdlet'.
VERBOSE: Importing cmdlet 'Connect-MgGraph'.
VERBOSE: Importing cmdlet 'Disconnect-MgGraph'.
VERBOSE: Importing cmdlet 'Add-MgEnvironment'.
VERBOSE: Importing cmdlet 'Get-MgEnvironment'.
VERBOSE: Importing cmdlet 'Remove-MgEnvironment'.
VERBOSE: Importing cmdlet 'Set-MgEnvironment'.
VERBOSE: Importing cmdlet 'Get-MgContext'.
VERBOSE: Importing cmdlet 'Get-MgGraphOption'.
VERBOSE: Importing cmdlet 'Invoke-MgGraphRequest'.
VERBOSE: Importing cmdlet 'Set-MgGraphOption'.
VERBOSE: Importing cmdlet 'Get-MgRequestContext'.
VERBOSE: Importing cmdlet 'Set-MgRequestContext'.
VERBOSE: Importing alias 'Connect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Invoke-GraphRequest'.
VERBOSE: Importing alias 'Invoke-MgRestMethod'.
VERBOSE: Importing alias 'Invoke-GraphRequest'.
VERBOSE: Importing alias 'Invoke-MgRestMethod'.
VERBOSE: Importing alias 'Invoke-GraphRequest'.
VERBOSE: Importing alias 'Invoke-MgRestMethod'.
VERBOSE: Importing alias 'Invoke-GraphRequest'.
VERBOSE: Importing alias 'Invoke-MgRestMethod'.
VERBOSE: Loading module from path 'C:\Users\xxxxx\WindowsPowerShell\Modules\Microsoft.Graph.Authentication\2.19.0\Microsoft.Graph.Authentication.Core.dll'.
Import-Module : Could not load file or assembly 'file:///C:\Users\xxxxx\WindowsPowerShell\Modules\ExchangeOnlineManagement\3.5.0\netFramework\Azure.Core.dll' or one of its dependencies. The system cannot find the file specified.
At line:1 char:1

• Import-Module Microsoft.Graph.Authentication -Debug

•   + CategoryInfo          : NotSpecified: (:) [Import-Module], FileNotFoundException
    + FullyQualifiedErrorId : System.IO.FileNotFoundException,Microsoft.PowerShell.Commands.ImportModuleCommand
  
  

</details>


### Configuration

Name                           Value
----                           -----
PSVersion                      5.1.22621.3672
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.22621.3672
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Windows 10, 11, Server 2022 x64

### Other information

_No response_

[RomainBenat]

Got the same issue on the version 3.5.0 of Exchange Online Management. The workaround remains the same.

[Eulafe]

Got the same issue on Azure Automation with Microsoft.Graph.* v2.19.0 + ExchangeOnlineManagement v3.5.0

Workaround works with Microsoft.Graph.* v2.19.0 + ExchangeOnlineManagement v3.4.0

Thanks for this!

[timayabi2020]

Hi @iserrano76 please update to the latest Microsoft.Graph PowerShell SDK version (2.21.0) which has the latest Azure.Core version (1.39.0) compatible with ExchangeOnlineManagement version 3.5.1.

[secretworkpersona]

Latest version (2.21.0) does not resolve the issue for me.

[iserrano76]

Hi @iserrano76 please update to the latest Microsoft.Graph PowerShell SDK version (2.21.0) which has the latest Azure.Core version (1.39.0) compatible with ExchangeOnlineManagement version 3.5.1.

Hi @timayabi2020,

It looks the same issue:

[timayabi2020]

@iserrano76 apologies I just realized that I was in a PowerShell 7 session and not 5.1 and I was able to reproduce the issue. After investigations, it seems that ExchangeOnlineManagment module from version 3.5.0 onwards is not isolating its dependencies into an Assembly Loading Context as described here https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/resolving-dependency-conflicts?view=powershell-7.4. Besides the work around of rolling back to version 3.4.0, you might want to consider running the modules in their individual PowerShell sessions.

[iserrano76]

@iserrano76 apologies I just realized that I was in a PowerShell 7 session and not 5.1 and I was able to reproduce the issue. After investigations, it seems that ExchangeOnlineManagment module from version 3.5.0 onwards is not isolating its dependencies into an Assembly Loading Context as described here https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/resolving-dependency-conflicts?view=powershell-7.4. Besides the work around of rolling back to version 3.4.0, you might want to consider running the modules in their individual PowerShell sessions.

Hi @timayabi2020, no problem.
I need to use both modules in the same session as I am using information from graph in the EXO session.
In my case if I import before graph it works, but I do not need always graph, so I am overloading the session but at least works for me as a workaround.

[ks-git-22]

Hi @timayabi2020

I have the same issue.

I need to use both modules in the same session.
So I cant't use their individual PowerShell sessions.

I can work around this issue by rolling back to version 3.4.0, but I understand this is only a temporary solution.
I think the permanent solution to this issue would be to be able to use ExchangeOnlineManagment and Microsoft.Graph PowerShell in the same PS session.

Will ExchangeOnlineManagement 3.5.2 or a later version resolve this issue?

[iserrano76]

Hi @timayabi2020

I have the same issue.

I need to use both modules in the same session. So I cant't use their individual PowerShell sessions.

I can work around this issue by rolling back to version 3.4.0, but I understand this is only a temporary solution. I think the permanent solution to this issue would be to be able to use ExchangeOnlineManagment and Microsoft.Graph PowerShell in the same PS session.

Will ExchangeOnlineManagement 3.5.2 or a later version resolve this issue?

Hi @ks-git-22

If you import modules in the the opposite order it should work with 3.5

Import-Module Microsoft.Graph.Authentication
Import-Module ExchangeOnlineManagement

Another way could be using #Requires modules:

#Requires -Modules Microsoft.Graph.Authentication
#Requires -Modules ExchangeOnlineManagement

I don't know if this could works for you at least a better workaround with the new versions of the modules.

In my case, I don't need always ExchangeOnlineManagement, this solution, works for me but overloaded the script with modules that are not always need it.

Best regards.

[secretworkpersona]

I plan to study @iserrano76 's link and get smarterer, but I'm asking in case somebody already knows the answer (Easy Button). I've previously crawled through modules to troubleshoot, but I'm not versed in assemblies.

The error is an attempt to load a file that doesn't exist. AzureCore.dll resides in
.\Modules\ExchangeOnlineManagement\3.5.1\netCore
but the call is to
.\Modules\ExchangeOnlineManagement\3.5.1\netFramework
where the file doesn't exist.

What determines the location where an attempt is made to load the file? I assume it's in a configuration file or written into the modules or other assemblies themselves. AzureCore.dll also does not exist in the netFramework folder in ExchangeOnlineManagement version 3.4.0 so the key is @iserrano76 's statement "version 3.5.0 onwards is not isolating its dependencies into an Assembly Loading Context", but I'm too woefully ignorant to know what that means or how to validate it.

Again, I plan to deep dive into this for my own understanding, but I'd take the tl;dr version in the short term.

[ks-git-22]

If you import modules in the the opposite order it should work with 3.5

Hi @iserrano76 and @timayabi2020

As you say, I import the modules in that order, Import-Module was succeed.

Then I run commands Connect-ExchangeOnline and Connect-MgGraph.
Connect-MgGraph was succeed, but Connect-ExchangeOnline was returned the following error message.

Command:

Connect-ExchangeOnline -AppID <Client ID> -Organization <Tenant Name> -CertificateThumbPrint <Thumprint>

Error Message:

IDX12729: Unable to decode the header '[PII of type 'System.String' is hidden. For more details, see https://aka.ms/Ide
ntityModel/PII.]' as Base64Url encoded string.
At C:\Program Files\WindowsPowerShell\Modules\ExchangeOnlineManagement\3.5.1\netFramework\ExchangeOnlineManagemen
t.psm1:762 char:21
+                     throw $_.Exception.InnerException;
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [], ArgumentException
    + FullyQualifiedErrorId : IDX12729: Unable to decode the header '[PII of type 'System.String' is hidden. For more
   details, see https://aka.ms/IdentityModel/PII.]' as Base64Url encoded string.

This error ocuurs by Connect-ExchangeOnline, so I contacted Microsoft 365 support.
Microsoft 365 support answered "This error is the problem of Graph."

Is this answer correct?

If this error is caused by Graph, do you know why?

Best regards.

[CraigTolley]

@ks-git-22 - After spending 5 hours today on this, I finally have something that works. It's suboptimal, but working.

Import-Module Microsoft.Graph.Authentication
Import-Module ExchangeOnlineManagement -RequiredVersion 3.4.0

Connect-ExchangeOnline -Certificate $Cert -AppId $AppId -Organization $TenantName
Connect-MgGraph -Certificate $Cert -ClientId $AppId -TenantId $TenantId

This is with ExchangeOnlineManagement version 3.4.0 and Microsoft.Graph 2.22.0, running on PowerShell 5.1.

Newer versions (3.5.0 and 3.5.1) give the 'Unable to decode header' that you got. Importing the modules in the other order gives the assembly load errors.

[ks-git-22]

@CraigTolley
I confirmed that ExchangeOnlineManagement 3.4.0 and Microsoft.Graph.Authentication 2.22.0 had run on PoserShell 5.1.

But newer versions (3.5.0 and 3.5.1) and Microsoft.Graph.Authentication 2.22.0 could not run.

Is there no other way to solve this issue than to revert ExchangeOnlineManagement to 3.4.0?