Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 11)

By /

If you would like to read the other parts in this article series please go to:

Introduction

In part 10 of this article series revolving around what the Windows Azure service is all about as well as how you deploy an Exchange hybrid deployment in Windows Azure, we added the virtual Exchange servers to the domain as well as installed Exchange 2013 bits on them.

In this part 11, we will continue where we left off in part 10.

Let’s get going…

Planning Exchange 2013 Namespaces      

Now that we have installed Exchange 2013 on the two virtual servers, we can begin to set up the Exchange namespaces by configuring the Exchange virtual directory URLs and creating the associated internal and external DNS records.

During the development of Exchange 2013, the Exchange team used quite a few resources on reducing the number of required namespaces. Both for single datacenter and multi datacenter scenarios. For a single datacenter scenario like we’re dealing with here, we need the following namespaces:

  • mail.azurelab.dk
  • autodiscover.azurelab.dk
  • smtp.azurelab.dk

Note:
You could bring the above list down to two by also using “mail.azurelab.dk” for SMTP, however, I like to have a dedicated namespace for Exchange client services and SMTP.

Unlike Exchange 2010, Exchange 2013 does not need an RPC Client Access namespace as the RPC Client Access Server service has been removed from the product.

Installing an Exchange 2013 Certificate

Before we create the DNS records and configure the URLs necessary for the planned namespaces, let us get the trusted certificate in place. In this article, I will use a wildcard certificate (*.azurelab.dk). If you are going to use a SAN certificate, you should include the three namespace above and that is it.

We will create a new Exchange certificate request using the “new Exchange certificate” wizard. To launch this wizard, click the “certificates” tab under “servers” in the EAC.

Type a friendly name for the certificate and click “next”.

Image
Figure 1: Entering a friendly name for the Exchange certificate

Since we will use a wildcard certificate in this article series, we will tick “Request a wildcard certificate” and enter the room domain (azurelab.dk) prepended with “*.”

Click “next”.

Image
Figure 2: Specifying the root domain for the wildcard certificate

Now specify the server on which the certificate request should be stored and click “next”.

Image
Figure 3: Specifying the server on which the certificate request should be stored

Now it is time to enter the organization information required. Do so and click “next”.

Image
Figure 4: Specifying information about the organization

Enter the UNC path to where the certificate request file should be stored and click “finish”.

Image
Figure 5: UNC path for certificate request file

When you have sent the certificate request to your favorite certificate provider and received the certificate, highlight the pending request, click the dots “…” and select “Import Exchange Certificate” as shown in Figure 6.

Image
Figure 6: Importing the Exchange Certificate

Specify the path to the certificate (.cer file) and enter the password that has been used to protect it (if one is used) and click “next”.

Image
Figure 7: Specifying UNC patch to certificate file and entering password that protects it

Specify the servers to which you wish to import the certificate (in my case, it is the two Exchange 2013 multi-role servers) and click “finish”.

Image
Figure 8: Specifying the servers to which the certificate should be imported

On the next page, click “services”.

Image
Figure 9: Switching to the services page

On the “services” page, tick “SMTP” and “IIS” and then click “save”.

Note:
We will not leverage the UM, POP and IMAP services in this article series.

Image
Figure 10: Selecting the services to which we want to assign the certificate

Select “yes” to the warning that states that the default SMTP certificate will be overwritten.

Image
Figure 11: Default SMTP certificate warning

Configuring Exchange 2013 Virtual Directory URLs

We now have to configure the virtual directories. Unlike Exchange 2010 and earlier, with Exchange 2013, we can also set an internal and external URL for including EWS from within the EAC, which is an improvement. However, we still have to switch to the Exchange Management Shell (EMS) to configure the URLs for the internal autodiscover service URI property.

To change the internal URL and set a new external URL, double-click the respective virtual directories. We need to change the internal URL and set the external URL for the following virtual directories:

  • OWA
  • ECP
  • EWS
  • Microsoft-Server-ActiveSync
  • OAB

Image
Figure 12: Virtual Directories in EAC

By default the internal URL is set to “https://servername.azurelab.dk/respective_service”. In this scenario, we will need to change this so both the internal and external URL is set to “https://mail.azurelab.dk/respective-service”.

Image
Figure 13: Default virtual directory configuration

Image
Figure 14: Virtual Directory Configuration end state

Now the last remaining thing is to configure the autodiscover service internal URI. As mentioned, we need to do so via the EMS, so launch that one and type the following:

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri “https://mail.azurelabs.dk/Autodiscover/Autodiscover.xml”

Image
Figure 15: Changing the URL for internal Autodiscover Service URI

When you have changed the configuration for the respective virtual directories on each server, it is a good idea to run an “IISRESET” or reboot them.

Creating the Internal & External DNS Records

In this specific scenario, we will use a split-brain DNS setup (same namespaces in internal and external DNS). This means we need to create the three records listed earlier on in this article in our AD DS DNS and at the DNS provider hosting our azurelab.dk domain.

Let us first create them in the internal DNS by launching the DNS Manager on one of the AD DS servers.

Image
Figure 16: DNS Manager on AD DS server

In here, we will create two A-records (DNS round robin method) for each namespace (mail, smtp and autodiscover). One record will point to the first Exchange 2013 multi-role server and the other to the second. We create the records with a 5-minute TTL, so that any changes reflect quickly throughout the environment.

Note:
We will need to create two records for each namespace (used round robin) since we do not use an internal load balancer for any of the Exchange services/protocols. However, since there are no L7 based session affinity requirements, this is perfectly fine and even supported in production environments. The autodiscover record is not necessary for standard Exchange deployments, but good to have in place when planning to establish an Exchange hybrid with an Exchange Online organization. If you wish to use true load balancer based load balancing, you do have the option of reserving internal IP addresses in Windows Azure now. Read more about this new feature in this blog post by Scott Guthrie.

Image
Figure 17: Creating the required A-records

The end state for the DNS records can be seen in Figure 18.

Image
Figure 18: A records that have been created for the namespaces

When it comes to external DNS record requirements, we only need to create one A-record per namespace as we just need to point to the VIP address associated with the Azure cloud services we created earlier on.

Image
Figure 19: DNS records in external DNS

Besides the above records, I have also created an MX record for the azurelab.dk domain as shown in Figure 20.

Image
Figure 20: MS record for the azurelab.dk domain

This concludes part 11 of this multi-part article in which I provide you with an explanation of what Windows Azure is and how you configure an Exchange 2013 hybrid lab environment in Windows Azure.

If you would like to read the other parts in this article series please go to:

About The Author

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top