Download.microsoft.com



[pic]

 

Microsoft Lync Server 2010 Supportability Guide

Microsoft Lync Server 2010

Published: March 2012

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.

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.

Copyright © 2012 Microsoft Corporation. All rights reserved.

Contents

Supportability 1

Active Directory Support 1

Supported Lync Server 2010 Topologies 1

Supported Server Collocation 5

Server Collocation in an Enterprise Edition Front End Pool Deployment 5

Server Collocation in a Standard Edition Server Deployment 7

Supported Migration Paths and Coexistence Scenarios 9

Supported Server Migration Paths and Coexistence Scenarios 9

Supported Clients from Previous Deployments 10

Supported Hardware 11

Server Hardware Platforms 11

Client and Device Hardware Support 13

Client Hardware Support 13

Device Hardware Support 15

File Storage Support 15

Server Software and Infrastructure Support 16

Server and Tools Operating System Support 16

Database Software and Clustering Support 18

Certificate Infrastructure Support 20

Wildcard Certificate Support 20

Domain Name System (DNS) Infrastructure Support 41

Internet Information Services (IIS) Support 41

IP and Networking Protocol Support 41

Voice Support 42

SIP Trunking Support 42

Direct SIP Connections Support 44

Exchange Unified Messaging (UM) Support 45

Components and Topologies for On-Premises Unified Messaging 45

Support for Hosted Exchange UM Integration 46

E9-1-1 Support 47

Virtualization Support 48

Additional Server Support and Requirements 48

Client and Device Software and Infrastructure Support 50

Client Software Support 50

Required Lync Server 2010 Components for Devices 52

Device System and Infrastructure Support 53

Supportability

Microsoft Lync Server 2010 communications software supports topologies that are designed to meet the needs of organizations that are small, medium, or large and that have varying requirements for performance, high availability, and scalability.

In This Section

• Active Directory Support

• Supported Lync Server 2010 Topologies

• Supported Server Collocation

• Supported Migration Paths and Coexistence Scenarios

• Supported Hardware

• Server Software and Infrastructure Support

• Additional Server Support and Requirements

• Client and Device Software and Infrastructure Support

Active Directory Support

The Active Directory Domain Services topologies supported by Microsoft Lync Server 2010 are as follows:

• Single forest with single domain

• Single forest with a single tree and multiple domains

• Single forest with multiple trees and disjoint namespaces

• Multiple forests in a central forest topology

• Multiple forests in a resource forest topology

[pic]Note:

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 Microsoft Knowledge Base article 300684, “Information about configuring Windows for domains with single-label DNS names,” at .

For details about supported topologies and requirements, see Active Directory Domain Services Requirements, Support, and Topologies in the Planning documentation.

Supported Lync Server 2010 Topologies

Microsoft Lync Server 2010 supports deployment of one or more sites that can be scaled to meet high availability and location requirements. You can structure these sites and their components to meet the access and resiliency requirements of your organization.

You can have one or more sites in your Lync Server 2010 deployment:

• Your deployment must include at least one central site (also known as a data center). Each central site must contain at least one of Enterprise Edition Front End pool or one Standard Edition server. These consist of the following:

• Enterprise Edition Front End pool, which consists of one or more Front End Servers (typically, at least two Front End Servers for scalability) and a separate Back End Server. A Front End pool can contain a maximum of ten Front End Servers. Load balancing is required for multiple Front End Servers. For SIP traffic, DNS load balancing is recommended, but hardware load balancing is also supported. If you use DNS load balancing for SIP traffic, you still need a hardware load balancer for HTTP traffic. A Windows cluster of two or more Back End Servers is recommended for high availability of the SQL Server databases. The cluster can be on an existing SQL Server cluster that includes cluster nodes that are used for other applications, but the back-end database must reside on dedicated cluster nodes. The back-end database requires a separate instance, but you can collocate the archiving and monitoring database with it. Lync Server 2010 also supports the use of a shared cluster for the file shares in your deployment. For details about database storage requirements, see Database Software and Clustering Support. For details about file storage requirements, see File Storage Support.

[pic]Important:

If you collocate Lync Server databases with other databases, we highly recommend assessing all factors that might affect availability and performance, as well as ensuring that, if a node fails, the remaining node can handle the load. To verify failover capabilities, we recommend testing all failover scenarios.

• Standard Edition server, which includes a collocated SQL Server Express database.

• Your deployment can also have one or more branch sites associated with a central site.

This section describes the sites and components of a Lync Server 2010 deployment. For details about Lync Server 2010 site, topology, and component planning, see Topology Basics You Must Know Before Planning and Reference Topologies in the Planning documentation. For details about integration of previous Office Communications Server components, see Supported Migration Paths and Coexistence Scenarios.

Central Site Topologies and Components

Although a central site topology must include one Front End pool or Standard Edition server, each central site can also contain the following:

• Multiple Front End pools, which can be in the same domain or different domains. Although, all Front End Servers in a Front End pool and the Back End Server for that pool, must be in the same domain.

• Multiple Standard Edition servers.

• A/V Conferencing Server or pool, if you want to support A/V conferencing functionality at the central site. For a Standard Edition server deployment, the A/V Conferencing Server is automatically collocated with the Standard Edition server and you cannot use a stand-alone A/V Conferencing Server or pool. For a Front End pool, use of a stand-alone A/V Conferencing Server or A/V Conferencing pool is optional but recommended for deployments with more than 10,000 users. The servers in an A/V Conferencing pool do not require load balancing because they provide their own load balancing. All Front End Servers of a central site that do not have a collocated A/V Conferencing Server use the same stand-alone A/V Conferencing Server or pool.

• Edge Server or Edge pool in your perimeter network, if you want your deployment to support federated partners, public IM connectivity, remote user access, participation of anonymous users in meetings, or hosted UM . You cannot collocate any other server role with an Edge Server. DNS load balancing is recommended, where appropriate, but hardware load balancing is also supported. The internal Edge interface and external Edge interface must use the same type of load balancing. You cannot use DNS load balancing on one Edge interface and hardware load balancing on the other Edge interface. For details about load balancing requirements and support, see Planning for External User Access in the Planning documentation and Deploying Edge Servers in the Deployment documentation.

• Mediation Server or pool, if you want to support Enterprise Voice or dial-in conferencing in a Front End pool at the central site. Depending on how you deploy Enterprise Voice support, you can collocate the Mediation Server in a Front End pool (the default) or deploy a stand-alone Mediation Server or pool. For details about the planning the appropriate Mediation Server topology, including collocation options, see Deployment Guidelines for Mediation Server in the Planning documentation. You can use DNS, hardware or application load balancing (when appropriate) to distribute traffic from a Mediation Server pool’s gateway peer, including a PSTN gateway, IP-PBX, or SIP trunk Session Border Control (SBC).

• Monitoring Server, if you want to support data collection about of your audio/video Quality of Experience (QoE) and call detail recording (CDR) for Enterprise Voice and A/V conferences in your deployment. Optionally, you can also install the Microsoft System Center Operations Manager (formerly Microsoft Operations Manager), which uses Monitoring CDR and QoE data to generate near real-time alerts showing the health of call reliability and media quality. A Monitoring Server can be collocated with an Archiving Server, with a SQL Server store of an Enterprise Edition Front End pool, or with a file store of a Front End pool. The Monitoring Server requires a database, but the database can be collocated on the Monitoring Server, with the database server for the Archiving Server, or on the Back End Server of an Enterprise Edition Front End pool. A Monitoring Server cannot be collocated with a Standard Edition server in a production environment.

• Archiving Server, if you want to archive IM communications and meeting content (for compliance reasons) in your deployment. An Archiving Server can be collocated with a Monitoring Server, with a SQL Server store of an Enterprise Edition Front End pool, or with a file store of an Enterprise Edition Front End pool. The Archiving Server requires a database, but the database can be collocated on the Archiving Server, with the database server for the Monitoring Server, or on the Back End Server of a Front End pool. An Archiving Server cannot be collocated with a Standard Edition server in a production environment.

• Director or Director pool, if you want to facilitate resiliency and redirection of Lync Server user requests to the user’s home pool, which can be either an Enterprise Edition Front End pool or a Standard Edition server. We recommend that you deploy a Director or Director pool in each central site that supports external user access and in each central site in which you deploy one or more Front End pools. Each Director pool can contain a maximum of ten Directors. A Director cannot be collocated with any other server role.

• Reverse proxy, which is not a Lync Server component but is required if you want to support sharing of web content for federated users. You cannot collocate a reverse proxy server with any Lync Server 2010 server role, but you can implement reverse proxy support for a Lync Server deployment by configuring the support on an existing reverse proxy server in your organization that is used for other applications.

All Front End pools and Standard Edition servers that you deploy at a central site share any of the following that you deploy for the central site:

• Director or Director pool

• Monitoring Server

• Archiving Server

• Stand-alone A/V Conferencing Server or pool (Enterprise Edition Front End pool only)

• Stand-alone Mediation Server or pool

• Edge Server or Edge pool

[pic]Note:

An Exchange UM Server can be implemented with your Lync Server 2010 deployment if you want to support integration of Microsoft Exchange unified messaging, but it is not a component of the Lync Server site.

Multiple central sites can also share any of the following that you deploy in one central site:

• Archiving Server

• Monitoring Server

• Stand-alone Mediation Server or pool

• Edge Server or Edge pool

[pic]Note:

An Exchange UM Server can be implemented with you Lync Server 2010 deployment and shared by multiple central sites, but it is not a component of the Lync Server site

For details about Lync Server 2010 server roles, see Server Roles in the Planning documentation.

For a summary of which Lync Server 2010 server roles can be collocated with other server roles, see Supported Server Collocation.

In addition to the server roles covered previously in this section, Lync Server 2010 has additional components and options, which can include some or all of the following:

• Firewalls

• PSTN gateways (if deploying Enterprise Voice)

• Exchange UM Server

• DNS load balancing

• Hardware load balancers

• SQL Server databases

• File shares

For details about all of the Lync Server 2010 components and options, see the Planning documentation.

Branch Site Topologies and Components

A branch site is associated with a central site and each Survivable Branch Appliance in a branch site is associated with an Enterprise Edition Front End pool or a Standard Edition server in the associated central site. Branch sites depend on the central site for most of their functionality, so components at a branch site contain only the following:

• A Survivable Branch Appliance, which combines a public switched telephone network (PSTN) gateway with some Lync Server functionality. Mediation Server can be collocated with the instance of the Registrar on the Survivable Branch Appliance, you can deploy a stand-alone Mediation Server or pool of Mediation Servers.

• A Survivable Branch Server, which is a Windows server that has Lync Server 2010 Registrar and Mediation Server software installed.

• A stand-alone PSTN gateway (not part of the Survivable Branch Appliance) and stand-alone Mediation Server.

The requirements for Survivable Branch Servers are the same as the requirements for any Lync Server 2010 server role.

Supported Server Collocation

Microsoft Lync Server 2010 communications software supports collocation of some server roles. Which server roles you can collocate is partly dependent on whether you are deploying a Front End pool or a Standard Edition server.

In This Section

• Server Collocation in an Enterprise Edition Front End Pool Deployment

• Server Collocation in a Standard Edition Server Deployment

Server Collocation in an Enterprise Edition Front End Pool Deployment

This section describes the server roles, databases, and file shares that you can collocate in a Microsoft Lync Server 2010 Front End pool deployment.

Server Roles

Collocation of the following server roles on the same computer is supported:

• Front End Server with the A/V Conferencing service and the Mediation service   The default configuration is collocated A/V Conferencing service and Mediation service, but you can choose to deploy either or both separately, each on a stand-alone server.

• Monitoring Server with Archiving Server   You can also collocate either or both of these on a database server, as described later in this section.

The following server roles must each be deployed on a separate computer:

• Director

• Edge Server

• Trusted Application Server

• Stand-alone A/V Conferencing Server (if not collocated with the Front End Server)

• Mediation Server (if not collocated with the Front End Server)

Collocating Microsoft Lync Server 2010, Group Chat with any server role is not supported.

If you do not collocate either or both of the following server roles on the Front End Server, you must deploy each stand-alone server on a separate computer:

• Stand-alone A/V Conferencing Server

• Stand-alone Mediation Server

Databases

You can collocate each of the following databases on the same database server:

• Back-end database

• Monitoring database

• Archiving database

You can collocate any or any or all of these databases in a single SQL instance or use a separate SQL instances for each, with the following limitations:

• Each SQL instance can contain only a single back-end database, single Monitoring database, and single Archiving database.

• The database server cannot support more than one Front End pool, one Archiving Server, and one Monitoring Server, but it can support one of each, regardless of whether the databases use the same SQL instance or separate SQL instances.

You can collocate a single Monitoring Server, a single Archiving Server, or both on with the databases. You can also collocate a file share with the databases, as described later in this section.

You should not collocate the Group Chat database and compliance database (for Group Chat Server) with any database server or with Group Chat Server. These collocations are not supported.

File Shares

The file share can be a separate server or can be collocated on the same server as any or all of the following:

• Database server, including the Back End Server of an Enterprise Edition Front End pool, Archiving database, and Monitoring database

• Monitoring Server

• Archiving Server

A single file share can be used for multiple Front End pools, Standard Edition servers, Archiving Servers, and Monitoring Servers (all in the same site).

Other Components

You cannot collocate a reverse proxy server, which is not a Lync Server 2010 component but is required in your deployment if you want to support sharing of web content for federated users, with any Lync Server server role. You can, however, implement reverse proxy support for a Lync Server deployment by configuring the support on an existing reverse proxy server in your organization that is used for other applications.

You cannot collocate any Exchange Unified Messaging (UM) component or SharePoint component with any Lync Server role.

Server Collocation in a Standard Edition Server Deployment

This section describes the server roles, databases, and file shares that you can collocate in a Microsoft Lync Server 2010 Standard Edition server deployment.

Server Roles

Collocation of the following server roles on the same computer is supported:

• Standard Edition server with A/V Conferencing service and Mediation service   The default configuration is collocated A/V Conferencing service and Mediation service. You can deploy Mediation service as a separate server or pool. You cannot deploy A/V Conferencing service as a separate server or pool.

• Monitoring Server with Archiving Server   You can collocate either or both of these with the database server, as described later in this topic.

• Standard Edition server with Monitoring Server and Archiving Server (for test purposes only)   You can collocate the Monitoring Server, Archiving Server, or both on the Standard Edition server in a test environment.

[pic]Important:

Do not collocate these two server roles on a Standard Edition server in a production environment.

The following server roles must each be deployed on a separate computer:

• Director

• Edge Server

• Trusted Application Server

Collocating Microsoft Lync Server 2010, Group Chat with any server role is unsupported.

If you do not collocate either or both of the following server roles on the Front End Server, you must deploy each stand-alone server on a separate computer:

• Stand-alone A/V Conferencing Server

• Stand-alone Mediation Server

Databases

By default, the SQL Server Express back-end database is collocated on the Standard Edition server. You cannot move it to a separate computer. You cannot collocate other databases on the Standard Edition server.

You can collocate each of the following databases on a single database server:

• Monitoring database

• Archiving database

• A back-end database for an Enterprise Edition Front End pool

You can collocate any or any or all of these databases in a single SQL instance or use a separate SQL instances for each, with the following limitations:

• Each SQL instance can contain only a single back-end database (for an Enterprise Edition Front End pool), single Monitoring database, or single Archiving database.

• The database server cannot support more than one Enterprise Edition Front End pool, one Archiving Server, and one Monitoring Server, but it can support one of each, regardless of whether the databases use the same SQL instance or separate SQL instances.

You can collocate a single Monitoring Server, a single Archiving Server, or both with the databases. You can also collocate a file share with the databases (as described later in this section).

You should not collocate the Group Chat database and compliance database (for Group Chat Server) with any database server or with Group Chat Server. These collocations are not supported.

File Shares

The file share can be a separate server or can be collocated on the same server as any or all of the following:

• Database server, including the Back End Server of a Front End pool, Archiving database, and Monitoring database

• Monitoring Server

• Archiving Server

A single file share can be used for multiple Front End pools, Standard Edition servers, Archiving Servers, and Monitoring Servers (all in the same site).

Other Components

You cannot collocate a reverse proxy server, which is not a Lync Server 2010 component but is required in your deployment if you want to support sharing of web content for federated users, with any Lync Server server role. You can, however, implement reverse proxy support for a Lync Server deployment by configuring the support on an existing reverse proxy server in your organization that is used for other applications.

You cannot collocate any Exchange Unified Messaging (UM) component or SharePoint component with any Lync Server role.

Supported Migration Paths and Coexistence Scenarios

Microsoft Lync Server 2010 supports migration from the more recent versions of Office Communications Server, including coexistence with specific client and server components of those previous deployments.

In This Section

• Supported Server Migration Paths and Coexistence Scenarios

• Supported Clients from Previous Deployments

Supported Server Migration Paths and Coexistence Scenarios

Microsoft Lync Server 2010 supports migration from either of the following:

• Microsoft Office Communications Server 2007

• Microsoft Office Communications Server 2007 R2

Migration from an environment running both of these previous versions of Office Communications Server is not supported. Migration for earlier versions, such as Live Communications Server 2005, is not supported.

Migration Methods

Migration of all Lync Server 2010 topologies and server roles is supported. You can migrate from one topology to a different topology, including from Standard Edition server to Enterprise Edition server.

Lync Server 2010 supports only the following migration method:

Side-by-side migration. In side-by-side migration, Lync Server 2010 is deployed alongside an existing Office Communications Server 2007 or Office Communications Server 2007 R2 deployment, and then you transfer operations to the new servers and move users to Lync Server 2010. This method requires additional server platforms, including hardware and software, during migration, and system names and pool names are different in the new configuration. If it becomes necessary to roll back to the previous version, you can shift operations back to the previous servers.

Migration across Active Directory forests is not supported.

The recommended migration path is a phased approach. For details about migrating from a previous release, including the appropriate phasing of component deployment, see Migration from Office Communications Server 2007 R2 to Lync Server 2010 in the Migration documentation.

Coexistence Scenarios

Lync Server 2010 can coexist with components of either an Office Communications Server 2007 deployment or an Office Communications Server 2007 R2 deployment. Concurrent deployment of Lync Server 2010 with both Office Communications Server 2007 and Office Communications Server 2007 R2 (concurrent deployment of all three versions) is not supported.

During a phased migration in which a previous Office Communications Server 2007 or Office Communications Server 2007 R2 deployment coexists temporarily with the new Lync Server 2010 deployment, support for mixed version routing is limited. For details, see the Migration documentation.

You can deploy a Lync Server 2010 database as new instance on an existing SQL Server on which you have deployed an Office Communications Server 2007 or Office Communications Server 2007 R2 database, if the hardware and software meet Lync Server 2010 requirements and minimum network requirements. You cannot use the same SQL instance for a Lync Server 2010 Front End pool that you use for an Office Communications Server 2007 or Office Communications Server 2007 R2 Front End pool.

[pic]Note:

If you intend to deploy server roles that are new to Lync Server 2010, such as a stand-alone A/V Conferencing Server or Survivable Branch Appliance, we recommend that you first upgrade your existing deployment as described in the Migration documentation and the Deployment documentation, and then deploy the new server roles as described in the Planning documentation and Deployment documentation.

For specific coexistence requirements and other details about coexistence and migration of Office Communications Server 2007 or Office Communications Server 2007 R2 and Lync Server 2010 components, see Migration from Office Communications Server 2007 R2 to Lync Server 2010 and Migration from Office Communications Server 2007 to Lync Server 2010 in the Migration documentation. For details about coexistence of Lync Server 2010 pools and Directors with Office Communications Server 2007 or Office Communications Server 2007 R2 pools and Directors, see Coexistence Changes in the Planning documentation. For details about mixed version support for clients, see Supported Clients from Previous Deployments. For details about support for previous UCMA applications, see Migrate Applications Built on Microsoft Unified Communications Managed API (UCMA) 2.0 Core SDK in the Planning documentation.

Supported Clients from Previous Deployments

In a coexistence scenario, Microsoft Lync Server 2010 communications software clients can interact with clients from earlier versions of Microsoft Office Communications Server. Users homed on different versions of the server and who are using different clients and client versions can interact as follows:

• When Lync Server 2010 clients interact with Office Communications Server 2007 R2 clients, instant messaging (IM), presence, and voice features are supported.

• When Lync Server 2010 clients interact with Office Communications Server 2007 clients, IM, presence, and video are supported with some voice feature limitations. For details see Client Interoperability in the Planning documentation.

• Interaction with Microsoft Office Communicator 2005 clients (basic presence and IM) is supported only if the Office Communicator 2005 user is on a federated network.

[pic]Note:

Users cannot use Lync Server 2010 clients to sign in to previous server versions.

For details about the ability of Lync Server 2010 clients to coexist and interact with clients from earlier versions of Office Communications Server, see Client Interoperability in the Planning documentation.

Supported Hardware

Hardware requirements vary according to server role, topology, storage requirements, and the specific deployment scenario.

In This Section

• Server Hardware Platforms

• Client and Device Hardware Support

• File Storage Support

Server Hardware Platforms

Microsoft Lync Server 2010 communications software server roles and computers running Lync Server administrative tools require 64-bit hardware.

The specific hardware used for Lync Server 2010 deployment can vary depending on size and usage requirements. This section describes the recommended hardware. Although these are recommendations, not requirements, using hardware that does not meet these recommendations can result in significant performance impacts and other problems.

Hardware Support for Servers Running Lync Server 2010

The following table describes the recommended hardware for all servers where you plan to install Lync Server 2010, except for the Director server role. These recommendations are based on a user pool of 80,000 users with eight Front End Servers and one Back End Server.

Hardware Recommendations for Servers Running Lync Server 2010

|Hardware component |Recommended |

|CPU |One of the following: |

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

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

| |Intel Itanium processors are not supported for Lync Server 2010 |

| |server roles. |

|Memory |16 GB |

|Disk |Local storage with at least 72 GB free disk space on a 10,000 RPM|

| |disk drive |

|Network |1 network adapter required (2 recommended), each 1 Gbps or higher|

Servers running the Director server role have lesser hardware requirements. These recommendations are based on a maximum of 39,000 external users per Front End pool (which follows the user model of 80,000 users per Front End pool, with 30% of users connecting externally and 1.5 multiple points of presence (MPOP)

Hardware Recommendations for Directors

|Hardware component |Recommended |

|CPU |One of the following: |

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

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

| |Intel Itanium processors are not supported for Lync Server 2010 |

| |server roles. |

|Memory |4 GB |

|Disk |Local storage with at least 72 GB free disk space on a 10,000 RPM|

| |disk drive |

|Network |1 network adapter required (2 recommended), each 1 Gbps or higher|

Hardware Support for Back End Servers and Other Database Servers

Back End Server requirements and requirements for other database servers are similar to those of servers running Lync Server 2010, except that Back End Servers require additional memory. The following table describes the recommended hardware for a Back End Server or other database servers, based on a 80,000 user pool with eight Front End Servers and one Back End Server with all databases required for your Lync Server deployment running on a single database server.

Hardware Recommendations for Back End Servers and Other Database Servers

|Hardware component |Recommended |

|CPU |One of the following: |

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

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

|Memory |32 GB recommended for Back End Server (with or without collocated|

| |Archiving and Monitoring databases), 16 GB recommended for |

| |Archiving and Monitoring database (not collocated with the Back |

| |End Server). |

|Disk |Local storage with at least 72 GB free disk space on a 10,000 RPM|

| |disk drive |

|Network |1 network adapter required (2 recommended), each 1 Gbps or higher|

Client and Device Hardware Support

Client computers must meet certain hardware requirements to support Microsoft Lync Server 2010 communications software clients. Additional hardware configurations must be in place before you deploy IP phones and analog devices.

In This Section

• Client Hardware Support

• Device Hardware Support

Client Hardware Support

This section describes the recommended hardware for Microsoft Lync Server 2010 communications software clients.

Recommended Hardware for Microsoft Lync 2010, Online Meeting Add-in for Microsoft Lync 2010, and Microsoft Lync 2010 Attendee

|Hardware component |Minimum requirement |

|CPU |Intel Pentium 4, AMD Athlon 64, or equivalent |

| |Data and voice: 1.6 gigahertz (GHz) or higher processor, 2 GHz |

| |32-bit or 64-bit processor (recommended) |

| |For video: Dual Core 1.9 GHz processor or higher for VGA, Quad |

| |Core 2.0 GHz or higher for high definition |

| |For the Microsoft RoundTable conferencing device: 2 GHz processor|

| |or higher |

|Memory |On Windows XP: 1 gigabyte (GB) of RAM |

| |On Windows Vista or Windows 7: 2 GB of RAM |

|Display resolution |1024x768 required |

|Graphics hardware |• Support for Microsoft DirectX 9.0 application programming |

| |interface (API) |

| |• 128 MB of graphics memory (minimum) |

| |• Windows Display Driver Model driver |

| |• Pixel Shader 2.0 in hardware |

| |• 32 bits per pixel |

|Telephony |Microphone and speakers, headset with microphone, or equivalent |

| |device |

| |Recommended: Microsoft unified communications (UC) device, or a |

| |phone running Microsoft Lync 2010 Phone Edition |

|Video source |USB 2.0 video camera or RoundTable device |

|Network |For network requirements, see Media Traffic Network Usage in the |

| |Planning documentation. |

Recommended Hardware for Microsoft Lync 2010 Attendant

|Hardware component |Minimum requirement |

|CPU |Intel Pentium 4, AMD Athlon 64, or equivalent |

| |Data and voice: 1 GHz or larger processor. Support for 32-bit and|

| |64-bit |

| |For the Microsoft RoundTable conferencing device: 2 GHz processor|

| |or higher |

|Memory |On Windows XP: 1 GB of RAM |

| |On Windows Vista or Windows 7: 2 GB of RAM |

|Display resolution |Required: Super VGA 1024 x 768 |

| |Recommended: Super VGA 1280 x 1024 or higher |

|Hard disk drive |At least 100 MB free |

|Telephony |Microphone and speakers, headset with microphone, or equivalent |

| |device |

| |Recommended: Microsoft unified communications (UC) device |

|Bandwidth requirements |Voice: 50 kbps (minimum); 80 kbps (high-quality) |

| |RoundTable device (for audio): 50 kbps (minimum); 350 kbps |

| |(high-quality) |

Device Hardware Support

Specific hardware configurations must be in place before you deploy IP phones and analog devices.

IP phones running Microsoft Lync 2010 Phone Edition communications software support Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED) and Power over Ethernet (PoE). To take advantage of LLDP-MED, the switch must support IEEE802.1AB and ANSI/TIA-1057. To take advantage of PoE, the switch must support PoE802.3AF or 802.3at.

To enable LLDP-MED, the administrator must enable LLDP by using the switch console window and set the LLDP-MED network policy with the correct voice VLAN ID.

In addition, if your deployment includes analog devices, you must configure the analog gateway to use Microsoft Lync Server 2010, and the gateway must be one of the following:

• An analog telephone adapter (ATA)

• A PSTN analog gateway

• A Survivable Branch Appliance that includes a PSTN analog gateway

• A Survivable Branch Appliance that includes a PSTN gateway that communicates with an ATA

To learn how to configure an analog gateway, see Planning to Deploy Analog Devices in the Planning documentation.

[pic]Important:

You can configure the switch for Enhanced 9-1-1 (E9-1-1), if the switch supports this.

File Storage Support

Microsoft Lync Server 2010 communications software supports using file shares on either direct attached storage (DAS) or a storage area network (SAN), including Distributed File System (DFS), and on a redundant array of independent disks (RAID) for file stores. For details about storage requirements, see Technical Requirements for IM and Presence and Technical Requirements for Director in the Planning documentation. For details about DFS for Windows Server 2008, see the DFS Step-by-Step Guide for Windows Server 2008 at .

Lync Server 2010 supports the use of a shared cluster for the file shares in your deployment. If you use a shared cluster for the file shares in your deployment, you should use cluster servers running Windows Server 2008 or Windows Server 2008 R2. Using cluster servers running an older version of Windows may encounter permission issues that prevent some features from being available. Use the Cluster Administrator to create the file shares. For details about using the Cluster Administrator, see Microsoft Knowledge Base article 284838, “How to Create a Server Cluster File Share with Cluster.exe” at .

Server Software and Infrastructure Support

Software support for server components, including all Microsoft Lync Server 2010 server roles and storage, includes supported operating systems, database software, infrastructure software, and other software required to support specific functionality. It also includes virtualization of server components.

In This Section

• Server and Tools Operating System Support

• Database Software and Clustering Support

• Certificate Infrastructure Support

• Wildcard Certificate Support

• Domain Name System (DNS) Infrastructure Support

• Internet Information Services (IIS) Support

• IP and Networking Protocol Support

• Voice Support

• Virtualization Support

Server and Tools Operating System Support

All server roles support the same Windows Server operating systems. The required operating system support for other server roles, such as database servers, depends on what software you install on those servers.

Microsoft Lync Server 2010 communications software administrative tools are installed by default on the server running Lync Server 2010, but you can install administrative tools separately on other computers running Windows operating systems. For example, you can use a client computer running Windows 7 as an administrative console for planning purposes.

[pic]Important:

Lync Server 2010 is available only in 64-bit, which requires 64-bit hardware and 64-bit editions of Windows Server. Lync Server 2010 is not available in a 32-bit version. This means that all server roles and computers running Lync Server administrative tools run a 64-bit edition operating system.

Operating Systems for Server Roles

Microsoft Lync Server 2010 supports the 64-bit editions of the following operating systems:

• The Windows Server 2008 R2 Standard operating system (required) or latest service pack (recommended)

• The Windows Server 2008 R2 Enterprise operating system (required) or latest service pack (recommended)

• The Windows Server 2008 R2 Datacenter operating system (required) or latest service pack (recommended)

• The Windows Server 2008 Standard operating system with Service Pack 2 (SP2) (required) or latest service pack (recommended)

• The Windows Server 2008 Enterprise operating system with SP2 (required) or latest service pack (recommended)

• The Windows Server 2008 Datacenter operating system with SP2 (required) or latest service pack (recommended)

[pic]Notes:

If you have an existing server running Windows Server 2008 with Service Pack 1 (SP1), you must upgrade it to either Windows Server 2008 SP2 (or latest service pack), or Windows Server 2008 R2 (or latest service pack) before deploying Lync Server 2010.

To deploy Lync Server 2010 on a computer that is running either the Windows Server 2008 R2 Datacenter operating system or the Windows Server 2008 Datacenter operating system with Service Pack 2 (SP2) and that is configured for multiple processor groups (dynamic hardware partitioning), you must upgrade Microsoft SQL Server 2008 Express database software, which is installed by default when you install Lync Server 2010, to Microsoft SQL Server 2008 R2 Express. The SQL instance name is RTC for a Standard Edition server back-end database and RTCLocal for the local configuration store (on each server role). A server running Lync Server 2010 Standard Edition has both SQL instances, and each needs to be upgraded separately.

Lync Server 2010 is not supported on the following operating systems:

• The Server Core installation option of Windows Server 2008 R2 or Windows Server 2008

• The Windows Web Server 2008 R2 operating system or the Windows Web Server 2008 operating system

• Windows Server 2008 R2 HPC Edition or Windows Server 2008 HPC Edition

Operating Systems for Other Servers

Operating system support for servers other than those on which you deploy Lync Server 2010 server roles is dependent on the software you plan to install on those servers. For details about requirements for Back End Servers and other database servers, see Database Software and Clustering Support. For details about requirements for reverse proxy servers (for edge deployment), see Internet Information Services (IIS) Support. For details about other software requirements, including infrastructure and virtualization support, see the other topics in the Server Software and Infrastructure Support section.

Additional Operating Systems for Administrative Tools

Lync Server 2010 supports installation of the administrative tools, which includes the Topology Builder, on computers running any of the 64-bit editions of the operating systems supported for deployment of server roles (as described in the previous section). Additionally, you can install administrative tools on the 64-bit editions of the following operating systems:

• The Windows 7 operating system (required) or latest service pack (recommended)

• The Windows Vista operating system with SP2 (required) or latest service pack (recommended)

Operating System for the Planning Tool

Lync Server 2010 supports installation of the Planning Tool on computers running any of the following operating systems:

• The 32-bit version of Windows 7 operating system (required) or latest service pack (recommended)

• The 64-bit version of Windows 7 operating system (required) or latest service pack (recommended) using the WOW64 x86 emulator

• The 32-bit edition of Windows Vista with SP2 operating system (required) or latest service pack (recommended)

• The 64-bit edition of Windows Vista with SP2 operating system (required) or latest service pack (recommended) using the WOW64 x86 emulator

• The 32-bit edition of Windows XP with SP3 operating system (required) or latest service pack (recommended)

• The 64-bit edition of Windows XP with SP3 operating system (required) or latest service pack (recommended) using WOW64 x86

• The 32-bit edition of Windows Server 2008 operating system (required) or latest service pack (recommended)

• The 64-bit edition of Windows Server 2008 operating system (required) or latest service pack (recommended) using WOW64 x86

• The 64-bit edition of Windows Server 2008 R2 operating system (required) or latest service pack (recommended) using WOW64 x86

Database Software and Clustering Support

The following list contains the database management systems for the back-end database, the Archiving database, the Monitoring database, Group Chat database and Group Chat compliance database that are supported by Microsoft Lync Server 2010:

• Back-end database of a Front End pool, Archiving database, Monitoring database, Group Chat database and Group Chat compliance database

• Microsoft SQL Server 2008 R2 Enterprise database software (64-bit edition) or latest service pack (recommended)

• Microsoft SQL Server 2008 R2 Standard (64-bit edition) or latest service pack (recommended)

• Microsoft SQL Server 2008 Enterprise (64-bit edition) with Service Pack 1 (SP1) (required) or latest service pack (recommended)

• Microsoft SQL Server 2008 Standard (64-bit edition) with SP1 (required) or latest service pack (recommended)

• Microsoft SQL Server 2005 Enterprise (64-bit edition) with Service Pack 3 (SP3) (required) or latest service pack (recommended)

• Microsoft SQL Server 2005 Standard (64-bit edition) with SP3 (required) or latest service pack (recommended)

• Standard Edition server database and local configuration store databases

• Microsoft SQL Server 2008 Express database software (64-bit edition)

[pic]Notes:

SQL Server Express (64-bit edition) is automatically installed by Lync Server 2010 on each Standard Edition server and each Lync Server 2010 server on which the local configuration store is deployed.

Lync Server 2010 supports manually upgrading each SQL Server 2008 Express database to SQL Server 2008 R2 Express (64-bit edition), after the initial deployment of each Standard Edition server and other Lync Server 2010 server on which the local configuration store is located.

[pic]Important

Lync Server 2010 does not support SQL Server 2008 32-bit edition, SQL Server 2008 R2 32-bit edition, or SQL Server 2005 32-bit edition. You must use the 64-bit edition.

SQL Server Web edition and SQL Server Workgroup edition are not supported. You cannot use them with Lync Server 2010.

Lync Server 2010 does not support native database mirroring.

To use the Monitoring Server role, you should install SQL Server Reporting Services.

In a Front End pool, the back-end database can be a single computer running SQL Server. Alternatively, you can cluster two or more dedicated computers running SQL Server in a multiple-node active/passive configuration. A SQL Server cluster for the back-end database improves availability by providing failover capabilities. In a multiple-node cluster, the Lync Server 2010 SQL instance must be able to failover to a passive node that, for performance reasons, should not be shared by any other SQL instance.

SQL Server database clustering using Windows clustering is the only SQL Server high availability mechanism supported by Lync Server 2010. SQL Server clustering support includes the following:

• Two-node failover clustering for the following:

• SQL Server 2008 R2 Standard or latest service pack (recommended)

• SQL Server 2008 Standard with SP1 (required) or latest service pack (recommended)

• SQL Server 2005 Standard with SP3 (required) or latest service pack (recommended)

• Up to sixteen-node failover clustering for the following:

• SQL Server 2008 R2 Enterprise or latest service pack (recommended)

• SQL Server 2008 Enterprise with SP1 (required) or latest service pack (recommended)

• SQL Server 2005 Enterprise with SP3 (required) or latest service pack (recommended)

[pic]Important:

If you collocate Lync Server databases with other databases, we highly recommend assessing all factors that might impact availability and performance, as well as ensuring that, if one node fails, the remaining node can handle the load. To verify failover capabilities, we recommend testing all failover scenarios.

Certificate Infrastructure Support

Microsoft Lync Server 2010 communications software requires a public key infrastructure (PKI) to support Transport Layer Security (TLS) and mutual TLS (MTLS) connections. By default, Lync Server 2010 is configured to use TLS for client-to-server connections. MTLS is used for connections between servers.

MTLS certificates must be issued by trusted certification authorities (CAs) for Lync Server. Lync Server supports certificates that are issued from the following CAs:

• Certificates issued from an internal CA:

• The Windows Server 2008 operating system CA

• The Windows Server 2008 R2 operating system CA

• The Windows Server 2003 Enterprise Edition operating system with Service Pack 1 (SP1) CA

• Windows Server 2003 operating system with SP1 stand-alone CA (supported, but not recommended)

When submitting a web-based certificate request to a Windows Server 2003 CA, you must submit it from a computer running either Windows Server 2003 with SP2 or Windows XP.

• Certificates issued from a public CA

For connections from clients running Windows 7 operating system, Windows Server 2008 operating system, Windows Server 2008 R2 operating system, Windows Vista operating system, and Microsoft Office Communicator 2007 Phone Edition, Lync Server 2010 includes support for certificates signed using the SHA-256 cryptographic hash function. To support external access using SHA-256, the external certificate is issued by a public CA using SHA-256.

Wildcard Certificate Support

Microsoft Lync Server 2010 uses certificates to provide communications encryption and server identity authentication. In some cases, such as web publishing through the reverse proxy, strong subject alternative name (SAN) entry matching to the fully qualified domain name (FQDN) of the server presenting the service is not required. In these cases, you can use certificates with wildcard SAN entries (commonly known as “wildcard certificates”) to reduce the cost of a certificate requested from a public certification authority and to reduce the complexity of the planning process for certificates.

[pic]Warning:

To retain the functionality of unified communications (UC) devices (for example, desk phones), you should test the deployed certificate carefully to ensure that devices function properly after you implement a wildcard certificate.

There is no support for a wildcard entry as the subject name (also referred to as the common name or CN) for any role. The following server roles are supported when using wildcard entries in the SAN:

Reverse proxy. Wildcard SAN entry is supported for simple URL publishing certificate.

Director. Wildcard SAN entry is supported for simple URLs in Director web components.

Front End Server (Standard Edition) and Front End pool (Enterprise Edition). Wildcard SAN entry is supported for simple URLs in Front End web components.

Exchange Unified Messaging (UM). The server dos not use SAN entries when deployed as a stand-alone server.

Microsoft Exchange Server Client Access server. Wildcard entries in the SAN are supported for internal and external clients.

Exchange Unified Messaging (UM) and Microsoft Exchange Server Client Access server on same server. Wildcard SAN entries are supported.

Server roles that are not addressed in this topic:

• Internal server roles (including, but not limited to the Mediation Server, Archiving and Monitoring Server, Survivable Branch Appliance, or Survivable Branch Server)

• External Edge Server interfaces

• Internal Edge Server

[pic]Note:

For the internal Edge Server interface, a wildcard entry can be assigned to the SAN, and is supported. The SAN on the internal Edge Server is not queried, and a wildcard SAN entry is of limited value.

To describe the possible wildcard certificate usages, the certificate guidance used for the Reference Architectures in the Planning documentation is replicated here to retain consistency. For details, see Reference Architecture. As mentioned previously, UC devices rely on strong name matching and will fail to authenticate if a wildcard SAN entry is presented before the FQDN entry. By following the order presented in the following tables, you limit the potential problems with a UC device and wildcard entries in the SAN.

Wildcard Certificate Configurations for Lync Server 2010

|Component |Subject name |SAN entries/Order |Certification |Enhanced key |Comments |

| | | |authority (CA) |usage (EKU) | |

|Director |dirpool01. |sip. |Private |Server |Assign to the |

| | |sip. | | |following servers and|

| | |dirweb. | | |roles in the Director|

| | |dirweb-ext. | | |pool: |

| | |., for | | |Each Director in the |

| | |example is director01| | |pool or to the |

| | |for a Director in a pool | | |stand-alone Director |

| | |dirpool. | | |when a Director pool |

| | |*. | | |is not deployed. |

| | | | | |The wildcard replaces|

| | | | | |both meet and dialin |

| | | | | |SAN where the meet |

| | | | | |and dialin simple |

| | | | | |URLs use the |

| | | | | |following formats: |

| | | | | |/admin |

| | | | | |/meet |

| | | | | |/dialin |

| | | | | |OR |

| | | | | |admin. |

| | | | | |meet. |

| | | | | |dialin. |

| Enterprise |pool01. (For a |sip. |Private |Server |Assign to the |

|Edition Front |load balanced pool) |sip. | | |following servers and|

|End | |lsweb. | | |roles in the next hop|

| | |lsweb-ext. | | |pool: |

| | |., for | | |Front End in Pool01 |

| | |example is fe01 for a| | |The wildcard replaces|

| | |front end server in a pool | | |both meet and dialin |

| | |pool01. | | |SAN where the meet |

| | |*. | | |and dialin simple |

| | | | | |URLs use the |

| | | | | |following formats: |

| | | | | |/admin |

| | | | | |/meet |

| | | | | |/dialin |

| | | | | |OR |

| | | | | |admin. |

| | | | | |meet. |

| | | | | |dialin. |

|Standard |se01. |sip. |Private |Server |Assign to the |

|Edition Front | |sip. | | |following servers and|

|End | |lsweb. | | |roles in the next hop|

| | |lsweb-ext. | | |pool: |

| | |se01. | | |The wildcard replaces|

| | |*. | | |both meet and dialin |

| | | | | |SAN where the meet |

| | | | | |and dialin simple |

| | | | | |URLs use the |

| | | | | |following formats: |

| | | | | |/admin |

| | | | | |/meet |

| | | | | |/dialin |

| | | | | |OR |

| | | | | |admin. |

| | | | | |meet. |

| | | | | |dialin. |

Microsoft Exchange Server 2007 and Exchange Server 2010

When you install and configure Microsoft Exchange Server, self-signed certificates are created and implemented. When you add a CA provided certificate to the server, we recommend that you do not delete the self-signed certificate until you have reconfigured all services and web services to successfully use the new certificate. In the event that something does not work correctly, the self-signed certificate will still be available so that you can reconfigure the original settings and restore the original functions, although the self-signed certificate will not allow all of the features that you need. This provides you with additional time to resolve the configurations without affecting all production functions.

For details about certificate use in Exchange, see the following:

• Understanding Digital Certificates and SSL:

• Understanding Client Access server Namespaces:

• Understanding the Autodiscover Service:

For Microsoft Exchange Server deployed with the Exchange Unified Messaging (UM) and Exchange Client Access server, there are four possible deployment scenarios:

• Scenario 1: Exchange Unified Messaging (UM) and Exchange Client Access server are deployed on different servers and Client Access server is Internet facing.

• Scenario 2: Exchange Unified Messaging (UM) and Exchange Client Access server are collocated on the same server and are Internet facing.

• Scenario 3: Exchange Unified Messaging (UM) and Exchange Client Access server are deployed on different servers with a reverse proxy for publishing.

• Scenario 4: Exchange Unified Messaging (UM) and Exchange Client Access server are collocated on the same server with a reverse proxy for publishing.

Scenario 1: Exchange Unified Messaging (UM) & Exchange Client Access Server Deployed on Different Servers (Client Access Server is Internet Facing)

|Microsoft Exchange component |Subject name |SAN entries/Order |Certification |Enhanced key usage |Comments |

| | | |authority (CA) |(EKU) | |

|Exchange Client Access server |mail. |mail. |Public |Server |Subject Name and SAN entry must match to |

|Internet-facing Active Directory | |autodiscover. | | |support external UC devices. |

|site Client Access server | |*. | | |Subject name and SAN entry |

|Server name: exchcas01. | | | | |mail. is an example name used |

| | | | | |to refer to Outlook Web Access, Outlook |

| | | | | |Anywhere, EWS, and the Offline Address |

| | | | | |Book. The only requirements are that the |

| | | | | |entry must match a DNS record and that |

| | | | | |the ExternalURL and other service entries|

| | | | | |can be referenced by the given name. |

| | | | | |autodiscover SAN entry is required to |

| | | | | |support external UC devices. |

|Exchange Client Access server |internalcas01. |internalcas01. |Private |Server |Non-Internet facing Active Directory site|

|Non-Internet-facing Active Directory| |*. | | |Client Access server communicates only |

|site Client Access server | | | | |with internal clients and servers. The |

|Server name: | | | | |Internet facing Active Directory site |

|internalcas01. | | | | |Client Access server proxies |

| | | | | |communications to this Client Access |

| | | | | |server if the request comes from a user |

| | | | | |or service that is querying for services |

| | | | | |(for example, mailbox) that is hosted in |

| | | | | |this Active Directory site. |

| | | | | |EWS and Offline Address Book services on |

| | | | | |the non-Internet facing Active Directory |

| | | | | |site are configured to use the |

| | | | | |certificate deployed. This certificate |

| | | | | |can be from the internal private CA. The |

| | | | | |root certificate for the private CA must |

| | | | | |be imported into the Trusted Third Party |

| | | | | |Root Certificates store on the |

| | | | | |Internet-facing Active Directory site |

| | | | | |Client Access server. |

Scenario 2: Exchange Unified Messaging (UM) & Exchange Client Access Server Collocated on Same Server (Internet Facing)

|Microsoft Exchange component |Subject name |SAN entries/Order |Certification |Enhanced key usage |Comments |

| | | |authority (CA) |(EKU) | |

|Exchange Client Access server and |mail. |mail. |Public |Server |Subject Name and SAN entry must match |

|Internet-facing Active Directory | |autodiscover. | | |to support external UC devices. |

|site Client Access server | |*. | | |Subject name and SAN entry |

|Server name: exchcas01. | | | | |mail. is an example name |

| | | | | |used to refer to Outlook Web Access, |

| | | | | |Outlook Anywhere, EWS, and the Offline|

| | | | | |Address Book. The only requirements |

| | | | | |are that the entry must match a DNS |

| | | | | |record and that the ExternalURL and |

| | | | | |other service entries can be |

| | | | | |referenced by the given name. |

| | | | | |autodiscover. SAN |

| | | | | |entry is required to support external |

| | | | | |UC devices. |

|Exchange Client Access server |internalcas01. |internalcas01. |Private |Server |Non-Internet facing Active Directory |

|Non-Internet facing Active Directory| |*. | | |site Client Access server communicates|

|site Client Access server | | | | |only with internal clients and |

|Server name: | | | | |servers. The Internet-facing Active |

|internalcas01. | | | | |Directory site Client Access server |

| | | | | |proxies communications to this Client |

| | | | | |Access server if the request comes |

| | | | | |from a user or service that is |

| | | | | |querying for services (for example, |

| | | | | |mailbox) that is hosted in this Active|

| | | | | |Directory site. |

| | | | | |Exchange Web Services and Offline |

| | | | | |Address Book services on the |

| | | | | |non-Internet facing Active Directory |

| | | | | |site are configured to use the |

| | | | | |certificate deployed. This certificate|

| | | | | |can be from the internal private CA. |

| | | | | |The root certificate for the private |

| | | | | |CA must be imported into the Trusted |

| | | | | |Third Party Root Certificates store on|

| | | | | |the Internet-facing Active Directory |

| | | | | |site Client Access server. |

Scenario 3: Exchange Unified Messaging (UM)/Exchange Client Access Server Deployed on Different Servers with Reverse Proxy for Publishing

|Microsoft Exchange component |Subject name |SAN entries/Order |Certification |Enhanced key usage |Comments |

| | | |authority (CA) |(EKU) | |

|Exchange Client Access server |exchcas01. |exchcas01. |Private |Server |Subject Name and SAN entry must match |

|Server name: exchcas01. | |mail. | | |to support external UC devices. |

| | |autodiscover. | | |Import private CA root certificate |

| | |*. | | |onto each Exchange Client Access |

| | | | | |server. |

| | | | | |Subject name and SAN entry |

| | | | | |mail. is an example name |

| | | | | |used to refer to Outlook Web Access, |

| | | | | |Outlook Anywhere, EWS, and the Offline|

| | | | | |Address Book. The only requirements |

| | | | | |are that the entry must match a DNS |

| | | | | |record and that the ExternalURL and |

| | | | | |other service entries can be |

| | | | | |referenced by the given name. |

| | | | | |autodiscover SAN entry is required to |

| | | | | |support external UC devices. |

| | | | | |The entry for the machine name (in |

| | | | | |this example, exchcas01.) |

| | | | | |must exist for integration with |

| | | | | |Outlook Web Access and IM. |

|Reverse Proxy |mail. |mail. |Public |Server |A matching entry for the subject name |

|Server name : rp. | |autodiscover. | | |must also be in the SAN of the |

| | |*. | | |certificate. |

| | | | | |Terminating TLS or SSL at the reverse |

| | | | | |proxy and then reestablishing TLS or |

| | | | | |SSL to the Client Access server will |

| | | | | |cause UC devices to fail. A feature of|

| | | | | |some products such as Microsoft |

| | | | | |Internet Security and Acceleration |

| | | | | |(ISA) Server and Microsoft Forefront |

| | | | | |Threat Management Gateway and other |

| | | | | |third-party implementations, TLS or |

| | | | | |SSL termination cannot be used if you |

| | | | | |will be supporting UC devices. |

| | | | | |SAN entry for autodiscover must exist |

| | | | | |for UC devices to work correctly. |

|Exchange Client Access server |internalcas01. |internalcas01. |Private |Server |Non-Internet facing Active Directory |

|Non-Internet-facing Active Directory | |*. | | |site Client Access server communicates|

|site Client Access server | | | | |only with internal clients and |

|Server name: | | | | |servers. The Internet facing Active |

|internalcas01. | | | | |Directory site Client Access server |

| | | | | |proxies communications to this Client |

| | | | | |Access server if the request comes |

| | | | | |from a user or service that is |

| | | | | |querying for services (for example, |

| | | | | |mailbox) that is hosted in this Active|

| | | | | |Directory site. |

| | | | | |Exchange Web Services and Offline |

| | | | | |Address Book services on the |

| | | | | |non-Internet facing Active Directory |

| | | | | |site are configured to use the |

| | | | | |certificate deployed. This certificate|

| | | | | |can be from the internal private CA. |

| | | | | |The root certificate for the private |

| | | | | |CA must be imported into the Trusted |

| | | | | |Third Party Root Certificates store on|

| | | | | |the Internet facing Active Directory |

| | | | | |site Client Access server. |

Scenario 4: Exchange Unified Messaging (UM)/Exchange Client Access Server Collocated on Same Server with Reverse Proxy for Publishing

|Microsoft Exchange component |Subject name |SAN entries/Order |Certification |Enhanced key usage |Comments |

| | | |authority (CA) |(EKU) | |

|Exchange Client Access server |mail. |exchcas01. |Private |Server |Subject Name and SAN entry must match to |

|Exchange Unified Messaging (UM) | |mail. | | |support external UC devices. |

|Server name: exchcas01. | |autodiscover. | | |Import private CA root certificate onto |

| | |*. | | |each Exchange Client Access server. |

| | | | | |Subject name and SAN entry |

| | | | | |mail. is an example name used |

| | | | | |to refer to Outlook Web Access, Outlook |

| | | | | |Anywhere, EWS, and the Offline Address |

| | | | | |Book. The only requirements are that the |

| | | | | |entry must match a DNS record and that |

| | | | | |the ExternalURL and other service entries|

| | | | | |can be referenced by the given name. |

| | | | | |autodiscover SAN entry is required to |

| | | | | |support external UC devices. |

| | | | | |The entry for the machine name (in this |

| | | | | |example, exchcas01.) must |

| | | | | |exist for integration with Outlook Web |

| | | | | |Access and IM. |

|Reverse Proxy |mail. |mail. |Public |Server |A matching entry for the subject name |

|Server name : rp. | |autodiscover. | | |must also be in the SAN of the |

| | |*. | | |certificate. |

| | | | | |Terminating TLS or SSL at the reverse |

| | | | | |proxy and then reestablishing TLS or SSL |

| | | | | |to the Client Access server will cause UC|

| | | | | |devices to fail. A feature of some |

| | | | | |products such as ISA Server and Forefront|

| | | | | |Threat Management Gateway (TMG) and other|

| | | | | |third-party implementations, TLS or SSL |

| | | | | |termination cannot be used if you will be|

| | | | | |supporting UC devices. |

| | | | | |SAN entry for autodiscover must exist for|

| | | | | |UC devices to work correctly. |

|Exchange Client Access server |internalcas01. |internalcas01. |Private |Server |Non-Internet facing Active Directory site|

|Non-Internet-facing Active Directory | |*. | | |Client Access server communicates only |

|site Client Access server | | | | |with internal clients and servers. The |

|Server name: | | | | |Internet-facing Active Directory site |

|internalcas01. | | | | |Client Access server proxies |

| | | | | |communications to this Client Access |

| | | | | |server if the request comes from a user |

| | | | | |or service that is querying for services |

| | | | | |(for example, mailbox) that is hosted in |

| | | | | |this Active Directory site. |

| | | | | |Exchange Web Services and Offline Address|

| | | | | |Book services on the non-Internet facing |

| | | | | |Active Directory site are configured to |

| | | | | |use the certificate deployed. This |

| | | | | |certificate can be from the internal |

| | | | | |private CA. The root certificate for the |

| | | | | |private CA must be imported into the |

| | | | | |Trusted Third Party Root Certificates |

| | | | | |store on the Internet-facing Active |

| | | | | |Directory site Client Access server. |

Domain Name System (DNS) Infrastructure Support

Microsoft Lync Server 2010 communications software requires Domain Name System (DNS) and uses it in the following ways:

• To discover internal servers or pools for server-to-server communications.

• To allow clients to discover the Front End pool or Standard Edition server used for various SIP transactions.

• To associate the simple URLs for conferences with the servers hosting those conferences.

• To allow external servers and clients to connect to Edge Servers or the HTTP reverse proxy for instant messaging (IM) or conferencing.

• To allow unified communications (UC) devices that are not logged in to discover the Front End pool or Standard Edition server running Device Update Web service, obtain updates, and send logs.

• To allow mobile clients to automatically discover Web Services resources without requiring users to manually enter URLs in device settings.

• For DNS load balancing.

[pic]Note:

Lync Server 2010 does not support internationalized domain names (IDNs).

[pic]Important:

The name you specify must be identical to the computer name configured on the server. By default the computer name of a computer that is not joined to a domain is a short name, not a fully qualified domain name (FQDN). Topology Builder uses FQDNs, not short names. So, you must configure a DNS suffix on the name of the computer to be deployed as an Edge Server that is not joined to a domain. Use only standard characters (including A–Z, a–z, 0–9, and hyphens) when assigning FQDNs of your Lync Servers, Edge Servers, and pools. Do not use Unicode characters or underscores. Nonstandard characters in an FQDN are often not supported by external DNS and public CAs (that is, when the FQDN must be assigned to the SN in the certificate). For details about adding a DNS suffix to a computer name, see Configure DNS Records for Edge Support.

Internet Information Services (IIS) Support

Several Microsoft Lync Server 2010 communications software components require Internet Information Services (IIS). For details about the IIS requirements for Lync Server 2010 components, see Internet Information Services (IIS) Requirements in the Planning documentation.

IP and Networking Protocol Support

Microsoft Lync Server 2010 communications software supports the following IP and networking protocols:

• IP Protocols. Lync Server 2010 supports only IP version 4 (IPv4). It does not support IP version 6 (IPv6).

[pic]Note:

Lync Server 2010 can function in a network with dual IP stack enabled.

• SIP Transport Protocols. Generically, SIP can use at least three transport types: User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Transport Layer Security (TLS). In the default SIP transport configuration, TLS runs over TCP. TLS is used within the Lync Server network. At the edge of the network, Lync Server can interoperate over TCP. Lync Server 2010 does not support UDP for SIP transport because it doesn’t meet the minimum standards for enterprise communications security, reliability, and scalability. For details, see the Office Communications Server team blog article, "To UDP, or not to UDP, that is the question," at .

[pic]Note:

The content of each blog and its URL are subject to change without notice.

Voice Support

If your deployment includes a Front End pool, you can deploy support for Enterprise Voice, the Voice over IP (VoIP) solution offered by Microsoft. Voice over IP (VoIP) is a software-based alternative to traditional PBX-based telephony. Though the VoIP call experience is similar to the traditional telephony experience, Enterprise Voice includes features that enable richer communication and collaboration. For example, your Enterprise Voice deployment can be configured to enable Microsoft Lync 2010 clients, including Microsoft Lync 2010 Phone Edition to allow users to view enhanced presence information or location information for contacts in your organization’s address book. Some Microsoft Lync Server 2010 features are enabled through integration with other Lync Server 2010 workloads and with Exchange Unified Messaging (UM). For details about the features and functionality available with Enterprise Voice and how to plan for deployment, see Planning for Enterprise Voice in the Planning documentation.

In This Section

• SIP Trunking Support

• Direct SIP Connections Support

• Exchange Unified Messaging (UM) Support

• E9-1-1 Support

SIP Trunking Support

If you plan to use Enterprise Voice with SIP trunking, you must deploy a Mediation Server and ensure that other infrastructure and components meet the support requirements appropriate to your deployment model. For details about determining whether to implement SIP trunking, see Why Use SIP Trunking? in the Planning documentation.

You can use the Microsoft Unified Communications Open Interoperability Program for enterprise telephony infrastructure to find qualified PSTN gateways, IP-PBXs, and SIP trunking services, including qualified IP telephony service providers. For details, see the Microsoft Unified Communications Open Interoperability Program website at .

Mediation Server Support

To implement SIP trunking, you must route the connection through a Mediation Server, which proxies communications sessions between Lync Server 2010 clients and the service provider. The Mediation Server decodes the media traffic from clients and servers and re-encodes it before sending it to the service provider. The re-encoding is needed because SIP trunks do not support some codecs used like Real Time Audio (RTA) or Interactive Connectivity Establishment (ICE) protocol negotiation for firewall traversal.

Each Mediation Server can have two network adapters, which provide an internal and an external network interface. The external interface is commonly called the gateway interface because traditionally it has been used to connect to a PSTN gateway or an IP-PBX. To implement a SIP trunk, you connect the external interface to a Session Border Controller (SBC) at a service provider.

Centralized vs. Distributed SIP Trunking

Centralized SIP trunking routes all VoIP traffic, including branch site traffic, through your data center. The centralized deployment model is simple, cost-effective, and generally the preferred approach for implementing SIP trunks with Lync Server 2010.

Depending on usage patterns within your enterprise, you may not want to route all users through the centralized SIP trunk. To analyze your needs, answer the following questions:

• How big is each site? How many users?

• Which Direct Inward Dialing (DID) numbers at each site get the most phone calls?

Distributed SIP trunking is a deployment model in which you implement a local SIP trunk at one or more branch sites. VoIP traffic is then routed from the branch site directly to their service provider, without going through your data center.

Distributed SIP trunking is required only in the following cases:

• The branch site requires survivable phone connectivity (for example, if the WAN goes down). If the branch does need redundancy and failover, the service provider will charge more and the configuration will take longer. This should be analyzed for each branch site. Some of your branches may require redundancy and failover, while others do not.

• The branch site and data center are in different countries/regions. For compatibility and legal reasons, you need at least one SIP trunk per country/region.

The decision about whether to deploy centralized or distributed SIP trunking requires a cost-benefit analysis. In some cases, it may be advantageous to opt for the distributed deployment model even if it is not required. In a completely centralized deployment, all branch site traffic is routed over WAN links. Instead of paying for the bandwidth required for WAN linking, you may want to use distributed SIP trunking.

[pic]Note:

For details about why and how you might use distributed SIP trunking, see Branch Site SIP Trunking in the Planning documentation.

Supported SIP Trunking Connection Types

Lync Server 2010 supports the following connection types for SIP trunking:

• Multiprotocol Label Switching (MPLS) is a private network that directs and carries data from one network node to the next. The bandwidth in an MPLS network is shared with other subscribers, and each data packet is assigned a label to distinguish one subscriber’s data from another’s. This connection type does not require VPN. A potential drawback is that excessive IP traffic can interfere with VoIP operation unless VoIP traffic is given priority.

• A private connection with no other traffic is typically the most reliable and secure connection type (for example, a leased fiber-optic connection or T1 line). This connection type provides the highest call-carrying capacity, but is typically the most expensive. VPN is not required. Private connections are appropriate for organizations with high call volumes or stringent security and availability requirements.

• The public Internet is the least expensive connection type, but also the least reliable, and the one with the lowest call-carrying capacity. Your Internet Telephony Service Provider (ITSP) can help secure this SIP trunk connection type if it supports TLS and Secure Real-Time Transport Protocol (SRTP) to encrypt signaling and media traffic. If you cannot configure a SIP trunk connection through the Internet to use TLS and SRTP, we strongly recommend that you use a VPN tunnel to provide a more secure connection. Contact your ITSP to determine whether it provides support for TLS with SRTP.

Selecting a Connection Type

The most appropriate SIP trunking connection type for your enterprise depends on your needs and your budget.

• For mid-size or larger enterprise, generally an MPLS network provides the most value. It can provide the necessary bandwidth at a cheaper rate than a specialized private network.

• Large enterprises may require a private fiber-optic or T1 connection.

• For a small enterprise or branch site with low call volume, SIP trunking through the Internet may be the best choice, however this connection type is not recommended for mid-size or larger sites.

Codec Support

The service provider proxy must support the following codecs:

• G.711 a-law (used primarily outside North America)

• G.711 µ-law (used in North America)

Direct SIP Connections Support

Microsoft Lync Server 2010 supports the use direct SIP connections to connect Lync Server 2010 to either of the following:

• An IP-PBX

• A PSTN gateway

The Mediation Servers in a Lync Server 2010 pool can control multiple gateways, Session Border Controllers (SBCs) provided by telephony service providers, or some combination thereof. Additionally, multiple Mediation Servers in the pool can interact with a single gateway.

You can use the Microsoft Unified Communications Open Interoperability Program for enterprise telephony infrastructure to find qualified PSTN gateways, IP-PBXs, and SIP trunking services. For details, see the Microsoft Unified Communications Open Interoperability Program website at .

For details about the topology and deployment options for direct SIP connections, see Direct SIP Connections in the Planning documentation.

Exchange Unified Messaging (UM) Support

Microsoft Lync Server 2010 supports integration with Exchange Unified Messaging (UM) for combining voice messaging and email messaging into a single messaging infrastructure. Exchange UM is one of several server roles that you can install and configure on a computer that is running Microsoft Exchange Server. For Lync Server Enterprise Voice deployments, Exchange UM combines voice messaging and email messaging into a single store that is accessible from a telephone (that is, Outlook Voice Access) or a computer. Exchange UM and Lync Server work together to provide call answering, Outlook Voice Access, and auto attendant services to users of Enterprise Voice.

In addition to the support that previous Lync Server releases have provided for integration with on-premises deployments of Exchange UM, Lync Server 2010 introduces support for integration with hosted Exchange UM. This enables you to provide voice messaging to your users if you migrate some or all of them to a hosted Exchange service provider such as Microsoft Exchange Online.

Lync Server 2010 supports the following versions:

• Microsoft Exchange Server 2010 (required) or with latest service pack (recommended)

• Microsoft Exchange Server 2007 with Service Pack 1 (SP1) (required) or latest service pack (recommended)

You cannot collocate Exchange UM with Lync Server or a Lync Server database. You can install Exchange UM and Lync Server in separate forests.

[pic]Note:

Exchange UM may not be required for Enterprise Voice deployments that have a PBX deployed, because the PBX can continue to provide voice mail and related services to all users. If you eventually retire the PBX, (for example, if you deploy SIP trunking for public switched telephone network (PSTN) connectivity) you must reconfigure Exchange UM to provide voice mail to users who previously used the PBX voice mail system.

In This Section

• Components and Topologies for On-Premises Unified Messaging

• Support for Hosted Exchange UM Integration

Components and Topologies for On-Premises Unified Messaging

This topic describes the Microsoft Exchange Server components required to provide Exchange Unified Messaging (UM) features to Microsoft Lync Server 2010 communications software Enterprise Voice users whose mailboxes are homed on an on-premises Microsoft Exchange deployment. It also describes the supported topologies for on-premises Exchange UM integration.

Exchange Server Components

To provide the Exchange UM features and services described earlier in this section to Enterprise Voice users in your organization, you must deploy the following Microsoft Exchange server roles:

• Mailbox Server, which hosts user mailboxes and provides a single storage location for email and voice mail.

• Hub Transport Server, which routes email messages from the Exchange UM Server to user mailboxes.

• Client Access Server, which hosts client protocols and services, such as Post Office Protocol version 3 (POP3), Internet Message Access Protocol 4 (IMAP4), Secure Hypertext Transfer Protocol (HTTPS), Outlook Anywhere, Availability service, and Autodiscover service. The Client Access Server also hosts Web services.

• Exchange UM Server, which connects Microsoft Exchange Server with Lync Server 2010.

Supported Topologies

You can deploy Lync Server and Exchange UM in the same forest or multiple forests. If the deployment spans multiple forests, you must perform the Exchange integration steps for each Exchange UM forest. Furthermore, you must configure each Microsoft Exchange forest to trust the Lync Server forest and the Lync Server forest to trust each Exchange UM forest. In addition to this forest trust, the Exchange UM settings for all users must be set on the user objects in the Lync Server forest.

Lync Server supports the following topologies for Exchange UM integration:

• Single forest

• Single domain (that is, a single forest with a single domain). Lync Server, Microsoft Exchange, and users all reside in the same domain.

• Multiple domain (that is, a root domain with one or more child domains). Lync Server, and Microsoft Exchange servers are deployed in different domains from the domain where you create users. Exchange UM servers can be deployed in different domains from the Lync Server pool they support.

• Multiple forest (that is, resource forest). Lync Server is deployed in a single forest, and then users are distributed across multiple forests. The users’ Exchange UM attributes must be replicated over to the Lync Server forest.

[pic]Note:

Exchange can be deployed in multiple forests. Each Exchange organization can provide Exchange UM to its users, or the Exchange UM servers can be deployed in the same forest as Lync Server.

Support for Hosted Exchange UM Integration

The Lync Server 2010 ExUM Routing application supports integration with Exchange Unified Messaging (UM) in an on-premises environment, where Lync Server 2010 and Exchange UM are both installed locally within your enterprise, or in with Exchange UM hosted by a service provider, as shown in the following diagram.

[pic]

The following modes are supported:

• On-premises Mode   Lync Server and Exchange UM are both deployed on local servers within your enterprise.

• Cross-premises Mode   Lync Server is deployed on local servers within your enterprise and Exchange UM is hosted in an online service provider’s facility, such as a Microsoft Exchange Online data center.

• Mixed Mode   Your Lync Server deployment has some user mailboxes homed on local servers running Microsoft Exchange Server within your enterprise and some mailboxes homed in a hosted Exchange service data center.

[pic]Note:

Mixed mode can be used as a transitional solution during evaluation and stepwise migration of users to hosted Exchange UM, or a permanent solution if you opt to keep some users’ Exchange UM services on-premises after migrating others.

To integrate Lync Server with hosted Exchange UM, you must configure a shared SIP address space (also called a split domain). In this configuration, both Lync Server and the third-party hosted Exchange UM service provider can access the same SIP domain address space. For details, see Hosted Exchange UM Integration Architecture in the Planning documentation.

E9-1-1 Support

Microsoft Lync Server 2010 communications software supports Enhanced 9-1-1 (E9-1-1) as part of an enterprise deployment. E9-1-1 is an emergency notification feature that associates the calling party’s telephone number with a civic or street address. E9-1-1 support is only available in the United States.

In order to support E9-1-1 as part of a Lync Server deployment, you must obtain E9-1-1 routing service from a certified emergency services provider. The emergency services provider routes emergency calls originating from Lync Server to the correct Public Safety Answering Point (PSAP) based on the location information contained within the call. For details about E9-1-1 support, see Emergency Services (E9-1-1) in the Planning documentation.

Virtualization Support

Microsoft Lync Server 2010 supports virtualization topologies that support all major workloads, including instant messaging (IM) and presence, conferencing, and Enterprise Voice. Virtualization is supported only on the Windows Server 2008 R2 operating system for all host and guest operating systems. The supported topologies are as follows:

• Standard Edition server topology, supporting up to 2,000 users per Standard Edition server, for proof-of-concept, pilot projects, and branch sites.

• Enterprise Edition data center topology, supporting up to 5,000 users per Front End Server.

Lync Server 2010 supports virtualization of the following:

• Front End Servers. If you virtualize a Front End Server, you can also virtualize some or all of the other server roles of that site.

• Standard Edition servers. When deploying a virtualized Standard Edition server, the only server roles that can be deployed with it are the Director, Monitoring Server, Archiving Server, and Edge Server.

• Edge Servers for Front End pools and Standard Edition servers.

Support includes both of the following:

• Microsoft Hyper-V technology

• VMWare

For details about virtualization support and requirements, including the number of virtual machines to be deployed, see Running in a Virtualized Environment in the Planning documentation.

Additional Server Support and Requirements

In addition to the software support described in the other sections of this Supportability documentation, Microsoft Lync Server 2010 has the following support limitations:

• Lync Server 2010 supports Domain Name System (DNS) and hardware load balancing for specific server roles. It also supports application load balancing for Mediation Servers, where appropriate. For details about when to use each, see the Planning documentation.

• Lync Server 2010 uses the Distribution List Expansion Protocol (DLX) to expand distribution lists. This protocol also specifies the web service method that is used to get the membership of a distribution list. Microsoft Exchange Server supports dynamic groups that do not have members statically assigned to them. Instead, they store queries that are evaluated when the group is expanded. DLX does not support dynamic distribution lists.

• The Enable User Wizard does not support automatic conversion of non-English characters to a SIP-compliant URI, so you must modify the SIP address manually.

• For servers running antivirus software, include all servers running Lync Server 2010 in the exception list in order to provide optimal performance and audio quality. For details, see Specifying Antivirus Scanning Exclusions in the Security documentation.

• If you use IPsec, we recommend disabling IPsec over the port ranges used for audio and video traffic. For details, see IPsec Exceptions in the Planning documentation.

• If your organization uses a Quality of Service (QoS) infrastructure, the media subsystem is designed to work within this existing infrastructure. For details about implementing QoS, see Enabling Quality of Service (QoS) in the Operations documentation.

• Use of the operating system firewall is supported. Lync Server 2010 manages the firewall exceptions for the operating system firewall, except for Microsoft SQL Server database software. For details about SQL Server firewall requirements, see the SQL Server documentation.

• The external interfaces used to implement support for external user access must be on a separate subnet, not on the same network as the internal interfaces.

• Lync Server 2010 does not support two-factor authentication. However, if you deploy Lync Server in a network environment that already provides two-factor authentication (for example, a VPN with two-factor authentication), Lync Server works in that environment.

• Lync Server 2010 and Microsoft Exchange Server 2010 Service Pack 1 (SP1) operate with support for Federal Information Processing Standard (FIPS) 140-2 algorithms if the Windows Server 2008 Service Pack 2 (SP2) Windows Server 2008 R2 operating systems are configured to use the FIPS 140-2 algorithms for system cryptography. To implement FIPS support, you must configure each server running Lync Server 2010 to support it. For details about FIPS-compliant algorithms and how to implement FIPS support, see Microsoft Knowledge Base article 811833, “The effects of enabling the “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting in Windows XP and in later versions of Windows,” at . For details about FIPS 140-2 support and limitations in Exchange 2010, see “Exchange 2010 SP1 and Support for FIPS Compliant Algorithms” at .

Lync Server 2010 requires the installation of other software on specific components prior to or during deployment. This includes software that is available with the operating system, downloadable software, and software that is automatically installed during installation of Lync Server 2010. Following is a list of additional software that can be required:

• Windows Update

• Message Queuing Server and Message Queuing Directory Service Integration

• Microsoft .NET 3.5 with Service Pack 1 (SP1) Framework

• Microsoft Visual C++ 2008 Redistributable

• Microsoft Visual J# version 2.0 Redistributable

• URL Rewrite Module version 2.0 Redistributable

• Windows Media Format Runtime

• Windows PowerShell version 2.0

• Windows Installer version 4.5

• Microsoft Silverlight 4 browser plug-in (Silverlight 4.0.50524.0 or the latest version for Lync Server Control Panel)

• Active Directory Domain Services (AD DS) tools

• SQL Server

Some of these software requirements only apply to specific server roles or components. For details about these software requirements, see Additional Software Requirements in the Planning documentation.

Client and Device Software and Infrastructure Support

Software support for Microsoft Lync Server 2010 clients and devices includes the supported operating systems, infrastructure software, and other additional software required to support client and device features.

In This Section

• Client Software Support

• Required Lync Server 2010 Components for Devices

• Device System and Infrastructure Support

Client Software Support

This section summarizes the software support for Microsoft Lync Server 2010 clients.

Windows Operating Systems

The following clients support the same Windows operating systems:

• Microsoft Lync 2010

• Online Meeting Add-in for Microsoft Lync 2010

• Microsoft Lync 2010 Attendee

• Microsoft Lync 2010 Attendant

Supported operating systems for these clients include the following:

• Windows 7 operating systems

• Windows Vista operating systems

• Windows XP operating system with Service Pack 3 (SP3)

[pic]Note:

Windows Installer 3.1 must be installed before deploying Lync 2010.

Installation of the client and updates requires administrator rights and permissions.

Lync supports communications between Lync and previous client versions. For details, see Lync 2010 Compatibility in the Planning documentation.

Macintosh Operating Systems

The following clients support the Macintosh operating system:

• Microsoft Lync for Mac 2011

• Microsoft Communicator for Mac 2011

Supported operating systems for these clients include the following:

• Mac OS 10.5.8 or the latest service pack or release (Intel-based)

Browsers

Lync supports the following browsers:

• Windows Internet Explorer 9 Internet browser

• Windows Internet Explorer 8 Internet browser

• Windows Internet Explorer 7 Internet browser

• Windows Internet Explorer 6 Internet browser

• Mozilla Firefox web browser

[pic]Note:

If you are using Lync with Microsoft Exchange Online and your organization has deployed an authenticating HTTP proxy, Internet Explorer 9 or Internet Explorer 8 is required.

Microsoft Lync Web App supports specific combinations of operating systems and browsers. For details, see Lync Web App Supported Platforms in the Planning documentation.

Microsoft Silverlight

The Microsoft Silverlight browser plug-in version 4.0 is required for Lync and the Online Meeting Add-in for Lync 2010. It is installed automatically during Lync setup.

Silverlight 4.0 is also required for Lync Web App. You can deploy Silverlight 4.0 to client computers or allow users to be prompted for installation when they first start Lync Web App.

Microsoft .NET Framework 3.5

To install Lync 2010 Attendant, the Microsoft .NET Framework 3.5 must already be installed. For details about installing the Microsoft .NET Framework 3.5, see .

Microsoft Office

Lync Server 2010 clients support integration with various versions of Microsoft Office. This section summarizes Microsoft Office supportability. For details, see Lync 2010 Compatibility in the Planning documentation.

• The Microsoft Outlook 2010 messaging and collaboration client and Microsoft Exchange Server 2010 are required for the full set of new Outlook integration features in Lync.

• Certain Lync integration features are supported on Microsoft Office 2007 suites and Microsoft Office 2003 Service Pack 3 (SP3). For integration with Microsoft Office 2007 to work correctly, you may have to install an update to Microsoft Outlook 2007. For details about the Outlook update, see Microsoft Knowledge Base article 936864, "Description of the 2007 Office hotfix package" at .

• The Online Meeting Add-in for Lync 2010 is supported with Microsoft Office 2010 suites, Office 2007, and the Microsoft Office 2003 suites.

Using Mandatory Profiles

If users are planning to use Lync 2010 conferencing features, they should not use Windows Active Directory Domain Services mandatory profiles to sign in to the Lync 2010 client. Because mandatory profiles are read-only user profiles, the Public Key Infrastructure (PKI) keys that are required for Lync 2010 conferencing cannot be saved to the profile. For details, see Microsoft Knowledge Base article 2552221, “Lync 2010 conferencing feature fails when the user is signed in using a mandatory user profile,” at .

Required Lync Server 2010 Components for Devices

Before you deploy unified communications (UC) phones, ensure that the following required Microsoft Lync Server 2010 components are in place.

Web Services

The Device Update Web service, which is an automated way to update your IP phones, is installed with Web Services, on the Front End Server.

[pic]Important:

In Lync Server 2010 Enterprise Edition, you may have multiple servers in the pool. For each instance of Web Services running on servers in a pool, there is a separate instance of Device Update Web service running in the pool. When you make a configuration change to the Device Update Web service, the changes are propagated to all the servers in that pool but not to servers in any other pool. For details about required configurations, see System and Infrastructure Requirements for Devices in the Planning documentation.

Enterprise Voice

Enterprise Voice is the voice over IP (VoIP) solution in Lync Server 2010 that allows users to make calls and use rich communication and collaboration features, such as viewing enhanced presence information or location information for contacts in your organization’s address book.

Enterprise Voice must be enabled for each device user. To check whether Enterprise Voice is enabled for a user, in Microsoft Lync Server 2010 Control Panel find the user, then view the user’s details. If the user is enabled for Enterprise Voice, the check box Enabled for Lync Server will be selected, and the Telephony drop down will have Enterprise Voice selected.

Contact Objects

(Applies to Common area phones) Phones that are not associated with a specific user must be associated with an Active Directory contact object. Like user accounts, contact objects can be assigned policies and voice plans, thereby giving you a way to manage the device.

For details about creating contact objects for common area phones, see Configuring Common Area Phones in the Deployment documentation.

Dial Plans, Voice Polices, and Outbound Call Routes

Dial plans, voice polices, and call routes must be set up for users. Dial plans are named sets of normalization rules that translate phone numbers for a named location, individual user, or contact object into a single standard (E.164) format, allowing UC device users to make calls to the public switched telephone network (PSTN). Voice policies are records that define call permissions for users, sites, or an entire organization and include various calling features that may be enabled or disabled as appropriate. Voice policies must be set up for device users. Call routes are rules that specify how Lync Server 2010 handles outbound calls from UC devices.

To verify whether dial plans, voice polices, and call routes are set up for users, or to set up or modify these user polices, see Planning Outbound Call Routing in the Planning documentation. For details about configuring policies for common area phones, see Configuring Common Area Phones in the Deployment documentation.

[pic]Important:

We recommend that you also configure Exchange Unified Messaging (UM) and Lync Server 2010 to work together and that you enable users for Exchange UM call answering and Outlook Voice Access. For details, see the Exchange Server 2010 TechNet Library at .

PIN Authentication and Policy

If you’re deploying phones from the new line of IP phones, you must enable personal identification number (PIN) authentication on Lync Server, and an appropriate PIN policy need to be in place. This allows authentication to be automatic when a user signs in on an Aastra 6721ip common area phone, Aastra 6725ip desk phone, HP 4110 IP Phone (common area phone), HP 4120 IP Phone (desk phone), Polycom CX500 IP common area phone, Polycom CX600 IP desk phone, or Polycom CX3000 IP conference phone. You set the PIN policy on the PIN Policy page of the Security group in Lync Server 2010 Control Panel. Also in Security, click Web Service, and verify that PIN authentication is enabled in the Global policy.

To do this is the Lync Server Management Shell, run the following command:

Set-CsWebServiceConfiguration -Identity "WebService:" –UsePinAuth $true

Device System and Infrastructure Support

This section describes the hardware, port, Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and security configurations that must be in place before you deploy IP phones. These requirements are in addition to the required components described in Required Lync Server 2010 Components for Devices in the Planning documentation.

[pic]Note:

Review the manufacturer’s data sheet for the devices that you are deploying to learn about additional requirements.

Hardware Requirements

IP phones running Microsoft Lync 2010 Phone Edition support Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED) and Power over Ethernet (PoE). To take advantage of LLDP-MED, the switch must support IEEE802.1AB and ANSI/TIA-1057. To take advantage of PoE, the switch must support PoE802.3AF or 802.3at.

To enable LLDP-MED, the administrator must enable LLDP by using the switch console window and set the LLDP-MED network policy with the correct voice VLAN ID.

[pic]Important:

You can configure the switch for Enhanced 9-1-1 (E9-1-1), if the switch supports this.

Port Requirements

IP phones use port 443 for the Device Update Web service.

DNS Requirements

IP phones require certain DNS records. The following table describes the records that you must create and publish to a DNS service, within the corporate network, if you are deploying IP phones. The following table provides details about the DNS records that are required for external IP phones.

DNS Records for External Devices

|Type |Value |Note |

|A |Fully qualified domain names (FQDNs) for the |The new Microsoft Lync Server 2010 DNS load balancing |

| |pool(s) hosting the Registrars |feature requires you to specify the server FQDN and the |

| | |pool FQDN, using the same IP address, for each server in|

| | |the pool and to create A records for all pools that |

| | |contain a Registrar. |

| | |For example: RegistrarServerOneInPool.: |

| | |1.2.3.4, RegistrarPool.: 1.2.3.4, |

| | |RegistrarServerTwoInPool.: 1.2.3.5, and |

| | |RegistrarPool.: 1.2. 3.5. |

| | |If you are using hardware load balancing, just specify A|

| | |records for each pool that contains a Registrar. Allows |

| | |external devices to connect by using SIP over TLS to the|

| | |Registrar internally. |

|SRV |_sipinternal._tcp. |Specifies the two SIP FQDNs for internal routing, one |

| |_sipinternaltls._tcp. |for communications over TCP, and one for TCP |

| | |communications that use TLS. |

|A |ucupdates-r2. |Specifies the Web Services portion of the Device Update |

| | |Web service URL. The device appends |

| | |“:443/RequestHandler/ucdevice.upx”. Make sure the |

| | |hardware load balancer translates external requests to |

| | |use “:443/RequestHandler/ucdevice.upx.” The external |

| | |port is 443. |

[pic]Note:

If the pool is already deployed, you can get this information from Lync Server Control Panel on the Topology page by viewing the Edge Server properties.

DHCP Requirements

IP phones require the Web Services URL and Registrar FQDN from the DHCP server, for connectivity. To make sure that the DHCP server can provide IP phones with the appropriate information, refer to the guidelines described in System and Infrastructure Requirements for Devices in the Planning documentation.

Security Requirements

If you are allowing external access for IP phones, a public key infrastructure (PKI) infrastructure must be in place, and devices must have a valid Lync Server 2010 certificate, which they obtain when they log on and is issued from a public certification authority (CA) (recommended) or a private CA. This allows the devices to connect to the Device Update Web service from outside the intranet. For details, see Certificate Infrastructure Requirements in the Planning documentation.

Edge Server Requirements

If you’re allowing external access for IP phones, deploy Edge Servers by following the instructions in Deploying Edge Servers in the Deployment documentation. However, during the setup process described in Set Up Network Interfaces for Edge Servers in the Deployment documentation, use the following configuration information to enable external access to the Device Update Web service:

• In the Configure a Reverse Proxy step, configure the reverse HTTP proxy to use the Device Update Web service virtual directory for the external URL for Web Services and the Device Update Web service.

• In the Configure DNS step, use the information in the following table.

DNS Records for External Devices

|Type |Value |Note |

|SRV |Edge Server:_sipexternal._tls., and |Allows external devices to connect by |

| |_sipexternaltls. |using SIP over TLS to the Registrar |

| | |internally. |

|A |Reverse proxy FQDN:. |Allows external devices to connect by |

| | |using TLS over HTTP to the Device |

| | |Update Web service. |

[pic]Note:

If the Edge Server is already deployed, you can get this information from Lync Server Control Panel on the Topology page by viewing the Edge Server properties.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download