EXO V2 module, earlier .NET versions and pesky TLS1.0/1.1

It’s been a while that the new module for managing Exchange Online using PowerShell.If not yet aware, please check out how to Use the Exchange Online PowerShell V2 module.

It’s not perfect (yet!), but huge improvements and Microsoft is working hard to get the module improved.

On my transition to the new module, I was made aware of connectivity issues by some colleagues:

New-ExoPSSession : An error occurred while sending the request..
At C:\Program Files\WindowsPowerShell\Modules\ExchangeOnlineManagement\0.3582.0\ExchangeOnlineManagement.psm1:401 char:30…

PSSession = New-ExoPSSession -ExchangeEnvironmentName $ExchangeEnviro …

But the issue existed ONLY when using the parameter -Credential


I was approached by several colleagues, that on some machines or servers there was no way of connecting to Exchange Online using the parameter -Credential. Not when the interactive authentication flow was used. The problem is that in a scheduled task you need to use this parameter.


I started comparing a lot of things, but couldn’t find the anything obvious and also the error wasn’t helpful.

The issue in this particular scenario:

The module doesn’t show the actual error. It just fails, but don’t pass the origin error to the user.

Therefore, I loaded the DLL and run the function New-ExoPSSession manually:

Import-Module "C:\Program Files\WindowsPowerShell\Modules\ExchangeOnlineManagement\Microsoft.Exchange.Management.ExoPowershellGalleryModule.dll" -Force

Note: Based on the path you might noticed something: PSVersion 4.0 (an older WMF)!

As next I run the function and was able to see the origin error:

This gave me a hint as I knew that we had disabled weak TLS ciphers on our ADFS servers, but why was it working interactively?

The difference is quite simple:

When you are using the interactive methode, the settings from your IE is used and here SSL and weak TLS versions are most likely disabled.

When you’re using credential, the module uses pure .NET and here it highly depends on the installed version, whether the OS (which would have been fine) or the .NET defaults are used.


In the install instructions of the module it is mentioned that for older versions .NET Framework 4.5 or later is required:

Install and maintain the Exchange Online PowerShell V2 module

But when you’re running a version older than .NET 4.7, the default is to use these weak ciphers. In combination with hardened ADFS this can lead into this scenario. You can read about the .NET defaults here.

In order to get pre 4.7 versions fixed, you just have to add the following registry keys and open a new PowerShell:

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 0 /f /reg:64
reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 0 /f /reg:32

Now you might say that you don’t care as you don’t have ADFS in place. Correct, but bear in mind that Microsoft 365 will deprecate TLS1.0 soon:

Preparing for TLS 1.2 in Office 365 and Office 365 GCC


Of course you can add the registry hack in order to get things working, but I rather recommend updating to the latest .NET version if possible. There are so many security related bug fixes in .NET.

Besides of this, I would love to see the module returns the origin error, just in case for further weird errors. Let’s see: I’ve sent my wishes to the PG.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s