Updating dns server
We're also able to create the DNS pinpoint zones from the command line, using the Windows utility. /recordadd autodiscover.uk @ A 10.1 Before reconfiguring Exchange to make use of matching Internal and External URLs we'll want to test that the Pin Point zones are correctly implemented, and our external DNS still functions as it should.
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. We'll try this out by attempting to resolve normal external records, along with our Exchange DNS names against internal DNS servers.
To create a new zone, right click Forward Lookup Zones and choose New Zone, then create a new zone with the following options: You'll see the first one, mail.uk below: Figure 4: Empty Pin Point 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 Pin Point DNS Zone Finally we repeat the same process for our second zone, autodiscover.uk: Figure 6: The second Pin Point DNS Zone for our Auto Discover namespace As these are AD-integrated DNS zones we don't need to create secondary copies of the zone - the Pin Point zones will propagate across our AD-based DNS structure.
The following Power Shell commands show the changes we'd need to make to change one of our Internet-facing Client Access Servers: We'll also need to change the Auto Discover 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 Auto Discovery: 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 Pin Point 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 Active Sync namespaces both inside, and outside your organization.
Often organizations provide external access to services like Outlook Web App and Exchange Active Sync using their registered domain names, whilst internally use a different domain that's not valid on the public internet.
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. 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.
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.