How to share the same email domain between two Exchange Online tenants for long term mail flow tenant to tenant coexistence [Part 1]

Note: Let me start with a quick note. This blog post was initially drafted to include multiple mail flow coexistence scenarios, between two Office 365 tenants. While I was writing the first scenario, I realized that it was so extensive that it didn’t make sense to put more scenarios in the same post. So stay tuned for more posts, each with its different scenario and some more focused on tenant to tenant enterprise migrations and mail flow during a coexistence period. Enjoy!

Some context

Microsoft tenant to tenant email migrations are very common in our days, and if some are small in terms of users, and the option is to just move them all at the same time, some are too big to have that approach.

Would you consider moving 50 thousand user mailboxes, in one single cut over batch, from one Exchange Online tenant to another? Probably not.

And there’s several reasons not to consider it, most, if not all of them having the user experience in mind. It’s not just about how many terabytes you can move per day, it’s also about re configuring Outlook profiles, re doing the Exchange partnership connection in your phone, all other Office 365 workloads, etc.

So when a cut over is not being considered, the coexistence between tenants comes into play. The biggest question is, can I leverage the same email domain in two tenants? And technically the answer is yes you can, but you’ll need an address rewriting service help you do it.

In a context of a migration, address rewriting is not all you need to have mail flow coexistence, but it’s the key component.

There are other components for you to consider, when doing tenant to tenant with coexistence, but this blog posts series will be focused on mail flow.

What do you need and why should you do it versus hosting it?

Lets address the requirements first. Assuming of course you have 2 tenants, the source and destination or in some cases just two tenants from which you want to send and receive email from, using a single SMTP domain, what you need next is something to do address rewriting (outbound email) and conditional forwarding or address rewriting (inbound email).

I will use the Microsoft Exchange Edge server. It’s a reliable service, that can be designed and implemented as high available and redundant, and it has a very easy to configure bidirectional address rewriting agent.

Note: before reading the rest of this blog post, I highly recommend that you click on the link above and read all details about how the Exchange Address Rewriting works.

Now lets address why should you do it yourself vs hosting it. In fact I think the decision is up to you, but there’s two things you should strongly consider:

  1. Do you want to pay a per user fee to host a service to either a migration software company or an email relay company, when you can do it yourself at much less cost?
  2. More importantly, will you allow a third party company into a crucial part of your email flow pipeline?

Those two questions are relevant, specially the second one. It involves SLAs and other super important things to consider, specially in the Enterprise space.

But if the answer to both questions above is yes, then you’re covered. If not, continue reading.

What will this blog post cover

This blog post will address a first scenario detailing mail flow simple coexistence with two tenants using one single email domain. I am labeling it as scenario 1, because this is the first blog post of a series that will cover other scenarios.

Scenario 1: Share a same email domain between two Exchange Online tenants


What are the requirements?

To set the scenario above you need the following:

  • Two Exchange Online tenants (of course!)
  • One unique vanity domain per Office 365 tenant, which in my cases is:
  • One vanity domain to be shared by the two tenants, which in my case is
  • At least one Microsoft Exchange Edge Server
  • An SSL certificate to encrypt mail flow between both Exchange Online tenants and the Microsoft Exchange Edge

Some important notes about the requirements:

  • my tenant vanity domains are sub domains of the shared vanity domain, but that is not a requirement. You can use different domains (i.e and in your configuration.
  • In this scenario all outbound and inbound mail flow goes via the Edge server. It is highly recommended that, for production purposes, you set up a high available and redundant multiple Edge server infrastructure.
  • My Edge Server is hosted in Azure, because it’s convenient for me to quickly set it up. You can host yours anywhere you want.
  • The SSL certificate and using TLS between the Exchange Online tenants and the Edge Server, is optional but recommended.

Outbound email from Office 365

In this scenario both tenants send all email via the Edge server. Optionally you can configure Conditional Mail Routing in Exchange Online, if you want just a group of users to route their email via the Edge. I am not going to detail that here, but please reach out if you need to elaborate more on that option.

Create the send connector in Exchange Online

First lets check how the connector in Office 365 is created. If you need any basic help on how to set up Exchange Online connectors, read this.

  • In the select mail flow scenario, select the source as “Office 365” and the destination as “Partner Organization”


  • Name the connector and turn it on


  • Select the destination email domains. I have selected * which means this connector applies to all external email domains


Note: Again here you can be more creative and configure a scenario where address rewriting (and more specifically here outbound email flow going via the Edge) only applies to specific destination domains – i.e you can rewrite addresses for your users but only when they email a specific partner company with a specific vanity domain

  • Enter the Public IP address of your Edge Server or load balancer in front of it.


  • Configure the connector to always use TLS when communicating to the Edge Server. Enter the subject name or the SAN of the certificate you will use (more on how to configure the certificate later)


And that’s it, your outbound connector is configured in your Exchange Online tenant. If you’re configuring this in a production environment, make sure you scope it for one test user first, until you’re 100% sure the Edge Server is configured properly and mail flow doesn’t have any issues.

Don’t forget to create the connector in both tenants.

Receive and Send connectors in the Edge Server(s)

Now that we addressed the Exchange Online connectors, lets look at the next hop in the mail flow pipeline, the Edge Server.

For this scenario to work properly, three things need to be created in the Edge Server:

  • Receive connector(s): This is key to accept email coming from EOP/Exchange Online
  • Address Rewrite Rule(s): To be applied by the inbound and outbound transport agents and rewrite addresses
  • Send connector(s): To send email outbound or inbound after the agent does its work

Lets address first the connectors.

Receive connector

There are multiple ways and scenarios to configure the receive connector, but ultimately here’s what you need to consider:

  • You should create a dedicated connector that accepts connections from EOP (Exchange Online Protection) only, by using the “remoteipranges” parameter when creating the connector
  • You should secure communications by adding TLS as an AuthMecanism and setting the “RequireTLS” flag to $true. You will also need to add the “TLSDomainCapabilities” and “TLSCertificateName” tags
  • If in your scenario, just like in mine, the Edge Servers are stand alone, you need to make the connector ‘ExternalAuthoritative’. This is key, because for address rewriting to be executed properly, the outbound emails should be considered internal email by the Edge Server. See more on how address rewriting works in this excellent article
  • Finally you need to make sure the connector accepts anonymous relay

Note: It is very important that you lock the connector down to a specific IP range and secure the communications with a certificate and TLS, since that connector will accept anonymous relay. Alternatively, if you have or can install an Edge Server in your existing Hybrid organization (and not stand alone like in this scenario), that will allow internal authenticated email, then you should opt for doing that.

Additional Note: I’ve added an additional method to protect your Edge and mail flow infrastructure from malicious relay from other Office 365 tenants. See the “Protect your Edge from malicious email relay by creating transport rules” section below.

Lets now start by creating the receive connector:

New-ReceiveConnector -Name “From EOP” -RemoteIPRanges [EOP remote Ranges] -Usage custom -AuthMechanism Tls -PermissionGroups AnonymousUsers, ExchangeUsers, ExchangeServers, Partners -Bindings

In the command above you should:

  • Change the name of the connector as per your naming convention
  • Add all EOP remote ranges that you can find here
  • Define specific bindings if relevant to your scenario

Once the connector is created, we need to add the necessary AD permissions:

Get-ReceiveConnector "From EOP" | Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient

Before you add TLS to the connector, you need the certificate name:

$cert = Get-ExchangeCertificate -Thumbprint [Thumbprint of your third party Exchange certificate assigned to the SMTP service]
$tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"

Note: Make sure that you obtain, import and assign a proper third party certificate to your Exchange Server Edge, before you configure the receive connector

Now lets set all the necessary TLS properties in the connector:

Get-ReceiveConnector "From EOP" | Set-ReceiveConnector -AuthMechanism ExternalAuthoritative, Tls -RequireTls:$true -TlsDomainCapabilities -TlsCertificateName $tlscertificatename -fqdn

Make sure that the FQDN of the connector matches the certificate name.


Above a snapshot of the most relevant properties of the receive connector.

Send connector

Again here, for the send connector, you can have multiple scenarios. For mine, my Edge Server just has a simple send connector, not scoped to any transport rule or address space, that sends outbound email for all domains. Since this send connector is to send email to the Internet, no special TLS settings are configured.

The command I used was:

New-SendConnector -Internet -Name "To Internet" -AddressSpaces *

See here how to create a send connector and create your own.

Exchange Edge Address rewrite rules

Before I explain what rules you should create, I strongly encourage you to read this Address Rewriting on Microsoft Edge Servers article.

Address rewriting rules can be done per domain or per user. When you plan yours, think about if a domain type rule is enough or not, i.e do you want to translate to, or do you want to translate to, meaning is the prefix changing or not? If the answer is yes the prefix will change, then you need one rule per user.

Lets now check what we need to do for this specific scenario:

  • is on the first tenant and we need to translate his address to
  • is on the second tenant and we need to translate her address to

Now the rules:

New-AddressRewriteEntry -Name "John to" -InternalAddress -ExternalAddress
New-AddressRewriteEntry -Name "Mary to" -InternalAddress -ExternalAddress

The rules I created in this scenario are bi-directional.

Again you should consider per domain rules when applicable. You can also import the rules via CSV, to make sure you can create all rules with minimum effort.

Protect your Edge from malicious email relay by creating transport rules

When you set up the connectors for inbound and outbound relay of email, although the connections require TLS and only accept emails from Exchange Online, you have no control on what other Exchange Online tenants will try to do, and if they try to use your Edge to relay email.

To be able to control that, you need to create multiple transport rules in all of your Edge servers. Creating a transport rule in an Edge server is not as linear and doesn’t have the same available options that a CAS server has, but here’s what you need to do:

First exclude the recipient domains by creating one transport rule for each (or consolidating all in one) that basically stops transport rule processing if it finds a match:

New-TransportRule -Name "Emails from Outside to Inside" -FromScope NotInOrganization -AnyOfRecipientAddressContains "" -StopRuleProcessing $true
New-TransportRule -Name "Emails from Outside to Inside" -FromScope NotInOrganization -AnyOfRecipientAddressContains "" -StopRuleProcessing $true
New-TransportRule -Name "Emails from Outside to Inside" -FromScope NotInOrganization -AnyOfRecipientAddressContains "" -StopRuleProcessing $true

And finally the rule with less priority that will drop the email if it’s from outside of the Organization:

New-TransportRule -Name "Drop email if Outside of Organization" -FromScope NotInOrganization -DeleteMessage $true

The rules above must be in the right priority, meaning priority 0 to 2 should be to the rules that stop processing more rules, if an internal domain is detected.

Then, if there’s no internal domain detected in any of the recipients of the message, the Edge should drop the message. This is to allow that inbound email still works and outbound doesn’t allow malicious connections for relay.

Basically what you are saying in the last rule is that if the sender is not internal to your organization, have the Edge server just drop the email, if that rule ends up being processed. I strongly advise you to test the rule right after you implement it, and make sure it allows all the domains you need.

Lets show the rule in action:


As you can see above the email sent from a non accepted domain gets dropped by the Edge server. Also remember that the rules was processed because no other rule found a domain match in all recipients.

Consider the transport rules, although unfortunately very limited when applied in Edge Servers, when it comes to available actions and predicates, as an additional and important layer of security that you can apply to your infrastructure.

Accepted domains in the Edge Server

One of the important things I mentioned before, is that the Edge Server considers the outbound and inbound emails, sent to and from the domains you are translating to and from, as internal emails.

In my scenario all I had to begin with was a stand alone Edge Server, with no accepted domains, which might not be the case for you if you use an Edge in an existing Hybrid infrastructure, but if it is, here’s what you need to know about accepted domains:

  • Add the vanity domain from source and destination tenants, that you are translating from (outbound) and to (inbound)
  • Add the vanity domain both tenants are sharing


Here’s the snapshot of mine, just so you understand better what I needed for my scenario.

DNS Records

Now let me describe how my email related DNS records should be configured. Remember this is specific for my scenario. Also I am only covering the MX and SPF DNS records. Make sure that you apply the industry recommendations for email when configuring your email domains (i.e DKIM).

The MX records

Here’s how the MX records for all 3 domains are configured, in my scenario:

  • MX record points to EOP in the Office 365 tenant where the domain is valid
  • MX record points to EOP in the Office 365 tenant where the domain is valid
  • MX points to the pool of Edge Servers

The explanation for the above is simple, you need to make sure that any email outside of the address rewriting can go to the correct recipient. For example, if someone external emails, there’s no reason for the email to go via the address rewriting process or the Edge pool. And this applies to any external communication going to source and destination going directly to those domains.

As for the, the opposite happens, meaning if someone emails, the email must go to the Edge just so the inbound transport agent can translate that address to For that reason and because the Edge is the source of authority for the domain, that effectively is not an SMTP address in any recipient in my scenario, the MX for that domain needs to point there.

The SPF records

Here I opted for the safest approach and configured all SPF records the same way, for all 3 domains, to include senders from:

  • MX record
  • Exchange Online protection
  • The Edge server

Lets break this down:

  • and for this domains, hosted in Office 365, allowing the MX and EOP is redundant but it does no harm, and I allowed the Edge server for one simple reason, if the address translation fails for some reason, the email can still go from the Edge server outbound and the source address would be on of these domains, so for those unexpected scenarios you should add the Edge to the SPF.
  • for this domain, adding EOP is in fact not needed in my scenario, since there’s no point in time where the domain is expected to be moved to Office 365, but in most scenarios, specially migration scenarios, EOP should be in the allowed senders, so I added it. The Edge and the MX are again redundant, but you should have at least one of them.

Here’s how the SPF would look:

v=spf1 mx ip4:[Edge IPV4 Public address] ~all

How everything works

It’s time to test the scenario now. Here’s what I will do:

  • Send an outbound email from both tenants
  • Reply to the outbound emails
  • Send an inbound email to both tenants

The results we will analyze are:

  • Verify source and destination “from” and “to” addresses, looking at the email in the destination
  • Verify that TLS is being used
  • See the transport agents in action

I don’t want to prove my scenario with screenshots, since I don’t think that’s relevant and I’d have to grey out most of the information anyway, but below you can find some snippets of how it worked, just so we’re clear on what you should expect and also how to troubleshoot any issues.

Outbound email from both tenants

The email being sent at the source, from John:


And from Mary:


Now lets see what happens when the email hits the Edge server:



I used the message tracking log, and as you can see for the message I sent, the agent event “SETROUTE” is translating the address.

Lets look at the message in the destination:



… and now lets really look inside the message 🙂 (just one of them now)

The original mailfrom address:


The address translated:


And TLS being used:


Reply to the outbound emails

For the reply I will just use one user as the example, since the behavior is the same for both.


So lets see what happens in the Edge:


As you can see above, there’s two messages address to Mary, one is a reply and the other a brand new message, in both cases you can see that the recipient got translated. Unlike outbound email, you won’t see an event ID associated to the transport agent, but you can check in the recipients column that it did its job.

And finally, the external email in the internal mailbox:


That’s it. Enough screenshots. Hopefully you understood how everything works and how you can troubleshoot it.

The bottom line

Hopefully after reading this blog post, you can understand better how the mail flow coexistence can be done. This was in fact a simple scenario but more will come in future posts. If you want me to describe and blog about a specific scenario you have, or if you need help understanding it better, please drop me a line.

I’ve been working in the migration business for more than 5 years now, and I’ve seen a lot of partners and customers that do need mail flow coexistence between two tenants. Because it’s not simple for Microsoft to address that, and allow things like the same vanity domain in two tenants, some companies created products and services that try and fill that gap, but like I said previously in this post, handing over your mail flow pipeline is not a simple decision nor one that Enterprises are willing to take, specially when it’s not that hard for you to do it yourself and I am sure that building and maintaining a high available mail flow infrastructure (like Edge servers) is cheaper than paying a per user fee to get this functionality.

In fact, for many Enterprises, they already have what they need. This doesn’t necessarily has to be done with Edge servers. The top email appliances in the market can do this as well. I might include some of those scenarios in future posts.

Stay tuned and thank you for reading!














Are you considering Exchange 2019 as a “hybrid” management server in Exchange Online environments with objects synced from on premises Active Directory?

If you happen to manage an Exchange Online environment where most or all users (and other objects) are synced from your local Active Directory, you know that, for your management tasks to be executed in a supported and easy way, you need two things:

  • The local Active Directory Schema extended to the latest (recommended) Exchange version
  • At least one Exchange management server, to execute the management actions from

Because you need the schema extended, to match the cloud Exchange attributes, in your management server, it’s also logic that you would try and keep your management server with the latest version possible. With that said, you should plan to update your Exchange server on premises, whenever a new version is made available.

Seems simple, right? Well it was that simple, until Exchange 2019 came out and Microsoft decided to not provide Exchange Server Hybrid keys for it.

In the past, Microsoft had a specific site where you would get the Hybrid keys from. In theory, to be compliant, for any Exchange on premises version that was used for management and/or hybrid purposes only, and that did not host any mailbox, you would be able to license it for free.

But in July 2018 in the tech community article “Hybrid Configuration Wizard and licensing of your on-premises server used for hybrid” Microsoft explains how you can now use the Hybrid Wizard to license your Exchange server for free, but also states “Please note that HCW does not provide a ‘hybrid key’ for Exchange Server 2019. If you need a hybrid key, the latest version that it is available for is Exchange Server 2016.”

I know this is not new, but managing synced organizations has been and will continue to be a hot topic, for many different reasons, so I decided to blog about it, again.

Why not extend the free licensing to Exchange 2019?

It’s public that Microsoft still has a strong focus on providing Exchange 2019 as the Exchange version for organizations that do not want to move to the cloud, and this licensing decision is for sure related to that, in my opinion.

Is the Hybrid Wizard the best option to license your server?

I think that the Microsoft move from the website to the Wizard, to obtain licenses for hybrid server versions until 2016, is a clever one because it allows the licensing process to be easier to control, however, not all Exchange on premises in this environments can be truly characterized as “Hybrid”.

Many organizations either never had Exchange on premises or don’t rely on any type of interaction with their on premises Exchange, that could truly define it as a “Hybrid server”. Mail flow is fully in the cloud, all hardware and applications on premises interact directly with Exchange Online and free/busy between the cloud and on premises is not required because no objects are hosted from on premises.

So now you not only ask those type of customers to install an Exchange Server, just so they can manage their synced objects in a supported way, but you also ask them to run the Hybrid Wizard in a technically “non-hybrid” environment.

What’s my best option to keep my management server up to date?

The answer is simple: To stay fully up to date, you should update to 2019 and pay for a Standard license.

But if you don’t want to do that, at least for now managing the objects with Exchange 2016 is also a very valid option. Keep the 2016 version for as long as it’s officially supported and tackle the upgrade when you really need to have it done to stay in that supported scenario.

Exchange room booking and recurring meetings was finally simplified

If you follow the Microsoft Exchange Team blog, you probably noticed this post from around 1 month ago, “Easier Room Booking in Outlook on the Web”.

I know it’s been a month, but I haven’t blogged my 2 cents around this, so here it goes.

Why this change

This was an old ask from the Community, so well done for the Exchange Team (and in this case more specifically the Calendar Team) for making this happen.

Selecting a room

The initial focus is on user experience as it relates to room filtering. You can use filters like room location (allows multiple locations), room availability and room features (Audio, Video, etc).

Recurring meetings and room availability

This is one of the major changes implemented. Although Exchange has mechanisms to allow you to coordinate the availability of all meeting attendees, the availability of meeting rooms for the entire series was always a challenge.

The Exchange Team is addressing the above by having Exchange perform an availability query for all meeting dates, until it finds one unavailable, and let you know for how many instances the room is available.

Multiple rooms

In my opinion this is the second major change. For Geo diverse teams, with attendees in multiple office locations, you can select “browse more rooms” and add a local room for each of the attendees locations.

How does an Admin implement this

Basically by leveraging the Set-Place cmdlet (only available in Exchange Online), to define the room characteristics.

Bottom line

I really like this new feature. If I had to point out some negatives, those would be the fact that it’s not support for Exchange on premises, it was launched as an Outlook Web Access feature only (for now – it’s in the road map to make it available for Outlook) and also, in my opinion, the Exchange Team should look at allowing the Organizer to select an additional room(s) when the one selected does not cover all instances.

Finally just want to point out the -GeoCoordinates parameter in the Set-Place cmdlet. It’s really cool and allows you to enter the coordinates of the room and integrate with Bing Maps!


Manage your Exchange Online from the Azure Cloud Shell

The Microsoft Exchange product group, recently announced that you can now manage your Exchange Online, via the Azure Cloud Shell.

If you’re not familiar with the Azure Cloud Shell, it’s basically a browser-based Shell experience in the cloud, fully maintained by Microsoft and that you can leverage to manage your Azure and now also Exchange Online subscriptions.

It’s a step towards running automation from anywhere, with minimal to no effort, which to me is one of the next big things coming to us as IT Consultants.

I wrote a blog article recently, on how to use a multi factor authentication account to connect to Exchange Online, and what Microsoft just did was to provide, by default, the Exchange Online Remote PowerShell module, in the Azure Shell. Smart idea and I bet an awesome quick win for them.

So is there any gotchas?

The quick answer is not any major one, but I still want to point a few things. The first one is that you need an Azure Subscription, otherwise you’ll see the below.


Although many Organizations embracing the Microsoft cloud are already using Office 365 AND Azure, some are not. Some just use Office 365 and it’s good to point out that if you want to leverage this new feature, it’s time for you to create that Azure subscription. The only cost you’ll have with using Azure Cloud Shell, is Azure Storage (also mandatory) cost, which is almost insignificant.

Another smaller thing but also worth pointing out, is MFA (Multi Factor Authentication), as Microsoft expects that you have MFA enabled across all accounts. I guess that’s directly related to the fact that this module you’re leveraging is for login with MFA enabled admin accounts.

Finally Microsoft also points out that they will claim sessions that are inactive for more than 20 minutes. Have that in mind when you build your automation, or just when you have your session open for daily work. This is an expected behavior for this type of cloud and container based Shell.

What else should you know?

I am not going to transcribe the article I pointed you to, in the top of this article, but I just want to highlight the main takeaways:

  • You can access the Azure Cloud Shell in several different ways, but via the Azure portal ( or directly via the Shell portal (, are the two main ones.
  • All Exchange Online cmdlets should be available.
  • RBAC fidelity is intact
  • This does not mean there’s plans to decommission the current Exchange PowerShell module (yet?) 🙂
  • You’ll use the Connect-EXOPSSession cmdlet to start the session
  • Microsoft provides SSO (Single Sign-On) just so you don’t have to login twice (i.e Azure Portal and Exchange Online) Yay!!!

And that’s it, enjoy!!!


Use a Multi Factor Authentication enabled account to connect to Exchange Online PowerShell

Security is a big theme for any online applications and Multi Factor Authentication is used more and more everyday. Those security standards easily extend to PowerShell or any other admin sessions, to execute tasks in your tenant. It will be more and more common to see organizations that no longer allow their IT administrators to connect to their Exchange Online using basic auth.

If you’re a heavy PowerShell user like me, this is for you. Microsoft has an excellent article on how to leverage an MFA account to connect to Exchange Online PowerShell.

You should read the article, as this things tend to be updated and you’ll be sure the have the latest steps, but in essence what you need to do is:

  • Make sure you have all prerequisites (i.e .Net Framework), specially in older versions of Windows
  • Install the Exchange Online Remote PowerShell module (from the Exchange Online EAC)
  • Make sure that WinRM allows basic authentication

Finally you can run the following command to connect to Office 365 commercial:

Connect-EXOPSSession -UserPrincipalName

And if you are connecting to a different instance, such as GCC High or 365 Germany, you need to specify the ConnectionUri and the AzureADAuthorizationEndPointUri parameters (see official article for parameter configurations).

Connect-EXOPSSession -UserPrincipalName <UPN> [-ConnectionUri <ConnectionUri> -AzureADAuthorizationEndPointUri <AzureADUri>]

Here’s how the PowerShell session looks like after you install the module.


And the authentication process.


And that’s it. Happy scripting!!!


While having Public Folder access in 365 set as remote in the Organization Config, point some users to the Exchange Online Public Folders

Some key things you should have in mind, when you’re moving your Exchange Organization from On Premises to Office 365, and Public Folders are in scope:

  • Before moving the Public Folders to Exchange Online, you need to move all of your users (at least you should move all of the ones that require Public Folder access). Users in Exchange On Premises cannot access Public Folders in Exchange Online.
  • You need to follow the Microsoft Official guidance to configure legacy on premises Public Folders under a hybrid deployment.
  • You can (and should in some scenarios) point some mailboxes to the online Public Folders and that’s what this blog post is all about

Now lets look at how a Hybrid Public Folder Organization Config looks like:


As you can see above, the Public Folders in 365 are configured as remote (step 5 in the guide mentioned above), and an on premises public folder mailbox is defined as their mailbox (created in step 2 of the guide).

What this does is very simple: at the mailbox level, for each mailbox, it will set the parameter “EffectivePublicFolderMailbox” to the mailbox “OnPremPFMBX”, which is a synced mailbox object from on premises, as you can see below:


And how do we change this, per user?

The answer is simple, you run a set-mailbox cmdlet, to one or multiple users, and you define the -defaultpublicfoldermailbox parameter, to a 365 Public Folder mailbox, that you of course need to have created before hand.

set-mailbox <Mailbox> -DefaultPublicFolderMailbox 365PFMBX

The command above is what you need to run, and you can adapt if to multiple users. Let me know if you need help with that.

Before closing this blog post lets just discuss one last thing: creating the Office 365 Public Folder mailbox.

A Public folder mailbox created under a Hybrid scenario, where public folder access is set to remote, will be set by default to a HoldForMigration state. Follow this excellent BitTitan article to understand why and resolve that issue. You need to resolve it before you can create new public folders in Exchange Online.

And while doing that don’t forget that, the best tool out there to migrate your Public Folders is the BitTitan MigrationWiz tool, so while you’re in our help center go ahead and read our migration guides and ask for a quote from our sales team.

Exchange Online: The end of RPC over HTTP

And that’s it, more than 3 years after Microsoft launched MAPI over HTTP (the replacement for RPC over HTTP – aka Outlook Anywhere), now it’s time to announce that in October 31st 2017 the RPC over HTTP feature will be deprecated in Office 365.

Some of my thoughts on this, and things you should consider..

How about Exchange On-Premises?

The deprecation of RPC over HTTP is announced just for Exchange Online. What does that mean to Exchange on premises deployments? Probably that in a future Cumulative Update the feature will be discontinued, but for now, all stays the same with on-premises.

When Microsoft launched Exchange 2016 they listed the RPC over HTTP feature as de-emphasized and not discontinued.  That basically meant that it still works and it’s still supported.

That doesn’t mean that this will always be the case, and with this announcement coming now to Exchange Online, maybe a new Exchange 2016 CU will remove the RPC over HTTP feature, or maybe this is just Microsoft not publishing the rpc virtual directory anymore, in Exchange Online. I guess that at some point we will find out, but for now all supported versions of Exchange also support RPC over HTTP in an on-premises deployment.

My personal opinion is that it won’t take long for RPC over HTTP to be also deprecated i

Check the matrix below for current connectivity supportability:

Product Exchange 2016 RTM Exchange 2013 SP1 Exchange 2013 RTM Exchange 2010 SP3
Outlook 2016 RTM
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2013 SP1
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2013 RTM Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2010 SP2 and updates KB2956191 and KB2965295 (April 14, 2015)
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2010 SP2 and earlier Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2007 Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere

Any versions of Outlook being affected?

The simple answer is yes. All versions will be affected. Outlook 2007 will stop working (remember Office 2007 is out of extended support), and all other versions need to be properly updated, to the minimum versions described on the table below:

Office version Update Build number
Office 2016 The December 8, 2015 update
  • Subscription: 16.0.6568.20xx
  • MSI: 16.0.4312.1001
Office 2013 Office 2013 Service Pack 1 (SP1) and the December 8, 2015 update 15.0.4779.1002
Office 2010 Office 2010 Service Pack 2 (SP2) and the December 8, 2015 update 14.0.7164.5002

Read the Microsoft article for more details on the above.

Why MAPI over HTTP?

Let me bullet point some main reasons:

  • Better connection resiliency
  • Additional secure sign-in scenarios (multi-factor authentication)
  • Better foundation for third-party identity providers
  • Less complexity as it doesn’t depend on RPC technology
  • With less complexity the Exchange team can innovate more quickly
  • Fits into today’s reality with clients connecting from all sorts of different networks

So in a nutshell, it’s more secure, more flexible and reliable in terms of connectivity, and it’s less complex.

For more information read this amazing blog post from the Exchange product team, around MAPI over HTTP.

What should an Exchange Online administrator start doing, right now?

Identify the Microsoft Outlook versions and builds that his users have and use to connect to Exchange Online.

How? Using the PowerShell is the best method. Here’s an example command that you can run:

Get-Mailbox | Search-MailboxAuditLog -LogonTypes owner -ShowDetails | ? { $_.ClientInfoString -like “*Outlook*” } | select MailboxOwnerUPN,Operation,LogonType,LastAccessed,ClientInfoString | export-csv .\OutlookConnections.csv

I will write a blog post soon with more details, screenshots and eventually a script to gather and export all if this information.


Office 365: Outbound conditional (per source domain) mail flow routing

Imagine this scenario: You have an anti-spam appliance in front of your Office 365 tenant, and you want outbound mail flow from your tenant to go via that appliance, but depending on what the email domain of the sender is. For example you have and as two vanity domains in Office 365, and you want outbound email to go via the mail appliance, but outbound email to go direct to the Internet.

The scenario above requires conditional routing, meaning the outbound mail flow path will be different depending on what the email domain of the source user (the sender) is. The example above is just one of several that might lead you to apply such configuration.

Now the important part: How do you configure it? Well, you can do it via PowerShell or via the UI, and to do the configuration you will need the following:

  • A Transport Rule
  • An Outbound Connector

Create the Outbound Connector

The first thing you need to create is the Outbound connector.

Via Exchange Online PowerShell

To create the connector via the PowerShell, connect to Exchange Online and run the following:

New-OutboundConnector -Name “To Internet Direct” -ConnectorType Partner -UseMXRecord $true -IsTransportRuleScoped $true

The command above creates a connector that goes directly to the Internet and it’s scoped to the transport rule we will create next. If you want to create a connector that goes via an appliance run the following:

New-OutboundConnector -Name “To Internet via Appliance” -ConnectorType Partner -UseMXRecord $false -SmartHosts <Appliance IP> -IsTransportRuleScoped $true

Via the Exchange Online Admin Center

Navigate to Mail Flow > Connectors and click “+”


Select Office 365 as source and Partner Organization as destination


Enter a name and description


Select “Only when I have a transport rule set up that redirects messages to this”


Select “Use MX Record” or “route email through these smart hosts” depending on if you want the email to go direct or via an appliance/smart host


Remove the always use TLS selection, unless the appliance or server your sending the email to is configured to use TLS


Confirm the settings and click next


Validate the connector and save

Create the transport rule

Once you have the outbound connector created, you can now create the transport rule.

Via Exchange Online PowerShell

To create the transport rule via the PowerShell, connect to Exchange Online and run the following:

New-TransportRule -Name “UseAppliance” -SenderDomain <Source Domain> -SentToScope NotInOrganization -RouteMessageOutboundConnector “To Internet Via Appliance”

The command above creates a transport rule, that uses the “To Internet Via appliance outbound connector, and that applies when the source domain is specific and the destination recipient is outside of the organization (very important setting).

Via the Exchange Online Admin Center

Navigate to Mail Flow > Rules and click “+ Create a New rule”


Click on more options

Give the rule a name

In the Conditions select “Apply this rule if..” > The recipient is located > Outside of the Organization

Click in Add Condition

Select “Apply this rule if..” > The Sender > Domain is > Enter the domain name of the source user

In the “Do the Following…” section select “Redirect the message to..” > The following connector. Select the outbound connector from the drop down list

Make sure the enforce rule option is selected


Now that you have both the transport rule and the outbound connector created, lets test and see if it’s being applied.

Test the routing

The first thing you should do is simple: Send an outbound email from the user that should have conditional routing applied to his domain. Make sure the email is to an external recipient.

Once you sent the email, in the Exchange Admin Center go to Mail flow > Message trace, select the sender you want to trace the message for and click on “search”


Note: It might take a few minutes after you sent the message before it shows in the message trace

Once you can see the message there, double click on it to see the details


In the details you can see if the transport rule was applied and the transport rule name


You will also be able to see if the message was delivered, is pending or has failed. This is key for you to troubleshoot the mail flow and see if the correct rules are applied and the correct outbound connectors are being used.

And that’s it. Job done! As always if you have questions let me know.