There’s a common misunderstanding that Exchange Server hybrid (whichever version you may be running) is needed to be kept on-premises forever if you have Azure AD Connect. AADC syncs on-premises Active Directory with Azure AD. When AADC and federated identity is enabled, MOST of the cloud attributes in Azure AD are READ ONLY. From that statement it’s been understood that hybrid is needed to be maintained to do all that Exchange Online remote management goodness. Wrong!
I hate to burst the bubble here, but, I’m going to burst the bubble.
Exchange Server Hybrid
Being a consultant, I’m going to do that frustrating thing and say those famous words: “it depends on the situation”. I love being ambiguous sometimes as it affords room for different options and ideas which is great for brainstorming and architecting.
Looking at Exchange Server hybrid functionality independently of thinking about the common tech phrase “hybrid”, what does Exchange Server hybrid do? Put simply, which isn’t very clear on TechNet or other publications, hybrid creates send and receive connectors between on-premises and Office 365 EXO. It’s now just a wizard / setup application that completes a few commands that can be achieved manually through powershell. It’s not even an Exchange Server role anymore.
From there though, with the additions of AD FS and Azure AD Connect + Azure AD, a seamless solution that “joins two disparate ADDS forests and Exchange organizations” so an enterprise can complete a staged migration. Hybrid alone won’t do any of that apart from allow for mail to be sent as “internal” between on-premises and Exchange Online. That’s as simple as it gets.
Use hybrid
It’s quite easy to complete a staged migration to EXO and leave a handful (two’s enough really, even Microsoft recommend that) of Exchange Server servers on-premises with hybrid enabled. For larger or enterprise customers that perhaps have SMTP relay requirements for legacy on-premises applications, leaving hybrid is a requirement to keep that mail flow and connectivity between cloud and on-premises for an ongoing basis.
Mid to large deployments where federated identity is enabled could also leave hybrid enabled without impacting the solution in any negative way either.
Hybrid is there to make the journey to Office 365 Exchange Online easier through staged migrations. In all but one of the transitions to Office 365 that I’ve worked on, only one has not needed to use hybrid. In that circumstance there was no federated identity requirements and the migration of ~300 mailboxes was orchestrated through a ‘big bang’ migration approach.
Timing is key in any migration or transition to the cloud. Hybrid provides the warm blanket or comfort in that it assists in affording more time to the transition.
Can you get rid of hybrid? But, how?
Once hybrid is in place, Exchange server in a federated identity world should be kept on-premises indefinitely. If you want Microsoft support, then you’ll need Exchange Server to do the remote management goodness.
Third party tools (mentioned further down) are available, BUT, and the is but in caps for a reason; Microsoft won’t provide you support if anything breaks with that service. You’ll likely need to source expertise that could get rather expensive. Protip: don’t do it.
Looking at an example where we have migrated all on-premises mailboxes to Exchange Online and there is no need for large on-premises legacy Exchange Server servers. The on-premises footprint is reduced to a handful of servers and one has the Hybrid Configuration Wizard run on it.
There is a tidy up process (see the following checklist) to remove hybrid integration, but, allow for remote management of Exchange Online:
- Migrate all mailboxes to Exchange Online
- Ensure all mail flow is delegated to EXO
- Ensure all DNS is delegated to Office 365
- Transition public folders to EXO (if any)
- Ensure the “Set-OrganizationConfig -PublicFoldersEnabled local” is run from Office 365 / EXO powershell
- To stop clients from trying to contact Exchange Server on-premises for anything, disable the service connection point
- Achieved by running “Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri $Null“
- The big one, remove the hybrid config “Remove-HybridConfiguration“
- Finally, review send and receive connectors on both Exchange Online and on-premises and remove those
- Since there won’t be any requirement for cross forest mail, deleting this connectors is recommended
For more information on the process, check out this TechNet article.
The (not so) tricky part: how do you manage remote mailboxes?
There’s two pieces of this puzzle to understand.
On-premises Exchange Server integrates with Active Directory. As all data is stored in this lovely (depends on how you look at it) database/directory, Exchange reads this and through various attributes knows that mailboxes are remote or config is associated with Office 365.
The second piece of the puzzle is powershell. Having the Azure AD and Office 365 powershell modules available additionally allows for streamlined remote management. This process can be tricky and I’ve written a quick piece (available here) should you get stuck trying to install the Online Services Sign-in Assistant.
With both of those items understood, the majority of what you need to do can be achieved just as easily without hybrid as with hybrid.
Don’t use hybrid
Let’s flip the coin and explore the wonderful (or other) world without hybrid. This world mainly consist of a “cloud first” or “born in the cloud” approach to IT. Not every organisation would want to implement a complex AADConnect, AD FS and hybrid mail environment. Well managed migrations to Office 365 can certainly be achieved without the cost and time expenditure on getting a hybrid and federated solution off the ground.
Microsoft’s recommendation around this again comes down to requirements. In a nutshell, if you don’t need any of the below features, you can quickly commence a migration to Office 365 Exchange Online without hybrid connectivity:
- Secure mail routing between on-premises and EXO organizations.
- Mail routing with a shared domain namespace. For example, both on-premises and EXO organizations use the @contoso.com SMTP domain.
- A unified global address list (GAL), also called a “shared address book.”
- Free/busy and calendar sharing between on-premises and EXO organizations.
- Centralized control of inbound and outbound mail flow. You can configure all inbound and outbound EXO messages to be routed through the on-premises Exchange organization.
- A single Outlook on the web URL for both the on-premises and Exchange Online organizations.
- The ability to move existing on-premises mailboxes to the Exchange Online organization. EXO mailboxes can also be moved back to the on-premises organization if needed.
- Centralized mailbox management using the on-premises Exchange admin center (EAC).
- Message tracking, MailTips, and multi-mailbox search between on-premises and Exchange Online organizations.
- Cloud-based message archiving for on-premises Exchange mailboxes. Exchange Online Archiving can be used with a hybrid deployment.
(Source: TechNet)
Non hybrid deployments can leverage a number of excellent 3rd party tools to migrate to Office 365. This is not a paid advertisement!, but, such tools as Skykick or MigrationWiz among others allows for a streamlined and managed migration.
Final words
Working in the enterprise space, it’s common that Exchange Server of some flavour is used as the prefered mail solution. Migrating to Office 365 from Exchange on-premises will most commonly leverage hybrid.
I would, for the most part, go with hybrid for the length of the migration. Thereafter though it CAN be removed. You might not need to, but, the option is. Don’t stress about it for or against though. The end result in remote mailbox management is near identical.
Cheers, Lucian
So On-Prem Exchange is necessary for hybrid though, right?
I understand if you get rid of it, then no Exchange related attributes are sync’d with the user account that gets sync’d with AADC?
Hi Garry,
On-prem Exchange is necessary, but, hybrid itself is not if you have a federated identity enabled.
Now, you can do away with Exchange altogether and use third party tools, but, you’ll forfeit any Microsoft support.
Cheers,
Lucian
My understanding is that if you want to keep users sync’d with O365, since they’re likely also needing their AD credentials for on-premise resource access (computers, printers, file shares, etc.), then you have to always be in a Hybrid situation.
Because if you at all get rid of on-prem Exchange, then their Exchange/e-mail attributes are no longer part of their AD account, and AADC will sync that up to O365 and their Exchange/e-mail attributes are now null in O365.
Correct me if I am wrong though.
It’s a tricky subject as in Exchange Server 2010 there was an Exchange role (more a feature) called hybrid and it was “built in”.
Now that’s a wizard that can be run from any Exchange Server in your on-premises org (Ex13 and Ex16).
AADC syncs on-prem attributes and MOST are READ ONLY in the cloud, therefore, you need on-prem Exchange (not necessarily hybrid) to write those attributes to ADDS which will sync to O365 via AADC.
The point of the post was to get some information out there that a hybrid concept and the hybrid config wizard should be looked at separately and indeed are two separate things.
Lucian, with such post you confuse a lot of subscribed people. You have to outline you need Exchange on premises anyway once you have AADSync in place, large font size and bold style. If you have on premises server (like AADConnect) which integrates on premises and online world, it is called hybrid deployment anyway. And it doesn’t matter if you have Exchange Hybrid or just Exchange Server on premises with AADConnect. Overall deployment is still hybrid. People are looking for the way of Exchange Server decomissioning from on premises and you give them more confusion in this area.
Hey Stanislav,
I appreciate the feedback, thank you.
This post was in reference to the hybrid component (HCW or hybrid role/feature) not so much the concept of “hybrid” (part on-prem and part cloud).
The piece was more of a longer conceptual read, more so than a straight technical “how to” guide to understand that you can indeed remove “hybrid” (HCW or hybrid role/feature) even in a AADC/AD FS design.
Would you want to have something along the lines of a detailed decommissioning process?
That could certainly be the basis on another blog post!
Cheers mate,
Lucian
Decommissioning is well-described on technet, no need to describe it.
I mean that the first question which always appears from customer after all mailboxes moved to Exchange Online:”How can I get rid of my last Exchange Hybrid server?” However such customer request means in most cases Exchange on-premises.
Garry and jquile comments just proofed confusion.
I like your blog however fully true statements about busted myths will be treated in another way in most cases. Just believe me 🙂
Also, its amazing and awesome that you’re in the Ukraine and subscribing to our blog!
The world today is truly a small place.
Keep the feedback and comments coming, we definitely appreciate them!
And yes the world is too small today and Ukraine is already too close to Australia!
Two things. DNS delegation should not be set to Office 365. Just make sure that the DNS records are correct and keep the DNS zone hosted where it is.
Secondly, autodiscover should not be set to $null. It should be set to EXO directly such as https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml (Use fiddler to work out your local end point). This method optimises the autodiscover look up process using the top level choice of SCP.
Hey David, thanks for the feedback and comments, though, I thought I’d reply as I would say there may be some confusion here.
The DNS delegation quote was pulled from a Microsoft TechNet post which Microsoft say as their “best practice” advice is to use Office 365 DNS. I agree with you that for larger orgs this clearly doesn’t work.
Autodiscover isn’t suggested to be set to $null, rather, on internal Exchange servers, setting the AutoDiscoverServiceInternalUri to $null helps to stop client connectivity conflicts and forces client to complete a external DNS autodiscover lookup.
The following TechNet (available here) article outlines that in more detail for you.
I think I can one up your #2. You should go look in Office 365 Admin Center -> Settings -> Domains and check to see there what your public Autodiscover CNAME is supposed to point to. Then use that for the value of your CAS server(s)’s AutoDiscoverServiceInternalUri.
Most commonly right now, that is “autodiscover.outlook.com”. I totally agree about taking advantage of the SCP lookup.
Hi Lucian, we have a customer in a hybrid situation, they are now on Office 365 and we want to remove the sync. Will any exchange attributes be lost when we remove the sync and decommission the server. Is there any way of syncing passwords without the AAD sync?
Daniel,
Attributes wont be lost as the on-prem ADDS schema will retain the attributes.
Password or any kind of sync to Azure AD, via Microsoft supported methods, has to be via Azure AD Connect.
I think Octa and a few other identity providers do some new things via their own tools based on the AAD API, but, for easy of support, i’d go with AADConnect.
Cheers,
Hi Lucian,
Many thanks for this article. We have a client using AD (including AAD/ ADFS/ ADFS Proxy (DMZ) ) and Exchange Hybrid/ CAS/ EMB on-prem with user mailboxes in O365 and legacy application mailboxes on-prem.
As an option to reduce datacentre footprint, what are your thoughts on migrating the on-prem AD (including AAD/ ADFS/ ADFS Proxy (DMZ) ) and Exchange Hybrid/ CAS/ EMB to an Azure datacentre? Is this something people generally do?
Thanks
Hi mate,
Azure supports all IaaS workloads now.
There was a time when Exchange was not supported, now Microsoft has changed and you should have no issues there.
However, deploying Exchange in Azure would be for specific use cases over just using Exchange Online.
If you don’t have those specific use cases, you should use Exchange Online and Azure IaaS for hybrid / management instances.
I am going to be pretty blunt here. This is just bad advice. The best practice exists for a reason, and they are the following:
1) The changes must come from on-premise AD if you use directory synchronization
2) The only supported interface to modify these values are those that come with having an on-premise Exchange server (EAC, EMS, etc.)
3) There are no Email Address Policies available without it and Active Directory provides no validation for these attributes, in that it doesn’t care if you have duplicate ProxyAddresses or domains that are not even in the Accepted Domains list.
Microsoft has gone out of their way to offer tools to manage these things, which I will admit could be improved (especially in regards to the various shared mailbox types and their provisioning). They provide a free hybrid co-existence license. It can be a relatively small footprint VM that can also have AAD Connect installed. So, the only thing you need is Windows Server licensing (which many already cover for the virtualization infrastructures), and a minimal amount of resources.
Sure, if you are personally okay with being responsible for these things in your own company, go for it. But these are folks that you are going to make recommendations to and implement a solution for, then you are going to walk away. This is just not why companies hire professional consultants (with the ever so rare exception that customers just want to do something really badly despite the best recommendations).
Hi Dustin,
You might have misread the post there.
The main point your on is that hybrid is necessary.
To defy conventional wisdom, Hybrid is not necessary long term.
That essentially creates connectors for mail routing cross premises.
Exchange on-premises can be used without the Hybrid component.
I wrote it to outline alternate available streamlined configurations.
I thought I saw a mention of 3rd party tools to manage Exchange recipients, and advocating it.
The other issue though is why remove hybrid if you already have it?
Most organizations have a requirement to relay mail from multi-function devices and other servers on-premise. This is another situation where hybrid itself (not just an on-premise Exchange server) comes in handy. The messages relayed through a hybrid server are treated as intra-organizational. Otherwise, mail can be treated as spam. EOP will always scan the messages, but it won’t do spam checks for hybrid delivered mail, just malware checks.
I was just going back over this, and I am going to standby my previous statements. You should definitely keep an official Exchange Hybrid configuration. You need to have the server anyhow, if you’re still doing directory synchronization… why go half-baked? You gain nothing by not running the HCW. And really, to properly use the Exchange tools on-premises (EMS and EAC), which is why Microsoft makes it a support requirement to have Exchange still, you actually NEED hybrid to be configured via the HCW; this is what enabled the *-RemoteMailbox cmdlets (which is also what the EAC sits on top of). Without those cmdlets, you’re not following the actual intent of keeping the server. I just don’t understand why you would be playing mental gymnastics to recommend something that actually makes things worse, not better, than having Exchange hybrid. Without those cmdlets, you’re still resorting to manually editing the attributes, which is specifically what is not supported.
Interesting post! We have a single Exchange Hybrid server left, which I would really like to get rid of. All users have been migrated to EXO. The VM is powered off 99% of the time (Azure VM, cost effective) and we only use it when creating/deleting users.
We have AAD Connect and ADFS in place, so from my point of view (I’m *not* an Exchange guy) I can’t see what the Hybridserver does. It’s just an annoying part of our infrastructure, that we need to maintain 🙁
Why not use JumpCloud and migrate away from the Hybrid (do u really want to maintain that Exchange server), and then from the dinosaur called AD (unless all your nodeas are Windows, and all strictly on-prem)?
I setup our organization of 36 mailboxes plus shared mailboxes from scratch on O365 cloud. I have never had on prem Exchange, we’re running a 2012r2 domain w/ AD Sync (passwords and some distribution lists).
The challenge I’m facing is because o365 is throttled and some staff have large mailboxes and most are using Outlook 2010, I’m wondering if having an on prem exchange server will cache all of the mailboxes on a local database. Our company also got bought out recently and we’re looking to download all mailboxes to PST – an on prem exchange server would greatly help this.
Is it possible to install an on prem exchange server and migrate mailboxes back to on site from o365 ?
Andrew, yes that is certainly possible. You can deploy Exchange on-premises with hybrid functionality. From there, you can move mailboxes back on-premises. However, you can only store them on-premises. There is no option to cache in Exchange Server. Also, here isn’t that much “throttling” on the Exchange Online side. I would look more at your WAN connectivity. If you can’t run Outlook in “online” mode, again, there is no cacheing functionality of the mailbox in Exchange server, rather, that is a function of Outlook. Try caching in Outlook for a better user experience. Otherwise, look to get a really fast WAN connection if online mode is the only option.
Appreciate the response and have staged a test environment to work with the above, glad you’ve confirmed that I can move mailboxes to local from Cloud.
Also – Yes – O365 *DOES* throttle connection speed. When viewing resource monitor while downloading a large mailbox for the first time the connection maxes out at about 300-400kbytes/sec on a 30mbit full duplex managed fiberlink (Should be downloading at 3mbit/sec) I’ve confirmed bandwidths at the router side AND at other customer locations the same bottleneck is present. Uploading is also throttled. I know this when migrated staff from local PST to Cloud O365 connects, it takes days to upload e-mail boxes. I have a single user that has a 3 gig mailbox and it took 2-3 days to fully download all of her e-mail to her workstation. Using Outlook 2016 on our RDS server in online mode (not cached) staff wouldn’t receive e-mail in real time so it’s really created some headaches as far as response goes and using OWA as an alternative has unfortunately become a common practice.
Hi Lucian, thanks for that article.
Wondering if you can help me to understand, how it could work, if I have to migrate 150 mailboxes from Ex2010 to O365, where the users location is not so good connected to internet (with reference to the new build of OST files, after a non hybrid migration). The company would get rid off the exchange infra and won’t use ADFS (only Password sync and maybe with SSO). Isn’t it correct, that you ramp down exchange, have AADConnect in place and you can use the EXO onboard mechanism to set up a mailbox (put a valid license to user account in O365, enable Exchange and here we go)?
I’ve read in this article and comments, that Hybrid and AADConnect could be on same VirtualMachines (VM)? Do you have any VM (hardware) requirements, like disk size, or CPU/RAM and so on?
thanks, Alex
Alex, if you have a smaller migration, maybe look into a tool like BitTitan or SkyKick to do the migration. Then once migrated, you can remove Exchange altogether as you don’t need Hybrid or Exchange on-premises. AADConnect with password sync won’t do true SSO, so, you may have user experience issues. AD FS allows for true SSO. Although, once you email MFA, then the users will always be prompted, so having AD FS does not give you that much of a smooth logon anyway. In terms of AADConnect- always keep that on its on server! You can co-locate it on a domain controller if need be, but, it’s best to keep it on its own and away from Exchange.
Hi, got an interesting case here in my hands, and could really need some second opinions.
Customer has 1 Forest,3 Domains and 1 Exchange organization on-premise.
They are a kind of a service provider.
Now we´re thinking to move to 365 world, and seperate their clients to their own tenants for certain reasons and remove their on-premise Exchange infra.
Doing multitenant environment using aadconnects per tenant is not an issue, issue here is the mail migration. When the customer is large enough hybrid is by anymeans the smoothest way to migrate mail. Keeping these in mind, i tought is it possible to work like this, one tenant per time.
1) Doing Hybrid configuration
2) Migrate
3) Remove hybrid configuration, and all the things related to it
4) Disable sync https://support.microsoft.com/en-us/help/2619062/you-can-t-manage-or-remove-objects-that-were-synchronized-through-the
5) Reconfigure to use attribute filtering ( no Exchange attributes synced )
6) Enable sync
Would Exchange specific attributes be writable at AAD this time?
Boogeyman here is AADConnect/Sync and the attributes stamped to it?
Hi Pertti, I think the main consideration you should think about is the federated identity setup. When thats enabled, your attributes are assumed to be synchronised from on-premises. While Hybrid Exchange and federated identity might seem “easier”, possibly cloud identity and migrating off with specialised tools like MigrationWiz or Skykick may be a simple route. Consider each customer of the service and their own requirements, as federated identity etc might not be needed for each. That could save you headaches and possibly doing more work than necessary.
Hi Lucian
Thanks for the post, very interesting and helpful. can you answer a question for me please? we have a customer who has 75 mailboxes with exchange online archiving enabled on the exchange server, is it best to do a cutover and then move the archives using the Microsoft network upload tool or should we setup a basic hybrid configuration to do the migration then remove hybrid? if yes, is AADSync a requirement in this scenario. Thank you
hi mate, 75 mailboxes is not a lot. Hybrid has a lot of complexity and if you don’t need it, Exchange Online on its own is much more streamlined. Ive used the import tool at a customer where we had 15,000 mailboxes to migrate (via hybrid) and it sped up the migration process. For me, take the path of least resistance. For smaller migrations, theres tools like BitTitan MigrationWiz or SkyKick that automate a lot of the process. The archives may still need a bit of manual planning.
Sure, I agree it is best to keep On-Prem Exchange going in a Hybrid setup but is it a big deal if you don’t? Not really. I’ve done Dir Sync for plenty of customers who don’t have Exchange, I’ve removed final Exchange servers after migrating all mailboxes to Exchange Online, I have moved away from Hybrid after an Exchange server died. In all cases its been just fine to manage them through AD attributes. Create a user in a sync’d OU, add the proper attributes, and it syncs up just fine. I do however wish Microsoft would create an application (EMC-esk) I could install on the same VM where ADConnect is running just to manage the accounts. I assume they like sticking people with Exchange Online license fees and On-prem Exchange/Windows/CALS licensing too much to do that though. Say you are in a hybrid environment with Exchange 2010 Update 3, what happens when Microsoft stops supporting that? You going to upgrade Exchange On-Prem that you aren’t even using except for the luxury of the EMC to manage accounts. Nah, I’m good.
Justin, what attributes are you setting?
These are the usual culprits that are set for a *RemoteMailbox*
`proxyAddresses`,
`msExchRecipientDisplayType`,
`msExchRecipientTypeDetails`, `msExchRemoteRecipientType`,
`mailNickname`,
`mail`
Thanks for the article Lucian.
Hi Justin, sounds like you ran forest and domain prep for exchange to get the exch attributes in AD? We too are just finishing decommissioning 20 exchange 2010 servers and will be down to 2 2016 Exchange servers which will do nothing more then user/group/contact creation/modification as we using online connectors for relaying. We use 3rd party software now to create mailboxes. Be nice to not have any on prem Exchange Servers