Exchange Server 2016 and Microsoft Cloud – Deployment Guide (Part 1)

By /

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

Introduction

In this article series we are going to build from scratch a high available Exchange Server 2016 on-premises and then build a disaster recovery site. We will take advantage of Microsoft Azure and Office 365 and in this deployment we will use several technologies from Microsoft to build the environment. We will use several products in this article series, such as: Public DNS hosted in Microsoft Azure as SaaS, Exchange Online Protection (EOP), Microsoft Intune, Microsoft Azure IaaS, Azure Active Directory Connect, ADFS, and Office Online Server.

Several MSExchange.org authors (including myself) have written several step-by-step guides in some of the technologies that we will use in this series, and we will reference those MSExchange.org articles to provide more information for the reader as we go along, but the focus of this articles series is to help the administrator to build the Active Directory, Exchange Server 2016 and Microsoft Azure from scratch using the latest tools and features available.

The scenario – Introduction…

Our scenario will evolve as we move forward in the series, and we will be bringing it back several times throughout the series as the components start to emerge in our design. We will start simple (Figure 01) and we are going to add just the first two components that we will be working on in this first article which is the Active Directory.

Image
Figure 01

Step 01 – Building the Active Directory…

The first design question when building a new Active Directory domain/forest is the name that will be used by the new Active Directory. In an era before the Cloud Services/Office365, there were some documentation/recommendations to use an internal name when creating Active Directory, something like company.local. Nowadays the recommendation is to use a valid domain that is registered with the Internet Authority (infralab.org for example), and that helps in future merge/acquisitions where we know for a fact that the Active Directory names will not conflict.

If you are not sure about routable (infralab.org) or non-routable domains (company.local), we created a small list of situations and features and the impact of the name for our future design, as follows:

Features Non-routable domain

Infralab.local

 Routable domain

Infralab.org
UPN at Domain and Trusts Required a change for Office365 No changes required
Internal DNS (split DNS) It is a nice to have used when using Exchange Server 2016/Skype for Business and Public Certificates No changes required
Active Directory Users and UPN configuration All users must be configured to use the valid UPN No changes required
Default Domain in Exchange Server It should be removed since is not used. No changes required
Outlook Anywhere authentication The users should be instructed to use DOMAIN\username or [email protected].

Note: If UPN was configured using the routable domain, then it’s fine.

 No changes required
Azure Active Directory Connect All users must be using the new UPN otherwise synchronization errors will occur. No changes required

Table 1

What about if I already have a domain using non-routable domain, what should I do? Well, for starters you can always tweak your current domain to support routable domain and integrate with Azure, Office365 and Exchange. It will require more steps but it can be done, and that is definitely an option for existent Active Directory environments running non-routable domains.

A second method is renaming your Active Directory domain but it is really specific because it is not supported on pretty much all versions of Exchange Server (2000, 2007, 2010, 2013 and 2016) and the same for Office Communications Server (OCS)/Lync Server (2010 and Skype for Business Server. So if you are coming from a single domain without those products that could be an option.

Building the First Domain Controller…

We are going to build two Domain Controllers on this article, both will be running Windows Server 2012 R2 (Windows Server 2016 is almost there but not ready for production) and we will make sure that Windows Update was executed and both servers are up-to-date with patching.

The servers will have a static IP address and we will define the first server to use 10.60.99.205 and the secondary server to 10.60.99.206. On the DNS configuration at the network adapter level, we will configure both servers to use 10.60.99.205 as preferred DNS server and 10.60.99.206 as alternate DNS Server.

We can prepare a server to be a domain controller using either Server Manager or PowerShell, these following steps can be used to prepare the server using Server Manager, as follows:

  1. Logged as local administrator
  2. Open Server Manager, click on Manage and then Add Roles and features
  3. In the Before you begin page, just click Next
  4. In the Installation Type page, leave Role-based or feature-based installation and click Next
  5. In the Server Selection page, leave default settings and click Next
  6. In the Server Roles page, select Active Directory Domain Services (Figure 02) and on the new dialog box that will be displayed, click Add Features, and back to the wizard, just click Next

Image
Figure 02

  1. In the Features page, click Next
  2. In the AD DS page, click on Next
  3. In the Confirmation page, click on Install
  4. Wait the completion, and click on Close
  5. Restart the server

If you want to do the same thing using PowerShell, then you can type in Add-WindowsFeature ad-domain-services –IncludeManagementTools, as shown in Figure 03.

Image
Figure 03

After the server restarts, we need to continue the Domain Controller promotion by opening Server Manager and then click on the Alert icon and click on Promote this server to a domain controller (Figure 04).

Image
Figure 04

Deploying the Active Directory on the first server…

These steps must be performed only on the first domain controller, because that is the process to create a new Active Directory domain and forest.

  1. In the Deployment Configuration page. Select Add a new forest and define the domain name, in our article series it will be infralab.org (Figure 05)

Image
Figure 05

  1. In the Domain Controller Options page. Leave default settings, and type in the password for the Directory Services Restore Mode, and click Next
  2. In the DNS Options page. Leave default settings, and click Next
  3. In the Additional Options page. The NetBIOS domain name will be filled automatically, if there are no conflicts in the network the name should be the first word of the domain entered in the first page of this same wizard. In our article series the NetBIOS name is infralab. Click Next
  4. In the Paths page. Leave default settings and click Next
  5. In the Review Options page. A summary of all options chosen so far will be displayed, click Next
  6. In the Prerequisites check page. Validate any warnings and if there is nothing critical, click on Install
  7. The server will be restarted automatically as part of the process

Deploying an additional Domain Controller…

After the initial Active Directory deployment on the first server, all other Domain Controllers will follow the same process. We will repeat these steps described below when building the Disaster Recovery site as well.

  1. In the Deployment Configuration page. Select Add a domain controller to an existing domain (Item 1), then click on Change (Item 2) and provide the administrator credentials, and finally click on Select (Item 3) and select the domain from the list. Click Next to continue. (Figure 06)

Image
Figure 06

  1. In the Domain Controller Options page. Leave default settings, and type in the password for the Directory Services Restore Mode, and click Next
  2. In the DNS Options page. Leave default settings, and click Next
  3. In the Additional Options page. This page is different from the first Domain Controller, just leave default settings and click Next
  4. In the Paths page. Leave default settings and click Next
  5. In the Review Options page. A summary of all options chosen so far will be displayed, click Next
  6. In the Prerequisites check page. Validate any warnings and if there is nothing critical, click on Install
  7. The server will be restarted automatically as part of the process.

Additional recommendation/best practices related to Domain Controllers:

The goal of this article series is to build the infrastructure of our scenario and our focus will be in the key areas to get that up and running. In order to save real estate in the articles we will not document every page and details about recommendations and best practices around the technologies unless they are key for the proposed scenario.

However, we will try to list some key points where the administrator can look into to improve the service that has been just deployed. If we have enough hints at the end of this series, we may release an additional article with the step by step for all recommendations that we provided. Here are some of points that will

  • Configure DSRM (Directory Services Recovery Mode) using a domain account to keep consistency
  • Check replication and SYSVOL shares after building the domain controllers
  • Check replication on a daily basis to make sure that your Active Directory replication is healthy
  • Configure DNS to use root hints (keep in mind that those domain controllers will be the DNS servers for our future Exchange Servers) and by doing that the Forwarders tab at the DNS Server level should be empty
  • Configure Time Services to synchronize with an atomic clock
  • Configure Firewall rules to allow DNS and Time Services from both Domain Controllers
  • Configure a Central Store for Group Policy Administrative Templates

Conclusion

In this first article, we got an idea about the environment and technologies that we will be exploring in this series and from that point we start with the building blocks which is the Active Directory. In the next article of this series we will build the Exchange Server 2016 and configure the high availability components to support the main site.

Additional Information:

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

About The Author

Anderson Patricio is a Canadian MVP in Cloud and Datacenter Management, and Office Server and Services, besides of the Microsoft Award he also holds a Solutions Master (MCSM) in Exchange, CISSP and several other certifications. Anderson contributes to the Microsoft Community with articles, tutorials, blog posts, twitter, forums and book reviews. He is a regular contributor here at Techgenix.com, MSExchange.org, ITPROCentral.com and Anderson Patricio.org (Portuguese).

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top