Topic Last Modified: 2012-10-18

The metropolitan site resiliency solution described in this section entails the following:

  • Splitting the Front End pool between two physical sites, hereafter called North and South. In Topology Builder, these two geographical sites are configured as one single Lync Server 2010 site.

  • Creating separate geographically dispersed clusters (physically separated Windows Server 2008 R2 failover clusters) for the following:

    • Back End Servers

    • Group Chat Database Servers

    • File Servers

  • Deploying a Windows Server 2008 R2 file share witness to which all server clusters are connected. To determine where to place the file share witness, refer to the Windows Server 2008 R2 failover cluster documentation at http://go.microsoft.com/fwlink/p/?LinkId=211216.

  • Enabling synchronous data replication between the geographically dispersed clusters.

  • Deploying servers running certain server roles in both sites. These roles include Front End Server, A/V Conferencing Server, Director, Edge Server, and Group Chat Server. The servers of each type in both sites are contained within one pool of that type, which crosses both sites. Except for Group Chat Server, all servers of these types, in both sites, are active. For Group Chat Server, only the servers in one site can be active at a time. The Group Chat Servers in the other site must be inactive.

    Additionally, Monitoring Server and Archiving Server can be deployed in both sites; however, only the Monitoring Server and Archiving Server in one site are associated with the other servers in your deployment. The Monitoring Server and Archiving Server in the other site is deployed but not associated with any pools, and it serves as a "hot" backup.

The following figure provides an overview of the resulting topology.


With the topology depicted in the preceding figure, a single site could become unavailable for any reason, and users would still be able to access supported unified communications services within minutes rather than hours. For a detailed depiction of the topology used to test the solution described in this section, see Site Resiliency Topology.

Scope of Testing and Support

This site resiliency solution has been tested and is supported by Microsoft for the following workloads:

  • IM and presence

  • Peer-to-peer scenarios; for example, peer-to-peer audio/video sessions

  • IM conferencing

  • Web conferencing

  • A/V conferencing

  • Application sharing

  • Enterprise Voice and Telephony Integration

  • Enterprise Voice applications, including Conferencing Attendant, Conferencing Announcement service, Outside Voice Control, and Response Group service

  • Approved unified communications devices

  • Simple URLs

  • Group Chat

  • Exchange UM

Workloads That Are Out of Scope

The following scenarios can be deployed in the metropolitan site resiliency topology, but the automatic failover of these workloads is not designed or supported:

  • Federation and Public IM Connectivity

  • Remote call control

  • Microsoft Lync Web App

  • XMPP Gateway