When you first install Exchange Server 2016 it is pre-configured with default URLs for the various HTTPS services such as OWA (Outlook on the web), ActiveSync (mobile device access), Exchange Web Services (the API used for a variety of client communications), and others.
The default URLs contain the fully qualified domain name of the server. So for example if your server name is “exchange01.domain.com” then the default URL for OWA will be “https://exchange01.domain.com/owa“.
These default URLs allow the services to function but they are not suitable for production deployments for several reasons such as:
- They are difficult for end users to remember (this primarily impacts Outlook on the web, where users tend to find it easier to remember a URL such as “webmail.domain.com“)
- A URL containing a specific server name can’t be load-balanced across multiple servers in a high availability deployment
- The internal AD namespace for many organizations is not a valid domain name on the internet, for example domain.local, which makes it impossible to acquire SSL certificates for Exchange 2016 (I’ll cover SSL certificates in a separate article coming soon)
The recommended practice is to change the URLs configured on your Exchange 2016 servers to aliases or generic host names such as “mail.domain.com” after you first install the server.
While there are a variety of namespace designs that apply to different deployment scenarios I will demonstrate here the simplest approach, which is to configure the same namespace (URL) for all services. I’ll be demonstrating with a single Exchange Server 2016 server, but this approach can also be used if you have multiple Exchange servers that you want to load balance (which I’ll cover in a future article).
In my example scenario:
- The server’s real name is demoex16.exchange2016demo.com
- The namespace I’ll be using is mail.exchange2016demo.com
- Internal and external namespaces will be the same
Using my GetExchangeURLs.ps1 script I can see the current configuration of the server.
PS C:\Scripts\> .\GetExchangeURLs.ps1 -Server DEMOEX16 ---------------------------------------- Querying DEMOEX16 ---------------------------------------- Outlook Anywhere - Internal: demoex16.exchange2016demo.com - External: demoex16.exchange2016demo.com Outlook Web App - Internal: https://demoex16.exchange2016demo.com/owa - External: Exchange Control Panel - Internal: https://demoex16.exchange2016demo.com/ecp - External: Offline Address Book - Internal: https://demoex16.exchange2016demo.com/OAB - External: Exchange Web Services - Internal: https://demoex16.exchange2016demo.com/EWS/Exchange.asmx - External: MAPI - Internal: https://demoex16.exchange2016demo.com/mapi - External: ActiveSync - Internal: https://demoex16.exchange2016demo.com/Microsoft-Server-ActiveSync - External: Autodiscover - Internal SCP: https://demoex16.exchange2016demo.com/Autodiscover/Autodiscover.xml Finished querying all servers specified.
In this article we’ll look at:
- Configuring DNS records for the new namespace
- Configuring the namespaces via the Exchange Admin Center
- Configuring the namespaces via PowerShell
- Using a PowerShell script to speed up the configuration of Client Access namespaces
Configuring DNS Records for the Client Access Namespaces
Before changing your server’s namespace configuration you should make sure that the DNS records for the new namespaces already exist in DNS. Some of the virtual directory configuration tasks can fail if the name you specify isn’t resolvable in DNS.
In this example scenario I’ll be using split DNS, which is a recommended practice for Exchange Server 2016 deployments. Split DNS means I will host a DNS zone on my internal DNS servers, and use that to resolve mail.exchange2016demo.com to the internal IP address of my Exchange server (or load balancer if this was a high availability deployment).
Meanwhile, the public DNS zone also has a mail.exchange2016demo.com record that resolves to the public IP address of my firewall or router, which will then NAT any external connections to the Exchange server’s internal IP.
Add the records to both of the zones in your split DNS configuration and make sure they are resolving correctly before you continue.
PS C:\> Resolve-DnsName mail.exchange2016demo.com Name Type TTL Section IPAddress ---- ---- --- ------- --------- mail.exchange2016demo.com A 3600 Answer 192.168.0.126
Configuring Exchange Server 2016 Namespaces Using the Exchange Admin Center
After logging in to the Exchange Admin Center in your organization navigate to Servers -> Virtual Directories and select the server you want to configure. There are two approaches you can take. The first is clicking the wrench icon to configure the external namespace for one or more servers.
A window appears that allows you to add one or more servers and specify an external namespace to use.
The outcome of this approach is that all of the external URLs are configured to use that namespace, but the internal URLs remain untouched. This is not ideal for our goal of configuring all services to use the same internal and external namespace.
Instead you can edit the configuration of each virtual directory listed in the Exchange Admin Center by clicking the edit icon.
From here you can edit both the internal and external namespaces for the virtual directory, as well as additional settings such as authentication.
This will achieve the desired outcome, but it is a slow and tedious task. For a single server it would be annoying, for multiple servers it would be downright frustrating. Also, if you ever needed to reconfigure the server you’d need to manually repeat the task.
Instead let’s look at using PowerShell to make the namespace configuration changes.
Configuring Exchange Server 2016 Namespaces Using PowerShell
In a previous article on avoiding server names in SSL certificates I demonstrate how to configure each virtual directory in Exchange Server using PowerShell. You can read that article for a full demonstration but in summary you can run cmdlets such as Set-OWAVirtualDirectory to configure the OWA virtual directory internal and external URLs. Each of the other virtual directories has its own cmdlet for configuring settings, including the Autodiscover virtual directory even though we don’t actually need to configure that one (instead we configure the AutodiscoverServiceInternalUri on the Client Access server).
For example, to configure the same URLs for OWA as shown in the screenshot above:
[PS] C:\>Get-OwaVirtualDirectory -Server DEMOEX16 | Set-OwaVirtualDirectory -InternalUrl https://mail.exchange2016demo.com/owa -ExternalUrl https://mail.exchange2016demo.com/owa
As with the Exchange Admin Center this task can become quite tedious as you move through each virtual directory on every server. But of course if the task can be performed in PowerShell it can be scripted!
Using a PowerShell Script to Configure Exchange Server 2016 Client Access Namespaces
Automating boring tasks is one of PowerShell’s great strengths, and this task is no different. Since every virtual directory (and the Autodiscover service URI) can be configured in PowerShell we can write a script to perform the task quickly.
In your own environment you could manually write out each of the PowerShell commands for your server names and simply save them in a script file. Or you can use my ConfigureExchangeURLs.ps1 script with a few easy to use parameters.
Here’s an example of how I can apply my desired namespace configuration to my Exchange 2016 server using ConfigureExchangeURLs.ps1.
PS C:\Scripts\> .\ConfigureExchangeURLs.ps1 -Server demoex16 -InternalURL mail.exchange2016demo.com -ExternalURL mail.exchange2016demo.com ---------------------------------------- Configuring demoex16 ---------------------------------------- Values: - Internal URL: mail.exchange2016demo.com - External URL: mail.exchange2016demo.com - Outlook Anywhere default authentication: NTLM - Outlook Anywhere internal SSL required: True - Outlook Anywhere external SSL required: True Configuring Outlook Anywhere URLs Configuring Outlook Web App URLs WARNING: You've changed the InternalURL or ExternalURL for the OWA virtual directory. Please make the same change for the ECP virtual directory in the same website. Configuring Exchange Control Panel URLs Configuring ActiveSync URLs Configuring Exchange Web Services URLs Configuring Offline Address Book URLs Configuring MAPI/HTTP URLs Configuring Autodiscover
Now let’s look at the output of GetExchangeURLs.ps1 again.
PS C:\Scripts\> .\GetExchangeURLs.ps1 -Server DEMOEX16 ---------------------------------------- Querying DEMOEX16 ---------------------------------------- Outlook Anywhere - Internal: mail.exchange2016demo.com - External: mail.exchange2016demo.com Outlook Web App - Internal: https://mail.exchange2016demo.com/owa - External: https://mail.exchange2016demo.com/owa Exchange Control Panel - Internal: https://mail.exchange2016demo.com/ecp - External: https://mail.exchange2016demo.com/ecp Offline Address Book - Internal: https://mail.exchange2016demo.com/OAB - External: https://mail.exchange2016demo.com/OAB Exchange Web Services - Internal: https://mail.exchange2016demo.com/EWS/Exchange.asmx - External: https://mail.exchange2016demo.com/EWS/Exchange.asmx MAPI - Internal: https://mail.exchange2016demo.com/mapi - External: https://mail.exchange2016demo.com/mapi ActiveSync - Internal: https://mail.exchange2016demo.com/Microsoft-Server-ActiveSync - External: https://mail.exchange2016demo.com/Microsoft-Server-ActiveSync Autodiscover - Internal SCP: https://mail.exchange2016demo.com/Autodiscover/Autodiscover.xml
Now that the namespaces are configured the next step is to configure an SSL certificate for the server. I’ll cover that in an upcoming article.
In this tutorial we looked at the default namespace configuration of a newly installed Exchange 2016 server, and discussed why we should configure Client Access namespaces for the server. As you can see there are several methods available for making the configuration changes, with the PowerShell script being the easiest by far. If it is your first time configuring a server it is worth doing the task manually the first time to gain some understanding of what is involved, but if you’re planning to deploy multiple servers then using a script such as ConfigureExchangeURLs.ps1 is highly recommended.