2026.3.0 - Exchange module not able to load

2026.3.0 - Exchange module not able to load

avatar

We got this error on 2026.1.5 hoping that 2026.3.0 would fix it, but it appears the issue persists. We have the ExchangeOnlineManagement module installed, version 3.10.1, and it is failing to load a .NET core DLL: Microsoft.Identity.Client.dll. We have reinstalled the module to no avail. This is using the integrated environment until the other environments get fixed.

Here is the exact error message:
Could not load file or assembly '/home/psuniversal/.PowerShellUniversal/Repository/Modules/ExchangeOnlineManagement/3.10.1/netCore/Microsoft.Identity.Client.dll'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)

All Comments (5)

avatar

Hello,

Thank you for your patience, and for the precise error message, it made this one straightforward to pin down.

I was able to reproduce your issue in our lab on PowerShell Universal 2026.3.0, and I can confirm the cause.

The problem is not the ExchangeOnlineManagement module, and it is not something a reinstall can correct, which is why your reinstalls did not change anything.

The Integrated environment runs your scripts inside the PowerShell Universal server process itself, so your script shares the server's loaded assemblies.

PowerShell Universal ships and pins its own copy of Microsoft.Identity.Client, the MSAL authentication library.

In 2026.1.5 that pin was version 4.66.2, and in both 2026.2.5 and 2026.3.0 it is version 4.80.0.

ExchangeOnlineManagement 3.10.1 requires Microsoft.Identity.Client version 4.83.1.

The .NET runtime can satisfy a request for an older version of a library from a newer one already loaded, but it cannot do the reverse, so a request for 4.83.1 against a 4.80.0 pin fails immediately with the error you reported.

This also explains why upgrading did not help, the move from 2026.1.5 to 2026.3.0 did raise the bundled MSAL from 4.66.2 to 4.80.0, so it got closer, but it is still below what the module requires.

To confirm the diagnosis, I ran the exact same module, on the same machine, under the same PowerShell 7.6.5, but in a standalone PowerShell process instead of the server process, and it loaded and authenticated without any issue.

Here are your options, in the order I would recommend them.

First, the cleanest resolution is to run ExchangeOnlineManagement outside the Integrated environment, which is why I would prioritize getting your other environments working again.

On that point, one detail is worth checking right away, ExchangeOnlineManagement 3.10.x raised its minimum requirement to PowerShell 7.6.

If any of your other environments point to PowerShell 7.4 or 7.5, the module will fail there as well, and that may well be the reason those environments appear broken.

Confirming the PowerShell version each environment targets is a quick check that could unblock you entirely.

Second, if you need to stay on the Integrated environment in the meantime, pinning ExchangeOnlineManagement to version 3.9.0 resolves the error.

Version 3.9.0 requires MSAL 4.68.0, which the server's 4.80.0 satisfies without conflict, and I verified this works in the Integrated environment.

The breaking change arrived in 3.10.0, which is where the requirement jumped from 4.68.0 to 4.83.1.

Third, and only as a last resort, it is possible to replace the module's bundled MSAL files with the server's own copies.

I want to be clear that this is unsupported, that any module update will undo it, and that I verified only the authentication path, so I would treat it strictly as a temporary measure.

I will also mention that the common advice found online, replacing only Microsoft.Identity.Client.dll, does not work here, it simply moves the failure to Microsoft.Identity.Client.Broker.dll, which has the same requirement.

Both files have to be replaced together for that approach to have any effect.

I am raising this internally with our product team as well, since the module will continue to advance and the underlying conflict will recur, so a longer term fix on our side is warranted.

Please let me know which direction you would like to take, and if you can share the PowerShell version your other environments are configured to use, I will gladly help you get those back in service.

Best regards,

Patrick Ouimet

avatar

Thank you for the explanation. I have tried getting the app running on other environments in 2026.3.1, but the app will not start. The environment is using the version of PowerShell that comes with 2026.3.1, which is 7.6.5. When looking at the live log, no entries are created when I click start. Any idea why?

avatar

I've been poking around with switching apps from the integrated environment to the system installed version of PowerShell, to the version of PowerShell that PSU ships with, and when I switched it to the system installed version to the PSU shipped version, I got the following error. It looks like it doesn't come with the execution bit set.

An error occurred trying to start process '/opt/psuniversal/Hosts/7.5/PowerShellUniversal.Host' with working directory '/home/psuniversal/.PowerShellUniversal/Repository'. Permission denied

   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at PowerShellUniversal.Automation.JobProcessManager.StartProcessAsCurrentUser(String powerShellPath, String commandLine, Variable credential, Action`1 onAgentOutput, Dictionary`2 environmentVariables, String verb) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\JobProcessManager.cs:line 906
   at PowerShellUniversal.Automation.JobProcessManager.StartProcess(ExecutionEnvironment environment, Variable credential, String powerShellPath, String commandLine, ProcessType type, Action`1 onAgentOutput, Dictionary`2 environmentVariables) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\JobProcessManager.cs:line 776
   at PowerShellUniversal.Automation.JobProcessManager.StartDashboard(Int32 port, ExecutionEnvironment environment, Variable credential) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\JobProcessManager.cs:line 498
   at Universal.Server.Services.DashboardProxy.StartOutOfProcessAsync(Dashboard dashboard, ExecutionEnvironment environment) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardProxy.cs:line 248
   at Universal.Server.Services.DashboardProxy.Start(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardProxy.cs:line 101
   at Universal.Server.Services.DashboardManager.StartOnNode(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardManager.cs:line 95
   at Universal.Server.Services.DashboardManager.Start(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardManager.cs:line 46
   at Universal.Server.Services.DashboardManager.Restart(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardManager.cs:line 138
   at PowerShellUniversal.AppPowerMenu.Restart() in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Shared\Apps\AppPowerMenu.razor:line 125
   at Universal.Server.Pages.Apps.Apps.RestartApp(Dashboard app) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Pages\Apps\Apps.razor:line 106
   at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task)
   at Universal.Server.Pages.Apps.AppRowMenu.Invoke(EventCallback`1 callback) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Pages\Apps\AppRowMenu.razor:line 71
   at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task)
   at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle, ComponentState owningComponentState)


Running chmod +x /opt/psuniversal/Hosts/7.5/PowerShellUniversal.Host fixed the app starting issue. What's interesting is now ExchangeOnlineManagement is missing from installed modules, even though I can see it in .PowerShellUniversal/Repository/Modules/ExchangeOnlineManagement.

avatar

Another observation: After switching the app to the version of PowerShell that ships with PSU, it initially worked. I decided to reboot the server, and now I am getting the same error. Rebooting the environment after the machine reboot causes the app to work correctly again.

avatar

Hello akapsch,

With 2026.3.1.0, there is a known issue that you can't create a new script.
When you mentioned that you cannot create a new entry, is it related to a new script?

Best regards,

Patrick Ouimet