Is there a reason why you don’t want to use the integrated PS7 or the one installed manually on the server? Does anything else run without an issue with that other one you’re having problems with?
I’m seeing this exchange issue as well, on my new build server. I can’t really compare it to the current production server, because that is using version 2 of the EXO cmdlets, and there were major changes when they went to v3. I can connect successfully to Exchange Online if I do it manually in a PowerShell 7 windows, but PSU can’t do it when it’s called by a script. I’m using the integrated 7 environment for the script.
I’m not seeing any issues connecting with EXO v3.6.0. This is a new server build from January with Universal v5.2 installed and then upgraded to v5.5 last week.
You’re using a different version of EXO. Both of us who had the issue are running 3.7.2.
I can load 3.7.2 fine in 5.5.0 and 5.5.1 (pending release).
I’m using the PowerShell 7 environment for my script. It does not seem to work in the integrated environment. It also works in a custom PS 7.4 environment I have in my lab.
Sorry, I saw v3 and just assumed it was all of v3. I did have 3.7.2 as well with no issues. I did downgrade to 3.6 to test something else to make sure it wasn’t 3.7.2 and haven’t upgraded back.
I also want to drop this discussion here as well: Long-Term Stability for using Microsoft 365 and Azure Modules - #4 by claudiospizzi
PS7 and .NET Core have some things we can try but this is a problem for more than just PSU and we need to figure out the best way to handle it. If that means we can work with Microsoft, I’m all ears.
It’s mainly for historic reasons and probably mostly doesn’t apply any more. There was a time when PSU had problems with memory leak and processor run away causing the server to lock up.
If using Integrated, everythng ran under a single process. By selecting a different environment, each process ran under it’s own instance of pwsh.exe which meant I could monitor the processes and if anything started getting a little intensive I could kill it programmatically and take out maybe a single dashboard rather than the whole server.
I also heavily rely on HaloAPI module and did have issues with parameter conflicts with PSU. I can’t specifically remember if this only affected Integrated environment, but I have a gut feeling it might have.
I now have over 100 apps, scripts and APIs running and it would be a somewhat arduous task to revert and test them in a different environment with little, if any gain.
See, I have the opposite, it will load if I set the environment to “Integrated” but not with “Powershell 7”. I installed from bare metal v5.5.0, no upgrade.
If it helps anybody, I have had to do this before. Obviously, not recommended if you don’t have too but it has worked for me.
$folderPath = “C:\ProgramData\UniversalAutomation\Repository\Modules\ExchangeOnlineManagement\3.7.1\netCore”
Get-ChildItem -Path $folderPath -Filter *.dll | ForEach-Object {
[System.Reflection.Assembly]::LoadFrom($_.FullName) | Out-Null
}
Make sure to put this before importing any modules