Disabling TLS 1.0 may cause Outlook to crash

Disabling TLS 1.0 may cause Outlook to crash for some of your clients.

I encountered this recently while upgrading a customer from Exchange 2010 to Exchange 2016. The customer had an existing Kemp Load Balancer they had been using for Exchange 2010. We upgraded the Kemp to the latest firmware and created a new Exchange 2016 VIP using the latest templates from Kemp. When we cut over our DNS to the new VIP, some of our Outlook clients started to receive the errors below. Other Outlook clients continued to operate without incident.

For some Outlook clients, we would receive errors when creating a brand new profile in Outlook. Errors such as,“Windows Shell Common DLL has stopped working”

Clicking “Close Program” would then be followed by an error reporting that “System resources are critically low”.

Clicking OK would then prompt Outlook to close. Upon further investigation of the event logs, we would see OLMAPI32.DLL was the faulting module.

In other instances of profile creation, we would receive the warning “You must restart Outlook for these changes to take effect”.

When we clicked OK we were immediately presented with a message that reported: “Cannot start Microsoft Outlook”.

If we tried to open Outlook from the icon we were prompted that “Outlook cannot log on”.

Existing Outlook profiles would remain in a disconnected state.

What made the issue particularly odd was that Outlook 2016 would throw these errors on some machines and yet work on others. So this was not an instance of Outlook incompatibility. What we discovered was that it was actually the underlying operating system. Outlook on Windows 8.1 or Windows 10 would continue to work fine. However, Outlook on an older operating system such as Windows 7 would throw the errors identified above.

We also determined, by manipulating HOSTS files, that pointing directly to an Exchange server made the errors go away. For our environment, this indicated that something with Kemp’s configuration was the root cause of our issue. We compared the problem VIP against a known working VIP (built from an older version of the Exchange 2016 template). We found that TLS 1.0 was disabled on the problem VIP, but enabled on the known working VIP. This made sense as  TLS 1.0 is still enabled by default on Exchange 2016 servers.

Note: At the time of writing, the Exchange product team recommends keeping TLS 1.0 enabled on your Exchange servers. This guidance will likely change in future cumulative updates. When Microsoft updates their guidance on TLS 1.0, we will update this document.

Solution 1 – Enable TLS 1.0 (less secure)

The first and simplest option is to enable TLS 1.0 on the VIP. While TLS 1.0 is an older protocol–we certainly want to move away from it at some point–Microsoft is currently recommending keeping TLS 1.0 enabled on our Exchange servers. As an extension of this, we should keep TLS 1.0 enabled on our Exchange 2016 VIP as well.

To do this, log into your Kemp Load Balancer, expand Virtual Services, and select View/Modify Services. From here, click Modify to the right of your Exchange 2016 VIP. Expand SSL Properties, and next to Supported Protocols, check the box TLS 1.0. This setting takes effect immediately.

Solution 2 – Don’t use TLS 1.0 (more secure)

The second option is to leave TLS 1.0 disabled on the VIP. At face value, that might indicate that you need to update all your client operating systems to either Windows 8.1 or 10. However, there is also a solution for Windows 7.

We had already enabled TLS 1.0 on our VIP to solve our issue. But then we ran across this great article from Chris Schrimsher to force Windows 7 clients to use TLS 1.1 or 1.2.

In summary, Chris recommends all Windows 7 machines be patched with the optional update KB3140245 and then requires the creation of two registry keys to force Windows 7 to use TLS 1.1 and later. Both tasks you could easily accomplish with System Center (or WSUS & GPOs)

https://blogs.technet.microsoft.com/schrimsher/2016/07/08/enabling-tls-1-1-and-1-2-in-outlook-on-windows-7/

Further Reading: Exchange TLS & SSL Best Practices

Have you run into this error? Which solution have you deployed? Or is this a non-issue because your organization is running Windows 8.1 and newer? Drop a comment below or join the conversation on Twitter @SuperTekBoy.