Exchange Server 2016 and Microsoft Cloud (Part 6)

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 5)
• Exchange Server 2016 and Microsoft Cloud (Part 7)
• Exchange Server 2016 and Microsoft Cloud (Part 8)
• Exchange Server 2016 and Microsoft Cloud (Part 9)

Adjusting Exchange Server to use the new DNS Names…

In the third article of this series we defined the names that we would add on the Public Certificate, however we still need to configure Exchange and its web services to use those names, and by doing that we ensure that all communication between end-users and Exchange service will be using those names.

These are the names that are being used on our current scenario and their main purpose, as follows:

• Autodiscover.infralab.org: will be used by Outlook and ActiveSync clients to locate the services and profile automatic configuration
• Smtp.infralab.org: will be used to all SMTP traffic
• Webmail.infralab.org : will be used for ActiveSync, Outlook Anywhere and Outlook Web Access for external clients.

The first step is to configure the external access URL on the Exchange Servers that will be facing the Internet. All communication from external clients will use that name to communicate with Exchange Server. Here are the main steps to configure the external access URL:

1. Logged on Exchange Admin Center (EAC)
2. Click on Servers and then Virtual Directories
3. Click on the second icon from left to right which is configure external access domain
4. In the new page, add the servers and configure the external name which is webmail.infralab.org, and click on save and then close, as shown in Figure 01.

Figure 01

We configured the external URLs using the previous wizard, and the second step is to configure the Internal URL to match the same name (we are keeping it simple and using split-brain DNS to redirect the user to the server using either Public IP for external clients, or internal IPs for the internal clients). The process to configure the internal URLs is as follows:

1. Logged on Exchange Admin Center (EAC)
2. Click on Servers, and then on virtual directories
3. For each server of the site configure the Internal URL to be the same as External URL for the following virtual directories (EWA, OWA, ECP, Microsoft-Server-ActiveSync, and OAB), as shown in Figure 02.
4. Click save

Figure 02

The final step is to configure the Outlook Anywhere, we have to repeat this configuration on each server within the same site to guarantee consistency. Here are the required steps to perform this procedure:

1. Logged on the Exchange Admin Center (EAC)
2. Click on servers
3. Double click on the server object, and then click on Outlook Anywhere
4. We will use the same name (webmail.infralab.org) for internal and external users as shown in Figure 03.
5. Click on save and repeat the same process on all servers of the same site

Figure 03

Microsoft Azure DNS…

In order to receive e-mail from the Internet and allow end-users to connect to the Exchange Services through webmail, Outlook Anywhere and ActiveSync devices, the external DNS must be configured. In this article series we will be using the power of Microsoft Azure to host our Public DNS.

The first step is to sign up at Microsoft Azure, and it can be easily done using https://azure.microsoft.com portal. After creating your account, the initial page of the Microsoft Azure portal will be similar to Figure 04.

Figure 04

In order to create a Public DNS, we will be creating a Resource Groups, click on Resource Groups item on the left side, and on the new blade click on Add. A new blade will be displayed (Figure 05), define the name of the Resource Group, subscription and location, and then click on create.

Figure 05

After creating the Resource Group, click on it, and then Add a new blade with a search field will be displayed, type in dns and hit enter. In the results, click on DNS (preview), a new blade containing the description of the service will show up (make sure that the publisher is Microsoft), click on Create.

In the new blade (Figure 06), type in the DNS Zone name, in our series we will use infralab.org, select the subscription, and select Use existing for Resource Group and define the Resource Group that we have just created in the previous step.

Figure 06

The new zone created in Microsoft Azure is not available on the Internet at this point. We need to open the Resource Group (in our series is PublicDNS) and a list of all zones will be shown (Figure 07). Click on the zone (infralab.org) and copy the Name Servers located on the right side (if you hover the mouse over, there is a copy button).

Figure 07

Until now all the changes performed in Microsoft Azure were local and it was not impacting the actual public domain. In order to switch over from the current Public DNS to Microsoft Azure, the Nameservers on the Internet Registrar must be configured to use the ones provided by Microsoft Azure.

We are using a common Internet Registrar for this series (Figure 08), and we will be editing the infralab.org zone on their web interface. We are configuring custom nameservers to our domain (infralab.org). Keep in mind that after this change all the information that is configured/defined in Microsoft Azure DNS will be live. It is highly recommended to make sure that all entries are created in Microsoft Azure before switching over.

Figure 08

The final result on the Microsoft Azure DNS should be similar to Figure 09.

Figure 09

Conclusion

In this article, we covered the required steps to build the Public DNS in Microsoft Azure and the required DNS entries to match the already planned names that Exchange Services are using. In order to make the consistency, we also configured Exchange Server(s) to use the same names to support Exchange Web Services and Outlook Anywhere.

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 5)
• Exchange Server 2016 and Microsoft Cloud (Part 7)
• Exchange Server 2016 and Microsoft Cloud (Part 8)
• Exchange Server 2016 and Microsoft Cloud (Part 9)