Monday, December 15, 2014

Office 365 - Hybrid Migration with ADFS - Introduction

In my next blog posts, I will perform a "hybrid migration" to Office 365 from Exchange 2010. I will implement Active Directory Federated Services (ADFS) for Single Sign-On (SSO), DirSync for directory synchronization, and hardware load balancing for ADFS high availability.

Such a migration will be somewhat complex.

Fortunately, I had already completed certain steps in a previous set of blog posts dedicated to a "staged migration" (Exchange 2007 to Office 365 - and more specifically, Exchange Online, the messaging component of Office 365).

I will build on that foundation to faciliate this new migration and avoid having to repeat many of the very same tasks all over again.

Some clarifications first...

For the reader's information, I have purged my Office 365 tenant of the remanents of the previous migration and am now ready to use it for a new "adventure": a hybrid migration from Exchange 2010 (SP3).

It was necessary to rebuild my onsite environment as well, since the previous migration changed the status quo to a great extent: absence of mailboxes migrated to the Cloud, changes in DNS entries, and a number of other elements. 

During my previous (staged) migration, I had performed several crucial tasks:

Created an Office 365 tenant with Microsoft.

Added my domain to the tenant.

Created the DNS record that validates my ownership of the domain.

Activated DirSync.

I will not republish the original blog posts here but refer the reader to the original posts (see the hyperlinks above).

If you are starting "from scratch" (fresh start), I would recommend that you refer to the pertinent parts of my staged migration (see links above). Once you have completed those steps, you can return to this series of blog posts and follow the rest of the process for a hybrid migration.

In some cases, however, I will have to repeat certain operations. For example, while my Office 365 tenant is still enabled for DirSync, my DirSync server no longer exists so I will have to build a new one.

Important note: in my case, DirSync was already activated in Office 365 (for the previous migration) and I will leave it in that state. However, in a hybrid migration we install and configure ADFS first and then (and only then) DirSync. If you have no existing Office 365 tenant, or have just created one, you can leave DirSync unactivated for the time being.

Here is a partial list of tasks that I will perform in my next blog posts:


  • Install server (Windows 2012 R2 - this has been completed - I will not demonstrate, step by step, how to install Windows 2012).
  • Install certificate
  • Install the ADFS role. Note: with Windows 2012 R2, the version of ADFS is 3.0.
  • Convert domain to federated domain

Load balancing for ADFS

In my test environment, I will only use one ADFS server. If you've read any documentation on federated authentication for Office 365, you may already know that, in a production environment, it is crucial that authentication services are always available. Therefore, we would install at least two ADFS servers and probably implement some sort of load balancing solution in front of them. Consequently, my load balancer will only have one "target" server whereas, in reality, we would want at least two.

I will use a KEMP VLM-200 virtual device. It has already been installed and configured for other purposes. I will not repeat those basic configuation steps here. On the other hand, I will perform these tasks:

  • Download a template for ADFS from the KEMP Technologies website.
  • Configure the VLM-200 for ADFS


  • Build a server for DirSync (this has been completed - I will not show how to install Windows server)
  • Install DirSync
  • Activate DirSync in the Office 365 tenant (this has been completed - I will show the reader where this is configured this however.

There are several other operations to complete. I'll present them after completing the steps mentioned above.

No comments:

Post a Comment