PowerShell 7 is out, compatibility mode saves most Office 365 modules

Two years ago, the first major version of PowerShell Core got released. At that time, the product was quite crippled, as the move from .NET to .NET Core broke almost every non-bundled module out there. In turn, this resulted in quite disappointing adoption numbers, as Microsoft noted a year later. I mean, who would have thought that breaking compatibility with modules/APIs that have been used for years across every Microsoft product would actually affect people. Go figure!

The .NET switch problems applied to any module related to Office 365 as well. Such modules either failed to load altogether or threw errors upon executing specific cmdlets, as I covered at length in this article. Using the Exchange Online remote PowerShell cmdlets was pretty much the only thing that did work, which comes as no surprise as those are effectively proxied by the client and run on the server, with any input/output getting deserialized.

So, after reversing their stance and prioritizing compatibility for the next release, did Microsoft solve all those issues with PowerShell 7 and Office 365? While there is a definite improvement in the “core” PowerShell functionality, most Office 365 related modules will still fail to work *natively* as they simply don’t support PowerShell Core. But, Microsoft introduced some compatibility improvements, which allow such modules to run in a local Windows PowerShell instance, to which PowerShell 7 proxies all input/output. Which adds some overhead, but in most cases works quite acceptable.

The TL;DR version is that compatibility mode saves the day, albeit I would have preferred if the corresponding teams within Microsoft actually released versions of their respective modules that natively support PowerShell Core. Oh well, beggars cannot be choosers. So let’s go over the individual modules.

The good old MSOnline module will immediately be imported in compatibility and didn’t throw any issues with the few tests I performed. Using the Connect-MsolService cmdlet without any parameter produced the standard ADAL credentials prompt (yay Forms!) and voila:

Funnily enough, the Azure AD module, which is much more recent release compared to the MSOnline module, threw an error immediately. Even using the “pass token” trick that helped me connect last time failed:

Which is very puzzling, considering the module has been supported in Azure Cloud Shell for a while now. The good news is that loading the module in compatibility mode works:

Next, we move on to Exchange Online PowerShell. As mentioned already, the good old “remoting” method works just fine on PowerShell Core/7, yay. What about the new, V2 module? Well there’s good news, and bad news. The bad news is that the module has a dependency on a binary not ported to .NET Core yet and in turn throws an error when trying to connect. The good news is that this only affects the “old-style” cmdlets, and you can use the new REST-based ones just fine:

For the “old-style” cmdlets, use the –UseWindowsPowerShell switch or you can just use the good old PS remoting method. Of course modern auth support will soon be required and this will no longer be possible, but until then I can take advantage of the CA policy I’ve configured with my home PC excluded and run my “O365 connectivity” script:

Just to be clear, I’m not recommending you folks to use the “old” connectivity method, in this day and age protecting your accounts with MFA is a must. But boy, it’s convenient… 🙂

Moving on, the Microsoft Teams module will happily authenticate you (via the device code flow, which is far from ideal), but will then fail with another dependency:

So, back to using the compatibility mode:

Lastly, the SharePoint Online module also fails with ADAL dependency, but works OK if you import it via the compatibility switch.

At this point I got bored and skipped testing all the remaining modules 🙂

Do note that whatever remarks I made above are all said with respect to Office 365. PowerShell 7 is a major release with important compatibility and performance improvements, tons of functionality added, and the .NET Core 3.1 support brings support for Windows Forms among other things. Better error handling, support for Files on demand, parallel ForEch-Object, very useful new operators and more awaits you.

Go update now: https://github.com/PowerShell/PowerShell/releases