This is the fourth part of the series "Exchange 2016 Hybrid Mode with Office 365". In this part, Exchange Hybrid Mode is activated and initial tests are carried out.
Here are the links to the previous articles:
Configuring the Exchange Hybrid Mode
The first steps for setting up Exchange Hybrid mode are quite unspectacular. In the local Exchange Admin Center, click on Configure under "Hybrid" and you will be prompted to log in to Office 365:
The login is done with the Office 365 Administrator account:
After logging in to Office 365, you will return to the Exchange Admin Center. Now click on "Configure" again:
The link now leads to the "Microsoft Office 365 Hybrid Configuration Wizard". The wizard must be downloaded and installed:
Once the installation is complete, the hybrid configuration wizard starts:
The first step is to specify the local Exchange server; in my test environment there is only one Exchange server, so the choice here is relatively simple:
In the next dialog, the login information for the local Exchange installation and Office 365 is requested:
The configuration data is now collected and after a short time you can continue by clicking on "Next":
Im nächsten Dialog wird „”Vollständige Hybridkonfiguration” ausgewählt:
The wizard now activates the trust relationship between Office 365 and the local Exchange installation:
The domain must also be validated for Office 365, here again a DNS TXT entry is required:
In my case, the entry is created at my host Strato. The TXT entry must be publicly resolvable:
You can then continue with the hybrid configuration wizard:
The wizard can automatically configure the local server for mail routing between Office 365 and the local Exchange installation. In this case, the send and receive connectors are configured by the wizard:
The corresponding Exchange server must be specified for the receive connector:
The same applies to the send connector:
The mail routing between the local Exchange server and Office 365 requires a certificate for encrypted transmission. I use the wildcard certificate here, which is also bound to the IIS service. In my environment, I have to make a few small adjustments later. More on this later:
In the last dialog, the public FQDN of the local Exchange server must be entered. In my test environment, this is outlook.frankysweb.org:
Note: This is about mail routing between Office 365 and the local Exchange environment. The wizard basically asks for the MX record for the domain frankysweb.org. The background is as follows: In a hybrid configuration, for example, the email address abc@frankysweb.org can belong to an Office 365 mailbox and the email address xyz@frankysweb.org to a mailbox on the local Exchange server. If abc@frankyweb.org now writes a mail to xyz@frankysweb.org, Office 365 must know the local Exchange server or the responsible mail server to which the mail is to be forwarded. The same applies in the other direction.
In the last step, click on "Refresh" again:
The wizard now configures Office 365 and the local Exchange environment according to the settings:
After a short time, the desired result will appear:
Customization Office 365 / Exchange Mail Routing
As already briefly mentioned, I still need to make a few small adjustments to the configuration for my test environment. In my test environment, the Sophos UTM acts as a SPAM filter. However, I also use the UTM for my private environment and only have a certificate for frankysweb.de for the UTM and the SPAM filter, but not for frankysweb.org. In this case, however, there is a problem with the Office 365 connector. In the default setting, the Office 365 connector only transmits the mails if the certificate also contains the corresponding entry. In my case, frankysweb.org is therefore required on the certificate.
However, the setting can be adjusted by accessing the Exchange Online Admin Portal:
The "Connectors" tab can be found under "Message flow". Here you will find the "Outbound to ..." connector:
This connector routes mails between Office 365 and the local server, but only if the certificate is valid. In my case, there is a mismatch here:
I have therefore adjusted the settings of the connector so that all certificates are accepted:
This means that mail routing in my test environment also works perfectly (I created an SMTP profile on the UTM for this purpose, which forwards mails to frankysweb.org to the test environment).
First tests
In order to test the interaction of the local Exchange server with Office 365, a mailbox hosted in Office 365 is of course also required. Office 365 mailboxes can now be conveniently created via the local Exchange Admin Center:
As with a local user, the relevant information must be entered. The user account is created in the local Active Directory and synchronized to Azure AD using Azure AD Ccnnect:
Office 365 mailboxes can also be managed via the local Exchange Admin Center:
A license must now be assigned to the new user in the Office 365 portal:
After a license has been assigned, the login with the new user can be tested on the Office 365 portal:
I test OWA first:
A test message from an external recipient arrives in the Office 365 mailbox. The mail is routed to Office 365 via the local Exchange server:
Another test from Office 365 to a local mailbox, the address book query is already working:
And here again the path from a local mailbox to Office 365:
All mails were successfully delivered, so the first tests were successful.
In the next article, we'll get down to the nitty-gritty: e-mail routing, free/busy information, address books, migration.