The moment you’ve all been waiting for has arrived! We are pleased to announce the Microsoft Hybrid Agent for Exchange Server is now available for preview!

We talked in some depth about the Hybrid Agent back at Ignite 2018 in Orlando, if you want a refresher on what we covered there you can see that recording here.

The Hybrid Agent was designed to remove some of the existing challenges customers face today when establishing a Hybrid Exchange environment. This includes, but is not limited to, adding external DNS entries, updating certificates, and allowing inbound network connections through the firewall.

From today, when running the Hybrid Configuration Wizard, you are presented with a new option for establishing hybrid; “Modern Hybrid”. Modern Hybrid is offered for both Minimal and Full Hybrid Configurations. This new option will only be presented if you have never run the Hybrid Configuration Wizard. If you have successfully established Hybrid in either Minimal or Full config before this release, this new option will not be available.

This feature will install an agent, built on the same technology as Azure Application Proxy, which will publish the Exchange on-premises environment to Exchange Online to support Free/busy and mailbox migrations without many of the challenges customers previously faced with external DNS, publishing of EWS and inbound connections ports having to be opened.

The secret sauce here to explain how this works is that the Hybrid Agent registers a custom URL for only your tenant in the following format:

<guid>.resource.mailboxmigration.his.msappproxy.net

This URL is then used by the Organization Relationship or the Intra Organization Connector and the Mailbox Replication Service to route requests from your tenant to on premises. This URL is only accessible from Exchange Online. Free/busy requests from cloud users to on premises and mailbox migrations to/from the cloud are the two flows currently supported through the Hybrid Agent.

Yes, this new feature offers some great new capabilities and we’re very proud of it, but the Hybrid Agent preview still has a few constraints:

• MailTips, Message Tracking and Multi-mailbox search do not traverse the Hybrid Agent. These Hybrid features would require the classic connectivity model where EWS and Autodiscover are published on-premises and externally available to Office 365.
• The public preview only supports a single Hybrid Agent install for the Exchange Organization. We are working to support multiple agent installs for redundancy, but this is not available yet. If the server running the Hybrid Agent goes offline, free/busy look ups from your tenant to on-premises and mailbox migrations to/from your tenant will no longer work. If the server hosting the agent is permanently offline, was rebuilt, or the agent was uninstalled, you can recover the original configuration by re-running the Hybrid Configuration Wizard to reinstall the Hybrid Agent directly on the new server. Do not attempt to install multiple active Hybrid Agents in your environment with this preview build, this could cause unexpected issues.
• The Hybrid Agent registers the internal FQDN of the Client Access Server (CAS) selected when running Hybrid Configuration Wizard in Azure Application Proxy. If the registered CAS is offline, free/busy look ups from your tenant to on-premises and mailbox migrations to/from your tenant will no longer work. If the selected CAS is permanently offline, a new CAS must be registered. This can be done by re-running the Hybrid Configuration Wizard.
• You can’t use the Hybrid Agent if you plan on enabling Hybrid Modern Auth, which you also need to get the most out of Outlook mobile. You need to publish AutoDiscover, EWS, MAPI and OAB the Classic way if you want to use HMA externally.
• The Hybrid Agent preview comes with some support limitations which are called out in the Terms document that you must agree to before installing the feature.

We also want to point out that SMTP does not traverse the Hybrid Agent and will still require a public certificate for mail flow between Office 365 and on-premises. SMTP traffic is out of scope for the Hybrid Agent, both now and through General Availability.

There are a few limitations with this preview build, but that’s why it’s a preview! We still think there’s a lot the agent can do today, and that’s why we’re making it available to you now!

Once you are ready to move forward with Hybrid Agent for your deployment, there are a few deployment decisions to make. Please read this next section all the way through before downloading and installing the agent.

Choosing the right location for installation of the Hybrid Agent is important. The agent install and subsequent run of configuring Hybrid via the Hybrid Configuration Wizard is supported on either a standalone machine designed as your “agent server”, or an Exchange 2010, 2013, 2016 or 2019 server with the Client Access role. The easiest way to deploy is accomplished by installing the Hybrid Agent directly on an Exchange CAS as it simplifies connectivity, but it is not required.

Here are the agent server requirements

• The machine hosting the Hybrid Agent install must be able to establish outbound HTTPS connections to the internet, and HTTPS and Remote PowerShell (RPS) connections to the CAS chosen for hybrid configuration.
• The machine hosting the Hybrid Agent should be running Windows Server 2012 R2 or 2016, with .NET Framework 4.6.2 (or later, as supported by the Exchange version you are installing on) installed.
• The machine where the Hybrid Agent is installed must have either Edge or Internet Explorer installed and must support ClickOnce.
• The machine where the Hybrid Agent is installed must be able to communicate with a Domain Controller to authenticate your on-premises Exchange Org admin credentials. This means that the machine must be domain joined.
• Installation must be done using a local machine administrator account and will require tenant global administrator credentials for registering the connector.
• TLS 1.2 must be enabled on the machine where the Hybrid Agent is installed.
  • Azure Application Proxy documentation

Now, the smart people with a good memory reading this post might spot one interesting wrinkle in this list above: we support you installing the agent on an Exchange 2010 server, but we require you use Windows Server 2012 R2 or later... Hang on, that’s not possible. That’s not supported. You didn’t spot that? Shame on you. Well, for those that did, firstly, have a gold star and a pat on the back – and secondly, we’re announcing here that we will support Exchange Server 2010 installed on Windows Server 2012 R2 with the upcoming release of Update Rollup 26 for Exchange Server 2010 SP3. We’re doing that so if you really want to add another Exchange 2010 server to your org, on Windows Server 2012 R2, you can. You’re welcome.

Port and Protocol requirements for the agent server

• Ports to be opened outbound are HTTPS (TCP) 443 and 80, as shown here.
• The agent machine must be able to connect HTTPS (TCP) 443, 80, 5985 and 5986 to the target CAS selected in the Hybrid Configuration Wizard.

Important notes

• All Client Access Servers must be able to reach outbound to Office 365 endpoints via HTTPS (TCP) 443 as free/busy request from on-premises users to Office 365 users do not traverse the Hybrid Agent. These requests still require your Exchange servers have outbound connectivity to Office 365 end points. Office 365 URLs and IP address ranges describes the required (and hybrid) ports and IPs outbound from on-premises to the service.
• The specific Client Access Server selected in the Hybrid Configuration Wizard must be able to make a Remote PowerShell connection to Office 365.
• The agent does support using an outbound proxy but doing so requires modifications to the configuration file after installation. Also, a proxy which prevents registration will result in the connector failing to install. It is recommended to install allowing the connectors to bypass the proxy until app config changes can be made.

“Wow”, you say, “I wish it was easier to confirm the required connectivity before installing…”. Well you are in luck! We have built a port and endpoint verification script helper just for you! We recommend you install this script on your designated agent machine, run it, and confirm all the port requirements have been met prior to installing. In our experience, it is likely your environment is thoroughly locked down and ensuring the required ports and endpoint are working as required will make your installation and configuration experience much better!

Verifying connectivity

1. On the server where you will be running the Hybrid Configuration Wizard (Hybrid Agent install and subsequent hybrid configuration steps), download the following sample script and save it to any directory: http://aka.ms/hybridconnectivity.
2. Open PowerShell and change directory to the location of the script.
3. Import the cmdlets: Import-Module .\HybridManagement.psm1
4. Next run Test-HybridConnectivity with the testO365Endpoints option to verify the machine you are installing on can reach out to all required endpoints for the Hybrid Agent installation and Hybrid Configuration Wizard setup.
5. Sample run below:

Uninstalling the Hybrid Agent

To uninstall the Hybrid Agent, re-run Hybrid Configuration Wizard from the same machine you performed the installation against and select Classic Connectivity. This will uninstall and de-register the Hybrid Agent from the machine and Azure, and you can resume setup and configure hybrid in the Classic mode.

More information

Additional details on the installation requirements and steps can be found here.

Now you are ready to run the Hybrid Configuration Wizard and install the new Hybrid Agent! Happy Hybriding and we look forward to reading your feedback, please do leave us comments below.

The Hybrid Team

Microsoft is retiring Unified Messaging (UM) in Exchange Online and replacing it with Cloud Voicemail and Auto Attendant services.  This impacts voicemail processing and Auto Attendant in Exchange Online for all customers using these workloads. The following servers connecting to Exchange UM Online will be transitioned by Microsoft to Cloud Voicemail on or before February 2020:

• Lync Server 2013
• Skype for Business Server 2015

Please note this announcement refers to Unified Messaging which is the processing of voicemails and Auto Attendant in Exchange Online. Storage of voicemails will continue to be supported in Exchange Online and Exchange on-premises Servers.

Customers using the above-mentioned servers to connect to Exchange UM Online will be transitioned to Cloud Voicemail by Microsoft. The transition timing will vary depending upon how your company has utilized the UM features. Over the course of this calendar year, we will selectively notify customers via the Office 365 Message Center of their coming transition. The first group of customers will be notified in February 2019 and then can expect to be transitioned in March 2019. The experience for each customer will be transparent – Microsoft will switch your users over to Cloud Voicemail and perform the necessary validation and testing.

Customers who have received a transition notification and would like to request postponement can do so by submitting a request via the support tool in the Office 365 Admin Portal. Please remember that final retirement date is February 2020.

Lync 2010 Servers connected to Exchange Online Unified Messaging will not be transitioned or supported with Cloud Voicemail. Customers using this topology must upgrade to Skype for Business Server prior to February 2020 for continued voicemail support via Cloud Voicemail.

The benefits of Cloud Voicemail are many. Cloud Voicemail uses Azure services based in the Microsoft Global Network to provide flexibility and scalability. It harnesses additional modern platform services such as Cortana, Graph, and AI to enhance those core experiences. Being native to the cloud allows for a single support model for all voice modalities including Skype for Business on-premises, Skype for Business Online, and Microsoft Teams. As we update Cloud Voicemail, all customers benefit regardless of platform. Cloud Voicemail also supports Microsoft voice architectures including Phone System, Calling Plans, and Direct Routing meaning it works great today and is ready for tomorrow’s innovations. Cloud Voicemail also adds additional countries to its regulatory compliance list making the technology available to more customers. And finally, Cloud Voicemail has successfully been at work since 2016 processing millions of calls per month for cloud customers.

Customers using Auto Attendant in Exchange UM Online are required to upgrade to Cloud Auto Attendant before February 2020. Administrators will need to recreate their auto attendants in Cloud Auto Attendant and switch their phone numbers over to them. Microsoft plans to introduce enhancements to the Cloud Auto Attendant service in Q1-CY2019 to provide customers with the necessary features to migrate their Auto Attendants from Exchange UM online, such as Hybrid Number support, multiple number support, transfer to PSTN, and more. See Set up a Phone System auto attendant to learn more about creating Auto Attendants.

For further information on this retirement, please visit our support article.

Exchange Team

Believe it or not – as of today, this blog has been around for 15 years! That’s right… the very First post was published on February 9, 2004, with How the M: Drive came about hot on its heels. Not too shabby for something people said would never work!

On this blog, we have something about every version of Exchange since Exchange 5.5; we headed off to the cloud with Exchange Online and we came back to earth recently announcing Exchange Server 2019. We dove into history with posts like A brief history of time – Exchange Server way as well as explained The story of Squeaky Lobster. Oh, and we also covered a bunch of technical stuff too, from time to time.

Have you ever wondered what the top 5 posts that people viewed on the blog have been (each of them with over 300,000 page views)? Well, here they are:

• Ask the Perf Guy: Sizing Exchange 2013 Deployments
• GAL Photos in Exchange 2010 and Outlook 2010
• Outlook Connectivity with MAPI over HTTP
• Want more control over Sent Items when using shared mailboxes?
• Configure Automatic Replies for a user in Exchange 2010

And did you know that we have had over 40M page views for content on our blog? 40M! Truth is, we suspect this number to be higher but over the years, as blog home has changed, different platforms tracked this differently so it’s a bit of a mystery.

Did you know that we had our blog officially translated into 10 languages for a few years (though sadly most of those are now gone (translated blog posts, not the languages))?

All of this would not have been possible if it was not for people writing stuff for the blog. The process that we go through when posting has not changed very much over the years but it always starts with an idea and someone willing to write about it. They are not always the same person. We don’t have an exact number but we have had 300+ people contribute to the blog by authoring blog posts. We’ve had Support Engineers, engineering PMs and Devs, the Marketing team, Consultants, Escalation Engineers and we probably missed about 10 more titles – all of whom have dedicated time to research and write stuff to share it with Exchange community. We also had many more people commenting and providing feedback, both from inside Microsoft and from our loyal readers and fans. Blogging was never really anyone’s job, so having ideas and finding people willing to write about them is what made this possible.

We realize that over the years (because we are now old and wise, in a Santa Claus kind of way), the way people consume information (and where they do it) have changed, but as we still seem to have a good sized following, we plan to keep this thing going. As mentioned, over the years we have moved our blog between different platforms (the current platform is platform #4) and we are considering moving again, which will help us be more plugged into overall Microsoft blogging / community efforts. Don’t you worry, if we do something, we plan to bring our content with us and work on redirection of old URLs to their new home. But more on that later; let’s spend our time today celebrating the past, why care about the future, we say. For today, anyway!

We have been doing a bit of cleanup, though. You might notice that bios (that we used to post for post authors) have been deleted. Honestly – over the years this stuff became so hopelessly out of date that it just needed to go. Trying to update someone’s bio from 10 years ago is just not all that interesting.

Anyway – as we remember the past and muse about the future – we wanted to ask a few questions, hoping to get a bit more insight into how you would like us to continue with this blog of ours:

Do you still find information in the form of a blog post something that you use? Why would you prefer something to be a blog post vs. let’s say a documentation article? Any other tips you have for us?

The Exchange Team Blog Team

Today we are announcing the availability of quarterly servicing updates, cumulative and update rollups, for all supported versions of Exchange Server. Exchange Server 2010, 2013, 2016 and 2019 all receive an update package. These updates include important fixes to address vulnerabilities being discussed in blogs and other social media outlets. While it is not the normal or preferred practice to release security updates in a cumulative update package, the nature of the product changes dictate that they be delivered this way as they include changes to the setup and configuration of Exchange Server. Additional details and recommended customer actions follow.

Changes to Exchange Web Services Push Notifications

An architectural change to Exchange Web Services (EWS) Push Notifications authentication is included in all packages released today. KB4490060 outlines the details of the changes made. Customers who rely upon Push Notifications, should understand the important changes made. We have evaluated the changes to push notifications against many commonly used EWS clients, e.g. Outlook Mac, Skype for Business Client, native iOS mail clients and observed no loss of functionality due to these changes. EWS Pull and Streaming Notifications functionality are unchanged by today’s updates.

The update to EWS Push Notifications is considered a critical security update and customers should deploy the update as soon as they understand and accept any potential impact. The change in Push Notification authentication is a permanent change to the product and necessary to protect the security of an Exchange Server.

After applying either the cumulative update or update rollup to a server, customers are advised to force a reset of the Exchange servers’ credentials stored in Active Directory. This can be accomplished using the Reset-ComputerMachinePassword cmdlet in PowerShell 5.1 or later. If PowerShell is not an option, netdom or Active Directory Users and Computers can also be used. Microsoft knows of no instances where machine accounts have been compromised. Updating a machine account password is considered a best practice to ensure the security of the server is not compromised. In addition, customers are encouraged to evaluate if their user password expiration policies are appropriate for Exchange enabled accounts.

Decreasing Exchange Rights in the Active Directory

The Exchange team has determined a change in the Active Directory rights granted to Exchange Servers using the default Shared Permissions Model is in order. Changes in the latest cumulative updates, described in KB4490059, reduce the scope of objects where Exchange is able to write security descriptors in the directory.

In order to apply these changes, a directory admin will need to run the cumulative update setup program with the /PrepareAD parameter. When multiple Exchange versions co-exist in a single Active Directory forest, the cumulative update matching the latest version of Exchange deployed should be used to run /PrepareAD. Setup will automatically run /PrepareDomain in the domain where /PrepareAD is executed. Environments with multiple domains in the forest will need to run the cumulative update setup program using the /PrepareDomain parameter in all domains in the forest. These steps will update the rights granted to Exchange Servers in the Active Directory to meet the new permissions scope. More information on /PrepareAD and /PrepareDomain is available at this link.

Customers running only Exchange Server 2010 will need to follow the instructions in KB4490059 to update their environments. The update rollup package released for 2010 will not apply the directory changes.

The directory updates described in KB4490059 are fully compatible with all versions of Exchange Server regardless of cumulative update or update rollup version deployed. There is no loss of product functionality associated with these updates.

The rights granted to Exchange in Active Directory using the Active Directory Split Permissions Model are unchanged by the updates released today.

Shared Permissions vs. Split Permissions Model

Early advisories released by Microsoft related to this vulnerability indicated that Active Directory Split Permissions Model was a possible mitigation to Domain Admin elevation. It is true Split Permissions affords additional directory protection over the Shared Permissions Model. However, Microsoft fully supports both modes of directory operation and recognizes that there are relative strengths and weaknesses inherent to both models. Before implementing a change of this type, customers should fully evaluate the impact to line of business processes, security and operational needs. The changes released today improve the security profile of the Shared Permissions Model, while retaining the administrative flexibility it affords. The combination of the directory permission changes and EWS security change provides the best possible protection against possible attacks, meaning that Active Directory Split Permissions are not required, but still optional.

Removing Legacy Auth protocols from Exchange Servers

The Exchange team has been hard at work adding a feature to limit legacy authentication mechanisms on a user by user basis. In Exchange Server 2019 Cumulative Update 1, we are announcing new cmdlet support to create organization policies that restrict legacy authentication protocols. Policies can be defined which restrict legacy authentication on a per protocol and user by user basis. The capabilities added are based upon the same functionality already available in Office 365. In the days ahead, we will release additional details on this blog concerning this exciting new feature.

Release Details

The KB articles that describe the fixes in each release and product downloads are available as follows:

• Exchange Server 2019 Cumulative Update 1 (KB4471391), VLSC Download
• Exchange Server 2016 Cumulative Update 12 (KB4471392), Download, UM Lang Packs
• Exchange Server 2013 Cumulative Update 22 (KB4345836), Download, UM Lang Packs
• Exchange Server 2010 Service Pack 3 Update Rollup 26 (KB4487052), Download, also available on Microsoft Update

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 Microsoft Docs 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 currently supported cumulative update for the product version in use, e.g., 2013 Cumulative Update 22, 2016 Cumulative Update 12 or 11.

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 Microsoft Docs.

The updates released today will replace the quarterly servicing updates originally planned for March. The next planned set of quarterly updates is targeted for delivery in June.

Important: To avoid a setup failure, it is necessary to install the Visual C++ 2012 runtime before installing Cumulative Update 22 or Cumulative Update 12 on Edge role if not already present.

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

The Exchange Team

At Ignite 2017 and 2018 we began telling you about the Meta Cache Database feature we’re using in the O365 cloud service to improve scenario performance and store more mailboxes on ever-growing hard disk drives (HDDs). If you have not had a chance to join us at Ignite or would like a refresher, here are the two sessions:

• Ignite 2017 – Exchange High Availability and Storage for Insiders
• Ignite 2018 – Email search in a flash! Accelerating Exchange 2019 with SSDs

For those of you who have been itching to try this out, there’s good news! Not only did we ship MCDB in the Exchange Server 2019 release, we now also have a setup guide available that outlines how you can use a new PowerShell script cmdlet to deploy this feature. For all the details, head on over to Microsoft Docs and read on:

MetaCacheDatabase (MCDB) Setup Guide

If you have questions or feedback, please let us know.

Tobias Klima

We often get request from customers to control mail flow routing in a hybrid deployment, for various compliance requirements. Achieving the desired routing greatly depends on where the MX record is pointed to and the involvement of 3rd party mail gateways. Also, use of Centralized Mail Transport and the two mandatory Office 365 native domains - tenant.onmicrosoft.com and tenant.mail.onmicrosoft.com may make it even more complex.

In this article, we will discuss the scenario, which is recommended for most hybrid organizations, where MX is pointed to EOP and customer wants to restrict their on-premises Exchange servers to only accept emails from their own Office 365 tenant.

Before we start, we highly recommend that you go through the following articles to understand the basics of Hybrid mail flow:

• Transport routing in Exchange hybrid deployments
• Set up connectors to route mail between Office 365 and your own email servers
• Manage mail flow with mailboxes in multiple locations (Exchange Online and on-premises)

The above diagram shows mail routing for contoso.com. Their MX record is pointed to Office365. This means on-premises Exchange servers are not supposed to receive external emails directly. Inbound email to Contoso’s On-premises servers will always originate from or relay through their Office 365 tenant. Contoso wants to block direct email delivery from other Office 365 tenants like fabricam.com to their on-premises Exchange Servers, because that would bypass policies and rules created on their Office 365 tenant.

In a hybrid Setup, mail from Exchange Online will be received by the on-premises Exchange server either by the Default Frontend Receive Connector or the “Inbound from Office 365” receive Connector created by hybrid configuration wizard. By default, “Inbound from Office 365” Receive Connector will have all Office 365 IP Address ranges as allowed Remote IP Range. Or, in case of the Frontend Receive connector, it will be open to all IPs (0.0.0.0-255.255.255.255). Perhaps it goes without saying, but if your MX record points to Office 365, you definitely don’t want to allow anonymous submissions via the on-premises receive connector. But it’s not as simple as disabling anonymous permission on the receive connector. For Exchange 2010 server, disabling anonymous permission on “Inbound from Office 365” receive connector would cause “5.7.1 Client was not authenticated” NDR for emails coming from even your own Tenant. Whereas, for Exchange 2013 onwards, it works inversely, disabling anonymous permission does not block email from your tenant and for that matter, emails from other tenants are also allowed. So, disabling anonymous permission is not enough to lock down the on-premises Exchange server to only accept emails from your own Office 365 tenant.

The concern with this configuration is: any Office 365 tenant who knows external hostname/IP address of your server can send emails to your on-premises servers directly. I want to clarify here that although our on-premises receive connector allows all Exchange Online IP Addresses to submit emails, mails sent from other tenants will not be an authenticated submission and they wouldn’t be able to relay through your on-premises server or be treated as internal to your organization. The emails from other tenants will have the X-MS-Exchange-Organization-AuthAs header set to “Anonymous”. Still, customers might want to go further than this to restrict other tenants to send emails directly to their on-premises environment to avoid various compliance issues. One obvious example is that you may have DLP rules configured inside of your Office 365 tenant, so sending email directly to your on-premises server would bypass that rule.

First, let’s try to understand the difference between the situations when mail is sent from your own tenant and mail is sent from other tenants. When email is sent from or relayed through your own tenant, Exchange Online will send XOORG SMTP command extension with the “MAIL FROM” Command which will be same as the default accepted domain on Exchange Online. The following two conditions are checked on the on-premises Server:

1. If the Receive connector TlsDomainCapabilities is set to AcceptedCloudServicesMail, and
2. If the XOORG Domain mentioned with MAIL FROM Command matches on-premises Accepted Domain or matches any remote domains with TrustedMailInboundEnabled set to true.

If the above conditions are true, on-premises server will treat the connection as Authenticated and will promote cross premises headers to org headers. The protocol log collected from on-premises server for an email received from Hotmail and relayed through Contoso tenant will look something like below-

2018-11-09T16:30:50.288Z,E161\Default Frontend E161,08D61A879C5AB8C3,13,192.168.2.52:25,4.4.0.1:29143,<,MAIL FROM:<someuser@hotmail.com> SIZE=22396 AUTH=<> XOORG=contoso.com,
2018-11-09T16:30:50.289Z,E161\Default Frontend E161,08D61A879C5AB8C3,14,192.168.2.52:25,4.4.0.1:29143,*,SMTPAcceptAnyRecipient SMTPAcceptAuthoritativeDomainSender BypassAntiSpam BypassMessageSizeLimit,Granted Mail Item Permissions
2018-11-09T16:30:50.289Z,E161\Default Frontend E161,08D61A879C5AB8C3,15,192.168.2.52:25,4.4.0.1:29143,*,08D61A879C5AB8C3;2018-11-09T16:30:48.725Z;1,receiving message
2018-11-09T16:30:50.290Z,E161\Default Frontend E161,08D61A879C5AB8C3,16,192.168.2.52:25,4.4.0.1:29143,<,RCPT TO:John@contoso.com,
2018-11-09T16:30:50.290Z,E161\Default Frontend E161,08D61A879C5AB8C3,17,192.168.2.52:25,4.4.0.1:29143,>,250 2.1.0 Sender OK,
2018-11-09T16:30:50.290Z,E161\Default Frontend E161,08D61A879C5AB8C3,18,192.168.2.52:25,4.4.0.1:29143,>,250 2.1.5 Recipient OK,
2018-11-09T16:30:50.538Z,E161\Default Frontend E161,08D61A879C5AB8C3,19,192.168.2.52:25,4.4.0.1:29143,<,BDAT 11393 LAST,
2018-11-09T16:30:50.789Z,E161\Default Frontend E161,08D61A879C5AB8C3,20,192.168.2.52:25,4.4.0.1:29143,*,,Set mail item OORG to 'contoso.com' based on 'MAIL FROM:'

Also, this will make sure that all emails directly sent from or relayed through EOP have the “X-OriginatorOrg” header set to your Verified Domain in EXO. So, the email will have the following header:

X-OriginatorOrg: contoso.com

All of this is setup for you by the Hybrid Configuration Wizard, and as long as Office 365 is connecting directly to your on-premises Exchange server(s), XOORG SMTP command is how we keep things secure – you only trust your Office 365 tenant, not others. In fact, because the XOORG command is only understood by Exchange, we say it is more secure to connect Office 365 directly to Exchange or Exchange Edge. Other application layer filtering devices, etc. do not understand XOORG, cannot pass it, and you actually end up in a less secure state.

Emails directly sent from other tenants to on-premises servers will also use the XOORG SMTP Extension and will have the X-OriginatorOrg header, but it will not match with your Accepted domain or Remote domain with TrustedMailInboundEnabled. They are still allowed by default into your on-premises Exchange environment because we must allow other possible routing configurations.

Can someone spoof XOORG? The answer is “no”, the XOORG headers cannot be spoofed because it is the combination of the EOP TLS certificate, connector setting and accepted domain – and we control the headers when they pass through us, which is the case when our certificate is used.

Note: X-MS-Exchange-Organization-AuthAs header stamped on email received by on-premises server from O365 can be either “Internal” or “Anonymous”. For instance, emails sent from your EXO tenant to on-premises servers, will have the X-MS-Exchange-Organization-AuthAs set to “Internal”. If it’s an external email which is relayed through your tenant, the original “Anonymous” identity would be preserved and the X-MS-Exchange-Organization-AuthAs will be set to “Anonymous”. Thus, X-MS-Exchange-Organization-AuthAs header would not differentiate between email coming directly to your on-premises and email relayed through your tenant.

How to make sure other Office 365 tenants can’t bypass intended routing

Now we know how to differentiate between emails from your own tenant and from others. XOORG validation and X-OriginatorOrg header is the key. You can create a transport rule on your on-premises organization to forward these messages for approval (if X-OriginatorOrg header is not stamped correctly, because these emails are not received through your Office 365 tenant). Alternately, you can generate incident report or redirect these emails to someone else for investigation. This way, you will know if there are valid emails which are coming directly to your on-premises server because of some configuration issues. For example, it might be an internal application sending emails directly on your in-house servers.

Once you identify these issues and decide if you’re ready to take more drastic measures, you can tweak the rule to reject instead of redirect or forward:

Now anyone who tries to send emails directly to your on-premises server bypassing your MX record (which points to EOP) will receive the following non-delivery report:

The rule will function similarly in all scenarios, whether centralized mail transport is enabled or not.

There is one more slightly different routing scenario which we want to cover in this article. Imagine MX for contoso.com is pointed to a 3rd party email filter which forwards the email to their on-premises Exchange server. And then based on recipient’s mailbox location, it can either be delivered locally or forwarded to Office 365. So although the routing is different, we have a very similar issue as mentioned earlier, that any Office 365 tenant who knows external hostname/IP address of your server can send emails to your on-premises server directly.

Stopping those emails using the Transport rule described above won’t work because inbound emails from internet through the 3rd party device won’t have the X-OriginatorOrg header and all those valid emails will be blocked too.

Now, looking at the above diagram, and from our earlier discussion, we can make following assumptions for an inbound email to the on-premises server:

1. Inbound email from internet will have IP Address of the 3^rd party email filter in the receive header if it’s correctly routed through the MX.
2. In hybrid mail flow, email from your own tenant contoso.com is considered as sent from “Inside the organization”.
3. Email from other tenants like fabrikam will be treated as anonymous email from “Outside the organization”.

So, based on the above assumptions, we can create the following rule to block email which is sent directly to on-premises server bypassing the 3^rd party filter. In this example, 192.168.2.51 is the IP address of your 3^rd party email filter.

We hope this post will be helpful in planning your hybrid mailflow. I also want to take a moment and thank Scott Landry, Daniel Talbot, Lou Mandich and Ramon Infante for their contributions.

Arindam Thokder

We are very glad to announce availability of the public folder consistency agent for public folders in Exchange Online. What is this, you ask? Read on!

The agent currently works on two scenarios:

Scenario 1: Stale permissions on public folders

Consider a scenario where a user was given permissions on a public folder, but their mailbox was then removed. For example:

User named “Fi” is assigned Editor permission to a public folder called Sales:

The mailbox for “Fi” is then removed; this could be either because the mailbox was removed or the user itself was deleted (which also removes the mailbox).

After the mailbox is gone, the previous permission entry from the public folder is not cleaned up and remains there as stale entry:

Such stale permissions were a cause of concern and may result in issues like:

• Other users might be unable to access public folders, even though they have the right permissions
• Permission conflicts

The consistency agent finds and removes such stale permissions from public folders.

After the agent removed stale permission on our sample folder:

Scenario 2: Mail enabled public folder ‘content mailbox’ cleanup

Mail Enabled Public Folders (MEPF) have an important property related to ‘content mailbox’, which must be pointing to the correct public folder mailbox hosting the actual public folder content. The content mailbox property is crucial for delivering emails sent to the MEPF to a correct public folder.

We have seen situations in which the content mailbox property on the MEPF do not point to the actual public folder mailbox hosting the public folder content. In such scenarios, email sent to MEPF’s would just remain in queue and would not be delivered correctly.

The consistency agent verifies content mailbox property on MEPF’s and updates the value if it is not pointing to a correct mailbox.

In the following example, public folder “PF1” content resides in a public folder mailbox M2, however, the content mailbox property of this MEPF object is pointing to a public folder mailbox M1:

After the MEPF object is updated by the agent, the ContentMailbox correctly points to the public folder mailbox M2:

If there is email that was still ‘queued up’ for a particular folder, it will get delivered after the correction is made.

The PF consistency agent is already at work for your tenant; nothing you need to do!

For mail enabled public folders, the agent runs every day to keep the MEPF updated and avoid any mail delivery issues. And stale permissions entries are checked for and removed once every 7 days.

We’ve love to hear your feedback! Please feel free to ask any questions via the comments section below.

Public Folder team

At Microsoft Ignite, Outlook for iOS and Android announced support for deploying managed device general app configuration settings for Office 365 mailboxes and on-premises mailboxes leveraging hybrid modern authentication. This capability leverages either the Managed App Configuration for iOS or the Android managed configurations to enable MDM solutions to push configuration settings.

Today, we are announcing the availability of new functionality within Intune that enables admins to easily deploy general app configuration to Outlook for iOS and Android via App configuration policies. This new functionality allows IT admins to configure the default behavior for several settings within Outlook for iOS and Android, such as Focused Inbox.

Note: For Outlook for iOS and Android to apply these settings, the app needs to be installed and managed by the Company Portal.

Figure 1: App Configuration Policy for Outlook for iOS on enrolled iOS devices from https://devicemanagement.microsoft.com. If you're in https://portal.azure.com, then you'll go to Intune -> Client apps -> App configuration policies and add a configuration policy. 

General App Configuration details

With this new policy experience, administrators can simply configure certain Outlook app settings’ default behavior and deploy them to their user’s enrolled mobile devices. For this first release, Outlook is supporting the following settings for configuration:

As you may have noticed, settings that are security-related in nature have an additional option, Allow user to change setting. For these settings (Save Contacts, External recipients MailTip, Block external images, and Require Biometrics to access the app), administrators can prevent the user from changing the app’s configuration; in other words, the administrator’s configuration cannot be overridden.  Allow user to change setting does not change the app behavior. For example, if the admin enables Block external images and prevents user change, then by default external images will not be downloaded in messages; however, the user can manually download the images for that message body.

Note: The Allow user to change setting for Require Biometrics to access the app is currently only available as a configuration key. This will be addressed in a future Intune portal update. For more information regarding the configuration key, please see Deploy app config settings.

The following conditions apply with respect to Outlook’s behavior when implementing app configuration:

• If the admin configures a setting with its default value, and the app is configured with the default, then the admin’s configuration doesn't have any effect. For example, if the admin sets External recipients MailTip=on, the default value is also on, so Outlook’s configuration doesn't change.
• If the admin configures a setting with the non-default value and the app is configured with the default, then the admin’s configuration is applied. For example, the admin sets Focused Inbox=off, but app default is on, so Outlook’s configuration for Focused Inbox is off.
• If the user has configured non-default value, but the admin has configured a default value and allows user choice, then we retain the user’s configured value. For example, the user has enabled contact sync, but the admin sets Save Contacts=off and allows user choice, so Outlook keeps contact sync on and does not break caller-ID for user.
• If the admin disables user choice, then Outlook always enforces the admin defined configuration, regardless of the user's configuration or default app config. For example, the user has enabled contact sync, but the admin sets Save Contacts=off and disables user choice, so contact sync gets disabled and the user is prevented from enabling it.
• If after the MDM configuration is applied, if the user changes the setting value to not match the admin desired value (and user choice is allowed), then the user’s configuration is retained. For example, block external images is off by default, admin set Block external images=on, but afterwards, user changes block external images back to off; in this scenario, block external images remains off the next time the policy is applied.

Users are alerted to configuration changes via a notification toast in the app:

Figure 1: Outlook for iOS and Android app config notification toast

This notification toast will automatically dismiss after 10 seconds. There are two scenarios where this notification toast will not appear:

• If the app has previously shown the notification in the last hour.
• If the app has been installed in less than 24 hours.

Save Contacts

The Save Contacts setting is a special case scenario because unlike the other settings, this setting requires user interaction – the user needs to grant Outlook permissions to access the native Contacts app and the data stored within. If the user does not grant access, then contact sync cannot be enabled.

Note: With Android Enterprise, administrators can configure the default permissions assigned to the managed app. Within the policy, you can define that Outlook for Android is granted READ_CONTACTS and WRITE_CONTACTS within the work profile; for more information on how to assign permissions, please see Add app configuration policies for managed Android devices. When assigning default permissions it is important to understand which Android Enterprise deployment models are in use, as the permissions may grant access to personal data.

The workflow for enabling Save Contacts is the same for new accounts and existing accounts.

1. The user is notified that the administrator has enabled contact sync. In Outlook for iOS, the notification occurs within the app, whereas, in Outlook for Android, a persistent notification is delivered via the Android notification center.
   
   Figure 3: User notification regarding contact sync
2. If the user taps on the notification, the user is prompted to grant access:
   
   Figure 4: User is prompted to grant access to native Contacts app
3. If the user allows Outlook to access the native Contacts app, access is granted and contact sync will be enabled. If the user denies Outlook access to the native Contacts app, then the user is prompted to go into the OS settings and enable contact sync:
   
   Figure 5: User is prompted to enable contact sync in OS settings
4. In the event the user denies Outlook access to the native Contacts app and dismisses the previous prompt, the user may later enable access by navigating to the account configuration within Outlook and tapping Open Settings:
   
   Figure 6: User can re-enable contact sync access in OS settings

Summary

We hope you enjoy this new policy experience available within the Intune portal for Outlook for iOS and Android. We'll continue to update the list of settings that can be managed via the MDM OS channel.

For more information on general app config with Outlook for iOS and Android, see Deploy app config settings. Up next is general app configuration for the without enrollment scenario. Stay tuned!

Ross Smith IV
Principal Program Manager
Customer Experience Engineering

Common questions

Q: What versions of Outlook for iOS and Android support general app configuration on enrolled devices?

Outlook for iOS 3.15.0 and Outlook for Android 3.0.30 and later support this functionality.

Q: Can I deploy general app config to Outlook for iOS and Android if the device is not enrolled?

Not at this time, but in the future, we plan to support this scenario for accounts that have an Intune App Protection Policy applied.

Q: What if I had already deployed the configuration keys manually in an App Configuration Policy; do I need to do anything?

No! The keys will be automatically consumed in the new policy experience.

Q: How do I create an App Configuration Policy for Outlook for iOS or Outlook for Android?

We’ll be updating Deploy app config settings to include the new policy experience, but you can also review Add app configuration policies for managed iOS devices and Add app configuration policies for managed Android devices.

Q: What if we are not using Intune to manage device enrollment, but instead are leveraging a third-party MDM solution?

Not to fear, we have you covered. These settings can be delivered via any MDM provider. For more information on the configuration keys you need to use, see Deploy app config settings.

Microsoft is committed to enforcing the best security for our services. As a result, TLS1.0, TLS1.1, and 3DES were deprecated in the Office 365 service.

While 3DES is currently in the process of being disabled, there is no date set for disabling TLS1.0 and TLS1.1. That said, we are working towards disabling these TLS versions for Exchange Online endpoints. Should TLS1.0 be compromised, we will have to act quickly to disable it in our service to protect our customers. In the case of SSL3.0, we disabled it in the service just over a month after the compromise was disclosed. Therefore, we urge you to be proactive by verifying TLS1.2 support for all of your email clients and servers as soon as possible.

For inbound and outbound connections with email servers and devices that are exposed to the internet, TLS1.0 usage is still around 5%. In most cases, TLS usage is optional for messages that are sent and received on the internet. There are certain scenarios where TLS is mandatory, and if TLS1.0 is turned off in Exchange Online, mail flow will be affected.

For example, over 10% of connections from customer on-premises email servers and devices still use TLS1.0. Even worse are the legacy SMTP Auth client submissions that are used by multi-function printers and applications that need to send email. For the SMTP Auth protocol, just less than 50% of connections are still using TLS1.0. These are likely old printers or legacy applications that either have not or cannot be updated to use TLS1.2.

To help you identify if your organization is contributing to those numbers, we have developed several reports for Exchange Online. You can use these reports to help determine which clients and servers are still using TLS1.0 and TLS1.1 to connect to the various email protocol endpoints in Exchange Online. These reports can be found in the Security and Compliance Center under the Mail Flow Dashboard.

Emails between your on-premises or partner email servers and Exchange Online

Third-party email servers sending and receiving email to and from our customers are normally beyond our control (or even the control of our customers). However, your on-premises or partner email servers are easily identified because their connections to and from Exchange Online use mail flow connectors. Exchange Online relies on successful TLS negotiations and certificates to identify and use the correct inbound connector. You can also configure outbound connectors to force the use of TLS. If a connector with forced TLS uses TLS1.0 today, messages will fail to send when TLS1.0 is disabled in Exchange Online.

To help identify servers that require updating to TLS1.2, we have developed the Connector Report, which is available in our Mail Flow Dashboard in the Security and Compliance Center. To access the report, click View Details and then the Connector Report link.

The Connector Report allows you to review mail flow volume or TLS usage for a specific connector, or traffic to and from the internet that does not use a connector.  The numbers behind the charts are available in the Details Table. For detailed information on the messages involved (including if 3DES is being used), you can download the data using the Request report feature. From that data, you can identify the exact server or device, and you can attempt to upgrade the server or device to TLS1.2.

Email submitted using the legacy SMTP Auth client submission protocol

Email clients can submit email messages using several different protocols. The SMTP Auth protocol is a widely supported protocol that’s used primarily by devices and applications that send automated messages on behalf of customers. Examples include scanner to email devices, or applications that send out alerts or notifications. SMTP Auth is identified by its endpoint smtp.office365.com.

To protect against the disclosure of credentials, TLS is mandatory for SMTP Auth. This means that when TLS1.0 is disabled, no messages can be sent from devices or clients that do not support TLS1.2.

To help identify which of your devices and applications are still using TLS1.0, we have created the SMTP Auth Clients report. This report is available in the Mail Flow Dashboard where its widget displays the number of mailboxes that have used SMTP Auth in the last week. The report displays pivots for sending volume and TLS version usage. The details table provides the individual users or system accounts and their volume or TLS usage. You can also download the data using the Request report feature, which includes information about whether or not 3DES is being used.

Email submitted using one of Microsoft's client submission protocols

The previously described reports apply to SMTP-related mail flow and submissions. For other protocols, a report is available on the Secure Score site. You can find if you have any TLS 1.0/1.1 and 3DES usage for Exchange Online by clicking Score Analyzer and scrolling to the Remove TLS dependencies tab.

If you want details on who is connecting using these weaker ciphers and protocols, click on the Update button and then Launch now on the flyout that appears.

This will take you to the Secure Trust Portal where you can download your TLS 1.0/1.1 and 3DES reports.

With these reports, you can now investigate the TLS usage in your Office 365 organization and take the necessary actions to avoid any mail flow disruptions in the future.

Sean Stevenson

Today we’re announcing a new site for the Exchange Deployment Assistant – https://assistants.microsoft.com! Like the rest of the Exchange documentation, the Deployment Assistant has lived on TechNet since it was created. With the move towards the docs.microsoft.com platform, we needed to make a similar migration for the Deployment Assistant.

With the move to the new assistants.microsoft.com site, we’ve updated the Deployment Assistant to focus solely on on-premises deployments. For online and hybrid scenarios, we’ve had two different resources offering the same guidance: the EDA, and the Office 365 mail migration advisors. Rather than having the same guidance in two different places, we’re standardizing on the Office 365 mail migration wizards for online and hybrid deployments.

When you go to the new site, you’ll see two options:

The first option, On-premises Exchange deployments, will go to the Deployment Assistant and all the on-premises deployment options you know and love today. You can select questions and answers to build checklists that help you deploy new Exchange 2013 or Exchange 2016 organizations, or upgrade to them from previous versions of Exchange. Exchange 2019 scenarios are coming soon!

The second option, Migrate Exchange to Office 365 will take you to the Office 365 mail migration advisors. The Office 365 mail migration advisors offer the best solutions for helping you migrate your organization to Office 365. These include staged and cut-over migrations and all flavors of hybrid migrations. They’ll help you decide which migration option is best for you and even make sure your Office 365 tenant is ready for the migration!

For those of you who are in the middle of an on-premises deployment or migration to Office 365, the existing Deployment Assistant will remain available until the end of April 2019. After that, and for everyone who’s looking to start a new deployment or migration, please start using the new Deployment Assistant at https://assistants.microsoft.com.

Finally, we want to host additional assistants at https://assistants.microsoft.com in the future, for Exchange and other products. What are some guided assistants you’d like to see? Let us know in the comments!

Thank you!

The Exchange Content Team

As you might have previously read, we released the first wave of mail flow insights last year (here is the original announcement).

Admins can use the 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.

We're excited to announce that second wave of mail flow insights will soon be available in the Office 365 Security & Compliance Center. The new insights will be rolled out to customers who have opted in to Targeted Release, and will start to show up in the admin's mail flow dashboard at the beginning of April 2019.

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.

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

Where to find mail flow insights?

• If you are a global admin or an Exchange administrator, you can go to the Office 365 Security & Compliance Center at https://protection.office.com.
• Expand Mail flow in the left hand nav, select Dashboard, you will see all insights on the right panel.

As the doc we linked to earlier details, we're creating six new insights, reports and widgets available. Here are just a few examples of what you'll find in the mail flow insights dashboard.

Mail Flow Map

This report provides a visual map showing how mail flows through your Office 365 organization. You can use this information to learn patterns, identify anomalies, and fix issues as they arise.

Domain mail flow status

The Top domain mail flow status report gives you the current mail flow status for your organization's domains. This insight helps you identify and troubleshoot domains that are experiencing mail flow impacting issues (such as not receiving external email), domain expirations or domains with incorrect MX records.

SMTP Auth client status

This report allows you to detect potentially compromised accounts due to the use of legacy (less secure) protocols. Clicking the widget will allow admins to see details of accounts that are still using the SMTP Basic Auth protocol, and will allow them to investigate potentially compromised accounts.

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

Note that you can click the Feedback button at the bottom of the page to give feedback directly from the Security & Compliance Center:

Carolyn Liu

EHLO!

As we hinted in our 15 year blogoversary post, this blog will be moving to a new home soon. Here is what you can expect:

• Our new home will be Microsoft Tech Community, Blogs section (there will be “Exchange” in the list once all is said and done, with its own unique URL)
• We have done a lot of cleanup of our 15 years of content already; generally speaking – if it is live on the blog today, it will migrate over. We did not try to delete ‘legacy’ content, rather get rid of stuff that is obviously not relevant anymore (like that Exchange 5.5 Webcast announcement from 14 years ago)
• Yes, we will be migrating post comments over too; however, due to reasons… all of the comments will migrate over as anonymous; we felt there was still value there to keep the discussion present even though it might not be immediately obvious who was asking and replying exactly. The context helps in many cases, and good advice is good advice so…
• We will work to make sure all of individual current post URLs redirect to migrated posts in their new location
• We will work to redirect short URLs that go to our blog today, like http://aka.ms/ehlo
• All of this is going to happen within next 3-6 weeks. Or earlier. Or later. Basically: “When it’s ready.”

What can you do to prepare?

If you want to keep being engaged with us and want to keep commenting to our posts (and continue the discussion that Exchange community is known for), you will need to register with Tech Community site. We are not doing any kind of migration of user accounts.

When we will be in the finalization stage, there is likely going to be some time when we will take a ‘snapshot’ and migrate that, and any comments etc. made after that will be lost once we move over (as they will not be in migration set). We will give you a heads up when this is about to happen. If unexpected things happen and you start getting errors temporarily, now you know what’s up!

The Exchange Team Blog Team

We’re constantly improving the security of Office 365 products and services. Modern Authentication and Conditional Access are two of the best ways of ensuring that your clients can take advantage of authentication features like multi-factor authentication (MFA), third-party SAML identity providers, and are implementing automated access control decisions for accessing your cloud apps based on conditions.

Firstly, here’s some news about Modern Authentication. As you might already know, all new Office 365 tenants created on or after August 1, 2017 have Modern Authentication enabled by default in Exchange Online for all clients.

Today, we’re announcing that Modern Authentication will soon be enabled for the Windows Outlook client and Skype for Business client in all managed (non-federated) tenants that were created before to August 1, 2017. Those tenants already have Modern Authentication enabled for Outlook mobile, Outlook for Mac and Outlook on the Web, so there are no changes to any of those clients.

What does it mean to be a ‘managed tenant’?

If you use Password Hash Sync, Pass-Through Authentication, or you create, manage and authenticate your user identities directly in the cloud, your tenant is considered a ‘managed tenant’ – and this change affects you.

If your still create, manage and authenticate your identities in your on-premises Active Directory, and you use ADFS or some other 3^rd party iDP to authenticate your users – your tenant will not be affected by this change.

Will my user experience be different?

This change affects the dialog users will see when requesting their credentials.

They used to see the following prompt (the exact dialog depends upon the OS of the client, but this should be similar enough to help you identify it):

Now they will see the following prompt:

How does this change authentication?

From the user’s perspective, it’s just a dialog change. From a security perspective, the client is now using OAuth (not Basic Auth) to authenticate.

What’s better about that? Why do I care?

Switching to Modern Authentication (even if it’s used just for username and password) is more secure than using Basic Auth. Modern Authentication is not subject to credential capture and re-use, credentials are not stored on the client device, it ensures users re-authenticate when something about their connection or state changes, and it makes adding MFA simple.

What do I need to do as an Admin?

Nothing. Nothing at all, well except perhaps one thing: help your users understand that this new dialog means their connection to Office 365 is even more secure than it was before. Feel free to take the credit for that; tell them you changed it to increase their security; we don’t mind.

The next thing to do is to start thinking about enabling MFA and Conditional Access, to make those connections even more secure. Here’s a great place to start finding out more.

Speaking of Conditional Access, that leads us to the next thing we wanted to announce: we’re making some changes there too, specifically related to Exchange ActiveSync (EAS).

We’re making a change to ensure that EAS connections will be evaluated against previously unsupported conditions within Conditional Access (CA).

As you might know, many conditions that are available in CA policies have not been supported for EAS. These include country, named locations, sign-in risk, and device platform. Currently, if you include any of these conditions in a policy that targets EAS, that condition is always enforced. For example, a policy to require a compliant device outside of the corporate network would always apply (independent of the user’s location).

The below shows how the admin would enable the client app condition used to target CA policy to EAS clients.

The change we have made ensures that CA policy applied to EAS correctly honors previously configured conditions. You may see some cases where EAS may begin to work where it was previously blocked. So, if you have CA policies today that block EAS traffic because a condition is not supported, we advise you inspect and remove any of the unsupported conditions from policy.

For example, suppose you previously configured the following policy: “Block all EAS traffic from French Guyana”. Today all EAS traffic is blocked. If you are relying on a rule like that to block all EAS traffic, you need to re-think your strategy.

With the change we are making, only the EAS traffic from French Guyana will be blocked. We’re sure that you find this behavior more logical, but we wanted to make sure you were aware of the change.

So, it’s worth checking your existing CA policies to make sure you don’t have rules that might be affected by this change.

Other than this, we don’t expect any other change in behavior: EAS clients should still receive quarantine email when they don’t meet the CA policy requirements; otherwise they will get email access just as they do today.

We really do treat the security of our service and the protection of your data as our primary concern.

Please leave any comments or feedback, and thanks for reading!

The Exchange Team

Introduction

The purpose of this article is to provide high level overview of hierarchy synchronization process in public folders and provide some troubleshooting steps to monitor and troubleshoot hierarchy related issues. The information presented here applies to public folder deployment in Exchange on-premises as well as Exchange Online, with any differences called out.

Before we get started, these are some of the terms used in public folder world:

Public folder hierarchy sync

In simple terms, the public folder hierarchy is the skeleton or logical structure in which the permissions and other properties of public folders are arranged. The hierarchy makes it possible for clients to determine which PF mailbox stores the actual content of the public folder. The hierarchy is synchronized across all public folder mailboxes, to ensure a single PF mailbox is not burdened with serving the hierarchy to all clients.

Frequent synchronization of the hierarchy is critical to ensure end users always get an up to date view of the hierarchy.

Here’s what can happen when the hierarchy is not in sync. Public folder mailbox EPF1 is the primary hierarchy mailbox and has two folders in the hierarchy. A new PF mailbox EPF2 is created. EPF2 won’t show the complete public folder structure until the hierarchy is synced:

Let’s discuss how the public folder synchronization works and the components involved.

Pull mode

In pull mode, hierarchy replication is driven by secondary hierarchy mailboxes. At regular interval, the secondary hierarchy mailbox connects to the primary hierarchy mailbox to pull the changes in hierarchy. This process is accomplished with the help of the ServiceHost process (running on each server) and the MRS proxy service (running on the server hosting the primary mailbox). The frequency of connection depends on whether clients were connected to the mailbox or not.

This workflow is executed with the following frequencies:

Additionally, the following situations also trigger sync operations between a secondary mailbox and primary:

1. A user connected to a secondary mailbox performs a hierarchy update / change: The operation is performed in the primary hierarchy mailbox and then immediately replicated to the PF mailbox that is serving hierarchy for the user who made the change.
2. An update is done in a folder whose content is hosted in a mailbox other than the primary mailbox: The operation is first applied in primary (all write hierarchy client operations get proxied there) and then replicated immediately to the mailbox hosting the affected folder.
3. An admin user invokes the Update-PublicFolderMailbox with the InvokeSynchronizer parameter.
4. A new mailbox is created by Migration or AutoSplit (in Exchange Online only): These processes will cause a full hierarchy sync to be executed in the new mailbox.

The process described above was the default model for full as well as incremental hierarchy synchronization in the early days of modern public folders and served well as long as the number of public folder mailboxes was not high. However, there were some limitations with this model:

• Secondary mailboxes had no way to know if there had been a change in hierarchy. In other words, secondary mailboxes would keep connecting to the primary at defined intervals, even if there was no change in hierarchy.
• More secondary mailboxes meant more sync jobs, thus more connections competing for the limited resources in the primary mailbox.
• Larger hierarchies mean more data during sync (larger sync states and more folders to transfer) which meant longer execution times and higher resource consumption (memory, IO, CPU and network).
• As the size of the user base increases it means more hierarchy mailboxes (and consequently a higher number and frequency of sync jobs) and this usually leads to more hierarchy churn (thus requiring longer sync jobs as more data is processed).

To address these problems, a new “push mode” of hierarchy sync was introduced.

Push mode

The push mode of hierarchy sync is driven by primary PF mailbox, mainly for the incremental synchronization of hierarchy. This change was introduced in Exchange Server 2016 CU2 on-premises and in Exchange Online around the same time.

In push mode, the primary PF mailbox proactively:

• Notifies secondary mailboxes when there have been changes.
• Sends any data the secondary mailbox may need to apply the recent changes, limiting the need for it to contact primary.

Pull mode is still used for:

• Initial sync of newly created PF mailboxes
• Full sync requests triggered by an administrator
• Fallback mechanism in case of push notification being lost, or when mailboxes become out of sync

In push mode, the primary PF mailbox drives the incremental hierarchy sync jobs, using transport to send email messages to a hidden distribution list containing the different public folder mailboxes present in the hierarchy.

Some key properties of this distribution list:

• It is a hidden Dynamic DL.
• It has ShowInAddressList set to false.
• Its identity will be persisted in the organization object so mailboxes can refer to it.
• You should normally find only one such dynamic distribution group created in an Exchange environment.

The hidden DL created for sending push notification messages cannot be seen in Exchange Online but you can use the following command to view the hidden DL in Exchange on-premises:

Get-DynamicDistributionGroup -IncludeSystemObjects pub*

Secondary mailboxes will use both modes of sync, pull mode for initial full sync and push mode for incremental hierarchy sync, depending on the sync state they are in. The first sync is performed using pull mode, after that, they will not contact primary mailbox repeatedly for incremental syncs. Instead, they wait for the hierarchy sync notification email and apply the hierarchy changes once the email is received. If the secondary hierarchy mailbox doesn’t receive a push notification message within 10 minutes, it will fall back to pull mode and perform the incremental sync by contacting the Primary mailbox.

Secondary mailboxes will also use the pull mode if an administrator triggers hierarchy sync.

Hierarchy mailbox assignment

Exchange by default automatically assigns a default public folder mailbox on all user mailboxes, load balancing between all available and assignable public folder mailboxes.

A public folder mailbox having following properties is considered available for automatic assignment. In the following example, both public folder mailboxes are considered available for automatic assignment:

An admin can exclude specific PF mailbox from being automatically assigned by configuring IsExcludedFromServingHierarchy to $True

Example:

Set-Mailbox -PublicFolder epf1 -IsExcludedFromServingHierarchy $True

An admin can override the system assignment by using this command:

Set-Mailbox <username> -DefaultPublicFolderMailbox <PFMailboxName>

Example:

Set-Mailbox cloud1 -DefaultPublicFolderMailbox epf1

The public folder mailbox serving hierarchy for the user can be found using this command:

Get-Mailbox |ft name,DefaultPublicFolderMailbox,EffectivePublicFolderMailbox

The admin assigned mailboxes appear under “DefaultPublicFolderMailbox”; whereas the system assigned PF mailbox will be displayed under “EffectivePublicFolderMailbox” and DefaultPublicFolderMailbox will be blank.

For larger deployments, avoid manually assigning DefaultPublicFolderMailbox on users, as it may overload the assigned PF mailbox with lots of concurrent connections. As we learned earlier, the system assigns DefaultPublicFolderMailbox on users in such a way that connections are load balanced between public folder mailboxes available for serving hierarchy. Follow the best practices guidelines here for public folder mailbox placement and assignment.

Making sure hierarchy is healthy

Here are some tips and tricks to help keep your public folder hierarchy in top shape.

Full hierarchy sync

Admins can use the following command to ensure that the public folder mailbox has received the initial full sync of hierarchy and confirm that the PF mailbox is ready to serve hierarchy. The value of True returned here indicates the mailbox has received its first full sync of hierarchy

Get-Mailbox -PublicFolder |ft Name,IsHierarchyReady

Diagnosing hierarchy sync issues

If you suspect a specific PF mailbox is not receiving hierarchy (perhaps users tell you they can’t see a folder they know to exist), you can use the following command to get diagnostic information about hierarchy:

Get-PublicFolderMailboxDiagnostics <pfmailboxname_notreceiving_hierarchy> -IncludeHierarchyInfo

Here are some other ways to view data;

To compare the hierarchy between PF mailboxes

$P=Get-PublicFolderMailboxDiagnostics <Primary_pfmailboxname> -IncludeHierarchyInfo
$S=Get-PublicFolderMailboxDiagnostics <pfmailboxname_notreceiving_hierarchy> -IncludeHierarchyInfo

Then, you can check the output of “HierarchyInfo” from both the mailboxes and compare:

$p.HierarchyInfo
$s.HierarchyInfo

If you find the hierarchy information is not the same, you can use following command to view the time of the last sync:

$S.AssistantInfo.LastAttemptedSyncTime.LocalTime

This command tells you the last time sync failed; a gibberish value (that’s a technical term now!) indicates sync has never failed:

$s.AssistantInfo.LastFailedSyncTime.LocalTime

The following command will give you a detailed failure message from the last sync failure, a blank output indicates sync has never failed:

$s.AssistantInfo.LastSyncFailure

You can explore the other values of AssistantInfo, SyncInfo & HierarchyInfo blocks.

In case the need arises to contact Microsoft Support for assistance, you should export the report to XML format and send it along.

Get-PublicFolderMailboxDiagnostics <pf mailbox failing to sync> -IncludeHierarchyInfo |Export-Clixml epf2.xml

Other useful information

The following are some things to know related to the hierarchy sync of public folders:

Push notification emails and journaling

Since push notifications are an email message delivered using transport they will be included in journaling if enabled in an organization. In such a scenario, you can use scoped journaling and exclude the SMTP address of primary public folder mailbox from the journaling rule (as that is a sender of push notification messages).

Public folder mailbox is a top sender

You may observe that the public folder mailbox shows in the “Top Sender and recipient report” in the Security & Compliance Center.

This is currently normal and not a sign of a problem, because the primary public folder mailbox sends a large number of push notification emails to secondary mailboxes via transport. The next version of the report will exclude the public folder hierarchy sync emails.

Multiple dynamic DL’s created

As discussed earlier, push notification emails are sent to an Exchange-managed dynamic distribution group. Normally, only one dynamic distribution group is enough for the push notification emails. However, in environments that have multiple domain controllers within a single AD site with AD replication issues between the DCs, multiple dynamic distribution groups may get created unexpectedly. The issue happens because of a race condition and time lag between AD replication between DC’s in same site. Please follow steps in this KB to resolve this.

Conclusion

We hope this gives you better understanding of modern public folder hierarchy and some tools you can use to perform the troubleshooting. We would love to hear any feedback you may have on the topic.

The Public Folder Team

As you are aware, we released the Microsoft Hybrid Agent for Exchange Server as a preview on Feb. 5^th, 2019. The blog post for that release is located here.

We have been busy working on a few improvements for the Hybrid Agent over that past two months and wanted to let you know of some new features now available in the latest build of the Hybrid Configuration Wizard.

The three enhancements for the Hybrid Agent are:

1. Multi Agent installation and configuration
2. Agent status views
3. Registration/Usage of a load balancer for the internal URL instead of a specific Exchange Client Access Server

Multi Agent Deployment

Option 1 – Use the Hybrid Configuration Wizard to install additional agents

For existing Hybrid Agent preview customers who would like to install additional Hybrid Agents for redundancy, simply download the latest version of the Hybrid Configuration Wizard (HCW) and open the application on the machine where you would like to install an additional Hybrid Agent.

1. Like previous HCW runs, start the application, select Next.
2. Select a desired server to execute against, select Next.
3. Provide credentials to sign into your Office 365 tenant, select Next.
4. The HCW will gather configuration information, select Next when complete.
5. Select the default option provided for either Full or Minimal, select Next.
6. Select Exchange Modern Hybrid Topology, Next.
7. Agree to the Terms, Next.
8. A new page will be shown that will provide you with the status of your existing / previously installed agent. Make sure the status of the existing agent is accurate before proceeding to the next step. Select Install and additional agent option, Next.

Example:

The HCW will install the additional Hybrid Agent. When the installation is complete, you can open the Microsoft Windows Services console from the machine and verify the service / agent is installed and running (look for Microsoft Hybrid Service - mshybridsvc). At that point, you can either re-run HCW if you wish to make further changes to your hybrid config, or simply cancel the wizard.

You can repeat this step on each machine where you would like an additional Hybrid Agent installed.

Option 2 – Manually download & install additional agents

A second option for installing additional agents is outside the HCW itself and is done by downloading and manually installing the agent on the desired machine.

1. Go to https://aka.ms/hybridagentinstaller.
2. Save the MSHybridService.msi to a location on your machine.
3. From that machine, open a Windows Command console as Administrator and run:
4. Msiexec /i MSHybridService.msi to install the hybrid agent. You will be prompted for your tenant Global Admin credentials.
5. After the installation is complete, you can open the Microsoft Windows Services console from the machine and verify the service / agent is installed and running.

You can repeat this step on each machine where you would like an additional Hybrid Agent installed.

Checking the Status of Your Hybrid Agents

Option 1 – Get status via the Hybrid Configuration Wizard (HCW)

1. Start the HCW application, select Next.
2. Select a server in your Exchange org, select Next.
3. Provide credentials to sign into your Office 365 tenant, select Next.
4. The HCW will gather configuration information, select Next when complete.
5. Select default option provided for either Full or Minimal, select Next.
6. Select Exchange Modern Hybrid Topology, Next.
7. Agree to the Terms, Next.
8. A new page will be shown that will provide you with the status of your existing installed agents.

Cancel the HCW app when you are done.

Option 2 – Get status via the Hybrid Management PowerShell Module

With each installation of the Hybrid Agent, we install the Hybrid Management PowerShell module in the directory …\Program Files\Microsoft Hybrid Service\ on the machine where the agent is installed. By default, this module is not imported and so you will need to import it before you can use it. This module also requires the Azure module for PowerShell if not already installed. Please install the PackageManagement modules first and then see this article for how to install the Azure module.

To import the Hybrid Management module, run the following from a Windows PowerShell prompt as Administrator:

Import-module .\HybridManagement.psm1

After that you can run:

Get-HybridAgent -credential (get-credential) to view agent status:

Note: the ‘id’ value provided in the above snip is the agent identity and not your unique tenant guid assigned to the route.

Directing your Hybrid Agent(s) to the load balancer instead of a specific server

If you would like your Hybrid Agent(s) to direct requests to your load balancer instead of a specific Exchange Client Access Server, this can be done with the Hybrid Management PowerShell module. In preview, the Hybrid Agent supports routing requests to the load balancer for Exchange Server 2013 – 2019 Client Access Servers. You cannot use this if you only have Exchange Server 2010 CAS deployed.

Follow the steps above to import the Hybrid Management module for PowerShell.

From PowerShell, then simply use the Update-HybridApplication cmdlet to change the value of the internalURL (targetURI parameter) from a specific server to your load balancer endpoint.

Before running this cmdlet you will need to get the unique guid value (e.g. 12345678-1234-1234-1234-1111111111111) of your tenant’s endpoint from either your MRS configuration or the Organization Relationship object (TargetSharingEPR). Example:

PS C:\PowerShell> Get-OrganizationRelationship ((Get-OnPremisesOrganization).OrganizationRelationship) | Select-Object TargetSharingEpr
TargetSharingEpr
----------------
https://e399b770-3b66-407b-a71a-96ef80a67714.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx

Or

PS C:\PowerShell> Get-MigrationEndpoint "Hybrid Migration Endpoint - EWS (Default Web Site)" | Select-Object RemoteServer
RemoteServer
------------
e399b770-3b66-407b-a71a-96ef80a67714.resource.mailboxmigration.his.msappproxy.net

To be clear, the ID parameter required in this cmdlet is not the agent ID, but the guid listed in your custom registered endpoint retrieved using the method above.

Example:

We really hope you are enjoying and benefitting from using the Hybrid Agent. We see a lot of usage and we’re working hard to improve it all the time.

Thank you!

Exchange Hybrid Team

Several weeks ago we added a new Microsoft 365 Roadmap item announcing our intent to add ability to migrate Google G Suite calendars and contacts to the ability to migrate mail to Office 365 using our native migration tools.  We're excited to say that this functionality has started rolling out!  You can expect to see the new features light up for your tenant in the coming weeks.

Since this is a new flavor of migration to Office 365, let's take a look at what is now becoming available and answer some frequently asked questions about it.  Before diving into any migration project, it is important to answer some basic questions about it:

1. What is the size of the organization you are trying to migrate?
2. Based on your business requirements, would you like to migrate using a "cutover" (everyone at once) or "staged" (longer-term coexistence) approach?
3. What is the (approximate) average mailbox size that you'd be migrating?
4. What kind of data do you need to migrate - like mail, calendar and contacts?
5. Given the answers to the above questions, does this migration tool fit my needs?

Answering these questions will give you some idea of the scope of your project. Then you just need to find out how to get started. And you can read all about that here.

Before you actually start clicking though, let's cover some of the terms you'll need to understand and an overview of how the new G Suite migration flow will work:

Intro to Mailbox Replication Service (MRS)

Microsoft Exchange Mailbox Replication Service (MRS) is a component that handles mailbox import, export, migration and restoration for Exchange and Office 365.  Migrations are managed using individual requests.  MRS is the principal mechanism used to move mailbox data from one place to another.  In context of moving data from G Suite to Office 365 MRS is used to move mailbox data, including messages, contacts, and calendar items.  Each mailbox being migrated from G Suite to Office 365 has its own request that will be processed by MRS.

What is a migration batch?

For better usability and scheduling at scale, another component called the Migration Service provides the ability to submit migration requests for batches of users. Behind the scenes, the Migration Service uses the Mailbox Replication Service to manage the per-mailbox requests.  Grouping a set of users into a batch is primarily for management purposes and does not impact the speed or throughput of your migrations based on batch size.  For your migration, you could choose to have one batch of all users or split the users into multiple batches - the choice is yours.

Give me an overview; how do migration batches work?

How is mail data migrated?

Mail data is currently migrated using IMAP protocol.  Authentication happens using domain-wide delegated access using a Service Account that is under your control.

How fast can I migrate my data?

For mail data there is a throughput limitation of 2 GB per mailbox per day. This limit is enforced by G Suite.

For contacts and calendar data, this completely depends on the quota restrictions for your tenant's service account on the Google G Suite side (because a different protocol is used to migrate calendars and contacts; please see documentation).

I reached my 2GB limit for the day (for mail) - will the migration continue the day after?

Yes - it will automatically continue once there is capacity to migrate more data, until the 2GB/day quota is reached.

What data will NOT be migrated over?

• Mail: Vacation Settings or Automatic reply settings as well as Filters or Rules
• Meeting Rooms: Room bookings
• Calendar: Shared calendars, cloud attachments, Google Hangout links and event colors
• Contacts: A maximum of three email addresses per contact are migrated over
• Contacts: Gmail tags, contact URLs and custom tags are not migrated over

Will this also support migrating data from Google Vault to Office 365?

No.

What is the smallest batch size and is there an optimal batch size?

A migration batch can have a single user, with no current upper limit.  There is no magic number for the best migration speed or efficiency.  We recommend creating batches per-department or another logical grouping for your organization.

What is the size of the largest email I can migrate from G Suite to Office 365?

The limitation is based on the transport configuration for your organization.  The default limit is 35MB. Please see this article on how this limit can be increased.

I tried migrating and saw mention of bad items; what are those?

Bad items are data conversion failures that may be encountered during the syncing phase.  Should you encounter any bad items, you can see these in the migration report on the user and batch levels.

How do I track progress of migrations?

You can view the progress and reports via the Exchange Admin Center or use the Get-MigrationBatch PowerShell cmdlet.

Mail on Office 365 doesn't support labels.  How is mail translated to folders?

In order to provide the best mail experience in Outlook as well as account for the Focused/Other view, we translate most labels to folders.  Mail with the 'Starred' label will become flagged.  Mail with the 'Important' label will influence its Focused/Other designation.  Mail with other labels will be copied into a folder with the corresponding label name, and mail with no other labels will be moved to the Archive folder.  This means that some items that had multiple flags in G Suite will appear in multiple folders in Office 365.

I started off a batch in EAC, why doesn't my migration make progress?

Please make sure that you went through all of the pre-requisite steps on the G Suite side and have provisioned users on the O365 side.  Also check the per-user error messages if you see users with a status of 'Failed'.

My messages have completed copying but my migration is stuck at 95%. Help!

This could be expected.  Check the status of migration batch; if it reached the 'Synced' status, you can choose to complete the migration batch.

What does completion do?

For G Suite migrations, there's an option to complete a batch.  During completion, an additional incremental sync of data is performed, followed by a "switchover".  During switchover, a forwarding address is applied to the source G Suite mailbox to forward emails to the configured Target Delivery Domain.  Also, any forwarding address applied to the target O365 user is removed.

Do I really need to "Complete" my batch?

Depends - If you're taking the cutover migration route, you don't need to complete your batch(es). If you're taking the staged migration route (i.e., migrating a subset of users sequentially over a longer period of time), you'd want to complete certain batches if you'd like the automatic mail forwarding rules to reverse (Forward email from Gmail to Exchange Online instead of Exchange Online to Gmail).

How can I tell if this feature is available in my tenant?

As an Admin, you will see the G Suite (Gmail) migration option under the Migration tab in the Exchange Admin Center (EAC) or will have access to the -Gmail parameter for New-MigrationBatch CMDlet.

We really hope you enjoy using this new set of tools and it makes your migration from G Suite to Office 365 even easier. We really want to hear your feedback, so please do leave us a comment, and feel free to ask any questions here too. We have plans to make this migration toolset even better over time, so keep an eye on the blog.

The Exchange Migration Team

As you might or might not know, in Exchange Online we have an upper limit of 100 migration batches. You can see this limit for MaxNumberOfBatches in the Exchange Online PowerShell Get-MigrationConfig:

(To understand the MaxConcurrentMigrations limit of 300, you can check this blog post written by one of our migration experts, Brad Hughes.)

100 batches created at the same time should be enough for all O365 multi-tenant customers. But, as we have seen in support, sometimes there are support tickets opened because customers would see the error that says: “The maximum number of migration batches is already running. Please remove a batch before you add another one”.

The main reason why this number of batches limit is in place is that having more than 100 batches causes performance problems and could cause outages for other customers in the multi-tenant system. Additional reading on resourcing for mailbox moves can be found here.

Let’s say that you want to migrate 50,000 mailboxes to Exchange Online: you could create 50 batches with 1000 users each, and you would still have 50 batches available.

If you need to complete all the migrations of users from Batch_1 at the same time, you can easily set -CompleteAfter at the migration batch level. Once this batch is completed, you could delete it to create room for another one.

In real world, though, we have seen that our customers rarely want to complete large amount of mailbox migrations at the same time. This is usually the reason why large migration batches are not created but rather smaller batches are preferred. That way, all the migrated users from one migration batch at a time can be completed together.

In this scenario, our recommendation is to have large batches for initial sync and if you need to complete the migration for users at a separate date, then you would complete the migration for groups of users in smaller batches, as needed. So how would you create small completion batches for already synced users from larger synced batches?

Suppose you want to complete migration of users A, B and C, who reached Synced status and they are all contained in a large batch of 1000 users called Batch_1.

To do this, first ensure that you have fewer than 100 batches created at the moment:

(Get-MigrationBatch).count

Then, proceed with PowerShell commands to get the users from the larger batch Batch_1 into the new smaller batch CompletionABC. Then complete this smaller batch and optionally, remove the completed migration batch:

New-MigrationBatch -Name CompletionABC -UserIds EmailAddressOfUserA, EmailAddressOfUserB, EmailAddressOfUserC
Complete-MigrationBatch CompletionABC
Remove-MigrationBatch CompletionABC

Another method we sometimes see people using is setting -CompleteAfter on the move requests directly using Set-MoveRequest.  We don't recommend this method because the Migration Service may overwrite the per-request CompleteAfter setting with the one from the batch without notice. This method of individually completing the move requests should only be done when you’ve started the migration through PowerShell, using New-MoveRequest cmdlet, without creating migration batches to contain those move requests.

I hope this post gives you a better idea of how to manage migration batches with many users being migrated and not have to run into the limit of number of batches.

See you in the cloud!

Special thanks to Brad Hughes and Nino Bilic who contributed to this blog post and their precious help in my daily support job.

Mirela Buruiana

To prepare for supporting on-premises Exchange Server 2019, I felt it necessary to build out a basic lab. I've used a default installation lab to great effect during my career supporting Exchange, both for demonstration purposes and troubleshooting customer environments by comparing my default configuration to their custom settings. This is something I've looked forward to with each new version of the product.

A welcome feature of Exchange Server 2019 is the addition of Windows Server 2019 Core to the list of supported operating systems. I have precious little experience with Windows Server Core since it was introduced, so I first navigated to Bhalchandra Atre's excellent blog post Deploy Exchange Server 2019 on Windows Server Core and read it verbatim. My reason for this post is to expand on a few items that I encountered during my installation process that I found little documentation for, especially in the context of installing Exchange on Windows Server Core.

After spinning up a domain controller, a Windows 10 client and two Windows Server 2019 Server Core installs, I ran smoothly through the steps detailed in Bhalchandra’s post, downloading the latest files for installation noted in his post:

• Exchange Server 2019 CU1 (or later) .ISO
• Visual C++ Redistributable Packages for Visual Studio 2013 (vcredist_x64.exe)

The UCMA 4.0 Runtime is still a prerequisite for installing Exchange 2019, but there’s no need to download it. As Bhalchandra points out, the UCMA installable is located under the “UCMARedist” folder on the Exchange Server 2019 .ISO.

I created the VMs with four volumes - one each for the OS, Exchange installation, databases and logs. Before going to install, I needed to initialize and format the Exchange installation and DB/Log volumes, a task easily done in PowerShell on Windows Server Core. Run Get-Disk to enumerate your disk numbers, then build your command lines. I’m sure there's a more efficient command line construction to accomplish this, but these three steps per disk ran smoothly for me:

Set-Disk -Number 1 -IsOffline $False
Get-Disk 1 | Initialize-Disk -PartitionStyle GPT
Get-Disk 1 | New-Partition -UseMaximumSize -DriveLetter F | Format-Volume -FileSystem NTFS -NewFileSystemLabel EXINSTALL
Set-Disk -Number 2 -IsOffline $False
Get-Disk 2 | Initialize-Disk -PartitionStyle GPT
Get-Disk 2 | New-Partition -UseMaximumSize -DriveLetter G | Format-Volume -FileSystem REFS -NewFileSystemLabel DB -SetIntegrityStreams $false
Set-Disk -Number 3 -IsOffline $False
Get-Disk 3 | Initialize-Disk -PartitionStyle GPT
Get-Disk 3 | New-Partition -UseMaximumSize -DriveLetter L | Format-Volume -FileSystem REFS -NewFileSystemLabel Logs -SetIntegrityStreams $false

You have the option to connect the Disk Management MMC from a regular Windows Server or Windows 10 client to Server Core systems to manage storage in a familiar fashion. As Server Core installs become more common in your environment, I recommend understanding your remote management options as detailed in Manage a Server Core server at Microsoft Docs.

Next, I had to learn how to configure the paging file on a Server Core installation. Microsoft Docs to the rescue again - Configure memory dump files for Server Core installation:

wmic computersystem set AutomaticManagedPagefile=False
wmic pagefileset where name="c:\\pagefile.sys" set InitialSize=32768,MaximumSize=32768

How did I come by that size? The minimum recommended RAM for the mailbox role is now 128 GB. The paging file guidance is defined as "a size equal to 25% of installed memory" according to the  Exchange Server system requirements, a notable change to the guidance of RAM + 10 MB to a maximum of 32778 that’s been recommended since April of 2014. Additionally, the paging file may now grow as large at 64 GB if you assign the maximum recommended RAM of 256 GB.

Next, I downloaded the latest HealthChecker.ps1 script and processed the output for any recommendations before putting the new Exchange installs into service. I regularly use and endorse this script with customers, and I highly recommend a monthly maintenance task of running the latest version of the script in your Exchange environment. Check out the available command line switches too, especially the -BuildHtmlServersReport to generate a very useful HTML output of the findings across multiple servers.

With the two servers prepped for installation, I pasted the unattended command line into the first server to begin the installation:

Setup.exe /m:install /roles:m /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents

In my enthusiasm to get started, I pasted in this overly simplistic command line on the first server which neglected to leverage the options to name and locate the first database and its transaction logs. It's easy enough to move Exchange databases, even renaming the .edb file while it's making the trip, but I had another thought. At some point in the future, Exchange 2019 will need to be properly uninstalled and there's no Control Panel in Windows Server Core. That's where I picked up my third valuable experience worth mentioning here - how to uninstall Exchange from Windows Server Core. You currently have one option recommended by the product group to do this: the command line.

I proceeded with the installation of the second Exchange 2019 server with the correct command line, rebooted it, then moved the Administrator mailbox and the -Arbitration mailboxes from the first database to the second one to prepare for the uninstallation of the first server. I pasted in this command line to start the uninstallation process:

Setup.exe /m:uninstall /roles:m /IAcceptExchangeServerLicenseTerms

The process failed at the prerequisite check, complaining of mailboxes still present on the server. The error reminded me to move or remove user mailboxes, system mailboxes, archive mailboxes and audit log mailboxes. Not the first time I’ve forgotten that one... Once I moved the audit log mailbox, the uninstall processed smoothly.

Important: You may find generalized guidance detailing how to uninstall software on Windows Server Core using MSIEXEC. Attempting to uninstall Exchange using this method will result in an incomplete removal of the server and is therefore not recommended. The product group supports both the GUI and command line options to install Exchange Server 2019, and currently just the command line option for uninstallation.

Here are the unattended installation commands I used and recorded in my build document:

Setup.exe /m:install /roles:m /MdbName:DB1 /DbFilePath:"G:\DB1\db1.edb" /LogFolderPath:"L:\DB1" /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents
Setup.exe /m:install /roles:m /MdbName:DB2 /DbFilePath:"G:\DB2\db2.edb" /LogFolderPath:"L:\DB2" /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents

Note: I didn't run /PrepareAD first as a standalone command because I was logged in with the necessary credentials to extend the schema on a server in the same site and domain as the schema master.

After the installations completed, I ran through all the standard tasks of getting a new Exchange server ready to host mailboxes using the same methods as before with Exchange 2013/2016.

Windows Server Core management options were mentioned earlier, but I want to specifically call out the Windows Admin Center as an excellent way to manage all your recent vintage Windows Servers, and it’s especially useful for Server Core. If you have not tried it yet, you may be missing out on a utility that will significantly improve your daily Windows Server administration tasks.

Final thought - if you're building out a lab for testing and would like to populate it quickly with real world users and data, I highly recommend Aaron Guilmette's awesome script Create Realistic Lab Users. Run it with -TheWholeShebang parameter and watch it go!

Butch Waller
Senior Premier Field Engineer

With the introduction of Unified Retention & Retention Labels in the Security and Compliance, many customers have questions on the differences between Unified Retention, Retention Labels and MRM retention, configurable parameters and other common scenarios.

Retention or Unified Retention

Retention or Unified Retention is available in Office 365 Security and Compliance portal.

Unified retention policy in Office 365 can help you achieve all these goals. Managing content commonly requires two actions:

1. Retaining content so that it can't be permanently deleted before the end of the retention period.
2. Deleting content permanently at the end of the retention period.

With a retention policy, you can:

• Decide proactively whether to retain content, delete content, or both - retain and then delete the content.
• Apply a single policy to the entire organization or just specific locations or users.
• Apply a policy to all content or just content meeting certain conditions, such as content containing specific keywords or specific types of sensitive information.

SCC Retention provides true retention, you can use a single SCC retention policy to perform both deletion and retention and at the same time a single policy can be applied across different workloads.

For more details, refer Overview of Retention Policies

Retention Labels

Retention Labels is available in Office 365 Security and Compliance portal.

Retention labels in Office 365 can help you take the right actions on the right content. With retention labels, you can classify data across your organization for governance, and enforce retention rules based on that classification.

With retention labels, you can:

• Enable people in your organization to apply a retention label manually to content in Outlook on the web, Outlook 2010 and later, OneDrive, SharePoint, and Office 365 groups. Users often know best what type of content they're working with, so they can classify it and have the appropriate policy applied.
• Apply retention labels to content automatically if it matches specific conditions, such as when the content contains:
  • Specific types of sensitive information.
  • Specific keywords that match a query you create.
  • The ability to apply retention labels to content automatically is important because:
  • You don't need to train your users on all of your classifications.
  • You don't need to rely on users to classify all content correctly.
  • Users no longer need to know about data governance policies - they can instead focus on their work.
• Apply a default retention label to a document library in SharePoint and Office 365 group sites, so that all documents in that library get the default retention label.
• Implement records management across Office 365, including both email and documents. You can use a retention label to classify content as a record. When this happens, the label can't be changed or removed, and the content can't be edited or deleted.

Retention setting in Labels and Unified Retention is same. A single retention labels policy to perform both deletion and retention and at the same time a single policy can be applied across different workloads.

There are different ways to monitor the usage of Retention Labels using Data Governance Dashboard, Label Activity Explorer (Available with E5 only), Content Search, Audit log

For more details, refer Overview of Retention Labels

Messaging Records Management (MRM)

Messaging Records Management aka Retention Policy is available in Exchange on-premises as well as in Exchange online and available in Exchange Admin Center (EAC).

You can use retention policies to enforce basic message retention for an entire mailbox or for specific default folders. Although there are several strategies for deploying MRM, here are some of the most common:

• Remove all messages after a specified period.
• Move messages to archive mailboxes after a specified period.
• Remove messages based on folder location.
• Allow users to classify messages.
• Retain messages for eDiscovery purposes.

When you implement MRM policies that remove messages from mailboxes after a specified period it also retains them in the Recoverable Items folder for In-Place eDiscovery purposes, even if the messages were deleted by the user or another process.

In Exchange Server and Exchange Online, MRM is accomplished through the use of retention tags and retention policies.

• Assigning retention policy tags (RPTs) to default folders, such as the Inbox and Deleted Items.
• Applying default policy tags (DPTs) to mailboxes to manage the retention of all untagged items.
• Allowing the user to assign personal tags to custom folders and individual items.

Messaging Record Management policy itself doesn’t perform any retention. You need to use a time-based In-Place Hold or Litigation Hold to preserves messages that were deleted for long period of time than the Single Item Recovery period.

In this post, we will be referring Messaging Records Management (MRM) as EAC based Retention.

For more details, refer Messaging records Management

Next, we will answer some of the frequently asked questions around Retention Policies in the SCC and EAC.

Deletion and Retention options for Retention. What do they really do?

While creating Unified Retention policy or Retention Labels, the settings below, may not be as clear for some customers. Let’s take a deeper look:

Option: “Yes, I want to retain”

This option means retain content in user’s mailbox (mail folders and Recoverable Items folder) wherever they are located for specified x days/months/years. You also get an option to retain them forever. This setting also applies to content in folders in archive mailbox and its Recoverable items folders.

Content deleted from user’s mail folders will be moved to Recoverable items folder and content which is already existing in Recoverable items folder (when policy is applied), will be retained for x days/months/years. In short retention will make sure that the content will not be purged completely from the mailbox for specified number of days/months/years

What happens to content when the retention period for emails is expired? It depends on what’ option is selected next;

“Do you want us to delete it after this time?”

If “Yes” is selected, MFA does the job of cleaning the expired contents from user’s mail folders and from the Recoverable items folders. This also includes expired content in archive mailbox and its recoverable items folders.

If “No” is selected, Managed Folder Assistant (MFA) will not clean the expired content (move to recoverable items folder) which exists in user’s mailbox folders. But the expired content in Recoverable items folder older than Single Item recovery period (14 days) will be cleaned, provided there is no other hold applied to this mailbox to retain the content longer.

To identify other holds on the mailbox, refer How to identify the type of hold placed on an Exchange Online mailbox.

Option: “No just delete content that’s older than”

This option indicates delete content in user’s mailbox (users’ mail folders and Recoverable Items folder) which is older than configured x days/months/years, wherever it is located. This also includes content in folders in the archive mailbox and its Recoverable items folder.

With this option selected, expired content from user's mail folders and Recoverable items will be deleted permanently (provided that there is no other hold configured to retain content for longer period.)

For more details refer Deleting content that's older than a specific age

Let’s discuss some of the common scenarios.

Retain and Delete content in the entire mailbox.

If you are planning to use Unified Retention and your requirement is that the mailbox should not hold any content older than 1 year.

You can create a SCC Retention as shown below so that any data which is older than 1 year would be deleted from the user's mail folders and Recoverable items folders.

This option makes sure than there is no content in the mailbox older than 1 year, both in users mail folder and Recoverable items folder, this also includes content in archive mailbox. The expired content is not immediately purged from the mailbox instead it is retained for some more days, it could be because other holds and because of DelayHoldApplied on the mailbox.

Retain the deleted content for a longer period.

If you are planning to use SCC Retention and your requirement is that the content from user's mail folders older than 1 years needs to be deleted and the deleted content need to be retained for 7 years for eDiscovery or recovery.

One of the ways to achieved this is by creating two SCC Retention policies

One policy to delete email older than 1 year:

Another policy to retain data for 7 years:

How is the retention period specified calculated?

The retention period calculation for different types of items varies and is documented in below article.

For more details How retention age is calculated

Above article applies both the EAC based retention and SCC Retention

Principles of retention.

A mailbox can have multiple Unified Retention or Retention Labels policies applied either implicitly or explicitly. At times in order to meet your compliance requirement, a given mailbox can be subjected to multiple policies, in such cases it’s important to understand which action take precedence, which is explained nicely using “Principles of retention”

For more detail on “Principles of retention” refer Overview of retention policies

Should I use the EAC based retention or SCC Retention?

It really depends on your retention requirements.

With introduction of auto-expanding archive feature, it is important that you move your old emails from primary mailbox to archive mailbox this includes emails from the user’s folders and Recoverable Items folder of primary mailbox, so that Primary mailbox doesn’t exceed the mailbox quota limits.

For auto-expanding archiving feature refer Auto-expanding archiving feature

Automate moving emails to the archive.

What if you want to automate moving emails older than 2 years from primary to archive, the only option to do this currently is using Default Policy tag or Personal tag in MRM 2.0 as these are the only retention tags which support move to archive action.

SCC Retention or even Retention Labels doesn’t provide us the same option of moving emails to archive mailbox. So, in this case EAC based retention is the only option (currently). This is probably the only advantage of using EAC based retention.

Does it mean that I can apply EAC based retention and SCC Retention to the same mailbox?

Yes, You can.

It's important note that a given mailbox can have only one EAC based retention with multiple tags and at the same mailbox can have multiple SCC Retention policies and Retention labels policies.

I would recommend using EAC based retention to meet your archiving (mailbox) needs and SCC retention for your retention needs.

But what about emails in the Recoverable Items folder in Primary mailbox?

As Recoverable items has its own quota, in order to prevent it from being full, you can opt to archive emails from your primary mailbox’s recoverable items to archive mailbox’s recoverable items. There is a special tag called “Recoverable Items tag” in EAC based retention which only support the move to archive action can move emails from Recoverable items folder of Primary mailbox to Recoverable items folder of Archive mailbox.

So, if you are planning to use EAC based retention for archiving purpose and SCC retention to meet your retention needs, your sample policies should look as below.

With above EAC based retention policy in place, emails (as well as other items) older than 180 days in users mail folders will be moved to archive mailbox, at the same time deleted content in Recoverable items of Primary mailbox will be moved to Recoverable items of archive mailbox after 14 days.

Also, when you are planning to use SCC retention along with EAC based retention policy it is important to understand how precedence works in EAC based retention like;

• Default Policy tag (DPT) with move to Archive action always overwrites the Retention Policy tag (RPT) or the Personal tag (PT), when the age limit for retention of DPT is lower than of RPT or PT.
• Explicitly assign tag wins over an implicit tag

It’s important to plan your policies & test the policies on test mailboxes to understand the behavior.

Organizations share a common goal of having consistent approach to categorize, classify important content from its creation, retention and disposal. In achieving this goal it's critical that administrators and Information Management teams carefully plan and test their data governance strategy.

Hope this post helps.

Big Thanks to Linda Harrell (Supportability PM - Information Protection) & Bhalchandra Atre (Supportability PM - Exchange) for reviewing this post.

Vikas Soundade

As mentioned back in March – we are moving! Starting today, we are starting our ‘freeze’ period where we do not expect to create any new posts on this blog. We’ll start again once we have moved to our new home. To give you an idea of what’s going to happen:

• We will take a snapshot of current blog state; posts, comments, graphics, etc.
• We are going to import this to Tech Community blogs production environment and do some optimization
• We will then work on enabling blog post URL redirection
• Finally, we will turn the original blog (this one) off
• We’ll make sure that short URLs like http://aka.ms/ehlo are redirected

We are aware of a few formatting issues that we will have at Tech Community site, and will work on sorting that out, but there should be no really bad surprises. In any event, all the above should happen by the end of next week. If there are issues that you run into, links appear broken or you find yourself in a different looking site – this is what is going on.

As a reminder: if you want to keep asking questions or commenting on our posts, you will need to register with the Tech Community site because we cannot migrate blog user accounts. Additional plus is that there is a bunch of communities where you can then get engaged in too, if you are so inclined!

See you on the other side!

The Exchange Team Blog Team