This week, I was on a technical board and had to explain to customers on the level of CTO (chief technical officer) how a hybrid Exchange environment works and how it has to be installed. That is why I cached the moment to write this article, which contains the main points of my presentation.
The goal is to understand Exchange hybrid on a top level after reading this article. So, let us start with the first chapter:
What is a hybrid Exchange environment?
Well, a hybrid deployment offers organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Microsoft Exchange organization to the cloud. A hybrid deployment provides the seamless look and feel of a single Exchange organization between an on-premises Exchange organization and Exchange Online in Microsoft Office 365. In addition, a hybrid deployment can serve as an intermediate step to moving completely to an Exchange Online organization.
However, on the picture below you can see a schematic overview, how a hybrid connection looks like:
As we can see on the left side, we have our on-premises environment. If our setup is done like best practice, we have a multi-server environment (no single server) and a geo redundancy. This is needed in a simple on-premises installation. On the right side we see our Office 365 tenant which contains Exchange Online. To activate it we only need the right license models. (More about that later). How to create a hybrid setup we will see later in this article. Important at this moment is just to see the topic.
What can be the reasons to configure Exchange hybrid?
There are many reasons why we could run Exchange hybrid. I made the experience that the reasons can vary, depending on the region we are coming from. Here in Switzerland, where I am home, one of the most common reasons is to keep (theoretically) sensitive data in the country. Even if it doesn’t matter that the data can be accessible from everywhere in the world, as long the data are physically in Switzerland, they stay under the Swiss Law.
Switzerland is also well known for Banks and Insurances, that’s why we have strict regulations here through FINMA, saying what this companies are allowed to do and what not. By running a hybrid Exchange environment, we are able to move simple and not confidential mailboxes to the cloud (which is mostly between 60 and 80% of the company employees). The other users like HR, Management, etc. can stay on the on-premises environment. In this scenario we also don’t need a that huge on-premises environment (number of local server and server licenses) as we would need without the hybrid configuration.
These are the reasons for the management of Swiss companies to have to think about. However, as I have written in another article on my Blog. Microsoft will build new data centers in Switzerland, so the physical data location point will be eliminated soon.
Other reasons to get a hybrid configuration are (like I already wrote) that we can decrease our on-premises environment. That means less hardware we have to worry about, less Windows server licenses, less Exchange server licenses, less energy, space (rack) and cooling costs, etc. We still are able to share Free/Busy information and take advantage of hybrid features like Cross-premises e-discovery and Exchange online archiving (on-premises mailbox, cloud archive).
How to install Exchange hybrid?
Before we start configuring hybrid Exchange, let us have a look on the topic:
To be able to use hybrid Exchange in the way that it brings best effort, we have to think about some few things. On one hand we have prerequisites like:
- Configuring AAD Connect
- Configuring Certificates for the Mail flow and communications.
- Adding Domains (accepted Domains) to the Office 365 Tenant
- Preparing our on-premises Exchange servers for hybrid Mode
- Optional: ADFS, Transport Server, Edge etc.
As we can see in the topic, our main configuration we have to make in our LAN and DMZ. The configuration on the tenant site is simple. What we have to do is to add our domains to the tenant. How we can do that I have written in the article HERE.
When this is done, we need to configure the AAD. Here it is important that we enable a common view of recipients in the on-premises and Office 365 sites. Optionally, we can also enable additional features such as:
- Group write-back
- Password Hash synchronization
- Password write-back
By designing hybrid Exchange we also need to decide how we want to configure our mail-flow. We can use the “old” way via on-premises Smart host, or we go threw EOP. I have written an article to this theme on my blog, this article you can find HERE.
However, let us continue now with our on-premises Exchange servers. The question I hear quite often is: “What Exchange version I need to run, to be able setting up Exchange hybrid?” Well, there is no “correct” answer on this question. Of course, as newer the on-premises environment is, as easier it is to configure hybrid Exchange. To be able to create the hybrid mode, our on-premises environment have to be at least on Exchange 2010 SP3. The CU doesn’t matter but we have to keep an eye on the life-cycle of Exchange 2010!
If this question is clear we can start with the configuration. For that, Microsoft has released the HCW (Hybrid Configuration Wizard). With the HCW we´ve got a tool, where we can follow a step by step wizard to create our hybrid configuration.
What does the HCW do? Well, it configures on-premises domains and recipients for coexistence (adding routable service domain, modifies recipients, policies, etc.). HCW also configures the Exchange federation (for allowing Free/Busy etc.), it configures Organisation Relationships, OAUTH, EWS for Mailbox moves and the Mail flow coexistence (connectors in on-premises and Office 365).
On the following picture you can see a schematic overview about the work flow:
Paul Cunningham from practical365.com has written an article on his blog how the setup works. I can recommend you to check this link HERE to see the step by step configuration.
Are there risks or other reasons NOT to go with a hybrid configuration?
Of course there is no product on the market which matches perfectly for every scenario. So let us have a look on the “other side of the medal”. If we want to go with an Exchange hybrid scenario that also means we have to handle additional work to deploy some of the prerequisites. As an example, if we don’t have a AAD, ADFS and/or WAProxy in our environment, we need to build them. That also means we need additional licenses and resources for this additional environment. We also need to think about if we have enough know-how to implement all that or if we need to hire external consultants for helping with the implementation.
Another thing is to make a concept, this (depends on the configuration) scenario can become more complex than a simple cutover/staged migration.
One more thing we have to think about is the user license management in general. If we move mailboxes to the cloud side of a hybrid environment, we need at least an Exchange online plan 1 (Or plan 2 if you need to use UM. However, this is a different story).
We also need to plan who is going to stay on-premises and who goes to the online side. This is important if we think about delegations and send-as, send in behalf, and other options. This only works if both Users are on the same site.
About what we have to think by going the hybrid way?
This question we have answered in many ways earlier in this article. We already know the pros and cons. We also know what is needed and we have an overview, how things have to be configured.
Hybrid can be very complex, but it doesn’t have to! Try to keep it as simple as possible. It will make troubleshooting in the future and operating much more easier.
If the project allows, try to use the newest version of your Exchange on-premises environment (If possible, but you don’t need to upgrade just for the project). Also use the HCW for the configuration (or other third party tools), it will handle all things for you. Like it´s written in the previous chapter, we also need to watch out for cross-premises permission and plan accordingly.
What about hybrid Topologies?
There are tree hybrid topologies we can go with. In this chapter I want to give you just a short overview about them. I simply cannot be to objective with my opinion, because I always try to work with my personal slogan: “keep it simple, but significant”. However, I understand that we can’t choose the topology of the infrastructure we have to work with.
The most common topology is the one I have described in this article. This is of course my favorite, because we talk about single Exchange environment (not single server, but single fabric) and one Active Directory forest. In this case the planning and configuration of hybrid Exchange is straight forward.
Another topology is if we have a single Exchange environment but a multi Active Directory. The challenge we have here is that user can exist in more than just in one forest. This also means that the directory synchronization can be very challenging.
The most challenging topology we can go with is if we need to configure hybrid Exchange with a multi Exchange environment and a multi Active Directory infrastructure. In this case we have huge challenges with the identity management. One solution for that could be a good IAM tool which manages all identities and helps us to go with. Another challenge will be the Exchange deployment in our configuration. More about this topology you can find on the Microsoft Technet HERE.
Where are my Mailboxes located?
This question is just for mailboxes in the cloud (on exchange online). Microsoft has a bulk of data centers around the world. Our mailboxes are normally located “in the near from us”. But what does that means? Where exactly? Well, to figure out where, we can use a PowerShell script to find that out. The script which was written by Joe Palarchio you can find below. In the next picture you can see how the output looks like:
Looks nice, right? And here the PowerShell script:
######################################################################################################
# #
# Name: Get-MailboxLocations.ps1 #
# #
# Version: 2.1 #
# #
# Description: Determines the number of datacenters and locations where Exchange Online mailboxes #
# are distributed. #
# #
# Limitations: Table of datacenters is static and may need to be expanded as Microsoft brings #
# additional datacenters online. #
# #
# Assumptions: The original table of datacenters listed "Bay Area" which is assumed to be "San #
# Francisco, California, USA". Datacenter codes have been truncated to two characters #
# with the assumption that it designates the location. #
# #
# Usage: Additional information on the usage of this script can found at the following #
# blog post: http://blogs.perficient.com/microsoft/?p=30871 #
# #
# Requires: Remote PowerShell Connection to Exchange Online #
# #
# Author: Joe Palarchio #
# #
# Disclaimer: This script is provided AS IS without any support. Please test in a lab environment #
# prior to production use. #
# #
######################################################################################################
$Datacenter = @{}
$Datacenter["CP"]=@("LAM","Brazil")
$Datacenter["GR"]=@("LAM","Brazil")
$Datacenter["HK"]=@("APC","Hong Kong")
$Datacenter["SI"]=@("APC","Singapore")
$Datacenter["SG"]=@("APC","Singapore")
$Datacenter["KA"]=@("JPN","Japan")
$Datacenter["OS"]=@("JPN","Japan")
$Datacenter["TY"]=@("JPN","Japan")
$Datacenter["AM"]=@("EUR","Amsterdam, Netherlands")
$Datacenter["DB"]=@("EUR","Dublin, Ireland")
$Datacenter["HE"]=@("EUR","Finland")
$Datacenter["VI"]=@("EUR","Austria")
$Datacenter["BL"]=@("NAM","Virginia, USA")
$Datacenter["SN"]=@("NAM","San Antonio, Texas, USA")
$Datacenter["BN"]=@("NAM","Virginia, USA")
$Datacenter["DM"]=@("NAM","Des Moines, Iowa, USA")
$Datacenter["BY"]=@("NAM","San Francisco, California, USA")
$Datacenter["CY"]=@("NAM","Cheyenne, Wyoming, USA")
$Datacenter["CO"]=@("NAM","Quincy, Washington, USA")
$Datacenter["MW"]=@("NAM","Quincy, Washington, USA")
$Datacenter["CH"]=@("NAM","Chicago, Illinois, USA")
$Datacenter["ME"]=@("APC","Melbourne, Victoria, Australia")
$Datacenter["SY"]=@("APC","Sydney, New South Wales, Australia")
$Datacenter["KL"]=@("APC","Kuala Lumpur, Malaysia")
$Datacenter["PS"]=@("APC","Busan, South Korea")
$Datacenter["YQ"]=@("CAN","Quebec City, Canada")
$Datacenter["YT"]=@("CAN","Toronto, Canada")
$Datacenter["MM"]=@("GBR","Durham, England")
$Datacenter["LO"]=@("GBR","London, England")
Write-Host
Write-Host "Getting Mailbox Information..."
$Mailboxes = Get-Mailbox -ResultSize Unlimited | Where-Object {$_.RecipientTypeDetails -ne "DiscoveryMailbox"}
$ServerCount = ($Mailboxes | Group-Object {$_.ServerName}).count
$DatabaseCount = ($Mailboxes | Group-Object {$_.Database}).count
$Mailboxes = $Mailboxes | Group-Object {$_.ServerName.SubString(0,2)} | Select @{Name="Datacenter";Expression={$_.Name}}, Count
$Locations=@()
# Not pretty error handling but allows counts to add properly when a datacenter location could not be identified from the table
$E = $ErrorActionPreference
$ErrorActionPreference = "SilentlyContinue"
ForEach ($Mailbox in $Mailboxes) {
$Object = New-Object -TypeName PSObject
$Object | Add-Member -Name 'Datacenter' -MemberType NoteProperty -Value $Mailbox.Datacenter
$Object | Add-Member -Name 'Region' -MemberType NoteProperty -Value $Datacenter[$Mailbox.Datacenter][0]
$Object | Add-Member -Name 'Location' -MemberType NoteProperty -Value $Datacenter[$Mailbox.Datacenter][1]
$Object | Add-Member -Name 'Count' -MemberType NoteProperty -Value $Mailbox.Count
$Locations += $Object
}
$ErrorActionPreference = $E
$TotalMailboxes = ($Locations | Measure-Object Count -Sum).sum
$LocationsConsolidated = $Locations | Group-Object Location | ForEach {
New-Object PSObject -Property @{
Location = $_.Name
Mailboxes = ("{0,9:N0}" -f ($_.Group | Measure-Object Count -Sum).Sum)
}
} | Sort-Object Count -Descending
Write-Host
Write-Host -NoNewline "Your "
Write-Host -NoNewline ("{0:N0}" -f $TotalMailboxes) -ForegroundColor Yellow
Write-Host -NoNewline " mailboxes are spread across "
Write-Host -NoNewline ("{0:N0}" -f $DatabaseCount) -ForegroundColor Yellow
Write-Host -NoNewline " databases on "
Write-Host -NoNewline ("{0:N0}" -f $ServerCount) -ForegroundColor Yellow
Write-Host -NoNewline " servers in "
Write-Host -NoNewline ("{0:N0}" -f $Locations.Count) -ForegroundColor Yellow
Write-Host -NoNewline " datacenters in "
Write-Host -NoNewline ("{0:N0}" -f $LocationsConsolidated.Count) -ForegroundColor Yellow
Write-Host " geographical locations."
Write-Host
Write-Host "The distribution of mailboxes is shown below:"
$LocationsConsolidated | Select Location, Mailboxes
Summary:
Like everywhere there is no final key or the one and only right solution. From my point of view a hybrid environment makes sense if you want to start to use the cloud in general. It opens a lot of new features and doors for collaborations. The more mailboxes you have in the cloud, the less you need to think about storage, etc.
Microsoft takes care about the mailbox databases and DAG’s. When you compare the ECP in an on-premises and an Exchange online environment, you will notice, that on the Exchange online side you even don’t have the options of configuring databases and DAG’s.
However, as I have written in this article there can be always a reason not to move to the cloud or to run a hybrid environment.
It is up to you or your company management. If you have any additional questions about it, feel free to contact me across the contact form, by commenting this article or through my Telegram channel.