ExchangeOnline module - Could not load file or assembly

PowerShell Universal
1 
PowerShell Universal version: 3.7.10
Environment: PowerShell v. 7.3.1
Server OS: 2022

Have anyone had any issues with the ExchangeOnlineManagement module, that it throws the error:
Could not load file or assembly 'Microsoft.Identity.Client, Version=4.44.0.0, Culture=neutral

From PSU dashboards or scripts I can import the ExchangeOnlineManagement module, but when I try and connect with Connect-ExchangeOnline I receive the above error.

When I try from a normal PS session directly on the server everything works as expected. :heavy_check_mark:

Also if I in PSU switch to the PS 5.1 environment and run the script, it works and I can connect. :heavy_check_mark:

I have tried:

  • Reinstall the ExchangeOnlineManagement module.
  • Remove the Microsoft.Graph module (have read that could interfere).
  • Upgrade to PS 7.3.2.
  • Repair PowerShell Universal.

Does anyone know what might be wrong?

Thanks.

2

What version of powershell is this session running on? I’ve had issues with the EXO cmdlets on 7.x an always run them on 5.1

3

That session is running 7.3.1 (or 7.3.2).

4

PSU uses version 4.46.0 of that assembly. I’m a bit surprised this mismatch would cause a problem.

    <PackageReference Include="Microsoft.Identity.Client" Version="4.46.0" />

Can you try to see what versions of assemblies are loaded in your dashboard? You can check with a function like this.

        function Show-UDAssemblies {
            Show-UDModal {
                $Assemblies = [AppDomain]::CurrentDomain.GetAssemblies() | Select-Object FullName | Sort-Object
                New-UDTable -Data $Assemblies
            }
        }
        Show-UDAssemblies
5

Hi Adam

It returns this version:

[information] Microsoft.Identity.Client, Version=4.33.0.0, Culture=neutral

6

Can you add the path to see where that is loaded from?

        function Show-UDAssemblies {
            Show-UDModal {
                $Assemblies = [AppDomain]::CurrentDomain.GetAssemblies() | Select-Object FullName, CodeBase
                New-UDTable -Data $Assemblies
            }
        }
        Show-UDAssemblies
7

I would recommend against using that module in PSU. Since the REST-based cmdlets have been introduced in EXO, you can achieve the exact same result by talking directly to https://outlook.office365.com/adminapi/beta/{tenant ID}/InvokeCommand with less footprint and fewer issues in general. POST JSON payload like "{"CmdletInput":{"CmdletName":"Get-MobileDevice","Parameters":{"ResultSize":"Unlimited"}}} You can set “X-ResposeFormat” header to “clixml” have the output conveniently sent to you as natively serialized Powershell.

1 Like
8

Can see that it is loaded from dbatools:

[information] file:///C:/Program Files/PowerShell/Modules/dbatools/1.1.145/bin/smo/coreclr/win/Microsoft.Identity.Client.dll
9

Egor would love to avoid using the module and entirely use REST calls to ExO. But from what I have read, and is shown in the URL, it is still in a beta phase. That’s why I haven’t considered using it.

But have you used it a lot and can confirm it is stable to use in production?

10

@Tbmoeller This is the very same endpoint the module is hitting. You can grab Fiddler and confirm yourself. So its as stable as using EXO module (assuming your code is sane).

The same thing applies to other Graph-based modules (azureadpreview, mg-*, az) tbh. I learned the hard way that some modules leak memory, some don’t maintain session while running inside PSU, so I just rolled my own very lightweight Invoke-GraphRequest function and everything is good so far (I still rely on MSAL.PS to get tokens as I use certificate-based auth and implementing it from scratch is a bit beyond my powershell skills).

11

Do you have a link to where I can read about that API? the only docs I can find mention that it is deprecated.

[DEPRECATED] Use the Outlook REST API (beta) | Microsoft Learn

12

Hi. I don’t believe it’s documented officially, as technically it’s an internal API, but Vasil Michev wrote a nice write up on this – (Ab)using the REST API endpoints behind the new ExO cmdlets | Blog (also check the comments section, some very solid hints there)

Upd: The link is not exactly accurate, it’s more for new EXO- cmdlets. Since it’s somewhat relevant and definitely helpful, I’m keeping it. But please see this Exchange Online PowerShell module gets rid of the WinRM dependence | Blog for actual examples on using InvokeCommand endpoint.

1 Like
13

@adam have same issue with the ExchangeOnline module. Though in my case the issue is “System.IdentityModel.Tokens.Jwt” which have a version mismatch.

The module expects version 6.22.1.0 but PSU has version 6.22.0.0.

Full error:

Could not load file or assembly 'System.IdentityModel.Tokens.Jwt, Version=6.22.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (0x80131621)
14

To get around this, I downloaded the latest PS7, created a new environment with it and then it worked.

Though I have seen examples of another issue with “System.IdentityModel.Tokens.Jwt” where, if a module includes an older version, and that version has been loaded, then the newer version wont be loaded when needed.

15

We should be able to bump the JWT NuGet package really easily to accomodate this.

16

Will it be done in a new release or do you have a workaround I can do?

17

It will be in the 3.7.12 release. I don’t have a good workaround for this for the time being but we should be able to get that release out this week.

This change is already in the nightly builds if you want to try them out.

18

Wondering if this is still an active issue. I am doing the same thing, cert auth exchange connection and getting: Could not load file or assembly 'System.IdentityModel.Tokens.Jwt, Version=6.12.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (0x80131621)