Want more control over Sent Items when using shared mailboxes?
Edit 6/15/2015: We are starting to make this feature available again in Office 365. Note that the new shared mailbox Sent Items behavior is disabled by default. If you want to enable it for your users, you can do so by using cmdlets mentioned below. Additionally, we are still on track to ship this to our on-premises customers in Exchange 2013 CU9, as mentioned before. Whether a mailbox is used by multiple users as a collaborative tool or a communication gateway to customers, retaining a record of emails sent from a shared mailbox remains an important business requirement. In Exchange 2010, there was a way to configure this behavior, but we did not have this feature starting with Exchange 2013. Our customers have told us that a shared mailbox should keep a copy of emails sent from the mailbox by all members of the mailbox in its own Sent Items folder. We have taken that feedback and decided to make some changes to how sent mails are handled for shared mailboxes. We are excited to announce that once this feature is enabled for you (see below), by default all shared mailboxes will retain a copy of emails sent from the mailbox. You will no longer have to figure out which mailbox member sent an email as the shared mailbox or on behalf of it. How does it work? Emails can be sent as the shared mailbox itself or on behalf of it by member(s) of the mailbox, assuming proper permissions have been granted. This feature is designed to retain a copy of an email sent from the shared mailbox in the Sent Items folder of the shared mailbox. The same behavior can be expected for emails sent on behalf of the shared mailbox, when configured to do so. A copy of the sent mail will also reside in the Sent Items folder of the member’s personal mailbox. Note: If the user has used the Outlook 2013 feature to change the folder that Sent Items are saved to, the messages will be copied to that folder instead of the user’s Sent Items folder. Users can reconfigure this by clicking the “Save Sent Items To” button on the Email Options tab. Administrators have control over this feature for either mails Sent As or Sent on Behalf of a shared mailbox. The table below summarizes where sent mails reside when members of a shared mailbox send mail from the shared mailbox. User Mailbox Shared Mailbox Sent Items Exchange 2010 Exchange 2010 Controlled through settings in KB2632409 Exchange 2010 Exchange 2013 (any version) Controlled through settings in KB2632409 Exchange 2013 CU9 (or newer) Office 365 Exchange 2010 The sent mail will be delivered to both the Inbox of the shared mailbox as an email attachment* and to the user mailbox' sent items Exchange 2013 CU9 (or newer) Office 365 Exchange 2013 CU9 (or newer) Office 365 The sent mail will be delivered to the Sent Items folder of shared mailbox and to the user mailbox' sent items *In a scenario where the user’s mailbox is on an Exchange 2013 CU9 server (or an Exchange 2013 without CU9 installed) and the shared mailbox is on an Exchange 2010 server, the shared mailbox will get an email message that looks like the following: This behavior will continue until the shared mailbox is moved to an Exchange 2013 CU9 server. Because this can happen even between Exchange 2013 servers (pre-CU9 and CU9), you might want to wait in turning the feature on for your on-premises deployment until you have completely rolled out Exchange 2013 CU9 to all of your servers. Who can use this feature? The feature is going to be available to all customers with shared mailboxes in Office 365 (phased rollout starting on 6/15/2015), as well as our on-premises customers (starting with Exchange 2013 CU9). Note: if after installation of Exchange 2013 CU9 in an on-premises environment you do not see the new CMDlet parameters, you should run /preparead explicitly with CU9 setup. How do I enable/disable this feature? In Office 365 and Exchange 2013 CU9, this feature is disabled by default. Enable the feature In Office 365, using the Admin portal, you can select your shared mailbox by going to Groups > Shared mailboxes first: Then Edit the Sent items copy status of the mailbox: Using PowerShell, for emails Sent As the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSentAsEnabled $True For emails Sent On Behalf of the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSendOnBehalfEnabled $True Disable the feature For messages Sent As the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSentAsEnabled $False For emails Sent On Behalf of the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSendOnBehalfEnabled $False What else do I need to know? The administrator for your organization has to create the shared mailbox and add you to it as an user, before you can use it. If you are an Office 365 Small Business administrator, see Create and use shared mailboxes. If you are an administrator for a different version of Office 365 or an on-premises Exchange administrator, see the TechNet article Create a Shared Mailbox. If you are currently using a client registry key to duplicate messages sent from a shared mailbox to a sent items folder of the sender, you should remember to remove client registry keys if you enable this feature server side. If you do not remove client registry keys, you could see duplicate messages in Sent Items folders (one created by client registry keys and one by the server). If one of the transport rules prevents messages larger than certain size and the message being sent is over that size, then the message will not be delivered to the its original recipient and will also not be copied to the sent items of the shared mailbox. Philip LohExchange Server TLS guidance Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It
Update: please see our official documentation which is now available on this subject: Exchange Server TLS configuration best practices. Overview In part 2 of our Exchange Server TLS Guidance series we focus on enabling and confirming TLS 1.2 can be used by your Exchange Servers for incoming and outgoing connections, as well as identifying any incoming connection which is not utilizing TLS 1.2. The ability to identify these incoming connections will vary by Windows Server OS version and other factors. Part 2 will not cover disabling TLS 1.0 or TLS 1.1, nor disabling older cipher suites from being used. Part 3 of the TLS guidance series will go into detail on those topics. Assumption For Part 2 of our TLS guidance series we assume you have already audited your on-premises Exchange Servers and applied all updates called out in Part 1: Getting Ready for TLS 1.2. Please perform the activities called out in part 1 if you have not prior to moving forward with any configurations outlined in part 2. Enabling TLS 1.2 The method used to enable TLS 1.2 varies by the version of the Windows Server operating system. Some versions of Windows Server have TLS 1.2 enabled by default while others do not. Our steps will, regardless of the OS’ default state, configure TLS 1.2 so it is enabled and available for incoming (Server) connections and outgoing (Client) connections. From part 1 you should be familiar with the various components Exchange Server relies on such as Schannel, WinHTTP and .NET. Unless stated otherwise the same registry paths are used across all supported Windows Server operating systems. Enable TLS 1.2 for Schannel All Windows Server versions TLS protocols are enabled or disabled in Windows Schannel by editing the Windows Registry. Each protocol version can be enabled or disabled independently. You don't need to enable or disable one protocol version to enable or disable another protocol version. The Enabled DWORD registry value defines whether the protocol version can be used. If the value is set to 0, the protocol version cannot be used, even if it is enabled by default or if the application explicitly requests that protocol version. If the value is set to 1, the protocol version can be used if enabled by default or if the application explicitly requests that protocol version. If the value is not defined, the operating system’s default value will be used. We recommend configuring the value to have a consistent state across your servers. The DisabledByDefault DWORD registry value defines whether the protocol version is used by default. This setting only applies when the application doesn't explicitly request the protocol versions to be used. If the value is set to 0, the protocol version will be available for use by default. If the value is set to 1, the protocol version will not be available for use by default. If the value is not defined, the operating system’s default value will be used. We recommend configuring the value to have a consistent state across your servers. For example; consider what would happen if TLS 1.2’s values were set to a combination of Enabled and DisabledByDefault both set to a value of 1. In this example an application could only use TLS 1.2 if the application specifically called for TLS 1.2. If the application did not specifically call for TLS 1.2, then it would not be able to use TLS 1.2 as even though the protocol is enabled, it is not in the default list of available protocols. To enable TLS 1.2 for both server (inbound) and client (outbound) connections on an Exchange Server please perform the following. From Notepad.exe, create a text file named TLS12-Enable.reg. Copy and paste the following text into the file. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 Save TLS12-Enable.reg. Double-click the TLS12-Enable.reg file. Click Yes to update your Windows Registry with these changes. Restart the machine for the changes to take effect. Enable TLS 1.2 for .NET 3.5 This step is only required for Exchange Server 2010 installations where .NET 3.5 is relied upon. Exchange Server 2013 or later installations may skip this step unless you have additional applications on the server utilizing .NET 3.5 which must be able to use TLS 1.2. The SystemDefaultTlsVersions registry value defines which security protocol version defaults will be used by .NET Framework 3.5. If the value is set to 0, then .NET Framework 3.5 will default to using SSL 3.0 or TLS 1.0. If the value is set to 1, then .NET Framework 3.5 will inherit its defaults from the Windows Schannel DisabledByDefault registry values. If the value is undefined, it will behave as if the value is set to 0. By configuring .NET Framework 3.5 to inherit its values from Schannel we gain the ability to use TLS 1.2. From Notepad.exe, create a text file named NET35-UseSchannelDefaults.reg. Copy, and then paste the following text. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 Save the NET35-UseSchannelDefaults.reg file. Double-click the NET35-UseSchannelDefaults.reg file. Click Yes to update your Windows Registry with these changes. Restart your computer for the change to take effect. Enable TLS 1.2 for .NET 4.x This step is only required for Exchange Server 2013 or later installations where .NET 4.x is relied upon. The SystemDefaultTlsVersions registry value defines which security protocol version defaults will be used by .NET Framework 4.x. If the value is set to 1, then .NET Framework 4.x will inherit its defaults from the Windows Schannel DisabledByDefault registry values. If the value is undefined, it will behave as if the value is set to 0. By configuring .NET Framework 4.x to inherit its values from Schannel we gain the ability to use the latest versions of TLS supported by the OS, including TLS 1.2. From Notepad.exe, create a text file named NET4X-UseSchannelDefaults.reg. Copy, and then paste the following text. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 Save the NET4X-UseSchannelDefaults.reg file. Double-click the NET4X-UseSchannelDefaults.reg file. Click Yes to update your Windows Registry with these changes. Restart your computer for the change to take effect. Note: When configuring a system for TLS 1.2, you can make the Schannel and .NET registry keys at the same time and reboot the server once. Validating TLS 1.2 is in use and identifying older incoming connections. Once TLS 1.2 has been enabled it may be helpful to validate your work was successful and the system is able to negotiate TLS 1.2 for inbound (server) connections and outbound (client) connections. We will provide a few methods for validating this. HTTP Based Protocols Many protocols used in Exchange Server are HTTP based, and therefore traverse the IIS processes on the Exchange server. MAPI/HTTP, Outlook Anywhere, Exchange Web Services, Exchange ActiveSync, REST, OWA & EAC, Offline Address Book downloads, and Autodiscover are examples of HTTP based protocols used by Exchange Server. Windows Server 2016 and Windows Server 2012 R2 The IIS team has added capabilities to Windows Server 2016 and Windows Server 2012 R2 to log custom fields related to encryption protocol versions and ciphers. We recommend reviewing the following blog for documentation on how to enable these custom fields and begin parsing logs for information on incoming connections in your environment related to HTTP based protocols. https://cloudblogs.microsoft.com/microsoftsecure/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/ Windows Server 2008 through 2012 Unfortunately, the IIS custom fields mentioned above do not exist for Windows Server 2008 SP2 through Windows Server 2012. You may have to rely on alternate methods to validate TLS 1.2 is in use on these versions of Windows Server for HTTP based protocols. Your load balancer or firewall logs may be able to provide this information. Please request guidance from your vendors to determine if their logs may provide this information. Message Headers (Exchange Server 2016 Only) Message header data in Exchange Server 2016 provides the protocol negotiated and used when the sending and receiving host exchanged a piece of mail. While this is a more manual method of checking how mail arrived it can be used for testing between specific systems in a pinch. Example when viewing message header data via Message Header Analyzer at https://testconnectivity.microsoft.com Note: There is one known exception to the message headers example. When a client sends a message by connecting to a server using authenticated SMTP (also known as the SMTP client submission protocol), the TLS version in the messages headers does not show the correct TLS version used by a customer’s client or device. Microsoft is investigating the possibility of adding this information in a future update. Mail Flow via SMTP Logging SMTP Logs in Exchange 2010 through Exchange 2016 will contain the encryption protocol and other encryption related information used during the exchange of email between two systems. When the server is the SMTP receiving system, the following strings exist in the log depending on the version of TLS used. TLS protocol SP_PROT_TLS1_0_SERVER TLS protocol SP_PROT_TLS1_1_SERVER TLS protocol SP_PROT_TLS1_2_SERVER When the server is the SMTP sending system, the following strings exist in the log depending on the version of TLS used. TLS protocol SP_PROT-TLS1_0_CLIENT TLS protocol SP_PROT-TLS1_1_CLIENT TLS protocol SP_PROT-TLS1_2_CLIENT Example entries from Exchange Server 2010 A server sending mail to another system using TLS 1.2: 2018-02-22T13:53:10.494Z,<CONNECTORNAME>,08D578EB9C3F6C39,28,10.0.0.240:15443,192.168.1.42:25,*,,"TLS protocol SP_PROT_TLS1_2_CLIENT negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA_384 with strength 384 bits and key exchange algorithm CALG_ECDHE with strength 384 bits" A server receiving mail from another system using TLS 1.2: 2018-02-22T13:50:37.681Z,SERVERNAME\CONNECTORNAME Internet,07C578BB0E912319,22,10.0.0.241:25,192.168.1.102:63767,*,,"TLS protocol SP_PROT_TLS1_2_SERVER negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA_384 with strength 384 bits and key exchange algorithm CALG_ECDHE with strength 256 bits" POP/IMAP No logging exists which will expose the encryption protocol version used for POP & IMAP clients. To capture this information, you may need to capture netmon logs from your server or inspect traffic as it flows through your load balancer or firewall where HTTPS bridging is taking place. Source IP Obfuscation and identifying clients using older TLS protocol versions. In many deployments by the time client connections reach the Exchange Server, the source IP of the incoming client connection has been replaced with the IP address of your load balancer or firewall. While you are still able to identify if TLS 1.2 is being used by these connections and validate your servers are operating properly, you may be unable to identify exactly what machine is responsible for the incoming client connection if it is still using older TLS protocol versions. In this scenario you may need to request guidance from the vendor of your load balancer of firewall to be able to parse the logs of those devices to find the true IP of the incoming connection, so you may ensure those machines are also properly updated and configured. Additional Considerations There are many more considerations beyond Exchange Server when making any changes to cryptography settings within an environment. Considerations such as (but not limited to): Do your Domain Controllers and Global Catalog servers support TLS 1.2? Do partner applications (such as, but not limited to, SharePoint, Lync, Skype, etc...) support TLS 1.2? Have you updated older Windows 7 desktops using Outlook to support TLS 1.2 over WinHTTP? Do your load balancers support TLS 1.2 being used? Do your desktop, mobile, and browser applications support TLS 1.2? Do devices such as multi-function printers support TLS 1.2? Do your third-party or custom in-house applications that integrate with Exchange Server or Office 356 support TLS 1.2? The point to take home here is while we can provide guidance for interacting with Office 365, Exchange Server, and other Microsoft products - we cannot guarantee everything in your environment will be unaffected. As such we strongly recommend any steps you take to transition to TLS 1.2 and away from older security protocols are first performed in labs which simulate your production environments before you slowly start rolling them out in production. Action Items Configure your Exchange Servers so they can use TLS 1.2 for incoming and outgoing connections using the steps provided and validate the protocol is actively being used. Start identifying incoming connections using older versions of TLS after TLS 1.2 has been enabled and make plans for those clients if you intend to disable older TLS protocol versions. Remember, a “client” in these terms could be another server device but when we see it as an incoming connection to an Exchange Server we consider the host initiating the connection to be operating in the role of a client. Deploy the latest releases for Exchange 2010, Exchange 2013, and Exchange 2016 released in March 2018. These releases are the first to support turning off TLS 1.0 and TLS 1.1. Guidance on how to do this will be made available in Part 3 of this blog post series. Review With proper execution, you will be able to enable the TLS 1.2 protocol on any Exchange Server running an Exchange Server Cumulative or Update Rollup released after September 1, 2017 installed on OS’es as far back as Windows Server 2008 SP2. With all your Exchange Servers able to use TLS 1.2 for incoming and outgoing connections you should be well prepared for the eventual sunsetting of older TLS protocols. Equally important is understanding what incoming connections in your environment are not utilizing TLS 1.2 now that it is available and building a plan for each of those systems if you intend to disable the older TLS protocols. Brian Day Senior Program Manager Office 365 Customer ExperienceExchange Server TLS guidance, part 1: Getting Ready for TLS 1.2
Update: please see our official documentation which is now available on this subject: Exchange Server TLS configuration best practices. Overview As the realm of security in technology continues to evolve over time, every so often we say hello to newer and more competent versions of technologies while saying goodbye to their older siblings. By the time you are reading this article you may have learned Office 365 intends to stop accepting inbound network connections if they are using TLS protocol versions prior to TLS 1.2, and started to wonder how this may affect your on-premises deployments of Exchange Server. For clarity, this does not mean your on-premises deployments must disable TLS 1.0/1.1 by the time Office 365’s change takes place. It only means TLS 1.2 must be enabled and used when communicating with Office 365. Today, in part 1 of this series we will provide you with the information required to prepare your environments for using TLS 1.2, as well as, what our plans are during the next few weeks. Part 1: This blog. What you need to be ready for TLS 1.2 being enabled. ETA: The present, which is now the past Part 2: Enabling and confirming TLS 1.2 is operational in supported Exchange Server deployments. ETA: Published on 4/2/2018 Part 3: Disabling TLS 1.0 and TLS 1.1 as well as how to run a TLS 1.2-only Exchange Server deployment aligned with Office 365’s configuration. ETA: Published on 5/23/2018 In addition to the Office 365 announcement, we know there are customers interested in this topic due to the PCI DSS 3.1 that currently has an effective date of June 30 th , 2018. We are seeing an uptick in requests for guidance related to this date and want to assure you we have the guidance underway. Protocols and Components TLS versus SSL Before going further, let us take a moment to clarify TLS and SSL in case they are unfamiliar terms. In the world of Exchange Servers, it isn’t uncommon to think of the TLS protocol (Transport Layer Security) as being involved only in mail delivery processes ("Transport" kind of indicates that). For the SSL protocol (Secure Socket Layer), we most often speak to it when planning for client namespaces and ensuring we’re able to use HTTPS for a secure HTTP session. For example, during the deployment of a new Exchange organization you may hear, “Did you already get the SSL certificate for the new Exchange namespace?” The S in HTTPS does not stand for SSL, it stands for Secure. What really should be asked in the SSL example above is “Did you already get the certificate to enable HTTPS for the new Exchange namespace?” as HTTPS can (and should) be using a TLS based protocol these days rather than an older SSL protocol. TLS can be thought of as the successor to SSL and can be used anywhere two systems must exchange information over an encrypted network session. The Windows Dev Center does a nice job of summarizing this for us here and here. Additional Components In addition to the TLS and SSL protocols, there are many other terms that may be useful to cover, which will become more important in later segments of this blog series. Schannel Microsoft Exchange Server relies on the Secure Channel (Schannel) security support provider, which is a Windows component used to provide identity repudiation and in some instances authentication to enable secure, private communications through encryption. One of the roles of Schannel is to implement versions of SSL/TLS protocols to be used during client/server information exchanges. Schannel also plays a part in determining what cipher suite to be used. Cipher Suites Cipher Suite selection, in addition to the encryption protocol (TLS/SSL) used to carry out information exchanges, is another significant piece of the overall puzzle. Cipher suites are a collection of algorithms used to determine how information exchanged between two systems will be encrypted for key exchange, bulk encryption, and message authentication. As one may expect, different versions of Windows have supported an ever-evolving list of cipher suites made up of different strengths throughout the course of release. If you are a customer accustomed to configuring applications to only use Federal Information Processing Standards (FIPS) compliant algorithms, then cipher suites are nothing new to you. WinHTTP Some components of Microsoft Exchange Server rely on Microsoft Windows HTTP Services (WinHTTP). WinHTTP provides a server-supported, high-level interface to the HTTP/1.1 Internet Protocol. WinHTTP enables Exchange to retrieve enabled encryption levels, specify the security protocol, and interact with server and client certificates when establishing an HTTPS connection. .NET Last, but certainly not least, is the Microsoft .NET Framework. .NET is a managed execution environment that includes a common language runtime (CLR) that is used as an execution engine and class library which provides reusable code; a vast majority of the code that makes up Exchange Server is written for the .NET Framework. With the release of Exchange Server 2013, our references to the Information Store now being “managed code” or “managed store” were due to its complete rewrite using .NET Framework. Settings for .NET itself can have an impact on how different protocols are used when applications exchange information with other systems. There are many components Exchange Server depends on to properly implement all its encryption capabilities. Understanding what those components are, and how every component should align when adjusting cryptography settings will help you better understand the impact to Exchange Server when those changes are carried out. With those clarifications out of the way let us keep moving on. How to Prepare If you would like to prepare your Exchange environments for the upcoming TLS 1.2 configuration guidance, please align yourself by auditing your current deployment against the below set of requirements. No guidance will be provided for versions of Exchange or Windows earlier than what is listed below. By ensuring you are ready for the TLS 1.2 configuration guidance you will minimize the amount of work to enable TLS 1.2 in your environment. Any update called out as ‘current’ is as of the publishing of this article and may not remain true in the future. Exchange Server versions Exchange Server 2016 Install Cumulative Update (CU) 8 in production for TLS 1.2 support and be ready to upgrade to CU9 after its release if you need to disable TLS 1.0 and TLS 1.1. Install the newest version of .NET and associated patches supported by your CU (currently 4.7.1). Exchange Server 2013 Install CU19 in production for TLS 1.2 support and be ready to upgrade to CU20 after its release if you need to disable TLS 1.0 and TLS 1.1. Install the newest version of .NET and associated patches supported by your CU (currently 4.7.1). Exchange Server 2010 Install SP3 RU19 in production today for TLS 1.2 support and be ready to upgrade to SP3 RU20 in production after its release if you need to disable TLS 1.0 and TLS 1.1. Install the latest version of .NET 3.5.1 and patches. Exchange Server versions older than 2010 Out of support. There is no path forward and you should be planning a migration to Exchange Online or a modern version of Exchange Server on-premises. As always you may refer to the Exchange Supportability Matrix if you need information related to what combinations of Exchange, Windows, and .NET Framework are supported operating together. Windows Server versions You cannot have an Exchange server without Windows Server, so don't forget to make sure you're in a good place at the operating system level to support using TLS 1.2. Many of the Schannel, WinHTTP, and. NET Framework updates require registry changes to become effective. After confirming the updates below are installed, please do not make any registry changes unless you already have custom settings you must use. We will cover registry changes for these updates in the next part of this series. Windows Server 2016 TLS 1.2 is the default security protocol for Schannel and consumable by WinHTTP. Ensure you have installed the most recent Monthly Quality Update along with any other offered Windows updates. Windows Server 2012 R2 TLS 1.2 is the default security protocol for Schannel and consumable by WinHTTP Ensure your server is current on Windows Updates. This should include security update KB3161949 for the current version of WinHTTP. If you rely on SHA512 certificates; please see KB2973337. Windows Server 2012 TLS 1.2 is the default security protocol for Schannel. Ensure your server is current on Windows Updates. This should include security update KB3161949 for the current version of WinHTTP. If you rely on SHA512 certificates; please see KB2973337. Exchange 2010 Installs Only: Install 3154519 for .NET Framework 3.5.1. Windows Server 2008 R2 SP1 TLS 1.2 is supported by the OS but is disabled by default. Ensure your server is current on Windows updates. This should include security update KB3161949 for the current version of WinHTTP. This should include optional recommended update KB3080079 which adds TLS 1.2 capability to Remote Desktop Services if you intend to connect to 2008 R2 SP1 based Exchange Servers via Remote Desktop. Also install this update on any Windows 7 machines you intend to connect from. If you rely on SHA512 certificates; please see KB2973337. Exchange 2010 Installs Only: Install 3154518 for .NET Framework 3.5.1. Windows Server 2008 SP2 TLS 1.2 is not supported by default. Ensure your server is current on Windows updates. This should include optional recommended update KB4019276. This update adds TLS 1.2 capability as a default secure protocol for Schannel. This should include security update KB3161949 for the current version of WinHTTP. If you rely on SHA512 certificates; please see KB2973337. Exchange 2010 Installs Only: Install 3154517 for .NET Framework 3.5.1. Why is having current updates helpful? It may normally go without saying, but by being on a current update you will minimize the risk of encountering any issues while applying a new update as these update paths are tested and well-known prior to the release of the new update. We would like to help you avoid any delay in deploying TLS configuration changes which could arise from battling upgrades from very old Exchange or Windows updates. In addition, with our December 2017 releases for Exchange Server, we’ve already been making underlying changes to prepare for this eventual moment in TLS' history. Starting with those releases, Exchange setup no longer overwrites the current cryptography settings of the server you're upgrading. If you have previously configured certain cryptography ciphers and their order of presentation, we will no longer reset them to our desired default configuration. For any new server installations (not an upgrade of an existing server to a new update), Exchange setup will still configure the recommended configuration as of the time the update was originally published. This will also happen if setup is run with /M:RecoverServer as we assume this is the first time Exchange is being installed on the server. If customers prefer a configuration other than our recommended out-of-the-box configuration, then you will still have to apply those updates after installing Exchange Server for the first time on a server. However, once Exchange is installed your custom cryptography config should remain in place after any future Exchange Server update. The Exchange team will continue to publish guidance on which cryptography settings we believe customers should use to optimally configure an Exchange server. What else have we been up to? Historically there were many areas within the Exchange codebase where specific cryptography protocols were hard-coded. Over the last few years we have been systematically updating all these areas and slowly converting components over to use protocols and ciphers as dictated by the underlying operating system and .NET. Progress in making these changes was intentionally done in a slow controlled manner over time to ensure stability of the product was not affected. We believe these changes should make administrators' lives easier by reducing where and how you need to configure cryptography settings for an Exchange Server. Am I a Server or a Client? Believe it or not even with Exchange 2016 the acceptance of inbound connections to the Mailbox Server role and the Edge Transport role are not the only purposes a server can have. Exchange Server is often playing the role of a client. Any time Exchange is initiating contact to another system it is effectively a client. Sending mail to another Exchange Server in your org? Client. Contacting O365 for a cross-premises F/B request? Client. Sending mail to a partner organization? Client. Doing a CRL lookup against a CDP so it can show S/MIME certificate status in OWA? Client. Proxying a client request from one Exchange Server to another? Client. Exchange obviously can also play the role of a server, as defined as the party answering a request from another system. Examples include receiving client connections, receiving inbound e-mail via SMTP, or accepting cross-forest requests from another Exchange org. Why does this matter? As you move forward with your configuration changes you must take caution to not move too quickly. Stop and take stock of not only what talks to Exchange, but what Exchange talks to as well. This may mean you have to coordinate changes across multiple environments to ensure you do not suffer any impact to service availability. In the next part of the series you will see configuration changes that refer to both Client and Server aspects of the machine. If you miss one setting you may find yourself with a system making outbound connections on older TLS protocols even though it allows incoming connections to only use TLS 1.2. In part 2 of this series we will discuss how to introduce TLS 1.2 into your environment safely while other servers may still be using TLS 1.0 or 1.1. Call to Action and Review Should you be preparing to act? Yes, we recommend all Exchange Server on-premises customers begin the transition towards using TLS 1.2. Action Items If you have not already, then please audit your systems for any updates we’ve outlined above as necessary and begin deploying them to prepare yourself for configuring TLS 1.2. Review Keep watching this space for additional information on configuring TLS 1.2, and then additional future guidance on deprecating TLS 1.0 and 1.1 from Exchange Servers. We're continuing to work with our partner teams across Microsoft to provide you with the best set of guidance and you'll continue to hear more from us to help guide you through this transition. We hope this first post is helpful in your planning and look forward to releasing the other upcoming parts! A huge debt of gratitude goes to Scott Landry, Brent Alinger, Chris Schrimsher and others for combining numerous efforts of work into this series of postings. Brian Day Senior Program Manager Office 365 Customer ExperiencePermanently Clear Previous Mailbox Info
We are introducing a new parameter that can be called by using the Set-User cmdlet in Exchange Online PowerShell. The feature is focused for customers doing migration of on-premises mailboxes to the cloud and you will be able to use it within three weeks or so (Edit 1/19: we updated this due to slower than expected rollout): Customers who have Hybrid or on-premises environments with AAD Connect / Dir Sync may have faced the following scenario: User Jon@contoso.com has a mailbox on-premises. Jon is represented as a Mail User in the cloud. You are synchronizing the on-premises directory to the cloud in preparation to migrate to Exchange Online. Due to issues with the on-premises sync or due to a configuration problem, the user Jon@contoso.com does not get the ExchangeGUID synchronized from on-premises to the cloud. If the Exchange GUID is missing from the object in the cloud, assigning an Exchange license to Jon@contoso.com will cause Exchange Online to give the user a mailbox, converting the object from a Mail User to a User Mailbox. (Adding the license is a step required for the migration of the mailbox from on-premises to the cloud.) The end result is the user that has 2 mailboxes: one on-premises and one in the cloud. This is not good. Mail flow issues will follow. Those doing these types of migrations will know that the ExchangeGUID value is very important as it helps Exchange Online identify that the user has a mailbox on-premises, and if an Exchange license is assigned in the cloud, a new mailbox should not be created. The immediate fix for this situation is to remove the Exchange License from Jon@contoso.com. This will convert the cloud object for Jon back to a Mail User. Mail flow should be restored at this point. The problem now is that you have an “unclean” cloud object for Jon. This is because Exchange online keeps pointers that indicate that there used to be a mailbox in the cloud for this user: PS C:\WINDOWS\system32> Get-User Jon@contoso.com | Select name,*Recipient* Name PreviousRecipientTypeDetails RecipientType RecipientTypeDetails ---- ---------------------------- ------------- -------------------- Jon UserMailbox MailUser MailUser Re-assigning the license after that will always err on the side of caution and Exchange Online will try to re-connect the (duplicate, temporary) mailbox in the cloud (and mailboxes can be reconnected for 30 days). Therefore Jon’s account in the cloud can’t be licensed in preparation for migration. Up to now, one of the few options to fix this problem was to delete *only in the cloud* Jon’s object and re-sync it from on-premises. This would delete jon@contoso.com from the cloud – but from all workloads, not only Exchange. This is problematic because Jon could have his OneDrive or SharePoint data in the cloud only and deleting his account means that this will be deleted too. If the account is then re-created, Jon and the tenant admin would have to work to recover to his new account all the data he used to have in OneDrive or SharePoint just because Exchange data needed to be “cleaned up”. The new parameter in the user cmdlet will allow tenant admin to clean up Exchange Online Jon’s object without having to delete it. To clean the object, you can run the following command: PS C:\> Set-User Jon@contoso.com -PermanentlyClearPreviousMailboxInfo Confirm Are you sure you want to perform this action? Delete all existing information about user “Jon@contoso.com"?. This operation will clear existing values from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY. Do you want to continue? Yes Yes to All No No to All [?] Help (default is "Y"): Y Executing this leaves you with a clean object that can be re-licensed without causing the 2-mailbox problem. Now you can on-board Jon’s on-premises mailbox following the usual steps. An alternative – a call to support to do the clean-up for you - is also not needed. Remember, cleaning up the user means that the older associated disconnected (duplicate) cloud mailbox is not recoverable. If you want to keep it or be able to check it’s content, we recommend using Soft Deletion or Inactive Mailboxes to keep the mailbox. Note: This command is expected to be executed when you have an on-premises mailbox and a mailbox in the cloud for the same object due to bad AAD Connect configuration, to clean the object that can be re-licensed. The procedure allows you get out of the dual mailbox state and enable you to re-try on-boarding the mailbox immediately. If you execute this for a user whose mailbox is cloud only after delicensing the user (and intend to later re-license the same user and expect to have a new clean mailbox for the user) - then this will not happen immediately. To avoid potential loss of mailbox data due to unintended/mistaken execution of the command, we retain the mailbox data for 30 days so that you may recover it. If your intention is to clean-up cloud only mailbox then you may hard delete the user account to re-create a clean mailbox. Mario Trigueros SolorioConfiguring Teams calendar access for Exchange on-premises mailboxes
Over the last several months, we have seen many customers adopting Microsoft Teams, even if their mailboxes are still hosted in an on-premises environment. One of the common issues in this scenario is not being able to see the Calendar tab in the Microsoft Teams client.How to Configure S/MIME in Office 365
S/MIME in Office 365 S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and digital signingof MIME data. Configuring S/MIME in Office 365 is a slightly different procedure than configuring S/MIME on-premises. This blog is for people who want to move from on-premises to Exchange Online and want to continue to use S/MIME. This article will also apply to any Office 365 customers who want to use S/MIME for sending digitally signed and encrypted mails. Configuring S/MIME will allow users to encrypt and/or digitally sign an email. S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity, non-repudiation of origin (using digital signatures), privacy, and data security (using encryption). Further, Office 365 also provides the capability for end users to compose, encrypt, decrypt, read, and digitally sign emails between two users in an organization using Outlook, Outlook Web App (OWA) or Exchange ActiveSync (EAS) clients. Below, we will take you through the configuration steps that you will need to follow to configure S/MIME for Exchange Online Only (Scenario 1), and for Exchange Hybrid(Scenario 2). Scenario 1: Exchange Online In this scenario, all the users are hosted on cloud and there is no on-premises Exchange organization. Requirements .SST File (Serialized store): The SST file contains all the root and intermediate certificates that are used when validating the S/MIME message in Office 365. The .SST file is created from certificate store explained below. End user’s certificate for signing and encrypting the message issued from Certificate Authorities(CA) either Windows based CA or Third party CA. Configuration Remember that in Exchange Online, only the SST will be used for S/MIME certificate validation. 1. Create a .SST file for the Trusted Root CA / Intermediate CA of the certificate issued to the users: You can use either Certificate MMC or PowerShellcmdlets to export SST file. I am using Certificate console to export the .SST here: Open certmgr.msc snap-in, expand Trusted Root Certificate Authorities > Certificates > select the CA Certificates which issued the certificates to end users for S/MIME and right click > All Tasks > Export… Note: There may be some Intermediate CA’s. You can move them to Trust Root CA folder and select them (including the Trusted CA certificates) and export it all in one .SST file. 2. Select Microsoft Serialized Certificate Store(.SST) > Click Next and save the SST file: 3. Upload .SST to office 365 server: Update the SST on office 365 exchange server by executing the following commands using remote PowerShell. $sst = Get-Content <sst file copied from the box>.sst -Encoding Byte (Example: $sst = Get-Content TenantRoot.sst -Encoding Byte) Set-SmimeConfig -SMIMECertificateIssuingCA $sst 4. Publish user’s certificate to the Exchange Online GAL (Global Address List) using Outlook. If not published, users will not be able to exchange S/MIME encrypted messages. Note: To publish the certificate, the user must first have the certificate installed on their local machine. On the File menu in Outlook 2013, click Options. On the Outlook Options window, click Trust Center, click Trust Center Settings..., and then click Email Security. In the Trust Center window, click Settings… (Here, you need to choose certificate issued by the CA you are going to use for S/MIME). In the Change Security Settings window, type the Security Settings Name (you can name it anything) and choose Signing and Encryption certificate. Select the appropriate certificate assigned in previous steps, leave the Algorithm default and click OK. Once the information is selected, you will notice the Default Setting is populated with Security Settings Name. Now you can click the Publish to GAL button. To publish the certificate to the GAL, click OK. 5. To confirm the certificate is published in AAD (Azure Active Directory), connect to Exchange Online using remote PowerShelland run following command. Check to make sure that the UserSMimeCertificate attribute is populated with the certificate information. If not, return to step 4. Get-Mailbox <user> | FL or FT *user* 6. Once you confirm the end user has the certificate on their machine under certificates > personal store and also published in AAD, the users can use Outlook, OWA, or EASto send and receive S/MIME messages. Note: Make sure you check S/MIME Supported Clients section below before exchanging S/MIME messages. Scenario 2: Exchange Hybrid In Exchange Hybrid topology, some mailboxes are homed on-premises and some mailboxes are homed online, and users share the same e-mail address space. Requirements: Public Key Infrastructure (PKI). You can use Active Directory Certificate Services to issue certificates to the end users. SST File (Microsoft serialized certificate store). Tenant admins will have to configure their tenant in O365 with signing certificates issuing CA & Intermediate certs information. They will have to produce a SST file, which is a collection of certificates, and then later import it into O365 to validate S/MIME. DirSync. You will need version 6593.0012 or higher of the DirSync tool. DirSync is used to synchronize the Active Directory user object to the Azure AD, so that cloud users can also see the certificate information of recipients when performing S/MIME (encrypt) operation. You can verify the DirSync version following these steps: Open Control Panel. Click Programs. Click Programs and Features. Click Windows Azure Active Directory Sync tool. Check the version as the screenshot below: Configuration: 1. Public Key Infrastructure (PKI) The users in your organization must have certificates issued for digitally signing and encryption purposes. You can either install Certificate Authority On-premises to issue certificates to the end users or have third party certificates issued to them. There are two attributes in a user object where certificate information stored: 1) UserCertificate and 2) UserSMimeCertificate. UserCertificateis populated automatically in on-premises deployment with a Windows root CA. This is populated at the time the user enrolls for a user certificate. This could be done manually for each user, or an administrator can set a GPO to automatically enroll all users. Certificates are stored in the userSMimeCertificate attribute when an Outlook client publishes a certificate to GAL. Outlook 2010 and above will populate both attributes with the same certificate http://support.microsoft.com/kb/2840546. But Outlook 2007 and below will not. http://support.microsoft.com/kb/822504 2.When setting a SST file, remember in Exchange online, only the SST will be used for S/MIME certificate validation. Create a SST file for the Trusted Root CA / Intermediate CA of the certificate issued to the users: You can use either Certificate MMC or PowerShellcmdlets to export the SST file. I am using the Certificate console to export the SST here: Open certmgr.msc snap-in, Expand Trusted Root Certificate Authorities > Certificates > select the CA Certificates which issued the certificates to end users for S/MIME, and right click > All Tasks > Export… Note: There may be some Intermediate CA. If there are, move them to Trust Root CA folder and select them, including the Trusted CA certificates, and export them all in one .SST file. Select SST > Click Next and save the SST file: Upload .SST to Office 365 server: Update the SST on Office 365 Exchange server by running the commands below using remote PowerShell: $sst = Get-Content <sst file copied from the box>.sst -Encoding Byte (Example: $sst = Get-Content TenantRoot.sst -Encoding Byte) Set-SmimeConfig -SMIMECertificateIssuingCA $sst 3.If end users are issued third party certificates, they can publish the certificate information to the GAL by following these steps: Note: To publish the certificate, the users must first have the certificate installed on their local machine. On the File menu in Outlook 2013, click Options. On the Outlook Options window, click Trust Center, click Trust Center Settings..., then Email Security. On Trust Center window, click Settings… (Here, you need to choose which certificate you are going to use for S/MIME). In the Change Security Settings window, type the Security Settings Name (you can name it anything), Choose Signing and Encryption certificate, select the appropriate certificate assigned in previous steps, leave the Algorithm default, and click OK. Once the information is selected, you will notice the Default Setting is populated with Security Settings Name. Now you can click the Publish to GAL button. To publish the certificate to the GAL, click OK. To confirm that the certificate is published in AAD (Azure Active Directory), connect to Exchange Online using remote PowerShell and run the following command. Check to see if the UserSMimeCertificate attribute is populated with the certificate information. If not, return to step 4. Get-Mailbox <user> | FL or FT *user* If Windows Certificate Authority is used, then the CA will publish the certificate information into the user object. In both cases, you need to use DirSync to replicate the on-premises Active Directory information to the cloud so that cloud users can exchange S/MIME messages. 4. After the above steps, your end users can use Outlook, OWA, or EASto send and receive S/MIME messages. Note: Make sure you check S/MIME Supported Clients section below before exchanging S/MIME messages. S/MIME Supported Clients All the client machines should have the PKI issued user certificate installed under (whichever is applicable) Certificates - Current User - Personal - Certificates - Trusted Root Certification Authorities - Certificates - Intermediate Certification Authorities - Certificates If the PKI issued certificate is not available, users will not be able to send digitally signed messages or decrypt the S/MIME encrypted messages. Outlook Web App: OWA for S/MIME - Supported only on Windows Vista or greater with browser IE9 and above. Not supported on other browsers or on MOWA (Mobile for Outlook Web Access). Third party certificates aren’t supported for OWA S/MIME; only Windows Certificate Authority issued certificates are supported. To use Outlook Web Access with the S/MIME control, the client system on which the user is running Internet Explorer must have Outlook Web Access with the S/MIME control installed. S/MIME functionality in Outlook Web Access cannot be used on a system that does not have Outlook Web Access with the S/MIME control installed. SMIME control in OWA requires .Net 4.5. All users accessing their mailboxes using OWA should install this on their machine. .Net 4.5 can be installed from Microsoft Downloads page. Outlook Outlook 2010 and above are supported. EAS Clients Windows phone 8.1 is a supported EAS client for S/MIME. To learn how to install a certificate on Windows Phone 8.1, see Installing digital certificates. For any other devices, you need to check with the device vendors. FAQ 1. Do both of these user object attributes (UserSMIMECertificate and UserCertificate) need to be populated with certificate information? Either, or both. 2. Do we support S/MIME for Cross Org/Cross Tenant? Cross Org/Cross Tenant S/MIME is not supported in Outlook Web App and EAS (Exchange Active Sync) With Outlook, it is a supported scenario. A tenant administrator may create contact objects with associated S/MIME public certificates, for users external to their organization that’d synchronize to Office 365 directory. Also, when we are looking for certificates for recipients, we check in all the Address Books. This includes the Global Address Book (GAL), the Contact Address Book (contacts folder), as well as any other address books (which includes LDAP address books). As long as we can find an entry in an address book for the recipient and it contains a certificate that we trust, then we can use it and send S/MIME mail. Note: Certificate in Exchange online GAL (for contact) is supported, however OWA client doesn’t support this scenario at present.. 3. When I select Encrypt mail and click on Send button in Outlook/OWA, I get error saying that the sender does not have a certificate. Why? In the example below, David is a sender. He was trying to send an S/MIME encrypted email message to a couple of recipients who have certificates published in the Active Directory, but David himself doesn’t have a certificate. When he clicks Send, he gets the below error. So, when sending an S/MIME encrypted message, we always check the sender’s certificate so that the message is encrypted such that the sender himself can see it from his Outlook ‘sent items’ folder. References Understanding S/MIME Special thanks to Frank Brown, Mike Brown, Timothy Heeney, Tariq Sharif, Vikas Malhotra and Eduardo Melo for reviewing this post! Suresh Kumar
Migrating On-Prem Distribution Groups to Exchange Online in Hybrid Mode
I have come across a number of articles on migrating distribution groups to Office 365 when you're not in hybrid mode. My situation is having hundreds of DLs on my on-prem Exchange environment that I need to move to the cloud. We don't want these converted to Office 365 groups, we want true distribution groups in the cloud. Is this possible with scripting or some other method? I really don't want to have to re-create these by hand.Exchange Server TLS guidance Part 3: Turning Off TLS 1.0/1.1
Update: please see our official documentation which is now available on this subject: Exchange Server TLS configuration best practices. Overview In part 3 of our Exchange Server TLS Guidance series, we introduce how to turn off TLS 1.0 and 1.1 in your Exchange Server deployment. Turning off TLS 1.0 and 1.1 can be a highly disruptive event if not planned and executed properly. The Exchange team believes that it is time for the ecosystem to fully embrace TLS 1.2, but urges you to proceed with caution when disabling TLS 1.0 and 1.1. This includes understanding how and being prepared to reverse the configuration steps if necessary. Assumption Before disabling TLS 1.0 and 1.1, it is important that you have completed the steps outlined in Part 1: Getting Ready for TLS 1.2 and Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It. Do not proceed until you have completed these steps on all Exchange servers, have read all of Part 3 (this post) and understand the implications of disabling TLS 1.0 and 1.1. Disabling TLS 1.0 and 1.1 We have attempted to simplify adopting newer versions of TLS by aligning Exchange configuration to the operating system capabilities. In Exchange Server 2016 and later, Exchange fully inherits the capabilities of the operating system on the platform where Exchange is installed. Exchange Server 2013 behaves the same as Exchange 2016 with the exception of POP and IMAP. Exchange 2010 has a similar restriction for POP and IMAP but behaves differently than Exchange 2013 (see the About POP and IMAP section below). The steps used to disable TLS 1.0 and 1.1 outlined below will apply to the following Exchange functionality: Simple Mail Transport Protocol Outlook Client Connectivity Exchange Active Sync Outlook on the Web (and Outlook Web App / Outlook Web Access in earlier versions of Exchange) Exchange Admin Center and Exchange Control Panel Autodiscover Exchange Web Services (and Representational State Transfer “REST” where implemented) Use of PowerShell by Exchange over HTTPS POP and IMAP (Exchange Server 2013 and later only) Disable TLS 1.0 and 1.1 in SChannel All Windows Server Versions In Part 2, we introduced how to enable TLS 1.2 in Windows SChannel using the Windows Registry. To disable TLS 1.0 and 1.1 you make use of the same Enabled and DisabledByDefault DWORD entries, but with different values. An admin must modify the TLS 1.0 and TLS 1.1 portions of the SChannel registry section and turn the protocols off instead of turning them on. To disable TLS 1.0 for both Server (inbound) and Client (outbound) connections on an Exchange Server perform the following: 1. From Notepad.exe, create a text file named TLS10-Disable.reg. 2. Copy and paste the following text into the file. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 3. Save TLS10-Disable.reg. 4. Double click the TLS10-Disable.reg file. 5. Click Yes to update your Windows Registry with these changes. 6. Restart the machine for the changes to take effect. To disable TLS 1.1 for both Server (inbound) and Client (outbound) connections on an Exchange Server please perform the following: 1. From Notepad.exe, create a text file named TLS11-Disable.reg. 2. Copy and paste the following text into the file. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 3. Save TLS11-Disable.reg. 4. Double click the TLS11-Disable.reg file. 5. Click Yes to update your Windows Registry with these changes. 6. Restart the machine for the changes to take effect. About POP/IMAP Exchange Server 2010 The Exchange product updates which allow POP/IMAP to dynamically consume the operating system SChannel configuration settings for POP/IMAP connections are not available in Exchange Server 2010. POP/IMAP are still dependent upon SChannel configuration, but are hard coded to allow TLS 1.0 or SSL 3.0 negotiation only in Exchange Server 2010. As of the posting date for this entry, if TLS 1.0 is disabled in SChannel, clients will fallback and attempt to negotiate SSL 3.0. If SSL 3.0 is disabled, client negotiation will fail. There are no current plans to change this product behavior. Microsoft’s implementation of TLS 1.0 has no known vulnerabilities but SSL 3.0 use is strongly discouraged. Customers who need to ensure that TLS 1.2 is used for SMTP / HTTPS traffic may need to add servers specifically configured to support TLS 1.0 only for POP/IMAP if needed in their environment. Note: We assume that most customers have disabled SSL 3.0 already. If not, the process used to disable SSL 3.0 can be found at support.microsoft.com. Exchange Server 2013 Similar to Exchange Server 2010, POP/IMAP on Exchange Server 2013 does not dynamically inherit the operating system SChannel settings. POP/IMAP protocols are hard coded to negotiate TLS 1.2 in Exchange Server 2013. This means customers can proceed with disabling TLS 1.0 and 1.1 on Exchange Server 2013. It is unlikely, but if TLS 1.3 (or later) support is added on the operating systems supported by Exchange Server 2013, customers will need to determine how to proceed with publishing endpoints which meet their requirements. .NET considerations and other applications on an Exchange Server The steps outlined in this series address the Exchange product code running on an Exchange server. The guidance provided represents the actions and steps to allow Exchange to successfully negotiate TLS 1.2. Exchange only requires the use of SystemDefaultTlsVersions and SchUseStrongCrypto. We have worked with the .NET team to ensure that use of other .NET settings does not conflict with how Exchange has been developed and our approach to dynamically inherit the operating system capabilities. It is entirely possible that other applications developed on the .NET Framework which are deployed on an Exchange Server may require additional configuration. Customers should work with the ISV’s for any applications installed on an Exchange server to understand an application’s specific requirements. Summary This concludes our series on how to enable TLS 1.2 on Exchange Server and disable older TLS versions. With proper planning and execution, customers should be able to successfully transition to TLS 1.2. We encourage you to complete this across all of your Exchange servers as soon as reasonably possible. We introduced the topic of ciphers as a part of the discussion on TLS encryption when we started this series. It is our intention in the near future to provide additional guidance to customers on the cipher and hashing algorithms that we recommend be used to best secure Exchange Server communications. For now, enjoy the improvements that TLS 1.2 can provide and check this off your list of things to do with your Exchange servers. A huge debt of gratitude goes to Scott Landry, Brent Alinger, Chris Schrimsher, Arindam Thokder and others for combining numerous efforts of work into this series of postings. The Exchange Team
