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

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


In part 20 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 created the publishing rule required for publishing the AD FS servers in the Active Directory forest to the Internet followed by verifying access from the Internet worked as required. We also added our domain to the Azure Active Directory tenant and configured it for Exchange Online use.

Let’s get going…

Adding Domain to Azure Active Directory tenant

So previously in this article series, we have verified that clients and devices can access and authenticate against our federation service from the Internet. Since the primary reason for the federation service is to provide single sign-on access to Office 365 workloads, the next step is to federate our Active Directory domain with the Azure Active Directory tenant, which Office 365 uses as the identity platform.

To do so, we need to connect to the AAD tenant and run a PowerShell command, but before we do so, we have to add our domain to the AAD tenant. To do so let us logon to the Office 365 Portal and click “Domains” in the navigation pane (Figure 1).

Figure 1:
Domains page in the Office 365 Portal

Click “Let’s get started”.

Figure 2: Adding domain to the Active Directory tenant using the Office 365 Portal

On this page, we need to specify the domain to be added. In our case “”. When you have done so, click “Next”.

Figure 3: Specifying domain to be added to the tenant

We are now presented with a TXT record that needs to be added to the domain zone at our external DNS provider. If you use a DNS provider that does not allow you to create a TXT record, you also have the option of using an invalid MX record.

Figure 4: TXT record information

Adding the TXT record to your DNS provider should be a straightforward task. Just remember to add it with a TTL value of 3600 or lower in order for it to replicate quicker.

Figure 5: Creating TXT record in external DNS

Now go back to the Office 365 Portal Domain section and click “Okay, I’ve added the record”. If verification succeeds, you are taken to the page shown in Figure 6. Click “Next”.

Figure 6: Domain verified with success

Now we have the option to update the existing cloud users. However, we will select to skip this step for now.

Figure 7:
Option to update existing cloud users

In step 2, we also have the option to create new cloud users, but since we will use Directory Synchronization to synchronize our Active Directory domain users to the Azure Active Directory tenant, we will skip this step as well.

Figure 8: Option to create cloud users

We have reached step 3, where the “Add a new domain in Office 365” wizard will determine which DNS records are needed.

Click “Next”.

Figure 9:
Required DNS records will be determined

We will select “No, I don’t have a website at” as we do not have one and click “Next”.

Figure 10:
Do you have a website or not?

We now have the option to change the name servers we use. We do not want to do so at this point.

Figure 11:
Option to change the nameservers we use for the domain

We need to tell which service we wish to use. This only Exchange Online is in scope for this article, tick “Outlook for email, calendar, and contacts”.

Figure 12:
Selecting which services to use

We are now presented with the DNS records we need to create.

Figure 13:
DNS records required for Exchange Online (non-hybrid scenario)

Since we are dealing with an Exchange hybrid scenario none of these needs to be created yet, so you can ignore them for now and finish the wizard.

Figure 14: Finishing the domain wizard

Unlike the old Office 365 Portal, the domain status will no longer state “incomplete” despite that we have not created the DNS records required for non-hybrid scenarios. This is just one out of many improvements and fixes to the portal.

Figure 15: Domain added with success

Federating our Domain with Azure Active Directory

With our domain added to the Azure Active Directory tenant (Office 365), we can now federate the domain as required. To do so, let us logon to the first AD FS server we deployed in our Active Directory domain. Prior to connecting to the Azure Active Directory tenant using PowerShell, we need to download and install the Microsoft Online Services Sign-In Assistant for IT Professionals RTW followed by the Windows Azure Active Directory Module for Windows PowerShell, which provides the PowerShell commands required for connecting to and managing our Azure Active Directory tenant using PowerShell.

Figure 16: Installing the Sign-in Assistant

Figure 17: Installing the Azure Active Directory module for PowerShell

Now let us connect to the tenant. We do this by launching PowerShell using the new shortcut on the Desktop or by opening Windows PowerShell and typing “Import-Module MSOnline” followed by typing “Connect-MsolService”. Then specify the credentials of a Global Administrator in Office 365.

Figure 18: Connecting to the Azure Active Directory tenant using PowerShell

Let us list the tenant domains with the current setting by typing “Get-MsolDomain | fl”. Here we can see that the custom domain we added currently is set as a managed domain as shown in Figure 19.

Figure 19: Custom domain listed as a managed domain

In order to federate the domain we must convert it to (yes you guessed right) a federated domain. We do this be running the following command:

Convert-MsolDomainToFederated –DomainName “” -SupportMultipleDomain

Figure 20: Converting our domain to a federated domain

The “SupportMultipleDomain” parameter is not required but makes it easier to add additional federated domains later on if that becomes a neat in the future.

As you can see in Figure 21 our custom domain has now been changed to a federated domain.

Figure 21: Custom domain converted to a federated domain

Let us open the AD FS management console (Server Manager > Tools) and select “Relying Party Trusts”. Here we can see that the Office 365 identity platform has been added as a relying party trust.

Figure 22: New relying party trust created

To see the details of the relying party trust, simply double-tab the trust in the right pane and examine the setting under each tab.

Verifying Authentication Redirection works as expected

We can now move on and verify that authentication redirection works as expected. To do so, let us open a browser on an external client and enter “”. This will redirect us to the page where we can specify the credentials for a federated user. Since we have not yet configured directory synchronization, we will just use a fictive test user ([email protected]).

Figure 23: Microsoft Online Services sign-in page

When switching to the password field, a redirection to the AD FS sing-in page should occur as shown in Figure 24.

Figure 24: Redirection to the AD FS based federation service

We are now presented with the AD FS sign-on page but since we haven’t set up directory synchronization, we cannot authenticate against our “on-premises” Active Directory yet.

Figure 25: AD FS sign-in page

This concludes part 21 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

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