Lync Edge Server Disaster Recovery

Lync Server 2013 Edge Servers do not provide a native disaster recovery solution. In the event of a disaster scenario, manual steps must be taken to direct services through the secondary Edge Server pool. However, proper planning can reduce the amount of effort required for these tasks. When planning for Edge Server disaster recovery, consider the strategies discussed in the following subsections.

Weighted DNS Records for Access Edge Services

It is possible to deploy the DNS SRV records required for Lync remote access and federation with a priority and weight. This configuration essentially allows for a primary and secondary DNS A record to be configured. Clients will always use the DNS record with the lowest-numbered priority value first and fall back to other records if the connection to the host fails. The weight value on SRV records should be used only for providing load balancing between services.

Example for Access Edge sign-on services:

Click here to view code image

_sip._tls.companyabc.com 86400 IN SRV 10 10 443 sip.companyabc.com
_sip._tls.companyabc.com 86400 IN SRV 20 10 443 sip2.companyabc.com

In the preceding configuration, the first record has a priority of 10, and as a result, clients would attempt to connect to the server sip.companyabc.com. If the client cannot connect to that server, the second record, with a priority of 20, would be used, and users would attempt to connect to sip2.companyabc.com.

This configuration can provide an automatic failover for inbound Access Edge services. However, failover will not be immediate. Keep in mind that the Lync client will cache records of servers to connect to, and will first attempt to connect to servers in that cache first. This can result in a slight sign-on delay in disaster scenarios while the client discovers the secondary DNS record.

Example for Access Edge federation services:

Click here to view code image

_sipfederationtls._tcp.companyabc.com 86400 IN SRV 10 10 5061 sip.companyabc.com
_sipfederationtls._tcp.companyabc.com 86400 IN SRV 20 10 5061 sip2.companyabc.com

In the preceding configuration, the first record has a priority of 10, and as a result, federated partner Edge Servers would attempt to connect to the server sip.companyabc.com. If the server cannot connect to sip.companyabc.com, the second record, with a priority of 20, would be used, and the server would attempt to connect to sip2.companyabc.com.

This configuration can provide an automatic failover for inbound federation requests; however, it does not account for enhanced federation configurations. Enhanced federation is when organizations define Access Edge server records for a federated partner. In this configuration, federation requests do not query the SRV record for connectivity options. If your organization is deploying enhanced federation, keep this in mind.

Outbound Federation Route

Every Lync Server Topology may have only a single outbound federation route defined. These routes may be defined per site; however, they are defined to a single Edge Server pool. In the event of a failure, this configuration must be manually updated to point to the secondary pool. The steps to perform this are covered in the “Executing Disaster Recovery Procedures” section.

A/V Edge Failover

The A/V Edge services on each Edge Server are statically associated with a Front End pool. No intervention is required in the event of a failure. When users are connected to the secondary pool, they will use the Edge Server pool in the secondary site for media traversal capabilities.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset