Exchange 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 ExperienceExchange TLS & SSL Best Practices
Note: for more up to date guidance on TLS, please see this post. Whether you are running Exchange on-premises, in the cloud, or somewhere in between, we know that security is a top priority. Microsoft is committed to giving you the information needed to make informed decisions on how to properly secure your environment. It has been suggested by some external parties that customers need to disable TLS 1.0 support. One piece of guidance we are aware of suggests taking steps to prepare to disable TLS 1.0 in summer of 2016. Another piece of guidance suggests that TLS 1.0 should not be used with internal-only applications (we do not believe that Exchange is typically used in this manner, as it connects to the outside world via SMTP). While we believe the intentions of both proposals are good and will promote adoption of TLS 1.1 & 1.2, at this time, we do not yet recommend disabling TLS 1.0 on your Exchange Server(s). Additionally, while TLS 1.1 & 1.2 are superior to TLS 1.0, the real world risks may be somewhat overstated at this point due to mitigations that have been taken across the industry. Of course, security is rarely a binary decision: disabling TLS 1.0 doesn’t suddenly turn something insecure into something secure. That said, we will continue to work towards the goal of making TLS 1.1 & 1.2 work fully with Exchange and a broad array of clients. More importantly, many customers may not have taken initial steps towards following current best practices. We believe that the first step towards a more secure environment is to have a TLS organizational awareness. While disabling TLS 1.0 on Exchange is not advised at this time, there are definite steps which can be taken today. TLS 1.0 is not widely viewed as insecure when SSL 3.0 is disabled, machines are properly updated, and proper ciphers are used. The current recommendations, which will continue evolving, are as follows: Deploy supported operating systems, clients, browsers, and Exchange versions Test everything by disabling SSL 3.0 on Internet Explorer Disable support for SSL 3.0 on the client Disable support for SSL 3.0 on the server Prioritize TLS 1.2 ciphers, and AES/3DES above others Strongly consider disabling RC4 ciphers Do NOT use MD5/MD2 certificate hashing anywhere in the chain Use RSA-2048 when creating new certificate keys When renewing or creating new requests, request SHA 256-bit or better Know what your version of Exchange supports Use tools to test and verify Do NOT get confused by explicit TLS vs. implicit TLS (For now) Wait to disable TLS 1.0 on the Exchange server Let’s get started down the list! Deploy supported operating systems, clients, browsers, and Exchange versions Perhaps it goes without saying, but the first step to securing any environment is to make sure that all servers, devices, clients, applications, etc. are updated. Most issues that support sees after following recommendations on Exchange are easily fixed with updates already available from the vendor of the incompatible device (printers, firewalls, load balancers) or software (mailers, etc.). For Exchange, this means test & apply your Windows & Exchange updates regularly. Two reasons for this – first, an environment is only as secure as the weakest link; second, older software typically won’t let you take advantage of the latest TLS versions and ciphers. Make sure firewalls, old Linux MTAs, load balancers, and mass mailer software are all updated. Make sure the multifunction printers have the latest firmware. Test everything by disabling SSL 3.0 on Internet Explorer Disabling SSL 3.0 in the browser is a good first step, because it insures that all your users remain safe, no matter where they may browse. Additionally, it easily allows you to test to make sure that websites and applications will continue to work or not. There’s still a small bit of the Internet that is still relying on SSL 3.0, but the time is overdue for it to be retired. To test your environment with Internet Explorer, follow KB3009008. Disable support for SSL 3.0 on the client After testing, you may also consider disabling it at the SCHANNEL layer for all clients. While you are viewing these settings, make sure that your clients have TLS 1.1 & 1.2 enabled. In most cases, the most recent version supported by both the client & server will be used. This is a good way to start moving towards a more secure environment. All supported versions of Windows have TLS 1.1 & 1.2 capabilities, but the older ones may not have them enabled by default. Note that registry changes under SCHANNEL are only good for applications that use the SCHANNEL API. Some applications could utilize 3 rd party or open source security APIs (like OpenSSL) which may not look at these registry keys. Also, note that changes do not take effect until reboot. Disable support for SSL 3.0 on the server The next recommendation is to disable SSL 3.0 on all servers, Exchange included. Do this by following all recommendations in the original security bulletin. Since servers can be both clients and servers, it is recommended to follow all applicable steps. As before, while you are viewing these settings, make sure that your servers have TLS 1.1 & 1.2 enabled. Note: Any of these registry changes require a reboot to take effect! You can do this with confidence because TLS 1.0 will be the minimum which you support. Exchange and Windows have both supported TLS 1.0 for over a decade. TLS 1.0 itself is not considered vulnerable when SSL 3.0 is disabled on clients and servers. In fact, most Exchange sessions already have been using TLS 1.0 or even later, for years. You are simply disabling the ability for the session to be downgraded to SSL 3.0. Disabling SSL 3.0 is typically not too impactful except for clients and devices that are older than (roughly) 10 years old. These recommendations should have already been carried out in your organization with haste. Even so, the POODLE vulnerability itself does require someone to intercept the traffic and sit between the client and server during the initial session negotiation. While this is not super difficult to accomplish, it is also not trivial. It is a much more severe problem for users who travel and for mobile devices which use hotspots. As many customers do support remote access to email, this is something for Exchange administrators to worry about. Since some mobile device vendors have not released ways to disable SSL 3.0, you can at least keep your Exchange resources safe by disabling SSL 3.0 on the server side. In addition, enabling support for TLS v1.1 and v1.2 are highly recommended. But leaving TLS 1.0 enabled is a good thing for now. Clients and applications should always prefer the most secure option, provided that Windows, the application, and the client all support it. Note: If you terminate SSL at load balancers, you’ll want to disable SSL 3.0 there as well (and perform subsequent steps there in addition). Check with your vendor to get their guidance. Also, be sure to check all Exchange servers which may be sharing a single VIP or DNS record. Office 365 completed these changes, and you will find that SSL 3.0 is not possible for any protocol. Prioritize TLS 1.2 ciphers, and AES/3DES above others The next step we recommend is based on a step we took in Office 365 to prioritize the latest ciphers which are considered much more resilient to brute force attack. The thing with ciphers is that it isn’t just about enabling the most secure one and disabling the rest. You want to offer several choices for clients to allow maximum compatibility. You typically want to disable the ones which are the least secure, but leave others to provide choice. The negotiation of a particular cipher depends on: The client passes an ordered list of ciphers which it supports The server replies with the best cipher which it has selected (server gets final say) Changing the order on the server can minimize the use of a less secure cipher, but you may want to go further and disable it completely. Cipher changes are made through this registry key, explained here. Strongly consider disabling RC4 ciphers Of course, there is risk of some clients not continuing to work if you disable too many ciphers. That said, Microsoft has been recommending that disabling RC4-suite of ciphers is a good best practice. It is considered to be a weak cipher. Disabling RC4 should be done with some care as it can introduce incompatibilities with older servers and clients, though problems should be minimal as supported versions of Windows have supported 3DES and AES alternatives for years. The rollout of this in Office 365 is in progress and should be completed shortly. Do NOT use MD5/MD2 certificate hashing anywhere in the chain Ciphers depend on the certificate chain being used - you can introduce problems when connecting to a host which has an insecure signature algorithm used in their chain. For example, we have seen that Office 365 SMTP transport is no longer able to connect to hosts with MD5 and MD2 hashing because they do not support modern ciphers. This applies to the certificate and any certificates in the chain. We see this with SMTP because Exchange is acting as a client, and because there are many older SMTP systems and firewalls still out there. Use RSA-2048 when creating new certificate keys Some things to watch out for when you renew or reissue certificates. First is that when creating your requests, use 2048-bit RSA. Anything less is not considered secure anymore. When renewing or creating new requests, request SHA 256-bit or better Second, when you renew, you should consider moving the signature algorithm from SHA1 to SHA2 if you haven’t already done so. This isn’t considered something that you need to worry about until renewal time, unless your certificate happens to be good for another couple of years – in which case, go ahead and take care of it now. You can check your Exchange certificates with a browser (or in Certificate Manager MMC): This example certificate was generated with Exchange 2013 on Windows 2012 R2. It has an RSA 2048-bit key and has an RSA SHA256 (SHA-2) signature algorithm. Know what your version of Exchange supports Some applications sometimes need to be re-compiled and tested to take advantage of these new protocols. So, every part of Exchange and Windows-based clients need to be examined and tested thoroughly. Currently, for Exchange Server, we are aware of the following limitations: SMTP – key piece of Exchange server infrastructure – support for TLS 1.1 and 1.2 were added in Exchange Server 2013 CU8 and Exchange Server 2010 SP3 RU9. This means if you want to add support for the latest ciphers and TLS versions, you may need to apply an update. IMPORTANT: SMTP is the main protocol used when communicating outside of your organization, something which is a key purpose of email. If you disable TLS 1.0, SMTP would no longer be able to use Opportunistic TLS with any external party which doesn’t support TLS 1.1 or 1.2. Emails will then be sent/received in the clear, which is certainly significantly less secure than TLS 1.0. That said, we have enabled new logging in the Exchange SMTP protocol logs to allow you to audit the impact of future changes on SMTP. Additional Note: SMTP is notably a protocol where Exchange acts as both a client and a server. Some older server implementations have been observed to incorrectly implement version negotiation. In these cases, the remote servers terminate the connection when Exchange (acting as a client) offers a version newer than TLS 1.0. This results in a complete stoppage of email to these systems. Fortunately, these situations are becoming rare as time passes, but this is pointed out because the effects often are more impactful than a mail client which cannot connect. POP/IMAP – not used as frequently in all environments, but if you do, beware that we only currently support TLS 1.1 and 1.2 on-premises in the Exchange Server 2016 Preview. We hope to make this available in a future CU, or you can make a request for it via proper channels so we can prioritize it. Office 365 already has this support. HTTPS (OWA, Outlook, EWS, Remote PS, etc.) – The support for TLS 1.1 and 1.2 is based on the support in IIS itself. Windows 2008 R2 or later supports both TLS 1.1 and 1.2, though the specific version of Windows may have these disabled or enabled by default. There is another important caveat here: the HTTPS proxy between CAS and Mailbox requires TLS 1.0 in current versions of Exchange Server – so disabling TLS 1.0 between CAS and Mailbox causes the proxy to fail. This is also something we have addressed in the Exchange 2016 Preview. We hope to make this available in a future CU, or you can make a request for it via Support. If you have dedicated roles, you can technically disable TLS 1.0 between the client & CAS, but we still are not recommending this. Office 365 already supports TLS 1.1 & 1.2, if the client supports them. Clients – TLS 1.0 is universal, with near 100% support. Though TLS 1.1 and 1.2 are growing more common, many Exchange clients still do not work with anything but TLS 1.0. For example, at this time, we are tracking multiple issues with Outlook running on Windows 8.0 or older. We are hoping to address these issues soon, but with Windows 7 commonly running in most customer environments, this is a really good reason to not disable TLS 1.0 yet. Comprehensive testing of other clients running without TLS 1.0 has not been completed by Microsoft at this time. Note: Windows Remote Desktop may also have challenges, depending on your version of Windows. For servers which are managed remotely, be sure to test this first. Use tools to test and verify There are several tools and websites you can go to for testing your server(s) and clients. It is highly recommended to do so. Some offer a grading/scoring system. Others offer pass/fail. We’re inclined to recommend one with a scoring system, since security is about risks and tradeoffs. Don’t be surprised if one or more of these tools doesn’t fully test for POODLE and just thinks TLS 1.0 is bad. Use your newfound knowledge to read the results for what they are. We prefer tools that let you check specific things (like cipher order, or individual TLS/SSL versions) in addition to the blanket “vulnerability tests”. There is also one fantastic (non-Microsoft) website called SSLLabs which simulates multiple clients and can warn you of compatibility issues with the clients which it knows about. For example, here we see that disabling TLS 1.0 would likely cause issues with older versions of Android clients: In addition, you can see how you compare with the rest of the Internet. This is great for HTTPS. Most certificate vendors have test tools available as well, though they have differing coverage of what is tested. Other tools are available which test additional protocols. Here is a test being run against IMAP on port 993 (referred to as the “SSL binding”; see below for explanation): As you can see, even on port 993, TLS 1.0 is used with AES256. Do NOT get confused by explicit TLS vs. implicit TLS In the course of human events, shortcuts are taken. One unfortunate shortcut occurred when TLS 1.0 added optional support for a per-protocol implementation of STARTTLS, also known as “explicit TLS”. Prior to “explicit TLS”, if a server application level protocol wanted to implement SSL/TLS in addition to a non-secure option, it had to take up a separate port on the machine for each. This is “implicit TLS”. See the following chart: Protocol IANA port (Explicit TLS) Protocol IANA Port (Implicit TLS) E-SMTP 25 SMTPS 465** POP3 110 POPS 995 IMAP4 143 IMAPS 993 HTTP 80* HTTPS 443 * HTTP doesn’t implement explicit TLS, because it is stateless and the overhead would not be worth it. ** Exchange specifically does not support SMTPS (implicit TLS). The first protocol which implemented this verb was ESMTP. By doing so, SMTP could support clients & servers on the same port, and could also easily implement “opportunistic” TLS/SSL. In fact, Exchange has never supported SMTPS (465), although we do reuse that port by default in Exchange 2013 for one of the three transport roles. For POP and IMAP, Exchange supports both the explicit option and the implicit option. What can be confusing is that because STARTTLS didn’t come about until TLS 1.0 – some people started confusing explicit TLS with “TLS” and some mail applications started using the terminology interchangeably. So, disabling port 995 & 993 does not turn off SSL 3.0 (you are disabling implicit POPS & IMAPS, but not SSL) – nor is enabling port 110 & 143 (explicit TLS) required for TLS 1.x. The terminology is confusing, but the concepts are mostly unrelated. This unfortunate optimization was brought into Exchange: However, tinkering with ports and implicit/explicit should not be necessary as you are NOT disabling SSL 3.0 by doing so. Securing Exchange Server shouldn’t mean changing any of these settings – just the SCHANNEL registry settings discussed above. (For now) Wait to disable TLS 1.0 on the Exchange server In summary, as of July 2015, Exchange currently supports TLS 1.0, but can also support TLS 1.1 & 1.2 with the following minimum requirements met: Protocol TLS v1.1/1.2 Minimum Requirements SMTP Exchange 2013 CU8 or Exchange 2010 SP3 RU9 POP/IMAP Exchange 2016 Preview HTTP (server) Windows 2008 R2; MAPI clients must run Windows 8.1 or later HTTP (proxy to MBX) Exchange 2016 Preview As you can see, since Exchange Server 2016 isn’t released yet as an in-market product (it is for lab use only at this time), and since Windows 7 is still the most prevalent Windows version, it is quite impractical to fully disable TLS 1.0. Not only will POP/IMAP break (for lack of TLS 1.1 and 1.2 support), but you cannot disable TLS 1.0 on any Exchange server running the mailbox server role. Most importantly, disabling TLS 1.0 will result in compatibility issues with some common mobile devices, clients, and possibly interrupt some Internet email. Don’t panic – if you have disabled SSL 3.0 and decided on a cipher order that your organization can agree on, you are likely quite secure, and you are not vulnerable to the POODLE attack. Microsoft is committed to adding full support for TLS 1.1 and 1.2. TLS v1.3 is still in draft, but stay tuned for more on that. In the meantime, don’t panic. On a test Exchange lab with Exchange 2013 on Windows Server 2012 R2, we were able to achieve a top rating by simply disabling SSL 3.0 and removing RC4 ciphers. This is nearly as good as one can achieve at the time of this posting on released versions of Exchange without impacting common clients. Additionally, this configuration should be highly compatible with nearly all clients and devices from the past decade or more, while utilizing the latest security with clients which do support it. Of course, security requires a watchful eye as new threats and vulnerabilities are discovered from time to time. As always, stay tuned to Security Bulletins and updates. Scott Landry Senior Program Manager, Exchange SupportabilityPermanently 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 SolorioExchange 2013/2016 Monitoring Mailboxes
Note 10/2022: This article also applies to Exchange Server 2019. Introduction Exchange Server 2013 introduced a new feature called Managed Availability, which is a built-in monitoring system with self-recovery capabilities. Managed Availability performs continuous tests (probes) that simulate end-user actions, to detect possible problems with Exchange components or their dependencies. If probes are failing, it performs gradual simple recovery actions to bring the affected component in healthy state. It uses special type of mailboxes, called Monitoring Mailboxes or health mailboxes, to simulate end-user kinds of tests. The life cycle of monitoring mailboxes is taken care entirely by Managed Availability components. In this post, we’ll see how Managed Availability takes care of monitoring mailboxes, what best practices to keep monitoring mailboxes happy are and some related troubleshooting. Monitoring Mailboxes Functioning of Managed Availability is implemented by Microsoft Exchange Health Manager Service running on each Exchange Server 2013 role. The Microsoft Exchange Health Manager Service is responsible for creating and maintaining monitoring mailboxes Let’s take a look at how the Health Manager creates them! How do we create monitoring mailboxes? The MS Exchange Health Manager Service runs in two processes, MSExchangeHMHost.exe and MSExchangeHMWorker.exe (let’s call it the HM worker). HM worker process, at the time of startup, checks for availability of monitoring mailboxes and creates monitoring mailboxes as needed. Starting with Exchange Server 2013 Cumulative Update 1, accounts for monitoring mailboxes are created under following container in the domain Exchange server resides: <ADdomain>\Microsoft Exchange System Objects\Monitoring Mailboxes Example: The logic HM worker process uses to detect and create monitoring mailboxes depends on Exchange Cumulative Update (CU) installed, Exchange role installed on the box and mailbox databases present. The Following logic was used to create monitoring mailboxes for Exchange Server 2013 servers between RTM to Cumulative Update 5: One monitoring mailbox per mailbox database copy, plus one for all of CAS servers. Here’s an example of monitoring mailboxes created on Exchange Server 2013 SP1 server that hosts both CAS and mailbox role: [PS] C:\>Get-Mailbox -Monitoring | ft displayname,whencreated DisplayName WhenCreated ----------- ----------- HealthMailboxb285a119be6649b3a89574f078e947f5 11/10/2014 9:07:29 AM HealthMailbox60d8a8d1285e41bfa5ce1ef1fb93d14e 11/10/2014 9:07:36 AM The display name of the monitoring mailbox created for database copy contained the GUID of the mailbox database for which it was created. Example: The display name of the monitoring mailbox created for CAS server contained the GUID of the Exchange server for which it was created. Example: The following logic is used to create monitoring mailbox for Exchange Server 2013 Cumulative Update 6 and onwards: One monitoring mailbox for each mailbox database copy hosted on mailbox role, plus ten monitoring mailboxes for each CAS server. The following naming convention is used for the display name of the monitoring mailbox created for a database: “HealthMailbox-“ + host name of server + “-“ + database name. At the startup, the HM worker checks for name of databases present on the server and then checks for presence of monitoring mailboxes with display name as explained above. If it doesn’t find a monitoring mailbox for a specific database, it creates a new monitoring mailbox. That means, if you rename DB1 to DB2, HM worker will create new monitoring mailbox for DB2 on next startup. And the following naming convention is used for display name of the monitoring mailbox created for a CAS server: “HealthMailbox-“ + host name of the CAS server + “-001” through “010.” We attempt to distribute the monitoring mailboxes created for CAS servers across the mailbox databases available. Let’s make this real: Imagine that you have only one Exchange server running Exchange 2013 CU6 or newer in the org (server is named EXCH1) that hosts both CAS and Mailbox role and has only one mailbox database, 11 monitoring mailboxes will be created. Example: The Health Manager Service will create more mailboxes according to the logic explained above as you go on adding more databases or server roles. Password resets HM Worker is responsible for maintaining the password for Monitoring mailboxes. HM worker uses a complex algorithm to generate password to be used for monitoring mailbox. The password for monitoring mailbox is reset under the following conditions: A new health mailbox is being created Each time HM Worker process starts and is not able to retrieve the existing password for the monitoring mailbox Any other scenario where HM Worker is not able to get hold of existing password for the monitoring mailbox Best practices Here are some best practices regarding management of user accounts associated with monitoring mailboxes as well as mailboxes themselves: Do not apply third party customized password policies to user accounts of monitoring mailboxes Exclude monitoring mailboxes from user account lockout policies Do not move the user accounts out from the Monitoring Mailboxes container Do not change the user account properties, like restricting password change etc. Do not change AD permission inheritance Since HM worker handles password resets for monitoring mailboxes, in a large environment, it is normal to see increased password reset traffic for monitoring mailbox accounts; note that doing one of the things above might increase the frequency of those resets Do not move the monitoring mailboxes between mailbox databases Do not apply mailbox quotas to monitoring mailboxes If applying a retention policy, ensure the data within the monitoring mailbox is retained for a minimum of 30 days before being deleted If you see a mailbox size increasing significantly for specific monitoring mailbox; you can simply disable the specific mailbox. The HM worker will create a new mailbox at next startup. Common tasks with monitoring mailboxes How to list monitoring mailboxes The Get-Mailbox command is provided with special parameter “-Monitoring” to list only the monitoring mailboxes. Here are some examples: To list all monitoring mailboxes present in the organization: Get-Mailbox –Monitoring To list monitoring mailboxes present on a database: Get-Mailbox –Monitoring -Database <database name> However, the mailboxes listed above may not be associated with the server on which database is hosted. As explained in creation logic, the name of Client Access Server or the mailbox database is important in searching for monitoring mailbox associated and in creation of monitoring mailbox. Use the following command to list the monitoring mailboxes associated with a specific server: Get-Mailbox -Monitoring | ?{$_.DisplayName -like "*-<servername>-*"} Example: Get-Mailbox -Monitoring | ?{$_.DisplayName -like "*-exch2-*"} | ft name,displayname,database Use the following command to list the monitoring mailbox associated with a specific database: Get-Mailbox -Monitoring | ?{$_.DisplayName -like "*-<name of database>"} Example: Get-Mailbox -Monitoring | ?{$_.DisplayName -like "*-db2exch2"} | ft name,displayname,database,servername Troubleshooting tips Here are some troubleshooting methods for monitoring mailboxes. How to re-create monitoring mailboxes (NOT considered regular maintenance!) The mailbox database removal doesn’t cleanup the AD user account associated with monitoring mailboxes. This can then result in orphaned AD user accounts. This happens because of deny permission inherited on Monitoring Mailboxes container. KB article 3046530has details on this, as well as the workaround to resolve it. If there are too many orphaned monitoring mailbox accounts, you may want to re-create them. Steps: 1) Make sure “Monitoring Mailboxes” container is present Open Active Directory Users & Computers Click on View and select “Advanced Features” The Browse to Microsoft Exchange System Objects Verify the presence of the “Monitoring Mailboxes” container. Example: If the Monitoring Mailboxes container is missing: Make sure you have Exchange Server 2013 CU1 or above installed. Perform PrepareAD with the Exchange Server 2013 version installed. 2) Stop the “Microsoft Exchange Server Health Manager” service on all Exchange Server 2013 servers. 3) Open Exchange Management Shell and use following command to disable existing health mailboxes: Get-Mailbox -Monitoring | Disable-Mailbox 4) Go back to Active Directory users & computers, right click on domain and search for “HealthMailbox” 5) Delete the health mailbox user accounts. 6) Wait for AD replication or force AD replication. 7) Start the “Microsoft Exchange Server Health Manager” on all Exchange Server 2013 servers. Bhalchandra Atre Updates 6/2/15: Updated best practices to include information on aging out data via retention policies.
