Microsoft · Web viewThe Web Conferencing service is responsible for multiplexing the Web...

This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. Copyright © 2010 Microsoft Corporation. All rights reserved.Microsoft, Active Directory, Lync, Silverlight, SQL Server, and Windows are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

Microsoft Lync Server 2010 Resource Kit Technical Overview Page 2

This chapter is part of the Microsoft Lync Server 2010 Resource Kit book that is currently being developed. Chapters will be available for download while this book is being completed. To help us improve it, we need your feedback. You can contact us at [email protected]. Please include the chapter name.

For information about the continuing release of chapters, check the DrRez blog, http://go.microsoft.com/fwlink/?LinkId=204593.


Table of ContentsIntroduction.................................................................................................................................................5

Standard Edition Server...............................................................................................................................7

Enterprise Edition........................................................................................................................................7

Central Management Server.....................................................................................................................11

Director.....................................................................................................................................................12

Notes from the Field..................................................................................................................................13

Using a Pool of Directors to Boost Reliability............................................................................................13

Survivable Branch Appliance or Server......................................................................................................15

Mediation Server.......................................................................................................................................16

Monitoring Server.....................................................................................................................................17

Archiving Server.........................................................................................................................................17

Edge Servers..............................................................................................................................................18

Group Chat Server.....................................................................................................................................19

Summary...................................................................................................................................................20

Additional Resources.................................................................................................................................20


IntroductionMicrosoft® Lync™ Server 2010 communications software is a major upgrade from Microsoft Office Communications Server 2007 R2. Lync Server 2010, similar to Microsoft Exchange Server, is an enterprise software server solution that provides four different workloads in an integrated and unified user experience. These workloads are IM and presence, applications sharing, audio/video and Web conferencing, and Enterprise Voice. Voice over IP (VoIP) is part of Enterprise Voice, but Enterprise Voice also includes voice specific server applications. Each workload uses different protocols and performs different functions. Figure 3-1 illustrates the servers, protocols, and ports that are used broken down by each workload. To view this figure in more detail, see http://go.microsoft.com/fwlink/?LinkId=204599.

Figure 3-1. Lync Server 2010 workloads

Lync Server 2010 uses network subset information to enable three new important scenarios. By making network subnets by using geographic locations (a process the administrator must perform), Lync Server 2010 is able to leverage this geographic information to enable Enhanced 9-1-1 (E9-1-1) and call admission control (CAC). This information also gives users the option to have Lync 2010 publish their location. E9-1-1, when integrated with a supported Public Safety Answering Point (PSAP) enables organizations in the United States to automatically provide the location of the distressed caller. With CAC, administrators can guarantee Quality of Service (QoS) for audio and video calls routed across WAN links that have limited bandwidth.


In addition, Lync Server 2010 and Lync 2010 offer an extensive platform for the server as well as the client. Microsoft Unified Communications Managed API (UCMA) 3.0 is a scalable rich API that independent software vendors (ISVs) can use to build server-side applications such as interactive voice response (IVR) applications and call centers. UCMA provides programmatic access to all the media types: presence, IM, audio/video conferencing, and Enterprise Voice.

On the client side, the Lync 2010 Managed API offers the power of the previous Microsoft Unified Communications Client API (UCC API) without the complexity. Building on the Lync 2010 Managed API is the Lync 2010 Automation API, which simplifies common tasks such as starting a conversation, joining a conference, and adding a contact. The Automation API automates Lync 2010 and exposes the Lync 2010 UI. In addition to the Automation API, Microsoft provides Microsoft Silverlight® controls to embed Lync 2010 functionality into the browser. Figure 3-2 illustrates how these APIs and controls are layered.

Figure 3-2. Lync 2010 client API framework

To simplify deployment, Lync Server 2010 has reduced the number of server roles from Office Communications Server 2007 R2. This reduction of server roles was made possible by consolidating services that are automatically installed together. This helps reduce the level of complexity and expertise required to successfully deploy Lync Server 2010 by simplifying the installation process. These server roles perform specific tasks that enable various usage scenarios. This chapter focuses on explaining the different services and server roles so that you can decide when to use them to fit your particular deployment needs.


Standard Edition ServerLync Server 2010 Standard Edition is designed for use in small and medium-sized organizations or organizations that do not require the performance and high availability offered by the Enterprise Edition. A Standard Edition server includes all the functionality to provide presence, instant messaging (IM), conferencing, and Enterprise Voice. The Standard Edition server is both a Session Initiation Protocol (SIP) registrar and a SIP proxy, as defined in Request for Comment (RFC) 3261, in a single physical server. When installing a Standard Edition server, the Microsoft SQL Server 2008 Express database software is automatically installed. This database stores data for all users who are enabled for SIP communications. These users are homed on the Standard Edition server.The data that is stored for each user includes the following:

Contact information (contact lists) Permissions (allowed lists or blocked lists) Endpoints (devices on which the user is currently registered) Subscription information (pending subscriptions) Lync Server specific user settings that are published in Active Directory® Domain

ServicesContact information refers to the list of contacts and groups created by the user.Permissions refer to whether contacts are allowed or blocked from viewing the presence state of users. Lync Server 2010 uses an extensible permission model referred to as enhanced presence. Endpoints refer to each of the devices from which the same user is signed in to Lync Server. Users can be signed in from multiple devices at the same time. The server tracks each of these endpoints to determine the most accurate presence state of the user. When an incoming invitation is sent to the user, Lync Server forks the invitation by sending the invitation to all the user’s endpoints. When the user responds from one of their devices, the server stops forking the incoming messages from that contact, and then it routes all subsequent messages for this session to the device from which the user accepted the original invite. After the session is terminated, any new messages from the same contact or any other contact are again forked to all endpoints to which the user is signed in. Because a Standard Edition server maintains user information, it is important to back up the database periodically so that, in the event of a server failure, this data can be restored. Because of its scaling characteristics and ease of deployment as a standalone server, the Standard Edition server is appropriate for organizations with fewer than 5,000 users or for pilot deployments where the main goals are simplicity and ease of management and where high availability is not a requirement.

Enterprise EditionEnterprise Edition improves the scalability and availability of Lync Server 2010 deployments by separating the logical operations that a Standard Edition server performs into individual physical or virtual servers. An Enterprise Edition deployment is referred to as a Front End pool because it involves multiple physical servers. A Front End pool separates the Back End Server that is running SQL Server from the services (SIP Registrar, SIP proxy, conferencing server, and server applications) that are running on the Front End servers. The Front End Servers maintain transient information—such as logged-on state and control information for an IM, Web, or audio/video (A/V) conference—only for the duration of a user’s session. This configuration is an advantage because in the event of a Front End Server failure, the clients


connected to that server can quickly reconnect to another Front End Server that belongs to the same Front End pool. In Lync Server 2010, load balancing SIP traffic by using a hardware load balancer is optional. Lync Server 2010 supports DNS load balancing. With DNS load balancing, Lync 2010 clients have built in logic to retry connecting to a different Front End Server that is part of the Front End pool returned by the DNS query. A hardware load balancer is still required to load balance Web traffic (HTTPS) from the Front End pool. However, the complexity of configuring hardware load balancer for Web traffic is more familiar to most large organizations that already use hardware load balancing for their Web servers.To implement SQL Server high availability in an Enterprise Edition deployment, multiple Back End servers can be clustered by using failover clustering, which is a feature of Windows Server® 2008 operating system and Windows Server 2008 R2 operating system. Microsoft supports only active-passive SQL Server clustering for Enterprise Edition deployments. Active-passive SQL Server clustering means only one SQL Server node is actively responding to SQL queries and commands from the Front End Servers while the other SQL Server node passively synchronizes its database with the changes from the active node’s database. The passive SQL Server node does not respond to SQL queries and commands from the Front End Servers until a failover occurs. When the active node becomes unresponsive due to a failure, the passive node takes over. The passive node must be an exact replica of the active node in the system configuration. The server that is running SQL Server can be shared with other applications as long as the Front End pool database is running on a separate SQL Server instance. Lync Server 2010 supports running the back-end SQL Server database on a 64-bit server. All servers that belong to a Front End pool must be joined to the same Active Directory domain. For example, Microsoft does not support a scenario in which half the Front End Servers are deployed in domain A and half in domain B, while the Back End servers are deployed in domain C. All servers in a Front End pool should be deployed within geographic proximity and have at least 1-gigabit connectivity between Front End Servers and Back End Servers.When you install a Front End pool, the following services are automatically installed as described in Table 3-1. The service that runs the Front End Server is the executable program, rtcsrv.exe. The Lync Server Replica Replicator Agent (ReplicaReplicatorAgent.exe) synchronizes configuration settings from the Central Management Server. The executable program, OcsAppServerHost.exe, hosts server applications that run as part of the Front End Server. The server applications installed as part of Lync Server 2010 are the following Lync services:

Bandwidth Policy Service: This service enforces CAC for audio and video traffic across network links that have limited bandwidth. For details, see Chapter 6 “Enterprise Voice.”Call Park service: This service enables users to put a call on hold from one phone and retrieve the call from a different phone by using an orbit number. For details, see Chapter 6.Conferencing Announcement service: This service provides announcement functionality so that a tone or message plays when a user joins or leaves a conference. For details, see Chapter 6.Response Group service: This service emulates the hunt group functionality in traditional private branch exchange (PBX) phone systems by queuing and then


routing incoming calls to a specific phone number to designated agents based on predefined routing rules. For details, see Chapter 12 “Response Group Service.”Audio Test service: This service offers users the ability to subjectively test the quality of the call before placing a call. The user checks the call quality by making a test call.

In Office Communications Server, the Mediation Server was a separate role. With Lync Server 2010, this role can be collocated on the Front End Server and Standard Edition server. For details, see the section titled “Mediation Server” later in this chapter. In the “Conferencing Services” section later in this chapter, Table 3-2 lists the conferencing-specific services that also run on the Front End Server. Every Front End Server hosts a Web server that runs the World Wide Web Publishing Service (W3SVC) to provide HTTPS access to content from the Address Book Service (ABS), Web scheduler, and Web conferences as shown in Table 3-1. Message Queuing (also known as MSMQ), which provides asynchronous messaging to SQL Server, must be installed separately.Depending on the organization’s needs, any of these applications can be enabled or disabled. As is always the case, all Front End Servers must be configured identically. Although the Application Server component installs on every Front End Server, it is activated only when one of its applications starts.Table 3-1. Services on the Front End Server

Process Name Executable Display Name

RTCSRV RTCSrv.exe Lync Server Front-End

REPLICA ReplicaReplicatorAgent.exe Lync Server Replica Replicator Agent

RTCATS OcsAppServerHost.exe RTCATS Lync Server Audio Test Service

RTCPDPAUTH OcsAppServerHost.exe RTCPDPAUTH

Lync Server Bandwidth Policy Service (Authentication)

RTCPDPCORE OcsAppServerHost.exe RTCPDPCORE

Lync Server Bandwidth Policy Service (Core)

RTCCPS OcsAppServerHost.exe RTCCPS Lync Server Call Park

RTCCAS OcsAppServerHost.exe RTCCAS Lync Server Conferencing Announcement

RTCCAA OcsAppServerHost.exe RTCCAA Lync Server Conferencing Attendant

RTCRGS OcsAppServerHost.exe RTCRGS Lync Server Response Group

RTCMEDSRV MediationServerSvc.exe Lync Server Mediation

W3SVC Iissvcs W3SVC

MSMQ mqsvc.exe Message Queuing

Conferencing ServicesConferencing servers (also known as multipoint control units or MCUs) manage the content for Lync Server 2010 conferences. These services are automatically installed and run on the Front End Server and Standard Edition server. They cannot be installed separately from the Front End Server or Standard Edition server. Table 3-2 lists the conferencing servers in Lync Server 2010 by process name, executable filename, and display name.


Table 3-2 Conferencing specific services


RTCIMMCU IMMCUSvc.exe Lync Server IM Conferencing

RTCASMCU ASMCUSvc.exe Lync Server Application Sharing

RTCAVMCU AVMCUSvc.exe Lync Server Audio/Video Conferencing

RTCDATAMCU DataMCUSvc.exe Lync Server Web Conferencing

RTCMEETINGMCU MeetingMCUSvc.exe Lync Server Web Conferencing Compatibility

Each conferencing server communicates directly with the clients that are participating in a conferencing session. Each conferencing server uses its own protocol, which is optimized for the media it supports. They also synchronize the state of the conference with a process called the Focus that also runs on the Front End Server and Standard Edition server. The protocol used to control the state of the conference session is called Centralized Conferencing Control Protocol (C3P). The Focus sends state updates to the conferencing server using C3P, which the conferencing server listens for over an HTTPS channel. Organizers can schedule conferences only on Front End Servers or a Standard Edition server on which they are homed. Users homed on other Standard Edition servers and Front End pools can join as participants to the conference, but they cannot schedule a meeting on a Front End Server or Standard Edition server that is not their home server. The following sections describe each conferencing services in more detail.

IM ConferencingEscalating from a two-party IM session to a multiparty IM conference involves more than just adding new participants. New state information is involved in an IM conference, and this information must be synchronized across all the parties in an IM conference, such as tracking the list of participants, determining which participants are conference leaders, displaying the participants’ network of origin, and exposing a set of actions participants can perform (for example, mute, eject, and promote). The Focus controls the management of the conference session, and the IM Conferencing service enforces it. The Focus and the IM Conferencing service communicate by using the C3P protocol. Only port 5061 is required by the IM Conferencing service.

Web ConferencingThe Web Conferencing service is responsible for multiplexing the Web conferencing data feed (for example, documents, application sharing, and whiteboard content) from the leader to all participants in the session. Persistent Shared Object Model (PSOM) is the protocol used to share documents and application content in real time to provide that collaborative experience. PSOM uses port number 8057.

Audio/Video ConferencingThe A/V Conferencing service provides multiplexing of audio and video media. In the case of audio, the A/V Conferencing Server mixes the audio feeds from every participant before returning the mixed audio to each participant. The A/V Conferencing Server uses the real-time audio (RTAudio) codecs for audio and real-time video (RTVideo) codecs for video. Both protocols are designed to optimize performance in high-latency, low-bandwidth networks such as the Internet. Two-way communications are


peer to peer. Therefore, for voice calls (which make up the large majority of audio communications), the A/V Conferencing Server is not involved.The protocol used by the Audio/Video Conferencing service is secure real-time transport protocol (SRTP) over User Datagram Protocol (UDP) (SRTP/UDP). SRTP/UDP uses the port range 49152-65535.

Application Sharing ConferencingThis Application Sharing service provides application and desktop sharing. This allows participants to select specific applications to share with those in the conference versus having to share their whole desktop. The ability to share their entire desktop is also available.The protocol used by the Application Sharing Conferencing service is the Remote Desktop Protocol (RDP) over SRTP over Transmission Control Protocol (TCP) (RDP/SRTP/TCP). RDP/SRTP/TCP uses the port range 49152-65535.

Central Management ServerThe Central Management Server is automatically installed on the first instance of a Standard Edition server or Front End pool deployed in an Active Directory domain. For large organizations, we recommend that you dedicate a Front End pool as the Central Management Server. The pool provides high availability for the Central Management Server. This server or pool is called the Central Management Server master.The Central Management Server consists of a Central Management store, which is a central repository that stores all the configuration information (such as, topology, policies, voice routes, and conference directories) that is used by Lync Server. With the exception of settings that are associated with the user account stored in Active Directory Domain Services, all configuration settings previously stored in Active Directory and Windows Management Instrumentation (WMI) for Office Communications Server 2007 R2 is now stored in the Central Management store. Centralizing Lync Server settings simplifies its management. For example, it is no longer necessary to wait for Active Directory replication to complete before a voice policy setting is recognized on all Lync Servers. With Central Management Server as the master, the administrator can make configuration changes only on the Central Management Server. Changes are replicated automatically to all Lync Servers, including Edge Servers (assuming port 4443 is opened on the internal firewall) that are normally not joined to the internal Active Directory domain. Table 3-3 shows the services that are installed and run in the Content Management Server pool. The File Transfer Agent is responsible for replicating configuration settings with the Replica Replicator Agent that runs on every Lync Server. Every server role (Standard Edition server, Front End Server, Edge Server, Mediation Server, Monitoring Server, Archiving Server, Group Chat Server, and Survivable Branch Appliance) in Lync Server 2010 automatically installs an instance of SQL Server Express in which to store configuration settings from the Central Management Server. Each Lync Server maintains a local read-only copy of the Central Management store in case the Central Management Server is unavailable, so the Lync Server can continue to operate by using its local copy of the store. In Office Communications Server 2007 R2, the server couldn’t start if it couldn’t reach a local domain controller to read its configuration information. The Central Management Server uses the Server Message Block (SMB) protocol (port 445) to replicate to Lync Servers that are inside the corporate network and HTTPS on port 4443 to replicate to Edge Servers in the network perimeter. For details, see Chapter 13 “Server Administration.”


Table 1-3. Content Management Server pool services


Master Replicator MasterReplicatorAgent.exe Lync Server Master Replicator Agent

FTA FileTransferAgent.exe Lync Server File Transfer Agent


DirectorWhen you are deploying a single Standard Edition server or Front End pool, your topology remains simple. However, to handle a large number of users or users who are geographically dispersed, deploying multiple Standard Edition servers and Front End pools might be necessary. In such situations, it is best to deploy a Director or an array of Directors. The Director directs client traffic to the correct home server. Before explaining why it is important to deploy this server role, some background information is necessary. When users sign in to Lync Server, Lync 2010 performs a DNS Service Record Locator (SRV) query to locate a Lync Server (Edge Server, Director, Standard Edition server, or Front End pool) that is authoritative for the user’s SIP domain. The SIP domain is the portion of the user’s sign-in address after the “at” (@) symbol. Lync contacts the IP address that was returned from the DNS query and attempts to sign in to this server. If this server is the user’s home server, the server signs in the user. If not, this server redirects or proxies the connection (depending on whether the user is connecting from inside or outside the corporate network) to the user’s home server or pool.In the case of a single Standard Edition server or Front End pool deployment, the DNS SRV query will return the user’s home server because there’s only one. However, if you have deployed multiple Standard Edition servers and Front End pools within your organization, you must determine which Standard Edition servers and Front End pools to advertise for this SRV record in DNS. One option is to publish the fully qualified domain name (FQDN) of all your Standard Edition servers and Front End pools. In that case, the DNS SRV query might or might not return the user’s home server when Lync queries DNS. If the DNS query returns the FQDN of a server that is not the user’s home server, this server must redirect Lync to the user’s home server. This redirection makes the initial sign-in traffic unresolved or nondeterministic because clients signing in are not guaranteed to reach the user’s home server in the first hop.This nondeterministic configuration has several effects. First, each home server and pool must account for the performance load that is generated by redirecting a portion of Lync sign-in requests from users that are not homed on that server. In the worst-case scenario, every home server and pool must handle the load of redirecting sign-in traffic for all users in your organization. Second, if the DNS query directed Lync to a server that is unavailable, the user must wait for the network timeout to expire before attempting to connect to another server.To avoid the problem of home servers redirecting Lync traffic to the correct home server, you can elect to advertise a Director in DNS for this SRV record. The Director’s role is to direct Lync traffic to the correct home server when signing in a user. We recommend that you deploy a Director when your organization hosts multiple Standard Edition servers or Front End pools. The Director forces the sign-in traffic into a determined path. Instead of publishing the FQDN of the Standard Edition servers and Front End pools in DNS, the DNS SRV publishes the FQDN of the Director or bank of Directors. When Lync


attempts to sign in the user, its DNS SRV query returns the FQDN of the Director. When Lync connects to the Director, the Director knows how to locate the user’s home server and redirects the client to that server. The Director’s role is to redirect internal users to the correct Standard Edition server or Front End pool on which the user is homed. This configuration allows Standard Edition servers and Front End pools to handle SIP traffic only for their users.Unlike Office Communications Server 2007 R2, with Lync Server 2010 a Director pool no longer requires a back-end database running SQL Server. Because the Director’s role is only to redirect or proxy client connections to the user’s home pool and not to home any users, its deployment and cost has been streamlined. The cost of deploying a Windows Server with SQL Server installed is no longer necessary.Table 3-4 lists the services running on the Director by process name, executable filename, and display name.Table 3-4. Director services


RTCSRV RTCSrv.exe Lync Server Front-End


Notes from the FieldUsing a Pool of Directors to Boost ReliabilityByron SpurlockQuadrantechnologies, Founder and Principal Architect

As the Director role becomes more commonly used in remote user scenarios with Lync Server 2010, there are some important planning considerations to keep in mind along with a few subtle changes. The Director is now a true server role. When you configure a server as a Director, you cannot home users on it. You can still configure a single Director or a Director pool. The Director is not designated as either a Standard Edition or Enterprise Edition server. The Director is the server that stands between your perimeter Edge Servers and your Lync Server 2010 home server or pool. A few of the benefits of having a Director in place are to offload user authentication requests and to provide an extra layer of security between the Edge Servers in the perimeter network and your internal Lync Server 2010 pool.

Note. For performance, you should deploy one Director for every 15,000 users who will access a site remotely.

For a user in your organization to authenticate against a Director instead of the user’s home pool server, you have to point your SRV record for automatic configuration to your Director instead of your Standard Edition server or Front End pool. If you deploy a single Director, you have just introduced a single point of failure into your environment. To avoid this single point of failure, you can add multiple servers to create a Director pool. You will have to locate these pooled Directors behind a physical hardware load balancer.

Note. A pool of Directors must be load balanced. You can use a hardware load balancer, or you can implement DNS load balancing to take care of the SIP traffic. Implementing DNS load balancing makes the administration of the hardware load balancer simpler, because the hardware load balancer has to balance only HTTP traffic, which hardware load balancer administrators are accustomed to. In addition, the Director is always a separate server or pool, not collocated with any other server role in Lync Server 2010. With Office Communications Server 2007, we supported an array of Standard Edition servers behind a load balancer, which was commonly referred to as a Director array. From Lync Server 2010 forward, an array of Standard Edition


servers is no longer supported. However, a pool of Enterprise Edition servers configured as Directors is supported (Figure 3-3).

Figure 3-3. Pool configured as Directors

The process illustrated in Figure 3-3 is as follows:1. The User Replicator process synchronizes user information with Active Directory domain

controllers. 2. Lync performs a DNS SRV query to locate a Lync Server that is authoritative of the user’s SIP

domain.3. The DNS SRV query performed by Lync returns the FQDN and IP address of the Director. 4. Lync contacts the IP address returned from the DNS SRV query and connects to the Director.5. Because the Director is not the user’s home server, the Director redirects Lync to the user’s

home server or pool.6. Lync signs in to the user’s home server or pool.

In addition to helping route traffic for internal deployments, a Director plays an important role for external topologies. When configuring federation, public IM connectivity, or remote access, deploying a Director as the Access Edge Server’s next hop is required when remote access for users is needed. By using a Director or bank of Directors, the only IP address and port number that needs to be opened on the internal firewall is access to the Director on port 5061 for SIP traffic. By restricting the Access Edge Server to reach only the Director, you can limit access to your internal network if the Access Edge Server is ever compromised. None of the internal Standard Edition servers and Front End pools can be directly accessed by the Access Edge Server. The Director provides the following benefits:

Authenticates remote users. The Director prevents unauthorized users from entering the internal network.


Proxies remote user connections to the correct Standard Edition server or Front End pool. This is necessary because remote user connections cannot be redirected.

Mitigates denial-of-service (DoS) attacks. The Director verifies that the intended recipient of a message is a valid user. This protects internal servers from processing invalid messages from a public IM connection or federated partner.

For outgoing connections to the Access Edge Server, the Standard Edition servers and Front End pools route traffic destined for external users (that is, federated contacts, public IM connectivity contacts, and remote users) to the Director. The Director then proxies the connection to the Access Edge Server.

Survivable Branch Appliance or ServerEither through organic growth or through acquisitions, many organizations have multiple offices, often called branch offices, in different geographic locations. This creates a challenge for the IT department to service such remote offices. Often it’s not cost effective to deploy a Standard Edition server or Front End pool and hire a full-time IT administrator for each branch office. This leaves remote management as the most cost effective way to administer IT in these remote offices. Another problem that often occurs when remote offices are connected to the central office or headquarters over a WAN link is network connection failures to the central office. In such circumstances, employees in these remote offices must be able to continue working. This is particularly important when it comes to mission-critical services such as voice service and connectivity between users within the remote office.To address these two concerns, Lync Server 2010, through Microsoft Certified Partners, provides appliances that are specifically designed to be deployed in remote offices. These Survivable Branch Appliances, as the name indicates, provide a back-up when connectivity to the Lync Servers in the central office is severed. When users are no longer able to connect to their pool in the central office, Lync 2010 automatically signs-in to the backup home server, the Survivable Branch Appliance that is deployed in the branch office, and continues to provide the same service with some limitations. The Survivable Branch Appliance runs the Windows Server 2008 R2 operating system with the Lync Server Registrar service and Mediation Server, and is integrated with a media gateway to provide connectivity to the PSTN. Because the location of the Survivable Branch Appliance may not have IT personnel, the appliance is designed for easy deployment and remote management. Before a Survivable Branch Appliance is deployed, administrators can set up its account and configuration at the central office. A technician at the branch site then begins the deployment, and the deployment can be completed by the branch site technician or by administrators at the central site. If the WAN connection between a branch site and its central site fails, the Survivable Branch Appliance provides the following voice features to users at the branch site:

All two-party functionality, including instant messaging and audio/video conferencing PSTN inbound and outbound calls Intrasite and intersite calls Call hold, retrieve, and transfer User authentication and authorization Leaving and retrieving voicemail Call forwarding, simultaneous ringing, call delegation, and team calling Call detail recording (CDR). PSTN dial-in conferencing with Conferencing Auto-Attendant


Users in the branch office when connected to the Survivable Branch Appliance can place calls to the PSTN via the Survivable Branch Appliance integrated gateway. This failover solution allows branch office users to continue doing business as usual as well as place emergency calls in the event of a natural disaster.

Mediation ServerWith Lync Server 2010, the Mediation Server role is integrated in the Front End Server and Standard Edition server. Optionally, it can also be deployed as a stand-alone server. A couple of factors introduced in Lync Server 2010 make it highly scalable to be integrated with the Front End Server. A single Mediation Server role can route outbound calls to multiple media gateways instead of a single media gateway as in the case of Office Communications Server. Another enhancement made to the Mediation Server is media bypass. With supported media gateways, Lync clients and phones can directly route media traffic to the media gateway without routing through the Mediation Server. The signaling traffic (SIP) still continues to route through the Mediation Server role, but the audio no longer has to. This substantially optimizes audio traffic and eliminates the problem of hairpinning call paths.The Mediation Server is a server role necessary to bridge the PSTN traffic to and from the media gateway to the Lync Server network. Because some existing media gateways do not support the SIP protocol over Transport Layer Security (TLS) and optimized media codecs used by Lync Server 2010, the Mediation Server is needed to translate the RTAudio and RTVideo codecs to the G.711 and G.723 codecs that are commonly used by media gateways. In addition to performing codec translation, the Mediation Server performs reverse number lookups (RNLs) to resolve phone numbers from incoming calls that arrive from the media gateway to the corresponding SIP Uniform Resource Identifier (URI). After phone numbers are resolved into SIP URIs, the Mediation Server routes the call to the user’s home server.The Mediation Server runs the following services as described in Table 3-5. The Replica Replicator Agent synchronizes configuration settings from the Central Management Server.Table 3-5. Mediation Server services


RTCMEDSRV MediationServerSvc.exe Lync Server Mediation


Monitoring ServerIf you need to collect statistical usage metrics for IM, conferencing, and Enterprise Voice by tracking call detail records, you must deploy the Monitoring Server. The Monitoring Server uses a back-end SQL Server database to store the usage metrics it collects from clients. This SQL Server can be shared with the Archiving Server.The Monitoring Server runs the following services as shown in Table 3-6. It depends on Message Queuing for high performance, asynchronous messaging with Lync Server. Message Queuing provides guaranteed message delivery, efficient routing, security, and priority-based messaging. For details, see Chapter 15 “Monitoring and Archiving.”


Table 3-6. Monitoring Server services


RTCCDR RtcCdr.exe Lync Server Call Detail Recording

RtcQms QmsSvc.exe Lync Server QoE Monitoring Service



Archiving ServerIf your organization has a policy that requires the content of every IM communication to be logged for compliance purposes, you will have to deploy the Archiving Server. This server role enables archiving of all messages at the server level. Because all IM conversations travel through the user’s home server, it is possible to enforce archiving at the server level without requiring any cooperation from Lync 2010. This architecture offers the most control to the administrator. The services that are installed as part of the Archiving Server are shown in Table 3-7. Archiving Server depends on Message Queuing for high performance, asynchronous messaging with Lync Server. Message Queuing provides guaranteed message delivery, efficient routing, security, and priority-based messaging. For details, see Chapter 15.Table 3-7. Archiving Server services


RTCLOG RTCArch.exe Lync Server Archiving



Edge ServersLync Server 2010 defines the Edge Server role to be deployed in the perimeter network of an organization’s network. This server role enables an organization to expose Lync Server functionality across the corporate network boundary to remote employees, federated partners, and public IM connectivity users. The Edge Server uses three Internet facing IP addresses and one internal facing IP address. The three Internet facing IP addresses are each assigned to one of the following edges:

Access Web Conferencing Audio/Video

These IP addresses must be directly exposed to the Internet unless deployed behind a network address translation (NAT) firewall. Using an NAT IP address helps reduce the surface area of attack from the Internet as well as the cost of purchasing static public IP addresses.Table 3-8 lists the processes that run on the Edge Server. The RTCSrv process serves as a SIP proxy and manages the signaling traffic as well as IM traffic that is carried on


(piggybacks on) SIP. The media relay authentication process, RTCMRAUTH, performs authentication of clients before any audio/video media stream is established. For details about this authentication process, see Chapter 7 “External User Access.” The RTCDATAPROXY process manages the Web conferencing traffic.Table 3-8. Edge Server processes


RTCSrv RTCSrv.exe Lync Server Access Edge

RTCMRAUTH MRASSvc.exe Lync Server Audio/Video Authentication

RTCMEDIARELAY MediaRelaySvc.exe Lync Server Audio/Video Edge

RTCDATAPROXY DataProxy.exe Lync Server Web Conferencing Edge


To provide high availability, multiple Edge Servers can be deployed in a pool topology between two hardware load balancers that must be configured on both sides of the Edge Servers. These edges are explained in more detail in the following sections.

Access Edge The Access Edge provides federation, public IM connectivity, and remote user access. The Access Edge handles SIP and SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) traffic only. The SIMPLE protocol piggybacks on the SIP protocol to provide IM communications. The Access Edge does not directly authenticate users. Only internal Standard Edition servers and Front End pools authenticate users. The network security administrator must open port 443 on the external NIC assigned to the Access Edge to allow users to sign-in to their Lync home server and participate in IM conversations. Port 5061 should be opened on the external Access Edge for federation and public IM connectivity with AOL, MSN, and Yahoo! On the internal facing network adapter of the Edge Server, SIP over SIMPLE traffic is transported over port 5061, so port 5061 must be opened to every internal Lync Standard Edition server and Front End pool.

Web Conferencing EdgeThe Web Conferencing Edge proxies Web conferencing traffic (PSOM protocol) across the firewall between the Internet and the internal Lync Server deployment. The network security administrator must open port 443 on the external network adapter to allow users to connect from the Internet to the Web Conferencing Edge and port 8057 on the internal network adapter so that PSOM traffic between the Web Conferencing Edge and internal Lync Servers can flow. Connections between the Web Conferencing Edge and the Web Conferencing service hosted on the Front End Server are always initiated by the internal Web Conferencing service. This design reduces the number of connection vectors into the corporate network and helps reduce the surface area of security attacks.

Audio/Video Edge The A/V Edge enables audio and video traffic to traverse the corporate perimeter network. The A/V Edge serves as a meeting point for bridging users that connect from the Internet to an A/V conference that is hosted on the organizer’s Front End Server or Standard Edition server. Participants and the Front End Server that is hosting the A/V Conferencing service connect to the A/V Edge to establish a media path. The A/V Edge relays the SRTP traffic between the participants and A/V Conferencing service. Because the Front End Server that is


hosting the A/V conference initiates the connection to the A/V Edge, the firewall rules on the internal Edge Servers of the network perimeter do not need to allow SRTP traffic to be initiated from the Edge Server.The A/V Edge uses the Interactive Connectivity Establishment (ICE)/Simple Traversal Underneath NAT (STUN) (ICE/STUN) protocol to enable media traffic to traverse firewalls and network address translations (NATs) that might lie between the end user’s client and the A/V Edge.

Group Chat ServerMicrosoft Lync Server 2010, Group Chat provides the platform for Microsoft Lync 2010 Group Chat. Group Chat allows for persistent, ongoing IM conversations. Chat rooms are particularly useful for ongoing collaboration among project team members because all data that is part of the IM conversation in a chat room persists. The Group Chat Server instantiates the chat room, manages its permissions, and maintains its state for the duration of the chat room.


SummaryLync Server 2010 provides multiple server roles to scale to your enterprise’s needs and purpose.The Enterprise Edition scales up the capacity of the Standard Edition server to provide higher capacity and higher availability. The Director redirects user connections to the user’s home server or home pool. The Edge Servers are deployed in the network perimeter to enable connectivity outside the organization’s private network. A reverse proxy is required to expose Lync Web services to remote users. The Archiving Server performs server-side archiving of all IM communications. The Monitoring Server gathers CDR and Quality of Experience (QoE) data.

Additional ResourcesFor more information, see the following:

Microsoft Lync home page, http://go.microsoft.com/fwlink/?LinkId=203110 Lync Server TechCenter, http://go.microsoft.com/fwlink/?LinkId=191354 Lync Server 2010 TechNet Library, http://go.microsoft.com/fwlink/?LinkId=202714 NextHop Blog, http://go.microsoft.com/fwlink/?LinkId=204623 DrRez Blog, http://go.microsoft.com/fwlink/?LinkId=204593


Date post:	25-Apr-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Microsoft · Web viewThe Web Conferencing service is responsible for multiplexing the Web...

Documents