Why you should run your Exchange hybrid
Interview with our IT expert Mathias.
System administrators and IT professionals are faced with a pressing question: on-premise or cloud? Both options offer clear advantages - independence and cost control versus flexibility and scalability. At JAM we have found a clear answer: Hybrid is the solution!
But how do you integrate this concept into the email server infrastructure? Our IT team has found answers and solutions. Today, our reporter Jens talks to our sysadmin Mathias about how we overcame the challenges.
- Our challenges with the old email system
- Changeover requirements and goals
- Using the Exchange Server Toolbox and Criteria-Based Routing
- Recommendations for readers
Jens: Hey Mathias! Thanks for taking the time! Can you please give us a brief overview of our previous email system to get us started? What challenges did we face?
Mathias: Hi Jens! Sure, no problem! Before going hybrid, our mail flow ran through our firewall, which routed the incoming mails via NAT rule to an edge server in the DMZ, in our case an hMail VM.
The hMail VM also ran the first instance of our Exchange Server Toolbox with a virus and spam check for incoming emails.
Afterwards, the emails were routed back to the firewall, where they were again checked for malicious code.
Finally, the emails were routed to our Exchange Server, on which another instance of the Exchange Server Toolbox was running.
Here, the emails were also archived in compliance with the law and automatically checked for spam and viruses.
Jens: What technological limitations or challenges did we have in the existing system that made a revision necessary?
Mathias: The complexity of the mail flow described above was a challenge. There were many things to consider, and even the smallest changes could restrict the mail flow.
In addition, employees had to be able to connect to our Exchange Server cleanly and with as little effort as possible from outside our company network - at least since the pandemic.
In this day and age, it was also a challenge to release and secure an Exchange Server to the outside world, as Exchange Servers have increasingly come into the crosshairs of hackers in recent years.
Jens: Could you please outline the main requirements and goals you wanted to achieve when implementing Exchange Hybrid?
Mathias: In the future, authentication should no longer go through our firewall, but take place directly in the cloud in order to exploit the security and analysis options implemented by Microsoft.
The aim was to increase the security of the company network and to simplify the login process for users.
In addition, in the long term, the MX records are to be converted to Exchange Online so that, among other things, the mail flow continues to function even if all our WAN lines in the company building are offline.
Jens: What technical challenges did you encounter when setting up the Hybrid Configuration Wizard (HCW) and the "Centralized Mail Transport" function?
Mathias: Hybrid operation has been possible since 2016. Over the years, a large number of documentations from Microsoft or other administrators have accumulated on the internet, and none of them ever fit 100% to your own requirements and wishes.
Microsoft has not set itself the goal of making hybrid operation as easy as possible for customers. Here you can already see that Microsoft would prefer to switch completely to Exchange Online.
A major challenge for hybrid operation and error-free configuration with the Hybrid Configuration Wizard is the configuration of one's own firewall(s).
The basic prerequisite for the configuration of the "Centralized Mail Transport" is that Exchange Online can communicate with the Exchange Server in its own environment without detours, e.g. through a WAF (Web Application Firewall or Reverse Proxy).
Jens: Centralized Mail Transport also has limitations. To get around these, you used Criteria-Based Routing (CBR). Could you explain in more detail how CBR works in your implementation, and what advantages it offers?
Mathias: In a recommended scenario from Microsoft, where the MX record points to Exchange Online, incoming emails must be routed via the on-premises DLP, encryption and journaling solution before they are delivered to Exchange Online.
To ensure that outgoing messages sent from Exchange Online to the Internet are also processed via the on-premises Exchange and thus the Exchange Server Toolbox, there is Centralized Mail Transport (CMT).
This makes it possible to route all messages from Exchange Online mailboxes through Exchange On-Premise before they are delivered to the Internet.
However, CMT has some limitations, e.g. when sending from mailboxes on the local Exchange Server or when sending emails between two cloud mailboxes.
This is where Criteria-Based Routing comes into play. With this, the route an email takes can be forced, and thus the above-mentioned restrictions can be solved.
Jens: How did the Exchange Server Toolbox influence the entire email traffic and archiving process?
Mathias: As a practical plug-in for the Exchange Server, the Exchange Server Toolbox made it easy for us to ensure compliance despite the use of Exchange Online.
We just had to make sure that all incoming and outgoing emails went through the Exchange Server Toolbox once.
Jens: Finally, do you have any recommendations for further resources or best practices for someone who is planning a similar implementation?
Mathias: Yes, with pleasure!
On the topic of criteria-based routing, I can recommend a good article from the Microsoft Tech Community in which criteria-based routing is "demystified".
If something doesn't work as expected, there are also some suggestions for troubleshooting here that are very helpful.
Jens: Thank you very much for the tips at the end and of course for the interview, Mathias!
Mathias: You're welcome!