Exchange 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 SupportabilityReleased: Exchange Server 2013 Service Pack 1
Download What's new Release notes Exchange Server 2013 Service Pack 1 (SP1) is now available for download! Please make sure to read the release notesbefore installing SP1. The final build number for Exchange Server 2013 SP1 is 15.00.0847.032. SP1 has already been deployed to thousands of production mailboxes in customer environments via the Exchange Server Technology Adoption Program (TAP). In addition to including fixes, SP1 provides enhancements to improve the Exchange 2013 experience. These include enhancements in security and compliance, architecture and administration, and user experiences. These key enhancements are introduced below. Note: Some of the documentation referenced may not be fully available at the time of publishing of this post. Security and Compliance SP1 provides enhancements improving security and compliance capabilities in Exchange Server 2013. This includes improvements in the Data Loss Prevention (DLP) feature and the return of S/MIME encryption for Outlook Web App users. DLP Policy Tips in Outlook Web App – DLP Policy Tips are now enabled for Outlook Web App (OWA) and OWA for Devices. These are the same Policy Tips available in Outlook 2013. DLP Policy Tips appear when a user attempts to send a message containing sensitive data that matches a DLP policy. Learn more about DLP Policy Tips. DLP Document Fingerprinting – DLP policies already allow you to detect sensitive information such as financial or personal data. DLP Document Fingerprinting expands this capability to detect forms used in your organization. For example, you can create a document fingerprint based on your organization’s patent request form to identify when users are sending that form, and then use DLP actions to properly control dissemination of the content. Learn more about DLP Document Fingerprinting. DLP sensitive information types for new regions – SP1 provides an expanded set of standard DLP sensitive information types covering an increased set of regions. SP1 adds region support for Poland, Finland and Taiwan. Learn more about the DLP sensitive information types available. S/MIME support for OWA – SP1 also reintroduces the S/MIME feature in OWA, enabling OWA users to send and receive signed and encrypted email. Signed messages allow the recipient to verify that the message came from the specified sender and contains the only the content from the sender. This capability is supported when using OWA with Internet Explorer 9 or later. Learn more about S/MIME in Exchange 2013. Architecture & Administration These improvements help Exchange meet our customer requirements and stay in step with the latest platforms. Windows Server 2012 R2 support – Exchange 2013 SP1 adds Windows Server 2012 R2 as a supported operating system and Active Directory environment for both domain and forest functional levels. For the complete configuration support information refer to the Exchange Server Supportability Matrix. This matrix includes details regarding Windows Server 2012 R2 support information about earlier versions of Exchange. Exchange Admin Center Cmdlet Logging – The Exchange 2010 Management Console includes PowerShell cmdlet logging functionality. Listening to your feedback, we’re happy to announce that this functionality is now included in the Exchange Admin Center (EAC). The logging feature enables you to capture and review the recent (up to 500) commands executed in the EAC user interface while the logging window is open. Logging is invoked from the EAC help menu and continues logging while the logging window remains open. ADFS for OWA – Also new for Outlook Web App in SP1 is claims-based authentication for organizations using Active Directory Federation Services. Learn more about the scenario. Edge Transport server role – SP1 also reintroduces the Edge Transport server role. If you have deployed Exchange 2013 with a supported legacy Exchange Edge Transport role, you don’t need to upgrade. That configuration is still supported. But we do recommend that future deployments use the Exchange 2013 Edge Transport role. Learn more about Edge Transport in Exchange 2013. New communication method for Exchange and Outlook – SP1 introduces a new communication method for Exchange Server and Microsoft Outlook called MAPI over HTTP(MAPI/HTTP). This communication method simplifies connectivity troubleshooting and improves the user connection experience with resuming from hibernate or switching networks. MAPI/HTTP is disabled by default, allowing you to decide when to enable it for your organization. MAPI/HTTP can be used in place of RPC/HTTP (Outlook Anywhere) for your Outlook 2013 SP1 clients while Outlook 2013 RTM and older clients continue to use RPC/HTTP. Learn more about deploying MAPI/HTTP. DAGs without Cluster Administrative Access Points - Windows Server 2012 R2 introduces failover clusters that can operate without an administrative access point: no IP addresses or IP address resource, no network name resource, and no cluster name object. SP1 enables you to create a DAG without an administrative access point on Windows Server 2012 R2 from EAC or PowerShell. This is an optional DAG configuration for SP1 and requires Windows Server 2012 R2. DAGs with administrative access points continue to be supported. Learn more about creating a DAG without an administrative access point here and here. SSL offloading – SP1 now supports SSL offloading, allowing you to terminate incoming SSL connections in front of your CAS servers and move the SSL workload (encryption & decryption tasks) to a load balancer device. Learn how to configure SSL offloading in Exchange 2013. User Experience We know the user experience is crucial to running a great messaging platform. SP1 provides continued enhancements to help your users work smarter. Enhanced text editor for OWA - OWA now uses the same rich text editor as SharePoint, thereby improving the user experience, and enabling several new formatting and composition capabilities that you expect from modern Web application - more pasting options, rich previews to linked content, and the ability to create and modify tables. Apps for Office in Compose – Mail apps are now available for use during the creation of new mail messages. This allows developers to build and users to leverage apps that can help them while they are composing mails. The compose apps leverage the Apps for Office platform and can be added via the existing Office store or corporate catalogs. Learn more about Apps for Office. Upgrading to SP1/Deploying SP1 As with all cumulative updates (CUs), SP1 is a full build of Exchange, and the deployment of SP1 is just like the deployment of a cumulative update. Active Directory Preparation Prior to or concurrent with upgrading or deploying SP1 onto a server, you must update Active Directory. These are the required actions to perform prior to installing SP1 on a server. 1. Exchange 2013 SP1 includes schema changes. Therefore, you will need to execute the following command to apply the schema changes. setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms 2. Exchange 2013 SP1 includes enterprise Active Directory changes (e.g., RBAC roles have been updated to support new cmdlets and/or properties). Therefore, you will need to execute the following command. setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms Server Deployment Once the above preparatory steps are completed, you can install SP1 on your servers. Of course, as always, if you don’t separately perform the above steps, they will be performed by Setup when you install your first Exchange 2013 SP1 server. If this is your first Exchange 2013 server deployment, you will need to deploy both Client Access Server and Mailbox Server roles in your organization. If you already deployed Exchange 2013 RTM code and want to upgrade to SP1, you will run the following command from a command line. setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms Alternatively you can start the installation through the GUI installer. Hybrid deployments and EOA Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., SP1) or the prior (e.g., CU3) Cumulative Update release. Note: We have learned some customers using 3rd party or custom transport agents may experience issues after installation of SP1. If you experience installation issues consult KB 2938053 to resolve this issue with transport agents. Looking Ahead Our next update for Exchange 2013 will be released as Exchange 2013 Cumulative Update 5. This CU release will continue the Exchange Server 2013 release process. If you want to learn more about Exchange Server 2013 SP1 and have the opportunity to ask questions to the Exchange team in person, come join us at the Microsoft Exchange Conference. Brian Shiers Technical Product Manager, Exchange.NET Framework 4.7 and Exchange Server
Update 6/15/2017: Added a clarification that .Net Framework 4.7 has shipped and that we are still validating this release with Exchange Server. We wanted to post a quick note to call out that our friends in .NET have released the .NET Framework 4.7 to Windows Update for client and server operating systems it supports. We are in the process of validating Exchange Server on the .NET Framework 4.7, but the work is not yet complete. We will be sure to release additional information and update the Exchange supportability matrix when .NET Framework 4.7 is supported with Exchange Server. We are working with the .NET team to ensure that Exchange customers have a smooth transition to .NET Framework 4.7, but in the meantime, please delay this particular .NET update on your Exchange servers. Information on how this block can be accomplished can be found in article 4024204, How to temporarily block the installation of the .NET Framework 4.7. It’s too late, I installed it. What do I do now? If .NET Framework 4.7 was already installed, we recommend you back to .NET Framework 4.6.2 Here are the steps: Note: These instructions assume you are running the latest Exchange 2016 Cumulative Update or the latest Exchange 2013 Cumulative Update as well as .NET Framework 4.6.2 prior to the upgrade to .NET Framework 4.7 at the time this article was drafted. If you were running a version of .NET Framework other than 4.6.2 or an older version of Exchange prior to the upgrade of .NET Framework 4.7, then please refer to the Exchange Supportability Matrix to validate what version of .NET Framework you need to roll back to and update the steps below accordingly. This may mean using different offline/web installers or looking for different names in Windows Update based on the version of .NET Framework you are attempting to roll back to if it is something other than .NET Framework 4.6.2. 1. If the server has already updated to .NET Framework 4.7 and has not rebooted yet, then reboot now to allow the installation to complete. 2. Stop all running services related to Exchange. You can run the following cmdlet from Exchange Management Shell to accomplish this: (Test-ServiceHealth).ServicesRunning | %{Stop-Service $_ -Force} 3. Depending on your operating system you may be looking for slightly different package names to uninstall .NET Framework 4.7. Uninstall the appropriate update. Reboot when prompted. On Windows 7 SP1 / Windows Server 2008 R2 SP1, you will see the Microsoft .NET Framework 4.7 as an installed product under Programs and Features in Control Panel. On Windows Server 2012 you can find this as Update for Microsoft Windows (KB3186505) under Installed Updates in Control Panel. On Windows 8.1 / Windows Server 2012 R2 you can find this as Update for Microsoft Windows (KB3186539) under Installed Updates in Control Panel. On Windows 10 Anniversary Update and Windows Server 2016 you can find this as Update for Microsoft Windows (KB3186568) under Installed Updates in Control Panel. 4. After rebooting check the version of the .NET Framework and verify that it is again showing version 4.6.2. You may use this method to determine what version of .NET Framework is installed on a machine. If it shows a version prior to 4.6.2 go to Windows Update, check for updates, and install .NET Framework 4.6.2. If .NET Framework 4.6.2 is no longer being offered via Windows Update, then you may need to use the Offline Installer or the Web Installer. Reboot when prompted. If the machine does show .NET Framework 4.6.2 proceed to step 5. .NET Framework 4.6.2 offline installer. .NET Framework 4.6.2 web installer. 5. After confirming .NET Framework 4.6.2 is again installed, stop Exchange services using the command from step 2. Then, run a repair of .NET 4.6.2 by downloading the offline installer, running setup, and choosing the repair option. Reboot when setup is complete. 6. Apply any security updates specifically for .NET 4.6.2 by going to Windows update, checking for updates, and installing any security updates found. Reboot after installation. 7. After reboot verify that the .NET Framework version is 4.6.2 and that all security updates are installed. 8. Follow the steps here to block future automatic installations of .NET Framework 4.7: How to temporarily block installation of the .NET Framework 4.7 The Exchange TeamReleased: Exchange Server 2013 Cumulative Update 3
The Exchange team is announcing today the availability of our most recent quarterly servicing update to Exchange Server 2013. Cumulative Update 3 for Exchange Server 2013 and updated UM Language Packs are now available on the Microsoft Download Center. Cumulative Update 3 includes fixes for customer reported issues, minor product enhancements and previously released security bulletins. A complete list of customer reported issues resolved in Exchange Server 2013 Cumulative Update 3 can be found in Knowledge Base Article KB 2892464. Note: Some article links may not be available at the time of this post's publication. Updated Exchange 2013 documentation, including Release Notes, will be available on TechNet soon. We would like to call attention to an important fix in Exchange Server 2013 Cumulative Update 3 which impacts customers who rely upon Backup and Recovery mechanisms to protect Exchange data. Cumulative Update 3 includes a fix for an issue which may randomly prevent a backup dataset taken from Exchange Server 2013 from restoring correctly. Customers who rely on Backup and Recovery in their day-to-day operations are encouraged to deploy Cumulative Update 3 and initiate backups of their data to ensure that data contained in backups may be restored correctly. More information on this fix is available in KB 2888315. In addition to the customer-reported fixes in Cumulative Update 3, the following new enhancements and improvements to existing functionality have also been added for Exchange Server 2013 customers: Usability improvements when adding members to distribution groups in the Exchange Administration Console (EAC) Windows Azure AD Rights Management available for use for IRM protection in on-premises Exchange deployments Improved administrator audit logging experience Windows 8.1/ IE 11 no longer require the use of OWA Light More information on these topics can be found in What’s New in Exchange Server 2013, Release Notes and Exchange 2013 documentation on TechNet. Before you deploy Exchange 2013 CU3... Here are some things to consider before you deploy Exchange 2013 CU3. Active Directory schema and configuration update: Exchange 2013 CU3 includes Exchange related updates to the Active Directory schema and configuration. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation. PowerShell Execution Policy: To prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to Unrestricted on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB 981474 to adjust the settings. Hybrid deployments and EOA: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to maintain currency on Cumulative Update releases. Our next update for Exchange 2013, Cumulative Update 4, will be released as Exchange 2013 Service Pack 1. Customers who are accustomed to deploying Cumulative Updates should consider Exchange 2013 SP1 to be equivalent to CU4 and deploy as normal. The Exchange Team
