In the first part of this blog we did configure the Geo DNS server and the Database Availability Group. We now will continue with configuring the CAS role and after that perform some testing.

The first step is to set all the url’s to the same value. This because each user will use the same url when connecting from the internet and will be redirected to the correct datacenter using the GeoDNS solution.

Using the Get-WebServicesVirtualDirectory _cmdlet we can see the current config. Because we only need a few parameters we will use the  select _option to only select the parameters we need:
_Get-WebServicesVirtualDirectory Select Identity, ExternalUrl, InternalUrl_

To set all the url’s to the same value we will use the _Set-WebServicesVirtualDirectory _cmdlet i.c.w. the _Get-WebServicesVirtualDirectory _cmdlet:

_Get-WebServicesVirtualDirectory Set-WebServicesVirtualDirectory –ExternalUrl -InternalUrl

After these URL’s have been fixed it’s time for the remaining URL’s to be corrected:


_Get-OwaVirtualDirectory Set-OwaVirtualDirectory –ExternalUrl



_Get-EcpVirtualDirectory Set-EcpVirtualDirectory –ExternalUrl



_Get-OabVirtualDirectory Set-OabVirtualDirectory –ExternalUrl



_Get-ActiveSyncVirtualDirectory Set-ActiveSyncVirtualDirectory  -Internalurl  -Externalurl

When the URL’s for the webservices have been configured it’s time to configure the Autodiscover url on both servers:

Set-ClientAccessServer –Identity EX01 –AutodiscoverInternalUri

And for the next server:

Set-ClientAccessServer –Identity EX02 –AutodiscoverInternalUri

Since we haven’t enabled Outlook Anywhere will need to enable it and configure it to use the correct FQDN. To do this we will need to use the Enable-OutlookAnywhere cmdlet:

_get-outlookanywhere set-OutlookAnywhere -InternalHostname -ExternalHostname -InternalClientsRequireSsl: $true -ExternalClientsRequireSsl: $true_

Now we have configured all services with the correct url’s it’s time to generate a certificate request:

First we generate the request and put the output in a variable called $newcert:

$newcert = New-ExchangeCertificate -GenerateRequest -SubjectName 

“c=NL,o=Johan Veldhuis,” -DomainName “”  -PrivateKeyExportable $true

Make sure you don’t forget the set the PrivateKeyExportable to true. This will give us the option to export the certificate including the private key which is needed on the other Exchange server.

Next step is to put the content of the variable in a txt file:

_newcert out-file c:\install\csr.txt_

Now we can send the CSR to the CA. Once we received the certificate we can install it on the Exchange server which is used to create the CSR:

Import-ExchangeCertificate –FileData ([byte []]$(Get-Content –Path “c:\install\certificate.cer” –Encoding Byte –ReadCount 0))

Next step is to assign the certificate to the services:

Get-ExchangeCertificate –ThumbPrint thumbprint  Enable-ExchangeCertificate –Services POP,IMAP,IIS,SMTP

In this example you will need to replace thumbprint by the _thumbprint _of the certificate we have installed. You can find the value of the thumbprint by running the following cmdlet:

_Get-ExchangeCertificate select Subject,Thumbprint_

Once this step has completed we can proceed with the next server. First we need to export the certificate including the private key:

$cert = Export-ExchangeCertificate -Thumbprint thumbprint -BinaryEncoded:$true -Password (Get-Credential).password

This will export the certificate and will ask you for a password to protect the certificate as it includes the private key. The output is stored in a variable called $cert.

Once the output is stored in the variable it’s time to create the PFX file:

Set-Content -Path “c:\certificates\cert.pfx” -Value $cert.FileData -Encoding Byte

Copy the PFX file to the other Exchange server and import it:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\certificates\cert.pfx -Encoding byte -ReadCount 0)) -Password:(Get-Credential).password

Once it has been imported we can assign it just as we did on the other server:

Get-ExchangeCertificate –ThumbPrint thumbprint  Enable-ExchangeCertificate –Services POP,IMAP,IIS,SMTP

With this step we have completed the implementation of our Geo DNS solution.

As with every deployment now comes the most important step: verify if everything works.

There are various clients we can use for testing our Geo DNS solution among them are:

  • Outlook Web App (OWA)
  • Outlook

We will skip ActiveSync in this test but normally you would of course test each connection method which is available.

To perform these tests we will need to reconfigure our client so it matches one of the configured networks. For example:



Besides this don’t to change the DNS settings so the Geo DNS will be used for lookups.

Because all clients depend on DNS first verify if that works, although we checked it in the 1st part of this blog.

To test this we can use nslookup:

From a client in the 192.168.2.x range we will get this answer:

From a client in the 192.168.3.x range we will get this answer:

So far so good let’s verify if we can connect to OWA from both subnets. To perform this test simply open your favorite browser and browse to the OWA url, in this scenario

As you can see OWA is displayed correctly. Once this test has been performed you will need to change the network settings of the client again to match the other network. Then perform the same test again and you should still have a working OWA only then proxied via the other server.

As a final test we will perform several checks using Outlook. After configuring the profile you can see we’re connected to Outlook. When this is completed we verified that both the connection to the mailbox and autodiscover work:

Now let’s change the client’s network settings and see what happens. You might see a short disconnected but after a few seconds you are connected via the other server:

And Outlook continuous to synchronize the mailbox for the user. Besides this test you might want to verify some other things via Outlook:

  • verify of free/busy works
  • verify if Outlook can download the addressbook
  • verify if you can connect to the Exchange Control Panel using Outlook

Here ends the second and last part of how to build a Geo DNS solution in your test environment. Keep in mind that if you are planning to use Geo DNS you will need a “real” Geo DNS solution. This solution was only used for testing purposes and should not be used in a production environment.


Johan Veldhuis