Today, we are announcing the availability of new functionality in Outlook for iOS and Android that simplifies the Exchange on-premises email account set up with Microsoft Intune and other enterprise mobility management (EMM) solutions.  

Now administrators can simply push the account set up details via mobile device management (MDM) to deliver the user and server endpoint details. Users can then easily add their Exchange on-premises email accounts to Outlook for iOS and Android to get up and running virtually instantly.  This new functionality will facilitate large scale deployments of the leading, secure email client which is known to be loved by users and trusted by IT.  

Managing and configuring the Outlook for iOS and Android features such as Focused Inbox or contact synchronization capabilities are not in scope for this release although under consideration for the future.  

This account set up capability supports Intune and other EMM providers that leverage either Managed App Configuration for iOS or the Android Enterprise Channel to enable MDM solutions to push configuration detail. Devices must be running at minimum iOS 10 or Android 5.0 and the Exchange on-premises accounts must utilize the ActiveSync protocol with Basic Authentication. 

This enhancement was developed specifically to support on-premises Exchange accounts with basic authentication via the ActiveSync protocol and not accounts that support modern authentication (OAuth). Why?  Because Modern Authentication capable accounts (e.g., cloud based accounts such as Office 365 or hybrid on-premises accounts) already support two simplified scenarios for account set up today:

1. A single sign-on experience that automatically finds and authenticates the account.
2. AutoDetect functionality for users to simply enter an email address and then authenticate the account with their credentials to gain access.

For more information, see the following TechNet articles:

1. Easy onboarding of Modern Authentication capable accounts to Outlook for iOS and Android
2. Easy onboarding of Exchange 2016 on-premises accounts using Basic Authentication for Outlook for iOS and Android
3. Easy onboarding of Exchange 2013 on-premises accounts using Basic Authentication for Outlook for iOS and Android

Lexi Torres
Principal Program Manager
Outlook

Hybrid Free/Busy is one of those things that many people do not fully understand. If everything works well, the complexity is hidden from view and people working in various parts of organization can seamlessly work together. But if things go wrong… you will appreciate deeper understanding of what makes it work. This is why we wanted to create the blog post series on the subject.

In this article, we will discuss how Free/Busy works in an Exchange Hybrid configuration. In next blog post, you will learn what we (Microsoft Support) see as the most common problems along with how we go about diagnosing those (often) complex issues. Hope you like reading, because there is a lot to cover!

So, what is Free/Busy? Free/Busy is a feature that allows you to see when others are free (their calendar shows availability), busy (their calendar shows them as busy), or even Out of Office, or Something Else (tentative or working away) so that you can find an appropriate time for your meetings. Calling it all “Free/Busy/OOF/Something-Else” didn’t sound so cool to marketing hence “Free/Busy”. In a Hybrid deployment, we usually have some mailboxes in Exchange On-Premises and some mailboxes in Exchange Online (users are in different premises) and this has to work there too.

One of the most important parts in Hybrid Configurations is the Federation Trust and many features, including Free/Busy can rely upon this.

A quick overview of a hybrid deployment with a focus on Federation Trust components

In Contoso – On-Premises side we have on-premises Exchange Servers and mailboxes.

We also have a federation trust with the Microsoft Federated Gateway (MFG) - now called Azure Authentication System. A Federation trust is not set by default for Exchange On-Premises organizations and we can either create it manually or run the Hybrid Configuration Wizard (HCW) which will do this for us. If you don’t have already a federation trust established on-premises (usually for purposes to share F/B with another on-premises organization) and you plan for a Hybrid deployment, then we strongly recommend you run HCW to automatically create the Federation Trust.

In Contoso – Cloud Side there are Office 365 Exchange Online servers, your Office 365 tenant and mailboxes migrated from on-premises. A Federation trust with the MFG is automatically created for cloud-only-based Exchange organizations whom do not have a Hybrid relationship to an on-premises organization. If you run Get-FederationTrust cmdlet in Exchange Online PowerShell (see here how to connect to Exchange Online PowerShell) you would see two trusts: “WindowsLiveId” (Consumer Instance of Microsoft Federation Gateway) and “MicrosoftOnline” (Business Instance of Microsoft Federation Gateway) .

Note: As a troubleshooting tip, you might want to make sure the Application Identifier is “260563” and the Application Uri is “outlook.com” for both; in case you have a different App ID (292841) and a different App URI (outlook.live.com) for a Cloud trust, this means your tenant has an old reference pointing to MFG and most probably Free/Busy from on-premises to cloud would fail with a quite generic 401 Unauthorized error. If you were to find yourself in a such situation, please open a support case with Microsoft to get it resolved.

About Free/Busy lookup directionality

To guide you to the correct troubleshooting steps we first need to determine what direction Free/Busy queries are failing in. Understanding how Free/Busy works in general and the direction that lookups are failing can greatly simplify the troubleshooting steps.

Simply said, there are 2 possible Free/Busy directions (referring to our example above):

When Joe looks up Jane’s Free/Busy, the Free/Busy direction is On-premises to Cloud.

When Jane looks up Joe’s Free/Busy, the Free/Busy direction is Cloud to On-Premises

Now that you are familiar with the Free/Busy directions, we should take a moment to discuss how it all works.

Let me set the stage for the below diagram: joe@contoso.com has his mailbox in Exchange on-premises and jane@contoso.com has been moved to Exchange Online.

In Exchange on-premises, joe@contoso.com is a Mailbox User. Because Directory Synchronization is a requirement for Hybrid Deployments, joe@contoso.com (mailbox) is synced to the cloud and represented as a Mail Enabled User (MEU) object in Cloud with Target Address (TA) of joe@contoso.com.

jane@contoso.com was once a Mailbox User in Exchange on-premises. Her mailbox was then migrated to Exchange Online. Jane now has a Mailbox User in Exchange Online and is represented as a Remote Mailbox (RM) object in Exchange On-Premises.

Jane has a Primary SMTP address (SMTP: jane@contoso.com) and a secondary smtp address (smtp: jane@contoso.mail.onmicrosoft.com). Notice how we refer to a primary email address (SMTP) and to a secondary email address (smtp). According to TechNet, the difference between primary and secondary addresses is that the primary address serves as the return e-mail address. When mail is received from a recipient, the primary address determines which address the mail appears to have come from. Recipients can receive mail sent to any of the addresses associated with them (primary or secondary).

The Target Address (TA) of the on-premises Remote Mailbox object is represented as jane@tenant.mail.onmicrosoft.com (secondary smtp) and this is crucial for Autodiscover and email routing from on-premises to cloud. A successful Autodiscover query is important in the Free/Busy process as it provides us with the Availability Service URL of the user which is the External EWS URL of an Exchange Organization.

This TechNet article gives us more information on this <domain>.mail.onmicrosoft.com secondary email address:

The wizard (HCW) adds an accepted domain to the on-premises organization for hybrid mail flow and Autodiscover requests for the cloud organization. This domain, referred to as the coexistence domain, is added as a secondary proxy domain (contoso.mail.onmicrosoft.com) to any email address policies which have PrimarySmtpAddress templates for domains selected in the Hybrid Configuration wizard(contoso.com). By default, this domain is <domain>.mail.onmicrosoft.com.

Table below illustrates the hybrid user objects discussed above as well as how to look them up.

• On-premises commands = Exchange Management Shell
• Cloud commands = Exchange Online PowerShell

Typical Hybrid user objects configuration

Now that we understand user objects and their relevant properties, we should come back to Free/Busy directions.

Between the on-premises organization and cloud organization there are bidirectional Organization Relationships and/or bidirectional Intra Organization Connectors (for Exchange 2013 or later) that are created during Hybrid Configuration. The source of these Relationships / Connectors plays an important role in the F/B directionality.

The Free/Busy directions are:

Direction On-premises to Cloud

You are logged in to Outlook on the Web or Outlook on Windows as an on-premises user (joe@contoso.com), you’re your mailbox hosted on your on-premises Exchange server. As an on-premises user you wish to have a meeting with the cloud user (jane@contoso.com) but will first have to check their availability for the meeting. Let’s walk through the process:

1. Joe creates a meeting request and adds Jane as an attendee.

2. The on-premises Exchange server in Contoso determines (usually based on Target Address of the mail-enabled user) that Jane is not a local mailbox and has a different domain name of contoso.mail.onmicrosoft.com set as the Target Address.

3. The Availability Service on the on-premises Exchange server (Client Access Server if Ex2010 or Mailbox Server if 2013/2016) in Contoso then checks to see if there is a path to query Jane’s Free/Busy information for Contoso’s cloud side.

• First, we check if we have an Intra-Organization Connector (1) with the domain name of contoso.mail.onmicrosoft.com (assuming the Exchange server is version 2013 or later).
• If an IOC does not exist, then we look to see if an Organization Relationship (2) is configured by looking for the domain name of contoso.mail.onmicrosoft.com in the list of any existing Organization Relationships.
• If neither an IOC nor an Organization Relationship for the domain contoso.mail.onmicrosoft.com exists, then we look for the domain name contoso.mail.onmicrosoft.com as an Availability Address Space (3).

4. Assuming we would have an Exchange 2010-only environment in the on-premises and we’ve ran HCW successfully, we should expect to see both an Organization Relationship as well as a Federation Trust which combined is the second option from step #3. The Target ApplicationURI in the Contoso on-premises Organization Relationship is set to outlook.com, which is an identifier for the Contoso Cloud organization trust in the Azure Authentication System. A request is then made to the Azure Authentication System for a delegation token that will be accepted by Contoso Cloud Organization.

5. Once the delegation token is received back from the Azure Authentication System, the Exchange server in Contoso on-premises sends an Autodiscover request to Exchange Online, and upon a successful Autodiscover response will send an EWS request to Exchange Online for Jane’s availability information.

6. The Exchange Online server validates the token provided by the Azure Authentication System and once confirmed, returns the requested Free/Busy data for Jane’s mailbox.

Here is a flowchart which illustrates the Free/Busy lookup process:

Direction Cloud to on-premises

You are logged in to Outlook on the Web or Outlook on Windows as a cloud user (jane@contoso.com), whose mailbox is in Exchange Online. Jane wants to have a meeting with an on-premises user (joe@contoso.com), but must first check their availability for the meeting.

1. Jane creates a meeting request and adds Joe as an attendee

2. The Exchange Online servers in Contoso-cloud side organization determine (usually based on target address of a mail-enabled user) that Joe is not a local mailbox and has a domain name of contoso.com set as the target address.

3. The Availability Service on Exchange Online servers checks to see if there is a path for it to find the Free/Busy information for Contoso on-premises side organization.

• First, we check if we have an Intra-Organization Connector (1) with the domain name of contoso.com (assuming the Exchange server is 2013 or later on-premises).
• If an IOC does not exist, then we look to see if an Organization Relationship (2) is configured by looking for the domain name of contoso.com in the list of any existing Organization Relationships.
• If neither an IOC nor an Organization Relationship for the domain contoso.com exists, then we then look for the domain name contoso.com as an Availability Address Space (3).

4. Assuming we would have an Exchange 2010-only environment in the on-premises and we’ve ran HCW successfully, we should expect to see both an Organization Relationship as well as a Federation Trust which combined is the second option from step #3. The Target ApplicationURI in the Contoso Cloud Organization Relationship is set to FYDIBOHF25SPDLT.contoso.com, which is an identifier for the Contoso on-premises organization trust in the Azure Authentication System. A request is then made to the Azure Authentication System for a delegation token which will be accepted by Contoso on-premises organization.

5. Once the delegation token is received back from the Azure Authentication System, the Exchange Online server in Contoso cloud sends an Autodiscover request to the on-premises Exchange Servers and upon receipt of a successful Autodiscover response it will then send an EWS request for Joe’s availability.

6. The Contoso on-premises Exchange server validates the token provided by the Azure Authentication System and once confirmed, returns the requested Free/Busy data for Joe’s mailbox.

Hybrid Free/Busy lookup order

To summarize, the following order would be used when processing for Free/Busy lookups from cloud to on-premises:

1. Look for IntraOrganizationConnector (OAUTH)
2. If there is no IntraOrganizationConnector or if it is disabled, then look for Organization Relationship (DAUTH)
3. If neither of these are found or they’re disabled, then look for Availability Address Space. Availability Address Space is normally only used for Lotus Notes organizations. If Free/Busy lookup is getting all the way down to using the final Availability Address Space option for cloud to on-premises lookups in a hybrid deployment, then this would suggest there are configuration issues which must be repaired.

The order for Free/Busy lookups from on-premises to cloud is almost the same with some exceptions:

1. If we have Exchange 2007 servers in coexistence with Exchange 2010/2013, we use Availability Address Space from Exchange 2007 to Exchange 2010/2013 and then Exchange 2010/2013 will use Org Relationship (Ex2010) or IntraOrganization Connector (Ex2013) to Cloud.
2. If we have Exchange 2010 with Exchange 2013/2016 and OAuth is enabled, Exchange 2010 will use Availability Address Space to Exchange 2013/2016 and then 2013/2016 will use the IntraOrganization Connector to Cloud.
3. If we have Exchange 2010 with Exchange 2013/2016 and OAuth is not enabled, Exchange 2010 will not send the request to the Exchange 2013/2016. Instead Exchange 2010 will use Organization Relationship to Cloud for Free/Busy.

Exchange 2013 Cu5+ and Exchange 2016 organizations without coexisting with legacy Exchange servers will use by default IntraOrganization Connectors from On-Premises to Cloud (normal process)

This table summarizes which components (Get-IntraorganizationConnector / Get-OrganizationRelationship / Get-AvailabilityAddressSpace) are present (YES) or not (NO) in the Exchange Organization depending on the Exchange Server versions on-premises in a Hybrid deployment.

Free/Busy component matrix

Note: OAuth is by default configured by HCW in Exchange 2013 CU5 and above (including Exchange 2016) organizations. If Exchange 2013 / Exchange 2016 servers coexist with Exchange 2010 or older then OAUTH is not configured by default by the HCW but can be manually configured.

Note: Exchange 2013 CU5 is considered old and unlike wine, the finest CU is always the most recent one. You probably have heard about our n and n-1 supported version statement in Hybrid Deployments and can read more about it here and here.

Which Free/Busy lookup method are you using?

I won't go into all the details about the two types of authentication (OAUTH vs DAUTH) in this post, but I recommend reading this blog post at bedtime: Deep Dive: How Hybrid Authentication Really Works. As explained there, OAuth is an open-standards based model which is more preferred to a customized model.

You can quickly determine if you are using OAuth or not by running: Get-IntraOrganizationConnector cmdlet in Exchange Management Shell (for F/B direction On-Premises to Cloud) and in Exchange Online PowerShell (for F/B direction Cloud to On-Premises). If you see Enabled = True, then you are using OAuth or the system should at least be trying to.

Note: We also need to make sure that the Target Domain is present on the Intra Organization Connector or Organization Relationship when deciding if using OAUTH or DAUTH.

I have created two flowcharts to show you the logic of using OAUTH vs DAUTH in a F/B lookup process for each F/B direction.

The user’s setup remains still the same as shown in previous examples and I am reposting the diagram here so that you don’t need to scroll up.

1. Joe’s Exchange server deciding whether to use Oauth or Dauth :

2. Jane’s Exchange Online server deciding whether to use Oauth or Dauth

Now that you know which method is being used (or at least which should be attempted) and we know the direction Free/Busy is failing, we can see if you have everything configured correctly. In most cases these configurations are handled by the HCW and should be accurate and you can re-run the HCW to get things back to a good configuration.

• If Exchange On-Premises > Exchange Online Free/Busy is failing for all users, you would first check Intra Organization Connector or the Organization Relationship from on-premises.
• If Exchange Online > Exchange On-Premises Free/Busy is failing for all users, you would first check Intra Organization Connector or the Organization Relationship from Exchange Online.

Below, you will see a sample of the expected configuration for Intra Organization Connectors and Org Relationships from both sides (on-premises and cloud). This Baseline configuration was documented by my co-worker Ray Fong (Support Escalation Engineer) and I am very happy to have it when I troubleshoot Free/Busy issues.

Exchange Online side

Use this article to connect to Exchange Online PowerShell.

INTRA ORGANIZATION CONNECTOR IN CLOUD

Get-IntraOrganizationConnector | fl TargetAddressDomains,DiscoveryEndpoint,Enabled
TargetAddressDomains : {contoso.com}
DiscoveryEndpoint    : https://autodiscover.contoso.com/autodiscover/autodiscover.svc *
Enabled              : True

Note: In practice, the On-Premises Discovery Endpoint (Autodiscover) is more likely to be found in the format https://mail.contoso.com/autodiscover/autodiscover.svc because of the EWS External URL, so pay attention to this Autodiscover URL and replace it if needed with the autodiscover.yourdomain.tld on the IOC present in the Cloud Side (Reference Set-IntraOrganizationConnector)

Get-IntraOrganizationConfiguration | fl OnPremiseTargetAddresses
OnPremiseTargetAddresses : {contoso.com}

• TargetAddressDomains - This should be your federated domains. Example: contoso.com
  • You can find the domains name by cross-checking Exchange Online's (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses
• TargetDiscoveryEndpoint - This should be the address of the On-Premises Autodiscover Endpoint. Example: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/.If you paste the URL in IE, you should receive a regular windows authentication security prompt
• Enabled - This must be True.

Exchange On-Premises side (use Exchange Management Shell)

INTRA ORGANIZATION CONNECTOR IN ON-PREM

Get-IntraOrganizationConnector | fl Name,TargetAddressDomains,DiscoveryEndpoint,Enabled
Name                 : ExchangeHybridOnPremisesToOnline
TargetAddressDomains : {contoso.mail.onmicrosoft.com}
DiscoveryEndpoint    : https://outlook.office365.com/autodiscover/autodiscover.svc
Enabled              : True

• TargetAddressDomains - This should be your tenant.mail.onmicroosft.com name. Example: 'contoso.mail.onmicrosoft.com'
• TargetDiscoveryEndpoint - This should be the address of EXO Autodiscover endpoint. Example: https://outlook.office365.com/autodiscover/autodiscover.svc
• Enabled - This must be True.

Exchange Online side

Use this article to connect to Exchange Online PowerShell.

ORGANIZATION RELATIONSHIP IN CLOUD

Get-OrganizationRelationship "Exchange Online to on premises Organization Relationship" | fl DomainNames,FreeBusy*,Target*,Enabled
DomainNames           : {contoso.com}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel   : LimitedDetails
FreeBusyAccessScope   :
TargetApplicationUri  : FYDIBOHF25SPDLT.contoso.com
TargetSharingEpr      :
TargetOwaURL          :
TargetAutodiscoverEpr : https://autodiscover.contoso.com/autodiscover/autodiscover.svc/WSSecurity
Enabled               : True

• DomainNames - This should be your federated domains. Example: contoso.com
  • You can find the domains name by cross-checking On-Premises' (Get-FederatedOrganizationIdentifier).Domains
• TargetAutodiscoverEPR - This should be the address of the On-Premises Autodiscover Endpoint. Example: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/WSSecurity. If you paste the URL in IE, you should receive a regular windows authentication security prompt
• TargetSharingEPR - Ideally this is blank. If it is set, it should be the On-Premises Exchange servers EWS ExternalUrl endpoint. Example: https://server.contoso.com/EWS/Exchange.asmx
  • You can find the URL by cross-checking On-Prem's Get-WebServicesVirtualDirectory ExternaUrl. If you paste the URL in IE with /WSSecurity at the end (https://server.contoso.com/EWS/Exchange.asmx/WSSecurity), you should receive a regular windows authentication security prompt
• TargetApplicationURI - This must match the ApplicationUrI from On-Prem. Example: FYDIBOHF25SPDLT.contoso.com
  • You can find the value by cross-checking On-Prem's (Get-FederationTrust).ApplicationUri
• FreeBusyAccessEnabled - This must be True.
• FreeBusyAccessLevel - This should be either AvailabilityOnly or LimitedDetails.
  • AvailabilityOnly: Free/Busy access with time only
  • LimitedDetails: Free/Busy access with time, subject, and location
• FreeBusyAccessScope - This is typically blank. The FreeBusyAccessScope parameter specifies a security distribution group in the internal organization that contains users that can have their Free/Busy information accessed by an external organization.
• Enabled - This must be True.

Exchange On-Premises side (use Exchange Management Shell)

ORGANIZATION RELATIONSHIP IN ON-PREM

Get-OrganizationRelationship "On Premises to Exchange Online Organization Relationship" | fl DomainNames,FreeBusy*,Target*,Enabled
DomainNames           : {contoso.mail.onmicrosoft.com}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel   : LimitedDetails
FreeBusyAccessScope   :
TargetApplicationUri  : Outlook.com
TargetSharingEpr      :
TargetOwaURL          : https://outlook.com/owa/contoso.onmicrosoft.com
TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
Enabled               : True

• DomainNames - This should be your tenant.mail.onmicrosoft.com name. Example: contoso.mail.onmicrosoft.com
• TargetAutodiscoverEpr - This should be a valid Exchange Online Autodiscover endpoint. Example: https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity or https://pod51038.outlook.com/autodiscover/autodiscover.svc/WSSecurity [<-- A pod address]
  • You can find the value from TargetAutodiscoverEpr of Get-FederationInformaiton -DomainName tenantname.mail.onmicrosoft.com -BypassAdditionalDomainValidation | fl
• TargetSharingEPR - Ideally this is blank. If it is set, it should be Office 365 EWS endpoint. Example: https://outlook.office365.com/EWS/Exchange.asmx
• TargetApplicationURI - This must be outlook.com if this is for organization relationship of the cloud tenant. For non-cloud organization relationship, this must match (Get-FederationTrust).ApplicationUri of the On-Prem trust of the other organization.
• FreeBusyAccessEnabled - This must be True.
• FreeBusyAccessLevel - This should be either AvailabilityOnly or LimitedDetails.
  • AvailabilityOnly: Free/Busy access with time only
  • LimitedDetails: Free/Busy access with time, subject, and location
• FreeBusyAccessScope - This is typically blank. The FreeBusyAccessScope parameter specifies a security distribution group in the internal organization that contains users that can have their Free/Busy information accessed by an external organization.
• Enabled - This must be True.

Both Autodiscover and EWS virtual directories must be enabled for WSSecurity authentication and/or OAuth.

For example, if using OAuth, you should have OAuth listed as Authentication Methods, whereas if using only DAuth (Exchange 2010 for example), you would see only WSSecurity.

Example of virtual directories authentication methods for an Exchange 2013 Hybrid Organization:

Get-AutodiscoverVirtualDirectory -Server SERVER01 | fl Name,AdminDisplayVersion,*authentication*
Name                          : Autodiscover (Default Web Site)
AdminDisplayVersion           : Version 15.0 (Build 1044.25)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}

Get-WebServicesVirtualDirectory -Server server01| fl Name,AdminDisplayVersion,*Authentication*
Name                          : EWS (Default Web Site)
AdminDisplayVersion           : Version 15.0 (Build 1044.25)
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}

As explained earlier, there are some situations where Free/Busy from on-premises to cloud is going via Availability Address Space. This would be the expected configuration for Availability Address Space in Exchange on-premises (Exchange Management Shell):

Get-AvailabilityAddressSpace contoso.mail.onmicrosoft.com | fl ForestName, UserName, UseServiceAccount, AccessMethod, ProxyUrl, Name
ForestName        : contoso.mail.onmicrosoft.com
UserName          :
UseServiceAccount : True
AccessMethod      : InternalProxy
ProxyUrl          : https://server01.contoso.com/EWS/Exchange.asmx
Name              : contoso.mail.onmicrosoft.com

• ForestName - The should be the tenant.mail.onmicrosoft.com domain name. This should also match the domain name of RemoteRoutingAddress of remote mailboxes. Example: contoso.mail.onmicrosoft.com
• UserName - This should be blank.
• UserServiceAccount - This must be True.
• AccessMethod - This should be InternalProxy.
• ProxyUrl - This should be the Exchange 2013/2016 Exchange Web Services Virtual Directory URL. The address could be the internal FQDN or load balancing EWS URL. Example: https://server01.contoso.com/EWS/Exchange.asmx

We recommend you check the following requirements for inbound/outbound connectivity to and from Exchange servers in a Hybrid Deployment:

• Understanding Federated Delegation
• Office 365 URLs and IP address ranges

If you have read this far – thank you! This concludes the Part 1 of this blog series. Onto troubleshooting next!

Huge thanks to all that contributed to this blog post: Ray Fong, Nino Bilic, Tim Heeney, Greg Taylor and Brian Day.

Mirela Buruiana

Hello Exchange Server followers! In December 2017 it was announced Office 365 planned to discontinue support for TLS 1.0 and TLS 1.1 connections on March 1^st, 2018, and after that time only TLS 1.2 connections would be allowed when interacting with Office 365.

Many of you have been asking for additional detail on what this meant for on-premises deployments in hybrid mode or what happens if you do business with customers whom use Office 365 as their collaboration platform.

We would like to bring to your attention an update on Office 365’s plans to enforce TLS 1.2, which has now been communicated in this KB article (KB4057306). The end of support for TLS 1.0 and TLS 1.1 has been moved from March 1^st, 2018, to October 31^st, 2018 to allow for more time to prepare.

Though this date has been pushed back a bit, we will continue our Exchange Server TLS guidance blog post series soon. We also ask that you continue your preparations for this change, so you are in a position to not be impacted upon its completion.

The Exchange Team

In late December 2017, we announced support for EAI in Q1 2018.

We are happy to announce that EAI is now enabled in Exchange Online and Exchange Online Protection for Office 365. Office 365 users can now send messages to and receive messages from internationalized email addresses.

In addition, we are pleased to announce that EAI is also enabled for outlook.com customers (including hotmail.com, live.com, etc.).

In the meantime, we are working to enable EAI for Exchange Server 2019, the new on-premises version of Exchange that's coming out later this year.

Carolyn Liu

In this second part of the Demystifying Hybrid Free/Busy, we will cover troubleshooting of Hybrid Free/Busy scenarios, more specifically – how and where to find an actual error that will indicate where the problem is. Before venturing forth, please make sure that you have seen Part 1 of this demystifying series!

Here is the graphics we posted in the previous post; use this as a reference for users that we will be referring to when troubleshooting:

Do you really have a Free/Busy issue?

Usually when a user creates a new meeting in Outlook on the web (OWA) or Outlook, clicks on Scheduling Assistant, adds his or her colleague to the meeting, they try to see when the user is available to meet. If they see the hash marks \\\\\\\ instead of seeing if the other user is free or busy, there is an issue.

You can often see an error message by hovering over hash marks, however we usually find that the error is not very specific. Instead we would need to take slightly more advanced steps to diagnose the issues by checking things like the Outlook logs, F12 Network tab, or Fiddler.

Before getting to actual Free/Busy errors it is worthy to know that there is a Free/Busy test on Remote Connectivity Analyzer, Office 365 tab that can help us with some configuration /functional issues.

This Free/Busy test is useful for checking DNS records, Autodiscover and EWS connectivity issues, pre-authentication for Autodiscover or EWS requests. It is, however not a relevant Free/Busy test per se, as it uses Basic authentication and not Federated authentication used in actual Free/Busy lookups. Therefore, don’t be surprised if you see this test as green (successful) but Free/Busy is not working in your Hybrid Organization.

I would also like to mention that there is a Free/Busy troubleshooter in Beta version, incorporated into SARA tool (Microsoft Support and Recovery Assistant for Office 365) which you can download it from here : https://diagnostics.outlook.com/#/

Open SARA and select Outlook, click Next, select I’m having problems with my calendar, input email address and password of the source mailbox (cloud mailbox if direction not working is cloud > on-premises) and then select I can’t see when someone is free or busy.

Due to underlying complexity of it all, this is not a completely reliable way of determining the cause of free/busy issues in Hybrid Deployments, but it is a good start when troubleshooting. This F/B test from SARA covers mostly cloud to cloud scenarios but I recommend it here because it does connectivity and additional checks on tenant, licensing and Autodiscover.

Where can we see actual Free/Busy error message?

First, we need to understand in which direction we have a lookup problem. Please see Part 1 for discussion of directionality. Sources of logs:

• Outlook logs
• OWA F12 Network Tab
• Fiddler – Outlook and OWA

These steps are important in order for us to see the relevant message error for Free/Busy issues. Once we know the error message, it’s much easier to resolve the issue.

OUTLOOK

Note: you will be able to see the Free/Busy error in plain text in Outlook 2010 logs only, if you are using Outlook 2013/2016, you can’t see the error in the Outlook log and you would need to provide the Outlook ETL log containing the error to Microsoft Support to parse it.

You will still be able to use Fiddler to see the Free/Busy error yourself if you have Outlook 2013/2016 or you can use OWA F12 method while reproducing issue in OWA client but that only works if the on-premises Exchange server version is 2013 or above for the Source Mailbox user.

For the Outlook F/B error, we need to first enable Outlook logging and after this we will reproduce issue (\\\\\\). After repro, we will collect Outlook logs.

1. Enable Outlook logging:

Follow this KB article and check the Enable troubleshooting logging (this requires restarting Outlook) option. Restart Outlook.

2. Reproduce the issue for the non-working direction.

Suppose Free/Busy direction not working is cloud to on-premises, logged on as a cloud user, add some on-premises users to a meeting until you see the hash marks (instead of Free/Busy information). You do not need to save or send a meeting request.

Note that if Outlook logging is turned on, you will see the following notification in Outlook:

Example:

In this screenshot, Jane is a cloud user mailbox. Jane logged on to a mailbox using Outlook 2016 and she is creating the meeting (organizer). She adds 3 participants: ex2010mbx1, ex2013mbx1 and Joe – who are all on-premises user mailboxes.

Jane cannot see Free/Busy for any of them.

3. Collect Outlook logs

Outlook 2010: we need the AS.log from %temp%\OlkAS folder (reference here)

Open the AS.log and look for the error.

(click thumbnail to view larger)

Outlook 2013 / 2016: we need Outlook-#####.etl log from %temp%\Outlook Logging folder (reference here). You would need to send the ETL file to Microsoft Support to get it analyzed as we are parsing this log with an internal tool.

You might not know this but Hybrid free/busy support cases are free of charge! Of course, you can still use the other methods (fiddler for Outlook/OWA or browser for OWA) to see Free/Busy error yourself, however we (Support) might ask you additionally to get this log as in the Outlook ETL log we have the best logging for the Free/Busy errors.

OWA / Outlook on the web

Cloud OWA F12 Network tab

You need to login to OWA as the source mailbox, hit F12 (Developer Tools for browser) and select the Network Tab. You would then lookup Free/Busy for the target mailbox (reproduce the issue). Once you see the hashmarks, look for GetUserAvailabilityInternal Action then look at Response Body to see the error message.

Note: The source mailbox needs to be hosted on Exchange 2013 or above in on-premises or in Exchange Online for us to be able to see the error message in OWA using F12. This method will not work for Exchange 2010 source mailboxes.

This is how this could look like in Internet Explorer (similar in other browsers):

(click thumbnail to view larger)

Fiddler – OWA or Outlook

You would need to download and install Fiddler tool and reproduce the Free/Busy issue in OWA or Outlook.

If you reproduce the problem in OWA, you would search for GetUserAvailabilityInternal Action for owa service.svc entry and then look at JSON /Raw tab to see the error message. If the source mailbox is on Exchange 2010 server, this is what you’ll need to do.

OWA View - Fiddler:

(click thumbnail to view larger)

If you are logged in with Outlook, you would search for GetUserAvailabilityResponse, check the Raw tab and you can click on “View in Notepad” button on the right bottom corner.

Outlook view Exchange Online - Fiddler:

(click thumbnail to view larger)

Outlook view Exchange 2010 Source Mailbox - Fiddler

(click thumbnail to view larger)

When troubleshooting Free/Busy issues, the following on-premises logs can be very useful, especially for Cloud to On-Premises Free/Busy direction.

IIS logs Default Web Site (DWS)
%SystemDrive%\inetpub\logs\LogFiles\W3SVC1
Example: C:\inetpub\logs\LogFiles\W3SVC1

Example of Autodiscover and EWS entries with IOC Enabled in IIS W3SVC1 logs:

Autodiscover – OAUTH (autodiscover.svc without /WSSecurity)

2016-01-06 17:45:27 10.0.0.5 POST /autodiscover/autodiscover.svc &CorrelationID=<empty>;&ClientId=QNFNHKEEKYENCJITQQ&cafeReqId=7972d1fc-a9d9-44c6-8851-480d3601cbd7; 443 S2S~00000002-0000-0ff1-ce00-000000000000 132.245.65.28 ASAutoDiscover/CrossForest/EmailDomain//15.01.0361.007 200 0 0 109

EWS – OAUTH (exchange.asmx without /WSSecurity)

2016-01-06 17:45:27 10.0.0.5 POST /ews/exchange.asmx &CorrelationID=<empty>;&ClientId=WSIVGUUAUWWRFACJBWDA&cafeReqId=6ce8864c-74a0-4ad2-a3dc-7b69e0415403; 443 <unverified>actas1(sip:joe@contoso.com|smtp:joe@contoso.com|upn:joe@contoso.com) 132.245.65.28 ASProxy/CrossForest/EmailDomain//15.01.0361.007 200 0 0 703

Example of EWS entry with Organization Relationship Enabled in IIS W3SVC1 logs:

EWS – DAUTH (exchange.asmx with /WSSecurity)

2016-01-06 18:04:41 10.0.0.5 POST /ews/exchange.asmx/WSSecurity &CorrelationID=<empty>;&ClientId=VOMGJKAWURSVKOXQLBVA&cafeReqId=18fd3a2e-7b1c-4828-8943-6b20912e2e44; 443 - 132.245.65.28 ASProxy/CrossForest/EmailDomain//15.01.0361.007 200 0 0 296

IIS logs Exchange BackEnd (BE)
%SystemDrive%\inetpub\logs\LogFiles\W3SVC2
Example: C:\inetpub\logs\LogFiles\W3SVC2

Example of EWS entry with Organization Relationship Enabled (DAUTH) in IIS W3SVC2 logs:

2016-01-06 18:04:41 fe80::f17f:beef:a5e3:7d3c%25 POST /ews/exchange.asmx/WSSecurity - 444 - fe80::f17f:beef:a5e3:7d3c%25 ASProxy/CrossForest/EmailDomain//15.01.0361.007 200 0 0 93

HTTPProxy logs for Autodiscover
%ExchangeInstallPath%Logging\HttpProxy\Autodiscover
Example: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Autodiscover

Example of Autodiscover entry with Organization Relationship Enabled (DAUTH)

2016-01-06T18:05:20.552Z,bcdfbed5-f11f-4250-a616-e38cb475cd3f,15,0,1104,2,,Autodiscover,autodiscover.contoso.com,/autodiscover/autodiscover.svc /WSSecurity,,,false,,contoso.com,Smtp~joe@contoso.com,ASAutoDiscover/CrossForest/EmailDomain/ /15.01.0361.007,132.245.65.28,exch-2013,200,200,,POST,Proxy,exch-2013.contoso.com,15.00.1104.000,IntraForest,AnchorMailboxHeader-SMTP,[…],BeginRequest=2016-01-06T18:05:20.192Z;CorrelationID=<empty>;ProxyState-Run=None;FEAuth=BEVersion-1941996624;NewConnection=fe80::f17f:beef:a5e3:7d3c%25&0;

HTTPProxy logs for EWS
%ExchangeInstallPath%Logging\HttpProxy\Ews
Example: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Ews

Example of EWS entry with Organization Relationship Enabled (DAUTH):

2016-01-06T18:04:41.490Z,4757ab2c-8ccc-4d1a-ae39-0780ecc8eabb,15,0,1104,2,{02CD833F-18AB-413A-83CB-0E86F4DA5362},Ews,mail.contoso.com,/ews/exchange.asmx/WSSecurity,,,false,,contoso.com, Smtp~joe@contoso.com,ASProxy/CrossForest/EmailDomain//15.01.0361.007,132.245.65.28,exch-2013,200,200,,POST,Proxy,exch-2013.contoso.com,15.00.1104.000,IntraForest,AnchorMailboxHeader-SMTP,[…],BeginRequest=2016-01-06T18:04:41.380Z;

EWS logs
%ExchangeInstallPath%Logging\Ews
Example: C:\Program Files\Microsoft\Exchange Server\V15\Logging\Ews

Example of EWS entry with Organization Relationship Enabled (DAUTH):

2016-01-06T18:04:41.490Z,4757ab2c-8ccc-4d1a-ae39-0780ecc8eabb,15,0,1104,2,{02CD833F-18AB-413A-83CB-0E86F4DA5362}, External,true,jane@contoso.mail.onmicrosoft.com,, ASProxy/CrossForest/EmailDomain//15.01.0361.007,Target=None;Req=Exchange2012/Exchange2013; ,132.245.65.28,exch-2013,exch-2013.contoso.com,GetUserAvailability,200,12150,,,,,,ebd34d71ac7342c19d947d881db4ad55,f866c73e-6c91-475e-bdec-0428bdeaa423,PrimaryServer; Requester=jane@contoso.mail.onmicrosoft.com; Failures=0

Event Viewer Application logs on Exchange Server
References here and here.

Example of Event ID 4002 for MSExchange Availability:

Log Name: Application
Source: MSExchange Availability
Event ID: 4002
Task Category: Availability Service
Level: Error
Description:
Process 4568: ProxyWebRequest CrossSite from S-1-5-21-391720751-1508397712-925700815-508779 to https://hybrid.contoso.com/ews/exchange.asmx failed. Caller SIDs: NetworkCredentials. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Web.Services.Protocols.SoapException: You have exceeded the available concurrent connections for your account. Try again once your other requests have completed.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)

IIS tracing for the error code in the IIS logs
Reference here.

Free/Busy errors and fixes

Ray Fong and I made a table (ATTACHED) with the Free/Busy errors encountered so far in Support and their possible resolutions. We cannot cover all possible scenarios and errors even though we have a good-sized list. This is meant to illustrate ways we can resolve specific errors and these suggestions might not work for you even if you have the same error.

If you know the exact Free/Busy error that you get and checked configuration as discussed in part 1 of this series, this is already a tremendous progress, and this will help us resolve your issue faster.

Of course, you can follow these suggestions on your own as most of the actions are harmless but if you don’t feel confident in troubleshooting on your own or you fear that actions are dangerous or irreversible, please contact us.

Free/Busy Errors discussed in the attached table:

FB_Errors.FixesV4

• “An internal server error occurred. The operation failed”
• "The remote user mailbox must specify the the explicit local mailbox in the header"
• "An error occurred when verifying security for the message"
• "Unable to connect to the remote server"
• “Autodiscover failed for email address <> with error ‘The request failed with HTTP status 404: Not Found’ ”
• “The request failed with HTTP status 401: Unauthorized - The user specified by the user-context in the token is ambiguous”
• "An existing connection was forcibly closed by the remote host - An unexpected error occurred on a receive "
• "An existing connection was forcibly closed by the remote host - An unexpected error occurred on a send ”
• "Configuration information for forest/domain could not be found in Active Directory"
• "Proxy web request failed.,inner exception: The request failed with HTTP status 401: Unauthorized."
• "The response from the Autodiscover service at 'https://autodiscover/autodiscover.svc/WSSecurity' failed due to an error in user setting 'ExternalEwsUrl'. Error message: InvalidUser."
• “The caller does not have access to free/busy data"
• “The request failed with HTTP status 403: Forbidden (The server denied the specified Uniform Resource Locator (URL). “
• “Unable to resolve e-mail address user@notes.domain.com to an Active Directory object”
• “An error occurred when processing the security tokens in the message.”
• “The cross-organization request for mailbox yyy@contoso.com is not allowed because the requester is from a different organization”
• “The request failed with HTTP status 401: Unauthorized - Microsoft.Exchange.Security.OAuth.OAuth TokenRequestFailedException: Missing signing certificate “
• “The application is missing a linked account for RBAC roles, or the linked account has no RBAC role assignments, or the calling users account is logon disabled”
• “The entered and stored passwords do not match“
• “The password has to be changed.”
• “The password for the account has expired”
• “Provision is needed before federated account can be logged in”
• “The request timed out”
• “The specified member name is either invalid or empty”
• “The result set contains too many calendar entries”
• “The request failed with HTTP status 401: Unauthorized - The token has an invalid signature.”
• “The request failed with HTTP status 401: Unauthorized - Client assertion contains an invalid signature. [Reason - The key was not found., Thumbprint of key used by client: 'XXX’ “
• “Proxy web request failed., inner exception: Response is not well-formed XML “

Thanks to all that contributed to this content: Ray Fong, Nino Bilic, Tim Heeney, Greg Taylor and Brian Day.

Mirela Buruiana

We wanted to post a quick note to let you know that we have announced the retirement of OWA for iPhone, iPad and Android.  To learn more, head over to the Tech Community blog.

Outlook Team

The March quarterly release updates for Exchange Server are now available on the download center (links below). These releases include all previously released updates, fixes for customer reported issues and limited new functionality. Exchange Server 2010 SP3 Update Rollup 20 was released as a security update previously this month as well.

Exchange Server Support for TLS 1.2

With the March 2018 updates, Exchange fully supports TLS 1.2 on all supported Exchange versions. Brian Day has taken on the task of documenting and helping customers de-mystify the complexity involved with transitioning to TLS 1.2. Customers looking to implement TLS 1.2 should definitely review the published guidance before attempting to move to TLS 1.2. While implementing TLS 1.2 support in Exchange, we have chosen to consume and support the version TLS settings provided via the underlying operating system. This should dramatically ease the adoption of newer versions of TLS go forward.

Support for .NET Framework 4.7.1

Reminder that customers should be in the process of moving to .NET Framework 4.7.1. .NET Framework 4.7.1 will be required on Exchange Server 2013 and 2016 installations starting with our June 2018 quarterly releases. Customers should plan to upgrade to .NET Framework 4.7.1 after applying March 2018 quarterly release to avoid blocking installation of the June 2018 quarterly releases for Exchange Server 2013 and 2016.

Release Details

KB articles that describe the fixes in each release are available as follows:

• Exchange Server 2016 Cumulative Update 9 (KB4055222), Download, UM Lang Packs
• Exchange Server 2013 Cumulative Update 20 (KB4055221), Download, UM Lang Packs

None of the updates released today include new Active Directory schema since the September 2017 quarterly updates were released. If upgrading from an older Exchange version or cumulative update, Active Directory schema updates may still be required. These updates will apply automatically during setup if the logged on user has the required permissions. If the Exchange Administrator lacks permissions to update Active Directory schema, a Schema Admin must execute SETUP /PrepareSchema prior to the first Exchange Server installation or upgrade. The Exchange Administrator should execute SETUP /PrepareAD to ensure RBAC roles are current. PrepareAD will run automatically during the first server upgrade if Exchange Setup detects this is required and the logged on user has sufficient permission.

Additional Information

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.

Also, 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 KB981474 to adjust the settings.

Reminder: 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., 2013 CU19, 2016 CU8) or the prior (e.g., 2013 CU18, 2016 CU7) Cumulative Update release.

For the latest information on Exchange Server and product announcements please see What's New in Exchange Server 2016 and Exchange Server 2016 Release Notes. You can also find updated information on Exchange Server 2013 in What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.

Note: Documentation may not be fully available at the time this post is published.

The Exchange Team

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.

1. From Notepad.exe, create a text file named TLS12-Enable.reg.
2. Copy and paste the following text into the file.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.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

3. Save TLS12-Enable.reg.
4. Double-click the TLS12-Enable.reg file.
5. Click Yes to update your Windows Registry with these changes.
6. 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.

1. From Notepad.exe, create a text file named NET35-UseSchannelDefaults.reg.
2. 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

3. Save the NET35-UseSchannelDefaults.reg file.
4. Double-click the NET35-UseSchannelDefaults.reg file.
5. Click Yes to update your Windows Registry with these changes.
6. 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.

1. From Notepad.exe, create a text file named NET4X-UseSchannelDefaults.reg.
2. 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

3. Save the NET4X-UseSchannelDefaults.reg file.
4. Double-click the NET4X-UseSchannelDefaults.reg file.
5. Click Yes to update your Windows Registry with these changes.
6. 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

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 Experience

We’re announcing a new architecture for Exchange Server and Office 365 hybrid customers that unlocks Enterprise Mobility + Security (EMS) capabilities for Outlook for iOS and Android. With Hybrid Modern Authentication, Exchange customers can combine the power of Outlook with Azure Conditional Access and Intune App Protection Policies to securely manage corporate messaging on mobile devices.

Once Exchange customers with servers on-premises establish a hybrid configuration with the Microsoft Cloud and enable Hybrid Modern Authentication with Office 365, Outlook for iOS and Android authenticates against Azure Active Directory and synchronizes the mailbox data in Exchange Online – the Outlook mobile client never connects with the on-premises Exchange environment – unlocking the power of Office 365, Outlook for iOS and Android and Enterprise Mobility + Security (EMS).

Architected in the Microsoft Cloud, Outlook for iOS and Android is fully integrated with Azure Active Directory and Microsoft Intune. This means that organizations can enforce conditional access as well as application and device management policies while experiencing the richness of Outlook for iOS and Android.

Now Exchange Server customers with hybrid modern authentication can use the cloud-backed capabilities of Outlook such as Focused Inbox, Intelligent Search and enhanced time management to achieve more on their mobile device.

A few capabilities of EMS include:

• Selective wipe—Remove corporate email data and leave personal data intact to facilitate a “bring your own device” (BYOD) approach to phones and tablets.
• App restriction policies—Restrict actions such as cut, copy, paste and “save as” between Intune-managed apps and personal apps on a device to reduce the risk of corporate data loss. App restriction policies are available for use on both mobile device management (MDM) enrolled devices and on unmanaged devices, through Intune’s App Protection policies.
• Conditional access—Ensure that your corporate email can only be accessed on phones and tablets that meet secure access policies set by IT such as device or app management policy enforcement or Multi Factor Authentication (MFA) user scenarios. And with Azure Identity Protection capabilities of EMS, you can ensure these conditional access policies grant or deny access based on risks associated with each unique identity.

For the initial roll out, Exchange Server customers can contact their Microsoft account team, customer sales and services (CSS) or technical account managers to initiate the set up and deployment process for this enterprise mobility and security solution with Outlook for iOS and Android.

For more technical information and licensing requirements, see Using Hybrid Modern Authentication with Outlook for iOS and Android.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

In recent months we’ve been receiving quite a few questions from customers regarding auto-expanding archives. I’d like to clear up some of the misconceptions and answer some of the most frequently asked questions we get on this subject. Think of this as a FAQ on the subject.

Before we get going, I strongly advise folks to understand Message Records Management concepts like retention policies and tags. For example - there have been a few cases that we saw where customers enabled auto-expanding archives, but no archiving policies have been configured for the user.

What are auto-expanding archives?

It’s essentially a component that provides our customers the ability to grow their mailbox archives over the normal 100GB quota limit.

Much of the core concepts are covered in Overview of unlimited archiving in Office 365 and Enable unlimited archiving in Office 365 - Admin Help.

Let’s look at a simple picture to demonstrate this at a high level:

The user’s primary mailbox has an archive mailbox (the main archive) associated with it. The main archive is expanded with additional storage as content is moved to the archive mailbox either by the user or as part of an archival policy on the mailbox.

What are the licensing requirements for auto-expanding archives?

Auto-expanding archives are supported under the following service plans (EDU organizations included):

• Exchange Online Plan 2
• Exchange Online Archiving addon
• Office 365 Enterprise E3/E5

The above service plans contain the following capabilities we check on the mailbox:

• BPOS_S_ArchiveAddOn,
• BPOS_S_Archive,
• BPOS_S_Enterprise

PS C:\> Get-Mailbox testing1|select PersistedCapabilities
PersistedCapabilities
---------------------
{BPOS_S_EquivioAnalytics, BPOS_S_CustomerLockbox, BPOS_S_Analytics, BPOS_S_Enterprise}

The supported recipient types are:

• SharedMailbox, or
• UserMailbox, or
• MailUser

When can I expect the archive to expand?

We have a few values that we track on the Main Archive within this feature. The important value for our customers is essentially called the transition threshold. This is the size threshold of the main archive at which we will start provisioning new auxiliary archives (“Additional storage” in the illustration above) and start moving content from the main archive to the auxiliary archive. This threshold size is currently 90GB.

Why do I need to wait 30 days for expansion to take place?

This question comes up a lot and can be confusing, but technically, archives are expanded as soon as the managed folder assistant is able to successfully run on the main archive that has reached the transition size (90GB).

The 30-day period is the retention period for data that has been moved from the main archive to the auxiliary archive. We call this data ghosted content within the archive mailbox location and we keep a copy for 30 days to provide us (and you) with a safety net in the service in case we run into any issues during the data move from main archive to the auxiliary archive.

After that period expires we flush the data in the main archive to release the space.

Will the archive immediately expand when it reaches the threshold?

Expansion does not occur in real-time, in other words we only check if a mailbox should be expanded when managed folder assistant runs on the main archive. Managed folder assistant is expected to process the mailbox successfully within 7 days (it might be sooner depending on service load) or – you can initiate managed folder assistant on the main archive manually. The below is an example:

PS C:\> Get-Mailbox testing1|select -ExpandProperty MailboxLocations
1;b2b6421a-8bb0-4a91-9504-73cf42af570f;MainArchive;namprd00.prod.outlook.com;e4811b9b-4a10-4575-bb21-db3d32a9f4c2
1;df788e2e-cdaf-44fa-bc52-b7ef9f9bb40c;Primary;namprd00.prod.outlook.com;3128bfb0-76a7-4492-9de2-4924c8b8e443
1; ab7b6054-eab4-4ea4-bb71-58dc6c8bacc1;AuxArchive;namprd00.prod.outlook.com; 76d35997-4d27-402c-aa3e-ffcd3f898faf
PS C:\> Start-ManagedFolderAssistant b2b6421a-8bb0-4a91-9504-73cf42af570f

What happens if the archive has reached the quota limit and I enable auto-expansion?

In the past, if a mailbox under litigation hold was enabled for auto-expanding archive we would not increase the archive and recoverable items quotas above 100GB.

We have seen many cases where customers would enable auto-expanding archives on a mailbox that has already reached the archive quota limit and expect expansion to occur immediately. This puts a lot of pressure on the mailbox since there isn't any buffer to allow the expansion to complete successfully.

We have recently made some changes where we now increase the archive quota and recoverable items quota to 110GB if the mailbox is under litigation hold and auto-expanding archive is being enabled on the mailbox level.

If you enabled auto-expanding at the org level and/or mailbox level prior to this change, but the archive and recoverable items quotas are still 100GB, you can re-enable auto-expanding archives on the mailbox to get the additional 10GB increase. This will have no other effect on the archive when you run Enable-Mailbox and any quotas above 110GB will not be affected.

Let's look at a quick example of a mailbox under litigation hold that was enabled for auto-expanding archive prior to the change mentioned above:

PS C:\> Get-mailbox testing1|select archivequota,recoverableitemsquota
ArchiveQuota RecoverableItemsQuota
------------ ---------------------
100 GB (107,374,182,400 bytes) 100 GB (107,374,182,400 bytes)
PS C:\> enable-mailbox testing1 -AutoExpandingArchive
WARNING: Auto-expanding Archive is already enabled for 'testing1'.
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
Testing1 Testing1 co2pr00mb0198 99 GB (106,300,440,576 bytes)
PS C:\> get-mailbox testing1|select archivequota,recoverableitemsquota
ArchiveQuota RecoverableItemsQuota
------------ ---------------------
110 GB (118,111,600,640 bytes) 110 GB (118,111,600,640 bytes)

As you can see, after re-enabling auto-expanding archive, the quotas received an additional 10GB increase.

How do quotas work when a mailbox is enabled for auto-expanding archives?

Quotas seem to be a subject of confusion when auto-expanding archives are in the mix, so I want to focus a little bit on this topic.

The Archive and Recoverable Items quotas are essentially ignored for the aggregate size of all locations for the archive. We do however, still utilize and enforce the archive and recoverable items quotas to ensure each mailbox location does not grow out of control; we essentially keep the size of each location within the quota threshold.

If we look at the current mailbox example, each mailbox location for the archive (Main Archive and Aux Archive) will not grow past the Archive and Recoverable items quota limit which is set at 100GB and 30GB. But the aggregate size over all the auxiliary archives can go past the 100GB and 30GB values.

PS C:\> get-mailbox testing1 |select RecoverableItemsQuota,ArchiveQuota,ArchiveWarningQuota
RecoverableItemsQuota ArchiveQuota ArchiveWarningQuota
--------------------- ------------ -------------------
30 GB (32,212,254,720 bytes) 100 GB (107,374,182,400 bytes) 90 GB (96,636,764,160 bytes)

We don’t increase the recoverable items quota in this case since the mailbox is not on any hold and recoverable items are removed after the RetainDeletedItemsFor period (default 14 days).

The behavior for customers that have mailboxes on litigation hold will be a little different. In this scenario we increase the recoverable items and archive quotas to 110GB as seen below at the mailbox level (not the organization level). The mailbox was on litigation hold prior to enabling auto-expanding archives on the mailbox, so we increased the quotas to 110GB for recoverable items and archive quotas.

PS C:\> Get-mailbox testing2 |select RecoverableItemsQuota,ArchiveQuota,ArchiveWarningQuota
RecoverableItemsQuota ArchiveQuota ArchiveWarningQuota
--------------------- ------------ -------------------
110 GB (118,111,600,640 bytes) 110 GB (118,111,600,640 bytes) 100 GB (107,374,182,400 bytes)

Now let’s look at the aggregate item size of a mailbox with quite a lot of data. Here we can see that the TotalDeletedItemSize is way above the 110GB recoverable items quota for the mailbox, so expansion is working great.

PS C:\> Get-mailbox TheWhale|select RecoverableItemsQuota,ArchiveQuota,ArchiveWarningQuota
RecoverableItemsQuota ArchiveQuota ArchiveWarningQuota
--------------------- ------------ -------------------
110 GB (118,111,600,640 bytes) 110 GB (118,111,600,640 bytes) 100 GB (107,374,182,400 bytes)
PS C:\> Get-MailboxStatistics TheWhale -Archive |select TotalItemSize,TotalDeletedItemSize
TotalItemSize TotalDeletedItemSize
------------- --------------------
393 GB (421,964,016,454 bytes) 724 GB (777,408,505,123 bytes)

Let’s look at TotalDeletedItemSize for the individual mailbox locations for the main archive and the auxiliary archive.

PS C:\> Get-MailboxStatistics e7d87e1c-b39f-493f-8e56-9d271d6d23ea |select TotalDeletedItemSize
TotalDeletedItemSize
--------------------
102.6 GB (110,125,981,616 bytes)

We can see that the main archive mailbox location is currently sitting at 102.6GB and below we see one of the auxiliary archives is at 53.75GB.

PS C:\> Get-MailboxStatistics 62928e39-bc01-4763-84f5-84ac314ea5e1 |select TotalDeletedItemSize
TotalDeletedItemSize
--------------------
53.75 GB (57,714,208,258 bytes)

This mailbox will get another auxiliary expansion location assigned to it soon and content will then start to move into that new location.

The main archive in this mailbox also now contains 51.63GB of ghosted content that will be flushed within 30 days to release the space within the main archive. If you recall, we keep the content that we move to a new auxiliary location in the main archive for 30 days as a safety net.

The most recent auxiliary archive provisioned for this mailbox was mailbox guid 62928e39-bc01-4763-84f5-84ac314ea5e1. Let’s see what content was moved and is now marked as ghosted content in the main archive (e7d87e1c-b39f-493f-8e56-9d271d6d23ea).

PS C:\> Get-MailboxFolderStatistics e7d87e1c-b39f-493f-8e56-9d271d6d23ea|?{$_.LastMovedTimeStamp -and $_.Foldersize -gt 0}|select FolderSize,LastMovedTimeStamp,Contentmailboxguid
FolderSize LastMovedTimeStamp ContentMailboxGuid
---------- ------------------ ------------------
15.74 GB (16,900,662,851 bytes) 3/29/2018 2:24:04 PM 62928e39-bc01-4763-84f5-84ac314ea5e1
898.9 KB (920,440 bytes) 3/29/2018 2:24:04 PM 62928e39-bc01-4763-84f5-84ac314ea5e1
28.4 GB (30,495,702,247 bytes) 3/29/2018 2:24:05 PM 62928e39-bc01-4763-84f5-84ac314ea5e1
7.485 GB (8,037,032,197 bytes) 3/29/2018 2:24:05 PM 62928e39-bc01-4763-84f5-84ac314ea5e1

We can see the 51.63GB that are marked as ghosted content since we have a LastMovedTimeStamp of 3/29/2018 and a ContentMailboxGuid associated with the folders – which is the newly provisioned auxiliary location 62928e39-bc01-4763-84f5-84ac314ea5e1. This content will be flushed within approximately 30 days.

How much content is being moved to auxiliary archives during the transition?

These numbers can change as the service evolves, but right now we will move 50% of the occupied size in the main archive. If you have 100GB in the Main Archive at the point where Managed Folder Assistant processes the main archive, we will expand and provision a new auxiliary archive and move about 50GB into that auxiliary archive. We only move 50% to cater for additional folder growth in those folders that have been moved.

How is the transition size calculated?

Well, we simply look at how much occupied space the main archive is utilizing. Occupied space is essentially any folder in the main archive that is movable or type DeletedItems or RecoverableItems (folders marked green below).

You may notice that the DeletedItems and RecoverableItems folder types are not movable. For these folders we create movable folders under the root of the folders and move the content to those newly created folders to get picked up by managed folder assistant. All of this happens in the background, so you don’t have to worry about it.

Folders that do not fall into those categories are not taken into consideration during expansion. So please do not move 10’s of GB into the /Top of Information Store or the /Archive folders – we don’t cater for those… yet.

PS C:\> Get-MailboxFolderStatistics b2b6421a-8bb0-4a91-9504-73cf42af570f|select folderpath,movable,*type*
FolderPath Movable FolderType
---------- ------- ----------
/Top of Information Store False Root
/Archive False Archive
/Calendar True User Created
/Calendar/United States holidays True User Created
/Clutter False Clutter
/Deleted Items False DeletedItems
/Drafts True User Created
/ExternalContacts False ExternalContacts
/Files False Files
/Inbox True User Created
/PersonMetadata True User Created
/Sent Items True User Created
/Recoverable Items False RecoverableItemsRoot
/Calendar Logging False CalendarLogging
/Deletions False RecoverableItemsDeletions
/DiscoveryHolds False RecoverableItemsDiscoveryHolds
/Purges False RecoverableItemsPurges
/Versions False RecoverableItemsVersions

Can I ingest more than 100GB into the archive via a third party tool?

This is quite a tricky one for us. We don’t officially support bulk ingestion of more than 100GB into the archive at any one given time. There is currently work on going to provide solutions for these scenarios in the future, but we don’t have any timelines to share right now.

Since there are multiple ingestion scenarios we suggest that you contact Microsoft so that we can understand your situation and advise you on the best way forward for your ingestion project.

Special thanks to the following folks for reviewing and providing valuable input:

• Gagandeep Kohli – Snr Software Engineer
• David Santamaria – Snr Escalations Engineer
• Angela Taylor – Snr Program Manager

That’s all we have for now, I hope this helps you understand this feature a little better. The component team is working hard to continually improve the feature as we grow in the service and find unique scenarios that our customers use.

Michael Hall
Snr. Service Engineer

On January 14, 2020, Exchange Server 2010 will reach end of support. If you haven’t already begun your migration from Exchange 2010 to Office 365 or Exchange 2016, now’s the time to start your planning.

What does end of support mean?

Exchange Server, like almost all Microsoft products, has a support lifecycle during which we provide new features, bug fixes, security fixes, and so on. This lifecycle typically lasts 10 years from the date of the product’s initial release, and the end of this lifecycle is known as the product’s end of support. When Exchange 2010 reaches its end of support on January 14, 2020, Microsoft will no longer provide:

• Technical support for problems that may occur
• Bug fixes for issues that are discovered and that may impact the stability and usability of the server
• Security fixes for vulnerabilities that are discovered and that may make the server vulnerable to security breaches
• Time zone updates

Installations of Exchange 2010 will continue to run after this date. However, because of the changes listed above, we strongly recommend that you migrate from Exchange 2010 as soon as possible.

For more information about Office 2010 servers nearing the end of support, see Resources to help upgrade Office 2010 clients and servers.

What are my options?

With Exchange 2010 reaching its end of support, this is a great time to explore your options and prepare a migration plan. You can:

• Migrate to Office 365 using cutover, express, or hybrid migration
• Migrate your Exchange 2010 servers to a Exchange Server 2016 on your on-premises servers

The following sections explore each option in more detail.

Migrate to Office 365

Migrating your email to Office 365 is your best and simplest option to help you retire your Exchange 2010 deployment. With a migration to Office 365, you can make a single hop from old technology to our latest offering. Office 365 receives new features and experiences first and you and your users can usually start using them right away. Upgrading to a new version of Exchange – you’re always on the latest version of Exchange in Office 365.

How should I migrate to Office 365?

Depending on your organization, you have a few options that will help you get to Office 365. When choosing a migration option, you need to consider a few things like the number of seats or mailboxes you need to move, how long you want the migration to last, and whether you need a seamless integration between your on-premises installation and Office 365 during the migration. This table below shows your migration options and the most important factors that’ll determine which method you’ll use.

The following sections give you an overview of these methods.

Cutover Migration

A cutover migration is one where, at a pre-selected date and time, you’ll migrate all your mailboxes, distribution groups, contacts, and so on, to Office 365. When you’ve finished, you’ll shut down your on-premises Exchange servers and start using Office 365 exclusively.

The cutover migration method is great for small organizations that don’t have very many mailboxes, want to get to Office 365 quickly, and don’t want to deal with some of the complexities of the other methods. But it’s also somewhat limited because it should be completed in a week or less and because it requires users to reconfigure their Outlook profiles. While cutover migration can handle up to 2,000 mailboxes, we strongly recommend you migrate a maximum of 150 mailboxes with this method. If you try to migrate more than 150 mailboxes, you could run out of time to transfer all the mailboxes before your deadline, and your IT support staff may get overwhelmed helping users reconfigure Outlook.

If you’re thinking about doing a cutover migration, here are a few things to consider:

• Office 365 will need to connect to your Exchange 2010 servers using Outlook Anywhere over TCP port 443
• All on-premises mailboxes will be moved to Office 365
• You’ll need an on-premises administrator account that has access to read the contents of your users’ mailboxes
• The Exchange 2010 accepted domains that you want to use in Office 365 need to be added as verified domains in the service
• Between the time you start the migration and when you begin the completion phase, Office 365 will periodically synchronize the Office 365 and on-premises mailboxes. This lets you complete the migration without worrying about email being left behind in your on-premises mailboxes
• Users will receive new temporary passwords for their Office 365 account that they’ll need to change when they log in to their mailboxes for the first time
• You’ll need an Office 365 license that includes Exchange Online for each user mailbox you migrate
• Users will need to set up a new Outlook profile on each of their devices and download their email again

Express Migration

An express migration is one where you have a few hundred mailboxes that you want to migrate to Office 365, can complete the migration within a couple weeks, and don’t need any of the advanced hybrid migration features like shared Free/Busy calendar information.

Express migration is great for organizations that need to take more time to migrate their mailboxes to Office 365, but still plan to complete the migration within a couple weeks. You get some benefits of the more advanced full hybrid migration without many of the complexities. You can control how many, and which, mailboxes are migrated at a given time. Office 365 mailboxes will be created with the username and passwords of their on-premises accounts and, unlike cutover migrations, your users won't need to recreate their Outlook profiles.

If you’re thinking about doing a staged migration, here are a few things to consider:

• Office 365 will need to connect to your Exchange 2010 servers using Outlook Anywhere over TCP port 443
• You'll need to perform a one-time directory synchronization between your on-premises Active Directory servers and Office 365
• Users will be able to log in to their Office 365 mailbox using the same username and password they were using when their mailbox was migrated
• You’ll need an Office 365 license that includes Exchange Online for each user mailbox you migrate
• Users don’t need to set up a new Outlook profile on most of their devices (some older Android phones might need a new profile) and won’t need to re-download their email

Full Hybrid Migration

A full hybrid migration is one where your organization has many hundreds, up to tens of thousands, of mailboxes and you want to move some or all of them to Office 365. Because these migrations are typically longer-term, hybrid migrations make it possible to:

• Show on-premises users the free/busy calendar information for users in Office 365, and vice versa
• See a unified Global Address List (GAL) that contains recipients from both on-premises and Office 365
• View full Outlook recipient cards for all users, regardless of whether they're on-premises or in Office 365
• Users will be able to log in to their Office 365 mailbox using the same username and password they were using before their mailbox was migrated
• Users don’t need to set up a new Outlook profile on most of their devices (some older Android phones might need a new profile) and won’t need to re-download their email
• Secure email communication between on-premises Exchange servers and Office 365 using TLS and certificates
• Treat messages sent between on-premises Exchange servers and Office 365 as internal, enabling them to:
  • Be properly evaluated and processed by transport and compliance agents targeting internal messages
  • Bypass anti-spam filters

Full hybrid migrations are best for organizations that expect to stay in a hybrid configuration for many months or more. You’ll get the features listed earlier in this section, plus directory synchronization, better integrated compliance features, and the ability to move mailboxes to and from Office 365 using online mailbox moves. Office 365 becomes an extension of your on-premises organization.

If you’re thinking about doing a full hybrid migration, there are a few things to consider. Full hybrid migrations aren’t suited to all types of organizations. Due to the complexity of full hybrid migrations, organizations with less than a few hundred mailboxes don't typically see benefits that justify the effort and cost needed to set one up. If this sounds like your organization, we strongly recommend that you consider Cutover or Express Migrations instead.

Migrate to Exchange Server 2016

While we strongly believe that you can achieve the best value and user experience by migrating to Office 365, we also understand that some organizations need to keep their email on-premises. This could be because of regulatory requirements, to guarantee data isn’t stored in a datacenter located in another country, and so on. If you choose to keep your email on-premises, you can migrate your Exchange 2010 environment to Exchange 2016. Exchange 2016 includes the features and advancements included with previous releases of Exchange, and it most closely matches the experience available with Office 365 (although some features are available only in Office 365).

Migration path to Exchange 2016

Here are the general phases for migrating to Exchange 2016:

• Install Exchange 2016 into your existing Exchange 2010 organization
• Move services and other infrastructure to Exchange 2016
• Move mailboxes and public folders to Exchange 2016
• Decommission remaining Exchange 2010 servers

Version coexistence

When migrating to Exchange 2016, you can install into an existing Exchange 2010 organization. This enables you to install one or more Exchange 2016 servers and perform your migration.

Server hardware

Server hardware requirements have changed from Exchange 2010. You’ll need to make sure the hardware you’re going to use is compatible. You can find out more about hardware requirements here.

How do I migrate to Exchange 2016?

If you’ve decided that you want to keep your email on-premises, you can use the following resources to help you with your migration:

• Exchange Deployment Assistant
• Active Directory schema changes for Exchange 2016
• System requirements for Exchange 2016
• Prerequisites for Exchange 2016

What if I need help?

If you’re migrating to Office 365, you might be eligible to use our Microsoft FastTrack service. FastTrack provides best practices, tools, and resources to make your migration to Office 365 as seamless as possible. Best of all, you’ll have a real support engineer that will walk you through your migration, from planning and design all the way to migrating your last mailbox. If you want to know more about FastTrack, take a look at Microsoft FastTrack.

If you run into any problems during your migration to Office 365 and you aren’t using FastTrack, or your migration to a newer version of Exchange Server, we’re here to help. Here are some resources you can use:

• Technical Community
• Customer Support

Exchange Team

Exchange Server 2013 enters the Extended Support phase of product lifecycle on April 10th, 2018. During Extended Support, products receive only updates defined as Critical consistent with the Security Update Guide. For Exchange Server 2013, critical updates will include any required product updates due to time zone definition changes.

With the transition of Exchange Server 2013 to Extended Support, the quarterly release schedule of cumulative updates will end. The last planned cumulative update for Exchange Server 2013, Cumulative Update 21, will be released in June 2018. Microsoft may at its discretion release a future cumulative update to aggregate previously released critical updates or to address unforeseen future O365 Hybrid connectivity requirements. At this time there is no explicit plan to exercise releasing future cumulative updates.

Microsoft encourages Exchange Server 2013 customers to adopt Cumulative Update 21 as soon as possible to ensure uninterrupted delivery of any future security related fixes. This includes customers who may still be running Exchange Server 2013 Service Pack 1. After September 19th 2018, only Cumulative Update 21 or its successors will receive critical updates. During the Extended Support phase, only the latest cumulative update is eligible to receive critical updates once the standard 3 month transition period of the prior cumulative update has lapsed.

Critical updates will continue to be made available via Windows Update and the Microsoft Download Center. Additional lifecycle information for all Microsoft products is available on support.microsoft.com.

Exchange Team

After over five years of providing configuration information and solutions to known issues, the OffCAT team is planning to remove OffCAT from the Microsoft Download Center on May 31, 2018. The good news is that core OffCAT features have been consolidated with the Microsoft Support and Recovery Assistant for Office 365 (SaRA) tool at https://diagnostics.outlook.com/. This will simplify the lineup of troubleshooting tools available for Outlook while at the same time provide the same level of Outlook scanning capabilities as OffCAT. In addition, SaRA also offers several enhancements including the ability to identify and fix specific issues with Outlook, Office Setup, OneDrive for Business, and several other Office programs.

We encourage you to transition very soon to the SaRA tool to scan for issues in Outlook. To help you with your transition, the OffCAT team compiled the following FAQ:

Where can I get information on scanning Outlook with SaRA?

Complete details on scanning Outlook for known issues or configuration information are available in How to scan Outlook by using the Microsoft Support and Recovery Assistant tool.

Do I need an Office 365 account to run SaRA?

To scan Outlook for known issues and to create a detailed report of your Outlook configuration, you do not need an Office 365 account. However, for most of the other scenarios provided in SaRA, you will need an Office 365 account.

Will OffCAT be uninstalled during the SaRA installation?

If already installed, OffCAT will not be automatically uninstalled when you install SaRA. OffCAT and SaRA use two separate installations that are not tied together.

Will OffCAT rules continue to be updated?

We are planning on updating and publishing OffCAT rules to the Internet through August 31, 2018. After this date, OffCAT will continue to function, but your scan results can be out-of-date.

Will I still be able to view existing OffCAT scans?

Yes. As long as you have OffCAT installed, you can view any OffCAT scan.

Which OffCAT features are not found today in SaRA?

The OffCAT team migrated the most frequently used features to SaRA. Here are the features that were not migrated and links to alternative resources (if available).

• ROIScan. The ROIScan tool is available here.
• CalCheck. Please see Information about the Calendar Checking Tool for Outlook (CalCheck).
• OffCAT add-in
• Command-line version
• Scanning Office applications other than Outlook. If you need troubleshooting issues with other Office applications, we recommend these alternative resources:
  • Microsoft Communities
  • Office Help & Training

Note, SaRA does provide scenarios that identify and address issues with the following Office programs:

• Outlook
• Office Setup and Activation
• OneDrive for Business
• Skype for Business
• KMS client activation

To troubleshoot KMS activation issues, we recommend these resources:

• Troubleshoot volume activation for Office 2016
• Troubleshoot volume activation for Office 2013
• Real-time logging

How do I request features for SaRA?
We hope that SaRA was able to detect and possibly provide a fix for your Outlook issue. Regardless of the outcome, however, you can suggest features when you see the survey at the end of the scenario.

Greg Mansius

There are a number of client protocols offered by Exchange Online to allow email clients to send email from their mailboxes. One of the most widespread protocols is SMTP Authenticated Submission (also known as SMTP Client Submission) which is supported by most email service providers. This non-proprietary protocol is used to send email by legacy email clients, third-party software and services, and devices such as multi-function printers. Changes that we’re making to how this protocol works in Exchange Online may adversely affect the rate at which these clients or devices can send email.

Starting June 1, the following changes will begin rolling out for SMTP Authenticated Submission protocol:

• Sent email will now be stored in the Sent Items folder of the mailbox.
• Only three concurrent connections to our service per mailbox will be allowed. Additional connections will be rejected with the error: 4.3.2 STOREDRV.ClientSubmit; sender thread limit exceeded.

Exchange Online uses a number of mechanisms to protect the service from abuse and ensure fair usage by users. One such protection is the Recipient Rate Limit (RRL) which limits the number of recipients per day to 10,000. The aim is to deter the sending of bulk email (and as mentioned on the service limits page, you should send bulk email using a specialized third-party provider). This change to the SMTP Authenticated Submission protocol will further protect the service from large bursts of emails in a short amount of time from automated systems. This will not affect the majority of SMTP Authentication Submission users who only send from one email client or multi-function device for a given mailbox.

For customers who have numerous devices sending emails using the same mailbox (for example, printer@contoso.com), there’s a small chance that multiple devices will try to send email at the same time. Any devices that are rejected would just need to retry. The same is true if an application that uses a cloud mailbox to send email tries to send multiple messages at the same time (and that behavior depends on how the application was designed). Most applications and devices that send email should be able to handle errors and retry sending email. However, retrying will reduce the overall rate at which email can be sent.

If this change adversely affects you, you have a few options:

1. Use a different mailbox for each application or device.
2. If you’re trying to send thousands of copies of the same message (for example, a newsletter) in parallel using a third-party application, you may need to send it out in batches or use distribution groups.
3. If time is important (for example, an alert system that generates multiple alerts at the same time), you’ll need to use a third-party delivery service that’s designed to send large amounts of email.

Sean Stevenson

Last September, we officially announced the increase of the supported limit of Public Folders in Exchange Online from 100,000 to 250,000.

In line with our efforts to scale Public Folders even further, we are glad to announce that Exchange Online now officially supports public folder hierarchies of up to 500K public folders in the cloud – double the previously supported limit of 250K public folders!

What does this mean?

All existing customers using Exchange Online who are currently constrained by the limit of 250K public folders, can now expand their Exchange Online public folder hierarchy up to 500K folders.

The current Exchange Online limits can be viewed here.

Note about migrations: Exchange 2013/2016 customers can still only migrate up to 100K public folders to Exchange Online, and Exchange 2010 customers can only migrate up to 250K public folders to Exchange Online. However, once folders are migrated to Exchange Online, you can expand the hierarchy up to 500K public folders. We are working to resolve these limitations in the future.

Keep checking this blog for further updates on the subject.

In case of any questions, please ask via the comments section below.

Public folder team

In July 2017, we announced that support for Session Border Controllers (SBC) that connect 3rd Party PBX systems to Exchange Online Unified Messaging (UM) would be discontinued as of July 2018. After feedback from customers and partners concerned about this change, we are announcing additional time for customers to prepare. The new date for discontinuation will be April 30, 2019. Customers with existing deployments remain fully supported until this date. However, Microsoft strongly advises all customers to begin their voicemail transition now. There are different alternatives for customers currently using an on-premises PBX system that connects to Exchange Online. We recognize that customers may also choose a combination of these options for their organization.

• Office 365. We believe the best option for customers is to transition to the cloud and use Office 365. This would include the enterprise voice workload and Cloud Voicemail. Customers would use Microsoft Teams for collaboration and voice services.
• Skype for Business Server. In this configuration, customers would deploy an on-premises Skype for Business server and take advantage of the services for voicemail supported by the server.
• 3^rd Party Voicemail System. With this approach, the customer acquires a 3rd party voicemail system that provides all the capabilities required to process voicemail and then place it in the user’s Exchange mailbox.

In past communications, customers may remember that we discussed another alternative which included voicemail routing.  These solutions involved vendors who rely upon Skype for Business and Exchange UM for the solution. It’s important to note that Microsoft does not certify these solutions. There may be impact to these 3rd party solutions as we evolve our architecture for voicemail. As 3rd party providers will be your primary source of support for these solutions, we recommend customers work with these vendors to ensure the longevity and supportability of the solution.

We know these changes can be challenging in the near-term. But we believe that continuing to identify areas where we can evolve the service we provide while taking full advantage of the cloud is the right answer. We will continue to evaluate emerging needs as customers make the transition from legacy dedicated voice to Microsoft’s Intelligent Communications solutions.

For customers that may have more questions, please contact your account team or Microsoft Support.  Customers already using Office 365 can submit a support case through the Office 365 Admin Portal.

Exchange team

Overview

Message Trace is a key tool for email admins to troubleshoot and track the health of their organization's mail flow. Message Trace in the Exchange Admin Center (EAC) is a useful tool for tracing messages, but it's visually cluttered and confusing, and it lacks a number of more sophisticated capabilities.

To make Message Trace more effective and easier for both professional and part-time email admins, we've redesigned Message Trace and placed it in the Office 365 Security & Compliance Center. The new Message Trace sports a streamlined, modern interface, and adds a number of new features that will help you get your job done more quickly and with greater effectiveness.

What's New

Message Trace Start Page

• All your queries, extended message trace requests, and downloadable reports on a single page.
• Save custom queries, for fast and error-free querying in the future.
• Recent queries are automatically saved – pick up where you left off, no need to start from scratch again.

New Message Trace Panel

• A more modern, streamlined and intuitive interface that's simpler to understand and use, helping you get your job done more quickly.
• New inline address picker to select and validate senders and recipients with fewer clicks.
• New time range slider to easily and visually choose common query start and end times.
• You can now view up to the last 10 days of data in real-time (previously limited to 7 days).
• Downloadable extended message trace reports are now available for any date range, not just those starting more than 7 days ago.

Updated Results Panel

• View up to 10,000 records in the Results panel (previous maximum was 1,000).
• Results are displayed in your default or custom time zone, instead of UTC.
• Filter results by Sender, Recipient, Subject or Status.
• Export the results you want to a CSV file (all, filtered, loaded, or selected).
• Find related message records: Select an item and find all related items that share the same message ID.
• Color-coded delivery status makes it easier to quickly spot possible issues.
• View message details more easily with a single click, or from the more info (. . .) fly-out menu.

Message Details Panel

While the key updates in the new Message Trace are the new start page and improvements to the search and results panels, the Message Trace details panel was also updated. The details panel continues to provide the same rich, diagnostics and recovery guidance as before, but it's been slightly streamlined, now using expandable sections to tuck the message events and more information details out of the way until you need them.

The new Message Trace in the Security & Compliance Center is deploying now and should be available for all Office 365 customers by the middle of May.

Frequently Asked Questions

Will the new Message Trace replace Message Trace in Exchange Admin Center (EAC)?

No. The new Message Trace is only available in the Security & Compliance Center (SCC). The legacy Message Trace in the EAC and the new Message Trace in SCC will co-exist for the foreseeable future.

Why is the new Message Trace located in the Security & Compliance Center instead of the Exchange Admin Center?

A significant part of an email admin's day-to-day job is keeping their organization's email secure, reducing or eliminating spam, protecting users from phishing and malware attacks, and preventing sensitive data from leaving the organization (data loss prevention or DLP). We've placed the new Message Trace in the SCC alongside the email antispam, antimalware, and DLP tools that already exist in the SCC, to give email admins a single location that hosts most of the tools they regularly work with.

What roles are required to access Message Trace in the SCC?

The new Message Trace in the SCC supports the same roles as the legacy Message Trace in the EAC, including Global administrator, Exchange administrator, and others.

Will this new Message Trace ship to on-premises Exchange?

At this time, we have no plans to ship this on-premises. The Security & Compliance Center is a purely online portal and does not exist in our on-premises releases.

If my organization is in Hybrid mode – what happens?

You will still be able to use this, but only for email traffic that goes through our cloud infrastructure. You will not be able to use this to track messages that are sent purely on-premises.

Kevin Shaughnessy

We're excited to announce that Mail flow Insights will soon be available in the Office 365 Security & Compliance Center. We'll continue to create and refine mail flow insights to help improve productivity for admins, and we'll announce them as they become available. The first wave of capabilities is being released in May 2018 and we're currently in the deployment stage; features shall start to show up for you on the week of May 14.

Admins can use mail flow dashboard in the Office 365 Security & Compliance Center to discover trends, insights and take actions to fix issues related to mail flow in their Office 365 organization.

You can see the details in this doc. But a quick summary is listed below.

Where to find the mail flow insights

1. Go to the Office 365 Security & Compliance Center at https://protection.office.com.
2. Expand Mail flow and then select Dashboard.

Capabilities in mail flow dashboard

Here are the first wave of capabilities that are being released in May 2018.

Queue alerts

When messages can't be sent from your Office 365 organization to your on-premises or partner email servers using connectors, the messages are queued in Office 365. Office 365 will continue to retry to delivery for 48 hours. After 48 hours, the messages will expire and will be returned to the senders in non-delivery reports (also known as a NDRs or bounce messages).

If the queued email volume exceeds the pre-defined threshold (the default value is 2000 messages), the alerts will be available in the mail flow dashboard at Recent alerts, and admins will receive an email notification (to their alternative email address).

Queues

Even if the queued message volume hasn't exceeded the threshold, you can still use the Queues area of the mail flow dashboard to see messages that have been queued for more than one hour. You can use the Queues area to monitor the number of queued messages (the value 0 indicates mail flow is OK) and take action before the number of queued messages becomes too large.

Forwarding report

The Forwarding Overview Report in the mail flow dashboard displays information on messages that are automatically forwarded from your Office 365 organization to recipients in external domains.

TLS report

The TLS Overview Report displays the TLS encryption that's used for the connection when messages are delivered to and from your Office 365 organization. The connections that are established with other email services are encrypted by TLS when TLS is offered by both sides.

Connector report

The Connector Report displays information about messages that are delivered to and from your Office 365 organization using connectors. You use connectors between your own email servers and Office 365 or your partner's servers and Office 365. The message volume for each connector and the TLS encryption for the connection is available.

Mail loop insight

A mail loop is bad because it wastes system resources, consumes your organization's mail volume quota, and sends confusing non-delivery reports (also known as NDRs or bounce messages) to the original senders. This insight reports when a mail loop is found in your organization, the email domains that are involved in the loop, and the number of messages from the previous day that were in the loop.

Slow mail flow rules insight

Inefficient mail flow rules (also known as transport rules) can lead to mail flow delays for your organization. This insight reports mail flow rules that have an impact on your organization's mail flow.

The insight will help you to identify and fine-tune mail flow rules to help reduce mail flow delays.

Let us know how you like it!

Carolyn Liu

Overview

In part 3 of our Exchange Server TLS Guidance series, we introduce how to turn off TLS 1.0 and 1.1 in your Exchange Server deployment. Turning off TLS 1.0 and 1.1 can be a highly disruptive event if not planned and executed properly. The Exchange team believes that it is time for the ecosystem to fully embrace TLS 1.2, but urges you to proceed with caution when disabling TLS 1.0 and 1.1. This includes understanding how and being prepared to reverse the configuration steps if necessary.

Assumption

Before disabling TLS 1.0 and 1.1, it is important that you have completed the steps outlined in Part 1: Getting Ready for TLS 1.2 and Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It. Do not proceed until you have completed these steps on all Exchange servers, have read all of Part 3 (this post) and understand the implications of disabling TLS 1.0 and 1.1.

Disabling TLS 1.0 and 1.1

We have attempted to simplify adopting newer versions of TLS by aligning Exchange configuration to the operating system capabilities. In Exchange Server 2016 and later, Exchange fully inherits the capabilities of the operating system on the platform where Exchange is installed. Exchange Server 2013 behaves the same as Exchange 2016 with the exception of POP and IMAP. Exchange 2010 has a similar restriction for POP and IMAP but behaves differently than Exchange 2013 (see the About POP and IMAP section below). The steps used to disable TLS 1.0 and 1.1 outlined below will apply to the following Exchange functionality:

• Simple Mail Transport Protocol
• Outlook Client Connectivity
• Exchange Active Sync
• Outlook on the Web (and Outlook Web App / Outlook Web Access in earlier versions of Exchange)
• Exchange Admin Center and Exchange Control Panel
• Autodiscover
• Exchange Web Services (and Representational State Transfer “REST” where implemented)
• Use of PowerShell by Exchange over HTTPS
• POP and IMAP (Exchange Server 2013 and later only)

Disable TLS 1.0 and 1.1 in SChannel

All Windows Server Versions

In Part 2, we introduced how to enable TLS 1.2 in Windows SChannel using the Windows Registry. To disable TLS 1.0 and 1.1 you make use of the same Enabled and DisabledByDefault DWORD entries, but with different values. An admin must modify the TLS 1.0 and TLS 1.1 portions of the SChannel registry section and turn the protocols off instead of turning them on.

To disable TLS 1.0 for both Server (inbound) and Client (outbound) connections on an Exchange Server perform the following:

1. From Notepad.exe, create a text file named TLS10-Disable.reg.

2. Copy and paste the following text into the file.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

3. Save TLS10-Disable.reg.

4. Double click the TLS10-Disable.reg file.

5. Click Yes to update your Windows Registry with these changes.

6. Restart the machine for the changes to take effect.

To disable TLS 1.1 for both Server (inbound) and Client (outbound) connections on an Exchange Server please perform the following:

1. From Notepad.exe, create a text file named TLS11-Disable.reg.

2. Copy and paste the following text into the file.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

3. Save TLS11-Disable.reg.

4. Double click the TLS11-Disable.reg file.

5. Click Yes to update your Windows Registry with these changes.

6. Restart the machine for the changes to take effect.

About POP/IMAP

Exchange Server 2010

The Exchange product updates which allow POP/IMAP to dynamically consume the operating system SChannel configuration settings for POP/IMAP connections are not available in Exchange Server 2010. POP/IMAP are still dependent upon SChannel configuration, but are hard coded to allow TLS 1.0 or SSL 3.0 negotiation only in Exchange Server 2010. As of the posting date for this entry, if TLS 1.0 is disabled in SChannel, clients will fallback and attempt to negotiate SSL 3.0. If SSL 3.0 is disabled, client negotiation will fail. There are no current plans to change this product behavior. Microsoft’s implementation of TLS 1.0 has no known vulnerabilities but SSL 3.0 use is strongly discouraged. Customers who need to ensure that TLS 1.2 is used for SMTP / HTTPS traffic may need to add servers specifically configured to support TLS 1.0 only for POP/IMAP if needed in their environment.

Note: We assume that most customers have disabled SSL 3.0 already. If not, the process used to disable SSL 3.0 can be found at support.microsoft.com.

Exchange Server 2013

Similar to Exchange Server 2010, POP/IMAP on Exchange Server 2013 does not dynamically inherit the operating system SChannel settings. POP/IMAP protocols are hard coded to negotiate TLS 1.2 in Exchange Server 2013. This means customers can proceed with disabling TLS 1.0 and 1.1 on Exchange Server 2013. It is unlikely, but if TLS 1.3 (or later) support is added on the operating systems supported by Exchange Server 2013, customers will need to determine how to proceed with publishing endpoints which meet their requirements.

.NET considerations and other applications on an Exchange Server

The steps outlined in this series address the Exchange product code running on an Exchange server. The guidance provided represents the actions and steps to allow Exchange to successfully negotiate TLS 1.2. Other articles specific to .NET may reference additional actions, e.g. the use of SchUseStrongCrypto. Exchange only requires the use of SystemDefaultTlsVersions introduced in Part 2 of this series. We have worked with the .NET team to ensure that use of other .NET settings does not conflict with how Exchange has been developed and our approach to dynamically inherit the operating system capabilities. It is entirely possible that other applications developed on the .NET Framework which are deployed on an Exchange Server may require additional configuration. Customers should work with the ISV’s for any applications installed on an Exchange server to understand an application’s specific requirements.

Summary

This concludes our series on how to enable TLS 1.2 on Exchange Server and disable older TLS versions. With proper planning and execution, customers should be able to successfully transition to TLS 1.2. We encourage you to complete this across all of your Exchange servers as soon as reasonably possible.

We introduced the topic of ciphers as a part of the discussion on TLS encryption when we started this series. It is our intention in the near future to provide additional guidance to customers on the cipher and hashing algorithms that we recommend be used to best secure Exchange Server communications. For now, enjoy the improvements that TLS 1.2 can provide and check this off your list of things to do with your Exchange servers.

A huge debt of gratitude goes to Scott Landry, Brent Alinger, Chris Schrimsher, Arindam Thokder and others for combining numerous efforts of work into this series of postings.

The Exchange Team

As someone who reads through hundreds of support cases each month, nothing pains me more than seeing customers struggling with seemingly complex issues, only to discover that the root cause is quite simple. Never is this truer than it is with DNS. Some of the most complicated security and lost mail issues boil down to a few simple records. In fact, we get well over a thousand tickets per month that could be easily avoided by addressing DNS issues. This blog post could save you time, frustration, even money! Please note that I’m focusing on Office 365 email DNS records here, especially those involved in routing & security decisions – but this advice may be applicable more broadly.

Best Practices List

Don’t use legacy DNS records anymore

For several years, we have been doing campaigns to let you know that we’re not going to forever support the use of records like mail.outlook.com, mail.messaging.microsoft.com, mail.global.frontbridge.com, mail.global.bigfish.com, etc. in your MX (mail exchanger) record. However, as of the time of this publishing, we still see over 2000 customer domains that still point to one of these. And that’s just the ones we can easily check in public DNS. There are easily an equal number of on-premises or cloud applications/firewalls/devices which still also appear to be using these records.

Why? Not updating and removing these records means that you’re not getting all the benefits available to you (some of our EOP features simply don’t work). This also increases your risk considerably, as we don’t constantly monitor to make sure all of these records still work like we do with the newer, supported records.

Remove all stale DNS records

It is critical that once you commit to using Office 365, you don’t keep one record pointing to your older routing path. Two variants of this pop up all the time:

• You move your mail to Office 365, but leave the old MX record (priority irrelevant). This is a terrible idea, because it means that any network glitch anywhere, even on the sending side, can send your mail into a black hole, never to return. Your old provider probably still accepts email for your domain (might not be a bad idea to tell them to stop). Why? This causes mail to go missing. If the other host chooses to reject the mail, senders will get bounce messages (NDRs) from time to time. What’s annoying is that these issues can be very intermittent, or so rare that you may barely notice them and if you do – it can be very difficult to track down.
• You move your entire domain to a new DNS provider, but forget to remove the zone at the old provider. I see this one with even the most experienced administrators. Why? In short, intermittent missing mails. Most Internet traffic will get the proper, new records because they’ll be using the SOA (start of authority) and NS (name server) records to determine where to resolve the records for your domain. But any customer who is using your old provider for their DNS will still get the old, orphaned information. This is called a DNS split, as multiple servers think they are the authority. More experienced providers will eventually expire the zone files, but some smaller providers might not have a procedure for deleting zones when customers stop paying the bills. And issues with a smaller provider might take weeks, or years to notice. Note that while domain registrars (the ones who list your domain with root servers) usually provide DNS zone hosting, the registrar may not be where the DNS zone (and actual DNS records) is hosted.

Don’t use multiple MX records, especially if they don’t point to the same provider

Aren’t multiple MX records more reliable? In some cases, yes; but most certainly not in this case. Office 365 assigns you a single record per domain, and if that domain is registered with us, we will accept mail for you. It is covered by our money-backed guarantee. We constantly monitor, and we have engineered multiple layers of redundancy already: at the A (host) record level, at the IP level, and more. At the IP level alone, there are thousands of severs sitting behind just a single virtual IP.

Why? More MX records – whether pointing to a 3^rd party scanning service, on-premises, or even a “continuity” provider means more complexity and possible message delays because your mail is taking an extra hop, which is not covered in any of our guarantees. It also means that when mail fails over to another route, unexpected things can happen with junk filtering and spoof detection. For example, a good bit of our EOP filtering stack does not trigger when we detect this configuration. This leaves you open to phishing attacks and more. It also makes it a pain to troubleshoot, because you’ll occasionally be troubleshooting messages that didn’t even pass through in the order you’d expect. SPF most likely will fail for those messages which take an extra hop, and that could trigger false positives. This is so important that I’ll say it one more time – EOP is NOT as effective if you have multiple MX records or mail doesn’t route to EOP first. It’s the first thing I ask support engineers to check when troubleshooting missed junk or false positives. I see countless issues where people are complaining about the effectiveness of EOP, only to discover that all MX records did not point to EOP.

Now, if you have opted not to use EOP and rely on a third party or on-premises filtering infrastructure instead, that is fine, but only use the records appropriate for that single configuration. Don’t mix and match a few of theirs with a few of ours, at least for a single domain.

As for other DNS records, it ultimately depends on how the client behaves – but if you’re not sure, don’t assume that more DNS records are always better.

Use only the MX records provided to your specific tenant

Sometimes, you’ll setup a domain inside of a test Office 365 tenant, and then move it to a production tenant. Sometimes, a company merges or divests, and you must move a domain to a new tenant. You absolutely must update DNS records when doing so. You cannot assume that we’ll let you keep using the old DNS records indefinitely, just because they work for a little while. I saw a case recently where a reseller was using a single DNS record for every tenant they were responsible for. Not only does this increase risk, but it is not supported, and mail will eventually break.

While it is technically true that you could use a single assigned A (host) record for every domain in your tenant, this is not advised, because it also increases risks. What if that domain expires or moves to another tenant, while the others stay where they are?

Don’t let your domain expire

It is sage advice to know when your DNS records are set to expire. Set yourself a reminder a few months in advance, just as you might do with certificates or anything else. Set yourself another reminder for a few days before. Even if you have it set to auto-renew, payment issues happen all the time. Don’t rely exclusively on email notifications.

Check your records occasionally

I know there’s a (mostly true) saying that goes something like, “if it isn’t broken, don’t fix it.” But that doesn’t mean you shouldn’t know what your DNS records are and know that they are setup correctly. Just because something appears to work fine, doesn’t mean that it is setup correctly. I would strongly advise doing a complete and exhaustive check of DNS at least once per year. There are tools all over the Internet to help you. Yes, when you identify that a change needs to happen, proceed with caution. But put together a plan now to get it fixed during the next possible window.

Where do I go to check all of this?

If you login with an Office 365 Admin account, the Domains page under Setup has everything you need for each domain you’ve registered with us. If you’ve purchased the domain through Microsoft and let us manage it for you, there should be nothing more required. If the domain is one that you manage yourself, the experience looks something like this (if GoDaddy is your registrar and DNS provider, we’ll actually walk you through the setup):

From this page, you can click into each domain to see what the value should be, for example:

Then, you can use nslookup to validate what the world sees. As an example:

C:\>nslookup
> server 4.2.2.2
Default Server:  b.resolvers.Level3.net
Address:  4.2.2.2
> set q=mx
> contoso.com
Server:  b.resolvers.Level3.net
Address:  4.2.2.2
contoso.com     MX preference = 10, mail exchanger = mail.global.frontbridge.com
> set q=txt
> contoso.com
Server:  b.resolvers.Level3.net
Address:  4.2.2.2
contoso.com     text =
"MS=ms47806392"

As you can see from this example, contoso.com does NOT have the proper MX record, and they have no SPF record. Alternately, you can use any number of 3^rd party DNS checking tools available on the web.

While you’re at it, check all your Office 365 DNS records as well. And odds are, if you’re still using those old records, you might not have setup DKIM and DMARC. Take this opportunity and stop procrastinating – your brand, your users’ safety, even the financial future of your company could depend on it. For more information, see the Office 365 Domains FAQ.

I hope you find these best practices helpful, and if you’re stuck, our support is able to assist you with any of this.

Scott Landry