Tag Archives: TLS 1.2

Install-Module MSOnline fails with unable to download from URI

When installing the MSOnline module using the Install-Module MSOnline command in PowerShell it fails with a cryptic error like:

WARNING: Unable to download from URI ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’ to ”.
WARNING: Unable to download the list of available providers. Check your internet connection.
PackageManagement\Install-PackageProvider : No match was found for the specified search criteria for the provider ‘NuGet’. The package provider requires ‘PackageManagement’ and ‘Provider’ tags. Please check if the specified package has the tags.


WARNING: Unable to download from URI ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’ to ”.
WARNING: Unable to download the list of available providers. Check your internet connection.
PackageManagement\Get-PackageProvider : Unable to find package provider ‘NuGet’. It may not be imported yet. Try ‘Get-PackageProvider -ListAvailable’.
Install-Module : NuGet provider is required to interact with NuGet-based repositories. Please ensure that ‘’ or newer version of NuGet provider is installed.

As shown in the following screenshot:


It turns out that this is a TLS issue, PowerShell does not use TLS 1.2 by default, while Microsoft requires TLS 1.2 from clients. To set TLS 1.2 usage for PowerShell, you can use the following command:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Now if you try again, it will install the MSOnline module:

Install-Module MSOnline

This is a per session setting, if you want to enable it for all sessions, add the previous command to the Microsoft.PowerShell_profile.ps1 and Microsoft.PowerShellISE_profile.ps1 profiles (use Notepad $Profile for this.

More information

Azure ActiveDirectory (MSOnline) – https://docs.microsoft.com/en-us/powershell/azure/active-directory/install-msonlinev1?view=azureadps-1.0

Exchange 2010 and TLS 1.2

In a previous blogpost I discussed an issue I had with Outlook 2010 and TLS 1.2. At the same time this reminded me that Microsoft will remove support for TLS 1.0 and TLS 1.1 in Office 365 on October 31, 2018 as communicated in https://support.microsoft.com/en-us/help/4057306/preparing-for-tls-1-2-in-office-365. This means that when you have communication issues with Office 365 because of an older and weaker protocol, you won’t get any support. Time to do some research….

Existing Exchange 2010 environment

As you may have seen on this side, I still am a big fan of Exchange 2010 and also have an pure Exchange 2010 hybrid environment up-and-running and it looks like this:


MX records is pointing to my Exchange 2010 Edge Transport Server (running on Windows 2008 R2), webmail and Autodiscover are routed via an F5 LTM load balancer to an Exchange 2010 CAS/HUB/Mailbox server (also running on Windows 2008 R2), and hybrid is configured directly on Exchange 2010 (for hybrid mail flow I’m using a separate FQDN, o365mail.inframan.nl) without any Exchange 2013 or Exchange 2016 server.

So, how do you test which TLS version is used by your Exchange 2010 server? In Exchange 2010 this should be done using the protocol logfiles. Message headers in Exchange 2010 do not contain enough information for showing this TLS information. So, you must enable protocol logging for the appropriate Receive Connectors and Send Connectors. In my environment this means the Default Receive Connector on the Exchange 2010 Edge Transport server (for O365 traffic from other tenants), the Default-First-Site-Name to Internet Send Connector, and both connectors between the Exchange 2010 server and Office 365 for hybrid. Analyzing the protocol logfiles can best be done in Excel (import as CSV files). When analyzing, look for a string like TLS protocol SP_PROT_TLS1_0_SERVER (when receiving) or TLS protocol SP_PROT-TLS1_0_CLIENT (when sending). When TLS 1.2 is used, look for a string like TLS protocol SP_PROT_TLS1_2_SERVER and TLS protocol SP_PROT-TLS1_2_CLIENT.

Continue reading Exchange 2010 and TLS 1.2

Outlook 2010 disconnected with TLS 1.2

When my normal laptop died last week I had to use an older laptop, and this laptop had Windows 7 and Outlook 2010 installed, one of my personal favorite Outlook clients.

However, Outlook 2010 did work correctly with Mailboxen in Exchange Online, but Outlook refused to work with Mailboxen on my on-premises Exchange 2016 server. The only thing I saw in the lower right corner was “Disconnected” and every now and then Outlook tried to connect, but no luck.


When checking the Connection Status in Outlook I could see that the directory connection was established, but the Exchange Connections disconnected. The Exchange sever and mailbox were ok since I was able to connect using OWA and my Outlook for iPhone client.


The Test Email AutoConfiguration option in Outlook wasn’t very helpful either, it just showed that it was unable to determine the settings and none of the Autodiscover options worked.



Using the Internet Explorer browser I tried to access my Autodiscover.exchangelabs.nl site, and after a logon prompt I got the famous ErrorCode 600. This is good, so I know my Autodiscover is at least listening properly.


The Exchange Remote Connectivity Analyzer (http://aka.ms/exrca) showed that there was an issue with my SSL certificate:


The SSL certificate however is a valid Digicert UC certificate and there’s nothing wrong with this certificate. IE does use it, and the Digicert help utility doesn’t show anything strange either.


Oh, and my Outlook 2016 running on another computer did work correctly, so there should be a configuration error impacting Outlook 2010 only.

Then I realized that a week before I accidentally ruined the Virtual Service on my Kemp Load Balancer and I quickly created a new Virtual Service using the correct template. As a security measure I only selected TLS 1.2 on the SSL properties of the Virtual Service.


After enabling TLS 1.0 on the Virtual Service, Outlook 2010 started to work correctly again and (to my surprise) so did the Remote Connectivity Analyzer.



So, obviously TLS 1.0 was the culprit here and by enabling TLS 1.0 Outlook 2010 started to work again.

When checking my laptop using the SSLLABS website (https://www.ssllabs.com/ssltest/viewMyClient.html), all looks fine and TLS 1.2 is fully supported by my Windows 7 client:


It must be something with Outlook 2010 and TLS1.2. I found an interesting article on Technet regarding enabling of TLS 1.1 and TLS 1.2. Create a DWORD value DefaultSecureProtocols in the registry under the following keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

Its value should be one of the following:

For only TLS 1.1 and 1.2: A00 (hexadecimal)

For TLS 1.0, 1.1, and 1.2: A80 (hexadecimal)


Also, create the following DWORD values DisabledByDefault in the following locations and assign it the value of ‘0’:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client


When needed create the necessary subkeys under the \Protocols key.

Now your Windows 7 and Outlook 2010 will support a TLS 1.2 environment only (this is also true for Windows 8 BTW).


Outlook 2010 does not support TLS 1.2 out of the box. This can be an issue if you or your network department starts implementing a TLS 1.2 environment only. You have to enable TLS 1.2 on the workstation by setting a registry key. After this it works fine.

Next October Microsoft will stop support for TLS 1.0 and TLS 1.1. This means that if you run into an issue caused by TLS 1.0 or TLS 1.1 it won’t be fixed. Please note that Microsoft will continue to accept TLS 1.0 and TLS 1.1 connection from clients, it just won’t be supported anymore.

Microsoft is working on a plan to disable TLS 1.0 and TLS 1.1 but that won’t happen anytime soon. When this is going to happen, Microsoft will give notification 6 months in advance of disabling TLS 1.0 and TLS 1.1.

More information





Last edited on October 26, 2018.