Professional Documents
Culture Documents
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
Determining Your Infrastructure Requirements............................................................................1 Determining Your System Requirements..................................................................................1 Hardware and Software Platform Requirements...................................................................1 Additional Software Requirements........................................................................................2 Network Infrastructure Requirements.......................................................................................4 Active Directory Domain Services Requirements, Support, and Topologies.............................6 Active Directory Domain Services Support...........................................................................6 Supported Active Directory Topologies..................................................................................7 Active Directory Infrastructure Requirements......................................................................12 Domain Name System (DNS) Requirements.........................................................................13 Determining DNS Requirements.........................................................................................14 DNS Requirements for Front End Pools.............................................................................17 DNS Requirements for Standard Edition Servers...............................................................20 DNS Requirements for Simple URLs..................................................................................21 DNS Requirements for Automatic Client Sign-In.................................................................23 Certificate Infrastructure Requirements..................................................................................25 Certificate Requirements for Internal Servers.....................................................................26 Certificate Requirements for External User Access............................................................31 Port Requirements.................................................................................................................33 Ports and Protocols.............................................................................................................33 IPsec Exceptions................................................................................................................44 Internet Information Services (IIS) Requirements...................................................................46 IIS Requirements for Front End Pools and Standard Edition Servers.................................47
Note: For details about other system requirements for client computers and devices, see Client Software and Infrastructure Support in the Supportability documentation.
The Message Queuing service must be enabled on all servers prior to deploying any of the above listed server roles. Message Queuing can be installed as an optional feature in Windows Server 2008. Microsoft .NET Framework Requirements Microsoft .NET Framework 3.5 with SP1 is required for Microsoft Lync Server 2010. Setup prompts you to install this prerequisite, and it automatically installs it if it is not already installed on the computer. .NET Framework 4.0 can be installed on the same computer as well, but does not take the place of .NET Framework 3.5 with SP1, which is the required version for Lync Server 2010.
Note: If you install Lync Server 2010 by using the command line, you need to manually install this prerequisite on the server. Lync Server 2010 only supports the 64-bit edition of the .NET Framework. Download the Microsoft .NET 3.5 Service Pack 1 (Full Package) at http://go.microsoft.com/fwlink/?linkid=197398. Notes: After installing the .NET Framework 3.5 SP1 package, you should immediately install the following updates: Additionally, installation of the administrative tools and the Planning Tool requires installation of Microsoft .NET Framework 3.5 with SP1, as well as the appropriate updates. For details, see the Topology Builder Requirements for Installation, Publishing, and Administration and Requirements for the Planning Tool sections. Microsoft Visual C++ 2008 Redistributable Package Requirements The Microsoft Visual C++ 2008 redistributable is required to run Microsoft Lync Server 2010 communications software. If you install Lync Server 2010 by using the Lync Server Deployment Wizard, Setup prompts you to install this prerequisite, and it automatically installs it if it is not already installed on the computer. If you choose not to install it, Setup terminates. Download the Microsoft Visual C++ 2008 Redistributable Package (x64) at http://go.microsoft.com/fwlink/?linkid=197399. Note: If you install Lync Server 2010 by using the command line, you need to manually install this prerequisite on the server where you plan to install. Windows Media Format Runtime Requirements To use the Call Park, Announcement, and Response Group applications, you must install Windows Media Format Runtime on Front End Servers. The Windows Media Format Runtime is required to run the Windows Media Audio (WMA) files that these applications play for announcements and music. We recommend that you install Windows Media Format Runtime before you install Microsoft Lync Server 2010 communications software. If Lync Server 2010 does not find this software on the server, it will prompt you to install it and then you must restart the server to complete installation. To install the Windows Media Format Runtime on servers running Windows Server 2008 R2, use the following command: %systemroot%\system32\dism.exe /online /add-package /packagepath: %windir%\servicing\Packages\Microsoft-Windows-Media-FormatPackage~31bf3856ad364e35~amd64~~6.1.7600.16385.mum /ignorecheck
To install the Windows Media Format Runtime on servers running Windows Server 2008, use the following command: %systemroot%\system32\pkgmgr.exe /quiet /ip /m:%windir %\servicing\Packages\Microsoft-Windows-Media-FormatPackage~31bf3856ad364e35~amd64~~6.0.6001.18000.mum Windows PowerShell Version 2.0 Lync Server 2010 Management Shell is a management interface of Microsoft Lync Server 2010, used to automate the administration of Lync Server 2010, as well as the server operating system. It requires Windows PowerShell command-line interface version 2.0, a scripting language and command-shell environment. You must remove previous versions of Windows PowerShell prior to installing Windows PowerShell version 2.0. For details about downloading Windows PowerShell version 2.0, see Knowledge Base article 968929, "Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0)," at http://go.microsoft.com/fwlink/?linkid=197390. Windows Installer Version 4.5 Microsoft Lync Server 2010 communications software uses Windows Installer technology to install, uninstall, and maintain various server roles. Windows Installer version 4.5 is available as a redistributable component for the Windows Server operating system. Download Windows Installer 4.5 from the Microsoft Download Center at http://go.microsoft.com/fwlink/?linkid=197395.
If your organization uses a Quality of Service (QoS) infrastructure, the media subsystem is designed to work within this existing infrastructure. If you use IPsec, we recommend disabling IPsec over the port ranges used for A/V traffic. For details, see IPsec Exceptions. To ensure optimal media quality, do the following: Provision your network links to support throughput of 45 kilobits per second (Kbps) per audio stream and 300 Kbps per video stream, if enabled, during peak usage periods. A bidirectional audio or video session consists of two streams. To cope with unexpected spikes in traffic above this level and increased usage over time, Lync Server media endpoints can adapt to varying network conditions and support loads of three times the throughput (see previous paragraph) for audio and video while still retaining acceptable quality. However, do not assume that this adaptability will support an underprovisioned network. In an under-provisioned network, the ability of the Lync Server media endpoints to dynamically deal with varying network conditions (for example, temporary high packet loss) is reduced. For network links where provisioning is extremely costly and difficult, you may need to consider provisioning for a lower volume of traffic. In this scenario, you let the elasticity of the Lync Server media endpoints absorb the difference between that traffic volume and the peak traffic level, at the cost of some reduction in the voice quality. Also, there is a decrease in the headroom otherwise available to absorb sudden peaks in traffic. For links that cannot be correctly provisioned in the short term (for example a site with very poor WAN links), consider disabling video for certain users. Provision your network to ensure a maximum end-to-end delay (latency) of 150 milliseconds (ms) under peak load. Latency is the one network impairment that Lync Server media components cannot reduce, and it is important to find and eliminate the weak points.
This section describes the AD DS support requirements for Lync Server 2010. For details about topology support, see Supported Active Directory Topologies. Supported Domain Controller Operating Systems Lync Server 2010 supports domain controllers running the following operating systems: Windows Server 2008 R2 operating system Windows Server 2008 operating system Windows Server 2008 Enterprise 32-Bit
The 32-bit or 64-bit versions of the Windows Server 2003 R2 operating system The 32-bit or 64-bit versions of the Windows Server 2003
Forest and Domain Functional Level You must raise all domains in which you deploy Lync Server 2010 to a domain functional level of Windows Server 2008 R2, Windows Server 2008, or at least Windows Server 2003. All forests in which you deploy Lync Server 2010 must be raised to a forest functional level of Windows Server 2008 R2, Windows Server 2008, or at least Windows Server 2003. Support for Read-Only Domain Controllers Lync Server 2010 supports Active Directory Domain Services (AD DS) deployments that include read-only domain controllers or read-only global catalog servers, as long as there are writable domain controllers available. Domain Names Lync Server does not support single-labeled domains. For example, a forest with a root domain named contoso.local is supported, but a root domain named local is not supported. For details, see the Knowledge Based article, Information about configuring Windows for domains with single-label DNS names, at http://go.microsoft.com/fwlink/?LinkId=143752. Locked Down AD DS Environments In a locked-down AD DS environment, Users and Computer objects are often placed in specific organizational units (OUs) with permissions inheritance disabled to help secure administrative delegation and to enable use of Group Policy objects (GPOs) to enforce security policies. Lync Server 2010 can be deployed in a locked-down Active Directory environment. For details about what is required to deploy Lync Server in a locked-down environment, see "Preparing a Locked Down Active Directory Domain Services" in the Deployment documentation.
The following figure identifies the icons used in the illustrations in this section.
Single Forest, Single Domain The simplest Active Directory topology supported by Lync Server 2010, a single domain forest, is a common topology. The following figure illustrates a Lync Server deployment in a single domain Active Directory topology. Single domain topology
Single Forest, Multiple Domains Another Active Directory topology supported by Lync Server is a single forest that consists of a root domain and one or more child domains. In this type of Active Directory topology, the domain where you create users can be different from the domain where you deploy Lync Server. However, if you deploy a Front End pool, you must deploy all the Front End Servers in the pool within a single domain. Lync Server support for Windows universal administrator groups enables cross-domain administration. The following figure illustrates a deployment in a single forest with multiple domains. In this figure, a user icon shows the domain where the user account is homed, and the arrow points to the domain where the Lync Server pool resides. User accounts include the following: User accounts within the same domain as the Lync Server pool User accounts in a different domain from the Lync Server pool
User accounts in a child domain of the domain with the Lync Server pool
Single Forest, Multiple Trees A multiple-tree forest topology consists of two or more domains that define independent tree structures and separate Active Directory namespaces. The following figure illustrates a single forest with multiple trees. In this figure, a user icon shows the domain where the user account is homed, a solid line points to a Lync Server pool that resides in the same or a different domain, and a dashed line points to Lync Server pool that resides in a different tree. User accounts include the following: User accounts within the same domain as the Lync Server pool User accounts in a different domain from (but the same tree as) the Lync Server pool User accounts in a different tree from the Lync Server pool
Multiple Forests, Central Forest Lync Server 2010 supports multiple forests that are configured in a central forest topology. Central forest topologies use contact objects in the central forest to represent users in the other forests. The central forest also hosts user accounts for any users in this forest. A directory synchronization product, such as Microsoft Identity Integration Server (MIIS), Microsoft Forefront Identity Manager (FIM) 2010, or Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1), manages the life cycle of user accounts within the organization: When a new user account is created in one of the forests or a user account is deleted from a forest, the directory synchronization product synchronizes the corresponding contact in the central forest. A central forest has the following advantages: Lync Server servers are centralized within a single forest. Users can search for and communicate with other users in any forest. Users can view presence of other users in any forest.
The directory synchronization product automates the addition and deletion of contact objects in the central forest as user accounts are created or removed. The following figure illustrates a central forest topology. In this figure, there are two-way trust relationships between the domain that hosts Lync Server, which is in the central forest, and each user-only domain, which is in a separate forest. The schema in the separate user forests does not need to be extended.
10
Multiple Forests, Resource Forest In a resource forest topology, one forest is dedicated to running server applications, such as Microsoft Exchange Server and Lync Server. The resource forest hosts the server applications and a synchronized representation of the active user object, but it does not contain logon-enabled user accounts. The resource forest acts as a shared services environment for the other forests where user objsects reside. The user forests have a forest-level trust relationship with the resource forest. When you deploy Lync Server in this type of topology, you create one disabled user object in the resource forest for every user account in the user forests. If Microsoft Exchange is already deployed in the resource forest, the disabled user accounts might already exist. A directory synchronization product, such as MIIS, Microsoft Forefront Identity Manager (FIM) 2010, or Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1), manages the life cycle of user accounts. When a new user account is created in one of the user forests or a user account is deleted from a forest, the directory synchronization product synchronizes the corresponding user representation in the resource forest. This topology can be used to provide a shared infrastructure for services in organizations that manage multiple forests or to separate the administration of Active Directory objects from other administration. Companies that need to isolate Active Directory administration for security reasons often choose this topology. This topology provides the benefit of limiting the need to extend the Active Directory schema to a single forest (that is, the resource forest). The following diagram illustrates a resource forest topology.
11
12
domain in the domain tree or forest. Universal group support, combined with administrator delegation, simplifies the management of a Lync Server deployment. For example, it is not necessary to add one domain to another to enable an administrator to manage both.
13
14
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 The internal contoso.com zone contains: DNS A and SRV records for all servers running Microsoft Lync Server 2010 communications software in the corporate network DNS A and SRV records for the Edge internal interface of each Lync Server 2010, Edge Server in the perimeter network 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 Microsoft 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: DNS A and SRV records for Lync 2010 client auto configuration (optional) DNS A and SRV records for the Edge external interface of each Lync Server 2010, Edge Server in the perimeter network 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 users SIP URI. This was also the case with earlier versions of Communicator. For example, if a user signs in as cstest01@contoso.com the first SRV record will work for automatic configuration as follows: _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 clients 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: Put host records on each client machine.
15
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 you are 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 as follows: 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 Lync 2010 client will query DNS for pool01.contoso.com and get back three IP addresses (not necessarily in this order), and cache them as follows: pool01.contoso.com pool01.contoso.com pool01.contoso.com 192.168.10.90 192.168.10.91 192.168.10.92
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.
16
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 is less reliable than DNS-based load balancing. DNS load balancing is used for the following: Load balancing Lync Server SIP servers (for example, Lync Server Registrar, Director and Access Edge) Load balancing Unified Communications Application 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 server running Lync Server (for example, Focus) DNS load balancing cannot be used for the following: 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.
Front End pool with multiple Front End Servers and a hardware load balancer (whether or not DNS load balancing is also deployed on that pool)
An internal A record that resolves the fully qualified domain name (FQDN) of the Front End pool to the virtual IP (VIP) address of the load balancer.
17
Deployment scenario
DNS requirement
A set of internal A records that resolve the FQDN of the pool to the IP address of each server in the pool. There must one A record for each server in the pool. A set of internal A records that resolve the FQDN of each server in the pool to the IP address of that server. For details, see DNS Load Balancing in the Planning for Other Features documentation. An internal A record that resolves the FQDN of the Front End pool to the IP address of the single Enterprise Edition Front End server.
Front End pool with a single Front End Server and a dedicated Back-End Database but no load balancer
An internal URL for conferencing that is different from the default pool FQDN
An internal A record that resolves the host name portion of the URL to the virtual IP of the conferencing load balancer (or single Front End Server if appropriate). For each supported SIP domain, an SRV record for _sipinternaltls._tcp.<domain> over port 5061 that maps to the FQDN of the Front End pool that authenticates and redirects client requests for sign-in. For details, see DNS Requirements for Automatic Client Sign-In. An internal A record with the name ucupdatesr2.<SIP domain> that resolves to the IP address of the Front End pool that hosts the Device Update Service. In the situation where an UC device is turned on, but a user has never logged into the device, the A record allows the device to discover the Front End pool hosting Device Update Service and obtain updates. Otherwise, devices obtain this information though in-band provisioning the first time a user logs in. For details, see Updating Devices in the Planning for Clients and Devices documentation. Important: If you have an existing deployment of Windows Server Update Services (WSUS) in Microsoft Office Communications Server 2007, you
18
Deployment scenario
DNS requirement
have already created an internal A record with the name ucupdates.<SIP domain>. For Microsoft Office Communications Server 2007 R2, you must create an additional DNS A record with the name ucupdates-r2.<SIP domain>. A reverse proxy to support HTTP traffic An external A record that resolves the external Web farm FQDN to the external IP address of the reverse proxy. Clients and UC devices use this record to connect to the reverse proxy. For details, see Determining DNS Requirements.
The following table shows an example of the DNS records required for the internal Web farm FQDN. Example DNS Records for Internal Web Farm FQDN
Internal Web farm FQDN Pool FQDN DNS A record(s)
ee-pool.contoso.com
ee-pool.contoso.com
DNS A record for eepool.contoso.com that resolves to the virtual IP (VIP) address of the load balancer used by the Enterprise Edition Front End Servers in the Front End pool. In this case, the load balancer distributes SIP traffic to the Front End Servers and HTTP(S) traffic to the Web Components Servers.
webcon.contoso.com
ee-pool.contoso.com
DNS A record for the eepool.contoso.com that resolves to the VIP address of the load balancer used by the Front End Servers. DNS A record for webcon.contoso.com that resolves to the VIP address of the load balancer used by the Web Components Servers.
19
An internal A record that resolves the fully qualified domain name (FQDN) of the server to its IP address. For each supported SIP domain, an SRV record for _sipinternaltls._tcp.<domain> over port 5061 that maps to the FQDN of the Standard Edition server that authenticates and redirects client requests for sign-in. For details, see DNS Requirements for Automatic Client Sign-In. An internal A record with the name ucupdatesr2.<SIP domain> that resolves to the IP address of the Standard Edition server hosting Device Update Service. In the situation where an UC device is turned on, but a user has never logged into the device, the A record allows the device to discover the server hosting Device Update Service and obtain updates. Otherwise, devices obtain the server information though in-band provisioning the first time a user logs in. For details, see Updating Devices in the Planning for Clients and Devices documentation. Important: If you have an existing deployment of Windows Server Update Services (WSUS) in Office Communications Server 2007, you have already created an internal A record with the name ucupdates.<SIP domain>. For Office Communications Server 2007 R2, you must create an additional DNS A record with the name ucupdates-r2.<SIP domain>.
20
Deployment scenario
DNS requirement
An external A record that resolves the external Web farm FQDN to the external IP address of the reverse proxy. Clients and UC devices use this record to connect to the reverse proxy. For details, see Determining DNS Requirements.
21
Simple URL Option 1 Simple URL Meet Example https://meet.contoso.com, https://meet.fabrikam.com, and so on (one for each SIP domain in your organization) https://dialin.contoso.com https://admin.contoso.com
Dial-in Admin
If you use Option 1, you must define the following: For each Meet simple URL, you need a DNS A record that resolves the URL to the IP address of the Director, if you have one deployed. Otherwise, it should resolve to the IP address of the load balancer of a Front End pool. If you have not deployed a pool and are using a Standard Edition server deployment, the DNS A record must resolve to the IP address of one Standard Edition server in your organization. If you have more than one SIP domain in your organization and you use this option, you must create Meet simple URLs for each SIP domain and you need a DNS A record for each Meet simple URL. For example, if you have both contoso.com and fabrikam.com, you will create DNS A records for both https://meet.contoso.com and https://meet.fabrikam.com. Alternatively, if you have multiple SIP domains and you want to minimize the DNS record and certificate requirements for these simple URLs, use Option 3 as described later in this topic. For the Dial-in simple URL, you need a DNS A record that resolves the URL to the IP address of the Director, if you have one deployed. Otherwise, it should resolve to the IP address of the load balancer of a Front End pool. If you have not deployed a pool and are using a Standard Edition server deployment, the DNS A record must resolve to the IP address of one Standard Edition server in your organization. The Admin-in simple URL is internal only. It requires a DNS A record that resolves the URL to the virtual IP (VIP) address of a Front End pool. If you have not deployed a pool and are using a Standard Edition server deployment, the DNS A record must resolve to the IP address of one Standard Edition server in your organization. Simple URL Option 2 With Option 2, all simple URLs are based on the domain name lync.contoso.com. Therefore, you need only one DNS A record, which resolves lync.contoso.com to the IP address of the load balancer of a Front End pool. If you have not deployed a pool and are using a Standard Edition server deployment, the DNS A record must resolve to the IP address of one Standard Edition server in your organization.
22
Simple URL Option 2 Simple URL Meet Example https://lync.contoso.com/Meet, https://lync.fabrikam.com/Meet, and so on (one for each SIP domain in your organization) https://lync.contoso.com/Dialin https://lync.contoso.com/Admin
Dial-in Admin
Simple URL Option 3 Option 3 is most useful if you have many SIP domains, and you want them to have separate simple URLs but want to minimize the DNS record and certificate requirements for these simple URLs. Simple URL Option 3 Simple URL Meet Example https://lync.contoso.com/contosoSIPdomain/Meet https://lync.contoso.com/fabrikamSIPdomain/Meet Dial-in https://lync.contoso.com/contosoSIPdomain/Dialin https://lync.contoso.com/fabrikamSIPdomain/ Dialin Admin https://lync.contoso.com/contosoSIPdomain/Admin https://lync.contoso.com/fabrikamSIPdomain/Admin
23
Note: In the following record requirements, SIP domain refers to the host portion of the SIP URIs assigned to users. For example, if SIP URIs are of the form *@contoso.com, contoso.com is the SIP domain. The SIP domain is often different from the internal Active Directory domain. An organization can also support multiple SIP domains. For details about configuring SIP domains, see Operations. To enable automatic configuration for your clients, you must create an internal DNS SRV record that maps one of the following records to the fully qualified domain name (FQDN) of the Front End pool or Standard Edition server that distributes sign-in requests from Lync clients: _sipinternaltls._tcp.<domain> - for internal TLS connections _sipinternal._tcp. <domain> - for internal TCP connections (performed only if TCP is allowed) You only need to create a single SRV record for the Front End pool or Standard Edition server or that will distribute sign-in requests. Important: Only a single Front End pool or Standard Edition server can be designated to distribute sign-in requests. Create only one SRV record for the designated server or pool. Do not create this SRV record for additional internal servers or pools. The following table shows some example records required for the fictitious company Contoso, which supports SIP domains of contoso.com and retail.contoso.com. Example of DNS Records Required for Automatic Client Sign-in with Multiple SIP Domains
FQDN of Front End pool used to distribute sign-in requests SIP domain DNS SRV record
pool01.contoso.com
contoso.com
An SRV record for _sipinternaltls._tcp.contoso.com domain over port 5061 that maps to pool01.contoso.com An SRV record for _sipinternaltls._tcp.retail.contoso.com domain over port 5061 that maps to pool01.contoso.com
pool01.contoso.com
retail.contoso.com
Note: By default, queries for DNS records adhere to strict domain name matching between the domain in the user name and the SRV record. If you prefer that client DNS queries use suffix matching instead, you can configure the DisableStrictDNSNaming Group Policy. For details, see the Planning for Clients and Devices documentation.
24
Example of the Certificates and DNS Records Required for Automatic Client Sign-In This example uses the same example names in the preceding table. The Contoso organization supports the SIP domains of contoso.com and retail.contoso.com, and all of its users have a SIP URI in one of the following forms: <user>@retail.contoso.com <user>@contoso.com
Example of Required DNS Records If the administrator at Contoso configures pool01.contoso.com as the pool that will distribute its sign-in requests, the following DNS records are required: SRV record for _sipinternaltls._tcp.contoso.com domain over port 5061 that maps to pool01.contoso.com SRV record for _sipinternaltls._tcp. retail.contoso.com domain over port 5061 that maps to pool01.contoso.com Example of Required Certificates In addition, the certificate that is assigned to the Front End Servers in the pool01.contoso.com Front End pool must include the following in its Subject Alternative Name: sip.contoso.com sip.retail.contoso.com
External user access to audio/video (A/V) sessions, application sharing, and conferencing For Lync Server 2010, the following common requirements apply: All server certificates must support server authorization (Server EKU). All server certificates must contain a CRL Distribution Point (CDP). Auto-enrollment is supported for internal servers running Lync Server. Auto-enrollment is not supported for Lync Server Edge Servers.
25
Default
FQDN of the pool and the FQDN of the server If you have multiple SIP domains and have enabled automatic client configuration, the certificate wizard detects and adds each supported SIP domain FQDNs. If this pool is the auto-logon server for clients and strict DNS
SN=se01.contoso.com; SAN=se01.contoso.com
On Standard Edition server, the server If this pool is the auto-logon server for clients and strict DNS FQDN is the same as the matching is required in group pool FQDN. policy, then you also need SAN=sip.contoso.com; The wizard SAN=sip.fabrikam.com detects any SIP domains you specified during setup and automatically adds them to the Subject Alternative Name.
26
Subject name/ Common Certificate name Subject Alternative Name Example Comments
matching is required in group policy, then you also need entries for sip.sipdomain (for each SIP domain you have). Web internal FQDN of the server Each of the following: SN=se01.contoso.com; SAN=se01.contoso.com; Internal SAN=meet.contoso.com; web FQDN SAN=meet.fabrikam.com; (which is the SAN=dialin.contoso.com; same as the SAN=admin.contoso.com FQDN of the server) Meet simple URLs Dial-in simple URL Admin simple URL Internal web FQDN cannot be overwritten in Topology Builder. If you have multiple Meet simple URLs, you must include all of them as Subject Alternative Names.
Web external
SN=se01.contoso.com; SAN=webcon01.contoso.com; External SAN=meet.contoso.com; Web FQDN SAN=meet.fabrikam.com; SAN=dialin.contoso.com Dial-in simple URL Admin simple URL
If you have multiple Meet simple URLs, you must include all of them as Subject Alternative Names.
27
Default
FQDN of the pool and FQDN of the server. If you have multiple SIP domains and have enabled automatic client configuration, the certificate wizard detects and adds each supported SIP domain FQDNs. If this pool is the auto-logon server for clients and strict DNS matching is required in group policy, then you also need entries for sip.sipdomain (for each SIP domain you have).
The wizard detects any SIP domains you specified during If this pool is the auto-logon server for clients and strict DNS setup and automatically matching is required in group adds them to policy, then you also need the Subject SAN=sip.contoso.com; Alternative SAN=sip.fabrikam.com Name.
Web Internal
SN=ee01.contoso.com; SAN=ee01.contoso.com; Internal SAN=meet.contoso.com; web FQDN SAN=meet.fabrikam.com; (which is the SAN=dialin.contoso.com; same as the SAN=admin.contoso.com FQDN of the server) Meet simple
Internal web FQDN cannot be overwritten inTopology Builder. If you have multiple Meet simple URLs, you must include all of them as Subject
28
Subject name/ Common Certificate name Subject Alternative Name Example Comments
Alternative Names.
Web external
SN=ee01.contoso.com; SAN=webcon01.contoso.com; External SAN=meet.contoso.com; Web FQDN SAN=meet.fabrikam.com; SAN=dialin.contoso.com Dial-in simple URL Admin simple URL
If you have multiple Meet simple URLs, you must include all of them as Subject Alternative Names.
Default
FQDN of the Director, FQDN of the Director pool If this pool is the auto-logon server for clients and strict DNS matching is required in group policy, then you also need entries for sip.sipdomain (for each SIP domain you have).
SN=dir-pool.contoso.com; SAN=dir-pool.contoso.com; SAN=dir01.contoso.com If this Director pool is the autologon server for clients and strict DNS matching is required in group policy, then also SAN=sip.contoso.com; SAN=sip.fabrikam.com
Web Internal
Each of the following: SN=dir01.contoso.com; Internal web SAN=dir01.contoso.com; SAN=meet.contoso.com; FQDN (which is SAN=meet.fabrikam.com; the same as the SAN=dialin.contoso.com; FQDN of the
29
server) Meet simple URLs Dial-in simple URL Admin simple URL
SAN=admin.contoso.com
Web external
Each of the following: SN=dir01.contoso.com; SAN=webcon01.contoso.com External SAN=meet.contoso.com; Web FQDN SAN=meet.fabrikam.com; Dial-in SAN=dialin.contoso.com simple URL Admin simple URL
If you have a standalone A/V Conferencing Server pool, the A/V Conferencing Servers in it each need the following certificates. If you collocate A/V Conferencing Server with the Front End Servers, the certificates listed in the Certificates for Front End Server in Enterprise Pool table earlier in this topic are sufficient. Certificates for Standalone A/V Conferencing Server
Subject name/ Certificate Common name Subject Alternative Name Example
Default
Not applicable
SN=av-pool.contoso.com
If you have a stand-alone Mediation Server pool, the Mediation Servers in it each need the following certificates. (If you collocate Mediation Server with the Front End Servers, the certificates listed in the Certificates for Front End Server in Enterprise Pool table earlier in this topic are sufficient.
30
Default
Default
31
The web conferencing Edge external interface or hardware load balancer VIP (for example, webcon.contoso.com). 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 FQDNs in the subject alternative names list does not matter. 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 hardware load balancer 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.
32
Port Requirements
Microsoft Lync Server 2010 communications software requires that specific ports on the firewall be open. Additionally, if Internet Protocol security (IPsec) is deployed in your organization, IPsec must be disabled over the range of ports used for the delivery of audio, video, and panorama video. This section includes the following topics: Ports and Protocols IPsec Exceptions
5060
TCP
Yes
Used by Standard Edition servers and Front End pools for listening to client connections from
33
Does this port need to be open Component (server role or client) Service name Port Protocol on the load balancer? Notes
Microsoft Lync 2010 (TCP). Front End Servers Lync Server Front-End service 5061 TCP (TLS) Yes Used by Standard Edition servers and Front End pools for all internal SIP communications between servers (MTLS), for SIP communications between Server and Client (TLS) and for SIP communications between Front End Servers and Mediation Servers (MTLS). Used for communication between the Focus (the Lync Server component that manages conference state) and the individual servers. Used for DCOM based operations such as Moving Users, User Replicator Synchronization, and Address Book Synchronization.
444
HTTPS
Yes
135
Yes (must be open on the hardware load balancer even if you are using DNS load balancing) No
TCP
Used for incoming SIP requests for instant messaging (IM) conferencing. Used to listen for
TCP
No
34
Does this port need to be open Component (server role or client) Service name Port Protocol on the load balancer? Notes
Web Conferencing service Front End Servers Lync Server Audio/Video Conferencing service Lync Server Audio/Video Conferencing service Web Compatibility service 5063
(TLS)
Persistent Shared Object Model (PSOM) connections from client. No Used for incoming SIP requests for audio/video (A/V) conferencing. Media port range used for video conferencing.
TCP
5750165335
TCP/UD P
No
80
HTTP
Yes (must be open on the hardware load balancer even if you are using DNS load balancing) Yes (must be open on the hardware load balancer even if you are using DNS load balancing) Yes (must be open on the hardware load balancer
Used for communication from Front End Servers to the Web farm FQDNs (the URLs used by IIS Web components) when HTTPS is not used.
443
HTTPS
Used for communication from Front End Servers to the Web farm FQDNs (the URLs used by IIS Web components).
8080
TCP
35
Does this port need to be open Component (server role or client) Service name Port Protocol on the load balancer? Notes
even if you are using DNS load balancing) Front End Servers Lync Server Conferencing Attendant service (dial-in conferencing) Lync Server Conferencing Attendant service (dial-in conferencing) Lync Server Mediation service 5064 TCP No Used for incoming SIP requests for dial-in conferencing.
5072
TCP
Yes
Used for incoming SIP requests for Microsoft Lync 2010 Attendant (dial in conferencing). Used by the Mediation Server for incoming requests from the Front End Server to the Mediation Server. Used for incoming SIP requests from the PSTN gateway to the Mediation Server. Used for incoming SIP requests from the PSTN gateway to the Mediation Server. Used for incoming SIP listening requests for application sharing. Media port range used for application sharing.
Front End Servers that also run a Collocated Mediation Server Front End Servers that also run a Collocated Mediation Server Front End Servers that also run a Collocated Mediation Server Front End Servers
5070
TCP
Yes
Lync Server Mediation service Lync Server Mediation service Lync Server Application Sharing service Lync Server Application Sharing service
5067
TCP (TLS)
Yes
5068
TCP
Yes
5065
TCP
No
4915265335
TCP
No
36
Does this port need to be open Component (server role or client) Service name Port Protocol on the load balancer? Notes
TCP
Yes
Used for incoming SIP requests for the Lync Server Conferencing Announcement service (that is, for dial-in conferencing). Used for incoming SIP requests for the Call Park application. Used for incoming SIP requests for the Audio Test service. Used for outbound Enhanced 9-1-1 (E9-11) gateway. Used by Quality of Experience (QoE) agent on the Front End Server. Used for incoming SIP requests for the Response Group application. Used for incoming SIP requests for the Response Group application. Used for call admission control by the Bandwidth Policy service for A/V Edge TURN traffic. Used for call admission control by the Lync Server Bandwidth Policy Service.
5075
TCP
Yes
5076
TCP
Yes
5066
TCP
No
Lync Server QoE Monitoring Service Lync Server Response Group service Lync Server Response Group service Lync Server Bandwidth Policy Service Lync Server Bandwidth Policy Service
5069
TCP
Yes
5071
TCP
Yes
8404
TCP (MTLS)
No
5080
TCP
Yes
448
TCP
Yes
37
Does this port need to be open Component (server role or client) Service name Port Protocol on the load balancer? Notes
445
TCP
No
Used to push configuration data from the Central Management store to servers running Lync Server. Media port range used for audio conferencing on all internal servers. Used by all servers that terminate audio: Front End Servers (for Lync Server Conferencing Attendant service, Lync Server Conferencing Announcement service, and Lync Server Audio/Video Conferencing service), and Mediation Server. Used by Standard Edition servers and Front End pools for listening to client connections from Lync 2010(TCP). Used for internal communications between servers and for client connections. Used by the Mediation Server for incoming requests from the Front End Server. Used for incoming SIP requests from the PSTN gateway.
Various
4915257500
TCP/UD P
N/A
Directors
5060
TCP
Yes
Directors
Lync Server Front-End service Lync Server Mediation service Lync Server Mediation service
5061
TCP
Yes
Mediation Servers
5070
TCP
Yes
Mediation Servers
5067
TCP (TLS)
Yes
38
Does this port need to be open Component (server role or client) Service name Port Protocol on the load balancer? Notes
Mediation Servers
Lync Server Mediation service Lync Server Mediation service Lync Server Monitoring service
5068
TCP
Yes
Used for incoming SIP requests from the PSTN gateway. Used for SIP requests from the Front End Servers. Used for message queuing and RPC operations.
Mediation Servers
5070
TCP (MTLS)
Yes
Monitoring Servers
135
Message N/A Queuing and remote procedur e call (RPC) Message N/A Queuing and RPC TCP N/A
Archiving Servers
135
Used for message queuing and RPC operations. Used by the reverse proxy to listen on the external interface for incoming requests from external users. Used by the reverse proxy to listen on the external interface for incoming requests from external users for Web components information and file downloads, distribution group expansion as well as Address Book information. Used for SIP/TLS communication with the internal network to the Web services cluster.
80
443
TCP
N/A
8080
TCP
N/A
39
Does this port need to be open Component (server role or client) Service name Port Protocol on the load balancer? Notes
Traffic from port 80 on the external interface is redirected to this port. Reverse proxy servers 4443 TCP N/A Used by the reverse proxy to listen on the internal interface. Traffic from port 443 on the external interface is redirected to this port. Used for SIP/TLS communication for external users accessing internal Web conferences, and STUN/TCP inbound and outbound media communications for accessing internal media and A/V sessions. Used for SIP/MTLS communication for remote user access or federation and public Internet connectivity. Used to listen for PSOM/MTLS communications from the Web Conferencing Server on the internal interface of the Web Conferencing Edge Server. Used for SIP/MTLS authentication of A/V users. Communications flow outbound through
Edge Servers
443
TCP
Yes
Edge Servers
Lync Server Access Edge service (internal and external interface) Lync Server Web Conferencing Edge service (internal interface)
5061
TCP
Yes
Edge Servers
8057
TCP
No
Edge Servers
5062
TCP
Yes
40
Does this port need to be open Component (server role or client) Service name Port Protocol on the load balancer? Notes
service (internal interface) Edge Servers Lync Server Audio/Video Edge service (internal and external interfaces) Lync Server Audio/Video Edge service port range 3478 UDP Yes
Edge Servers
50,00059,999
RTP/TC P, RTP/UD P
No
Used for inbound and outbound media transfer through the external firewall. This port range always needs to be opened outbound for TCP. If you federate with an organization running Microsoft Office Communications Server 2007 R2 or Microsoft Office Communications Server 2007, you must open this range both outbound and inbound, and for both TCP and UDP. Used to push configuration data from the Central Management store to the Edge Server. This port must be opened on every individual Edge Server, not on the load balancer. Used by Lync 2010 to find the Registrar FQDN
Edge Servers
4443
TCP
No
Clients
67/68
DHCP
N/A
41
Does this port need to be open Component (server role or client) Service name Port Protocol on the load balancer? Notes
(if DNS SRV fails and manual settings are not configured). Clients 68916901 TCP N/A Used for file transfer between Lync 2010 clients and previous clients (clients of Office Communicator 2007 R2, Office Communications Server 2007, and Live Communications Server 2005). Used by clients for audio port range (minimum of 20 ports required). Used by clients for video port range (minimum of 20 ports required). Used by clients for peerto-peer file transfer (for conferencing file transfer, clients use PSOM). Used by clients for application sharing. Used by the devices listed to find the Lync Server 2010 certificate, provisioning FQDN, and Registrar FQDN.
Clients
N/A
Clients
N/A
Clients
N/A
Clients Microsoft Lync 2010 Phone Edition for Aastra 6721ip common area phone Microsoft Lync 2010 Phone Edition for Aastra 6725ip desk phone
102465535 67/68
TCP DHCP
N/A N/A
42
Does this port need to be open Component (server role or client) Service name Port Protocol on the load balancer? Notes
Microsoft Lync 2010 Phone Edition for Polycom CX500 common area phone Microsoft Lync 2010 Phone Edition for Polycom CX600 desk phone
43
IPsec Exceptions
For enterprise networks where Internet Protocol security (IPsec) (see IETF RFC 4301-4309) has been deployed, IPsec must be disabled over the range of ports used for the delivery of audio, video, and panorama video. The recommendation is motivated by the need to avoid any delay in the allocation of media ports due to IPsec negotiation. The following table explains the recommended IPsec exception settings. Recommended IPsec Exceptions
Destination Rule name Source IP IP Protocol Source port Destination port Filter action
A/V Edge Server Internal Inbound A/V Edge Server External Inbound A/V Edge Server Internal Outbound A/V Edge Server External Outbound Mediation Server Inbound Mediation Server Outbound Conferencing Attendant Inbound Conferencing Attendant Outbound A/V Conferencing Inbound A/V Conferencing Server Outbound Exchange Inbound
Any
UDP and Any TCP UDP and Any TCP UDP & TCP Any
Any
Permit
Any
Any
Permit
Any
Permit
Any
UDP and Any TCP UDP and Any TCP UDP and Any TCP UDP and Any TCP UDP and Any TCP
Any
Permit
Mediation Server(s)
Any
Permit
Any
Any
Permit
Any Any
A/V UDP and Any Conferencing TCP Servers UDP and Any TCP UDP and Any
Any
Permit
Any
Permit
44
Source port
Destination port
Filter action
Messaging Application Sharing Servers Inbound Application Sharing Server Outbound Exchange Outbound Any Application Sharing Servers Any
TCP
Any
Any
Permit
Any
Any
Permit
Clients
Any
Permit
45
Common HTTP Features Application Development Application Development Application Development Application Development Health and Diagnostics Health and Diagnostics Security Security Management Tools Management Tools
HTTP Redirection ASP.NET .NET Extensibility ISAPI Extensions ISAPI Filters Logging Tools Tracing Basic Authentication Windows Authentication IIS Management Scripts and Tools IIS 6 Management Compatibility
You must install the following additional components to enable features in Lync Server: IIS URL Rewrite module at http://go.microsoft.com/fwlink/?linkid=197391. Important: If you are running Windows Server 2008 R2, you must install version 1.1 of the URL Rewrite module, available at http://go.microsoft.com/fwlink/?linkid=197394. IIS Application Request Routing module at http://go.microsoft.com/fwlink/?linkid=197392
Security Note If you are using IIS 7.0 on a Windows Server 2008 operating system, Lync Server 2010 Setup disables kernel mode authentication in IIS.
46
IIS Requirements for Front End Pools and Standard Edition Servers
For Standard Edition servers and Front End Servers, and Directors, the Microsoft Lync Server 2010 installer creates virtual directories in IIS for the following purposes: To enable users to download files from the Address Book Service To enable clients to obtain updates (for example, Microsoft Lync 2010) To enable conferencing To enable users to download meeting content
To enable unified communications (UC) devices to connect to Device Update Service and obtain updates To enable users to expand distribution groups To enable phone conferencing To enable response group features Static Content Default Document HTTP Errors ASP.NET .NET Extensibility Internet Server API (ISAPI) Extensions ISAPI Filters HTTP Logging Logging Tools Tracing Windows Authentication Request Filtering Static Content Compression IIS Management Console IIS Management Scripts and Tools Tracing AnonymousAuthenticationModule ClientCertificateMappingAuthenticationModule
The following table lists the URIs for the virtual directories for internal access and the file system resources to which they refer.. Virtual Directories for Internal Access
Feature Virtual directory URI Refers to
https://<Internal FQDN>/ABS/int/Handler
47
Feature
Refers to
Server download files for internal users. Client updates http://<Internal FQDN>/AutoUpdate/Int Location of update files for internal computer-based clients. Location of conferencing resources for internal users. Location of unified communications (UC) device update files for internal UC devices. Location of meeting content for internal users. Location of the Web service that enables group expansion for internal users. Also, the location of the Address Book Web Query service that provides global address list information to internal Microsoft Lync 2010 Mobile clients. Location of phone conferencing data for internal users. Location of the Device Update Service Request Handler that enables internal UC devices to upload logs and check for updates. Location of Response Group ConfigurationTool.
Conf
http://<Internal FQDN>/Conf/Int
Device updates
http://<Internal FQDN>/DeviceUpdateFiles_Int
Phone Conferencing
Device updates
For Front End pools in a consolidated configuration, you must deploy IIS before you can add servers to the pool.
48
Security Note: You must use the IIS administrative snap-in to assign the certificate used by the IIS Web component server.
49