If you would like to read the other parts of this article series please go to:
- Configuring an Exchange Hybrid Deployment & Migrating to Office 365 (Exchange Online) (Part 10)
- Configuring an Exchange Hybrid Deployment & Migrating to Office 365 (Exchange Online) (Part 11)
- Configuring an Exchange Hybrid Deployment & Migrating to Office 365 (Exchange Online) (Part 13)
Introduction
In part 1 of this multi-part article series revolving around Exchange hybrid deployment based migrations to Office 365 or more precisely Exchange Online, I explained to you in simple terms what migration approaches we have at our disposal, when it comes to migrating from an Exchange based on-premise environment to Exchange Online. In addition, I briefly described what an Exchange hybrid deployment is and what it offers in terms of coexistence. Moreover, we created an Office 365 trial tenant and added our domain which in this case is “office365lab.dk.dk” to this tenant.
In this part 2, we will continue where we left off in part 1. That is we will deploy the Active Directory Federation Service (ADFS) servers that are required for identity federation with Office 365. More specifically, we will deploy and configure two ADFS servers. In order to achieve high availability, the ADFS servers will be confgiured in an ADFS farm and load balanced using Windows Network Load Balancing (WNLB).
Important:
Before you start deploy and configure the servers required to achieve rich coexistence between the Exchange on-premise and Exchange Online, you should run the Microsoft Office 365 Deployment Readiness Tool in the respective Active Directory forest. The tool will provide an analysis of the environment in preparation for the actual Office 365 enterprise deployment and it’s important you fix any issues caught by the tool prior to deploying the rich coexistence servers. You can download the tool here.
A Brief Explanation of Office 365 Identity Federation
By using the WS-Federation (WS-Fed) and WS-Trust protocols, Active Directory Federation Services (ADFS) 2.0 provides claims-based single sign-on (aka identity federation) for the services in the Office 365 service offering. The benefits of using indentity federation is to provide the users in the enterprise with a SSO experience no matter if they are located on an external network or on the internal corporate network.
Basically, ADFS 2.0 is a Security Token Service (STS) that is capable of issuing, validating and exchanging security tokens on behalf of the users in the enterprise.
Although ADFS can be deployed using stand-alone federation servers, the identity federation service usually consist of two or more ADFS Proxy servers in placed in the perimeter network and two or more ADFS servers located on the internal corporate network. The internal ADFS servers are configured in a so called federation server farm, which then again is load balanced using some form of load balancing solution. The ADFS Proxy servers are are not configured in a federation server farm per se, but incoming sessions hitting these servers are simply load balanced.
Diagram 1
The reason why it’s recommended to deploy at least two ADFS Proxy and ADFS servers is in order to achieve redundancy. This is critial since an unavailable ADFS infrastructure means that users won’t be able to access any used services in Office 365.
By default, the ADFS configuration is stored in a Windows Internal Database (WID) both when it comes to ADFS Proxy and ADFS servers. If you need more than five federation servers in a farm or need to spread them over multiple locations, it’s possible to store the ADFS configuration in a SQL database, but generally such a configuration should be avoided because of costs as well as complexity.
It’s also worth noting that the ADFS Proxy servers can be eliminated in certain scenarios where a TMG array or an UAG farm is located in the perimeter network. However, UAG is not capable of pre-authenticating active Office 365 clients (ActiveSync, Outlook Anywhere and Lync) only passive clients (browser-based clients such as OWA).
Its important to bear in mind that identity federation required directory synchronization (DirSync) from the on-premise Active Directory forest to the Office 365 tenant, so that a shadow user is created for each on-premise user in the Office 365 tenant.
I won’t go much more into the details of identity federation here as I’ll show you the authentication experience as we progress through this articles series.
Configuring Windows Load Balancing on the ADFS Servers
When configuring rich coexistence between an Exchange on-premise environment and Office 365, it’s crucial identity federation works all the time. As already mentioned, if the identity federation service becomes unavailable, it means that the Active Directory users within the enterprise cannot authenticate against an Office 365 service such as Exchange Online. Since the user cannot authenticate he cannot access an Office 365 service as he does not know the password set for the Office 365 user object itself. Because of this, it’s highly recommended to load balance all ADFS servers as well as ADFS Proxy servers using Windows Network Load Balancing (WNLB), a virtual load balancing appliance or a hardware load balancer solution. Since ADFS doesn’t require layer 7 based affinity, WNLB is fully supported.
Before we configure ADFS on the two ADFS servers, we’ll configure them in a WNLB. To do so, first install the ”Network Load Balancing” component. This can be done by opening the Server Manager and launching the ”Add Features Wizard” as shown in Figure 1. On the ”Select Features” page, check ”Network Load Balancing”.
Figure 1: Selecting the Network Load Balancing component
When the component has been installed, click ”Close” to exit the wizard.
Figure 2: NLB component installed
Now launch ”Network Load Balancing Manager” from ”Start” > ”Administrative Tools”.
Figure 3: Launching the NLB Manager
In the NLB Manager, select ”Cluster” in the menu and then click ”New”.
Figure 4: NLB Manager
Figure 5: Opening the New NLB Cluster creation wizard
In ”New Cluster: Connect” type the server name of the ADFS server you currently are logged on to then click ”Connect”.
Select the interface name listed and click ”Next”.
Note:
In this article series I’ll configure the Windows NLB in unicast mode which is the reason why I only have one interface connected to the server.
Figure 6: Specifying the name of the first node and the associated interface
On the ”New Cluster: Host Parameters” page, leave the defaults as is and click ”Next”.
Figure 7: Host Parameters page
On the ”New Cluster: Cluster IP Addresses” page, click ”Add”.
Figure 8: Adding a virtual IP address to the NLB cluster
Now enter the IP addresses (virtual IP address) that should accept incoming sessions for the Windows NLB cluster.
When done, click ”OK” and ”Next”.
Figure 9: Specifying the virtual IP address
Figure 10: Virtual IP address
On the ”New Cluster: Cluster Parameters” page, enter the FQDN for the Windows NLB in the ”Full Internet Name” text field and then select the cluster operation mode.
In this article series, we use ”sts.office365lab.dk” as the FQDN and will run the Windows NLB in unicast mode.
Click ”Next”.
Figure 11: Specifying the full internet name and cluster operation mode
On the ”New Cluster: Port Rules” page, leave the defaults so the NLB cluster listens on all ports.
Click ”Finish”.
Figure 12: Port rules
The NLB cluster has now been configured although only with a single node.
Figure 13: NLB cluster created
In order to add the other ADFS server as a node, right-click on the cluster name and then select ”Add Host To Cluster” in the context menu.
Figure 14: Adding another node to the NLB cluster
On the ”Add Host to Cluster: Connect” page, enter the server name of the other ADFS server and then click ”Connect”. Select the listed interface and click ”Next”.
Figure 15: Specifying the name and interface of the other node
Leave the defaults and click ”Next”.
Figure 16: Host Parameters
Click ”Finish”.
Figure 17: Port rules
After a little while the other node has been added to the NLB cluster.
Figure 18: NLB cluster now includes two nodes
Okay so although we now have a NLB cluster set with ”sts.office365lab.dk” associated with the specified virtual IP address, there’s no way traffic that hits ”sts.office365lab.dk” can be directed to the NLB cluster since the FQDN doesn’t exist in DNS.
So let’s open the DNS Manager on a domain controller in the Active Directory forest and add a new host record (A-record).
Figure 19: Creating a DNS record in AD DNS
Name it ”sts” and then enter the VIP address that was set when the NLB cluster was created.
Figure 20: Naming the record and specifying the VIP of the NLB cluster
Important:
In this article series all servers including the ADFS servers are based on virtual machines in a Hyper-V environment. This means that we need to enable spoofing of MAC addresses on the interface for servers participating as nodes in an NLB cluster running in unicast mode. To do so, shut down each node and then open the property page for each respective virtual machine. On the property page, select the virtual network adapter, then check ”Enable spoofing of MAC addresses”.
Figure 21: Enabling spoofing of MAC addresses
Now start each cluster node and then verifiy you can ping ”sts.office365lab.dk” or whatever FQDN you use in your environment.
Figure 22: Ping the FQDN associated with the NLB Cluster
This concludes part 2 of this multi-part article in which I explain how you configure Exchange hybrid deployment followed by migrating to Office 365 (Exchange Online).
If you would like to read the other parts of this article series please go to:
