Configuring an Exchange 2013 Hybrid Deployment and Migrating to Office 365 (Exchange Online) (Part 7)

By /

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

Introduction

In part 6 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we deployed the Active Directory Federation Proxy (ADFS) servers that are required for external identity federation with Office 365. More specifically, we deployed and configured two ADFS Proxy servers. In order to achieve high availability, the ADFS Proxy servers have been load balanced using Windows Network Load Balancing (WNLB).

In this part 7, we will continue where we left off in part 6. That is we will install the Windows Azure Active Directory Module for Windows PowerShell and convert our custom Office 365 domain to a federated domain. In addition, we will enable directory synchronization for our Office 365 tenant, so that it’s ready for part 8.

Let’s get going…

Converting the Custom Domain to a Federated Domain

So during the last four articles in this series, we prepared for identity federation between the on-premises environment and Office 365. We did so by deploying and configuring two ADFS servers on the internal network and two ADFS Proxy servers in the perimeter network.

Despite creating the federation service farm, we have yet to configure the actual federation with our Office 365 tenant in order to achieve single sign-on (SSO) for clients connecting to Office 365. We can do this using Windows PowerShell on a machine that has the Windows Azure Active Directory Module for Windows PowerShell installed. Personally, I like to install this PowerShell module on the primary ADFS server in a federation farm as you then do not have to set the ADFS context using the “Set-MsolAdfscontext” cmdlet prior to converting the respective custom domain to a federated domain.

All right, let us log on to the primary ADFS server. Now open a browser and download the Microsoft Online Services Sign-In Assistant for IT Professionals, which is a prerequisite for installing the Windows Azure Active Directory Module for Windows PowerShell. When downloaded, launch the Setup wizard.

Accept the “License Agreement” and click “Next”.

Image
Figure 1: MOS Sign-In Assistant Setup License Agreement

When installed, click “Finish” to exit the setup wizard.

Image
Figure 2: MOS Sign-in Assistant installed successfully

Despite having installed .NET Framework 4.5 on the server, we also need to install .NET Framework 3.5 in order to be able to install the Windows Azure Active Directory Module for Windows PowerShell. This can be done via the Server Manager.

Image
Figure 3: Adding the .NET Framework 3.5 Features via the Server Manager

After having installed .NET Framework 3.5, we are ready to install the Windows Azure Active Directory Module for Windows PowerShell. This tool can be downloaded from the Office 365 portal. More specifically under “users and groups” > “Single sign-on”, where you click “Manage”.

Now under “step 3”, select the “Windows 64-bit version” and click the “download” button.

Image
Figure 4: Downloading the Windows Azure Active Directory Module for Windows PowerShell

With the module downloaded, double-click the “AdministrationConfig-en” MSI file to launch the module setup wizard.

Click “Next”.

Image
Figure 5: WAAD Module for Windows PowerShell setup wizard – Welcome page

Accept the license agreement and click “Next”.

Image
Figure 6: WAAD Module for Windows PowerShell setup wizard – License Terms page

Accept the default installation path and click “Next”.

Image
Figure 7: WAAD Module for Windows PowerShell setup wizard – Install Location page

Click “Install”.

Image
Figure 8: WAAD Module for Windows PowerShell setup wizard – Ready to Install page

Click “Finish”.

Image
Figure 9: WAAD Module for Windows PowerShell setup wizard – Completion page

Launch the Windows Azure Active Directory Module for Windows PowerShell.

Image
Figure 10: Launching the Windows Azure Active Directory Module for Windows PowerShell

Type “Connect-MSOLService” and then authenticate using an Office 365 global administrator account.

Image
Figure 11: Connecting to the Office 365 tenant using Powershell

Now type “Get-MSOLDomain –DomainName clouduser.dk” to list the custom domain(s) and authentication type.

Image
Figure 12: Listing custom domain(s) and authentication type

Now convert the domain that you wish to use for federation using the below command. In this example, it is “clouduser.dk”:

Convert-MsolDomainToFederated –DomainName “clouduser.dk”

Image
Figure 13: Converting the domain to a federated domain

When the command has finished, let us verify that the domain has been converted to a federated domain. We can do so using: Get-MsolDomain | fl

Image
Figure 14: Domain converted to a federated domain

Finally, let’s open the ADFS Management console. Here we can see that AD FS now provides single sign-on (SSO) access for client computers.

Image
Figure 15: AD FS Management console

Okay the domain has now been converted with success.

Note:
If you need to configure support for multiple UPN domains, check out this blog post I wrote on the topic. The steps have been written for Windows Server 2008 based ADFS servers.

Next up, let us test whether the “login.microsoftonline.com” site detects the respective domain as a federated domain. To do so, enter a fictive UPN with a UPN domain suffix matching the one we just federated. When you have entered the UPN and pressed “tab”, you should see the password field grey out as shown below. This means that Office 365 will redirect all authentication requests for the respective domain to the ADFS Proxy servers in our on-premises federation service infrastructure.

Note:
If you haven’t seen the below sign-in page before, I can inform you that it’s the new Office 365 login page that the Office 365 product team has been working on. The redesign goals with it was to create a simple experience that’s optimized for modern devices, reduces the number of times users need to sign in, and provides the best possible experience across the many devices that you want to use.

Image
Figure 16: Testing federation is detected by the Microsoft Online Login Page

After a few seconds, we should be taken to the ADFS Proxy server page in our on-premises infrastructure as shown in Figure 17.

Image
Figure 17: Forms based login based on on-premises ADFS Proxy server

This concludes part 7 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

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