Planning for external user access lync server 2010 (rc)

Microsoft Lync Server 2010
Planning for External User Access
Draft for Release Candidate 8-26-2010

This document is provided “as-is”. Information and views expressed in this document, including
URL and other Internet Web site references, may change without notice. You bear the risk of
using it.

Some examples depicted herein are provided for illustration only and are fictitious. No real
association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any
Microsoft product. You may copy and use this document for your internal, reference purposes.
This document is confidential and proprietary to Microsoft. It is disclosed and can be used only
pursuant to a non-disclosure agreement.

Copyright © 2010. Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveSync, ActiveX, Excel, Forefront, Groove, Hyper-V, Internet
Explorer, Lync, MSDN, MSN, OneNote, Outlook, PowerPoint, RoundTable, SharePoint,
Silverlight, SQL Server, Visio, Visual C++, Windows, Windows Media, Windows PowerShell,
Windows Server, and Windows Vista are trademarks of the Microsoft group of companies. All
other trademarks are property of their respective owners.

Contents
External User Access.........................................................................................................................................1

External Communications Capabilities.............................................................................................................3
Capabilities Available to Internal Users........................................................................................................4
Capabilities Available to Remote Users........................................................................................................4
Capabilities Available to Federated Users....................................................................................................4
Capabilities Available to Public IM Users......................................................................................................5
Capabilities Available to Anonymous Users.................................................................................................5
Planning Process...........................................................................................................................................6
Data Collection..........................................................................................................................................6
Choosing a Topology...............................................................................................................................10
Determining DNS Requirements.............................................................................................................12
Changes in Lync Server 2010 that Affect Planning.....................................................................................23
Certificate Requirements........................................................................................................................23
New Load Balancing Options..................................................................................................................24
Network Address Translation..................................................................................................................24
Simple URL Options.................................................................................................................................25
Reverse Proxy Publishing........................................................................................................................26
Coexistence Changes...............................................................................................................................28

Topologies for External User Access...............................................................................................................30
Reference Architecture...............................................................................................................................30
Assumptions............................................................................................................................................30
Reference Architecture 1: Single Consolidated Edge.................................................................................33
Certificate Summary................................................................................................................................35
Port Summary..........................................................................................................................................36
DNS Summary..........................................................................................................................................44
Reference Architecture 2: Scaled Consolidated Edge (DNS Load Balanced)..............................................48
Port Summary..........................................................................................................................................52
DNS Summary..........................................................................................................................................62
Reference Architecture 3: Scaled Consolidated Edge (Hardware Load Balanced).....................................67
Hardware Load Balancer Requirements:................................................................................................67
Port Summary..........................................................................................................................................72
DNS Summary..........................................................................................................................................84

Components Required for External User Access............................................................................................88
Edge Server.................................................................................................................................................88
Reverse Proxy..............................................................................................................................................88
Firewall........................................................................................................................................................89
Director.......................................................................................................................................................89
Hardware Load Balancers...........................................................................................................................90

Requirements for Edge Components.............................................................................................................90
System Requirements for Edge Components.............................................................................................90
Hardware and Software Requirements for Edge Components..............................................................91
Hardware and Software Requirements for Edge Servers and Directors............................................91
Hardware and Software Requirements for Reverse Proxy Servers, Load Balancers, and Firewalls...92
Supported Server Collocation for Edge Components.............................................................................92

Deployment Best Practices for External User Access.....................................................................................93

External User Access
Much of the communication in your organization probably involves people outside your firewall:
employees who are temporarily or permanently offsite, employees of customer or partner
organizations, people who use public instant messaging (IM) services, and potential customers or
partners whom you invite to meetings and presentations. In this documentation, these people are
referred to as external users.

Note: Diagram will be added to describe external access and the definition of all the different “External
User access” type (e.g. Remote User, Anonymous User etc). So there will be fewer paragraphs in the
document.

With Microsoft® Lync™ Server 2010 communications software, users in your organization can use IM
and presence to communicate with external users, and they can participate in A/V conferencing and
Web conferencing with your offsite employees and other types of external users. You can also support
external access from mobile devices and over Enterprise Voice. External users can sign in to Lync Server
2010 without logging on to your intranet, so they do not have to have an internal account in your
organization. This can facilitate ease of use and performance for external users.

In order to support communications across your organization’s firewall, you deploy Lync Server Edge
Server, in your perimeter network (also known as screened subnet or DMZ). The Edge Server controls
how users outside the firewall can connect to your internal Lync Server deployment. It also controls
communications with external users that originate within the firewall.

Depending on your requirements, you can deploy one or more Edge Servers in one or more locations.
This section describes external user access in Lync Server, and it explains how to plan your edge
topology.

Note:
Although you need an Edge Server to support Enterprise Voice and Microsoft Lync 2010 Mobile
external user access, this section focuses on support for IM, presence, A/V conferencing, and
Web conferencing. For details about support for Enterprise Voice, see Enterprise Voice.

In This Document

• Overview of External User Access
• External Communications Capabilities
• Planning for External User Access
• Topologies for External User Access
• Components Required for External User Access
• Requirements for Edge Components
• Deployment Best Practices for External User Access

1

Microsoft Lync Server 2010 Planning for External User Access

Overview of External User Access
In this documentation, we use the term external user to refer to a user who signs in to your Lync Server
2010 deployment from outside the firewall. External users that you can authorize to use Lync Server
2010 to communicate with internal users (that is, users who sign in to Lync Server 2010 from inside the
firewall) can include the following:

• Remote users Users within your organization who sign in to Lync Server from outside the firewall
using a Virtual Private Network (VPN) when they are not connected to the organization’s network
(for example, business travelers and telecommuters).

• Federated users Users who have an account with a trusted customer or partner organization.
When you have established a trust relationship with this type of organization’s domain, you can
authorize users in that domain to access your Lync Server deployment. This trust relationship is
called federation and is not related to or dependent upon an Active Directory trust relationship.

• Public IM users Users of public instant messaging (IM) services, including any or all of the
following: Windows Live, AOL, and Yahoo!, as well as XMPP-based providers and servers, such as
Google Talk and Jabber. A public IM service provider is a specific type of federated partner. Support
for public IM users has specific requirements that are different from the requirements for users of
other federated partners. Customers that do not have a volume license for Lync Server 2010 will
require a separate license if they choose to configure public IM connectivity with Windows Live
Messenger, AOL, and Yahoo! For details, see http://go.microsoft.com/fwlink/?linkid=197275.

• Anonymous users Users who do not have a user account in your organization’s Active Directory
Domain Services (AD DS)or in a supported federated domain, but who have received invitations to
participate remotely in an on-premises conference.

Your edge deployment authenticates these types of users and controls external access for the following
types of communication:

• IM and presence Authorized external users can participate in IM conversations and conferences, as
well as obtain information about one another’s presence status.

• Web conferencing. Authorized external users can participate in conferences that are hosted on your
Lync Server deployment. Remote users, federated users, and anonymous users can be enabled for
participation in Web conferencing, but conferencing support for public IM users is limited.
Depending on the options that you select, Web conferencing-enabled users can participate in
desktop and application sharing and can act as meeting organizers or presenters.

• A/V conferencing. Authorized external users can share audio and video in conferences that your
Lync Server deployment provides.

In order to control communications across the firewall, you can create global policies that define how
users inside and outside your firewall communicate with each other. You can also configure settings and

2


create and apply policies for individual internal users or for specific types of external users to control
communications with external users. For example, you can allow users in federated domains to access
IM and presence but not A/V conferencing or Web conferencing.

External Communications Capabilities
Lync Server 2010 provides communications capabilities for users inside and outside of your organization.
The type of communications that are supported depends on the type of user. The following table
summarizes the communications capabilities by type of user. The following sections in this document
provide more detail.

Summary of External User Access Capabilities by User Type

Scenario Remote user Federated user PIC/Interop Anonymous user

Presence Yes Yes Yes No

Instant messaging Yes Yes Yes No
(IM) peer-to-peer

IM conferencing Yes Yes No Yes

Collaboration Yes Yes No Yes

Audio/video (A/V) Yes Yes Yes* for the new No
version of
peer-to-peer
Windows Live
Messenger

A/V Conferencing Yes Yes No Yes

File Transfer Yes Yes No No

* For PIC A/V peer-to peer support, you must use the new version of Windows Live Messenger. In this
scenario, only audio is supported.

3


Capabilities Available to Internal Users
With your authorization, users who are logged on to your intranet can communicate with external users
in the following ways:

• IM and presence Users can participate in one-on-one IM conversations with public IM users and IM
Conferences with remote and federated users, as well as view the presence of remote, federated
and public IM users. They can also add remote users, federated users, and public IM users to their
Contact lists.

• Web conferencing Meeting organizers can invite remote users, federated users, and anonymous
users to conferences as either presenter or attendee. Presenters can share applications or their
desktop with federated users, and they can give federated users control.

• A/V conferencing Meeting organizers can specify that meeting audio and video for conferences be
hosted on your internal Lync Server deployment.

Capabilities Available to Remote Users
• IM and presence Users can send instant messages and view presence status without using a virtual
private network (VPN) to log on to the internal network. They can add users from federated
partners and users of supported public IM service providers to their contact list, and they can view
those users’ presence status, even while they are signed in remotely.

• Web conferencing Users can participate in conferences as if they were logged on to the internal
network.

• A/V conferencing Users can participate in A/V conferences as if they were logged on to the internal
network.

Essentially remote users have the same capabilities as internal users.

Capabilities Available to Federated Users
The functionality available to federated users depends on the option you choose during deployment.
You can choose either of these options:

• IM and presence only Users can participate in IM conversations with individual Lync Server users in
your organization and access presence information, but they cannot participate in Lync Server-based
IM multi-party conferences, it is strictly peer to peer conferencing. You can choose this option
whether or not you deploy conferencing support internally.

• IM and presence, Web conferencing, and A/V conferencing Users can participate in IM
conversations with individual Lync Server users in your organization and access presence

4


information, as well as participate in Web conferences and A/V conferences (if they are supported
by your Lync Server deployment). Federated users have access to the full feature set, except for the
Lync Server 2010 address book

Capabilities Available to Public IM Users
The functionality available to federated and public IM users depends on the option you choose during
deployment. You can choose either of these options:

• IM and presence only Users can participate in IM conversations with individual Lync Server users in
your organization and access presence information, but they cannot participate in Lync Server-based
IM multi-party conferences, it is strictly peer to peer conferencing.

• IM and presence, Web conferencing, and A/V conferencing In addition to peer-to-peer IM
conferencing and viewing presence, public IM users can participate in A/V conferencing with
Windows Live Messenger users.
Some conferencing features, including file transfer and application sharing, are not available for public
IM users. The availability of features to public IM users depends on their public IM service provider. For
example, A/V conferencing is available to public IM users only if they are Windows Live users. You can
specify whether you want the edge topology to support IM and presence only or IM and presence, Web
conferencing, and A/V conferencing as part of the deployment process, but you can change this option
after deployment.

Capabilities Available to Anonymous Users
Anonymous users can participate in IM, Web conferences and audio conferences that are hosted on
your internal deployment. Anonymous users require an invitation to gain access to these features.

5


Planning for External User Access
The basic functionality provided by a Lync Server 2010, Edge Server has not changed significantly from
Office Communications Server 2007 R2, but the deployment options have. For example, the following
options are new:

• Topology Builder approach to planning and installation
• DNS load balancing of both internal and external Edge interfaces
• Support for Network Address Translation (NAT) of the A/V Edge for multiple Edge servers in a
pool
• A single public certificate can be applied to Edge interfaces / services that require a certificate
This document focuses on the impact these new options have on planning.

Planning Process
Lync Server 2010 places emphasis on the planning process and typically, the more time you devote to
planning your Edge environment, the less time you’ll spend deploying it. There are four basic steps to
planning but we will focus only on the first; the other three are covered in the Edge Deployment
documentation:

1. Data Collection
2. Edge Planning Tool
3. Topology Builder
4. Run Setup

Data Collection
In Lync Server 2010, you can run the Microsoft Lync Server 2010, Planning Tool without documenting
your existing and proposed IP addresses and Edge server FQDN’s, but it is significantly harder to do so
without causing configuration errors. For example, a common mistake is to reuse FQDN’s from an
existing Edge deployment for your Lync Server 2010 Edge deployment.

Note
Once you’ve run the Planning Tool and exported it to Topology Builder, it cannot be modified. You
have to start over. By documenting your Edge environment, you avoid losing this information.

Therefore, the recommended approach is to use the drawing below to guide you through gathering the
various FQDN and IP addresses that you need to enter into the Planning Tool. By documenting the
current and proposed configuration, you can put the values in the proper context for your production
environment. And, you are forced to think about how you will configure coexistence and new features
such as simple URLs, file shares, dedicated A/V conferencing servers, and DNS load balancing.

6


Data Collection Template for Lync Server 2010 Single Consolidated Edge Environment

7


Data Collection Template for Lync Server 2010 Scaled Consolidated Edge (DNS Load Balanced) Environment

8


Data Collection Template for Lync Server 2010 Scaled Consolidated Edge (Hardware Load Balanced) Environment

9


Choosing a Topology
When you choose a topology, you can pick from the following supported topology options:

1. Single consolidated Edge using network address translation (NAT)

2. Scaled consolidated Edge using NAT and Domain Name System (DNS) load balancing

3. Scaled consolidated Edge using public IP and hardware load balancing

The following table summarizes the functionality available with the three supported Lync Server 2010
topologies. The column headings indicate the functionality available for a given Edge configuration
option. Using the Scaled Edge (DNS load balancer) option as an example, you can see that it supports
high availability, requires network address translation of Edge external interfaces, does not support
publicly routable IP addresses, reduces cost because a hardware load balancer isn’t required and does
not support failover for Exchange UM, public instant messaging (IM) connectivity (PIC) and federation
with earlier versions of Office Communications Server.

Summary of Edge server Topology Options

High NAT Additional public Cost Failover for Exchange UM
availability allowed IP required (remote user), PIC and
federation with older
version of OCS

Single Edge No Yes No Yes No

Scaled Edge Yes Yes No Yes No

(DNS load
balancer)

Scaled Edge Yes No Yes No Yes

(Hardware
load balancer)

Note:
The NAT Allowed and Additional Public IP required columns pertain only to the Edge external
interfaces. A Yes in the NAT Allowed column means that the associated Edge Server topology
supports the use of NAT on the Edge external interfaces. If you decide to use NAT, you must use it
on all three external interfaces. A Yes in the Additional Public IP required column means that you
will need extra public IP addresses to deploy the associated Edge Server topology.

10


The primary decision points for topology selection are High Availability and load balancing; and the
requirement for high availability can influence the load balancing decision.
• High availability If you need high availability, deploy at least two Edge servers in a pool. A
single Edge pool will support up to ten Edge servers. If more capacity is required, you can deploy
multiple Edge pools. As a general rule, 10% of a given user base will need external access.
• DNS load balancing DNS load balancing is the recommended approach for load balancing Lync
Server 2010 Edge servers when using NAT for the Edge external interfaces.
• Hardware load balancing Hardware load balancing is supported for load balancing Lync Server
2010 Edge servers when using publicly routable IP addresses for the Edge external interfaces.
For example, you would use this approach in situations where failover is required for any of the
following applications:
o PIC
o External access to Exchange 2007 UM or Exchange 2010 UM
o Federation with companies running Office Communications Server 2007 R2 or Office
Communications Server 2007
These three applications will continue to operate but they are not DNS load balancing aware
and will only connect to the first Edge Server in the pool; and if that server is unavailable, the
connection will fail.

11


Determining DNS Requirements
Use the following flow chart to determine Domain Name System (DNS) requirements.

12


Split-Brain DNS
Like network address translation (NAT), the term split-brain DNS is defined several different ways. For
this document, the term split-brain DNS means the following (using contoso.com as an example):

Internal DNS:
• Contains a DNS zone called contoso.com for which it is authoritative

13


• The internal contoso.com zone contains:
o DNS A and SRV records for all servers running Lync Server 2010 in the corporate
network
o DNS A and SRV records for the Edge internal interface of each Lync Server 2010, Edge
Server in the perimeter network
o DNS A records for the reverse proxy internal interface of each reverse proxy server in
the perimeter network
• All Lync Server 2010 servers in the perimeter network point to the internal DNS servers for
resolving queries to contoso.com
• All Lync Server 2010 servers and clients running Lync 2010 in the corporate network point to
the internal DNS servers for resolving queries to contoso.com

External DNS:
• Contains a DNS zone called contoso.com for which it is authoritative
• The external contoso.com zone contains:
o DNS A and SRV records for Lync 2010 client auto configuration (optional)
o DNS A and SRV records for the Edge external interface of each Lync Server 2010, Edge
Server in the perimeter network
o DNS A records for the reverse proxy external interface of each reverse proxy server in
the perimeter network

Automatic Configuration without Split-Brain DNS

If split-brain DNS is used, then automatic configuration of the Lync 2010 client will work fine as long as
the _sipinternaltls._tcp SRV record is created in the external DNS contoso.com zone. However, if split-
brain DNS is not in use then client automatic configuration will not work unless one of the workarounds
described below is implemented. This is because Lync 2010 requires that the domain of the target host
match the domain of the user’s SIP URI. This was also the case with previous versions of Communicator.

For example, if a user signs in as cstest01@contoso.com the first SRV record will work for automatic
configuration.

_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061
sip.contoso.com

However, this record will not be used by Lync for automatic configuration even though it is a valid SRV
record because the client’s SIP domain is contoso.com, not litwareinc.com.

_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061
sip.litwareinc.com.

If automatic configuration is required for Lync clients, select one of the following options:

14


• Put host records on each client machine.

• Use Group Policy objects (GPOs) to populate the correct server values.

Note:
This option does not enable automatic configuration, but it does automate the process of
manual configuration, so if this approach is used, the SRV records associated with automatic
configuration are not required.
• Create a .com zone in the internal DNS that matches the external DNS zone and create DNS A
records corresponding to the Lync Server 2010 pool used for automatic configuration. For
example, if a user is homed on pool01.contoso.net but signs into Lync as cstest01@contoso.com,
create an internal DNS zone called contoso.com and inside it, create a DNS A record for
pool01.contoso.com.

• If creating an entire zone in the internal DNS is not an option, you can create dedicated zones
that correspond to the SRV records that are required for automatic configuration, and populate
those zones using dnscmd.exe

dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary

dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061
access.contoso.com.

dnscmd . /zoneadd access.contoso.com. /dsprimary

dnscmd . /recordadd access.contoso.com. @ A 192.168.10.90

dnscmd . /recordadd access.contoso.com. @ A 192.168.10.91

For details, see http://go.microsoft.com/fwlink/?LinkId=200707.

DNS Load Balancing
DNS load balancing is typically implemented at the application level. The application, (for example, a
Lync 2010 client or SIP server), tries to connect to a server in a pool by connecting to one of the IP
addresses resulting from the DNS A query for the pool fully qualified domain name (FQDN).

For example, if there are three front end servers in a pool named pool01.contoso.com, the following will
happen:

• The Office Communicator 14 client will query DNS for pool01.contoso.com and get back three IP
addresses (not necessarily in this order), and cache them
pool01.contoso.com 192.168.10.90



15


• Then, the client attempts to establish a Transmission Control Protocol (TCP) connection to one
of the IP addresses in its cache using a TCP SYN request. If that fails, the client tries the next IP
address in its cache.
• If the TCP SYN request succeeds, the client attempts to connect to the front end server a SIP
REGISTER.
• If the SIP REGISTER attempt fails (for example, a SIP XXX error is returned), the client has
intelligence built in to try each subsequent IP address in its cache.
• If it gets to the end without a successful connection, the user is notified that no Lync Server
2010 servers are available at the moment

Note:
DNS-based load balancing is different from DNS round robin (DNS RR) which typically refers to load
balancing by relying on DNS to provide one IP address corresponding to one of the servers in a pool;
with a different IP being returned every time a DNS A record query is resolved by the DNS Server.
Typically DNS RR only enables load balancing, but does not enable failover; for example, if the
connection to the one IP address returned by the DNS A query fails, the connection fails. Therefore,
DNS round robin it is less reliable than DNS Based Load Balancing.

DNS load balancing is used for the following:

• Load balancing Lync Server SIP servers such as Lync Server Registrar, Director, and Access Edge
• Load balancing Unified Communications Applications Services (UCAS) applications (for example,
Microsoft Lync 2010 Attendant, Response Group application, and Call Park application)
• Draining of UCAS applications
• Load balancing Server to Server (as well as client-to-server) connections for SIP traffic
• Load balancing client to Web Conferencing Edge traffic
• Load balancing other HTTP(s) traffic between servers running Lync Server (for example, Focus)
DNS load balancing cannot be used for:

• DCOM traffic
• Client-to-server web traffic
If multiple DNS records are returned to a DNS SRV query, the Access Edge service always picks the DNS
SRV record with the lowest numerical priority and highest numerical weight. If multiple DNS SRV records
with equal priority and weight are returned, the Access Edge service will pick the SRV record that came
back first from the DNS server.

16


Determining Firewall and 50k Port Range Requirements
Use the following Firewall and Port flowchart to determine firewall requirements and which ports to
open; then review the network address translation (NAT) terminology because NAT can be implemented
in many different ways. For a detailed example of firewall port settings, see the reference architectures
in the Topologies for External User Access section.

Note:
Regarding the 50,000-59,999 port range, the best practice for Lync Server 2010 is to open it
outbound for RDP/TCP for the A/V Edge external interface if corporate policy allows.

17


NAT Requirements for External User Access
NAT is typically a routing function, but newer devices, firewalls, and even hardware load balancers can
be configured for NAT. Rather than focusing on which device is performing NAT, this topic describes the
required NAT behavior instead.

Microsoft Lync Server 2010 does not support NAT for traffic to or from the Edge internal interface, but
for the Edge external interface, the following NAT behavior is required. This documentation uses the
acronyms ChangeDST and ChangeSRC in tables and drawings to define the required behavior as
described below.

• ChangeDST The process of changing the destination IP address on packets destined for the
network that is using NAT. This is also known as transparency, port forwarding, destination NAT
mode, or half-NAT mode.
• ChangeSRC The process of changing the source IP address on packets leaving the network that
is using NAT. This is also known as proxy, secure NAT, stateful NAT, source NAT or full-NAT
mode.

Important:
Some vendors define the process described in ChangeSRC as Source NAT (SNAT) or full-NAT,
which changes both the source and destination IP addresses on traffic leaving the network that
is using NAT, but that is not case for Edge. The Edge Media Relay Authentication Server (MRAS)
changes only the source IP address on packets leaving the Edge external interface.

Regardless of the naming convention used, the NAT behavior required for the Edge server external
interface is as follows:

For traffic from the Internet to the Edge external interface:

• Change the destination IP address of the incoming packet from the Edge external interface
public IP address to the translated IP address of the Edge external interface
• Leave the source IP address intact so there is a return route for the traffic

For traffic from the Edge external interface to the Internet:

• Change the source IP address of the packet leaving the Edge external interface, from the
translated IP address to the public IP address of the Edge external interface so that the internal
Edge IP address is not exposed and because it’s a non-routable IP address.
• Leave the destination IP address intact on the outgoing packets.

18


The figure below shows the distinction between changing the destination IP address (ChangeDST) for
inbound traffic and changing the source IP Address (ChangeSRC) for outbound traffic using the A/V edge
as an example.

The key points are:

• For traffic incoming to the A/V Edge, the source IP address and port do not change but the
destination IP address changes from 131.107.155.30 to the translated IP address of 10.45.16.10.
• For traffic outbound from the A/V Edge back to the workstation, the source IP address changes
from that of the workstation’s public IP address to that of the A/V Edge’s private IP address. And
the destination IP remains the workstation’s public IP address. After the packet leaves the first
NAT device outbound, the rule on the NAT device changes the source IP address from the A/V
Edge’s private IP address (10.45.16.10) to its public IP address (131.107.155.30)

19


A/V Edge Service Port Range Requirements

In most cases, the A/V Edge service requires that external firewall rules allow RTP/TCP and RTP/UDP
traffic in the 50,000 through 59,999 port range to flow in one or both directions. For example, opening
this port range is required to support certain federation scenarios and the following table provides the
details for each scenario. The table assumes that Lync Server 2010 is the primary federation partner and
it is being configured to communicate with one of the three federation partner types listed.

A/V Edge Service Port Range (50,000 – 59,999) Requirements

Federation partner RTP/TCP RTP/TCP (outbound) RTP/UDP RTP/UDP
(inbound) (inbound) (outbound)

Microsoft Lync Server N/A Open if Application Sharing, file N/A N/A
2010 transfer or peer-to-peer Audio with
the new version for Windows Live
Messenger is required.

A/V will use STUN/TCP/443 and
STUN/UDP/3478 but the best
practice is to open RTP/TCP
50,000-59,999 outbound

Microsoft Office N/A Open if Desktop Sharing is required N/A N/A
Communications
Server 2007 R2

A/V will use STUN/TCP/443 and
STUN/UDP/3478

Microsoft Office Open Open Open Open
Communications
Server 2007

Note:
(inbound) refers to RTP/TCP and RTP/UDP traffic from the Internet to the A/V Edge external interface.

(outbound) refers to RTP/TCP and RTP/UDP traffic from the A/V Edge external interface to the Internet.

20


Planning for Certificates
Certificate creation for Edge is simplified in Lync Server 2010.

Create a single public certificate and assign it to following Edge server interfaces:

21


External Interface:

• Access Edge
• Web Conferencing Edge
Internal Interface:

• A/V Authentication Service

Create a single internal certificate and assign it to following Edge server interfaces:

Internal Interface:

• Edge server
For detailed certificate requirements, see the “Changes in Lync Server 2010 that Affect Planning”
section.

22


Changes in Lync Server 2010 that Affect Planning
There are several new features in Lync Server 2010 that can potentially affect the planning process and
they are discussed in detail, later in this section.

Certificate Requirements
Lync Server 2010 supports the use of a single public certificate for Access and Web Conferencing Edge
external interfaces, plus the A/V Authentication Edge internal interface. This leaves the Edge internal
interface, which can use either a private certificate issued by an internal certification authority (CA) or a
public certificate.

Requirements for the public certificate used for access and web conferencing Edge external interfaces +
the A/V authentication Edge internal interface are:

• The certificate must be issued by an approved public CA that supports subject alternative
names. For details, see Knowledge Base article 929395, "Unified Communications Certificate
Partners for Exchange Server and for Communications Server," at
http://support.microsoft.com/kb/929395.

• If the certificate will be used on an Edge pool, it must be created as exportable, with the same
certificate used on each Edge server in the Edge pool.

• The subject name of the certificate is the access Edge external interface fully qualified domain
name (FQDN) or hardware load balancer VIP (for example, access.contoso.com).

• The subject alternative name list contains the FQDNs of the following:

o The access Edge external interface or HLB VIP (for example, access.contoso.com)

Note:
Even though the certificate subject name is equal to the access Edge FQDN, the
subject alternative name must also contain the access Edge FQDN because
Transport Layer Security (TLS) ignores the subject name and uses the subject
alternative name entries for validation.

o The web conferencing Edge external interface or hardware load balancer VIP (for
example, webcon.contoso.com).

o If using client auto-configuration, also include any SIP domain FQDNs used within your
company (for example, sip.contoso.com, sip.fabrikam.com).

Note:
The order of the FQDN’s in the subject alternative names list does not matter.

23


If you are deploying multiple, load-balanced Edge Servers at a site, the A/V authentication certificate
that is installed on each Edge Server must be from the same CA and must use the same private key. This
means that the certificate must be exportable, if it is to be used on more than one Edge Server. It must
also be exportable if you request the certificate from any computer other than the Edge Server.

Requirements for the private (or public) certificate used for the Edge internal interface are as follows:

• The certificate can be issued by an internal CA or an approved public certificate CA.

• If the certificate will be used on an Edge pool, it must be created as exportable, with the same
certificate used on each Edge server in the Edge pool.

• The subject name of the certificate is the Edge internal interface FQDN or HLB VIP (for example,
csedge.contoso.com).

• No subject alternative name list is required.

If you are deploying multiple, load-balanced Edge Servers at a site, the A/V authentication certificate
that is installed on each Edge Server must be from the same CA and must use the same private key. This
means that the certificate must be exportable, if it is to be used on more than one Edge Server. It must
also be exportable if you request the certificate from any computer other than the Edge Server.

New Load Balancing Options
The preferred method for load balancing Lync Server 2010, Edge Server traffic is to use DNS load
balancing on both internal and external interfaces, but Hardware load balancing will still be supported.
For details, see “Choosing a Topology.”

DNS load balancing is now used on User and Director pools. If you have a pool of Edge servers, you need
to consider how they will resolve the internal pool FQDN of the next hop server. The recommend
approach to DNS name resolution is to configure the Lync Server 2010 Edge server internal interface for
either a perimeter or internal DNS server.

Network Address Translation
Unlike Office Communications Server 2007 R2, Lync Server 2010 supports placing Access, Web
Conferencing, and A/V Edge external interfaces behind a router or firewall that performs NAT for both
single and scaled consolidated Edge server topologies.

Using NAT for all Edge external interfaces requires the use of DNS load balancing (DNS LB). In turn, using
DNS LB allows you to reduce the number of public IP address per Edge server in an Edge pool as
described below:

24


Lync Server 2010 Scaled Consolidated Edge (DNS load balancer)

• Requires three public IP address for load balancer virtual IP addresses (one time requirement
that doesn’t increment as more Edge servers are added to the pool), and three public IP
addresses per Edge server in a pool.

Lync Server 2010 Scaled Consolidated Edge (hardware load balancer)

• Requires three public IP addresses per Edge server in an pool

IP Address Requirements for Scaled Consolidated Edge

Number of Edge # of required IP addresses # of required IP addresses
servers per pool
Lync Server 2010 (DNS load balancer) Lync Server 2010 (hardware load balancer)

2 6 3+6

3 9 3+9

4 12 3 + 12

5 15 3 + 15

Simple URL Options
Office Communications Server 2007 R2 embedded links into meeting requests that were unreadable to
most people, making it difficult to troubleshoot. Lync Server 2010 addresses that issue by publishing
meeting information in an easy to read format:

Sample OCS 2007 R2 meeting request:

meet:sip:cstest01@contoso.com;gruu;opaque=app:conf:focus:id:86dddd778f0443
feaad144739eb6d285%3Fconf-key=A3O3Mrxm9

Sample Lync Server 2010 meeting request (shared simple URL syntax)

https://cs.contoso.com/meet/cstest01/D7RDV4KG

Sample Lync Server 2010 meeting request (dedicated simple URL syntax)

https://meet-us.contoso.com/cstest01/D7RDV4KG

When planning your simple URLs, you need to decide whether to use the shared or dedicated format.
Selection criteria for each approach are listed in table x.x;

25


Simple URL format Use for

Shared • Single pool deployments
• Multiple pool deployments where each pool shares global simple URLs
• Multiple pool deployments where each pool has dedicated simple URLs and
public certificate cost is an issue (you can save one certificate per pool buy
using shared simple URLs)

Dedicated • Multiple pool deployments where each pool has dedicated simple URLs
• Deployments where you do not want to potentially expose internal server
names externally

Note
Simple URLs are defined globally, but in some cases you may want to create a different set of simple
URLs (dialin, meet, and if internal, admin) per geography or pool; if so, you can use Windows
PowerShell™ command-line interface to assign them at the pool level.

Reverse Proxy Publishing
Office Communications Server 2007 R2 required publishing of up to five web sites using a reverse proxy
server:

1. Address book files

2. Distribution group expansion

3. Meeting content

4. Phone Edition upgrade files

5. Communicator Web Access

Publishing all five web sites typically required two Reverse Proxy certificates:

• Subject Name = ExternalWebFarmFQDN (for example,ocsrp.contoso.com)

• Subject Name = CWAExternalFQDN (for example,cwa.contoso.com)

Lync Server 2010 supports publishing the same information, and now supports external publishing of
simple URLs for online meetings. Also, Communicator Web Access functionality still exists but has been
renamed Microsoft Lync Web App and is now available as a service on a Standard Edition Front End
Server or on each Front End Server in a Front End pool, rather than a dedicated physical sever. The client

26


is now referred to as the Microsoft Lync Web App instead of the Communicator Web Access client and
supports additional functionality.

Depending on how you configured Office Communications Server 2007 R2 reverse proxy publishing, the
changes in Lync Server 2010 publishing requirements can increase the number of public certificates or
subject alternative name entries required.

Lync Server Reverse Proxy Certificate Requirements

Role/Subject name Subject Used to publish Subject name syntax example
alternative name

externalWebFarmFQDN N/A Address Book files ocsrp.contoso.com

Distribution Group Expansion Note Typically,
Online meeting content ExternalWebFarmFQDN = the
ReverseProxyExternalFQDN
Tanjay Upgrade files

Simple URL / AdminFQDN N/A AdminFQDN is not published N/A
externally. It’s only used
internally.

Simple URL / DialinFQDN N/A Dial-in Conferencing information dialin.contoso.com

Simple URL / MeetFQDN N/A Online Meeting URL meet.contoso.com

Note
• The externalWebFarmFQDN value is used for Lync Server 2010 users. In coexistence scenarios it
is likely there will already be an externalWebFarmFQDN value for existing Office
Communications Server 2007 R2 or Office Communications Server 2007 users. In that scenario,
make a new one dedicated to Lync Server 2010.

• AdminFQDN is blocked from external publication for security reasons.

• DialinFQDN, MeetFQDN and AdminFQDN are referred to as simple URLs in Lync Server 2010 and
it is possible to save a certificate depending on how they are defined. This table assumes you’ve
chosen dedicated Simple URLs for each role. For details on selecting a simple URL format, see
Simple URL Options in the Planning documentation.

Important
If you create and publish dedicated simple URLs (for example, one for each role) and then set up a
pool of Front End Servers based on that configuration, you cannot change to using a single simple
URL for all roles (for example, rp.contoso.com/meet), unless you run setup again on each Front End
Server in the pool. The same requirement applies if converting from a single simple URL format to
using dedicated simple URLs.

27


Coexistence Changes
If you need to coexist with an Office Communications Server 2007 R2 Edge environment---while
providing external user access to a Lync Server 2010 pool---deploy the Lync Server 2010 Edge server(s)
and Director(s) side by side with the existing Edge. Otherwise, Lync Server 2010 will not have full
functionality. Instructions and options for deploying this configuration are included in the Migration
documentation.

To determine whether a specific combination of Edge and user pool combination is supported during
the coexistence period, see the following table.

Edge version Pool version Supported?

Lync Server 2010 Edge Lync Server 2010 pool Yes

Office Communications Server 2007 R2 pool No

Office Communications Lync Server 2010 pool Yes
Server 2007 R2 Edge
Office Communications Server 2007 R2 pool Yes

28


To determine whether a specific combination of Edge, Director and user pool combination is supported
during the coexistence period, see the following table.

Edge version Director version/Pool version combination Supported?

Lync Server 2010 Edge Lync Server 2010 Director Yes

Lync Server 2010 pool

Lync Server 2010 Director No

Office Communications Server 2007 R2 pool

Office Communications Server 2007 R2 Director No


Office Communications Server 2007 R2 Director No


Office Communications Lync Server 2010 Director Yes
Server 2007 R2 Edge

Lync Server 2010 Director No


Office Communications Server 2007 R2 Director Yes


Office Communications Server 2007 R2 Director Yes


29


Topologies for External User Access
Providing external user access for Lync Server requires that you deploy at least one Edge Server and one
reverse proxy in your perimeter network. Additionally, you may need to deploy a Director in your
internal network.

If you need greater capability than a single Edge Server can provide, or if you need high availability for
your edge deployment, you can deploy multiple Edge Servers and configure load balancing. If your
organization has multiple data centers, you can have Edge deployments at more than one location.
However, only one of the Edge deployments can be designated as the federation route.

This section describes the reference topologies for edge deployments. For details about the components
that make up the topology, see Components Required for External User Access.

All edge services run on each Edge Server; services cannot be split between two different Edge servers.
If you deploy a pool of Edge Servers for scalability, all edge services are deployed on each Edge Server in
the pool.

Reference Architecture
Three reference architectures are provided to highlight the Lync Server 2010 topologies that have been
tested and are therefore supported. There are two primary Edge topologies and one alternate:

1. Primary – RA1 Single consolidated Edge using network address translation (NAT)

2. Primary – RA2 Scaled consolidated Edge using NAT and Domain Name System (DNS) load
balancing

3. Alternate – RA3 Scaled consolidated Edge using public IP and hardware load balancing

The recommended approach for deploying Lync Server 2010, Edge Server is to use the Planning Tool to
generate an input file for Topology Builder. The reference architectures in this section are not a
replacement for that process, but instead are a set of drawings and tables designed to assist with it.

For best results you should use the topology flowchart in the “Planning for External User Access” section
to select a topology and then review the reference architecture section that corresponds to it. The
assumptions below apply to all three topologies, and you should review them first.

Assumptions
There are a number of network and environmental factors that can affect Edge server performance. The
reference architectures are designed using best practices to help prevent common configuration issues
and are based on the assumptions defined below. If you choose a different configuration, (for example,

30


a three-leg perimeter network), you may still be able to make it work, but it won’t be a configuration
that has been tested.

• Dedicated perimeter network perimeter network (also known as a DMZ, demilitarized zone, and
screened subnet) with internal and external firewalls.

• Lync Server 2010 supports virtualization of Edge servers but the reference architectures assume
physical servers are used.

• Two network interface cards (NICs) configured as follows:

o Edge internal interface is on a different network than the Edge external interface.

o The Edge external interface NIC has three IP addresses bound to it (that is, Access, Web
Conferencing and A/V, with the Access IP address set to primary and the other two IP
addresses set to secondary).

o Only one default GW is configured and it’s assigned to the Access Edge external
interface and pointed to the external forward IP address.

• Windows Server 2008 strong host model is used on all Edge servers.

• Director is not shown for simplicity but a Director would typically be deployed to reduce the risk
of a denial-of-service attack.

• A static, persistent route is configured from the network containing the Edge internal interface
to all the corporate networks containing CS 14 servers and clients.

• Split-brain DNS (that is, the same domain hosted on internal and external DNS servers) is not
used in the examples specifically to highlight the workarounds required for this configuration
but typically it is deployed.

• Edge servers are pointed to a DNS server in the perimeter because host files do not natively
support DNS load balancing.

• All Edge external interfaces use either NAT, with destination IP addresses changed inbound and
the source IP addresses changed outbound, combined with DNS load balancing. Or, they use
publicly routable IP addresses combined with hardware load balancing.

A hybrid configuration with Access Edge service and Web Conferencing Edge services behind
NAT and the A/V Edge service configured with a publicly routable IP address, is not supported in
Lync Server 2010.

• Router and Firewall functions are integrated into a single device and for reference, the Edge and
reverse proxy server(s) in a perimeter network that is in between an external and internal
integrated router/firewall

31


• Only a single reverse proxy server is shown but if there was an array of reverse proxy servers
deployed in the perimeter network, they would be load balanced using a hardware load
balancer because DNS load balancing does not work with client to server web traffic.

After you have selected a topology and determined your certificate, port and DNS requirements, you
can use one of the three reference architectures to see how a typical deployment will look. You should
then be able to modify the existing tables with your production fully qualified domain names (FQDNs)
and IP addresses and use them to assist with your production deployment.

32


Reference Architecture 1: Single Consolidated Edge
If your organization requires support for fewer than 5,000 Access Edge service client connections, 1,000
active Web Conferencing service client connections, and 500 concurrent A/V Edge sessions, and high
availability of the Edge Server is not important, this topology offers the advantages of lower hardware
cost and simpler deployment. If you need greater capacity or you require high availability, you need to
deploy the scaled consolidated Edge Server topology. For details, see “Reference Architecture 2: Scaled
Consolidated Edge (DNS Load Balanced)” later in this document.

For simplicity, figure x.x does not show any Directors deployed but in a real world production
deployment they are recommended. For more information about the topology for Directors, see
Components and Topologies for Director. The reverse proxy is also not load balanced but if it was, it would
require a hardware load balancer; Domain Name System (DNS) load balancing is not an option for load
balancing reverse proxy traffic.

Note
For clarity, the .com DNS zone represents the external interface for both reverse proxy and
consolidated edge servers, and the .net DNS zone refers to the internal interfaces. Depending on
how your DNS is configured, both interfaces could be in the same zone (for example, in a split-brain
DNS configuration).

33


Single Consolidated Edge Topology

34


Certificate Summary
Before proceeding, take a minute to map the entries in the table with the fully qualified domain names
(FQDNs)/IP addresses shown in the previous figure so that the relationships are clear. For example,
notice there is no certificate assigned to the A/V Edge external interface (av.contoso.com) but there is
an A/V related certificate (avauth.contoso.net) assigned to the Media Authentication Service.

The certificates listed in the following table are required to support the edge topology shown in Figure
x.x. There are three certificates shown for the reverse proxy server to highlight the certificate
requirements for dedicated simple URLs (for example https://dial-in.contoso.com). For deployments
that have a single pool or where multiple pools share the same dial-in conferencing and meeting simple
URLs, you could create a single publishing rule and corresponding certificate. For example, URLs defined
in topology builder as cs.contoso.com/dialin and cs.contoso.com/meet could share a single publishing
rule and certificate with a subject name of cs.contoso.com. For details, see “Simple URL Options”.

Note:
The following table shows a second SIP entry in the subject alternative name list for reference. For
each SIP domain in your organization, you need a corresponding FQDN listed in the certificate
subject alternative name list.

Certificates Required for Single Consolidated Edge Topology

Subject name Subject alternative Certificatio Enhanced Assign to
name entries/Order n authority key usage
(CA) (EKU)

Single Consolidated Edge

access.contoso.com webcon.contoso.com Public Server/Client Assign to the following Edge
Server roles:
sip.contoso.com
External interface:
sip.fabrikam.com
• Access Edge
Internal interface:

• Media Authentication
Service
(using the Lync Server
Certificate Wizard)

csedge.contoso.net N/A Internal Server Assign to the following Edge
Server role:

Internal Interface:

• Edge server
Certificate Wizard)

Reverse Proxy
35


(CA) (EKU)

csweb- N/A Public Server Address Book Service, DGX
ext.contoso.com and IP Device publishing
rules

dialin.contoso.com N/A Public Server Dial-in conferencing
publishing rule

meet.contoso.com N/A Public Server Online meeting publishing
rule

Next Hop Pool

pool01.contoso.net sip.contoso.com Internal Server Assign to the following
servers and roles in the next
sip.fabrikam.com hop pool:

csweb.contoso.net • Front End 01 in Pool01
• Front End 02 in Pool01
csweb-ext.contoso.com
Certificate Wizard)
admin.contoso.com

dialin.contoso.com

• Default Web site on
meet.contoso.com
Front End 01
fe01.contoso.net • Default Web site on
Front End 02
fe02.contoso.net (using the Internet
pool01.contoso.net Information Services (IIS)
Administrative interface)

Port Summary
The Lync Server 2010, Edge Server functionality described in this reference architecture is very similar to
what was first introduced in Office Communications Server 2007 R2, with the following exceptions:

• Port 8080 from the reverse proxy internal interface to the pool virtual IP (VIP)
• Port 4443 from the reverse proxy internal interface to the pool VIP
• Port 4443 from the pool front end(s) to the Edge internal interface
There are several options for the 50,000 – 59,999 port ranges, but the following figure shows the
common configuration for interoperability with previous version of Office Communications Server. For
details on the options for configuring this port range, see “A/V Edge Service Port Range Requirements”.

36


37


Firewall Details for Single/Scaled Consolidated Edge with DNS Load Balancing
External Interface

Protocol / Port Used For

HTTP 80 (out) Downloading certificate revocation lists

DNS 53 (out) External DNS queries

SIP/TLS/443 (in) Client to server SIP traffic for remote user access

SIP/MTLS/5061 (in/out) Federation

PSOM/TLS/443 (in) Remote user access to web conferences for anonymous and federated users

RTP/TCP/50K range (in) Media exchange (for details, see “A/V Edge Service Port Range Requirements”)

Required for Office Communications Server 2007 inter-op

RTP/TCP/50K range (out) Media exchange (for details, see “A/V Edge Service Port Range Requirements”)


Required for Office Communications Server 2007 R2 desktop sharing and federation

Required for Lync Server 2010 application sharing, file transfer, or A/V with Windows
Live Messenger

RTP/UDP/50K range (in) Media exchange ( for details, see “A/V Edge Service Port Range Requirements”)

RTP/UDP/50K range (out) Media exchange ( for details, see “A/V Edge Service Port Range Requirements”)

STUN/UDP/3478 (in/out) External user access to A/V sessions (UDP)

STUN/TCP/443 (in) External user access to A/V sessions and media (TCP)

Internal Interface



PSOM/MTLS/8057 (out) Web conferencing traffic from pool-to-Edge

SIP/MTLS/5062 (out) Authentication of A/V users (Media Authentication service)

STUN/UDP/3478 (out) Preferred path for media transfer between internal and external users (UDP)

STUN/TCP/443 (out) Alternate path for media transfer between internal and external users (TCP)

HTTPS 4443 (out) Pushing Central Management store updates to Edge nodes

38


Note:
When reading the preceding table,

(in) refers to traffic going from a less trusted network to a more trusted network, such as Internet to
Perimeter or Perimeter to corporate), For example, traffic from Internet to the Edge external
interface or from the Edge internal interface to the next hop pool.

(out) refers to traffic going from a more trusted network to a less trusted network, such as
corporate to Perimeter or Perimeter to Internet). For example, traffic from a corporate pool to the
Edge internal interface or from the Edge external interface to the Internet.

(in/out) refers to traffic that is going both directions.

It is recommended that you only open the ports required to support the functionality for which you are
providing external access.

For remote access to work for any edge service, it is mandatory that SIP traffic is allowed to flow bi-
directionally as shown in the previous figure. Stated another way, the Access Edge service is involved in
instant messaging (IM), presence, Web conferencing, and audio/video (A/V).

Firewall Details for Reverse Proxy Server

39


External Interface

Protocol/Port Use For

HTTP 80 (in) (Optional) Redirection to HTTPS if user accidentally enters http://publishedSiteFQDN

HTTPS 443 (in) Address book downloads, address book Web query service, client updates, meeting
content, device updates, group expansion, dial-in conferencing, and meetings.

Internal Interface

Protocol/Port Used For

HTTP 8080 (in) Redirected web conferencing traffic from port 80 externally

HTTPS 4443 (in) Traffic sent to 443 on the reverse proxy external interface is redirected to a pool on
port 4443 from the reverse proxy internal interface so that the pool web services can
distinguish it from internal web traffic

Note:
When reading the previous table,

Perimeter or Perimeter to corporate), For example, traffic from Internet to the reverse proxy
external interface or from the reverse proxy internal interface to a Standard Edition pool or a
hardware load balancer VIP associated with an Front End pool.

40


External Ports Settings Required for Single Consolidated Edge Topology
Edge Source Source Destination Destination Transport Application Notes
role IP address port IP address port

Access 10.45.16.10 80 Any Any TCP HTTP

Access 10.45.16.10 53 Any Any UDP DNS

Web Any Any 10.45.16.20 443 TCP PSOM (TLS)
Conferen
cing

A/V 10.45.16.30 50,000 – Any Any TCP RTP Required only for desktop sharing or
59,999 federation with partners running Office
Communications Server 2007 or Office
Communications Server 2007 R2.

Also required for application sharing and/or
file transfer with Lync Server 2010
federated users.

A/V 10.45.16.30 50,000 – Any Any UDP RTP Required only for federation with partners
59,999 still running Office Communications Server
2007

A/V Any Any 10.45.16.30 50,000 – TCP RTP Required only for federation with partners
2007.

41


role IP address Port IP address port

A/V Any Any 10.45.16.30 50,000 – UDP RTP Required only for federation with partners
2007.

A/V 10.45.16.30 3478 Any Any UDP STUN 3478 outbound is used to determine the
version of Edge server Lync Server 2010 is
communicating with and also for media
traffic from Edge server to Edge server.

Required for federation with Office
Communications Server 2007 R2, and also if
multiple Edge pools are deployed within a
company.

A/V Any Any 10.45.16.30 3478 UDP STUN

A/V Any Any 10.45.16.30 443 TCP STUN

Reverse Proxy

N/A Any Any 10.45.16.40 80 TCP SIP (TLS)

N/A Any Any 10.45.16.40 443 TCP HTTPS

42


Internal Ports Settings Required for Single Consolidated Edge Topology

Access 172.25.33.10 5061 192.168.10.90 Any TCP SIP (MTLS) Destination will be the next hop server(s).
In the case of the reference architecture, it’s
192.168.10.91 the IP addresses of the two pool Front End
Servers.

Access 192.168.10.90 Any 172.25.33.10 5061 TCP SIP (MTLS) Source will be the next hop server(s). In the
case of the reference architecture, it’s the IP
192.168.10.91 addresses of the two pool Front End
Servers.

Web Any Any 172.25.33.10 8057 TCP PSOM (MTLS)
Conferen
cing

A/V 192.168.10.90 Any 172.25.33.10 5062 TCP SIP (MTLS) Include all front end servers using this
particular A/V authentication service.
192.168.10.91



A/V 192.168.10.90 Any 172.25.33.10 4443 TCP HTTPS Used for Central Management Store
database replication, include all Front End
192.168.10.91 servers.

Reverse Proxy

N/A 172.25.33.40 Any 192.168.10.190 8080 TCP SIP (TLS)

N/A 172.25.33.40 Any 192.168.10.190 4443 TCP HTTPS

43


DNS Summary
DNS record requirements for remote access to Lync Server are fairly straightforward compared to those
for certificates and ports. Also, many records are optional, depending on how you configure Lync 2010
clients and whether you enable federation.

For details about Lync Server 2010 DNS requirements, see “Required DNS Records for Edge
Components” in the Lync Server 2010 documentation.

For details on configuring automatic configuration of Lync 2010 clients if split-brain DNS is not
configured, see “Automatic Configuration without Split Brain DNS” earlier in this document.

The following table contains a summary of the DNS records that are required to support the single
consolidated edge topology shown in the Single Consolidated Edge Topology figure. Note that
certain DNS records are required only for automatic configuration of Lync 2010 clients. If you plan to use
Group Policy Objects (GPOs) to configure Lync clients, the associated records are not necessary.

Important: Edge/Reverse Proxy Network Adapter Requirements
To avoid routing issues, verify that there are at least two network adapters in your edge and reverse
proxy servers and that the default gateway is set only on the network adapter associated with the
external interface. For example, as shown in the Single Consolidated Edge Topology figure, the default
gateway would point to the external firewall (10.45.16.1).

You can configure two network adapters in your Edge Server as follows:

Network adapter 1 (Internal Interface)

• Internal interface with 172.25.33.10 assigned
• No default gateway and a static route from 172.25.33.0 to 192.168.10.0. Note: When
configuring the static route you have to enter a gateway value (for example, 172.25.33.2 in the
Single Consolidated Edge Topology figure.)
Network adapter 2 (External Interface)

• Three private IP addresses are assigned to this NIC
• Access Edge IP address is primary with default gateway set to integrated router (10.45.16.1)
• Web Conferencing and A/V Edge IP addresses secondary

44


DNS Records Required for Single Consolidated Edge Topology
Location Type FQDN IP address Port Maps to/Comments

Consolidated Edge

External DNS A access.contoso.com 131.107.155.10/24 Access Edge external interface (contoso)

A access.fabrikam.com 131.107.155.10/24 Access Edge external interface (fabrikam)

A webcon.contoso.com 131.107.155.20/24 Web Conferencing Edge external interface

A av.contoso.com 131.107.155.30/24 A/V Edge external interface

SRV _sip._tls.contoso.com access.contoso.com 443 Access Edge external interface (access.contoso.com)

SRV _sip._tls.fabrikam.com access.fabrikam.com 443 Required for automatic configuration of Lync 2010
clients to work externally
SRV _sipfederationtls._tcp.contoso.com access.contoso.com 5061 Access Edge external interface (access.contoso.com)

SRV _sipfederationtls._tcp.fabrikam.com access.fabrikam.com 5061 Required for enhanced federation

Internal DNS A csedge.contoso.net 172.25.33.10/24 Consolidated Edge internal interface

Reverse Proxy

External DNS A ocsrp.contoso.com 131.107.155.40/24 Used to publish Address Book Service, group
expansion, and conference content
A dialin.contoso.com 131.107.155.40/24
Dial in conferencing published externally
A meet.contoso.com 131.107.155.40/24
Conferences published externally
A csweb-ext.contoso.com 131.107.155.40/24
Lync Server 2010 external web farm FQDN
Internal DNS A rproxy.contoso.com 172.25.33.40/24
Reverse proxy internal interface


Next Hop Pool

45



Internal DNS A pool01.contoso.net 192.168.10.90/24 Pool01 (DNS load balancer)

A pool01.contoso.net 192.168.10.91/24 Pool01 (DNS load balancer)

A fe01.contoso.net 192.168.10.90/24 Pool01 Front End Server (NODE 1)


A csweb.contoso.net 192.168.10.190/24 Pool01 (VIP) for client to server web traffic

A sql01.contoso.net 192.168.10.100/24 Pool01 back end Microsoft SQL Server® 2005/
Microsoft SQL Server 2008 database server
A pool01.contoso.com 192.168.10.90/24
Pool01 (DNS LB) – for automatic configuration of
A pool01.fabrikam.com 192.168.10.90/24 Lync 2010 clients to work internally
A sip.contoso.com 192.168.10.90/24 Pool01 (DNS LB) – for automatic configuration of
Lync 2010 clients to work internally
A sip.fabrikam.com 192.168.10.90/24
Required for automatic configuration of Lync 2010
clients to work internally
A admin.contoso.com 192.168.10.190/24 clients to work internally

Dial-in conferencing published internally

Conferences published internally

Lync Server 2010 Control Panel published internally

SRV _sipinternaltls._tcp.contoso.com pool01.contoso.com 5061 Required for automatic configuration of Lync 2010

SRV _sipinternaltls._tcp.fabrikam.com pool01.fabrikam.com 5061 Required for automatic configuration of Lync 2010

SRV _ntp._udp.contoso.com timeServerFQDN 123 Network Time Protocol (NTP) source required for
Microsoft Lync 2010 Phone Edition devices

46


VIP = Virtual IP address

Important:
The records listed in the previous table are shown with either a .net extension or a .com extension to highlight which zone they need to reside
in if you are not using split-brain DNS. If you are using split-brain DNS, all records would be in the same zone, with the only distinction being
whether they are in the internal or external version For details, see “Split-Brain DNS” earlier in this document.

47


Reference Architecture 2: Scaled Consolidated Edge (DNS Load
Balanced)
In the Edge Server pool topology, two or more Edge Servers are deployed as a load-balanced pool in the
perimeter network of the data center. DNS load balancing is used for traffic to both the external and
internal Edge interfaces.

If your organization requires support for more than 5,000 Access Edge service client connections, 1,000
active Web Conferencing service client connections, or 500 concurrent A/V Edge sessions, and/or high
availability of the Edge Server is important, this topology offers the advantages of scalability and failover
support.

For simplicity, the following figure does not show any Directors deployed but in a real world production
deployment they are recommended. For details about the topology for Directors, see Components and
Topologies for Director. The reverse proxy is also not load balanced. If it was, it would require a hardware
load balancer; DNS load balancing is not an option for load balancing reverse proxy traffic.

Note
DNS configuration).

48


Scaled Consolidated Edge Topology (DNS Load Balanced)

49


Certificate Summary
(FQDNs)/IP addresses shown in the Scaled Consolidated Edge Topology (DNS Load Balanced) figure so
that the relationships are clear. For example, notice there is no certificate assigned to the A/V Edge
external interface (av.contoso.com) but there is an A/V related certificate (avauth.contoso.net) assigned
to the Media Authentication Service.

The certificates listed in the following table are required to support the edge topology shown in Figure
x.x. There are three certificates shown for the reverse proxy server to highlight the certificate
requirements for dedicated simple URLs (for example https://dial-in.contoso.com). For deployments
that have a single pool or where multiple pools share the same dial-in conferencing and meeting simple
URLs, you could create a single publishing rule and corresponding certificate. For example, URLs defined
in topology builder as cs.contoso.com/dialin and cs.contoso.com/meet could share a single publishing
rule and certificate with a subject name of cs.contoso.com. For details, see “Simple URL Options”.

Note:


Important:
The public certificate used on the Edge interfaces must be created as exportable certificates and the
same certificate must be assigned to each Edge server in the pool.

Certificates Required for Scaled Consolidated Edge Topology (DNS Load Balanced)

Subject name Subject alternate Certificatio Enhanced Assign to
(CA) (EKU)

Scaled Consolidated Edge

server roles on each server
sip.contoso.com in the Edge pool:

sip.fabrikam.com External interface:

• Access Edge
Internal interface:

Service
Certificate Wizard)


50


Subject name Subject alternate Certificatio Enhanced Assign to
(CA) (EKU)

server role:

Internal Interface:

• Edge server
Certificate Wizard)

Reverse Proxy

csweb- N/A Public Server ABS, DGX and IP Device
ext.contoso.com publishing rules

publishing rule

meet.contoso.com N/A Public Server Online meeting publishing
rule

Next Hop Pool

servers and roles in the
sip.fabrikam.com Next Hop Pool:

Certificate Wizard)
admin.contoso.com

dialin.contoso.com

meet.contoso.com
Front End 01
Front End 02
administrative interface)

51


Port Summary
The Lync Server 2010 edge functionality described in this reference architecture is very similar to what
was first introduced in Office Communications Server 2007 R2, with the following exceptions:

• Port 4443 from the reverse proxy internal interface to the pool VIPPort 4443 from the pool front
end(s) to the Edge internal interface
• If DNS load balancing is deployed, all traffic now goes to each Edge server (external and internal
interfaces) instead of being split between a hardware load balancer VIP and the Edge server
interfaces
There are several options for the 50,000 – 59,999 port ranges, but the following figure shows the
common configuration for interoperability with previous versions of Office Communications Server. For
details about the options for configuring this port range, see “A/V Edge Service Port Range
Requirements”.

52


53


Firewall Details for Single / Scaled Consolidated Edge with DNS Load Balancing

External Interface




SIP/TLS/443 (in) Client to server SIP traffic for remote user access


PSOM/TLS/443 (in) Remote user access to web conferences for anonymous and federated users





Required for Office Communications Server 2007 R2 desktop sharing and federation

Required for Lync Server 2010 application sharing, file transfer or A/V with Windows
Live Messenger

RTP/UDP/50K range (in) Media exchange (for details, see “A/V Edge Service Port Range Requirements”)

RTP/UDP/50K range (out) Media exchange (for details, see “A/V Edge Service Port Range Requirements”)

STUN/UDP/3478 (in/out) External user access to A/V sessions (UDP)

STUN/TCP/443 (in) External user access to A/V sessions and media (TCP)

Internal Interface



PSOM/MTLS/8057 (out) Web conferencing traffic from pool-to-Edge

SIP/MTLS/5062 (out) Authentication of A/V users (Media Authentication service)

STUN/UDP/3478 (out) Preferred path for media transfer between internal and external users (UDP)

STUN/TCP/443 (out) Alternate path for media transfer between internal and external users (TCP)

HTTPS 4443 (out) Pushing Central Management store updates to Edge nodes

54


Note:





instant messaging (IM), presence, Web conferencing, and audio/video (A/V).


55


External Interface

Protocol/Port Use for

HTTP 80 (in) (Optional)Redirection to HTTPS if user accidentally enters http://publishedSiteFQDN

HTTPS 443 (in) Address book downloads, address book Web query service, client updates,
conference content, device updates, group expansion, dial-in conferencing, and
conferences.

Internal Interface


HTTP 8080 ( in ) Redirected web conferencing traffic from port 80 externally

HTTPS 4443 ( in ) Traffic sent to 443 on the reverse proxy external interface is redirected to a pool on

Note:

hardware load balancer VIP associated with an Front End pool.

56


External Ports Settings Required for Scaled Consolidated Edge Topology (DNS Load Balanced)

External Interface – Node 1



Conferen
cing


federated users.

2007

2007.

57



2007.

version of Edge Server that Lync Server
2010 is communicating with and also for
media traffic from Edge Server-to-Edge
Server.

company.






Conferen
cing

59,999 federation with partners still running Office
Communications Server 2007.


58



2007.

2007.

2007.

Server.

company.



Reverse Proxy



59


Internal Firewall Ports Settings Required for Scaled Consolidated Edge Topology (DNS Load Balanced)

Internal Interface – Node 1

Servers.

Servers.

Conferen
cing

A/V 192.168.10.90 Any 172.25.33.10 5062 TCP SIP (MTLS) Include all Front End Servers using this
particular A/V Authentication service.
192.168.10.91



A/V 192.168.10.90 Any 172.25.33.10 4443 TCP HTTPS Used for Central Management store
replication, include all Front End Servers.
192.168.10.91


Servers.

60



case of the reference architecture, it is the
192.168.10.91 IP addresses of the two pool Front End
Servers.

Conferen
cing

192.168.10.91



192.168.10.91

Reverse Proxy

N/A 172.25.33.40 Any 192.168.10.190 8080 TCP SIP (TLS)

N/A 172.25.33.40 Any 192.168.10.190 4443 TCP HTTPS

61


DNS Summary
for certificates and ports. Also, many records are optional, depending on how you configure Lync clients
and whether you enable federation.

For details on Lync Server 2010 DNS requirements, see “Required DNS Records for Edge Components” in
the Lync Server 2010 help file.

For details about configuring automatic configuration of Lync 2010 clients if split-brain DNS is not
configured, see “Automatic Configuration without Split Brain DNS” earlier in this document.

The following table contains a summary of the DNS records that are required to support the scaled
consolidated edge topology shown in the Single Consolidated Edge Topology figure. Note that
certain DNS records are required only for Office Communicator client automatic configuration. If you
plan to use Group Policy Objects (GPOs) to configure Lync clients, the associated records are not
necessary.

To avoid routing issues, verify that there are at least two network adapters in your edge and reverse
proxy servers and that the default gateway is set only on the network adapter associated with the
external interface. For example, as shown in the Scaled Consolidated Edge Topology (DNS Load
Balanced)figure, the default gateway would point to the external firewall (10.45.16.1).



configuring the static route you have to enter a gateway value (for example, 172.25.33.2 in the
Scaled Consolidated Edge Topology figure).

• Three private IP addresses are assigned to this NIC

62


Table x.x DNS Records Required for Scaled Consolidated Edge Topology (DNS Load Balanced)

Consolidated Edge

External DNS A access.contoso.com 131.107.155.10/24 Access Edge external interface (NODE 1)

A access.contoso.com 131.107.155.11/24 Access Edge external interface (NODE 2)

A access.fabrikam.com 131.107.155.10/24 Access Edge external interface (NODE 1)

A access.fabrikam.com 131.107.155.11/24 Access Edge external interface (NODE 2)

A webcon.contoso.com 131.107.155.20/24 Web Conferencing Edge external interface (NODE 1)

A webcon.contoso.com 131.107.155.21/24 Web Conferencing Edge external interface (NODE 2)

A av.contoso.com 131.107.155.30/24 A/V Edge external interface (NODE 1)

A av.contoso.com 131.107.155.31/24 A/V Edge external interface (NODE 2)


SRV _sip._tls.fabrikam.com access.fabrikam.com 443 Required for automatic configuration of Lync 2010
clients to work externally


Internal DNS A csedge.contoso.net 172.25.33.10/24 Consolidated Edge internal interface (DNS load
balancer)
A csedge.contoso.net 172.25.33.11/24
Consolidated Edge internal interface (DNS load
A con01.contoso.net 172.25.33.10/24 balancer)
A con02.contoso.net 172.25.33.11/24 Consolidated Edge internal interface (NODE 1)

Consolidated Edge internal interface (NODE 2)

Reverse Proxy

63



Dial-in conferencing published externally
Conference published externally

Location Type FQDN IP Address Port Maps To/Comments

Next Hop Pool

64








A sql01.contoso.net 192.168.10.100/24 Pool01 Back End Server running Microsoft SQL
Server® 2005/ Microsoft SQL Server 2008 database
A pool01.contoso.com 192.168.10.90/24 server
A pool01.fabrikam.com 192.168.10.90/24 Pool01 (DNS load balancer) – for automatic
configuration of Lync 2010 clients to work internally
A sip.contoso.com 192.168.10.90/24
Pool01 (DNS load balancer) – for automatic
configuration of Lync 2010 clients to work internally
A meet.contoso.com 192.168.10.190/24 clients to work internally

A admin.contoso.com 192.168.10.190/24 Required for automatic configuration of Lync 2010




SRV _sipinternaltls._tcp.contoso.com pool01.contoso.com 5061 Required for automatic configuration of Lync 2010

SRV _sipinternaltls._tcp.fabrikam.com pool01.fabrikam.com 5061 Required for automatic configuration of Lync 2010


65



Important:
in if you are not using split-brain DNS. If you are using split-brain DNS, all records would be in the same zone, with the only distinction being
whether they are in the internal or external version. For details, see “Split-Brain DNS” earlier in this document.

66


Reference Architecture 3: Scaled Consolidated Edge
(Hardware Load Balanced)
In the Edge Server pool topology, two or more Edge Servers are deployed as a load-balanced pool in the
perimeter network of the data center. Hardware load balancing is used for traffic to both the external
and internal Edge interfaces.

If your organization requires support for more than 5,000 Access Edge service client connections, 1,000
active Web Conferencing service client connections, or 500 concurrent A/V Edge sessions, and/or high
availability of the Edge Server is important, this topology offers the advantages of scalability and failover
support.

For simplicity, the following figure does not show any Directors deployed but in a real world production
deployment they are recommended. For more information about the topology for Directors, see
Components and Topologies for Director. The reverse proxy is also not load balanced but if it was, it would
require a hardware load balancer. DNS load balancing is not an option for load balancing reverse proxy
traffic.

Note
DNS configuration).

Hardware Load Balancer Requirements:
AV Edge Hardware Load Balancer Requirements

1. Turn off TCP nagling for both internal and external ports 443. Nagling is the process of
combining several small packets into a single, larger packet for more efficient transmission.
2. Do not use NAT for internal and external Firewall.
3. Edge internal interface must be on a different network than the Edge external interface.
4. The A/V Edge external interface must use publically routable IP addresses.
5. Change only the destination IP address for inbound traffic to the A/V Edge external interface.

67


Web Service Hardware Load Balancer Requirements

1. For external Web service VIPs, set cookie based Persistence on a per port basis for external
ports 4443, 8080 on the hardware load balancer.
2. For internal Web service VIPS, set Source_addr persistence (internal port 80, 443) on the
hardware load balancer.
3. Use default persistence of 300 seconds; if connection or performance issues are encountered,
increase the persistence setting to 1800 seconds.
4. For reverse proxy rules, set “Forward host header” to True. This will ensure that the original URL
is forwarded.
5. For the firewall between reverse proxy and hardware load balancer, create two new rules. One
to allow https: traffic on port 4443, from reverse proxy to hardware load balancer, and a second
to allow http: traffic on port 8080 from reverse proxy to hardware load balancer. The hardware
load balancer must be configured to listen on ports 80, 8080, 443 and 4443.

68


Scaled Consolidated Edge Topology (Hardware Load Balanced)

69


Certificate Summary
(FQDNs)/IP addresses shown in the Scaled Consolidated Edge Topology (Hardware Load Balanced) figure
so that the relationships are clear. For example, notice there is no certificate assigned to the A/V Edge
external interface (av.contoso.com) but there is an A/V related certificate (avauth.contoso.net) assigned
to the Media Authentication Service.

The certificates listed in the following table are required to support the edge topology shown in the
Scaled Consolidated Edge Topology (Hardware Load Balanced) figure. There are three certificates shown
for the reverse proxy server to highlight the certificate requirements for dedicated simple URLs (for
example https://dial-in.contoso.com). For deployments that have a single pool or where multiple pools
share the same dial-in conferencing and meeting simple URLs, you could create a single publishing rule
and corresponding certificate. For example, URLs defined in topology builder as cs.contoso.com/dialin
and cs.contoso.com/meet could share a single publishing rule and certificate with a subject name of
cs.contoso.com. For details, see “Simple URL Options.”

Note:


Important:
The public certificate used on the Edge interfaces must be created as exportable certificates and the
same certificate must be assigned to each Edge Server in the pool.

Certificates Required for Scaled Consolidated Edge Topology (Hardware Load Balanced)

(CA) (EKU)

Scaled Consolidated Edge

Server roles on each server
sip.contoso.com in the Edge pool:

sip.fabrikam.com External interface:

• Access Edge
Internal interface:

Service
Certificate Wizard)

70


(CA) (EKU)

Server role:

Internal Interface:

• Edge server
Certificate Wizard)

Reverse Proxy

csweb- N/A Public Server Address Book Service, DGX
ext.contoso.com and IP Device publishing
rules

publishing rule

meet.contoso.com N/A Public Server Conference publishing rule

Next Hop Pool

servers and roles in the next
sip.fabrikam.com hop pool:

Certificate Wizard)
admin.contoso.com

dialin.contoso.com

meet.contoso.com
Front End 01
Front End 02
administrative interface)

71


Port Summary
The Lync Server 2010 edge functionality described in this reference architecture is very similar to what
was first introduced in Office Communications Server 2007 R2, with the following exceptions:

• Port 4443 from the pool front end(s) to the Edge internal interface
There are several options for the 50,000 – 59,999 port ranges but the following figure shows the
common configuration for interoperability with previous versions of Office Communications Server. For
details on the options for configuring this port range, see “A/V Edge Service Port Range Requirements”.

72


73


Firewall Details for Scaled Consolidated Edge with Hardware Load Balancing

74


Note: External Interface




SIP/TLS/443 (in) Client to server SIP traffic for remote user access. Open to Access Edge external VIP
only (not individual Edge pool servers)

SIP/MTLS/5061 (in/out) Federation. Open to Access Edge external VIP only (not individual Edge pool servers)

PSOM/TLS/443 (in) Remote user access to web conferences for anonymous and federated users. Open
to Web Conferencing Edge external VIP only (not individual Edge pool servers)





Required for Office Communications Server 2007 R2 Desktop Sharing and Federation

Required for Lync Server 2010 application sharing, file transfer or A/V with Windows
Live Messenger

RTP/UDP/50K range (in) Media exchange (for details, see “A/V Edge Service Port Range Requirements”)

RTP/UDP/50K range (out) Media exchange (for details, see “A/V Edge Service Port Range Requirements”)

STUN/UDP/3478 (in/out) External user access to A/V sessions (UDP). Open to A/V Edge external VIP and
individual Edge pool servers

STUN/TCP/443 (in) External user access to A/V sessions and media (TCP). Open to A/V Edge external VIP
and individual Edge pool servers

Internal Interface


SIP/MTLS/5061 (in/out) Federation. Open to Edge internal VIP and individual Edge pool servers

PSOM/MTLS/8057 (out) Web conferencing traffic; pool to Edge. Open to individual Edge pool servers only

SIP/MTLS/5062 (out) Authentication of A/V users (media authentication service). Open to Edge internal
VIP only (not individual Edge pool servers)

STUN/UDP/3478 (out) Preferred path for media transfer between internal and external users (UDP). Open
to Edge internal VIP and individual Edge pool servers

STUN/TCP/443 (out) Alternate path for media transfer between internal and external users (TCP). Open
to Edge internal VIP and individual Edge pool servers

HTTPS 4443 (out) Pushing Central Management store updates to Edge nodes. Open to individual Edge
pool servers only

75







IM, presence, Web conferencing, and audio/video A/V.

76



External Interface

Protocol/Port Used for

HTTP 80 (in) (Optional) Redirection to HTTPS if user accidentally enters http://publishedSiteFQDN

HTTPS 443 (in) Address book downloads, address book Web query service, client updates, meeting
content, device updates, group expansion, dial-in conferencing, and conferences.

Internal Interface


HTTP 8080 ( in ) Redirected web conferencing traffic from port 80 externally

HTTPS 4443 ( in ) Traffic sent to 443 on the reverse proxy external interface is redirected to a pool on

Note:

hardware load balancer VIP associated with a Front End pool.

77


Table x.x External Ports Settings Required for Scaled Consolidated Edge Topology (Hardware Load Balanced)

External Interface – VIP(s)

Access Any Any 131.107.155.110 443 TCP SIP (TLS)

Access 131.107.155.110 5061 Any Any TCP SIP (MTLS)

Access Any Any 131.107.155.110 5061 TCP SIP (MTLS)

Conferen
cing







federated users.

2007


78



2007.


2007.

Server.

company.






59,999 federation with partners still running Office
Communications Server 2007.

2007.

79



2007.

2007.

Server.

company.



Reverse Proxy



80


Internal Firewall Ports Settings Required for Scaled Consolidated Edge Topology (Hardware Load Balanced)

Internal Interface – VIP

Access 172.25.33.110 5061 192.168.10.90 5061 TCP SIP (MTLS)

192.168.10.91

Access 192.168.10.90 5061 172.25.33.110 5061 TCP SIP (MTLS)

192.168.10.91

A/V Any Any 172.25.33.110 5062 TCP SIP (MTLS)




Servers.

Servers.

Conferen
cing


81



192.168.10.91



192.168.10.91


Servers.

case of the reference architecture, it is the
192.168.10.91 IP addresses of the two pool Front End
Servers.

Conferen
cing

A/V 192.168.10.90 Any 172.25.33.11 5062 TCP SIP (MTLS) Include all front end servers using this
particular A/V authentication service.
192.168.10.91



192.168.10.91

Reverse Proxy

82



N/A 172.25.33.40 Any 192.168.10.190 8080 TCP SIP (TLS)

N/A 172.25.33.40 Any 192.168.10.190 4443 TCP HTTPS

83


DNS Summary
for certificates and ports. Also, many records are optional, depending on how you configure Lync Server
clients and whether you enable federation.

For details on Lync Server 2010 DNS requirements, see “Required DNS Records for Edge Components” in
the Lync Server 2010 documentation.

For details on configuring automatic configuration of Lync clients if split-brain DNS is not configured, see
“Automatic Configuration without Split Brain DNS” earlier in this document.

The following table contains a summary of the DNS records that are required to support the scaled
consolidated edge topology shown in the Scaled Consolidated Edge Topology (Hardware Load Balanced)
figure. Note that certain DNS records are required only for Lync client automatic configuration. If you
plan to use Group Policy Objects (GPOs) to configure Lync clients, the associated records are not
necessary.

To avoid routing issues be sure there are at least two network adapters in your edge and reverse proxy
servers and that the default gateway is set only on the network adapter associated with the external
interface. For example, as shown in the Scaled Consolidated Edge Topology (Hardware Load Balanced)
figure, the default gateway would point to the external firewall (10.45.16.1).



configuring the static route you have to enter a gateway value (for example, 172.25.33.2 in
Scaled Consolidated Edge Topology (Hardware Load Balanced figure).

• Three public IP addresses are assigned to this NIC

84


DNS Records Required for Scaled Consolidated Edge Topology (Hardware Load Balanced)

Consolidated Edge

External DNS A access.contoso.com 131.107.155.110/24 Access Edge external interface (VIP)

A access.fabrikam.com 131.107.155.110/24 Access Edge external interface (VIP)

A webcon.contoso.com 131.107.155.120/24 Web Conferencing Edge external interface (VIP)

A av.contoso.com 131.107.155.130/24 A/V Edge external interface (VIP)


SRV _sip._tls.fabrikam.com access.fabrikam.com 443 Required for Office Communicator automatic
configuration to work externally


Internal DNS A csedge.contoso.net 172.25.33.110/24 Consolidated Edge internal interface (VIP)



Reverse Proxy

Dial-in conferencing published externally
Conferences published externally

85



Next Hop Pool






A sql01.contoso.net 192.168.10.100/24 Pool01 Back End Server running Microsoft SQL
Server® 2005/ Microsoft SQL Server 2008 database
A pool01.contoso.com 192.168.10.90/24 server
A pool01.fabrikam.com 192.168.10.90/24 Pool01 (DNS load balancer) – for automatic
configuration of Lync clients to work internally
A sip.contoso.com 192.168.10.90/24
Pool01 (DNS load blaancer) – for automatic
configuration of Lync clients to work internally
Required for automatic configuration of Lync clients to
A meet.contoso.com 192.168.10.190/24 work internally

A admin.contoso.com 192.168.10.190/24 Required for automatic configuration of Lync clients to
work internally




SRV _sipinternaltls._tcp.contoso.com pool01.contoso.com 5061 Required for automatic configuration of Lync clients to
work internally

SRV _sipinternaltls._tcp.fabrikam.com pool01.fabrikam.com 5061 Required automatic configuration of Lync clients to
work internally

86





Important:
in if split-brain DNS is not in use. If you’re using split-brain DNS, all records would be in the same zone, with the only distinction being whether
they are in the internal or external version For details, see “Split-Brain DNS” earlier in this document.

87


Components Required for External User Access
Most edge components are deployed in a perimeter network (also known as a DMZ,
demilitarized zone, or screened subnet). The following components make up the edge topology
of the perimeter network. Except where noted, the components are part of all three reference
architectures and are in the perimeter network. Edge components include the following:

• Edge Server(s)

• Reverse proxy

• Load balancer (Edge Server pool topology only)

• Firewall

• Director (in internal network)

Edge Server
The Edge Server controls traffic across the firewall and usage of the internal deployment by
external users. The Edge Server runs the following services:

• Access Edge service The Access Edge service provides a single, trusted connection point for
both outbound and inbound Session Initiation Protocol (SIP) traffic.

• Web Conferencing Edge service The Web Conferencing Edge service enables external users
to join meetings that are hosted on your internal Lync Server 2010 deployment. It also
processes meeting invitations that your internal and remote users send to federated, public,
and anonymous users.

• A/V Edge service The A/V Edge service makes audio, video, application sharing and file
transfer available to external users. Your users can add audio and video to meetings that
include external participants, and they can share audio and video directly with an external
user in point-to-point sessions. The A/V Edge service also provides support for desktop
sharing and file transfer.

Authorized external users can access the Edge Servers in order to connect to your internal Lync
Server deployment, but the Edge Servers do not provide any other access to the internal
network.

Reverse Proxy
The reverse proxy is required for the following:

88

• To enable external users to download meeting content

• To enable external users to expand distribution groups

• To enable remote users to download files from the Address Book Server or to submit
queries to the Address Book Web Query service

• To enable remote users to obtain updates to client and device software

Note:
External users do not need a VPN connection to your organization in order to participate
in Lync Server-based communications. External users who are connected to your
organization’s internal network over a VPN bypass the reverse proxy.

Firewall
You can deploy your edge topology with only an external firewall or both external and internal
firewalls. The reference architectures include two firewalls; using two firewalls is the
recommended approach because it ensures strict routing and port mapping from one network
edge to the other, and it protects your internal deployment behind two levels of firewall.

Director
A Director is an Enterprise pool that does not home users. Instead, it serves as an internal next-
hop server to which an Edge Server routes inbound SIP traffic destined for internal servers. The
Director authenticates inbound requests and redirects them to the user’s home pool or server.

If your organization is going to enable external access, we recommend that you deploy a
Director. By authenticating inbound SIP traffic from remote users, the Director relieves Front
End pool servers from the overhead of performing authentication of remote users. It also helps
insulate home servers and Front End pools from malicious traffic such as denial-of-service
attacks; if the network is flooded with invalid external traffic in such an attack, this traffic ends
at the Director, and internal users should not see any effect on performance. For details about
the use of Directors, see Director.

89


Hardware Load Balancers
The Lync Server 2010 scaled consolidated Edge topology is optimized for DNS load balancing but
hardware load balancing is still supported. If you choose to deploy hardware load balancers, you
can configure them for on both the external and internal interfaces of the Edge Server pool.

Regardless of whether you use hardware load balancing for your Edge server pool, you will need
a hardware load balancer if there are two or more reverse proxy servers deployed.
Note:
If you are using a hardware load balancer, the load balancer deployed for connections
with the internal network must be configured to load-balance only the traffic to the
Access Edge service and the A/V Edge service. It cannot load-balance the traffic to the
internal Web Conferencing Edge service.

Note:
The direct server return (DSR) NAT mode applies only to hardware load balancers and is
used in cases where a hardware load balancer is a bottleneck for traffic flow. With DSR NAT,
servers are tricked into accepting traffic for a VIP, but instead of sending a response back to
the hardware load balancer, it’s sent directly to a router. Direct server return NAT is not
supported with Lync Server 2010.

Requirements for Edge Components
Support for external user access for Lync Server requires meeting specific infrastructure and
system requirements.

• System Requirements for Edge Components

• Infrastructure Requirements for External User Access

System Requirements for Edge Components
System requirements for edge components include hardware, software, and collocation
requirements for Edge Servers, as well as for any Directors and reverse proxy servers that you
plan to deploy.

• Hardware and Software Requirements for Edge Components

• Supported Server Collocation for Edge Components

90

Hardware and Software Requirements for Edge Components
The hardware and software requirements for edge components include those for the Lync
Server-based components, including Edge Servers and Directors, as well as those for other
components, including reverse proxy servers, firewalls, and load balancers to be deployed the
perimeter network to support external user access. For more information about the
components required to support external user access and supported topologies, see Components
Required for External User Access.

Hardware and Software Requirements for Edge Servers and Directors
The hardware and software requirements for each Edge Server are the same as those for any
other core Lync Server component that you deploy. Directors are internal components and
installed as part of the internal network prior to deployment of Edge Servers. For hardware and
software requirements for Directors, see Requirements for Director.

The following table shows the hardware requirements for Edge Servers.

Hardware System Requirements for Edge Servers

Hardware component Minimum requirement

CPU One of the following:

• 64-bit dual processor, quad-core, 2.0 GHz
or higher

• 64-bit 4-way processor, dual-core, 2.0 GHz
or higher

Memory 12 GB recommended

Disk Local storage with at least 30 GB free disk
space

Network 2-port 1 Gbps network adapter
(recommended)

Lync Server 2010 is available only in a 64-bit edition, so each Edge Server and Director requires
one of the following operating systems.

• The 64-bit edition of Windows Server 2008 Enterprise Edition with SP2 operating system, or
the 64-bit edition of Windows Server 2008 Standard Edition with SP2 operating system.

• The 64-bit edition of Windows Server 2008 R2 Enterprise operating system, or the 64-bit
edition of Windows Server 2008 R2 Standard operating system.

91

Lync Server 2010 also requires installation of the following programs:

• Microsoft .Net 3.5 SP1

• PowerShell v2

Additionally, Lync Server requires the Microsoft Visual C++ 2008C redistributable, but it is
automatically installed as part of the Edge Server installation.

Hardware and Software Requirements for Reverse Proxy Servers, Load Balancers, and
Firewalls
Hardware and software requirements for reverse proxy servers, load balancers, and firewalls are
dependent on the specific hardware and software used to deploy these components. For these
hardware and software requirements, see the product documentation of the hardware and
software that you chose to deploy for these components. For example, if you use Microsoft
Forefront Threat Management Gateway 2010 for the reverse proxy server, see the system
requirements for the Forefront Threat Management Gateway 2010 at
http://go.microsoft.com/fwlink/?LinkId=200729.

Supported Server Collocation for Edge Components
Access Edge service, Web Conferencing Edge service, and A/V Edge service are collocated on the
same server. The following edge components cannot be collocated with each other or with any
other Lync Server 2010 server role.

• Edge Server

• Director

• Reverse proxy

The reverse proxy does not need to be dedicated to Lync Server. If you already have a supported
reverse proxy server in the perimeter network to support other services, you can use it for Lync
Server.

92


Deployment Best Practices for External User Access
To enhance Edge Server performance and security, as well as to facilitate deployment, apply the
following best practices when you deploy your perimeter network and Edge Servers:

• Deploy Edge Servers only after you have tested and verified operation of Lync Server 2010
inside your organization.

• Deploy Edge Servers in a workgroup rather than an internal domain. Doing so simplifies
installation and keeps Active Directory Domain Services (AD DS) out of the perimeter
network. Locating AD DS in the perimeter network can present a significant security risk.

Although you can deploy Edge Servers in a workgroup or a domain, we strongly
recommend that you not deploy Edge Servers in your internal domain. You may want to
deploy them in a perimeter domain for maintenance purposes.

• Deploy your Edge Servers in a staging or lab environment before you deploy them in your
production environment. Deploy them in your perimeter network only when you are
satisfied that the test deployment meets your requirements and that it can be incorporated
successfully in a production environment.

• Disable all services that are not essential to the Edge Server.

Run only programs that embody routing logic and that are written in Microsoft SIP
Processing Language (MSPL) with the Lync Server API.

• Enable monitoring and auditing on the computer as early as possible.

• Use a computer that has two network adapters to provide physical separation of the
internal and external network interfaces. The internal and external adapters should be on
two different subnets.

• Deploy the Edge Server between an internal firewall and an external firewall in order to
ensure strict routing from one network edge to the other, as well as to protect your internal
deployment behind two levels of firewall.

• Deploy Directors in the internal network to relieve Front End pool servers from the
overhead of performing authentication of external users and SIP redirection to the home
pool of the user (that is, if multiple pools are in use), as well as to help insulate home servers
and Front End pools from malicious traffic such as denial-of-service attacks. If the network is
flooded with invalid external traffic in such an attack, this traffic ends at the Director, which
minimizes any performance impact on internal users.

93

Planning for external user access lync server 2010 (rc)

More Related Content

What's hot (20)

Similar to Planning for external user access lync server 2010 (rc) (20)

More from Daniel Ullmark (6)

Planning for external user access lync server 2010 (rc)