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 ExperienceUpcoming changes to Exchange Web Services (EWS) API for Office 365
Update: For latest information related to basic authentication in Exchange Online, please see Basic Authentication and Exchange Online – September 2022 Update. Over the last few years, we have been investing in services that help developers access information in Office 365 in a simple and intuitive way, specifically through Microsoft Graph. Microsoft Graph and the use of OAuth 2.0 provide increased security and seamless integration with other Microsoft cloud services and is rapidly expanding developer access to the rich data sets behind Microsoft applications. As we make progress on this journey, we have continued to evaluate the role of Exchange Web Services (EWS). Today we are sharing our plans to move away from Basic Authentication access for EWS over the next two years, with support ending Oct. 13, 2020. These plans apply only to the cloud-based Office 365/Exchange Online products; there are no changes to EWS capabilities of on-premises Exchange products. Exchange Web Services will not receive feature updates Starting today, Exchange Web Services (EWS) will no longer receive feature updates. While the service will continue to receive security updates and certain non-security updates, product design and features will remain unchanged. This change also applies to the EWS SDKs for Java and .NET as well. While we are no longer actively investing in it, EWS will still be available and supported for use in production environments. However, we strongly suggest migrating to Microsoft Graph to access Exchange Online data and gain access to the latest features and functionality. For more information and details on how to make the transition, please refer to the following articles: Overview of Microsoft Graph Overview of Outlook mail API on Microsoft Graph While EWS and Graph have mostly overlapping functionality, there are some differences. If you rely on an EWS API that does not have a Graph counterpart, please let us know via UserVoice of features needed for your app scenarios. Basic Authentication for EWS will be decommissioned Exchange Web Services (EWS) was launched with support for Basic Authentication. Over time, we've introduced OAuth 2.0 for authentication and authorization, which is a more secure and reliable way than Basic Authentication to access data. Please refer to the following article for more information: Getting started with OAuth2 for Microsoft Graph Today, we are announcing that on October 13th, 2020 we will stop supporting and fully decommission the Basic Authentication for EWS to access Exchange Online. This means that new or existing apps will not be able to use Basic Authentication when connecting to Exchange using EWS. Next Steps The deprecation of these APIs follows our service deprecation policies. We understand changes like this may cause some inconvenience, but we are confident it will ensure more secure, reliable, and performant experiences for our customers. We're here to help if you need it. If you have questions, please let us know in Stack Overflow with the [MicrosoftGraph] tag. Thank you in advance for updating and opening your apps to a wider range of useful and intelligent features on Microsoft Graph. We are extremely excited about the growing opportunities that Microsoft Graph offers to our customers, and we remain fully committed to continue our journey to empower developers to access Office 365 data with the most modern features and tools. Frequently Asked Questions Q: Will my application stop working when you make this change? A: It might, yes, it depends on the app itself and how it was coded. If it’s using EWS, and if it’s using Basic authentication then yes, on October 13th 2020 it will fail to connect. However, if the app is using Modern Auth/OAuth, then no, it will keep working as it did before. Q: Why October 13th 2020? Why that date? A: Starting October 13, 2020, Office 365 ProPlus or Office perpetual in mainstream support will be required to connect to Office 365 services. This announcement is posted here Office 365 ProPlus Updates. This change requires that Office 2013/Office 2016 are also required to use Modern Auth. Please see this. Q: Our in-house team created an app for meeting room scheduling, how do we go about changing that over to Graph and OAuth2.0? A: Don’t forget you can keep using EWS if you want to, so then really, it’s just the question of authentication. To get a better understanding of how to use OAuth 2.0 take a look here. Q: How does this impact my On-Premises Exchange deployment? A: It does not. This change only affects Exchange Online. Q: We require Modern Authentication + Multi Factor Auth for all our Outlook users connecting to O365, how do apps work when I have that set as a requirement? A: Applications can be written so they are treated as ‘trusted applications’. That way they can bypass the MFA requirement, more details are here. Q: How do I know which of my apps use Basic authentication to EWS? A: If you only use Outlook to connect to Exchange Online then you don’t need to worry, as long as you are using Office 2019 or Office 2019 Pro Plus you’ll be fine come October 2020. However, if you also have integrated apps into your Office 365 tenant you’ll need to check with the application developers to verify how it authenticates to Exchange Online if you aren’t’ sure. We are investigating how we can share this information with tenant admins, but have nothing available at the time of writing this blog. Q: What features does EWS have that Graph can’t provide? A: Graph is constantly evolving and adding features and functionality to provide the richest set of experiences we can. To see the latest features we’ve added to Graph, go here Overview of Outlook mail API on Microsoft Graph Q: Will this affect my Exchange Hybrid configuration? Exchange On-Premises calls into Exchange Online using EWS doesn’t it? A: Yes, it does. But it doesn’t use Basic Authentication, it uses token-based authentication, and it’s described in this blog post. How Hybrid Authentication Really Works. The Exchange TeamExchange 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 Experience
