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

by [Published on 11 July 2013 / Last Updated on 11 July 2013]

In this article we will deploy the Active Directory Federation Proxy (ADFS) servers that are required for external identity federation with Office 365.

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

Introduction

In part 4 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 installed and configured Active Directory Federation Service (ADFS) 2.1 on the two ADFS servers on the internal network. After we configured the servers, we verified they worked as expected.

In this part 5, we will continue where we left off in part 4. That is we will deploy the Active Directory Federation Proxy (ADFS) servers that are required for external identity federation with Office 365. More specifically, we will deploy and configure two ADFS Proxy servers. In order to achieve high availability, the ADFS Proxy servers will be load balanced using Windows Network Load Balancing (WNLB).

Configuring Windows Load Balancing on the ADFS Proxy Servers

When configuring rich coexistence between an Exchange on-premise environment and Office 365, it’s crucial identity federation that works all the time. As already mentioned in previous parts of this article series, 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 Proxy servers, we will configure them in a WNLB. To do so, first install the ”Network Load Balancing” feature. This can be done by opening the Server Manager and launching the ”Add Roles and Features Wizard” as shown in Figure 1. On the ”Select Features” page, tick ”Network Load Balancing”.

Image
Figure 1:
Selecting the Network Load feature

When the WNLB feature has been installed, click ”Close” to exit the wizard.

Image
Figure 2: NLB feature installed

Now launch ”Network Load Balancing Manager” by clicking “Tools” > “Network Load Balancing Manager” in the “Server Manager”.

Image
Figure 3: Launching the NLB Manager

In the NLB Manager, select ”Cluster” in the menu and then click ”New”. 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.

Image
Figure 4:
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”.

Image
Figure 5: Host Parameters page

On the ”New Cluster: Cluster IP Addresses” page, click ”Add”.

Now enter the IP addresses (virtual IP address) that should accept incoming sessions for the Windows NLB cluster. When done, click ”OK” and ”Next”.

Image
Figure 6:
Adding a virtual IP address to the NLB cluster

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.clouduser.dk” as the FQDN and will run the Windows NLB in unicast mode.

Click ”Next”.

Image
Figure 7:
Specifying the full internet name and cluster operation mode

On the ”New Cluster: Port Rules” page, configure the NLB cluster to only listen on port 443/TCP.

Click ”Finish”.

Image
Figure 8:
Port rules

The NLB cluster has now been configured although only with a single node.

In order to add the other ADFS Proxy server as a node, right-click on the cluster name and then select ”Add Host To Cluster” in the context menu.

Image
Figure 9: NLB cluster created and adding a second node

On the ”Add Host to Cluster: Connect” page, enter the IP address of the other ADFS Proxy server and then click ”Connect”. Select the listed interface and click ”Next”.

Image
Figure 10:
Specifying the IP address and interface of the other node

Leave the defaults and click ”Next”.

Image
Figure 11:
Host Parameters

Click ”Finish”.

Image
Figure 12:
Port rules

After a little while, the other node has been added to the NLB cluster.

Image
Figure 13:
NLB cluster now includes two nodes

Okay, so although we now have an NLB cluster set with ”sts.clouduser.dk” associated with the specified virtual IP address, there’s no way traffic that hits ”sts.clouduser.dk” from the Internet can be directed to the NLB cluster since the FQDN doesn’t exist in external DNS.

So now is the time to create an A record named “sts” in the parent for the “clouduser.dk” domain at the external DNS provider hosting our domain. In my case, I’ll need to open the web GUI at my provider and created the record as shown in Figure 14.

It will be named ”sts” and as you can see, is associated with a public IP address that forward traffic to the VIP address was set to when the ADFS Proxy NLB cluster was created.

Image
Figure 14:
Creating the federation DNS record in external DNS

Adding Federation FQDN to the hosts file on the ADFS Proxy servers

Because the ADFS Proxy servers has been configured with the same virtual name (sts.clouduser.dk) as the ADFS servers on the internal network, we need to make sure that when the ADFS Proxy servers are going to route 443 traffic to ”sts.clouduser.dk” that it goes to the ADFS servers on the internal network. An easy way to achieve this is to add ”sts.clouduser.dk” to the local hosts file on each ADFS Proxy pointing to the VIP of the ADFS servers on the internal network.

Image
Figure 15:
Adding federation FQDN to the hosts file on the ADFS Proxy servers

After having added ”sts.clouduser.dk” to the hosts file on both ADFS Proxy servers, open a command prompt and type ”IPConfig /Flushdns” to flush the NBT remote cache name table and then try to ping ”sts.clouduser.dk”. This should now resolve to the VIP configured on the ADFS servers on the internal network.

Image
Figure 16:
”sts.clouduser.dk” resolving to the VIP configured on the ADFS servers on the internal network

Enable MAC Spoofing on the Hyper-V Virtual Machines

In this article series all servers including the ADFS Proxy 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”.

Image
Figure 17:
Enabling spoofing of MAC addresses

Now start each cluster node again.

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

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

The Author — Henrik Walther

Henrik Walther avatar

Henrik Walther is a respected writer with special focus on Microsoft Exchange and Office 365/BPOS (Exchange Online) solutions within the unified communications area. Prior to joining Microsoft, he was an eight year Exchange MVP and back in 2006 he took the Microsoft Certified Master: Exchange certification.

Latest Contributions

Featured Links