You can then proceed with typing your credentials, meeting the MFA challenge or performing passwordless authentication, depending on what’s configured for your account/organization. In effect, when you issue the Connect-ExchangeOnline cmdlet without any parameters, the default browser will be launched and the familiar Azure AD login page will be displayed. The “browser-based SSO” method alleviates some of the annoyances by leveraging a clever workaround of sorts, redirecting the response (and the token) to a local HTTPS listener. While this flow is designed to be used on devices with limited input capabilities, it’s also the default method for some PowerShell modules running in “core” environments, even if the device is capable to use the browser control. If you have used some of the “cloud” PowerShell modules on a PSCore install, you might have experienced the annoyance of having to go over the device code flow in order to complete the authentication process. Let’s start with the new “browser-based SSO” method. I do want to point few facts that I personally find interesting though. Since the announcement at Ignite, quite few public preview versions of the module have been made available, so people that were interested in PowerShell 7 support have most likely already tested it and I will not go over many details here. In other words, we now have cross-platform support for running Exchange Online PowerShell cmdlets!

The biggest improvement this version brings is support for running the module on PowerShell 7+ instances, as announced back at Ignite.

Yesterday, Microsoft officially released the 2.0.4 version of the Exchange Online V2 PowerShell module.

Azuread powershell 7