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.

Microsoft Product Lifecycle Policy (http://aka.ms/lifecycle)

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

The introduction of email authentication mechanisms like SPF, DKIM, and DMARC have improved email security and spoofing prevention. However, some scenarios have been disrupted by these authentication mechanisms, namely auto-forwarding and relaying. Here in Office 365, we are committed to ensuring the security of our customers and the general integrity of the email ecosystem that we are a part of.

From July 16th, we will begin rolling out Sender Rewriting Scheme (SRS) functionality to solve the problem of auto-forwarding being incompatible with SPF. The SRS feature will rewrite the P1 From address (also known as the Envelope From address) for all applicable messages being sent externally from Office 365. The From header (also known as Display From address or P2 From address) which is displayed by email clients will remain unchanged. This change will improve deliverability of applicable messages since SPF checks that were failing in the past for such messages will now pass.

Regarding ‘applicable’ messages, we anticipate the following scenarios will be affected and result in SRS rewriting the P1 From address:

1. Messages that are auto-forwarded (or redirected) from hosted mailboxes using one of the supported methods – SMTP forwarding, Mailbox Rule (or Inbox rule) redirection, Transport Rule redirection.
2. Messages that are auto-forwarded (or redirected) from our customer’s on-premise environments and relayed through Office 365.

Note: SRS rewriting would also rewrite the P1 From address of messages that are relayed from our customer’s on-premise environment, where the P1 From domain is NOT a verified domain. Customers should only be sending messages from domains in their Accepted Domains list. Find out more about Accepted Domains in Office 365 here.

This change results in Non-Delivery Reports (NDRs) returning to Office 365 instead of the original sender as it occurs today without SRS. Part of the SRS implementation, therefore, is to reroute returning NDRs to the original sender in the case where a message could not be delivered.

Details

Auto-forwarding emails for an Office 365 hosted mailbox

A message auto-forwarded for a hosted mailbox by mechanisms such as SMTP forwarding or Mailbox Rule redirection or Transport Rule redirection will have the P1 From rewritten before it leaves Office 365 using the following pattern:

<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>

Example:

A message is sent from Bob (bob@fabrikam.com) to John's mailbox in Office 365 (john.work@contoso.com). John has set up auto-forwarding to his home email address (john.home@example.com).

Relaying from a customer's on-premises server

A message relayed from a customer's on-premises server or application through Office 365 from a non-verified domain will have the P1 From address rewritten before leaving Office 365 using the following pattern:

bounces+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Customer's Default Accepted Domain>

Important: In order to receive NDRs for relayed messages that are rewritten by SRS, a mailbox (either hosted or on-premises) needs to be created with the username 'bounces' and the domain being the default Accepted Domain of the customer.

Example:

A message is sent from Bob (bob@fabrikam.com) to John's mailbox (john.onprem@contoso.com) on his company's own Exchange server. John has set up auto-forwarding to his home email address (john.home@example.com).

Find out more about the draft SRS standard that this change is took design ideas from here: http://www.openspf.org/SRS

Sean Stevenson

We are very happy to announce a new feature that will help you the admin reduce the amount of time needed to configure config objects once hybrid setup is complete.

What does this feature do?

This feature enables a one-time transfer of key organization policy objects during the onboarding process from Exchange on-premises to Exchange Online. This feature is tightly integrated into the existing Hybrid Configuration Wizard. The administrator running the HCW can choose to migrate either all the detected objects while onboarding from Exchange on-premises to Exchange Online or choose not to transfer any. This is only a one-time transfer though, to avoid the need to have you set them up manually. Once the one-time transfer is complete, you will need to manually update values in either On-prem or Online to keep them in sync if you change anything.

We’re supporting this config transfer whether you are migrating from Exchange Server 2010, Exchange Server 2013 or Exchange Server 2016, and we’re delivering this feature in phases. Phase 1 will be launched at the end of June 2018. Which is… kind of… pretty much now, really.

What kind of Policy objects are in scope?

The objects we’re including in phase 1 are:

• Retention Policy
• Retention Policy Tags
• OWA Mailbox Policy
• Mobile Device Mailbox Policy
• Active Sync Mailbox Policy

However, in phase 1 only new objects/policies will be copied over from on-premises to cloud. Any existing objects/policies in Exchange Online will not be modified.

How do I use this cool new feature?

This feature is completely integrated into the existing Hybrid Configuration Wizard. Just downloading the latest HCW is all you need to do. As you can see from the screenshot, we’ve added a checkbox at the bottom of the Hybrid Features page to allow you to enable this feature and to copy over objects from your Exchange on-premises organization to Exchange Online.

What’s next?

In phase 2, in addition to copying several new objects (Organization Config, DLP Policy, Active Sync Device Access Rule and Active Sync Organization Settings) from on-premises to cloud, the admin will be given a choice to update existing objects in the cloud if the attribute values are different from those on-premises.

We hope you enjoy this new feature and look forward to hearing any feedback or comments, either here on the blog or directly in HCW – we’ve built an awesome feedback system into the HCW and we love to hear what our customers have to say.

Kavya Chandra
Program Manager, Office 365 Enterprise Cloud

The latest cumulative updates for Exchange Server 2016 and Exchange Server 2013 are now available on the download center. An update rollup for Exchange Server 2010 is also available. The updates released today include important changes to the pre-requisites required to install Exchange Server. The installation packages include fixes to customer reported issues, all previously reported security/quality issues and updated functionality.

Updated Pre-requisite requirements

.NET Framework 4.7.1

As announced previously, Exchange Server 2016 Cumulative Update 10 and Exchange Server 2013 Cumulative Update 21 require .NET Framework 4.7.1. Exchange Setup will enforce this requirement during cumulative update installation. Customers who are running an older version of .NET Framework will need to update their server to .NET Framework 4.7.1 then install the latest cumulative update.

VC++ 2013 runtime library is required

The Exchange Server updates released today require the VC++ 2013 runtime library installed on the server. The VC++ runtime library is required to provide current and future security updates for a third party component shipped with Exchange Server. The component provides WebReady Document Viewing in Exchange Server 2010 and 2013 and Data Loss Prevention in Exchange Server 2013 and 2016. Setup will enforce the installation of the pre-requisite on Exchange Server 2013 and 2016 when a cumulative update is applied. Exchange Server 2010 Update Rollup 22 and later will force the installation of the VC++ runtime before the update can be applied. Future security updates for all versions of Exchange Server will force installation of the runtime package if not already installed. Customers who use Windows Update to patch or update their servers, will need to ensure that the VC++ 2013 runtime package is applied before running Windows Update. Update Rollup 22 and future security updates for all versions of Exchange server will fail to install manually or via Windows Update if the runtime library is not installed.

The packages released today include an updated version of the third party component to resolve the issues identified in Microsoft Advisory ADV180010. Customers are encouraged to apply the updates released today as soon as possible. The Exchange team has previously stated they will not ship security fixes in a cumulative update not previously released separate from a cumulative update. That goal and official plan of record are unchanged. Shipping the updated third party components in a cumulative update was necessary to integrate a new version of the components and a new product dependency not previously required by Exchange in a manner customers are accustomed to with minimal disruption to the Windows Update process.

Important Updates for Exchange Server 2010

Support for Windows Server 2016 Domain Controllers

Exchange Server 2010 Service Pack 3 Update Rollup 22 and later add support for Windows Server 2016 domain controllers. There are no restrictions to adding Windows Server 2016 domain controllers in forests where Exchange Server 2010 is deployed. Support for Active Directory Forest Functional Levels through Windows Server 2016 is included. Domain Controllers must be running Windows Server 2016 updates released through June 2018 to be supported. Customers are encouraged to remain current by applying monthly operating system quality updates.

Fix for Exchange Web Services Impersonation in Co-existent Environments

The issue identified in KB4295751 is now resolved in Update Rollup 22. Customers who have Exchange Server 2010 deployed in the same forest as Exchange Server 2016 are encouraged to deploy Update Rollup 22 to ensure that unauthorized access to mailboxes on Exchange Server 2010 does not occur.

Latest time zone updates

All of the packages released today include support for time zone updates published by Microsoft through May 2018.

Exchange Server 2013 Extended Support

Exchange Server 2013 entered extended support in April 2018. Cumulative Update 21 is the last planned quarterly update for Exchange Server 2013. Customers must upgrade to Cumulative Update 21 to continue to receive future security updates.

Release Details

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

• Exchange Server 2016 Cumulative Update 10 (KB4099852), Download, UM Lang Packs
• Exchange Server 2013 Cumulative Update 21 (KB4099855), Download, UM Lang Packs
• Exchange Server 2010 Update Rollup 22 (KB4295699), Download

The updates released today do not include new updates to Active Directory Schema. If upgrading from an older Exchange version or installing a new server, Active Directory 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 before applying either of the cumulative updates released today.

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 CU20, 2016 CU9) or the prior (e.g., 2013 CU19, 2016 CU8) 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

Long time Exchange administrators will remember that Exchange Server had a feature that was for a while unceremoniously referred to as the “dumpster”. We have since renamed the feature to a more descriptive Recoverable Items Folder. This blog post also contains a bit of history of this feature for those interested.

Up to now, during public folder migration, all the public folder data including dumpsters was migrated from on-premises servers to the cloud. Administrators did not have an option to exclude this data at migration.

We are introducing the ability to migrate public folders to cloud without migrating the dumpster data. To do this, administrators need to pass the ExcludeDumpsters parameter while creating the migration batch. This option can be used when source server version is Exchange 2013 or 2016. Here is an example of how to use this parameter:

New-MigrationBatch -Name PublicFolderMigration -CSVData $bytes -SourceEndpoint $PfEndpoint.Identity -ExcludeDumpsters

Why would you want to do this?

Excluding this data can help you scale your public folder migration if you do not need the data to come over. This will result in faster public folder migration as the amount of data that will need to be migrated is going to be smaller.

To check the dumpster folders size, you can run the following:

Get-PublicFolder \NON_IPM_SUBTREE\DUMPSTER_ROOT -Recurse -ResultSize:unlimited | ?{$_.FolderClass -ne "$null"} | ft name,foldersize

In addition to size consideration, we have seen some organizations where dumpster data got corrupted (for various reasons) and administrators did not want that corrupted data migrated to cloud. If you find yourself in that situation, this feature will enable you to leave that data behind.

The obvious drawback to doing this is that users will lose the ability to recover items that were previous deleted from public folders (pre-migration).

Note: The ExcludeDumpsters parameter is optional and if not passed to migration batch, all dumpsters will migrate to cloud. Once you choose to exclude dumpsters and the migration is finalized, there is no way to go back and re-include the dumpsters into cloud public folders. If, during the migration in which you used the ExcludeDumpsters parameter, you decide that you do want to migrate the dumpsters data to the cloud, remove the current migration batch and create another without the ExcludeDumpsters parameter.

This option can be added at point 4 of Step 7 in below TechNet articles for public folder migration (we will work to change the documentation next):

• Use batch migration to migrate Exchange 2013 public folders to Exchange Online
• Use batch migration to migrate Exchange 2016 public folders to Exchange Online

Keep checking this blog for further updates on the subject!

In case of any questions, please do reach out to us via the comments section below.

Public folder team

We are correcting how shared (and resource) mailboxes are created in Exchange Online.

As per our documentation (here and here), shared and resource mailboxes in Exchange Online should be created with the size of 50GB and if a larger size is desired, a license should be assigned to the mailbox. For some time now, though, while our documentation has (correctly) stated this, the Exchange Online system would, for many of our customers, create both new shared and resource mailboxes with a default size of 100GB even if a license was not assigned. We knew that this was happening, and we were working to address this in our mailbox provisioning system.

This is what is now being corrected to the documented behavior.

The new shared or resource mailbox creation behavior (starting end of July) will by default be 50GB, as per our documentation – and if you require a shared mailbox that is larger than 50GB, an Exchange Online Plan 2 license will need to be assigned to it. Once a license is assigned, the mailbox size should quickly increase to 100GB (equivalent size for an Exchange Online Plan 2 licensed user mailbox).

To help you with understanding how this change might impact your existing shared mailboxes and what the behavior is going forward, we have prepared the following Q&A:

When the 50GB shared mailbox creation correction goes into effect, will all the already created unlicensed shared mailboxes with a default size of 100GB be automatically switched to 50GB?

No, not automatically; but they could revert to 50GB under certain situations, read on to understand these scenarios.

When would a currently unlicensed shared mailbox lose its existing 100GB status?

Changing the state of the license on the mailbox will apply the corrected 50GB default state. If license on the mailbox is changed, the 100GB status for that mailbox will be irreversibly lost and to increase the mailbox size back to 100GB, an appropriate license will be required.

I currently have an unlicensed 100GB shared mailbox with 80GB of data and I need archiving for it. What will happen if I assign the Exchange Online Archiving license?

Any change to the licensing state of the shared mailbox will make the shared mailbox lose its 100GB status. In other words – even assigning the Archiving license only to a currently unlicensed shared mailbox will change the mailbox quota to 50GB and an Exchange Online Plan 2 license (or equivalent) will be needed to increase the mailbox size to 100GB. In this scenario, if you wanted to assign an Archiving license, you would also need to assign at least an Exchange Plan 2 license.

When this change goes into effect, let’s say I have an 80GB user mailbox and want to convert it to a shared mailbox. What will happen?

When mailbox conversion happens, the currently assigned license will stay assigned on the mailbox (by default) and shared mailbox will keep sending/receiving email. If you then remove the license from this converted shared mailbox, the 50GB mailbox quota will get enforced. The mailbox size will still be 80GB, but because the mailbox will be over quota, sending and receiving of email will not work (incoming email will error with “Mailbox is full” error, code 5.2.2). Assigning the required license to the mailbox again will resolve this problem (this change might take a little bit of time). If you intend to use a shared mailbox larger than 50GB actively, we recommend that you keep the license assigned after conversion so there are no work disruptions. You are also able to leverage Inactive Mailboxes if you just need to keep mailbox data around in inactive state.

If I have a user mailbox that is under 50GB in size and convert it to a shared mailbox – what will happen?

When mailbox conversion happens, the license will stay assigned on the mailbox (by default). If you remove the license, the mailbox will still be available for sending and receiving email because the size of the converted shared mailbox is under 50GB and shared mailboxes under 50GB do not require a license. If the size of this shared mailbox goes over 50GB, you will need to add a license to it (to increase its size to 100GB) or remove some email from it (to stay under the 50GB).

If I have a shared mailbox that is approaching 50GB and need it to be larger, what should I do?

Simply assign it an Exchange Online Plan 2 license; you do not need to do anything else. Shared mailbox size will be increased to 100GB automatically within 15 minutes.

Licensing change already went into effect. I just converted a 50GB unlicensed shared mailbox into a user mailbox and now I have a 50GB user mailbox. What’s going on?

When you convert an unlicensed mailbox from shared to user (using Exchange Admin Center, for example), the resultant mailbox will be an unlicensed user mailbox (because the starting shared mailbox did not have a license). This mailbox is not ‘attached’ to an account as there is no license assigned. When the license is assigned to the user, the mailbox will be re-attached to the account and its size will be set according to the license that was assigned to it. So, if you assign a license that gives the user a 100GB mailbox, the mailbox size will be increased to 100GB. Reminder: without a license, such an ‘unattached’ mailbox will be deleted after 30 days (as it does today).

I have an 80GB shared mailbox on-premises and I need to migrate it to Exchange Online. What should I do?

Because the target Exchange Online shared mailbox needs to be larger than the default (unlicensed) 50GB size, the shared mailbox cloud MailUser object needs to be licensed before migration is attempted. Otherwise, the migration attempt will immediately fail with the “Mailbox size exceeds target quota” error. Once the Exchange Online Plan 2 license is assigned, migration can be started.

Nino Bilic

Last month, we announced the release of mail flow insights in the Office 365 Security & Compliance Center in this blog post. We're making changes to the mail flow insights dashboard to make it more intuitive. These changes are currently in deployment, and will be available in the week of June 25, 2018.

We've changed some widgets in the mail flow dashboard, as shown in the following screenshot:

We've combined the TLS report for inbound and outbound email traffic and the connector report into one widget. Clicking View details will give you all the TLS status for your organization, and the connector report link will lead you to the detailed connector report. We will retire the TLS report in the near future since it's no longer needed.

We've changed the "Forwarding overview report" widget to "Auto-forward messages" to give you a quick summary of the auto-forwarding status for your organization:

Click the message number in the "Auto-forwarded messages" widget and the flyout will show the auto-forwarded message status. You can see the details by clicking "Forwarding Report" link, as shown below:

We encourage you to take advantage of mail flow insights in the Office 365 Security & Compliance Center. We will continue to improve the current insights as well as add new insights, and we're looking forward for your valuable feedback.

Carolyn Liu

We often get questions about throttling in Mailbox Replication Service (MRS) based migrations in Exchange online. When migrating, you may see messages such as StalledDueTo_TargetDiskLatency for some periods of time. These messages come from our resource-based throttling infrastructure in Exchange Online.

This is how this would look like in the output of Get-MoveRequestStatistics:

PS C:\> Get-MoveRequestStatistics <user> | fl Status,StatusDetail
Status : InProgress
StatusDetail : StalledDueTo_TargetDiskLatency

Or in a move report, you may see:

The job has been paused temporarily due to unfavorable server health, with request throttling state: 'StalledDueToTarget_DiskLatency'.

We throttle and prioritize work in the Exchange Online service based on priority and resource load. The highest priority is the end-user experience, so some workloads like OWA access, Outlook access, and email delivery are the highest priority. Other things, like select mailbox assistants and customer migrations, are in the second tier but with lower priority than client access and mail flow. There are also some even lower-priority workloads such as load-balancing mailbox moves, maintenance, and other discretionary tasks. We throttle lower priority workloads at the point where they could degrade the end-user experience or the performance of higher priority workloads. For instance, we throttle migrations when they might negatively impact OWA access or email delivery.

Take this example: As a customer, you migrate your data to Exchange online. Imagine one day you receive a notification stating: “Your email delivery will be delayed by 1-2 hours today to allow another customer to migrate to Exchange Online more quickly.” You would not accept this scenario and we don’t either. We absolutely understand migration is important, but it is not the highest priority workload in Exchange Online.

In summary, there are some things you should understand to make your migration experience go smoothly.

1. The throttling you see is not per-user or per-tenant. We throttle only based on resource load in MRS-based migrations. So, when you see a message indicating a stall, it is simply happening to preserve the overall health of the Exchange Online service. We do not have any ability to lift MRS migration throttling for a particular tenant or user. Additionally, you may get better migration throughput during off-peak hours since the resources consumed during these times will probably be lower.
2. Seeing a “StalledDueTo” or throttling message does not mean that Office 365 has a problem. You should expect some amount of throttling in any migration you perform. This throttling may occur at unpredictable or inconvenient times; you should plan your migrations accordingly. There is no action you need to take; the migration will resume automatically when resources become available.
3. Do not set very short timelines for migrations of individual user mailboxes, because you are unable to predict migration resource availability in Office 365. Instead make sure you complete the initial sync well ahead of time and complete the migrations at a later time.

Note: Some migration stalls can originate from the on-premises environment. It’s important to take note of the directionality of the stall. If the message says “Source” and you are moving mailboxes to Exchange Online, it means the stall is from the on-premises environment. Likewise, if the message says “Target” and you are moving mailboxes from Exchange Online (back to on-premises), the stall is also originating from the on-premises environment.

Brad Hughes

Over the last few years, we have been investing in services that help developers access information in Office 365 in a simple and intuitive way, specifically through Microsoft Graph.  Microsoft Graph and the use of OAuth 2.0 provide increased security and seamless integration with other Microsoft cloud services and is rapidly expanding developer access to the rich data sets behind Microsoft applications.  

As we make progress on this journey, we have continued to evaluate the role of Exchange Web Services (EWS). Today we are sharing our plans to move away from Basic Authentication access for EWS over the next two years, with support ending Oct. 13, 2020.   

These plans apply only to the cloud-based Office 365/Exchange Online products; there are no changes to EWS capabilities of on-premises Exchange products. 

Exchange Web Services will not receive feature updates 

Starting today, Exchange Web Services (EWS) will no longer receive feature updates. While the service will continue to receive security updates and certain non-security updates, product design and features will remain unchanged. This change also applies to the EWS SDKs for Java and .NET as well. 

While we are no longer actively investing in it, EWS will still be available and supported for use in production environments.  However, we strongly suggest migrating to Microsoft Graph to access Exchange Online data and gain access to the latest features and functionality. For more information and details on how to make the transition, please refer to the following articles: 

• Overview of Microsoft Graph 
• Overview of Outlook mail API on Microsoft Graph 

While EWS and Graph have mostly overlapping functionality, there are some differences. If you rely on an EWS API that does not have a Graph counterpart, please let us know via UserVoice of features needed for your app scenarios.   

Basic Authentication for EWS will be decommissioned 

Exchange Web Services (EWS) was launched with support for Basic Authentication. Over time, we've introduced OAuth 2.0 for authentication and authorization, which is a more secure and reliable way than Basic Authentication to access data. Please refer to the following article for more information: 

Getting started with OAuth2 for Microsoft Graph 

Today, we are announcing that on October 13th, 2020 we will stop supporting and fully decommission the Basic Authentication for EWS to access Exchange Online. This means that new or existing apps will not be able to use Basic Authentication when connecting to Exchange using EWS.  

Next Steps 

The deprecation of these APIs follows our service deprecation policies. We understand changes like this may cause some inconvenience, but we are confident it will ensure more secure, reliable, and performant experiences for our customers. 

We're here to help if you need it. If you have questions, please let us know in Stack Overflow with the [MicrosoftGraph] tag. 

Thank you in advance for updating and opening your apps to a wider range of useful and intelligent features on Microsoft Graph. We are extremely excited about the growing opportunities that Microsoft Graph offers to our customers, and we remain fully committed to continue our journey to empower developers to access Office 365 data with the most modern features and tools. 

Frequently Asked Questions  

Q: Will my application stop working when you make this change? 

A: It might, yes, it depends on the app itself and how it was coded. If it’s using EWS, and if it’s using Basic authentication then yes, on October 13th 2020 it will fail to connect. However, if the app is using Modern Auth/OAuth, then no, it will keep working as it did before.  

Q: Why October 13th 2020? Why that date? 

A: Starting October 13, 2020, Office 365 ProPlus or Office perpetual in mainstream support will be required to connect to Office 365 services. This announcement is posted here Office 365 ProPlus Updates.  

This change requires that Office 2013/Office 2016 are also required to use Modern Auth. Please see this.

Q: Our in-house team created an app for meeting room scheduling, how do we go about changing that over to Graph and OAuth2.0?  

A: Don’t forget you can keep using EWS if you want to, so then really, it’s just the question of authentication. To get a better understanding of how to use OAuth 2.0 take a look here.

Q: How does this impact my On-Premises Exchange deployment? 

A: It does not. This change only affects Exchange Online.  

Q: We require Modern Authentication + Multi Factor Auth for all our Outlook users connecting to O365, how do apps work when I have that set as a requirement? 

A: Applications can be written so they are treated as ‘trusted applications’. That way they can bypass the MFA requirement, more details are here.

Q: How do I know which of my apps use Basic authentication to EWS? 

A: If you only Outlook to connect to Exchange Online then you don’t need to worry, as long as you are using Office 2019 or Office 2019 Pro Plus you’ll be fine come October 2020. However, if you also have integrated apps into your Office 365 tenant you’ll need to check with the application developers to verify how it authenticates to Exchange Online if you aren’t’ sure. We are investigating how we can share this information with tenant admins, but have nothing available at the time of writing this blog.  

Q: What features does EWS have that Graph can’t provide? 

A: Graph is constantly evolving and adding features and functionality to provide the richest set of experiences we can. To see the latest features we’ve added to Graph, go here Overview of Outlook mail API on Microsoft Graph 

Q: Will this affect my Exchange Hybrid configuration? Exchange On-Premises calls into Exchange Online using EWS doesn’t it? 

A: Yes, it does. But it doesn’t use Basic Authentication, it uses token-based authentication, and it’s described in this blog post. How Hybrid Authentication Really Works.  

The Exchange Team

The Exchange team is aware of issues with the Windows Operating System updates published July 10th, 2018 causing Exchange to not function correctly. The Windows servicing team has advised us that they will be releasing updates to the affected packages. We encourage Exchange customers to delay applying the July 10th updates, including the security updates released on the same date, on to an Exchange server until the updated packages are available.

Update: July 17th

We wanted to provide you an update on this issue.

The issue has been resolved and new updates will be available through Windows Update for all operating systems by end of day July 17th (PDT). The Exchange Team recommends that customers use Windows Update or update the catalogs on their own SUS servers to ensure the latest version of the update is available for installation on your Exchange Servers. Doing so will avoid any possible disruption to the MSExchangeTransport service which may have been impacted by the July 10th update.

Note: There will be a unique KB number associated for each Windows operating system. Applying the latest updates from Windows Update will ensure you have the correct update for your operating system regardless of updates previously applied.

The Exchange Team

A few years ago, we created a web site that would allow our hybrid customers to obtain what’s generally known as the “hybrid key”. This self-service site would validate your O365 tenant and after a few clicks, give you the key to license your on-premises server used for hybrid purposes. This site is no longer available for use, and we’ve come up with a better way for you to get the key.

We are excited to inform you we are now working on a feature that will allow the Hybrid Configuration Wizard (HCW) to detect and license your designated on-premises “hybrid server”, without having to go to a separate web site or call our support team. We expect this change to be live in HCW by August 7^th.

What will the new experience be?

When you choose the “Detect the optimal Exchange server” option, HCW will perform the license check on the server and give you a new “license this server now” option, if the server is currently not licensed. Note: HCW will not let you continue from this point on if this server is not licensed, unless you specify an alternate Exchange server to run Hybrid against (second radio button below):

Selecting the “license this server now” link will prompt you for your online administrator credentials. We realize this is an extra credential prompt at this time, but it is needed to validate and obtain the key (the old key distribution site also required authentication).

HCW will then indicate the progress of applying the server license to your on-premises server:

Next up, you will get a confirmation that the server has been licensed. You will also have an option to copy the product key (and the CMDlet needed to use it) if you wish to do so:

At this time, unless you want to complete the setup of Hybrid in the HCW, you can exit / cancel the wizard. Full completion of the HCW workflow is not needed for this process to be executed; your on-premises server will remain licensed, and you can re-run HCW at a later date / time.

Let us know what you think!

The Exchange Hybrid Team

We’re pleased to announce a preview build of Exchange Server 2019 is now available. You can download it here.

We strongly believe Office 365 delivers the best and most cost-effective experience to our customers, but we understand that some customers have reasons to remain on-premises. Exchange Server 2019 is designed to deliver security, performance, and improved administration and management capabilities. These are the attributes our largest on-premises customers tell us they need from Exchange. We also have features end-users will love too of course.

Here are some of the key features in each of these areas:

Security: We’ve included support for installing Exchange Server 2019 onto Windows Server Core. Exchange Server 2019 installed on Windows Server 2019 Core provides the most secure platform for Exchange. You also have the option of installing the Exchange 2019 Preview onto Windows Server 2016 Core or Windows Server 2016/2019 with Desktop Experience, but we have worked hard to make sure running Exchange on Windows Server Core 2019 is the best choice for our code.

Performance: We’ve done work to allow Exchange Server to take advantage of the larger core and memory packed systems our customers buy these days. We’re confident you can be very successful running Exchange Server with up to 48 processor cores and 256GB of RAM.

We’ve re-engineered search using Bing technology to make it even faster and provide better results, and in doing so have made database failovers much faster, and administration easier.  The search indexes are now within the database itself. There are no more separate log files to manage. As the index data is now within the database, normal log shipping includes the database and search data in a single replication and the index is always up to date on all database copies.

At Ignite last year, we told you that Exchange Online had started using Solid State Drives. Yes, SSD’s. Many people were shocked at this.  For years we’ve been telling you to use cheap low-cost storage, and then we switched and started using SSD? What’s up with that Exchange team?

Well, that isn’t exactly what we said, what we said was we were using SSD’s in addition to cheap low-cost spinning disks. Why? Well we’ve pretty much reached the limits of what we can do with cheap storage, read latency in those disks hasn’t really improved yet storage capacity just keeps getting larger. It led us to conclude we needed to re-think our strategy. And we did, and the short version is that we store some of the data from those spinning disks on the SSD, and we use that super-fast device to store key search data, to make logins faster, and message retrieval faster. We still use low-cost storage for storing all of data but intelligently use SSD’s to make the overall user experience better.

We’re adding this tiered storage read/write capability to Exchange Server 2019 but it’s not enabled in the Preview build. We know you will all have lots of questions about this new feature and we will of course have planning and configuration guidance available when we ship, but we will be talking a lot more about these changes at Microsoft Ignite 2018. You are going, aren’t you? We are.

End user experience: One of the most important capabilities in Exchange is calendaring. All large enterprises are heavy calendar users and those organizations rely on calendars to help people get their work done. We’re bringing a few key features such as Do Not Forward and Simplified Calendar Sharing from Office 365 to On-Premises Exchange. We’re sure a lot of end users will be very happy with those features. Administrators get some new calendaring features too, as we’re adding the ability for admins to manage events on user’s calendars and to assign delegate permissions more easily.

One thing to note is that Unified Messaging role will not be available in Exchange Server 2019. Customers who currently connect either a 3rd party PBX or Skype for Business Server to Exchange Server won’t be able to do so with Exchange Server 2019 mailboxes. Those customers considering an upgrade to Exchange Server 2019 should consider migrating to Skype for Business Server 2019 and using Cloud Voicemail, or migrating to Office 365 with Cloud Voicemail. More information on this change will be available prior to launch.

That’s a brief roundup of many of the changes we have baked into Exchange Server 2019.

We plan on launching Exchange Server 2019 later this year, and we’re planning on talking about it a lot more at Microsoft Ignite.

Take a look at the Preview, and we really suggest you install it on Windows Server Core, and Windows Server 2019 Core if you have access to that. We will be publishing a blog post with tips for running Exchange on Server Core in a few days.

But please remember it’s not a production release, so please don’t install into production at all.

We look forward to your feedback, and in case we didn’t say it enough times, we’ll see you at Microsoft Ignite!

The Exchange Team.