Keeping names simple within Exchange Server can be tricky. Often organizations provide external access to services like Outlook Web App and Exchange ActiveSync using their registered domain names, whilst internally use a different domain that’s not valid on the public internet.
With an ever mobile workforce, you’ll also find that you users have a variety of ways to access email, expect wireless access on the mobile devices they’ve been issued with and having different internal and external URLs for Exchange Services not only confuses users, but can also cause technical issues when the external address isn’t accessible from the LAN or needs to traverse proxy servers.
There’s also another reason why organizations need to consider using their real domain name for Exchange services internally as well as externally. The CA/Browser forum, which is a collaboration between Certificate Authorities and developers of Web Browsers has introduced new standards for certificate issuance, stating that no certificate will be issued with an invalid top-level-domain expiring after November the 1st, 2015.
That means right now, it’s no longer possible to buy a three-year certificate with a .local name within it; so if you’re currently planning an Exchange implementation, you probably don’t want to have to make changes to the design after implementation. If you’re already managing an Exchange implementation that uses invalid TLDs and third-party certificates then you’ll need to start thinking about solutions.
One great solution to all these issues is to simplify your Exchange organization and use the same names both internally and externally in your internet-facing sites. That way, you don’t need to consider how you’ll implement different certificates internally and externally, and your end users get the simplicity of only needing to know a single name for your web facing Exchange services.
Often this is implemented using Split DNS. This means as well as having your external DNS zone for your organization, with the associated external records for Exchange and all your other external-facing DNS records, you create an internal copy of the DNS zone substituting the IP addresses for Exchange with the internal DNS records.
Figure 1: Example of a typical Split-DNS implementation
The downside of Split DNS is that on an on-going basis you need to maintain two sets of DNS records for your organization’s domain name, so any change you make to the external DNS zone such as changing web hosting providers, needs to be implemented internally. If you’ve got a large number of externally facing services then the on-going management of the zones can be troublesome.
PinPoint DNS Zones are an alternative technique that’s very similar to Split DNS, but significantly simplifies the amount of administrative effort needed to maintain records, and is simpler to setup too.
A PinPoint DNS zone is what is says on the tin. We’re pinpointing just the DNS records that will be different to the external zone, such as mail.exchangelabs.co.uk and autodiscover.exchangelabs.co.uk by creating a zone for each. The rest of the DNS records remain unchanged and are referenced from the external, real, master DNS zone:
Figure 2: A typical example of PinPoint DNS
The way this works is that internal clients perform a DNS lookup for a record for an Exchange URL, and the internal DNS is checked first. As a pinpoint zone exists for these records, the local AD-integrated DNS responds with the internal IP address. A query for other DNS records, such as the public website for the organization continue to be served by the existing external DNS infrastructure.
Implementing PinPoint Zones
The most logical place to implement PinPoint DNS zones is on your Active Directory integrated DNS servers, as the internal clients we’re targeting will usually be configured to use these for DNS name resolution.
Based on our diagram above, we’ll need to add to zones, names as follows, both with an “A” record pointing at our internal IP:
Using the GUI to add PinPoint DNS Zones
First let’s look at how to add PinPoint zones using the Windows DNS Manager. Unless you’ve already added extra zones, opening Windows DNS manager on a domain controller should show your internal Active Directory domain namespace:
Figure 3: Active Directory Integrated DNS
We’ll then add our two zones, one by one, creating two DNS zones each with the name of the HTTPS namespace we’re “pin pointing”. To create a new zone, right click Forward Lookup Zones and choose New Zone, then create a new zone with the following options:
- Type of Zone: Primary Zone, Stored in Active Directory
- AD Zone Replication Scope: Depending on your AD environment, you may want to choose Forest or Domain. For smaller environments either will be fine, and for larger environments where multiple domains within the forest use Exchange, choose Forest.
- Zone Name: Enter the first of your PinPoint zones names, for example mail.exchangelabs.co.uk.
- Dynamic Updates: You typically won’t need dynamic updates for this zone.
You’ll see the first one, mail.exchangelabs.co.uk below:
Figure 4: Empty PinPoint DNS Zone
Next, we’ll navigate to the new zone and create a new record. It’s important that we leave the hostname value blank here so that it serves as a record for the top level domain itself:
Figure 5: Completing configuration of a PinPoint DNS Zone
Finally we repeat the same process for our second zone, autodiscover.exchangelabs.co.uk:
Figure 6: The second PinPoint DNS Zone for our AutoDiscover namespace
As these are AD-integrated DNS zones we don’t need to create secondary copies of the zone – the PinPoint zones will propagate across our AD-based DNS structure.
Using the Command Line to add PinPoint DNS Zones
We’re also able to create the DNS pinpoint zones from the command line, using the Windows dnscmd.exe utility.
Although it’s simple enough to do this from the GUI, and far simpler than split-DNS, if you’ve got a larger number of names associated with Exchange, for example names for failover and failback you can save yourself even more time by popping open the command prompt and adding the zones from there.
To add our two PinPoint zones for our Exchange infrastructure, we’ll use the following four commands to add the zone, and then add the records:
dnscmd . /zoneadd mail.exchangelabs.co.uk /dsprimary
dnscmd . /recordadd mail.exchangelabs.co.uk @ A 10.169.15.15
dnscmd . /zoneadd autodiscover.exchangelabs.co.uk /dsprimary
dnscmd . /recordadd autodiscover.exchangelabs.co.uk @ A 10.169.15.15
Testing PinPoint Zones
Before reconfiguring Exchange to make use of matching Internal and External URLs we’ll want to test that the PinPoint zones are correctly implemented, and our external DNS still functions as it should.
We’ll try this out by attempting to resolve normal external records, along with our Exchange DNS names against internal DNS servers.
Figure 7: Internal DNS query
If we then try the same queries externally, you’ll see they differ for just our PinPoint zones and return the original external address:
Figure 8: External DNS Query
As you’ll see above, the internal query returns internal IPs for Exchange DNS names, but continues to return the external IPs from the normal external DNS servers hosting the actual domain.
After implementing PinPoint DNS zones, you should also reconfigure your Exchange Internal URLs where appropriate so that clients can make use of and discover them.
When reconfiguring the Exchange URLs, you’ll need to reconfigure the InternalURL value to match the ExternalURL we’ve mirrored internally using PinPoint DNS. We’ll typically need to reconfigure the following Exchange Virtual Directories:
- Outlook Web App
- Exchange Control Panel
- Offline Address Book
- Exchange Web Services
- ActiveSync (Although only the ExternalURL is used)
We can reconfigure Outlook Web App, the Exchange Control Panel, Offline Address Book and ActiveSync using the Exchange Management Console or the Exchange Management Shell, but we’ll need to reconfigure the Exchange Web Services Virtual Directory using the Exchange Management Shell.
The following PowerShell commands show the changes we’d need to make to change one of our Internet-facing Client Access Servers:
Set-OWAVirtualDirectory -Identity “exmb02\OWA (Default Web Site)” -InternalURL https://mail.exchangelabs.co.uk/owa
Set-ECPVirtualDirectory -Identity “exmb02\ECP (Default Web Site)” -InternalURL https://mail.exchangelabs.co.uk/ecp
Set-OABVirtualDirectory -Identity “exmb02\OAB (Default Web Site)” -InternalURL https://mail.exchangelabs.co.uk/OAB
Set-WebServicesVirtualDirectory -Identity “exmb02\EWS (Default Web Site)” -InternalURL https://mail.exchangelabs.co.uk/EWS/Exchange.asmx
Set-ActiveSyncVirtualDirectory -Identity “exmb02\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://mail.exchangelabs.co.uk/Microsoft-Server-ActiveSync
We’ll also need to change the AutoDiscover Service Connection Point on each Internet-facing Client Access Server, which is the URL specified in Active Directory for domain-joined clients to locate the correct location for AutoDiscovery:
Set-ClientAccessServer -Identity exmb02 -AutoDiscoverServiceInternalURI https://autodiscover.exchangelabs.co.uk/AutoDiscover/AutoDiscover.xml
For internal, domain-joined clients, you may also need to consider modifications common for any split-DNS scenario, which include:
- Ensuring that the names specified for PinPoint DNS by-pass your Proxy Server infrastructure, either by updating your central Proxy AutoConfig (WPAD) file or altering your Group Policy.
- Ensuring that the PinPoint DNS names are added to your clients Intranet Zone via Group Policy.
As with any change to your environment, it’s recommended to test these changes in an isolated test lab that mirrors your organization’s configuration.
In this article, we’ve looked at the concept of PinPoint DNS zones which serve as a simple yet effective alternative to using Split DNS to allow end-users to use the same friendly URLs and ActiveSync namespaces both inside, and outside your organization.