A guide to planning for enabling access to your Lync Server deployment for external users, including your own users while they work outside the office, as well as enabling collaboration and communication with users from other organizations. (Planning for External User Access Lync Server 2010 (RC).doc)
3. 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
Certificate Summary................................................................................................................................50
Port Summary..........................................................................................................................................52
DNS Summary..........................................................................................................................................62
Reference Architecture 3: Scaled Consolidated Edge (Hardware Load Balanced).....................................67
Hardware Load Balancer Requirements:................................................................................................67
Certificate Summary................................................................................................................................70
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
4. 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
5. 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
6. 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
7. Microsoft Lync Server 2010 Planning for External User Access
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
8. Microsoft Lync Server 2010 Planning for External User Access
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
9. Microsoft Lync Server 2010 Planning for External User Access
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
10. Microsoft Lync Server 2010 Planning for External User Access
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
11. Microsoft Lync Server 2010 Planning for External User Access
Data Collection Template for Lync Server 2010 Single Consolidated Edge Environment
7
12. Microsoft Lync Server 2010 Planning for External User Access
Data Collection Template for Lync Server 2010 Scaled Consolidated Edge (DNS Load Balanced) Environment
8
13. Microsoft Lync Server 2010 Planning for External User Access
Data Collection Template for Lync Server 2010 Scaled Consolidated Edge (Hardware Load Balanced) Environment
9
14. Microsoft Lync Server 2010 Planning for External User Access
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
15. Microsoft Lync Server 2010 Planning for External User Access
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
16. Microsoft Lync Server 2010 Planning for External User Access
Determining DNS Requirements
Use the following flow chart to determine Domain Name System (DNS) requirements.
12
17. Microsoft Lync Server 2010 Planning for External User Access
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
18. Microsoft Lync Server 2010 Planning for External User Access
• 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
19. Microsoft Lync Server 2010 Planning for External User Access
• 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
pool01.contoso.com 192.168.10.91
pool01.contoso.com 192.168.10.92
15
20. Microsoft Lync Server 2010 Planning for External User Access
• 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
21. Microsoft Lync Server 2010 Planning for External User Access
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
22. Microsoft Lync Server 2010 Planning for External User Access
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
23. Microsoft Lync Server 2010 Planning for External User Access
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
24. Microsoft Lync Server 2010 Planning for External User Access
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
25. Microsoft Lync Server 2010 Planning for External User Access
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
26. Microsoft Lync Server 2010 Planning for External User Access
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
27. Microsoft Lync Server 2010 Planning for External User Access
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
28. Microsoft Lync Server 2010 Planning for External User Access
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
29. Microsoft Lync Server 2010 Planning for External User Access
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
30. Microsoft Lync Server 2010 Planning for External User Access
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
31. Microsoft Lync Server 2010 Planning for External User Access
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
32. Microsoft Lync Server 2010 Planning for External User Access
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
33. Microsoft Lync Server 2010 Planning for External User Access
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
Lync Server 2010 pool
Office Communications Server 2007 R2 Director No
Office Communications Server 2007 R2 pool
Office Communications Lync Server 2010 Director Yes
Server 2007 R2 Edge
Lync Server 2010 pool
Lync Server 2010 Director No
Office Communications Server 2007 R2 pool
Office Communications Server 2007 R2 Director Yes
Lync Server 2010 pool
Office Communications Server 2007 R2 Director Yes
Office Communications Server 2007 R2 pool
29
34. Microsoft Lync Server 2010 Planning for External User Access
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
35. Microsoft Lync Server 2010 Planning for External User Access
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
36. Microsoft Lync Server 2010 Planning for External User Access
• 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
37. Microsoft Lync Server 2010 Planning for External User Access
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
38. Microsoft Lync Server 2010 Planning for External User Access
Single Consolidated Edge Topology
34
39. Microsoft Lync Server 2010 Planning for External User Access
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
• Web Conferencing 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
(using the Lync Server
Certificate Wizard)
Reverse Proxy
35
40. Microsoft Lync Server 2010 Planning for External User Access
Subject name Subject alternative Certificatio Enhanced Assign to
name entries/Order n authority key usage
(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
(using the Lync Server
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
42. Microsoft Lync Server 2010 Planning for External User Access
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 inter-op
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
Protocol / Port Used For
SIP/MTLS/5061 (in/out) Federation
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
43. Microsoft Lync Server 2010 Planning for External User Access
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
44. Microsoft Lync Server 2010 Planning for External User Access
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,
(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 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
45. Microsoft Lync Server 2010 Planning for External User Access
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
59,999 still running Office Communications Server
2007.
41
46. Microsoft Lync Server 2010 Planning for External User Access
Edge Source Source Destination Destination Transport Application Notes
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
59,999 still running Office Communications Server
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
47. Microsoft Lync Server 2010 Planning for External User Access
Internal Ports Settings Required for Single Consolidated Edge Topology
Edge Source Source Destination Destination Transport Application Notes
role IP address port IP address port
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 Any Any 172.25.33.10 3478 UDP STUN
A/V Any Any 172.25.33.10 443 TCP STUN
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
48. Microsoft Lync Server 2010 Planning for External User Access
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
49. Microsoft Lync Server 2010 Planning for External User Access
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
Location Type FQDN IP address Port Maps to/Comments
Next Hop Pool
45
50. Microsoft Lync Server 2010 Planning for External User Access
Location Type FQDN IP address Port Maps to/Comments
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 fe02.contoso.net 192.168.10.91/24 Pool01 Front End Server (NODE 2)
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
A dialin.contoso.com 192.168.10.190/24
clients to work internally
A meet.contoso.com 192.168.10.190/24
Required for automatic configuration of Lync 2010
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
clients to work internally
SRV _sipinternaltls._tcp.fabrikam.com pool01.fabrikam.com 5061 Required for automatic configuration of Lync 2010
clients to work internally
SRV _ntp._udp.contoso.com timeServerFQDN 123 Network Time Protocol (NTP) source required for
Microsoft Lync 2010 Phone Edition devices
46