Exchange Tutorials

In the fourth part of our Exchange lab series we:

• Discussed the importance of a correctly configured namespace
• Configured URLs via Exchange Admin Center (EAC)
• Configured URLs via PowerShell
• Configured split DNS

In the fifth part of our Exchange lab series we:

• Generate a certificate request
• Process a certificate request
• Complete a certificate request
• Assign services to a certificate
• Check our work

Let’s get started.

Generate a Certificate Request

In the last part of our series, we got our namespace configured. Now we need to make sure we have a certificate for that namespace.

Note: Adding a certificate to your lab is optional. Whether you choose to go with a certificate really depends on how close to a production experience you want to be. You can always purchase a certificate for your lab and import it into production later on. If a certificate is not critical for your lab experience you may still wish to review this section in preparation for production.

Log in to the Exchange Admin Center (EAC). Select the Servers tab and Certificates sub-tab.

This page displays all currently installed Exchange certificates. These three self-signed certificates are installed with Exchange out of the box. The self-signed certificate titled “Microsoft Exchange” is the one that Exchange is currently using for all of its web services. That’s the one that we will replace with a trusted 3rd party certificate.

Like its predecessor, Exchange 2016 maintains the Certificate Request Wizard. This wizard takes all the guesswork out of generating a certificate request.

To launch the wizard click the New () button.

In the New Exchange Certificate wizard select Create a request for a certificate from a certification authority. Click Next.

In the third part of our Exchange lab series we:

• Installed Exchange 2016 with the graphical setup
• Installed Exchange 2016 with the command line

In the fourth part of our Exchange lab series we:

• Discuss the importance of a correctly configured namespace
• Configure URLs via Exchange Admin Center (EAC)
• Configure URLs via PowerShell
• Configure Split-DNS

Let’s get started!

Note: For instructions on previous versions of Exchange check the following articles:
Designing a simple namespace for Exchange 2013
Designing a simple namespace for Exchange 2010

What’s in a namespace?

A namespace is critically important.

Not only does namespace govern the availability of services like Outlook Web App, or, ActiveSync, but it also governs items such as the distribution of the Offline Address Book, or, Autodiscover. In addition–beginning with Exchange 2013 and continued with 2016–all client requests are made over HTTPS versus straight TCP/IP. This means Outlook Anywhere now manages Outlook connectivity internally as well as externally.

It is imperative we correctly configure our URLs and apply a certificate containing those URLs. Otherwise, our clients won’t be able to establish the necessary SSL connections. Which will lead to all sorts of problems.

Out of the box, Exchange configures its internal URLs to match its internal hostname. It leaves its external URLs blank. Due to recent restrictions, third-party certificate providers no longer allow internal hostnames on certificates. An example of an internal hostname would be anything that ends .LOCAL or .PRIV. In short, it is any top-level domain that is not routable on the internet.

The challenge? If our internal hostnames cannot be found on our certificate it will give our test users a variety of security warnings. This makes it difficult to use internal hostnames with Exchange.

The simplest solution? Don’t use internal hostnames. Instead, use only external hostnames. We will use the same external hostname for both our internal and external URLs. Our URLs for each service will be as follows:

That solves our certificate problem. But how does that work with DNS?

We do this by way of split-DNS. Split-DNS allows us to use the same URLs internally as we do externally. Split-DNS is a non-authoritative copy of our external DNS hosted internally. This non-authoritative copy uses the internal IPs of our servers (versus the public IPs the authoritative copy is using).

For example, our external DNS provider will resolve webmail.exchangeservergeek.com to 71.72.221.140. Whereas internally our own DNS server would resolve webmail.exchangeservergeek.com to 192.168.10.13, which is the internal IP of EX16-01. Depending on which side of the firewall our test user sits will determine which IP they receive.

The need for split-DNS is to keep our local traffic on the local LAN. Without split-DNS, all local traffic would go out the firewall for name resolution only to try and come back in later with the public IP of Exchange. Not only is this an unnecessary detour for your internal clients–plus the unnecessary consumption of internet bandwidth–but most firewalls will block this kind of behavior deeming it suspicious.

In part one of our Exchange 2016 lab series we:

• Explored the options for building an Exchange lab
• Reviewed the requirements for Exchange 2016
• Built the Exchange 2016 virtual machine
• Installed the base operating system with all updates

In the second part of our Exchange lab series we will:

• Install Exchange 2016 mailbox server prerequisites
• Extend the Active Directory schema for Exchange 2016

Let’s get started!

Exchange 2016 Mailbox Server Prerequisites

First, let’s get the operating system core components installed. To do this open a PowerShell console as the administrator.

Then issue the following command.

Update: If using Windows Server 2016, drop the AS-HTTP-Activation component from the command.

 C:\> Install-WindowsFeature AS-HTTP-Activation, Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

This command may seem like a lot but in essence, it can be grouped into 4 sets of components being installed.

• .NET 4.5 support
• Internet Information Service (IIS)
• Windows Failover Clustering