Microsoft Lync Server 2010 Edge : Edge Configuration

Edge Server Management Console

Administrators of Live Communications Server 2005 and Office Communications Server 2007 will notice that there is no longer a specialized Microsoft Management Console (MMC) snap-in for managing the Edge Server. Instead, all Edge Server configuration is done within the internal network and then replicated or exported to the Edge Servers.

This model creates a central point of management for the entire deployment so administrators don’t have to manage each server individually. With the Topology Builder approach, each Edge Server pool member is configured identically, which reduces the risk of human error configuring one Edge Server slightly different from another and then having to troubleshoot why one media or signaling path is problematic.

Enabling Edge Server Features

To enable the Edge Servers to process remote access and federation requests, the Access Edge configuration must be updated to enable these features. Figure 1 shows a sample policy configuration. Use the following steps to enable Access Edge features to the Lync Server infrastructure:

Figure 1. Access Edge Configuration

Alternatively, the Lync Server Management Shell also can be used to configure the following setting:

Set-CSAccessEdgeConfiguration –AllowOutsideusers $true –AllowFederatedUsers $true
–EnablePartnerDiscovery $true –EnableArchivingDisclaimer $true AllowAnonymousUsers
$true


					  

There are some additional options available for Access Edge Server configuration that are not exposed in the Lync Server Control Panel. The following parameters can also be used as part of the Set-CSAccessEdgeConfiguration cmdlet to configure external access:

• BeClearingHouse— True or false value indicating whether the Access Edge Servers are directly connected to other organizations. A clearinghouse Access Edge Server can be used to support direct federation between multiple organizations. It can also be considered a federation gateway for multiple internal Lync Server deployments. Typically, this value is false.

• DefaultRouteFQDN— Used to override a default federation route. If it is required to proxy client connections through a specific server for federation, this parameter can be entered. This parameter must be used in conjunction with the UseDefaultRouting parameter.

• UseDefaultRouting— True or false value indicating whether the Access Edge Servers will use a manually entered default route FQDN. This value is false by default, which enables Access Edge Servers to use DNS SRV records for routing federation requests.

• KeepCRLsUpToDateForPeers— True or false value indicating whether the Access Edge Servers will periodically check whether a partner’s certificate is still valid based on the CRL. This parameter is true by default.

• MarkSourceVerifiableOnOutgoingMessages— True or false value indicating whether the Access Edge Servers mark outgoing messages from a verified source. This enables partners to assign a higher level of trust to messages they receive from an organization marking messages as verifiable. This parameter is true by default.

• OutgoingTLSCountForFederatedPartners— Numeric value from 1 to 4 indicating the maximum number of connections that can be used for a federated partner. The default value is 4, but if connections should be more limited, this value can be reduced.

Managing A/V Edge Configuration

By default, an A/V Edge Server applies a global policy, which controls bandwidth limits for users and ports as well as the lifetime of media relay tokens. This setting is not exposed in the Lync Server Control Panel and must be managed with the Lync Server Management Shell.

First, use the Get-CsAVEdgeConfiguration cmdlet to view the Global defaults:

Unless there is a need to limit the values, leave the Global policy in place. To create a new A/V Edge configuration, which applies at the SF site level, use the following command. In this example, the MaxTokenLifetime is increased to 10 days, the bandwidth per user is decreased to 5000 KB, and maximum bandwidth per port is decreased to 2000 KB:

New-CsAVEdgeConfiguration "site:SF" –MaxTokenLifetime "10:00:00"
–MaxBandwidthPerUserKb 5000 –MaxBandwidthPerPortKb 2000

Introducing High Availability

Redundancy for Edge Servers requires just adding more Edge Servers to a pool. Like a Front End pool, up to ten servers can be defined in an Edge Server pool. Load balancing can either be done with DNS load balancing requests or by using a hardware load balancer.

DNS load balancing is done by entering multiple host records for the Edge Server pool name within DNS. When clients or servers attempt to reach a server that is unavailable, they will attempt to use an alternate server.

A hardware load balancer can still be used for Edge Servers in Lync Server, which adds greater load-balancing capabilities at the price of greater complexity. As in prior releases, the internal Access Edge and A/V Authentication Edge interfaces should be load-balanced, but the Web Conferencing Edge internal ports should not be load-balanced.

Adding Edge Servers to a Pool

Adding an additional Edge Server to a pool requires updating and publishing the topology to reflect the change. Use the following steps to add an additional pool member:

Now, publish the topology again and proceed with the new Edge Server installation.