Originally posted on Lucian’s blog at clouduccino.com (click here to view). Follow Lucian on Twitter @LucianFrango.


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.

busted

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


Originally posted on Lucian’s blog at clouduccino.com (click here to view). Follow Lucian on Twitter @LucianFrango.

Category:
Exchange, Office 365
Tags:
, ,

Join the conversation! 30 Comments

  1. 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?

    Reply
    • 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

      Reply
  2. 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.

    Reply
    • 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.

      Reply
  3. […] via Exchange Server hybrid “edition” myths and misunderstandings — Kloud Blog […]

    Reply
  4. 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.

    Reply
    • 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

      Reply
      • 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!

      Reply
  5. 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.

    Reply
    • 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.

      Reply
    • 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.

      Reply
  6. 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?

    Reply
    • 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,

      Reply
  7. 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

    Reply
    • 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.

      Reply
  8. 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).

    Reply
    • 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.

      Reply
      • 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.

  9. 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 😦

    Reply
  10. 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)?

    Reply
  11. 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 ?

    Reply
    • 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.

      Reply
      • 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.

  12. […] this is true… but it is a bad idea.  As a matter of fact, it is such a bad idea that I wrote a very blunt response to another blog post suggesting that keeping hybrid in place is not really necessary.  Well, […]

    Reply
  13. 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

    Reply
    • 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.

      Reply
  14. 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?

    Reply
    • 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.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: