Exchange Server 2016 and Microsoft Cloud (Part 5)

If you would like to read the other parts in this article series please go to:

• Exchange Server 2016 and Microsoft Cloud – Deployment Guide (Part 1)
• Exchange Server 2016 and Microsoft Cloud – Deployment Guide (Part 2)
• Exchange Server 2016 and Microsoft Cloud – Deployment Guide (Part 3)
• Exchange Server 2016 and Microsoft Cloud – Deployment Guide (Part 4)
• Exchange Server 2016 and Microsoft Cloud (Part 6)
• Exchange Server 2016 and Microsoft Cloud (Part 7)
• Exchange Server 2016 and Microsoft Cloud (Part 8)
• Exchange Server 2016 and Microsoft Cloud (Part 9)

Introduction

So far in this series we built the domain controllers to support Exchange Server, after that we deployed the Exchange Servers, created high availability (DAG) at mailbox level, and also covered the components for high availability for the client access.

In this series, we are covering the deployment from scratch and because of that we will take a couple of additional steps related to the mail flow in Exchange Server. We will configure it to be as simple as possible and then we will be gradually increasing the complexity and integrating with Office 365.

In this article, we will be configuring the Firewall and prepare the Public DNS. In the second step we will configure all mail flow going straight to Exchange Server, and in the sequence we will move that flow to Office365/EOP (Exchange Online Protection). All those steps will provide enough guidance to the administrator to understand where his current environment is situated and how to move forward to the next level.

Configuring the Firewall…

Before working on the Public DNS, the administrator has to configure the Firewall to allow the traffic from the Internet to reach the Exchange Servers.

We will be starting with the scenario shown in Figure 01, and the first step is to discuss with the Firewall Administrator and assign a Public IP to be used by the Exchange Servers. Basically, we want all outbound traffic or at least SMTP traffic from Exchange Servers to be bound to the same Public IP when leaving the organization. A good security practice is to make sure that Exchange Servers are the only servers in the company to be able to connect on the port 25 on the Internet.

Now that we have a static Public IP reserved for Exchange outbound traffic (or at least SMTP), we must configure a reverse DNS for that IP. If you don’t have delegation of your reverse DNS, you can always contact your ISP and ask them to create one for you. In our scenario, we will be using smtp.infralab.org for that static Public IP that we defined in the previous step.

Figure 01

The next step is to allow incoming traffic from the Internet to the Exchange Server(s). In our scenario depicted in the figure above, we have a load balancer which makes it easier on the Firewall side, all services being published on the external side must communicate with the VIP (Virtual IP Address) of the Load Balancer which will balance the request among the healthy Exchange Servers. If a load balancer is not an option, then the administrator can try to load balance the internal request at the Firewall level, or a more manual approach is to use one Exchange Server, and if that fails, change the rule to publish the remaining server (this last option should never be used in production).

In the Firewall, we should use the same Public IP for the incoming traffic, this way we have consistency at the IP level for all Exchange Server(s) in any given site. These are the basic rules that should be enabled on the Firewall to support our current environment:

• Enable port 443 HTTPS (TCP) (you may want to enable 80 as well) to the Exchange Server(s)
  This rule will allow OWA, Outlook Anywhere and ActiveSync external end-points to communicate with Exchange Server
• Enable port 25 SMTP (TCP). This rule allows external SMTP servers to communicate with Exchange Server and deliver messages

At this point, we need to create the SPF record to guarantee to the Internet that we are properly informing which servers are able to send messages for our domain. The author favorite choice to create an SPF record is the Microsoft SPF Record Wizard, however it was not available during the time this article was written, so another good option is using the http://www.spfwizard.net site.

After having the SPF created based on your requirements, you are required to create a TXT record on your Public DNS. We will be creating that on Microsoft Azure DNS (we will go over the DNS configuration in the next section) and add the information as shown in Figure 02. After creating the records, a good way to test it is using MXToolbox.com, the site even allows to test the SPF record information.

Figure 02

We covered a lot of Firewall settings, and we also touched some of the DNS settings that will be added. Please, don’t worry about the DNS management, we will be covering those steps on the following article of this series.

In order to keep track of the changes required on either Firewall and Public DNS, the following table will summarize the basic steps and where it should be configured.

Mail flow having only on-premises environment…

The portion to receive messages will be configured on the Public DNS where the MX record will point out to the Public IP on the Firewall that is already expecting 25 SMTP traffic.

The only missing component is to configure outbound mail flow on the Exchange Server(s), and these steps can be used to accomplish such task.

1. Logged on the EAC as Exchange Administrator
2. Click on Mail flow and then Send Connectors
3. Click on Add (+)
4. In the Create a send connector page. Label the new send connector, and select Internet, click Next (Figure 03).

Figure 03

5. In the following page of the wizard, leave default settings (MX record associated with recipient domain) and click Next
6. In this page, click on + and on the new page, type * on the FullQualified Domain Name (FQDN) field, and click save. Back to the main page, the result should be similar to Figure 04.

Figure 04

7. In this page, add all Exchange Servers that will be able to send messages to the Internet, and then click on Finish.
   Note: It is really important that your firewall is configured to allow all servers that are listed on this page to send outbound messages using the pre-defined Public IP address.

Conclusion

In this article we went over the planning of external DNS servers (including SPF entry) and firewall configuration. In our next article of this series, we will be working on the fine tuning of the names that we planned at the beginning of this series on Exchange Server and Public DNS settings.

If you would like to read the other parts in this article series please go to:

• Exchange Server 2016 and Microsoft Cloud – Deployment Guide (Part 1)
• Exchange Server 2016 and Microsoft Cloud – Deployment Guide (Part 2)
• Exchange Server 2016 and Microsoft Cloud – Deployment Guide (Part 3)
• Exchange Server 2016 and Microsoft Cloud – Deployment Guide (Part 4)
• Exchange Server 2016 and Microsoft Cloud (Part 6)
• Exchange Server 2016 and Microsoft Cloud (Part 7)
• Exchange Server 2016 and Microsoft Cloud (Part 8)
• Exchange Server 2016 and Microsoft Cloud (Part 9)