{"id":1517,"date":"2020-08-27T01:00:00","date_gmt":"2020-08-27T01:00:00","guid":{"rendered":"http:\/\/inswwdev.azurewebsites.net\/au\/insights\/uncategorized\/exchange-2016-free-busy-not-working-maybe-tls-1-0-1-1-are-the-culprit\/"},"modified":"2020-08-27T01:00:00","modified_gmt":"2020-08-27T01:00:00","slug":"exchange-2016-free-busy-not-working-maybe-tls-1-0-1-1-are-the-culprit","status":"publish","type":"post","link":"https:\/\/www.insentragroup.com\/us\/insights\/geek-speak\/modern-workplace\/exchange-2016-free-busy-not-working-maybe-tls-1-0-1-1-are-the-culprit\/","title":{"rendered":"Exchange 2016 Free\/Busy Not Working? Maybe TLS 1.0 & 1.1 are the Culprit"},"content":{"rendered":"

Firstly, it would be worthwhile to read Microsoft\u2019s\u00a0troubleshooting wizard<\/a>\u00a0which walks you through a resolution for the free\/busy issue as it relates to hybrid. The type of free\/busy issue I want to discuss here is more as it relates to on-prem deployments, specifically when a Windows 2016 server is new in the environment.\u00a0 <\/span><\/p>\n

So, you have the shiny and new Exchange<\/span>, configured and in coexistence with the other Exchange 2016 servers: or Exchange 2010 if you are upgrading.\u00a0 You\u2019ve followed all the guides and documentation exactly and everything is looking great, so you move over a test mailbox and begin trialing the functionality.\u00a0 You notice that when trying to view availability in the calendar you can\u2019t.\u00a0 You go back through everything, all the virtual directories are configured, there are no permissions blocking or missing and nothing is blocking the network between the servers. <\/span><\/p>\n

One of the more telling signs of this issue is when you\u2019re reviewing logs and events and you are consistently seeing an error, typically Event ID 4002:<\/span><\/p>\n

\"\"<\/span><\/p>\n

The telling line is:<\/span><\/p>\n

\u201c\u2026System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host\u201d <\/span><\/p>\n

In the <\/span>error logs you might see \u201cProxy web request fail, inner exception: The underlying connection was closed.\u201d Based on my research this issue can be caused by a lot of different things, with an equal number of potential fixes to try, based on whichs forums you\u2019re seeing.\u00a0 \u00a0\u00a0<\/span><\/p>\n

TL-WHAT NOW?<\/h3>\n

Transport Layer Security is the successor to Secure Sockets Layer (SSL) and is a way to provide secure communications over a computer network.\u00a0 It is used to ensure the communication between the services (server to server or client to server for example) is private and helps prevent it from being fiddled with while in transit.\u00a0 This is done with authentication and integrity checks against the message authentication code to validate there are no losses or alterations.\u00a0 It is essential to help protect data and is in use in more places than you may realize.\u00a0 <\/span><\/p>\n

GREAT, HOW DO I FIX IT?<\/h3>\n

This is really a strange one, not long ago Microsoft had been pushing to sunset TLS 1.0 and 1.1 and has been vocal about requiring 1.2 to access Microsoft 365 services.\u00a0 They published a series of blogs about getting ready for TLS 1.2<\/a> and no longer utilizing the older protocols.\u00a0 I recently ran into the issue of free\/busy which I described above, and there was a lot of head scratching because it was between three brand new Exchange 2016 servers!\u00a0 In this case the fix was to disable the usage of 1.0 and 1.1 in the environment completely and to put the following registry keys on all of the <\/span>\u00a0<\/span><\/p>\n

[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]”SchUseStrongCrypto”=dword:00000001 <\/span><\/p>\n

[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv4.0.30319] “SchUseStrongCrypto”=dword:00000001<\/span><\/p>\n

\u200bThese two keys force the server to always use TLS 1.2, however it will require a reboot before they will take effect. Once the keys were placed in the Exchange servers the free\/busy issue was immediately cleared up! \u00a0\u200b<\/p>\n

\u200b\u200bA quick note, which it would be worthwhile to walk through is Microsoft\u2019s Exchange guide to prepare for TLS 1.2. Part 1<\/a> is the investigation and preparation of the servers, Part 2<\/a> walks through enabling 1.2 on Exchange servers and Part 3<\/a> provides guidance for disabling the old protocols in the environment.<\/p>\n

\u200bI subsequently had two more customers who had very similar issues with their on-premises environments, with different setups (2010 & 2016 coexistence). The fix in both cases was to use the above stated registry keys to force the 2016 servers to communicate on TLS 1.2.<\/p>\n

Hopefully, this resolves your free\/busy issue once you\u2019ve also investigated and tried some of the more conventional methods (hint: check your network). If you have any questions or need assistance, please don\u2019t hesitate to reach out to Insentra!\u200b\u200b\u200b<\/p>\n","protected":false},"excerpt":{"rendered":"

Firstly, it would be worthwhile to read Microsoft\u2019s\u00a0troubleshooting wizard\u00a0which walks you through a resolution for the free\/busy issue as it relates to hybrid. The type of free\/busy issue I want to discuss here is more as it relates to on-prem deployments, specifically when a Windows 2016 server is new in the environment.\u00a0 So, you have… Continue reading Exchange 2016 Free\/Busy Not Working? Maybe TLS 1.0 & 1.1 are the Culprit<\/span><\/a><\/p>\n","protected":false},"author":53,"featured_media":1518,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[19],"tags":[],"class_list":["post-1517","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-modern-workplace","entry"],"_links":{"self":[{"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/posts\/1517","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/comments?post=1517"}],"version-history":[{"count":0,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/posts\/1517\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/media\/1518"}],"wp:attachment":[{"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/media?parent=1517"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/categories?post=1517"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/tags?post=1517"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}