Design considerations for Office 365 with single sign-on and Azure Virtual Machines

 

Applies to: Office 365

Summary: Describes network connectivity, component redundancy, and availability considerations for Office 365 with single sign-on and Azure Virtual Machines.

We're listening to your feedback and consolidating all our Office 365 deployment content. On July 1st, 2015, all information in this guide will be moved to https://support.office.com/, and these pages will be removed from TechNet. As you review the content still on TechNet, you'll notice many have links pointing to the new content already on https://support.office.com/.

To explore content available on https://support.office.com/, start with the Office 365 for business - Admin Help page.

If you choose to deploy Office 365 directory integration components on Azure Virtual Machines, we recommend that you deploy one or more Active Directory domain controller replicas of your on-premises Active Directory in Azure. Deploying these replicas to virtual machines eliminates the cross-premises network connection as a single point of failure in the deployment. This has the added benefit of faster logon because the logon traffic doesn’t need to traverse the cross-premises network connection for each logon attempt.

Active Directory domain controllers

Although it’s possible to deploy Active Directory Federation Services (AD FS) on virtual machines in Azure and leave the domain controllers on-premises, we strongly discourage it. Separating your domain controllers from your AD FS may introduce latency into the authentication chain. This creates a real-time dependency on the network connectivity for these two services. Placing domain controllers on virtual machines within Azure mitigates these risks.

Domain controllers in Azure should be placed in a separate Active Directory site. This introduces some additional Active Directory replication latency. The default replication delay between Active Directory sites is 3 hours (180 minutes). The default synchronization schedule between Active Directory and Office 365, by using the Azure Active Directory Sync tool, is also 3 hours.

Consequently, it may take up to 6 hours for a change made on-premises to replicate to Office 365, unless the replication delay is adjusted. For more information, see How Active Directory Replication Topology Works.

For general guidance about running Active Directory services on virtual machines, see Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines.

-
 

Virtual private network connectivity

Network connectivity is required between Virtual Machines and your on-premises corporate network. Such connectivity should always take place over a private network for security reasons.

Domain controllers that are installed on virtual machines in Azure should:

• Never use a publicly routable endpoint.

• Always use a private network.

Azure supports virtual private networks (VPNs) by using a Microsoft Azure Virtual Network.

Component redundancy and availability

When you implement services on virtual machines, you have to expand the existing on-premises management and monitoring process to these services. The management and monitoring can traverse the VPN that you set up to connect to Azure.

For improved availability, multiple virtual machines are used for most components. By using multiple virtual machines, services remain available during local network failures, local disk hardware failures, and any planned downtime that Azure may require.

When multiple virtual machines are connected in a cloud service, an availability set should be used to ensure that the virtual machines are located in different fault domains. This is similar to ensuring two redundant servers were located on physically different server racks in your on-premises datacenter.

The following figure depicts two availability sets with two virtual machines in each set.

Figure 1. Two availability sets with two virtual machines in each set

For more information about Azure fault domains and availability sets, see Manage Virtual Machine Availability.

Separating the redundant servers for each component as previously described works for all the components discussed except the Directory Sync tool. It doesn’t support server redundancy. In the event of a virtual server failure, recovery steps may be needed. These steps are essentially the same for on-premises and cloud deployments of the tool.

If the Directory Sync tool temporarily stops working, directory synchronization resumes where it left off when the tool is working again. Should the server fail completely, directory synchronization won’t resume until the Directory Sync tool is reinstalled on a new virtual server.