jborean93/omi

Unable to use Connect-ExchangeOnline on macOS arm64

kai-h opened this issue · 11 comments

kai-h commented
SUMMARY

After installing PSWSMan via

Install-Module -Name PSWSMan`
Install-WSMan

and then installing the Exchange Online Management via

Install-Module -Name ExchangeOnlineManagement

I am unable to connect to Exchange Online on an M1 Mac. This is odd, as I have it working on my other M1 Mac, but can not get it working on this one.

When I go to use Connect-ExchangeOnline It drops me out to a web browser, where I can authenticate, but then when I return to PowerShell, it says:

Line |
 475 |$PSSession = New-ExoPSSession -ExchangeEnvironmentName $E|                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | This parameter set requires WSMan, and no supported WSMan client library was found. WSMan is either not
     | installed or unavailable for this system.

I have also installed the universal version of OpenSSL 1.0 via sudo port install openssl10 +universal
just for good measure, and tried the same sequence of steps with the arm64 version of PowerShell 7.2.0-preview.10

LIBMI VERSION

Run https://github.com/jborean93/omi/.github/tools/Get-OmiVersion.ps1 and paste output here
https://github.com/jborean93/omi/.github/tools/Get-OmiVersion.ps1 - Not Found

OS / ENVIRONMENT

macOS 11.6
PowerShell PowerShell 7.1.4 x86_64
PowerShell 7.2.0-preview.10 arm64
OpenSSL 1.0 Universal

See #37 (comment) for the failures on x86_64. See #20 for supporting universal binaries where I have a POC PR to try and implement that #34.

kai-h commented

I currently have this working on an M1 MacBook Pro, but not on my new M1 Mac mini.

Are you able to suggest any way I can compare the two setups as I got it working quite some time ago on the MacBook Pro, so can't remember exactly the steps I tried.

The MacBook Pro will be running the whole stack under Rosetta 2, as I definitely don't have the arm64 preview version of PowerShell installed.

When running on an M1 it comes down to whether the OpenSSL version picked up supports the same architecture as to what is running PowerShell. Because you don't have the preview version of pwsh you will need to ensure the path to the OpenSSL libs supports x64_86. Considering you have OpenSSL installed with +universal then things should work but I don't know much about port to really explain how it all works. What I suggest

  • Stop using openssl10, this port of OMI supports OpenSSL 1.1 and even 3.0
    • There aren't any reasons I can think off where you will still need OpenSSL 1.0.x
    • Using a newer version opens up the ability to use new protocols and cipher suites
  • Use file /path/to/dylib or lipo -archs /path/to/dylib to verify that the linked OpenSSL libs are truly x86_64 compatible
  • Use Install-WSMan -Verbose to see what OpenSSL libs are used when setting up the symlinks - use file/lipo to check their architectures
  • Set DYLD_PRINT_APIS=1 when starting pwsh and see what failed to load
    • Usually failed is a good string to search for the failure messages
kai-h commented

Apologies opening a closed ticket, but I fixed the problem and thought someone else might benefit from the solution.

PowerShell 7.1.x, is all x86_64, which is run under Rosetta. WSMan is also x86_64.
I had installed updated OpenSSL via MacPorts, however had not installed universal builds of OpenSSL.
I had simply run sudo port install openssl in Terminal which had, of course, installed the arm64 versions of OpenSSL. Even though the libraries were all there, PowerShell couldn't use them as it was running under Rosetta 2.

I had installed OpenSSL with the +universal switch, however I only did this for OpenSSL 1.0 as this is what PowerShell used to need, I had neglected to do this for the current version.

The solution was to run sudo port install openssl +universal which installed a Universal build of the OpenSSL libraries, and now PowerShell remote sessions to Exchange Online are working, with MFA, when using the ExO v2 cmdlets.

Thanks for the update, what you said makes sense.

Just as an FYI I'm changing the logic to better handle the split architecture issues on an M1 mac as well as support arm64 pwsh. It's still a WIP in progress but it will all be included in the next release. You still need to ensure the OpenSSL libs match the pwsh architecture but the selection logic should be a lot more robust than it currently is.

kai-h commented

Great, if you need anyone to test it, I'll give it a go.

Thinking through what was happening in my case - I had installed OpenSSL 1.0 as universal, but also installed OpenSSL 1.1, however this was pure arm64.

When looking for libraries, PSWSman must have been correctly seeing that 1.1 was installed, and tried to use that in preference over 1.0, however it was arm64 only, not universal, so couldn't load.

Yea that's one of the improvements merged in #39. It will take into consideration the architecture of the OpenSSL binary and continuing to try other libraries present if the arch doesn't fit.

Now that PS 7.2 was officially released, the arm64 variant of Homebrew automatically also installs PowerShell in native arm64 code on M1 Macs. The OpenSSL 3 package's platform is arm64 as well so I thought everything should now just work without any manual intervention, right? It seems that's not the case. PSWSMan correctly picked openssl@3, even though openssl@1.1 is also installed (required by other packages installed via Homebrew).

Any idea where I should look at to get this working?

I did download the latest macos-3 artifacts from the GHA builds and installed them manually. Shouldn't they be universal x86_64 and arm64? 🤔

PSWSMan correctly picked openssl@3, even though openssl@1.1 is also installed (required by other packages installed via Homebrew).

The logic right now just uses whatever openssl is set at in brew which IIRC it set to openssl@3. The unreleased changes in the main branch will check openssl, openssl@3, and openssl@1.1 in that order until a valid version is found. Unfortunately I've been slow with finalising those changes so it's not quite ready for a release yet.

I did download the latest macos-3 artifacts from the GHA builds and installed them manually. Shouldn't they be universal x86_64 and arm64? thinking

If you downloaded macOS-3 from the latest GHA build it should be a universal build and compatible with both x86_64 and arm64 PowerShell. The tricky bit is ensuring the linked OpenSSL libs are also either universal or are for the same architecture as what's running PowerShell. Check what OpenSSL lib the libssl and libcrypto symlinks in the pwsh dir are pointing to and update them to an arm64 compatible one if they aren't already. You can use file ... or lipo -archs ... to check the type of binary architecture.

Hopefully this all becomes a moot point and handled automatically once I release the next version but I still need to solve the new import process which is tricky on macOS due to the potential for running pwsh on both x86_64 and arm64.

You are awesome and faster than me, didn't find the time to follow up on this and saw you were releasing v2.3.0 this morning. Works out of the box now, thank you so much @jborean93 ! 🎉

@jborean93 You are amazing, thank you so much for making this thing work!