Topic Last Modified: 2011-03-23

Each server running Microsoft Lync Server 2010 runs one or more server roles. A server role is a defined set of Lync Server 2010 functionality provided by that server. You do not need to deploy all available server roles in your network. Install only the server roles that contain the functionality that you want.

Even if you are not familiar with server roles in Lync Server, the Microsoft Lync Server 2010, Planning Tool can guide you to the best solution for the servers you need to deploy, based on the features that you want. This section provides a brief overview of the server roles and the general features they provide:

For most server roles, for scalability and high availability you can deploy pools of multiple servers all running the same server role. Each server in a pool must run an identical server role or roles. For some types of pools in Lync Server, you must deploy a load balancer to spread traffic between the various servers in the pool.

Standard Edition Server

The Standard Edition server is designed for small organizations, and for pilot projects of large organizations. It enables many of the features of Lync Server 2010, including the necessary databases, to run on a single server. This enables you to have Lync Server functionality for a lesser cost, but does not provide a true high-availability solution.

Standard Edition server enables you to use instant messaging (IM), presence, conferencing, and Enterprise Voice, all running on one server. One Standard Edition server supports as many as 5,000 users.

For a high-availability solution, use Lync Server 2010 Enterprise Edition.

Front End Server and Back End Server

The Front End Server is the core server role, and runs many basic Lync Server functions. The Front End Server, along with the Back End Servers that provide the database, are the only server roles required to be in any Lync Server Enterprise Edition deployment.

A Front End pool is a set of Front End Servers, configured identically, that work together to provide services for a common group of users. A pool provides scalability and failover capability your users.

Front End Server includes the following functionality:

  • User authentication and registration

  • Presence information and contact card exchange

  • Address book services and distribution list expansion

  • IM functionality, including multiparty IM conferences

  • Web conferencing and application sharing (if deployed)

  • Application hosting services, for both applications included with Lync Server (for example, Conferencing Attendant and Response Group application) and third-party applications

Additionally, one Front End pool in the deployment also runs the Central Management Server, which manages and deploys basic configuration data to all servers running Lync Server 2010. The Central Management Server also provides Lync Server Management Shell and file transfer capabilities.

The Back End Servers are database servers running Microsoft SQL Server that provide the database services for the Front End pool. You can have a single Back End Server, but a cluster of two or more servers is recommended for failover. Back End Servers do not run any Lync Server software. If you already have a SQL Server cluster that you are using for other applications, you can also use this cluster for Lync Server 2010, if performance allows.

Information stored in the Back End Server databases includes presence information, users' Contacts lists, conferencing data including persistent data about the state of all current conferences, and conference scheduling data.

Front End Server Scalability

In a Front End pool, you should have one Front End Server for every 10,000 users homed in the pool, plus an additional Front End Server to provide good performance when one server is unavailable. The maximum number of users in one Front End pool is 80,000. If you have more than 80,000 users at a site, you can deploy more than one Front End pool.

The additional Front End Server ensures good performance in case one server is unavailable. When an active server is unavailable, its connections are transferred automatically to the other servers in the pool. For example, if you have 30,000 users and three Front End Servers, then when one server is unavailable, the connections of 10,000 users need to be transferred to the other two servers, for an average of 5,000 per server. If you start with four Front End Servers for your 30,000 users, then when one is unavailable a total of 7,500 users will be moved to three other servers, for an average of 2,500 per server. This is a much more manageable load.

A/V Conferencing Server

A/V Conferencing Server provides A/V conferencing functionality to your deployment. It can be collocated with Front End Server, or deployed separately as a single server or A/V Conferencing Server pool.

For details, see Web Conferencing and A/V Conferencing in the Planning documentation.

A/V Conferencing Server Scalability

If you deploy A/V Conferencing Server separately, you need one A/V Conferencing Server for each 20,000 users at a site. At a minimum we recommend two A/V Conferencing Servers for high availability.

Edge Server

Edge Server enables your users to communicate and collaborate with users outside the organization’s firewalls. These external users can include the organization’s own users who are currently working offsite, users from federated partner organizations, and outside users who have been invited to join conferences hosted on your Lync Server deployment. Edge Server also enables connectivity to public IM connectivity services, including Windows Live, AOL, and Yahoo!.

For details, see Planning for External User Access in the Planning documentation.

Edge Server Scalability

For performance, you should deploy one Edge Server for every 15,000 users you expect to access a site remotely. At a minimum we recommend two Edge Servers for high availability.

Mediation Server

Mediation Server is a necessary component for implementing Enterprise Voice and dial-in conferencing. Mediation Server translates signaling and, in some configurations, media between your internal Lync Server infrastructure and a public switched telephone network (PSTN) gateway, IP-PBX, or a Session Initiation Protocol (SIP) trunk.

For details, see Mediation Server Component in the Planning documentation.

Mediation Server Scalability

For details about Mediation Server scalability, see Estimating Voice Usage and Traffic in the Planning documentation.

Monitoring Server

Monitoring Server collects data about the quality of your network media, in both Enterprise Voice calls and A/V conferences. This information can help you provide the best possible media experience for your users. It also collects call error records (CERs), which you can use to troubleshoot failed calls. Additionally, it collects usage information in the form of call detail records (CDRs) about various Lync Server features so that you can calculate return on investment of your deployment, and plan the future growth of your deployment.

For details, see Planning for Monitoring in the Planning documentation.

Monitoring Server Scalability

One Monitoring Server can support up to 250,000 users if not collocated with Archiving Server. If collocated, it can support up to 100,000 users.

Archiving Server

Archiving Server enables you to archive IM communications and meeting content for compliance reasons. If you do not have legal compliance concerns, you do not need to deploy Archiving Server.

For details, see Planning for Archiving in the Planning documentation.

Archiving Server Scalability

One Archiving Server can support up to 500,000 users if not collocated with Monitoring Server. If collocated, it can support up to 100,000 users.


Directors can authenticate Lync Server user requests, but do not home user accounts, or provide presence or conferencing services. Directors are most useful in deployments that enable external user access, where the Director can authenticate requests before sending them on to internal servers. Directors can also improve performance in organizations with multiple Front End pools. For details, see Director in the Planning documentation.

Director Scalability

For performance, you should deploy one Director for every 15,000 users who will access a site remotely. At a minimum we recommend two Directors for high availability.