Tag Archives: free/busy

Exchange Resource Forest and Exchange Hybrid – Part III

In my previous two blogposts I’ve explained more about the Exchange Resource Forest model and how to implement Azure AD Connect into such an environment. In this blogpost I’ll show you more about creating a hybrid environment with an Exchange Resource Forest model.

Exchange 2010 Hybrid

If you have been following my blog, or maybe my work as a consultant you most likely know I’m not a big fan of installing Exchange 2016 into an existing Exchange 2010 environment when creating a hybrid environment. It adds a lot of additional complexity since you are halfway a migration to Exchange 2016, you need network and client access changes and most likely hit users multiple times. Better is to create an Exchange 2010 hybrid scenario and when the migration to Exchange Online is done, upgrade the Exchange 2010 remains to Exchange 2016.

My Resource Forest environment is built on Exchange 2010 (that’s what most of my customers are still running) and I will create another Exchange 2010 hybrid environment, but this time built on the Exchange Resource Forest. The solution will look something like this:


The only more challenging part is the use of an Edge Transport server for inbound and outbound SMTP, but if your SSL certificates are ok, you’re good to go. In our example, the Edge Transport server is used for inbound and outbound SMTP, but the hybrid SMTP will be sent directly from Exchange Online to the Exchange 2010 multi-role server. Centralized Mail Transport will be used, so all mail will always go via the Edge Transport server, even outbound mail from Exchange Online.

Note. Before you continue, you have to make sure that your certificates are ok, that a valid 3rd party certificate is used and bound to IIS and SMTP, and that your load balancer is configured correctly. A common pitfall is that address translation occurs, and that all inbound connections originate from the IP address of the load balancer. In this case inbound SMTP ends up on the wrong connector, causing secure traffic between Exchange 2010 and Exchange Online to fail.

Logon to the Exchange 2010 server and download the Hybrid Configuration Wizard at https://aka.ms/TAPHCW and start the wizard by clicking the Install button.

Click the Next button a couple of times, the wizard will detect the optimal Exchange server to be used to create the hybrid configuration (this is the server where the hybrid configuration wizard is running, and is known as the ‘hybrid server’) and logon to the Office 365 tenant using a tenant administrator account as shown in the following figure:


Continue with the wizard, select Full Hybrid (or minimal hybrid if you need to), and create a federation trust (and enter this crazy TXT record in public DNS). When you reach the radio button for Configure my Client Access and Mailbox server window, you can select the enable centralized mail transport checkbox if you want to.


Select the Hub Transport server (or Mailbox server when running Exchange 2013 or Exchange 2016) that should be used for secure communication with Exchange Online. This server is configured in an Office 365 Send Connector and a Receive Connector from Office 365 is created on this server.


Select a proper certificate (which should already be present on the Exchange server of course), enter the Organization FQDN that’s used to access your on-premises environment (i.e. webmail.exchangefun.nl) and you’re ready to finalize the hybrid configuration wizard. The options you’ve selected in the wizard are now pushed to the Exchange server and Active Directory when you click the update button.


And after a minute or two the Hybrid Configuration Wizard should be finished, and of course no warning message should be shown:


We’ve now configured a hybrid configuration with an on-premises Exchange 2010 server that’s in a Resource Forest.

Move Mailbox

An easy way to test the new hybrid configuration is to test a mailbox move from Exchange 2010 on-premises to Exchange Online. To do so, logon to the Exchange (Online) Admin Center, go to Recipients | Migration and start a new migration batch. Select move to Exchange Online and select a user to move to Exchange Online as shown in the following figure:


Enter the on-premises administrator account to find a proper migration endpoint (through Autodiscover):


It will automatically detect and show the migration endpoint on the Exchange 2010 server:


Click Next to continue, enter a migration batch name, increase the bad item and large item limit if needed and follow the wizard. The migration batch is automatically started, but manually completed. I typically complete migration batches off business hours, but for a test or lab environment you can safely select to complete the batch automatically. When you click the new button a new migration batch is created, and the mailbox move is automatically initiated. When the mailbox is moved to Exchange Online you can logon to Office 365 and start testing.


The first test is to see if mail flows between Exchange 2010 on-premises to Exchange Online. In the previous figure the mailbox ‘Jaap Wesselius [Linked]’ is a mailbox that was not migrated, so this works fine. Checking the header of this message reveals the same:


The figure might be a bit blurry, but in the last column we can see that TLS 1.2 is used for communications between Exchange Online and Exchange 2010.

Sending from Gmail to the mailbox in Exchange Online reveals that Gmail sends the message to the Edge Transport server, which sends in to the Exchange 2010 server and to Exchange Online:


Inbound messaging is working as well. When mail is sent from Exchange Online to Gmail, we can see in the headers that mail goes from Exchange Online to the Exchange 2010 server, to the Edge Transport server and to Gmail.


Another important topic to test is free/busy information between Exchange 2010 and Exchange Online. When an on-premises mailbox wants to schedule a meeting with two migrated mailboxes in Exchange Online the following should be visible:


The Exchange 2010 server will contact Exchange Online using Exchange Web Services (EWS) to check the availability for the users Don and Duw.

Vice versa, when user Don wants to schedule a meeting the following should be visible:


The server in Exchange Online now contacts the Exchange 2010 server (via the load balancer) using EWS to check the availability of the on-premises mailboxes.

It happens a lot that availability information or free/busy information in the on-premises environment is not available. This can be an Autodiscover issue, a certificate issue or a pre-authentication issue in the load balancer. Enough stuff to troubleshoot in this case.

If free/busy is working properly, cross-premises Mail Tips are most likely working as well since this is also using EWS:


So, it looks like everything is working as expected.


In this blog post and the previous two blog posts I’ve explained more about the Exchange Resource Forest model, how linked mailboxes are related to their corresponding accounts, how to implement Azure AD Connect in a Resource Forest environment and how to setup a hybrid environment in this model.

This was built on top of Exchange 2010 but is very similar for Exchange 2013 or Exchange 2016. If all prerequisites are met it doesn’t make any difference if you’re running a single forest environment with Exchange installed or a Resource Forest model.

Since the Resource Forest is a fully supported scenario by Microsoft, the hybrid environment in a Resource Forest is fully supported as well.

Creating an Exchange 2013 Hybrid environment

Updated: November 11, 2015

In a series of blog posts we will create an Exchange hybrid environment, where the on-premises environment consists of Exchange 2013 multi-role servers. Creating such an environment consists of several steps:

  • Implementing Directory Synchronization.
  • Running the Hybrid Configuration Wizard.
  • Creating Migration Endpoints.
  • Moving Mailboxes to Exchange Online.

Current Infrastructure

The current infrastructure consists of two Exchange 2013 multi-role servers and two Exchange 2013 Edge Transport servers, all of which are fully patched and running the latest version of Exchange 2013 (i.e. Exchange 2013 CU8). An Office Web Apps 2013 servers is also involved for rendering attachments in Outlook Web App.

A Kemp LM3600 LoadMaster is used for distributing incoming client requests from the Internet across both servers. SMTP is directed to two Exchange 2013 Edge Transport servers, which are subscribed to the internal Exchange 2013 servers, as shown in Figure 1.


Figure 1. The starting point when creating a new Hybrid environment.

In Office 365 we have are using a tenant called ExchangeLabsNL, for Exchange Online the tenant name is not important, but for SharePoint Online it is important. The corresponding SharePoint Online environment is accessible via Exchangelabs.nl.sharepoint.com, so the tenant name is important after all.

Note. The tenant name cannot be changed later on, so don’t choose any silly names for your tenant. One day you will regret this.

Directory Synchronization Server

In our on-premises environment we are going to install a dedicated Directory Synchronization server. This is not really a hard requirement since DirSync can be installed on a Domain Controller as well. Personally I prefer to use a dedicated DirSync server and keep all Domain Controllers identical.

Exchange Hybrid Server

There’s a lot of confusion about the Exchange Hybrid server when creating an Exchange Hybrid environment and to be honest, it took quite some time for me as well to get rid of the confusion.

A true hybrid server does not exist, but in Microsoft terminology, the hybrid server is the Exchange server where the Hybrid Configuration Wizard (or HCW) is run to configure a Hybrid Configuration. And the Hybrid Configuration is nothing more than some information written in Active Directory so it can be easily found and used by all Exchange servers in the organization. In Figure 1, the hybrid server can be either server EXCH01 or server EXCH02.

An additional Exchange 2013 server can be added as a hybrid server. You can even use a dedicated FQDN like hybrid.contoso.com for this to separate SMTP and migration traffic from/to Office 365 form regular client traffic accessing the normal Exchange servers EXCH01 and EXCH02.

Free/busy information in this scenario for example is not using the dedicated hybrid server, since it is not possible to designate this kind of traffic to dedicated servers. When users in Exchange Online are creating new meetings with users in Exchange on-premises, the free/busy information is found using the normal Exchange EWS virtual directory. This information in turn is found using normal Autodiscover requests.

So, before you start building your Exchange Hybrid environment you have to make absolutely sure your starting point is working flawlessly, internally and externally. If you run into issues with AutoDiscover, free/busy, out-of-office or Certificate errors you have to fix these first before continuing with the hybrid configuration. One great tool to test your existing environment is the Remote Connectivity Analyzer (www.testexchangeconnectivity.com) and of course your own Outlook clients Glimlach 

Note. If you are running Exchange 2010 you can also use the existing Exchange 2010 servers to create a hybrid environment without adding Exchange 2013 servers (although you have to be absolutely sure about this, Exchange 2010 is no longer in mainstream support). If you want to use Exchange 2013 in your existing Exchange 2010 environment you have to start a coexistence project first. When this is fully functioning (without error of course) you can continue with the DirSync and hybrid configuration.

When all is running fine you can continue with implementing the DirSync solution, as outlined in the following blogpost: https://jaapwesselius.com/2015/05/13/implementing-directory-synchronization/

Disabled Outlook Anywhere causing free/busy issues

I am always amazed by the amount of customers running Exchange 2007 or Exchange 2010 and NOT using Autodiscover. Their response is always “we don’t need it” and “we configure the Outlook profile manually”. In Exchange 2007 and Exchange 2010 you can get away with this (you cannot with Exchange 2013 and Autodiscover is mandatory) but when you want to implement a hybrid scenario with Exchange online you really need Autodiscover since Exchange Online uses Autodiscover to find relevant information regarding your on-premises Exchange environment.

Recently a customer with Exchange 2010 wanted to build a hybrid environment with Exchange Online, and one of my first findings was the lack of Autodiscover. So, after configuring their Exchange environment and creating the necessary DNS records Autodiscover was working properly as shown in the following picture:


Continue reading Disabled Outlook Anywhere causing free/busy issues