LS Deploy Edge Dir

Microsoft Lync Server 2010 Edge Deployment 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
Deploying Edge Servers...............................................................................................................1 Edge Deployment Overview......................................................................................................1 Deployment Process for External User Access......................................................................2 Edge Deployment Tools.........................................................................................................6 Deployment Best Practices for External User Access............................................................6 Preparing for Installation of Servers in the Perimeter Network...................................................7 System Requirements for Edge Components........................................................................7 Hardware and Software Requirements for Edge Components............................................7 Supported Server Collocation for Edge Components..........................................................9 Configure DNS for Edge Support...........................................................................................9 Configure DNS Records for Edge Support.........................................................................9 Configure the DNS Suffix for Edge Servers......................................................................10 Set Up Hardware Load Balancers for Scaled Edge Topology...............................................11 Configure Firewalls and Ports for External User Access.......................................................11 Determining External A/V Firewall and Port Requirements................................................11 Request Edge Certificates...................................................................................................15 Request Certificates from a Public CA..............................................................................15 Request Certificates from an Internal Enterprise CA.........................................................15 Prepare for Support of Public IM Connectivity......................................................................16 Building an Edge and Director Topology..................................................................................16 Define the Director...............................................................................................................17 Define a Single Director in Topology Builder.....................................................................17 Define a Multiple Director Pool in Topology Builder...........................................................18 Defining Your Edge Topology...............................................................................................20 Define the Topology for a Single Edge Server...................................................................20 Define the Topology for a DNS Load Balanced Edge Pool................................................23 Define the Topology for a Hardware Load Balanced Edge Pool........................................26 Publish Your Topology..........................................................................................................30 Setting Up the Director............................................................................................................30 Install the Local Configuration Store....................................................................................31 Install Lync Server 2010 on the Director...............................................................................32 Configure Certificates for the Director..................................................................................32 Start Services on the Director..............................................................................................33 Test the Director..................................................................................................................34 Configure Automatic Client Sign-In To Use the Director.......................................................34 Setting Up Edge Servers.........................................................................................................35 Set Up Network Interfaces for Edge Servers........................................................................35 Install Prerequisite Software on Edge Servers.....................................................................37 Export Your Topology and Copy It to External Media for Edge Installation............................37 Install Edge Servers.............................................................................................................37 Set Up Edge Certificates......................................................................................................38 Certificate Requirements for External User Access...........................................................39
Set Up Certificates for the Internal Edge Interface............................................................40 Set Up Certificates for the External Edge Interface...........................................................45 Set Up Certificates for the Reverse Proxy.........................................................................51 Start Edge Servers..............................................................................................................51 Set Up Reverse Proxy Servers............................................................................................51 Configure Web Farm FQDNs...........................................................................................53 Configure Network Adapters.............................................................................................53 Request and Configure a Certificate for Your Reverse HTTP Proxy..................................54 Configure Web Publishing Rules for a Single Internal Pool...............................................55 Verify or Configure Authentication and Certification on IIS Virtual Directories....................58 Create DNS Records for Reverse Proxy Servers..............................................................58 Verify Access through Your Reverse Proxy.......................................................................58 Configuring Support for External User Access.........................................................................59 Enable or Disable External User Access for Your Organization............................................60 Enable or Disable Remote User Access for Your Organization.........................................61 Enable or Disable Federation for Your Organization.........................................................62 Enable or Disable Anonymous User Access for Your Organization...................................64 Configure Communications with External Users...................................................................65 Manage Remote User Access..........................................................................................66 Manage Federated Partner User Access..........................................................................67 Configure Policies to Control Federated User Access.......................................................68 Control Access by Individual Federated Domains.............................................................69 Manage IM Provider Support............................................................................................71 Configure Policies to Control Access by Users of IM Service Providers............................71 Specify Supported IM Service Providers...........................................................................73 Configure Conferencing Policies to Support Anonymous Users........................................76 Apply Policies for External User Access to Users.............................................................77 Apply External User Access Policies to Users..................................................................77 Apply Conferencing Policies to Support Anonymous Users..............................................78 Verifying Your Edge Deployment.............................................................................................79 Verify Connectivity Between Internal Servers and Edge Servers..........................................79 Verify Connectivity for External Users..................................................................................79
Deploying Edge Servers

Deploying edge components for Microsoft Lync Server 2010 makes it possible for external users who are not logged into your organizations internal network, including authenticated and anonymous remote users, federated partners, and users of public instant messaging (IM) services, to communicate with other users in your organization using Lync Server. The deployment and configuration processes for Lync Server 2010 are significantly different from previous releases because Lync Server 2010 provides new tools for installation and administration that change the way that you work with Lync Server components. The sections in the Edge Deployment Overview topic describe the deployment process, new tools, and how you use the tools to deploy edge components for external user access. Before you begin, watch the short video at http://go.microsoft.com/fwlink/?LinkId=205566 for an overview of using Topology Builder to add an Edge Server to an existing Lync Server 2010 deployment.
In This Section
Edge Deployment Overview Preparing for Installation of Servers in the Perimeter Network Building an Edge and Director Topology Setting Up the Director Setting Up Edge Servers Configuring Support for External User Access Verifying Your Edge Deployment
Edge Deployment Overview

To provide support for external user access, federation, and integration with public IM connectivity, you need to deploy Edge Servers and other components in the perimeter network, in addition to preparing the network and firewall infrastructure to support these components. Deployment includes using the tools provided in Microsoft Lync Server 2010 to start the deployment of Edge Servers. This section provides an overview of the Edge Server deployment process, the tools that you'll use to deploy Edge Servers, and best practices for deploying components to support external user access.
In This Section
Deployment Process for External User Access Edge Deployment Tools Deployment Best Practices for External User Access
Deployment Process for External User Access

Effective planning for external user access requires that you take into account the following: Prerequisites for deploying an edge topology. Steps that are required to deploy Edge Servers and related components.
Deployment Prerequisites for External User Access Before you deploy your perimeter network and implement support for external users, you must already have deployed your Microsoft Lync Server 2010 internal servers, including a Front End pool or a Standard Edition server. If you plan to deploy Directors in your internal network, you should also deploy them prior to deploying Edge Servers. For details about the Director deployment process, see Director in the Planning documentation. Deployment Process for Edge Servers The following table provides an overview of the Edge Server deployment process. For details about deployment steps, see Deploying Edge Servers. Note: The information in the following table focuses on a new deployment. If you have deployed Edge Servers in an Office Communications Server 2007 R2 or Office Communications Server 2007 environment, see the Migration for details about migrating to Lync Server 2010. Migration is not supported from any version prior to Office Communications Server 2007, including Live Communications Server 2005, and Live Communications Server 2003. Edge Server Deployment Process
Phase Steps Permissions Documentation
Create the appropriate edge topology and determine the appropriate components.
Run Topology Domain Admins group and Builder to RTCUniversalServerAdmins group configure Edge Note: Server settings You can define a topology and create and using an account that is a publish the member of the local users topology, and then group, but publishing a use Lync Server topology requires an Management Shell account that is a member of to export the the Domain Admins group topology and the configuration file. RTCUniversalServerAdmi ns group. 1. Ensure that system prerequisites are met. 2. Configure IP As appropriate to your organization
Defining Your Edge Topology
Prepare for setup.
Preparing for Installation of Servers in the Perimeter Network
Microsoft Lync Server 2010 Edge Deployment Guide Phase Steps Permissions Documentation
addresses for both internal and public facing network interfaces on each Edge Server. 3. Configure internal and external DNS records, including configuring the DNS suffix on the computer to be deployed as an Edge Server. 4. Configure firewalls. 5. (Optional) Create and install public certificates. The time required to obtain certificates depends on which certification authority (CA) issues the certificate. If you do not perform this step at this point, you must do it during Edge Server installation. The Edge Server service cannot be started until certificates are obtained. 6. Provision support for public IM connectivity, if your deployment is to support
communications with Windows Live, AOL, or Yahoo! users. Set up reverse proxy. Set up the Administrators group reverse proxy (for example, for Microsoft Forefront Threat Management Gateway 2010 or Microsoft Internet Security and Acceleration (ISA) Server with Service Pack 1) in the perimeter network, obtain the necessary public certificates, and configure the web publishing rules on the reverse proxy server. (Optional) Install and configure one or more Directors in the internal network. 1. Install prerequisite software. 2. Transport the exported topology configuration file to each Edge Server. 3. Install the Lync Server 2010 software on each Edge Server. Administrators group
Set Up Reverse Proxy Servers
Setup a Director (recommended).
Setting Up the Director
Set up Edge Servers.
Administrators group
Setting Up Edge Servers
4. Configure the Edge Servers. 5. Request and install certificates for each Edge Server. 6. Start the Edge Server services. Configure support for external user access. 1. Use the Lync Server 2010 Control Panel to configure support for each of the following (as applicable): Remote user access Federation Public IM connectivity Anonymous users 2. Configure user accounts for remote user access, federation, public IM connectivity, and anonymous user support (as applicable) Verify your Edge Server configuration. 1. Verify server connectivity and replication of configuration data from internal servers. 2. Verify that external users can For verification of replication, RTCUniversalServerAdmins group or user account that is assigned to the CSAdministrator role For verification of user connectivity, a user for each type of external user access that you support Verifying Your Edge Deployment RTCUniversalServerAdmins group or user account that is assigned to the CSAdministrator role Configuring Support for External User Access
connect, including Remote users remote users, users in federated domains, public IM users, and anonymous users, as appropriate to your deployment.
Edge Deployment Tools

Microsoft Lync Server 2010 includes two tools to facilitate planning and deployment of both internal servers and Edge Servers. We recommend running them on a local workstation first to plan your design. After the topology is completed, upload the resulting topology definition to your production environment. To do this, you must be a member of the Domain Admins group and the RTCUniversalServerAdmins group. Planning Tool Office Communications Server 2007 R2 included a Planning Tool and an Edge Planning Tool that you could use to help guide topology design. In Lync Server 2010, these two tools have been combined into a single Lync Server 2010, Planning Tool that has additional features and functionality, including the ability to generate an XML-based topology document. Topology Builder Lync Server 2010 Topology Builder helps you define your topology and components. Topology Builder is essential to deploying servers running Lync Server 2010. Topology Builder can use the XML topology file provided by the Planning Tool to start the initial design of your topology, or you can skip the Planning Tool and use the Topology Builder to design your deployment. Topology Builder publishes the results to a Central Management store that is used to configure all of the servers running Lync Server 2010 in your organization. You cannot install Lync Server 2010 on servers without using Topology Builder. If you built your edge topology during your planning process, including running Topology Builder to define your edge topology, you can use those results to start your Edge Server deployment. If you did not finish building your edge topology earlier or you want to change the information you previously specified, you must finish running Topology Builder before proceeding with other deployment steps. For details about how to build your topology, see Topologies for External User Access. For details about the Planning Tool and Topology Builder, see Beginning the Planning Process in the Planning documentation.
Deployment Best Practices for External User Access

To enhance Edge Server performance and security, and to facilitate deployment, apply the following best practices when you deploy your perimeter network and Edge Servers:
Deploy Edge Servers only after you have tested and verified operation of Microsoft Lync Server 2010 communications software inside your organization. We recommend that you deploy Edge Servers in a workgroup rather than a domain. Doing so simplifies installation and keeps Active Directory Domain Services (AD DS) out of the perimeter network. Locating AD DS in the perimeter network can present a significant security risk. Joining an Edge Server to a domain located entirely in the perimeter network is supported but not recommended. An Edge Server should never be part of a domain in the internal network.
Preparing for Installation of Servers in the Perimeter Network

Before you set up Edge Server components, you need to ensure that computers that you are setting up meet system requirements and complete other prerequisite steps required for deployment of Edge Server components. Before you begin, review the details in the following topics in the Planning documentation for the reference architecture that you want to deploy: Reference Architecture 1: Single Consolidated Edge Reference Architecture 2: Scaled Consolidated Edge (DNS Load Balanced) Reference Architecture 3: Scaled Consolidated Edge (Hardware Load Balanced)
In This Section
System Requirements for Edge Components Configure DNS Records for Edge Support Set Up Hardware Load Balancers for Scaled Edge Topology Configure Firewalls and Ports for External User Access Request Edge Certificates Prepare for Support of Public IM Connectivity
System Requirements for Edge Components

System requirements for edge components include hardware, software, and collocation requirements for Edge Servers and also for any Directors and reverse proxy servers that you plan to deploy. In This Section Hardware and Software Requirements for Edge Components Supported Server Collocation for Edge Components
Hardware and Software Requirements for Edge Components The hardware and software requirements for edge components include those for the Microsoft Lync Server 2010 communications software components, including Edge Servers and Directors, as well as those for other components, including reverse proxy servers, firewalls, and load balancers to be
deployed the perimeter network to support external user access. For details about the components required to support external user access and supported topologies, see Components Required for External User Access. Hardware and Software Requirements for Edge Servers and Directors The operating system requirements for Edge Servers are the same as for the other Lync Server 2010 roles: the 64-bit edition of the Windows Server 2008 SP2 or Windows Server 2008 R2. In addition, the operating system must be configured for the Application Server role and be running the .NET Framework 3.5 Service Pack 1 (SP1). Directors are internal components and installed as part of the internal network prior to deployment of Edge Servers. For hardware and software requirements for Directors, see Technical Requirements for Director. The following table shows the hardware requirements for Edge Servers. Hardware System Requirements for Edge Servers
Hardware component Minimum requirement
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 Disk Network
12 GB recommended Local storage with at least 30 GB free disk space Two interfaces required, either one 2-port 1 Gbps NIC or two 1-port 1 Gbps NICs.
Lync Server 2010 is available only in a 64-bit edition, so each Edge Server and Director requires one of the following operating systems. The 64-bit edition of Windows Server 2008 Enterprise Edition with SP2 operating system, or the 64-bit edition of Windows Server 2008 Standard Edition with SP2 operating system. The 64-bit edition of Windows Server 2008 R2 Enterprise operating system, or the 64-bit edition of Windows Server 2008 R2 Standard operating system. Lync Server 2010 also requires installation of the following programs and updates: Microsoft .NET Framework 3.5 SP1 Windows PowerShell command-line interface version 2.0
Windows Server 2008 R2 update available from Microsoft Knowledge Base article 2028827, "The applications that use the TDI driver for network traffic may stop responding in Windows Server 2008 R2 or in Windows 7," at http://go.microsoft.com/fwlink/?LinkId=205459. Windows 2008 SP2 update is required to avoid increasing memory usage on Web Conferencing Edge Server. For details, see Microsoft Knowledge Base article 979231,"Memory usage keeps increasing if Schannel authentication is used after the update 968389 is installed
in Windows Vista or in Windows Server 2008," at http://go.microsoft.com/fwlink/? LinkId=200747. After you apply this update, the increasing memory usage should go away. Windows Server 2008 update available from Microsoft Knowledge Base article 2029048, "Applications that use the TDI driver for network traffic may stop responding in Windows Server 2008 or in Windows Vista," at http://go.microsoft.com/fwlink/?LinkId=205458. Additionally, Lync Server requires the Microsoft Visual C++ 2008C redistributable, but it is automatically installed as part of the Edge Server installation. Supported Server Collocation for Edge Components Access Edge service, Web Conferencing Edge service, and A/V Edge service are collocated on the same server. The following edge components cannot be collocated with each other or with any other Microsoft Lync Server 2010 server role: Edge Server Director Reverse proxy
The reverse proxy does not need to be dedicated to Lync Server. If you already have a supported reverse proxy server in the perimeter network to support other services, you can use it for Lync Server. For details, see the Supportability documentation.
Configure DNS for Edge Support

To configure the Domain Name System (DNS), you need to configure DNS records and a DNS suffix for the computer name of each Edge Server that is not joined to a domain. In This Section Configure DNS Records for Edge Support Configure the DNS Suffix for Edge Servers
Configure DNS Records for Edge Support You must configure Domain Name System (DNS) records for internal and external edge interfaces, including both Edge Server and reverse proxy interfaces. Note: By default, DNS uses a round robin algorithm to rotate the order of resource record data returned in query answers where multiple resource records of the same type exist for a queried DNS domain name. Lync Server 2010 DNS load balancing depends on this mechanism. Verify that this setting has not been disabled. If you are using a DNS server that is not running a Windows operating system, verify that round-robin resource record ordering is enabled. Use the following procedures to create and verify each DNS SRV record and DNS A record required for external user access. For details about each record required to support external user access, see Determining DNS Requirements.
To create a DNS SRV record 1. On the appropriate DNS server, click Start, click Control Panel, click Administrative Tools, and then click DNS. Important: You need to configure DNS so that there are: 1) external DNS entries for external DNS lookups by remote users and federated partners; 2) entries for DNS lookups for use by the Edge Servers within the perimeter network (also known as DMZ, demilitarized zone, and screened subnet), including A records for the internal servers running Lync Server 2010; and 3) internal DNS entries for lookups by the internal clients and servers running Lync Server 2010. 2. In the console tree for your SIP domain, expand Forward Lookup Zones, and then right-click the domain where Lync Server 2010 is installed. 3. Click Other New Records. 4. In Select a resource record type, type Service Location (SRV), and then click Create Record. 5. Provide all required information for the DNS SRV record. To create a DNS A record 1. On the DNS server, click Start, click Control Panel, click Administrative Tools, and then click DNS. 2. In the console tree for your SIP domain, expand Forward Lookup Zones, and then right-click the domain in which Lync Server 2010 is installed. 3. Click New Host (A). 4. Provide all required information for the DNS SRV record. To verify a DNS record 1. Log on to a client computer in the domain. 2. Click Start, and then click Run. 3. At the command prompt, run the following command: nslookup <FQDN edge interface> 4. Verify that you receive a reply that resolves to the appropriate IP address for the FQDN. See Also Create a DNS SRV Record for Integration with Hosted Exchange UM Configure the DNS Suffix for Edge Servers By default the computer name of an Edge Server that is not joined to a domain is a short name, not a fully qualified domain name (FQDN). However, Topology Builder uses FQDNs, not short names, and the internal name on the Edge Server must match the FQDN used by Topology Builder, so you must change the short name to an FQDN by adding a Domain Name System (DNS) suffix to the
10
name of each Edge Server that is not joined to a domain. Use the following procedure to add the DNS suffix to the computer name. To add the DNS suffix to the computer name on an Edge Server that is not joined to a domain 1. On the computer, click Start, right-click Computer, and then click Properties. 2. Under Computer name, domain, and workgroup settings, click Change settings. 3. On the Computer Name tab, click Change. 4. In Computer Name/Domain Changes, click More. 5. In DNS Suffix and NetBIOS Computer Name, in Primary DNS suffix of this computer, type the name of your internal domain (for example, corp.contoso.com), and then click OK three times. 6. Restart the computer. Note: After you complete these steps, DNS load balancing is operational.
Set Up Hardware Load Balancers for Scaled Edge Topology

If you are configuring a scaled edge topology using a hardware load balancer, see Reference Architecture 3: Scaled Consolidated Edge (Hardware Load Balanced) in the Planning documentation.
Configure Firewalls and Ports for External User Access

To configure firewalls and ports, you need to configure them for Edge Servers, reverse proxy servers, and possibly hardware load balancers (for a scaled deployment that does not use DNS load balancing). This section provides information about firewall and port requirements for all Edge Server components and the configuration of firewall ports for Edge Servers. For details about configuring ports for reverse proxy servers, see Set Up Reverse Proxy Servers. If you are deploying a scaled edge topology and are using hardware load balancing instead of DNS load balancing, see Reference Architecture 3: Scaled Consolidated Edge (Hardware Load Balanced) in the Planning documentation for details about configuring ports for hardware load balancers. In This Section Determining External A/V Firewall and Port Requirements
Determining External A/V Firewall and Port Requirements Use the following Firewall and Port table to determine firewall requirements and which ports to open. Then, review the network address translation (NAT) terminology because NAT can be implemented in many different ways. For a detailed example of firewall port settings, see the reference architectures in Topologies for External User Access.
11
A/V Firewall and Port Requirements

Federation with Feature TCP/443 UDP/3478 RTP/UDP 50,00059,999 RTP/TCP 50,00059,999
Windows Live Messenger 2011
Point to Point Audio/Video (A/V)
Open inbound
Open inbound Open outbound
Not required
Not required
Lync Server 2010
A/V
Open inbound
Not required
Not required
Lync Server 2010
Application sharing/desktop sharing
Open inbound
Not required
Not required
Lync Server 2010
File transfer
Open inbound
Not required
Not required
Office Communications Server 2007 R2
A/V
Open inbound
Not required
Not required
Office Communications Server 2007 R2
Desktop sharing
Open inbound
Not required
Not required
Office Communications Server 2007 R2 Office Communications Server 2007
File transfer
N/A
N/A
N/A
N/A
A/V
Open inbound
Open inbound
Open inbound Open outbound N/A
Office Communications Server 2007 Office
Desktop sharing
N/A
N/A
N/A
File transfer
N/A
N/A
N/A
N/A
12
Microsoft Lync Server 2010 Edge Deployment Guide Federation with Feature TCP/443 UDP/3478 RTP/UDP 50,00059,999 RTP/TCP 50,00059,999
Communications Server 2007 Notes: (inbound) refers to RTP/TCP and RTP/UDP traffic from the Internet to the A/V Edge external interface. (outbound) refers to RTP/TCP and RTP/UDP traffic from the A/V Edge external interface to the Internet. External A/V Firewall Port Requirements for External User Access The firewall port requirements for external (and internal) SIP and conferencing (PowerPoint presentations, whiteboarding and polling) interfaces are consistent, regardless of the version your federation partner is running. The same is not true for the Audio/Video Edge external interface. In most cases, the A/V Edge service requires that external firewall rules allow RTP/TCP and RTP/UDP traffic in the 50,000 through 59,999 port range to flow in one or both directions. For example, opening this port range is required to support certain federation scenarios and the preceding table provides the details for each scenario. The table assumes that Lync Server 2010 is the primary federation partner and it is being configured to communicate with one of the four federation partner types listed. NAT Requirements for External User Access NAT is typically a routing function, but newer devices such as firewalls, and even hardware load balancers can be configured for NAT. Rather than focusing on which device is performing NAT, this topic describes the required NAT behavior instead. Microsoft Lync Server 2010 communications software does not support NAT for traffic to or from the Edge internal interface, but for the Edge external interface, the following NAT behavior is required. This documentation uses the acronyms ChangeDST and ChangeSRC in tables and drawings to define the following required behavior: ChangeDST The process of changing the destination IP address on packets destined for the network that is using NAT. This is also known as transparency, port forwarding, destination NAT mode, or half-NAT mode. ChangeSRC the process of changing the source IP address on packets leaving the network that is using NAT. This is also known as proxy, secure NAT, stateful NAT, source NAT or full-NAT mode. Regardless of the naming convention used, the NAT behavior required for the external interface of the Edge Server is as follows: For traffic from the Internet to the Edge external interface: Change the destination IP address of the incoming packet from the Edge external interface public IP address to the translated IP address of the Edge external interface. Leave the source IP address intact so that there is a return route for the traffic.
13
For traffic from the Edge external interface to the Internet: Change the source IP address of the packet leaving the Edge external interface, from the translated IP address to the public IP address of the Edge external interface so that the internal Edge IP address is not exposed and because it is a non-routable IP address. Leave the destination IP address intact on the outgoing packets.
The following figure shows the distinction between changing the destination IP address (ChangeDST) for inbound traffic and changing the source IP Address (ChangeSRC) for outbound traffic using the A/V edge as an example. Changing the destination IP address (ChangeDST) for inbound traffic and changing the source IP Address (ChangeSRC)
The key points are: For traffic incoming to the A/V Edge, the source IP address does not change but the destination IP address changes from 131.107.155.30 to the translated IP address of 10.45.16.10. For traffic outbound from the A/V Edge back to the workstation, the source IP address changes from that of the servers public IP address to that of the A/V Edges public IP address. And the destination IP remains the workstations public IP address. After the packet leaves the first NAT device outbound, the rule on the NAT device changes the source IP address from the A/V Edges external interface IP address (10.45.16.10) to its public IP address (131.107.155.30).
14
Request Edge Certificates

The certificates required to support external user access include certificates issued by a public certification authority (CA), and certificates issued by an internal Enterprise CA: Certificates required for the external interface of Edge Servers and the reverse proxy must be issued by a public CA. Certificates required for the internal interface can be issued by either a public CA or an internal enterprise CA. We recommend using an internal Windows Server 2008 CA or Windows Server 2008 R2 CA for creating these certificates to save on the expense of using public certificates. It can take time to process certificate requests, especially requests to public CAs, so you should request certificates for your Edge Servers early enough to ensure that they are available when you start deployment of your Edge Server components. For a summary of certificate requirements for Edge Servers, see Certificate Requirements for External User Access. In This Section Request Certificates from a Public CA Request Certificates from an Internal Enterprise CA
Request Certificates from a Public CA Your Edge Server deployment requires a single public certificate for the external interfaces of Edge Servers, which is used for the Access Edge service, the Web Conferencing Edge service, and for A/V authentication service. This certificate must have an exportable private key to ensure that the A/V authentication service uses the same keys on all Edge servers in a pool. The reverse proxy, which is used with Microsoft Internet Security and Acceleration (ISA) Server 2006 or Microsoft Forefront Threat Management Gateway 2010, also requires a public certificate. Although you can choose to use a public CA for the internal edge certificate, we recommend that you use an internal enterprise CA for those other certificates instead to minimize the cost of certificates. For a summary of certificate requirements for Edge Servers, see Certificate Requirements for External User Access. For details about using an internal Enterprise CA to obtain the internal edge and A/V authentication certificates, see Request Certificates from an Internal Enterprise CA. Note: When you install an Edge Server, setup includes a certificate wizard that facilitates the tasks of requesting, assigning, and installing certificates, as described in the Set Up Edge Certificates section. If you want to request certificates prior to installing an Edge Server (such as to save time during actual deployment of Edge Server components), you can do so using internal servers as long as you ensure that the certificates are exportable and contain all of the required subject alternative names. This documentation does not provide procedures for using internal servers to request certificates. Request Certificates from an Internal Enterprise CA The certificates required for the internal edge interface can be issued by either a public certification authority (CA) or an internal CA. You can use an internal enterprise CA to help minimize the cost of
15
certificates. If your organization has an internal CA deployed, the certificates for the internal edge should be issued by the internal CA. Using an internal enterprise CA for internal certificates can reduce the cost of certificates. For a summary of certificate requirements for edge components, see Certificate Requirements for External User Access. For details about using a public CA to obtain certificates, see Request Certificates from a Public CA. For details about requesting, installing, and assigning certificates, see Set Up Edge Certificates.
Prepare for Support of Public IM Connectivity

Supporting connectivity with public IM users in your organization requires that the appropriate licensing is in place and that the provisioning process for the public IM services that you want to support is complete. Provisioning can take up to thirty days, so allow sufficient time to complete the process prior to the date on which you want to implement support. For details about licensing requirements and how to complete the provisioning process, see the "Public IM Connectivity Provisioning Guide for Microsoft Lync Server, Office Communications Server, and Live Communications Server" at http://go.microsoft.com/fwlink/?LinkId=155970. If you are implementing audio/video (A/V) federation with Windows Live Messenger, there are two parameters that you need to modify: the Microsoft Lync Server 2010 encryption level and the EnablePublicCloudAccess policy. By default, the encryption level is set to Required. You must change this setting to Supported. The EnablePublicCloudAccess policy is set to false, this needs to be set to true You can do this from the Lync Server Management Shell.
1. Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell. 2. From the command prompt, type the following commands: Set-CsMediaConfiguration EncryptionLevel SupportEncryption Set-CsExternalAccessPolicy Global EnablePublicCloudAccess $true -EnablePublicCloudAudioVideoAccess $true Note: This example modifies the global policy. Change this to the appropriate policy in your environment. See Also Set-CsMediaConfiguration
Building an Edge and Director Topology

Building the topology involves the following planning and deployment tasks: Planning You need to define an appropriate topology for your organization and identify the components required to deploy it. These are standard steps in the planning process. The Microsoft Lync Server 2010, Planning Tool makes it easy to start the planning process, including the ability to easily make changes as your requirements and plans are finalized.
16
Deployment The topology that you define using Topology Builder is essential to the deployment of any Lync Server 2010 server. If you do not finish defining and publishing your topology by using Topology Builder as part of your planning efforts, you must complete it and make the information available from the Edge Servers before you deploy your Edge Servers. You cannot deploy Edge Server components until you have deployed at least one internal pool, and you must install Topology Builder to deploy an internal pool. This section does not cover installation of Topology Builder because that is part of the installation process for the internal pool. For details about these tools, see Edge Deployment Tools. Note: If you previously used Topology Builder to define a complete topology, including the edge topology, you do can skip the Defining Your Edge Topology and Publish Your Topology tasks in this section, but you do need to complete the Export Your Topology and Copy It to External Media for Edge Installation task.
In This Section
Define the Director Defining Your Edge Topology Publish Your Topology
Define the Director

If you enable access for external users by deploying Edge Servers, you should also deploy a Director. A Director is a server running Microsoft Lync Server 2010 that authenticates user requests, but does not home any user accounts. When you use a Director to authenticate external users, it does the following: Relieves servers in the Front End pool from the overhead of performing authentication of these users. Helps insulate internal Front End pools from malicious traffic, such as denial-of-service (DoS) attacks. Ends traffic at the Director when the network is flooded with invalid external traffic in a DoS or similar attack. As a result, internal users should not experience any effect on performance. To deploy any of the servers running Lync Server 2010, you must use Topology Builder first to define and publish your topology, including your Director and Edge Server topology. In This Section Define a Single Director in Topology Builder Define a Multiple Director Pool in Topology Builder
Define a Single Director in Topology Builder Lync Server 2010 Directors can be single-instance servers or they can be installed as a loadbalanced pool of multiple Directors for higher availability and capacity. Both hardware load balancing and Domain Name System (DNS) load balancing are supported. This topic explains how to configure DNS load balancing for Director pools.
17
To successfully publish, enable, or disable a topology when you add or remove a server role, you should be logged on as a user who is a member of the RTCUniversalServerAdmins and Domain Admins groups. You can also delegate the proper administrator rights and permissions for adding server roles. For details, see Delegate Setup Permissions in the Standard Edition server or Enterprise Edition server Deployment documentation. For other configuration changes, only membership in the RTCUniversalServerAdmins group is required. To define the Director (single instance) 1. Start Topology Builder: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Topology Builder. 2. On the welcome page, click Download Topology from Existing Deployment. 3. In the Save Topology As dialog box, type the name and location of the local copy of the existing topology, and then click Save. 4. Expand the site in which you plan to add the Director, right-click Director pools, and then click New Director Pool. 5. In the Define the Director pool FQDN dialog box, do the following: In Pool FQDN, type the FQDN for the Director pool. Click Single computer pool, and then click Next.
6. In the Define the file share dialog box, do one of the following: a. To use an existing file share, click Use a previously defined file share, select a file share from the list, and then click Next. b. To create a new file share, click Define a new file share, type the FQDN for the location of the file share in File Server FQDN, type the name of the share in File Share, and then click Next. Important: The file share that you specify or create in this step must exist or be created prior to publishing the topology. 7. In the Specify the Web Services URL dialog box, in External Base URL, specify the FQDN for the Directors, and then click Finish. Important: The name must be resolvable from Internet DNS servers and point to the public IP address of the reverse proxy, which listens for HTTP/HTTPS requests to that URL and proxies them to the external Web Services virtual directory on that Director. 8. Publish the topology.
Define a Multiple Director Pool in Topology Builder Lync Server 2010 Directors can be single-instance servers or can be installed as a load-balanced pool of multiple Directors for higher availability and capacity. Both hardware load balancing and Domain Name System (DNS) load balancing are supported. The documentation explains how to configure DNS load balancing for Director pools.
18
To successfully publish, enable, or disable a topology when you add or remove a server role, you should be logged on as a user who is a member of the RTCUniversalServerAdmins and Domain Admins groups. You can also delegate the proper administrator rights and permissions for adding server roles. For details, see Delegate Setup Permissions in the Standard Edition server or Enterprise Edition server Deployment documentation. For other configuration changes, only membership in the RTCUniversalServerAdmins group is required. To define the Director (multiple Director pool) 1. Start Topology Builder: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Topology Builder. 2. On the welcome page, click Download Topology from Existing Deployment. 3. In the Save Topology As dialog box, type the name and location of the local copy of the existing topology, and then click Save. 4. Expand the site in which you plan to add the Director, right-click Director pools, and then click New Director Pool. 5. In the Define the Director pool FQDN dialog box, do the following: In Pool FQDN, type the FQDN for the Director pool. Click Multiple computer pool, and then click Next. Specify the computer FQDN of the first pool member, and then click Add.
6. In the Define the computers in this pool dialog box, do the following: Repeat the previous step for each computer that you want to add. When you are finished, click Next. 7. In the Define the file share dialog box, do one of the following: To use an existing file share, click Use a previously defined file share, select a file share from the list, and then click Next. To create a new file share, click Define a new file share, type the FQDN for the location of the file share in File Server FQDN, type the name of the share in File Share, and then click Next. Important The file share that you specify or create in this step must exist or be created prior to publishing the topology. The file share assigned to a Director is not actually used, so you can assign the file share of any pool in the organization. 8. In the Specify the Web Services URL dialog box, in External Base URL, specify the FQDN for the Directors, and then click Finish. Important: The name must be resolvable from Internet DNS servers and point to the public IP address of the reverse proxy, which listens for HTTP/HTTPS requests sent to that URL and proxies them to the external Web Services virtual directory on that Director pool.
19
9. Publish the topology.
Defining Your Edge Topology

To deploy a server running Lync Server 2010, you must use Topology Builder first to define and publish your topology, including your edge topology. In This Section Define the Topology for a Single Edge Server Define the Topology for a DNS Load Balanced Edge Pool Define the Topology for a Hardware Load Balanced Edge Pool
Define the Topology for a Single Edge Server You must use Topology Builder to build your topology and you must set up at least one internal Front End pool or Standard Edition server before you can deploy your Edge Server. Use the following procedure to define the edge topology for a single Edge Server, and then use the procedures in Publish Your Topology and Export Your Topology and Copy It to External Media for Edge Installation to publish the topology and make it available to your Edge Server. To successfully publish, enable, or disable a topology when adding or removing a server role, you must be logged in as a user who is a member of the RTCUniversalServerAdmins and Domain Admins groups. You can also grant the administrator rights and permissions required for adding server roles to a user account. For details, see Delegate Setup Permissions in the Standard Edition server or Enterprise Edition server Deployment documentation. For other configuration changes, only membership in the RTCUniversalServerAdmins group is required. If you defined your edge topology when you defined and published your internal topology, and no changes are required to the edge topology that you previously defined, you do not need to do define it and publish it again. Use the following procedure only if you need to make changes to your edge topology. You must make the previously defined and published topology available to your Edge Servers, which you do by using the procedure in Export Your Topology and Copy It to External Media for Edge Installation. Important: You cannot run Topology Builder from an Edge Server. You must run it from your Front End Server or Standard Edition servers. To define the topology for a single Edge Server 1. Start Topology Builder: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Topology Builder. 2. In the console tree, expand the site in which you want to deploy an Edge Server. 3. Right-click Edge pools, and then click New Edge Pool. 4. In Define the New Edge Pool, click Next. 5. In Define the Edge pool FQDN, do the following:
20
In Pool FQDN, type the fully qualified domain name (FQDN) of the internal interface for the Edge Server. 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 an 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 AZ, az, 09, 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 (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. Click Single computer pool, and then click Next. 6. In Select features, do the following: If you plan to use a single FQDN and IP address for the SIP Access service, Lync Server Web Conferencing service, and A/V Edge services, select the Use a single FQDN & IP Address check box. If you plan to enable federation select the Enable federation (port 5061) check box. Note: You can select this option, but only one Edge pool or Edge Server in your organization can be published externally for federation. All access by federated users, including public instant messaging (IM) users, go through the same Edge pool or single Edge Server. For example, if your deployment includes an Edge pool or single Edge Server deployed in New York and one deployed in London and you enable federation support on the New York Edge pool or single Edge Server, signal traffic for federated users will go through the New York Edge pool or single Edge Server. This is true even for communications with London users, although a London internal user calling a London federated user uses the London pool or Edge Server for A/V traffic. If you plan to use network address translation (NAT) for your public facing IP addresses, select the The external IP address of the Edge pool is translated by NAT check box. 7. In External FQDNs, do the following: If in Select features you chose to use a single FQDN and IP address for the SIP access, Web Conferencing service, and A/V Edge service, type the external FQDN in SIP Access. Note: If you choose this option, you must specify a different port number for each of
21
the edge services (recommended port settings: 5061 for Access Edge service, 444 for Web Conferencing Edge service, and 443 for A/V Edge service). Selecting this option can help prevent potential connectivity issues, and simplify the configuration because you can then use the same port number (for example, 443) for all three services. If in Select features you did not chose to use a single FQDN and IP Address, type the External FQDNs for SIP Access, Web Conferencing and Audio Video, keeping the default ports. 8. Click Next. 9. In Define the Internal IP address, type the IP address of your Edge Server in Internal IP address, and then click Next. 10. In Define the External IP address, do the following: If you chose to use a single FQDN and IP Address for the SIP access, Web Conferencing service, and A/V Edge service, type the external IP address of the Edge Server in SIP Access, and then, click Next. If you did not chose to use a single FQDN and IP Address for the SIP access, Web Conferencing service, and A/V Edge service, type the external IP addresses of the Edge Server in SIP Access, Web Conferencing, and A/V Conferencing, and then click Next. 11. If you chose to use NAT, a dialog box appears. In Public IP address, type the public IP address to be translated by NAT, and then click Next. Note: This should be the external IP address of the A/V Edge service. 12. In Define the next hop, in Next hop pool, select the name of the internal pool, which can be either a Front End pool or a Standard Edition pool. Or, if your deployment includes a Director, type the name of the Director. Then, click Next. 13. In Associate Front End pools, specify one or more internal pools, which can include Front End pools and Standard Edition servers, to be associated with this Edge Server, by selecting the names of the internal pools that are to use this Edge Server for communication with supported external users. Note: Only one load-balanced Edge pool or single Edge Server can be associated with each internal pool for A/V traffic. If you already have an internal pool associated with an Edge pool or Edge Server, a warning appears indicating that the internal pool is already associated an Edge pool or Edge Server. If you select a pool that is already associated with another Edge Server, it will change the association. 14. Click Finish. 15. Publish your topology.
22
Define the Topology for a DNS Load Balanced Edge Pool You must use Topology Builder to build your internal and edge topology and you must set up at least one internal Front End pool or Standard Edition server before you can deploy any Edge Servers. Use the following procedure to define your edge topology for a load-balanced Edge pool, and then use the procedures in Publish Your Topology and Export Your Topology and Copy It to External Media for Edge Installation to publish the topology and make it available to Edge Servers. Note: 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. To successfully publish, enable, or disable a topology when adding or removing a server role, you must be logged in as a user who is a member of the RTCUniversalServerAdmins and Domain Admins groups. You can also grant the administrator rights and permissions required for adding server roles to a user account. For details, see Delegate Setup Permissions in the Standard Edition server or Enterprise Edition server Deployment documentation. For other configuration changes, only membership in the RTCUniversalServerAdmins group is required. If you defined your edge topology when you defined and published your internal topology, and no changes are required to the edge topology that you previously defined, you do not need to define it and publish it again. Use the following procedure only if you need to make changes to your edge topology. You must make the previously defined and published topology available to your Edge Servers, which you do by using the procedure in Export Your Topology and Copy It to External Media for Edge Installation. Important: You cannot run Topology Builder from an Edge Server. You must run it from your Front End pool or Standard Edition servers. To define the topology for a DNS load balanced Edge Server pool 1. Start Topology Builder: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Topology Builder. 2. In the console tree, expand the site in which you want to deploy Edge Servers. 3. Right-click Edge Pools, and then click New Edge Pool. 4. In Define the New Edge Pool, click Next. 5. In Define the Edge pool FQDN, do the following: In Pool FQDN, type the fully qualified domain name (FQDN) for the internal connection of the Edge pool. Important: Use only standard characters (including AZ, az, 09, 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 (when the FQDN must be assigned to the SN in the certificate). For details about adding a DNS suffix to
23
a computer name, see Configure DNS Records for Edge Support. Click Multiple computer pool, and then click Next. 6. In Select features, do the following: If you plan to use a single FQDN and IP address for the SIP access, Lync Server Web Conferencing service and A/V Edge services, select the Use a single FQDN & IP Address check box. Important: Using a single FQDN and IP address will reduce the number of IP addresses required, but will require a distinct and separate port for each interface, by default 5061 for the Access Edge, and 444 for the Web Conferencing Edge. External users who are behind a proxy or firewall that does not allow communication over ports such as port 5061 and 444 may not be able to connect to your deployment. It is recommended to use the multiple FQDN and IP address selection with port 443 assigned to each interface. If you plan to enable federation, select the Enable federation (port 5061) check box. Note: You can select this option, but only one Edge pool or Edge Server in your organization can be published externally for federation. All access by federated users, including public instant messaging (IM) users, go through the same Edge pool or single Edge Server. For instance, if your deployment includes an Edge pool or single Edge Server deployed in New York and one deployed in London and you enable federation support on the New York Edge pool or single Edge Server, signal traffic for federated users will go through the New York Edge pool or single Edge Server. This is true even for communications with London users, although a London internal user calling a London federated user uses the London pool or Edge Server for A/V traffic. If you plan to use network address translation (NAT) for your public facing IP addresses, select the The external IP address of the Edge pool is translated by NAT check box. 7. Click Next. 8. In External FQDNs, do the following: If in Select features you did not chose to use a single FQDN and IP Address, type the FQDN that you have chosen for your public facing side of the edge pool for in SIP Access. In Web Conferencing, type the FQDN you have chosen for your public facing side of the Edge pool. In Audio/Video, type the FQDN you have chosen for your public facing side of the Edge pool. Use the default ports. (By default, port 443) This is the recommended selection. Note: These will be the publicly facing virtual IP (VIP) FQDNs for the pool. By selecting this option, you can help prevent potential connectivity issues and
24
simplify the configuration because you can then use the same port number for all three services. If in Select features you chose to use a single FQDN and IP Address for the SIP access, Web Conferencing service, and A/V Edge service, type the external FQDN in SIP Access. Note: If you choose this option, you must specify a different port number for each of the Edge services (recommended port settings: 5061 for Access Edge service, 444 for Web Conferencing Edge service, and 443 for A/V Edge service). 9. Click Next. 10. In Define the computers in this pool, click Add. 11. In Internal FQDN and IP address, do the following: In Internal IP address, type the IP address of the first Edge Server that you want to create in this pool. In Internal FQDN, type the FQDN of the first Edge Server that you want to create in this pool. Note: Use only standard characters (including AZ, az, 09, and hyphens) when assigning FQDNs of your Lync Servers, Edge Servers, pools, and arrays. Do not use Unicode characters or underscores. Nonstandard characters in an FQDN are often not supported by external DNS and public CAs (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. 12. Click Next. 13. In Define the external IP addresses, do the following: If you chose to use a single FQDN and IP Address for the SIP access, Web Conferencing service, and A/V Edge service, type the external IP address of the Edge Server in SIP Access. If you did not chose to use a single FQDN and IP Address for the SIP access, Web Conferencing service, and A/V Conferencing service, type the IP address that you have chosen for your public facing side of this Edge pool server for SIP Access. In Web Conferencing, type the IP address that you have chosen for your public facing side of this Edge pool server. In A/V Conferencing, type the IP address you have chosen for your public facing side of this Edge pool server. 14. Click Finish. Note: You will now see the first Edge Server you created in your pool in the Define the computers in this pool dialog box. 15. In Define the computers in this pool, click Add, and then repeat steps 11 through 14
25
for the second Edge Server that you want to add to you Edge pool. 16. After you repeat steps 11 through 14, click Next in Define the computers in this pool. Note: At this point, you can see both of the Edge Servers in your pool. 17. If you chose to use NAT, a dialog box appears. In Public IP address, type the public IP address to be translated by NAT, and then click Next. Note: This should be the external IP Address of the A/V Edge. 18. In Define the next hop, in the Next hop pool list, select the name of the internal pool, which can be either a Front End pool or a Standard Edition pool. Or, if your deployment includes a Director, select the name of the Director. Then, click Next. 19. In Associate Front End pools, specify one or more internal pools, which can include Front End pools and Standard Edition servers, to be associated with this Edge Server, by selecting the names of the internal pool(s) that is to use this Edge Server for communication with supported external users. Note: Only one load-balanced Edge pool or single Edge Server can be associated with each internal pool for A/V traffic. If you already have an internal pool associated with an Edge pool or Edge Server, a warning appears indicating that the internal pool is already associated an Edge pool or Edge Server. If you select a pool that is already associated with another Edge Server, it will change the association. 20. Click Finish. 21. Publish your topology.
Define the Topology for a Hardware Load Balanced Edge Pool You must use Topology Builder to build your topology and you must set up at least one internal Front End pool or Standard Edition server before you can deploy your Edge Server. Use the following procedure to define the edge topology for a hardware load-balanced Edge pool, and then use the procedures in Publish Your Topology and Export Your Topology and Copy It to External Media for Edge Installation to publish the topology and make it available to your Edge Server. Note: 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. To successfully publish, enable, or disable a topology when adding or removing a server role, you must be logged on as a user who is a member of the RTCUniversalServerAdmins and Domain Admins groups. You can also grant the administrator rights and permissions required for adding server roles to a user account. For details, see Delegate Setup Permissions in the Standard Edition
26
server or Enterprise Edition server Deployment documentation. For other configuration changes, only membership in the RTCUniversalServerAdmins group is required. If you defined your edge topology when you defined and published your internal topology, and no changes are required to the edge topology that you previously defined, you do not need to define it and publish it again. Use the following procedure only if you need to make changes to your edge topology. You must make the previously defined and published topology available to your Edge Servers, which you do by using the procedure in Export Your Topology and Copy It to External Media for Edge Installation. Important: You cannot run Topology Builder from an Edge Server. You must run it from your Front End Server or Standard Edition servers. To define the topology for a hardware load balanced Edge Server pool 1. Start Topology Builder: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Topology Builder. 2. In the console tree, expand the site in which you want to deploy Edge Servers. 3. Right-click Edge Pools, and then select New Edge Pool. 4. In Define the New Edge Pool, click Next. 5. In Define the Edge pool FQDN, do the following: In FQDN, type the fully qualified domain name (FQDN) you have chosen for the internal side of the Edge pool. Important: Use only standard characters (including AZ, az, 09, 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 (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. Click Multiple computer pool, and then Next. 6. In Select features do the following: If you plan to use a single FQDN and IP address for the SIP access service, Lync Server Web Conferencing service, and A/V Edge service, select the Use a single FQDN & IP Address check box. Important: Using a single FQDN and IP address will reduce the number of IP addresses required, but will require a distinct and separate port for each interface, by default 5061 for the Access Edge, and 444 for the Web Conferencing Edge. External users who are behind a proxy or firewall that does not allow communication over ports such as port 5061 and 444 may not be able to connect to your deployment. It is recommended to use the multiple FQDN and
27
IP address selection with port 443 assigned to each interface. If you plan to enable federation, select the Enable federation (port 5061) check box. Note: You can select this option, but only one Edge pool or Edge Server in your organization may be published externally for federation. All access by federated users, including public instant messaging (IM) users, go through the same Edge pool or single Edge Server. For instance, if your deployment includes an Edge pool or single Edge Server deployed in New York and one deployed in London and you enable federation support on the New York Edge pool or single Edge Server, signal traffic for federated users will go through the New York Edge pool or single Edge Server. This is true even for communications with London users, although a London internal user calling a London federated user uses the London pool or Edge Server for A/V traffic. Important: Do Not select the The external IP address of the Edge pool is translated by NAT check box. Network address translation (NAT) is not supported when you are using hardware load balancing. 7. Click Next. 8. In External FQDNs, do the following: If in Select features you did not chose to use a single FQDN and IP address, type the FQDN that you have chosen for your public facing side of the edge pool for in SIP Access. In Web Conferencing, type the FQDN you have chosen for your public facing side of the Edge pool. In Audio/Video, type the FQDN you have chosen for your public facing side of the Edge pool. Use the default ports. (By default, port 443) This is the recommended selection. Note: These will be the publicly facing virtual IP (VIP) FQDNs for the pool. By selecting this option, you can help prevent potential connectivity issues and simplify the configuration because you can then use the same port number for all three services. If in Select features you chose to use a single FQDN and IP address for the SIP access, Web Conferencing service, and A/V Edge service, type the external FQDN in SIP Access. Note: If you choose to select this option, you must specify a different port number for each of the Edge services (recommended port settings: 5061 for Access Edge service, 444 for Web Conferencing Edge service, and 443 for A/V Edge service). 9. Click Next.
28
10. In Define the computers in this pool, click Add. 11. In Internal FQDN and IP address, do the following: In Internal IP address, type the IP address of the first Edge Server that you want to create in this pool. In Internal FQDN, type the FQDN of the first Edge Server that you want to create in this pool. Note: Use only standard characters (including AZ, az, 09, and hyphens) when assigning FQDNs of your Lync Servers, Edge Servers, pools, and arrays. Do not use Unicode characters or underscores. Nonstandard characters in an FQDN are often not supported by external DNS and public CAs (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. 12. Click Next. 13. In Define the external IP addresses, do the following: If you chose to use a single FQDN and IP Address for the SIP access, Web Conferencing service, and A/V Edge service, type the external IP address of the Edge Server in SIP Access. If you did not chose to use a single FQDN and IP Address for the SIP access, Web Conferencing service, and A/V Conferencing service, type the IP address that you have chosen for your public facing side of this Edge pool server for SIP Access. In Web Conferencing, type the IP address that you have chosen for your public facing side of this Edge pool server. In A/V Conferencing, type the IP address you have chosen for your public facing side of this Edge pool server. 14. Click Finish. Note: You will now see the first Edge Server you created in your pool in the Define the computers in this pool dialog box. 15. In Define the computers in this pool, click Add, and then repeat steps 11 through 14 for the second Edge Server that you want to add to your Edge pool. 16. After you repeat steps 11 through 14, click Next in Define the computers in this pool. Note: At this point, you can see both of the Edge Servers in your pool. 17. In Define the next hop, in the Next hop pool list, select the name of the internal pool, which can be either a Front End pool or a Standard Edition pool. Or, if your deployment includes a Director, select the name of the Director. Then, click Next. 18. In Associate Front End pools, specify one or more internal pools, which can include Front End pools and Standard Edition servers, to be associated with this Edge Server, by selecting the names of the internal pool(s) that is to use this Edge Server for
29
communication with supported external users. Note: Only one load-balanced Edge pool or single Edge Server can be associated with each internal pool for A/V traffic. If you already have an internal pool associated with an Edge pool or Edge Server, a warning appears indicating that the internal pool is already associated an Edge pool or Edge Server. If you select a pool that is already associated with another Edge Server, it will change the association. 19. Click Finish. 20. Publish your topology.
Publish Your Topology

Each time you use Topology Builder to build your topology, you must publish the topology to a database in the Central Management store so that the data can be used to deploy Lync Server 2010. Use the following procedure to publish your topology. To publish the topology 1. Start Topology Builder: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Topology Builder. 2. In Topology Builder, in the console tree, right-click Lync Server 2010, and then click Publish Topology. 3. On the Welcome page of the wizard, click Next. 4. On the Topology Builder found a CMS store page, click Next. 5. On the Create other databases page, click Next. 6. When the status indicates that database creation succeeded, do the following: To view the log, click View log. To close the wizard, click Finish.
Setting Up the Director

If you enable access for external users by deploying Edge Servers, you should also deploy a Director. A Director is a server running Microsoft Lync Server 2010 that authenticates user requests, but does not home any user accounts. The primary steps required to setting up a Director or Director pool are similar to that of setting up an Enterprise Edition Front End pool or Standard Edition server. After you have defined your Director(s) in Topology Builder, you need to perform the steps in this section.
In This Section
Install the Local Configuration Store
30
Install Lync Server 2010 on the Director Configure Certificates for the Director Start Services on the Director Test the Director Configure Automatic Client Sign-In To Use the Director
Install the Local Configuration Store

To successfully complete this procedure, you should be logged on to the server minimally as a local administrator and a domain user who has membership in at least the RTCUniversalReadOnlyAdmin group. The first step of the Lync Server Deployment Wizard is to install the Local Configuration store. The Local Configuration store is SQL Server Express, which installs a local database that will retain a read-only copy of the Central Management store. The Central Management store is added to the existing SQL Server database installed on the Standard Edition server SQL Server Express-based database. Important: If this is the first time that you have run Microsoft Lync Server 2010 setup on this server, you will be prompted for a drive and path to install Lync Server 2010. If your organization requires that you locate Internet Information Services (IIS) and all Web Services on a drive other than the system drive, you can change the installation location path for the Lync Server files in the Setup dialog box. If you install the Setup files to this path, including OCSCore.msi, the rest of the Lync Server 2010 files will be deployed to this drive as well. To install the Local Configuration store 1. From the installation media, browse to \setup\amd64\Setup.exe, and then click OK. 2. If you are prompted to install the Microsoft Visual C++ 2008 distributable, click Yes. 3. On the Lync Server 2010 Installation Location page, click OK. 4. On the End User License Agreement page, review the license terms, select I accept the terms in the license agreement, and then click OK. This step is required before you can continue. 5. On the Deployment Wizard page, click Install or Update Lync Server System. 6. On the Lync Server 2010 page, next to Step1: Install Local Configuration Store, click Run. 7. On the Local Server Configuration page, ensure that the Retrieve configuration automatically from the Central Management Store option is selected, and then click Next. 8. When the local server configuration installation is complete, click Finish.
31
Install Lync Server 2010 on the Director

Use the following steps to install the Lync Server 2010 components on a Director. To install Lync Server components on a Director 1. In the Lync Server Deployment Wizard, on the Lync Server 2010 page, next to Step 2: Setup or Remove Lync Server Components, click Run. 2. On the Setup Lync Server components page, click Next to set up components as defined in the published topology. 3. When Lync Server components setup has completed, click Finish.
Configure Certificates for the Director

Important: When you run the Certificate Wizard, ensure that you are logged in using an account that is a member of a group that has been assigned the appropriate permissions for the type of certificate template you will use. By default, a Lync Server certificate request will use the Web Server certificate template. If you use an account that is a member of the RTCUniversalServerAdmins group to request a certificate using this template, verify that the group has been assigned the Enroll permissions required to use that template. Each Director requires a default certificate, a web internal certificate, and a web external certificate. For details about the certificate requirements for Directors, see Certificate Requirements for Internal Servers in the Planning documentation. Use the following procedure to configure Director certificates. Repeat the procedure for each Director. The steps of this procedure describe how to configure a certificate from an Internal Enterprise Root certification authority (CA) deployed by your organization and with offline request processing. For details about obtaining certificates from an external CA, contact your support team. To configure certificates for the Director or Director pool 1. In the Lync Server Deployment Wizard, next to Step 3: Request, Install or Assign Certificates, click Run. 2. On the Certificate Wizard page, click Request. 3. On the Certificate Request page, click Next. 4. On the Delayed or Immediate Requests page, accept the default Send the request immediately option, and then click Next. 5. On the Choose a Certification Authority (CA) page, click the internal Windows certification authority that you want to use, and then click Next. 6. On the Certification Authority Account page, specify alternate credentials to be used if the account you are logged on with does not have sufficient authority to request the certificate, and then click Next. 7. On the Specify Alternate Certificate Template page, click Next.
32
8. On the Name and Security Settings page, you can specify a Friendly Name, accept the 2048-bit key length, and then click Next. 9. On the Organization Information page, optionally specify organization information, and then click Next. 10. On the Geographical Information page, optionally specify geographical information, and then click Next. 11. On the Subject Name / Subject Alternative Names page, click Next. Note: The subject alternative name list should contain the name of the computer on which you are installing the Director (if a single Director) or the Director pool name, and the simple URL names configured for the organization. 12. On the SIP Domain setting page, select the Configured SIP Domains for all domains that you want the Director to handle, and then click Next. 13. On the Configure Additional Subject Alternative Names page, add any additional required subject alternative names, and then click Next. 14. On the Certificate Request Summary page, click Next. 15. On the Executing Commands page, click Next after the commands have finished running. 16. On the Online Certificate Request Status page, click Finish. 17. On the Certificate Assignment page, click Next. Note: if you want to view the certificate, double-click the certificate in the list. 18. On the Certificate Assignment Summary page, click Next. 19. On the Executing Commands page, click Finish after the commands have finished running. 20. On the Certificate Wizard page, click Close.
Start Services on the Director

After you install the Local Configuration Store, install the Lync Server Components, and configure certificates on a Director, you must start the Lync Server services on the server. You can use the following procedure to start services on each Director in your deployment. To start services on a Director 1. In the Lync Server Deployment Wizard, on the Lync Server 2010 page, click the Run button next to Step 4: Start Services. 2. On the Start Services page, click Next to start the Lync Server services on the server. 3. On the Executing Commands page, after all services have started successfully, click Finish.
33
4. Below Step 4: Start Services, click Services Status (Optional). 5. In the Services Microsoft Management Console (MMC) on the server, verify that all of the Lync Server 2010 services are running.
Test the Director

At this stage, you have a Director or Director pool configured, but your Domain Name System (DNS) SRV entries still point clients to log on by using a pool or Standard Edition server. Before changing the DNS record to make Microsoft Lync 2010 clients log on automatically by using the Director, test a client by manually pointing it to the Director. To test the deployment 1. Log on to the computer on which you have the Lync Server Control Panel installed with a domain account that is part of the CSAdministrator group. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the navigation pane, click Topology, and in the Status column confirm that there is a green server with an arrow (that is, ) for your Director or Director pool. 4. Connect two client computers that have the Lync Server 2010 client installed and log on with a different user account enabled for Lync Server 2010 to each computer. 5. On one of the client computers, click the Options menu, select the Personal settings group, click Advanced, click Manual Configuration, and then set the Internal Server name or IP address to the fully qualified domain name (FQDN) of the new Director or Director pool. 6. Log on to both clients and verify that the client logging on by using the Director is able to log on successfully, see the presence status of the other user, and that they can exchange instant messages.
Configure Automatic Client Sign-In To Use the Director

When you deploy a Microsoft Lync Server 2010, Director or a pool of Directors, we recommend that you use Automatic Client Sign-In as a best practice. For details about how to configure DNS servers for automatic client sign-in, see DNS Requirements for Automatic Client Sign-In in the Planning documentation. If you have already deployed Automatic Client Sign-In, see the following sections to configure it on your Director(s).
34
Single Director Instance If you already have Automatic Client Sign-In deployed and it is pointing to a Standard Edition server in an Enterprise Edition Front End pool, you need to change the DNS SRV record to point to the Director. Director Pool If you already have Automatic Client Sign-In deployed and it is pointing to a Standard Edition server in an Enterprise Edition Front End pool, you need to change the DNS SRV record to point to the Director pool.
Setting Up Edge Servers

The primary tasks required to set up Edge Servers are the same for installing a single Edge Server or a load-balanced pool of Edge Servers, except that a pool of hardware load balanced Edge Servers requires deployment of the load balancers and additional steps for replicating the set up on multiple Edge Servers.
In This Section
Set Up Network Interfaces for Edge Servers Install Prerequisite Software on Edge Servers Export Your Topology and Copy It to External Media for Edge Installation Install Edge Servers Set Up Edge Certificates Start Edge Servers Set Up Reverse Proxy Servers
Set Up Network Interfaces for Edge Servers

Each Edge Server is a multihomed computer with external and internal facing interfaces. The adapter Domain Name System (DNS) settings depend on whether there are DNS servers in the perimeter network. If DNS servers exist in the perimeter, they must have a zone containing one or more DNS A records for the next hop server or pool (that is, either a Director or a designated Front End pool), and for external queries they refer name lookups to other public DNS servers. If no DNS servers exist in the perimeter, the Edge Server(s) use external DNS servers to resolve Internet name lookups, and each Edge Server uses a HOST to resolve the next hop server names to IP addresses. noteDSDOC112778PADS Security Note
For security reasons, we recommend that you do not have your Edge Servers access a DNS server located in the internal network. To configure interfaces with DNS servers in the perimeter network 1. Install two network adapters for each Edge Server, one for the internal-facing interface and one for the external-facing interface.
35
Important: The internal and external subnets must not be routable to each other. 2. On the external interface, configure three static IP addresses on the external perimeter network (also known as DMZ, demilitarized zone, and screened subnet) subnet, and point the default gateway to the internal interface of the external firewall. Configure adapter DNS settings to point to a pair of perimeter DNS servers. Note: It is possible to use as few as one IP address for this interface, but to do this you need to change the port assignments to non-standard values. You determine this when you create the topology in Topology Builder. 3. On the internal interface, configure one static IP address on the internal perimeter network subnet and do not set a default gateway. Configure adapter DNS settings to point to at least one DNS server, preferably a pair of perimeter DNS servers. 4. Create persistent static routes on the internal interface to all internal networks where clients, Lync Server 2010, and Exchange Unified Messaging (UM) servers reside. To configure interfaces without any DNS servers in the perimeter network 1. Install two network adapters for each Edge Server, one for the internal-facing interface and one for the external-facing interface. Important: The internal and external subnets must not be routable to each other. 2. On the external interface, configure three static IP addresses on the external perimeter network subnet, and point the default gateway to the internal interface of the external firewall. Configure adapter DNS settings to point at least one DNS server, preferably to a pair of external DNS servers. Note: It is possible to use as few as one IP address for this interface, but to do this you need to change the port assignments to non-standard values. You determine this when you create the topology in Topology Builder. 3. On the internal interface, configure one static IP address on the internal perimeter network subnet and do not set a default gateway. Leave adapter DNS settings empty. 4. Create persistent static routes on the internal interface to all internal networks where Lync clients or servers running Lync Server 2010 reside. 5. Edit the HOST file on each Edge Server to contain a record for the next hop server or virtual IP (VIP) (the record will be the Director, Standard Edition server, or a Front End pool that was configured as the Edge Server next hop address in Topology Builder). If you are using DNS load balancing, include a line for each member of the next hop pool.
36
Install Prerequisite Software on Edge Servers

You need to deploy prerequisite software on each Edge Server that you deploy prior to installing Lync Server 2010. This includes installing the operating system on a server that meets system requirements. For details about system requirements, including the supported operating systems, see System Requirements for Edge Components.
Export Your Topology and Copy It to External Media for Edge Installation
After you publish your topology, the Lync Server Deployment Wizard needs access to the Central Management store data in order to start the deployment process on the server. In the internal network, the data is accessible directly from the servers, but Edge Servers that are not in the internal domain cannot access the data. To make the topology configuration data available for an Edge Server deployment, you must export the topology data to a file and copy it to external media (for example, a USB drive or a network share that is accessible from the Edge Server) before you run the Lync Server Deployment Wizard on the Edge Server. Use the following procedure to make your topology configuration data available on the Edge Server that you are deploying. Note: After you install Lync Server 2010 on an Edge Server, you manage the Edge Server using the administrative tools in the internal network, which automatically replicate configuration to any Edge Servers in your deployment. The only exception is assigning and installing certificates, as well as stopping and starting services, which must be done on the Edge Server. To make your topology data available on an Edge Server by using Lync Server Management Shell 1. Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell. 2. In the Lync Server Management Shell, run the following cmdlet: Export-CsConfiguration -FileName <ConfigurationFilePath.zip> 3. Copy the exported file to external media (for example, a USB drive or a network share that is accessible from the Edge Server during deployment).
Install Edge Servers

You install Lync Server 2010 on Edge Servers by using Lync Server Deployment Wizard. By running the Deployment Wizard on each Edge Server, you can complete most of the tasks required to set up the Edge Server. In order to deploy Lync Server 2010 on an Edge Server, you must have already run Topology Builder to define and publish your Edge Server topology, and exported it to media that is accessible from the Edge Server. For details, see Topologies for External User Access and Export Your Topology and Copy It to External Media for Edge Installation. After using the Deployment Wizard to install each Edge Server, install and assign the required certificates, and start the required services, you can complete the setup by using the information in Configuring Support for External User Access to enable and configure external user access and the
37
information in Verifying Your Edge Deployment to validate the setup, including server and client connectivity. To install an Edge Server 1. Log on to the computer on which you want to install your Edge Server as a member of the local Administrators group or an account with equivalent user rights and permissions. 2. Ensure that the topology configuration file you created using Topology Builder, and then exported and copied to external media, is available on the Edge Server (for example, on the Edge Server, attach the USB drive onto which you copied the topology configuration file, or verify access to the network share where you copied the file). 3. Start the Deployment Wizard. Note: If you get a message saying that you need to install Microsoft Visual C++ Redistributable, click Yes. In the next dialog box, you can accept the default Installation Location or click the Browse to select an alternate location, and then click Install. In the next dialog box, select the I accept the terms in the license agreement check box, and then click OK. 4. In the Deployment Wizard, click Install or Update Lync Server System. 5. After the wizard determines the deployment state, for Step 1. Install Local Configuration Store, click Run and then do the following: In the Configure Local Replica of Central Management Store dialog box, click Import from a file (Recommended for Edge Servers), go to the location of the exported topology configuration file, select the .zip file, click Open, and then click Next. The Deployment Wizard reads the configuration information from the configuration file and writes the XML configuration file to the local computer. After the Executing Commands process is finished, click Finish. 6. In the Deployment Wizard, click Step 2: SetUp or Remove Lync Server Components to install the Lync Server edge components specified in the XML configuration file that is stored on the local computer. 7. After completing the installation, use the information in Set Up Edge Certificates to install and assign the required certificates before you start services.
Set Up Edge Certificates

When you install an Edge Server, you need to request, install, and assign the required certificates for the internal and external interfaces. In This Section Certificate Requirements for External User Access Set Up Certificates for the Internal Edge Interface Set Up Certificates for the External Edge Interface
38
Set Up Certificates for the Reverse Proxy
Certificate Requirements for External User Access Microsoft Lync Server 2010 communications software supports the use of a single public certificate for access and web conferencing Edge external interfaces, plus the A/V Authentication service. The Edge internal interface typically uses a private certificate issued by an internal certification authority (CA), but can also use a public certificate, provided that it is from a trusted public CA. The reverse proxy in your deployment uses a public certificate and encrypts the communication from the reverse proxy to clients and the reverse proxy to internal servers by using HTTP (that is, Transport Layer Security over HTTP). Following are the requirements for the public certificate used for access and web conferencing Edge external interfaces, and the A/V authentication service: The certificate must be issued by an approved public CA that supports subject alternative name. For details, see Microsoft Knowledge Base article 929395, "Unified Communications Certificate Partners for Exchange Server and for Communications Server," at http://go.microsoft.com/fwlink/?LinkId=202834. If the certificate will be used on an Edge pool, it must be created as exportable, with the same certificate used on each Edge Server in the Edge pool. The exportable private key requirement is for the purposes of the A/V Authentication service, which must use the same private key across all Edge Servers in the pool. The subject name of the certificate is the access Edge external interface fully qualified domain name (FQDN) or hardware load balancer VIP (for example, access.contoso.com). Note: For Lync Server 2010, this is no longer a requirement, but it is still recommended for compatibility with Office Communications Server. The subject alternative name list contains the FQDNs of the following: The access Edge external interface or hardware load balancer VIP (for example, access.contoso.com). Note: Even though the certificate subject name is equal to the access Edge FQDN, the subject alternative name must also contain the access Edge FQDN because Transport Layer Security (TLS) ignores the subject name and uses the subject alternative name entries for validation. The web conferencing Edge external interface or hardware load balancer VIP (for example, webcon.contoso.com). If you are using client auto-configuration or federation, also include any SIP domain FQDNs used within your company (for example, sip.contoso.com, sip.fabrikam.com). The A/V authentication service does not use the subject name or the subject alternative names entries. Note: The order of the FQDNs in the subject alternative names list does not matter.
39
If you are deploying multiple, load-balanced Edge Servers at a site, the A/V authentication service certificate that is installed on each Edge Server must be from the same CA and must use the same private key. Note that the certificate's private key must be exportable, regardless of whether it is used on one Edge Server or many Edge Servers. It must also be exportable if you request the certificate from any computer other than the Edge Server. Because the A/V authentication service does not use the subject name or subject alternative name, you can reuse the access Edge certificate as long as the subject name and subject alternative name requirements are met for the access Edge and the web conferencing Edge and the certificates private key is exportable. Requirements for the private (or public) certificate used for the Edge internal interface are as follows: The certificate can be issued by an internal CA or an approved public certificate CA. The subject name of the certificate is typically the Edge internal interface FQDN or hardware load balancer VIP (for example, lsedge.contoso.com). However, you can use a wildcard certificate on the Edge internal. No subject alternative name list is required. External user access to meeting content for meetings External user access to expand and display members of distribution groups External user access to downloadable files from the Address Book Service External user access to the Lync Web App client External user access to the Dial-in Conferencing Settings web page External user access to the Location Information Service External device access to the Device Update Service and obtain updates The reverse proxy in your deployment services requests for:
The reverse proxy publishes the internal server Web Components URLs. The Web Components URLs are defined on the Director, Front End Server or Front End pool as the External web services in Topology Builder. Wildcard entries are supported in the subject alternative name field of the certificate assigned to the reverse proxy. For details about how to configure the certificate request for the reverse proxy, see Request and Configure a Certificate for Your Reverse HTTP Proxy. See Also Wildcard Certificate Support Set Up Certificates for the Internal Edge Interface Important: When you run the Certificate Wizard, ensure that you are logged in using an account that is a member of a group that has been assigned the appropriate permissions for the type of certificate template you will use. By default, a Lync Server certificate request will use the Web Server certificate template. If you use an account that is a member of the RTCUniversalServerAdmins group to request a certificate using this template, verify that the group has been assigned the Enroll permissions required to use that template.
40
A single certificate is required on the internal interface of each Edge Server. Certificates for the internal interface can be issued by an internal enterprise certification authority (CA) or a public CA. If your organization has an internal CA deployed you can save on the expense of using public certificates by using the internal CA to issue the certificate for the internal interface. You can use an internal Windows Server 2008 CA or Windows Server 2008 R2 CA to create these certificates. For details about this and other certificate requirements, see Certificate Requirements for External User Access. To set up certificates on the internal edge interface at a site, use the procedures in this section to do the following: 1. Download the CA certification chain for the internal interface to each Edge Server. 2. Import the CA certification chain for the internal interface, on each Edge Server. 3. Create the certificate request for the internal interface, on one Edge Server, called the first Edge Server. 4. Import the certificate for the internal interface on the first Edge Server. 5. Import the certificate on the other Edge Servers at this site (or deployed behind this load balancer). 6. Assign the certificate for the internal interface of every Edge Server. If you have more than one site with Edge Servers (that is, a multiple-site edge topology), or separate sets of Edge Servers deployed behind different load balancers, you need to follow these steps for each site that has Edge Servers, and for each set of Edge Servers deployed behind a different load balancer. Notes: The steps of the procedures in this section are based on using a Windows Server 2008 Enterprise CA or a Windows Server 2008 R2 CA to create a certificate for each Edge Server. For step-by-step guidance for any other CA, consult the documentation for that CA. By default, all authenticated users have the appropriate user rights to request certificates. The procedures in this section are based on creating certificate requests on the Edge Server as part of the Edge Server deployment process. It is possible to create certificate requests using the Front End Server. You can do this to complete the certificate request early in the planning and deployment process, before you start deployment of the Edge Servers. To do this, you must ensure that the certificate you request is exportable. The procedures in this section describe using a .cer file for the certificate. If you use a different type of file, modify these procedures as appropriate. To download the CA certification chain for the internal interface 1. Log on to an Lync Server 2010 server in the internal network (that is, not the Edge Server) as a member of the Administrators group. 2. Run the following command at a command prompt by clicking Start, clicking Run, and then typing the following: https://<name of your Issuing CA Server>/certsrv Note:
41
If you are using a Windows Server 2008 or Windows Server 2008 R2 enterprise CA, you must use https, not http. 3. On the issuing CAs certsrv web page, under Select a task, click Download a CA certificate, certificate chain, or CRL. 4. Under Download a CA Certificate, Certificate Chain, or CRL, click Download CA certificate chain. 5. In the File Download dialog box, click Save. 6. Save the .p7b file to the hard disk drive on the server, and then copy it to a folder on each Edge Server. Note: The .p7b file contains all of the certificates that are in the certification path. To view the certification path, open the server certificate and click the certification path. To import the CA certification chain for the internal interface 1. On each Edge Server, open the Microsoft Management Console (MMC) by clicking Start, clicking Run, typing mmc in the Open box, and then clicking OK. 2. On the File menu, click Add/Remove Snap-in, and then click Add. 3. In the Add Standalone Snap-ins box, click Certificates, and then click Add. 4. In the Certificate snap-in dialog box, click Computer account, and then click Next. 5. In the Select Computer dialog box, ensure that the Local computer: (the computer this console is running on) check box is selected, and then click Finish. 6. Click Close, and then click OK. 7. In the console tree, expand Certificates (Local Computer), right-click Trusted Root Certification Authorities, point to All Tasks, and then click Import. 8. In the wizard, in File to Import, specify the file name of the certificate (that is, the name of that you specified when you downloaded the CA certification chain for the internal interface in the previous procedure). 9. Repeat this procedure on each Edge Server. To create the certificate request for the internal interface 1. On one of the Edge Servers, start the Deployment Wizard, and next to Step 3: Request, Install, or Assign Certificates, click Run. Notes: If you have multiple Edge Servers in one location in a pool, you can run the Certificate Wizard on any one of the Edge Servers. After you run Step 3 the first time, the button changes to Run again, and a green check mark that indicates successful completion of the task is not displayed until all require certificates have been requested, installed, and assigned. 2. On the Available Certificate Tasks page, click Create a new certificate request.
42
3. On the Certificate Request page, click Next. 4. On the Delayed or Immediate Requests page, click Prepare the request now, but send it later. 5. On the Certificate Request File page, type the full path and file name to which the request is to be saved (for example, c:\cert_internal_edge.cer). 6. On the Specify Alternate Certificate Template page, to use a template other than the default WebServer template, select the Use alternative certificate template for the selected Certificate Authority check box. 7. On the Name and Security Settings page, do the following: In Friendly name, type a display name for the certificate (for example, Internal Edge). In Bit length, specify the bit length (typically, the default of 2048). Note: High bit lengths offer more security, but they have a negative impact on speed. If the certificate needs to be exportable, select the Mark certificate private key as exportable check box. 8. On the Organization Information page, type the name for the organization and the organizational unit (OU) (for example, a division or department). 9. On the Geographical Information page, specify the location information. 10. On the Subject Name/Subject Alternate Names page, the information to be automatically populated by the wizard is displayed. 11. On the Configure Additional Subject Alternate Names page, specify any additional subject alternative names that are required. 12. On the Request Summary page, review the certificate information that is going to be used to generate the request. 13. After the commands complete, do the following: To view the log for the certificate request, click View Log. To complete the certificate request, click Next. To view the generated certificate signing request (CSR) file, click View. To close the wizard, click Finish.
14. On the Certificate Request File page, do the following:
15. Submit this file to your CA (by email or other method supported by your organization for your enterprise CA) and, when you receive the response file, copy the new certificate to this computer so that it is available for import. To import the certificate for the internal interface 1. Log on to the Edge Server on which you created the certificate request as a member of the local Administrators group. 2. In the Deployment Wizard, next to Step 3: Request, Install, or Assign Certificates,
43
click Run again. After you run Step 3 the first time, the button changes to Run again, but a green check mark (indicating successful completion of the task) is not displayed until all require certificates have been requested, installed, and assigned. 3. On the Available Certificate Tasks page, click Import a certificate from a .P7b, .pfx or .cer file. 4. On the Import Certificate page, type the full path and file name of the certificate that you requested and received for the internal interface of this Edge Server (or, click Browse to locate and select the file). 5. If you are importing certificates for other members of the pool a certificate containing a private key, select the Certificate file contains certifcates private key check box and specify the password. To export the certificate with the private key for Edge Servers in a pool 1. Log on as a member of the Administrators group to the same Edge Server on which you imported the certificate. 2. Click Start, click Run, and type MMC. 3. From the MMC console, click File, click Add/Remove Snap-in. 4. From Add or Remove Snap-ins page, click Certificates, click Add. 5. In the Certificates snap-in dialog, select Computer account. Click Next. In Select Computer, select Local computer: (the computer this console is running on). Click Finish. Click OK to complete configuration of the MMC console. 6. Double-click Certificates (Local Computer) to expand the certificate stores. Doubleclick Personal, then double-click Certificates. Important: If there are no certificates in the Certificates Personal store for the local computer, there is no private key associated with the certificate that was imported. Review the request and import steps. If the problem persists, contact your certification authority administrator or provider. 7. In the Certificates Personal store for the local computer, right-click the certificate that you are exporting. Click All Tasks, click Export. 8. In the Certificate Export Wizard, click Next. Select Yes, export the private key. Click Next. Note: If the selection Yes, export the private key is not available, the private key associated with this certificate was not marked for export. You will need to request the certificate again, ensuring that the certificate is marked to allow for the export of the private key before you can continue with the export. Contact your certification authority administrator or provider. 9. On the Export File Formats dialog, select Personal Information Exchange
44
PKCS#12 (.PFX) and then select the following: Include all certificates in the certification path if possible Export all extended properties Warning: When exporting the certificate from an Edge server, do not select Delete the private key if the export is successful. Selecting this option will require that you import the certificate and the private key to this Edge server. Click Next to continue. 10. Type a password for the private key. Re-enter the password to confirm. Click Next. 11. Type a path and file name for the exported certificate, using a file extension of .pfx. The path must either be accessible to all other Edge servers in the pool or available to transport by means of removable media - for example, a USB flash drive. Click Next. 12. Review the summary on the Completing the Certificate Export Wizard dialog. Click Finish. 13. Click OK in the successful export dialog. 14. Import the exported certificate file to the other Edge servers following the steps outlined in the Set Up Certificates for the External Edge Interface procedures. To assign the internal certificate on the Edge Servers 1. On each Edge Server, in the Deployment Wizard, next to Step 3: Request, Install, or Assign Certificates, click Run again. 2. On the Available Certificate Tasks page, click Assign an existing certificate. 3. On the Certificate Assignment page, select Edge Internal in the list. 4. On the Certificate Store page, select the certificate that you imported for the internal edge (from the previous procedure). 5. On the Certificate Assignment Summary page, review your settings, and then click Next to assign the certificates. 6. On the wizard completion page, click Finish. 7. After using this procedure to assign the internal edge certificate, open the Certificate snap-in on each server, expand Certificates (Local computer), expand Personal, click Certificates, and then verify in the details pane that the internal edge certificate is listed. 8. If your deployment includes multiple Edge Servers, repeat this procedure for each Edge Server.
Set Up Certificates for the External Edge Interface Important: When you run the Certificate Wizard, ensure that you are logged in using an account that is a member of a group that has been assigned the appropriate permissions for the type of
45
certificate template you will use. By default, a Lync Server certificate request will use the Web Server certificate template. If you use an account that is a member of the RTCUniversalServerAdmins group to request a certificate using this template, verify that the group has been assigned the Enroll permissions required to use that template. Each Edge Server requires a public certificate on the interface between the perimeter network and the Internet, and the certificates subject alternative name must contain the external names of the Access Edge service and Web Conferencing Edge service fully qualified domain names (FQDNs). For details about this and other certificate requirements, see Certificate Requirements for External User Access. For a list of public certification authorities (CAs) that provide certificates that comply with specific requirements for unified communications certificates and have partnered with Microsoft to ensure they work with the Lync Server Certificate Wizard, see Microsoft Knowledge Base article 929395, "Unified Communications Certificate Partners for Exchange Server and for Communications Server," at http://go.microsoft.com/fwlink/?LinkId=202834. Configuring Certificates on the External Interfaces To set up a certificate on the external edge interface at a site, use the procedures in this section to do the following: Create the certificate request for the external interface of the Edge Server. Submit the request to your public CA. Import the certificate for the external interface of each Edge Server. Assign the certificate for the external interface of each Edge Server.
If your deployment includes multiple Edge Servers, export the certificate along with its private key, and then copy it to the other Edge Servers. Then, for each Edge Server, import it and assign it as previously described. Repeat this procedure for each Edge Server. You can request public certificates directly from a public certification authority (CA) (such as from the website of a public CA). The procedures in this section use the Certificate Wizard for most certificate tasks. If you chose to request a certificate directly from a public CA, then you will need to modify each procedure as appropriate to request, transport, and import the certificate and also to import the certificate chain. When you request a certificate from an External CA, the credentials provided must have rights to request a certificate from that CA. Each CA has a security policy that defines which credentials (that is, specific user and group names) are allowed to request, issue, manage, or read certificates. If you decide to use the Certificates Microsoft Management Console (MMC) to import the certificate chain and certificate, you must import them to the certificate store for the computer. If you import them to the user or service certificate store, the certificate will not be available for assignment in the Lync Server Certificate Wizard. To create the certificate request for the external interface of the Edge Server 1. On the Edge Server, in the Deployment Wizard, next to Step 3: Request, Install, or Assign Certificates, click Run again. Notes:
46
If your organization wants to support public instant messaging (IM) connectivity with AOL, you cannot use the Lync Server Deployment Wizard to request the certificate. Instead, perform the steps in the To create a certificate request for the external interface of the Edge Server to support public IM connectivity with AOL procedure later in this topic. If you have multiple Edge Servers in one location in a pool, you can run the Lync Server Certificate Wizard on any one of the Edge Servers. 2. On the Available Certificate Tasks page, click Create a new certificate request. 3. On the Certificate Request page, click External Edge Certificate. 4. On the Delayed or Immediate Request page, select the Prepare the request now, but send it later check box. 5. On the Certificate Request File page, type the full path and file name of the file to which the request is to be saved (for example, c:\cert_exernal_edge.cer). 6. On the Specify Alternate Certificate Template page, to use a template other than the default WebServer template, select the Use alternative certificate template for the selected certification authority check box. 7. On the Name and Security Settings page, do the following: In Friendly name, type a display name for the certificate. In Bit length, specify the bit length (typically, the default of 2048). Verify that the Mark certificate private key as exportable check box is selected.
8. On the Organization Information page, type the name for the organization and the organizational unit (for example, a division or department). 9. On the Geographical Information page, specify the location information. 10. On the Subject Name/Subject Alternate Names page, the information to be automatically populated by the wizard is displayed. If additional subject alternative names are needed, you specify them in the next two steps. 11. On the SIP Domain Setting on Subject Alternate Names (SANs) page, select the domain check box to add a sip.<sipdomain> entry to the subject alternative names list. 12. On the Configure Additional Subject Alternate Names page, specify any additional subject alternative names that are required. 13. On the Request Summary page, review the certificate information to be used to generate the request. 14. After the commands finish running, do the following: To view the log for the certificate request, click View Log. To complete the certificate request, click Next. To view the generated certificate signing request (CSR) file, click View. To close the wizard, click Finish.
15. On the Certificate Request File page, do the following:
16. Copy the output file to a location where you can submit it to the public CA.
47
To create a certificate request for the external interface of the Edge Server to support public IM connectivity with AOL 1. When the required template is available to the CA, use the following Windows PowerShell cmdlet from at the Edge Server to request the certificate: Request-CsCertificate New -Type AccessEdgeExternal Output C:\ <certfilename.txt or certfilename.csr> ClientEku $true Template <template name> The default certificate name of the template provided in Lync Server 2010 is Web Server. Only specify the <template name> if you need to use a template that is different from the default template. Note: If your organization wants to support public IM connectivity with AOL, you must use Windows PowerShell instead of the Certificate Wizard to request the certificate to be assigned to the external edge for the Access Edge service. This is because the Lync Server 2010 Web Server template that the Certificate Wizard uses to request a certificate does not support client EKU configuration. Before using Windows PowerShell to create the certificate, the CA administrator must create and deploy a new template that supports client EKU. To submit a request to a public certification authority 1. Open the output file. 2. Copy and paste the contents of the Certificate Signing Request (CSR). 3. If prompted, specify the following: Microsoft as the server platform. IIS as the version. Web Server as the usage type. PKCS7 as the response format.
4. When the public CA has verified your information, you will receive an email message containing text required for your certificate. 5. Copy the text from the email message and save the contents in a text file (.txt) on your local computer. To import the certificate for the external interface of the Edge Server 1. Log on as a member of the Administrators group to the same Edge Server on which you created the certificate request. 2. In the Deployment Wizard, on the Deploy Edge Server page, next to Step 3: Request, Install, or Assign Certificates, click Run again. 3. On the Available Certificate Tasks page, click Import a certificate from a .p7b, pfx or .cer file. 4. On the Import Certificate page, click Browse to locate and select the certificate that
48
you requested for the external interface of the Edge Server (or, you can type the full path and file name). If the certificate contains a private key, select Certificate file contains certificates private key and type the password for the private key. Click Next. 5. On Import Certificate Summary page, review the summary and then click Next. 6. On Executing Commands, review the results of the import, click View Log for more information as needed, and then click Finish to complete the certificate import. 7. If you are configuring an Edge Server pool, export the certificate with its private key as outlined in the To export the certificate with the private key for Edge Servers in a pool procedure later in this topic. Copy the exported certificate file to the other Edge Servers, and import it into the computer store on each Edge Server. To export the certificate with the private key for Edge Servers in a pool 1. Log on as a member of the Administrators group to the same Edge Server on which you imported the certificate. 2. Click Start, click Run, and type MMC. 3. In the Microsoft Management Console (MMC) console, click File, and then click Add/Remove Snap-in. 4. In Add or Remove Snap-ins, click Certificates, and then click Add. 5. In the Certificates dialog box, select Computer account, click Next, select Local computer: (the computer this console is running on) in Select Computer, click Finish and then click OK to complete configuration of the MMC console. 6. Double-click Certificates (Local Computer) to expand the certificate stores, doubleclick Personal, and then double-click Certificates. Important: If there are no certificates in the Certificates Personal store for the local computer, there is no private key associated with the certificate that was imported. Review the request and import steps. If the problem persists, contact your certification authority administrator or provider. 7. In the Certificates Personal store for the local computer, right-click the certificate that you are exporting, click All Tasks, and then click Export. 8. In the Certificate Export Wizard, click Next, select Yes, export the private key, and then click Next. Note: If the selection Yes, export the private key is not available, the private key associated with this certificate was not marked for export. You will need to request the certificate again, ensuring that the certificate is marked to allow for the export of the private key before you can continue with the export. Contact your certification authority administrator or provider. 9. On the Export File Formats dialog, select Personal Information Exchange PKCS#12 (.PFX) and then select the following:
49
Include all certificates in the certification path if possible Export all extended properties Warning: When exporting the certificate from an Edge server, do not select Delete the private key if the export is successful. Selecting this option will require that you import the certificate and the private key to this Edge server.
10. Click Next. 11. Type a password for the private key, type the password again to confirm, and then click Next. 12. Type a path and file name for the exported certificate, using a file extension of .pfx. The path must either be accessible to all other Edge servers in the pool or available to transport by means of removable media - for example, a USB flash drive. Click Next. 13. Review the summary in Completing the Certificate Export Wizard, and then click Finish. 14. In the successful export dialog box, click OK. 15. Import the exported certificate file to the other Edge servers following the steps outlined in the To import the certificate for the external interface of the Edge Server procedure earlier in this topic. To assign the certificate for the external interface of the Edge Server 1. On each Edge Server, in the Deployment Wizard, next to Step 3: Request, Install, or Assign Certificates, click Run again. 2. On the Available Certificate Tasks page, click Assign an existing certificate. 3. On the Certificate Assignment page, click External Edge Certificate and select the Advanced Certificate Usages check box. 4. On the Advanced Certificate Usages page, select all check boxes to assign the certificate for all usages. 5. On the Certificate Store page, select the public certificate that you requested and imported for the external interface of the Edge Server. Note: If the certificate you requested and imported is not in the list, one of the trouble shooting methods is to verify that subject name and subject alternative names of the certificate meet all requirements for the certificate and, if you manually imported the certificate and certificate chain instead of using the preceding procedures, that the certificate is in the correct certificate store (the computer certificate store, not the user or service certificate store). 6. On the Certificate Assignment Summary page, review your settings, and then click Next to assign the certificates. 7. On the wizard completion page, click Finish. 8. After using this procedure to assign the edge certificate, open the Certificate snap-in
50
on each server, expand Certificates (Local computer), expand Personal, click Certificates, and then verify in the details pane that the certificate is listed. 9. If your deployment includes multiple Edge Servers, repeat this procedure for each Edge Server.
Set Up Certificates for the Reverse Proxy Each reverse proxy server requires a web server certificate for use by the listening service. The web server certificate must be issued by a public certification authority (CA). For details about this and other certificate requirements, see Certificate Requirements for External User Access. To set up a Web Services certificate for the reverse proxy You should have already set up your reverse proxy, including setting up the Web Services certificate. If you did not do so before starting your deployment of your Edge Servers, use the procedures in Set Up Reverse Proxy Servers to create request and install the Web Services certificate, and then create each web publishing rule and configure it to use the certificate.
Start Edge Servers

After completing the set up of the Edge Servers and load balancers, you need to start the services on each Edge Server. To start the services 1. On each Edge Server, in the Deployment Wizard, next to Step 4: Start Services, click Run. 2. On the Start Lync Server 2010 Services page, review the list of services, and then click Next to start the services. 3. After the services are started, click Finish to close the wizard. 4. Under Step 4: Start Services, click Services Status (Optional). 5. In the Services Microsoft Management Console (MMC) on the server, verify that all of the Lync Server 2010 services are running.
Set Up Reverse Proxy Servers

For Microsoft Lync Server 2010 Edge Server deployments, an HTTPS reverse proxy in the perimeter network is required for external clients to access the Lync Server 2010 Web Services (called Web Components in Office Communications Server) on the Director and the users home pool. Some of the features that require external access through a reverse proxy include the following:
51
Enabling external users to download meeting content for your meetings. Enabling external users to expand distribution groups. Enabling remote users to download files from the Address Book service. Accessing the Microsoft Lync Web App client. Accessing the Dial-in Conferencing Settings webpage. Accessing the Location Information service. Enabling external devices to connect to Device Update web service and obtain updates. Enabling mobile applications to automatically discover mobility URLs from the Internet.
We recommend that you configure your HTTP reverse proxy to publish all Web Services in all pools. Publishing https:// ExternalFQDN/* publishes all IIS virtual directories for a pool. You need one publishing rule for each Standard Edition server, Front End pool, or Director or Director pool in your organization. In addition, you need to publish the simple URLs. If the organization has a Director or Director pool, the HTTP reverse proxy listens for HTTP/HTTPS requests to the simple URLs and proxies them to the external Web Services virtual directory on the Director or Director pool. If you have not deployed a Director, you need to designate one pool to handle requests to the simple URLs. (If this is not the users home pool, it will redirect them onward to the Web Services on the users home pool). The simple URLs can be handled by a dedicated web publishing rule, or you can add it to the public names of the web publishing rule for the Director. If you are deploying mobile applications and plan to use automatic discovery, you also need to publish the external Autodiscover Service URL. You can use Microsoft Forefront Threat Management Gateway 2010 or Microsoft Internet Security and Acceleration (ISA) Server 2006 SP1 as a reverse proxy. The detailed steps in this section describe how to configure Forefront Threat Management Gateway (TMG) 2010, and the steps for configuring ISA Server 2006 are almost identical. If you are using a different reverse proxy, consult the documentation for that product. You can use the information in this section to set up a TMG 2010 reverse proxy, which requires completing the procedures in this section. Configure Web Farm FQDNs Configure Network Adapters Request and Configure a Certificate for Your Reverse HTTP Proxy Configure Web Publishing Rules for a Single Internal Pool Verify or Configure Authentication and Certification on IIS Virtual Directories Create DNS Records for Reverse Proxy Servers Verify Access through Your Reverse Proxy
Before You Begin Set up the system you use for your reverse proxy before continuing with the configuration for reverse proxy.
52
Configure Web Farm FQDNs When you set up Topology Builder, you had the option to configure an external Web Services fully qualified domain name (FQDN) on each Standard Edition server, Front End pool, and Director or Director pool. These names are sent to the clients in that pool when they log on and they are used to make an HTTPS connection back to the reverse proxy when connecting remotely. If you did not configure these URLs during the initial Topology Builder configuration, you need to configure Lync Server 2010 using the procedure in this topic. To configure an external pool FQDN for Web Services 1. Start Topology Builder: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Topology Builder. 2. In Topology Builder, in the console tree under Standard Edition Front Ends, Enterprise Edition Front Ends, and Directors, right-click the pool name that you need to edit, and then click Edit Properties. 3. In the Web Services section, add or edit the External Web Services FQDN and then click OK. 4. Right-click Lync Server 2010, and then click Publish. 5. Repeat these steps for all of the Standard Edition servers, Front End pools, and Directors or Director pools in the organization.
Configure Network Adapters You must assign one or more IP addresses to the external network adapter and at least one IP address to the internal network adapter. If this is a new installation, install Microsoft Forefront Threat Management Gateway 2010 according to the setup instructions included with the product. In the following procedures, the server running Forefront Threat Management Gateway (TMG) 2010 has two network adapters: A public, or external, network adapter, which is displayed to the clients that attempt to connect to your website (that is, usually over the Internet). A private, or internal, network interface, which is displayed to the internal servers running Lync Server 2010 that are hosting Web Services. Important In a manner similar to the Edge Servers, you need to set the default gateway on the external-facing adapter to the internal address of the external firewall, and you need to create persistent static routes in the internal-facing interface for all subnets containing servers referenced by the web publishing rules. The reverse proxy must be able to resolve the internal Director and next hop pool FQDNs used in the web publishing rules to IP addresses. As with the Edge Servers, for security reasons, we recommend that you do not have Edge Servers access a DNS server located in the internal network. This means you either need DNS servers in the perimeter, or you need HOST file entries on the reverse proxy that resolves each of these FQDNs to the internal IP address of the servers.
53
To configure the network adapter cards on the reverse proxy computer 1. On the Windows Server 2008 or Windows Server 2008 R2 server running TMG 2010, open Change Adapter Settings by clicking Start, pointing to Control Panel, clicking Network and Sharing Center, and then clicking Change Adapter Settings. 2. Right-click the external network connection that you want to use for the external interface, and then click Properties. 3. On the Properties page, click the Networking tab, click Internet Protocol Version 4 (TCP/IPv4) in the This connection uses the following items list, and then click Properties. 4. On the Internet Protocol (TCP/IP) Properties page, configure the IP addresses as appropriate for the network subnet to which the network adapter is attached. Note: If the reverse proxy is already being used by other applications that use HTTPS/443, such as for publishing Outlook Web Access, you either need to add another IP address so that you can publish the Lync Server 2010 Web Services on HTTPS/443 without interfering with the existing rules and web listeners, or you need to replace the existing certificate with one that adds the new external FQDN names to the subject alternative name. 5. Click OK, and then click OK. 6. In Network Connections, right-click the internal network connection that you want to use for the internal interface, and then click Properties. 7. Repeat steps 3 through 5 to configure the internal network connection.
Request and Configure a Certificate for Your Reverse HTTP Proxy You need to install the root certification authority (CA) certificate on the server running Microsoft Forefront Threat Management Gateway 2010 for the CA infrastructure that issued the server certificates to the internal servers running Microsoft Lync Server 2010. You also must install a public web server certificate on your reverse proxy server. This certificates subject alternative names should contain the published external fully qualified domain names (FQDNs) of each pool that is home to users enabled for remote access, and the external FQDNs of all Directors or Director pools that will be used within that Edge infrastructure. The subject alternative name must also contain the meeting simple URL, the dial-in simple URL, and, if you are deploying mobile applications and plan to use automatic discovery, the external Autodiscover Service URL as shown in the following table.
Value Example
Subject name Subject alternative name
Pool FQDN Pool FQDN
webext.contoso.com webext.contoso.com Important:
54
Microsoft Lync Server 2010 Edge Deployment Guide Value Example
The subject name must also be present in the subject alternative name. Subject alternative name Meeting simple URL Note: All meeting simple URLs must be in the subject alternative name. Each SIP domain must have at least one active meeting simple URL. Subject alternative name Subject alternative name Dial-in simple URL External Autodiscover Service URL dialin.contoso.com lyncdiscover.contoso.com meet.contoso.com
Note: If your internal deployment consists of more than one Standard Edition server or Front End pool, you must configure web publishing rules for each external web farm FQDN and you will either need a certificate and web listener for each, or you must obtain a certificate whose subject alternative name contains the names used by all of the pools, assign it to a web listener, and share it among multiple web publishing rules. Configure Web Publishing Rules for a Single Internal Pool Microsoft Forefront Threat Management Gateway 2010 uses web publishing rules to publish internal resources, such as a meeting URL, to users on the Internet. In addition to the Web Services URLs for the virtual directories, you must also create publishing rules for simple URLs. For each simple URL, you must create an individual rule on the reverse proxy that points to that simple URL. If you are deploying mobility and using automatic discovery, you need to create a publishing rule for the external Autodiscover Service URL. Automatic discovery also requires publishing rules for the external Lync Server Web Services URL for your Director pool and Front End pool. For details about creating the web publishing rules for automatic discovery, see Configuring the Reverse Proxy for Mobility. Use the following procedures to create web publishing rules. Note: These procedures assume that you have installed the Standard Edition of Forefront Threat Management Gateway (TMG) 2010.
55
To create a web server publishing rule on the computer running TMG 2010 1. Click Start, point to Programs, point to Microsoft Forefront TMG, and then click Forefront TMG Management. 2. In the left pane, expand ServerName, right-click Firewall Policy, point to New, and then click Web Site Publishing Rule. 3. On the Welcome to the New Web Publishing Rule page, type a display name for the publishing rule (for example, LyncServerWebDownloadsRule). 4. On the Select Rule Action page, select Allow. 5. On the Publishing Type page, select Publish a single Web site or load balancer. 6. On the Server Connection Security page, select Use SSL to connect to the published Web server or server farm. 7. On the Internal Publishing Details page, type the fully qualified domain name (FQDN) of the internal web farm that hosts your meeting content and Address Book content in the Internal Site name box. Note: If your internal server is a Standard Edition server, this FQDN is the Standard Edition server FQDN. If your internal server is a Front End pool, this FQDN is a hardware load balancer virtual IP (VIP) that load balances the internal web farm servers. The TMG server must be able to resolve the FQDN to the IP address of the internal web server. If the TMG server is not able to resolve the FQDN to the proper IP address, you can select Use a computer name or IP address to connect to the published server, and then in the Computer name orIP address box, type the IP address of the internal web server. If you do this, you must ensure that port 53 is open on the TMG server and that it can reach a DNS server that resides in the perimeter network. You can also use entries in the local hosts file to provide name resolution. 8. On the Internal Publishing Details page, in the Path (optional) box, type /* as the path of the folder to be published. Note: In the website publishing wizard you can only specify one path. Additional paths can be added by modifying the properties of the rule. 9. On the Public Name Details page, confirm that This domain name is selected under Accept Requests for, type the external Web Services FQDN, in the Public Name box. 10. On Select Web Listener page, click New to open the New Web Listener Definition Wizard. 11. On the Welcome to the New Web Listener Wizard page, type a name for the web listener in the Web listener name box (for example, LyncServerWebServers). 12. On the Client Connection Security page, select Require SSL secured connections with clients. 13. On the Web Listener IP Address page, select External, and then click Select IP
56
Addresses. 14. On the External Listener IP selection page, select Specified IP address on the Forefront TMG computer in the selected network, select the appropriate IP address, click Add. 15. On the Listener SSL Certificates page, select Assign a certificate for each IP address, select the IP address that is associated with the external web FQDN, and then click Select Certificate. 16. On the Select Certificate page, select the certificate that matches the public names specified in step 9, click Select. 17. On the Authentication Setting page, select No Authentication. 18. On the Single Sign On Setting page, click Next. 19. On the Completing the Web Listener Wizard page, verify that the Web listener settings are correct, and then click Finish. 20. On the Authentication Delegation page, select No delegation, but client may authenticate directly. 21. On the User Set page, click Next. 22. On the Completing the New Web Publishing Rule Wizard page, verify that the web publishing rule settings are correct, and then click Finish. 23. Click Apply in the details pane to save the changes and update the configuration. To modify the properties of the web publishing rule 1. Click Start, point to Programs, point to Microsoft Forefront TMG, and then click Forefront TMG Management. 2. In the left pane, expand ServerName, and then click Firewall Policy. 3. In the details pane, right-click the web server publishing rule that you created in the previous procedure (for example, LyncServerExternalRule), and then click Properties. 4. On the Properties page, on the From tab, do the following: In the This rule applies to traffic from these sources list, click Anywhere, and then click Remove. Click Add. In Add Network Entities, expand Networks, click External, click Add, and then click Close. 5. On the To tab, ensure that the Forward the original host header instead of the actual one check box is selected. 6. On the Bridging tab, select the Redirect request to SSL port check box, and then specify port 4443. 7. On the Public Name tab, add the simple URLs (for example, meet.contoso.com and dialin.contoso.com). 8. Click Apply to save changes, and then click OK. 9. Click Apply in the details pane to save the changes and update the configuration.
57
Verify or Configure Authentication and Certification on IIS Virtual Directories Use the following procedure to configure certification on your Internet Information Services (IIS) virtual directories or verify that the certification is configured correctly. Perform the following procedure on each server running IIS in your internal Lync Server pool. Note: The following procedure is for the Lync Server External Web Site in IIS. To verify or configure authentication and certification on IIS virtual directories 1. Click Start, point to All Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager. 2. In Internet Information Services (IIS) Manager, expand ServerName, and then expand Sites. 3. Right-click Lync Server External Web Site, and then click Edit Bindings 4. Verify that https is associated with port 4443, and then click https. 5. Select the HTTPS entry, click Edit, and then verify that Lync Server WebServicesExternalCertificate is bound to this protocol.
Create DNS Records for Reverse Proxy Servers Create external DNS A records that point to the public external interface of your ISA Server, as described in Configure DNS Records for Edge Support. You need DNS records for the external Web Service FQDNs for each pool, the Director (or Director pool), and each simple URL. Verify Access through Your Reverse Proxy Use the following procedure to verify that your users can access information on the reverse proxy. You might need to complete the firewall configuration and Domain Name System (DNS) configuration before access will work correctly. To verify that you can access the website through the Internet Open a web browser, type the URLs in the Address bar that clients use to access the Address Book files and the website for conferencing as follows: For Address Book Server, type a URL similar to the following: https://externalwebfarmFQDN/abs where externalwebfarmFQDN is the external FQDN of the web farm that hosts Address Book Server files. The user should receive an HTTP challenge, because directory security on the Address Book Server folder is configured to Windows authentication by default. For conferencing, type a URL similar to the following: https://externalwebfarmFQDN/meet where externalwebfarmFQDN is the external FQDN of the web farm that hosts meeting content. This URL should display the troubleshooting page for conferencing.
58
For distribution group expansion, type a URL similar to the following: https://externalwebfarmFQDN/GroupExpansion/service.svc. The user should receive an HTTP challenge, because directory security on the distribution group expansion service is configured to Windows authentication by default. For dial-in, type the simple URL for dial-in conferencing. The user should be directed to the dial-in page.
Configuring Support for External User Access

After installing and configuring you internal deployment of Microsoft Lync Server 2010, internal users in your organization can collaborate with other internal users who have SIP accounts in your Active Directory Domain Services (AD DS). Collaboration can include exchanging instant messages and presence information and, if configured, participating in conferences (also known as "meetings"). By default, only users who are logged on to your internal network can log on to Lync Server 2010. You enable and configure external user access to control whether supported external users can collaborate with internal Lync Server users. External users can include remote users, federated users (including supported users of public instant messaging (IM) service providers), and anonymous participants in conferences, depending on how you configure external user access. Deploying an Edge Server or Edge pool is the first step to supporting external users. For details about deploying Edge Servers, see Deploying Edge Servers in the Deployment documentation. After completing the setup of an Edge Server or Edge pool, you must enable the types of external user access that you want to support and configure support for the external users that your organization wants to support. In Lync Server 2010, you enable and configure external user access using the Lync Server Control Panel and the Lync Server Management Shell. For details about these management tools, see Lync Server Control Panel in the Operations documentation, Lync Server Management Shell in the Operations documentation, Lync Server Control Panel in the Operations documentation, and Install Lync Server Administrative Tools in the Operations documentation. To support external user access, you must do both of the following: Enable support for your organization. To enable support for external user access in your deployment, you enable each type external user access that you want to support. You enable and disable support for external user access Lync Server 2010 Control Panel by editing the global settings on the Access Edge Configuration page in the External User Access group. Enabling support for external user access specifies that your servers running the Lync Server Access Edge service support communications with external users, but external users cannot communicate with internal users until you also configure at least one policy to manage the use of external user access. External users cannot communicate with users of your organization when external user access is disabled or if no policies are configured to support it. Configure and assign one or more policies to support external user access, which can include the following. External user access policies, which you can create and configure to control use of one or more types of external user access, including access for your remote users, access by
59
users of federated domains, and access for users of supported public IM service providers. You configure external user policies in Lync Server 2010 Control Panel using the global policy and, optionally, one or more site and user policies, on the External Access Policy page in the External User Access group. The global policy is created when you first deploy an Edge Server or Edge pool and cannot be deleted. You create and configure any site and user policies that you want to use to limit external user access to specific sites or users. Global and site policies are automatically assigned. If you create and configure a user policy, you must then assign it to the specific users or users groups to whom you want it to apply. Each external user access policy can support one or more of the following: remote user access, federated user access, and public IM connectivity. Conferencing policies, which you can create and configure to control conferencing in your organization, including which users in your organization can invite anonymous users to conferences that they host. After creating a conferencing policy and enabling support for anonymous users in the policy, you must then assign the policy to the specific users or user groups that need to be able to invite anonymous users to their conferences. You can configure external user access settings, including any policies that you want to use to control external user access, even if you have not enabled external user access for your organization. However, the policies and other settings that you configure are in effect only when you have external user access enabled for your organization. External users cannot communicate with users of your organization when external user access is disabled or if no external user access policies are configured to support it. Your edge deployment authenticates the types of external users and controls access based on how you configure your edge support. In order to control communications across the firewall, you can configure one or more policies and configure other settings that define how users inside and outside your firewall communicate with each other. This includes the default global policy for external user access, in addition to site and user policies that you can create and configure to enable one or more types of external user access for specific sites or users.
In This Section
Enable or Disable External User Access for Your Organization Configure Communications with External Users
Enable or Disable External User Access for Your Organization

After deploying one or more Edge Servers, you must enable the specific types of external user access to be supported for your organization. This includes the following types of external user access: Remote user access Enable this if you want users in your organization who are outside your firewall, such as telecommuters and users who are traveling, to be able to connect to Lync Server 2010. Federation Enable this if you want to support access by users of federated partner domains, users of public IM service providers, or both.
60
Anonymous user access Enable this if you want internal users to be able to invite anonymous users to their conferences. Note: In addition to enabling external user access support, you must also configure policies to control the use of external user access in your organization before any type of external user access is available to users. For details about creating, configuring, and applying policies for external user access, see Manage Communications with External Users in the Deployment documentation or Operations documentation. In This Section Enable or Disable Remote User Access for Your Organization Enable or Disable Federation for Your Organization Enable or Disable Anonymous User Access for Your Organization
Enable or Disable Remote User Access for Your Organization Remote users are users in your organization who have a persistent Active Directory identity within the organization. Remote users often sign in to Lync Server your network from outside the firewall by using a virtual private network (VPN) when they are not connected internally to your organizations network. Remote users include employees working at home or on the road and other remote workers, such as trusted vendors, who have been granted enterprise credentials. If you enable remote user access for remote users, supported remote users do not have to connect using a VPN in order to collaborate with internal users using Lync Server 2010. To support remote user access, you must enable it. When you enable it, you enable it for your entire organization. If you later want to temporarily or permanently prevent remote user access, you can disable it for your organization. Use the procedure in this section to enable or disable remote user access for your organization. Note: Enabling remote user access only specifies that your servers running the Access Edge service support communications with remote users, but remote users cannot participate in instant messaging (IM) or conferences in your organization until you also configure at least one policy to manage the use of remote user access. For details about configuring policies for the use of remote user access, see Manage Remote User Access in the Deployment documentation or the Operations documentation. To enable or disable remote user access for your organization 1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or is assigned to the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click External User Access, and then click Access Edge
61
Configuration. 4. On the Access Edge Configuration page, click Global, click Edit, and then click Show details. 5. In Edit Access Edge Configuration, do one of the following: To enable remote user access for your organization, select the Enable remote user access check box. To disable remote user access for your organization, clear the Enable remote user access check box. 6. Click Commit. To enable remote users to sign in to your servers running Lync Server 2010, you must also configure at least one external access policy to support remote user access. For details, see Manage Remote User Access in the Deployment documentation or the Operations documentation.
Enable or Disable Federation for Your Organization Support for federation is required to enable users who have an account with a trusted customer or partner organization, including partner domains and users of public instant messaging (IM) provider users that you support, to collaborate with users in your organization. Federation is also required to use a hosted Exchange service provider to provide voice mail to Enterprise Voice users whose mailboxes are located on a hosted Exchange service such as Microsoft Exchange Online. When you have established a trust relationship with such external domains, you can authorize users in those domains to access your deployment and participate in Lync Server communications. This trust relationship is called federation and it is not related to or dependent upon an Active Directory trust relationship. To support access by users of federated domains, you must enable federation. If you enable federation for your organization, you must also specify whether to implement the following options: Enable partner domain discovery. If you enable this option, Lync Server 2010 uses Domain Name System (DNS) records to try to discover domains not listed in the allowed domains list, automatically evaluating incoming traffic from discovered federated partners and limiting or blocking that traffic based on trust level, amount of traffic, and administrator settings. If you do not select this option, federated user access is enabled only for users in the domains that you include on the allowed domains list. Whether or not you select this option, you can specify that individual domains to be blocked or allowed, including restricting access to specific servers running the Access Edge service in the federated domain. For details about controlling access by federated domains, see Control Access by Individual Federated Domains. Send an archiving disclaimer to federated partners to advise them that communications are recorded. If you support archiving of external communications with federated partner domains, you should enable the archiving disclaimer notification to warn partners that their messages are being archived. If you later want to temporarily or permanently prevent access by users of federated domains, you can disable federation for your organization. Use the procedure in this section to enable or disable
62
federated user access for your organization, including specifying the appropriate federation options to be supported for your organization. Note: Enabling federation for your organization only specifies that your servers running the Access Edge service support routing to federated domains. Users in federated domains cannot participate in IM or conferences in your organization until you also configure at least one policy to support federated user access. Users of public IM service providers cannot participate in IM or conferences in your organization until you also configure at least one policy to support public IM connectivity. Lync Server cannot use a hosted Exchange service to provide call answering, Outlook Voice Access (including voice mail), or auto-attendant services for users whose mailboxes are located on a hosted Exchange service until you configure a hosted voice mail policy that provides routing information. For details about configuring policies for communication with users of federated domains in other organizations, see Manage Federated Partner User Access in the Deployment documentation or the Operations documentation. Additionally, if you want to support communication with users of IM service providers, you must configure policies to support it and also configure support for the individual service providers that you want to support. For details, see Manage IM Provider Support in the Deployment documentation or the Operations documentation. For details about creating a hosted voice mail policy, see Manage Hosted Voice Mail Policies in the Deployment documentation. To enable or disable federated user access for your organization 1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or is assigned to the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click External User Access, and then click Access Edge Configuration. 4. On the Access Edge Configuration page, click Global, click Edit, and then click Show details. 5. In Edit Access Edge Configuration, do one of the following: To enable federated user access for your organization, select the Enable communications with federated users check box. To disable federated user access for your organization, clear the Enable communications with federated users check box. 6. If you selected the Enable communications with federated users check box, do the following: a. If you want to support automatic discovery of partner domains, select the Enable partner domain discovery check box. b. If your organization supports archiving of external communications, select the
63
Send archiving disclaimer to federated partners check box. 7. Click Commit. To enable federated users to collaborate with users in your Lync Server 2010 deployment, you must also configure at least one external access policy to support federated user access. For details, see Manage Federated Partner User Access in the Deployment documentation or the Operations documentation. To control access for specific federated domains, see Control Access by Individual Federated Domains in the Deployment documentation or Operations documentation.
Enable or Disable Anonymous User Access for Your Organization Anonymous users are users who do not have a user account in your organization's Active Directory Domain Services (AD DS) or in a supported federated domain, can be invited to participate remotely in an on-premises conference. By allowing anonymous participation in meetings you enable anonymous users (that is, users whose identity is verified through the meeting or conference key only) to join meetings. Allowing anonymous participation requires enabling it for your organization. If you later want to temporarily or permanently prevent access by anonymous users, you can disable it for your organization. Use the procedure in this section to enable or disable anonymous user access for your organization. Note: Enabling anonymous user access for your organization only specifies that your servers running the Access Edge service support access by anonymous users. Anonymous users cannot participate in any meetings in your organization until you also configure at least one conferencing policy and apply it to one or more users or user groups. The only users that can invite anonymous users to meetings are those users that are assigned a conferencing policy that is configured to support anonymous users. For details about configuring conferencing policies to support anonymous users, see Configure Conferencing Policies to Support Anonymous Users in the Deployment documentation or the Operations documentation. To enable or disable anonymous user access for your organization 1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or is assigned to the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click External User Access, and then click Access Edge Configuration. 4. On the Access Edge Configuration page, click Global, click Edit, and then click Show details.
64
5. In Edit Access Edge Configuration, do one of the following: To enable anonymous user access for your organization, select the Enable communications with anonymous users check box. To disable anonymous user access for your organization, clear the Enable communications with anonymous users check box. 6. Click Commit. To enable anonymous users to participate in conferences hosted by users in your Lync Server 2010 deployment, you must also configure and assign at least one conferencing policy to support anonymous users. For details, see Configure Conferencing Policies to Support Anonymous Users in the Deployment documentation or the Operations documentation.
Configure Communications with External Users

By default, no policies are configured to support external user access, including remote user access, federated user access, even if you have already enabled external user access support for your organization. To control the use of external user access, you must configure one or more policies, specifying the type of external user access supported for each policy. This includes the following external access policies: Global policy The global policy is created when you deploy your Edge Servers. By default, no external user access options are enabled in the global policy. To support external user access at the global level, you configure the global policy to support one or more types of external user access options. The global policy applies to all users in your organization, but site policies and user policies override the global policy. If you delete the global policy, you do not remove it. Instead, you reset it to the default setting. Site policy You can create and configure one or more site policies to limit support for external user access to specific sites. The configuration in the site policy overrides the global policy, but only for the specific site covered by the site policy. For example, if you enable remote user access in the global policy, you might specify a site policy that disables remote user access for a specific site. By default, a site policy is applied to all users of that site, but you can assign a user policy to a user to override the site policy setting. User policy You can create and configure one or more user policies to limit support for remote user access to specific users. The configuration in the user policy overrides the global and site policy, but only for the specific users to whom the user policy is assigned. For example, if you enable remote user access in the global policy and site policy, you might specify a user policy that disables remote user access and then assign that user policy to specific users. If you create a user policy, you must apply it to one or more users before it takes effect. To support participation by anonymous users in conferences, you must configure a conferencing policy and assign the policy to users. Assigning a conferencing policy in which anonymous participation is enabled to users or user groups enables those users to invite anonymous users to conferences that they host.
65
In addition to external user access policies and conferencing policies, some external user access options, including access by federated users and access by public users, require configuration of other options. This includes the following: Specifying allowed and blocked domains for federated partners, including any specific servers running the Access Edge service that you want to allow or block. Specifying which specific service providers your organization supports, including the name of the server running the Access Edge service and the verification level supported for the provider. In This Section Manage Remote User Access Manage Federated Partner User Access Manage IM Provider Support Configure Conferencing Policies to Support Anonymous Users Apply Policies for External User Access to Users
Manage Remote User Access You configure one or more external user access policies to control whether remote users can collaborate with internal Lync Server users. To control remote user access, you can configure policies at the global, site, and user level. Site policies override the global policy, and user policies override site and global policies. For details about the types of policies that you can configure, see Manage Communications with External Users in the Deployment documentation or the Planning documentation. Note: You can configure policies to control remote user access, even if you have not enabled remote user access for your organization. However, the policies that you configure are in effect only when you have remote user access enabled for your organization. For details about enabling remote user access, see Enable or Disable Remote User Access for Your Organization in the Deployment documentation or the Operations documentation. Additionally, if you specify a user policy to control remote user access, the policy applies only to users that are enabled for Lync Server 2010 and configured to use the policy. For details about specifying users that can sign in to Lync Server 2010 from remote locations, see Apply External User Access Policies to Users in the Deployment documentation or the Operations documentation. Use the following procedure to configure each external access policy that you want to use to control remote user access. Note: This procedure describes how to configure a policy only to enable communications with remote users, but each policy that you configure to support remote user access can also support federated user access and public user access. For details about configuring policies to support federated users, see Configure Policies to Control Federated User
66
Access. For details about configuring policies to support public users, see Configure Policies to Control Access by Users of IM Service Providers. To configure an external access policy to support remote user access 1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or is assigned to the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click External User Access, and then click External Access Policy. 4. On the External Access Policy page, do one of the following: To configure the global policy to support remote user access, click the global policy, click Edit, and then click Show details. To create a new site policy, click New, and then click Site policy. In Select a Site, click the appropriate site from the list and then click OK. To create a new user policy, click New, and then click User policy. In New External Access Policy, create a unique name in the Name field that indicates what the user policy covers (for example, EnableRemoteUsers for a user policy that enables communications for remote users). To change an existing policy, click the appropriate policy listed in the table, click Edit, and then click Show details. 5. (Optional) If you want to add or edit a description, specify the information for the policy in Description. 6. Do one of the following: To enable remote user access for the policy, select the Enable communications with remote users check box. To disable remote user access for the policy, clear the Enable communications with remote users check box. 7. Click Commit. To enable remote user access, you must also enable support for remote user access in your organization. For details, see Enable or Disable Remote User Access for Your Organization in the Deployment documentation or the Operations documentation. If this is a user policy, you must also apply the policy to users that you want to be able to connect remotely. For details, see Apply External User Access Policies to Users in the Deployment documentation or the Operations documentation.
Manage Federated Partner User Access Configuring support for users of federated domains requires that you do both of the following:
67
Configuring one or more external user access policies to support users of federated domains. Specifying any specific federated domains that you want to allow or block. Additionally, when you enabled support for federation, you should have specified whether to allow automatic discovery of federated domains. For details, see Enable or Disable Federation for Your Organization in the Deployment documentation. In This Section Configure Policies to Control Federated User Access Control Access by Individual Federated Domains
Configure Policies to Control Federated User Access When you configure policies to support for federated partners, the policies apply to users of federated domains, but not for users of instant messaging (IM) service providers (for example, Windows Live), unless you also enable support for service provider users in the policy. You can configure one or more external user access policies to control whether users of federated domains can collaborate with internal Lync Server users. To control federated user access, you can configure policies at the global, site, and user level. Site policies override the global policy, and user policies override site and global policies. For details about the types of policies that you can configure, see Manage Communications with External Users in the Deployment documentation or the Planning documentation. Note: You can configure policies to control federated user access, even if you have not enabled federation for your organization. However, the policies that you configure are in effect only when you have federation enabled for your organization. For details about enabling federation, see Enable or Disable Federation for Your Organization in the Deployment documentation or the Operations documentation. Additionally, if you specify a user policy to control federated user access, the policy applies only to users that are enabled for Lync Server 2010 and configured to use the policy. For details about specifying federated users that can sign in to Lync Server 2010, see Apply External User Access Policies to Users in the Deployment documentation or the Operations documentation. To configure a policy to support access by users of federated domains 1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or is assigned to the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click External User Access, and then click External Access Policy. 4. On the External Access Policy page, do one of the following: To configure the global policy to support federated user access, click the global
68
policy, click Edit, and then click Show details. To create a new site policy, click New, and then click Site policy. In Select a Site, click the appropriate site from the list and then click OK. To create a new user policy, click New, and then click User policy. In New External Access Policy, create a unique name in the Name field that indicates what the user policy covers (for example, EnableFederatedUsers for a user policy that enables communications for federated domain users). To change an existing policy, click the appropriate policy listed in the table, click Edit, and then click Show details. 5. (Optional) If you want to add or edit a description, specify the information for the policy in Description. 6. Do one of the following: To enable federated user access for the policy, select the Enable communications with federated users check box. To disable federated user access for the policy, clear the Enable communications with federated users check box. 7. Click Commit. To enable federated user access, you must also enable support for federation in your organization. For details, see Enable or Disable Federation for Your Organization in the Deployment documentation or the Operations documentation. If this is a user policy, you must also apply the policy to users that you want to be able to collaborate with federated users. For details, see Apply External User Access Policies to Users in the Deployment documentation or the Operations documentation.
Control Access by Individual Federated Domains If you have configured support for federated partners, you can manage which specific domains can federate with your organization by doing either or both of the following: Configure one or more specific external domains as allowed federated domains. To do this, add each domain to the list of allowed domains. Even if partner discovery is enabled for your organization, do this if the domain is a federated partner that might need to communicate with more than 1,000 of your users or might need to send more than 20 messages per second. If partner discovery is not enabled for your organization, only users of external domains that you add to the allowed domains list can participate in IM and conferencing with users in your organization. If you want to restrict access for a federated domain to a specific server running the Access Edge service of the federated partner, you can specify the domain name of the server running the Access Edge service for each domain in the list of allowed domains. Block one or more external domains from connecting to your organization. To do this, add the domain to the list of blocked domains.
69
Note: This procedure describes how to configure support for specific domains, but implementing support for federated users also requires that you enable support for federated users for your organization, and configure and apply policies to control which users can collaborate with federated users. For details about enabling support for federated users, see Enable or Disable Federation for Your Organization in the Deployment documentation or the Operations documentation. For details about configuring policies to control federation, see Configure Policies to Control Federated User Access in the Deployment documentation or the Operations documentation. To add an external domain to the list of allowed domains 1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or is assigned to the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click External User Access, and then click Federated Domains. 4. On the Federated Domains page, click New, and then click Allowed domain. 5. In New Federated Domains, do the following: In Domain name (or FQDN), type the name of the federated partner domain. Notes: This name must be unique and cannot already exist as an allowed domain for this server running the Access Edge service. The name cannot exceed 256 characters in length. The search on the federated partner domain name performs a suffix match. For example, if you type contoso.com, the search will also return the domain it.contoso.com. A federated partner domain cannot simultaneously be blocked and allowed. Lync Server 2010 prevents this from happening so that you do not have to synch up your lists. If you want to restrict access for this federated domain to users of a specific server running the Access Edge service, in Access Edge service (FQDN), type the FQDN of the federated domains server running the Access Edge service. If you want to provide additional information, in Comment, type information that you want to share with other system administrators about this configuration. 6. Click Commit. 7. Repeat steps 4 through 6 for each federated partner domain that you want to allow. To enable federated user access, you must also enable support for federated user access in your organization. For details, see Enable or Disable Federation for Your Organization in the Deployment documentation or the Operations documentation. Additionally, you must configure and apply the policy to users that you want to be able to collaborate with federated users. For details, see Configure Policies to Control Federated User
70
Access in the Deployment documentation or the Operations documentation. To add an external domain to the list of blocked domains 1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or is assigned to the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click External User Access. 4. Click Federated Domains, click New, and then click Blocked domain. 5. In New Federated Domains, do the following: In Domain name (or FQDN), type the name of the federated partner domain that you want to block. Notes: The name cannot exceed 256 characters in length. The search on the federated partner domain name performs a suffix match. For example, if you type contoso.com, the search will also return the domain it.contoso.com. A federated partner domain cannot simultaneously be blocked and allowed. Lync Server 2010 prevents this from happening so that you do not have to synch up your lists. (Optional) In Comment, type information that you want to share with other system administrators about this configuration. 6. Click Commit. 7. Repeat steps 4 through 6 for each federated partner that you want to block.
Manage IM Provider Support To configure support for users of public instant messaging (IM) providers, you need to do both of the following: Configure one or more external user access policies to support the use of public IM services. Specify which public IM providers you want to support. To perform these tasks, use the procedures in this this section. In This Section Configure Policies to Control Access by Users of IM Service Providers Specify Supported IM Service Providers
Configure Policies to Control Access by Users of IM Service Providers Public instant messaging (IM) connectivity enables users in your organization to use IM to communicate with users of IM services provided by public IM service providers, including the
71
Windows Live network of Internet services, Yahoo!, and AOL. You configure one or more external user access policies to control whether public users can collaborate with internal Lync Server users. To control public user access, you can configure policies at the global, site, and user level. Site policies override the global policy, and user policies override site and global policies. For details about the types of policies that you can configure, see Manage Communications with External Users in the Deployment documentation or the Planning documentation. In the case of IM invitations, the response depends on the client software. The request is accepted unless external senders are explicitly blocked by a user-configured rule (that is, the settings in the users client Allow and Block lists). Additionally, IM invitations can be blocked if a user elects to block all IM from users who are not on his or her Allow list. Note: You can configure policies to control public user access, even if you have not enabled federation for your organization. However, the policies that you configure are in effect only when you have federation enabled for your organization. For details about enabling federation, see Enable or Disable Federation for Your Organization in the Deployment documentation or the Operations documentation. Additionally, if you specify a user policy to control public user access, the policy applies only to users that are enabled for Lync Server 2010 and configured to use the policy. For details about specifying public users that can sign in to Lync Server 2010, see Apply External User Access Policies to Users in the Deployment documentation or the Operations documentation. Use the following procedure to configure a policy to support access by users of one or more public IM providers. To configure an external access policy to support public user access 1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or is assigned to the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click External User Access, and then click External Access Policy. 4. On the External Access Policy page, do one of the following: To configure the global policy to support public user access, click the global policy, click Edit, and then click Show details. To create a new site policy, click New, and then click Site policy. In Select a Site, click the appropriate site from the list and then click OK. To create a new user policy, click New, and then click User policy. In New External Access Policy, create a unique name in the Name field that indicates what the user policy covers (for example, EnablePublicUsers for a user policy that enables communications for public users). To change an existing policy, click the appropriate policy listed in the table, click
72
Edit, and then click Show details. 5. (Optional) If you want to add or edit a description, specify the information for the policy in Description. 6. Do one of the following: To enable public user access for the policy, select the Enable communications with public users check box. To disable public user access for the policy, clear the Enable communications with public users check box. 7. Click Commit. To enable public user access, you must also enable support for federation in your organization. For details, see Enable or Disable Federation for Your Organization in the Deployment documentation or the Operations documentation. If this is a user policy, you must also apply the policy to public users that you want to be able to collaborate with public users. For details, see Apply External User Access Policies to Users in the Deployment documentation or the Operations documentation.
Specify Supported IM Service Providers Users of public instant messaging (IM) services, including any or all of the following: Windows Live, AOL, and Yahoo!, and Extensible Messaging and Presence Protocol (XMPP) providers and servers (for example, Google Talk or Jabber) by using an XMPP gateway. A public IM service provider is a specific type of federated partner. Support for public IM users has specific requirements that are different from the requirements for users of other federated partners. Customers that do not have a volume license for Lync Server 2010 require a separate license if they choose to configure public IM connectivity with Windows Live, AOL, and Yahoo! For details, see "Changes in Office Communications Server Public IM Federation" at http://go.microsoft.com/fwlink/?linkid=197275 and "Microsoft Lync: Pricing and Licensing" at http://go.microsoft.com/fwlink/?LinkId=202848. Note: To use XMPP, you must install the XMPP Gateway. You can download the XMPP Gateway from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkId=204552. After you install the XMPP Gateway, you need to install the hotfix, which is available for download from http://go.microsoft.com/fwlink/?LinkId=204561. You can add or remove an IM service provider, and change other settings for any IM service provider (including temporarily blocking the IM service provider). The settings that you can specify for each IM service provider include the following: Whether the IM service provider is hosted or public. Hosted IM service providers are internal to your organization, running as hosted services. Some organizations allow external users to establish federation with internal servers as a hosting provider, similar to establishing federation with a public provider, such as MSN. Whether to permit the IM service provider to federate with your organization.
73
The network address of the IM service providers Access Edge, which you specify by using the fully qualified domain name (FQDN) of the server running the Access Edge service. The filtering options for incoming communications are as follows: Allow communications only with users verified by this provider This setting is the default. It means that you trust the IM service provider's verification level and handle incoming messages accordingly. Requests marked as unverified are handled as described for the Allow communications only with users on recipients' contact lists option. Requests marked as verified are handled as described for the Allow all communications with this provider option. Allow communications only with users on recipients' contact lists This setting means you do not trust verification levels asserted by the IM service provider. If you choose this option, the server running the Access Edge service marks all incoming presence subscription requests as unverified. If the sender is already on the recipients Allow list, the internal server responds to that request. Otherwise, the request is rejected. Similarly, requests for an IM session that are marked unverified are rejected by the client. Allow all communications with this provider This setting means that you accept all messages regardless of whether they are verified or not. If you choose this option, the server running the Access Edge service marks all messages as verified. The recipient's home pool or server notifies the client, and all messages are handled according to settings on the client. In the case of presence subscription requests, the client settings determine how the message is handled. By default, the Windows Live, AOL, and Yahoo! are available in the list, but are not enabled. For a public IM service provider, public IM connectivity may require the purchase of additional service licenses and provisioning the connections. For details, see the Lync Server 2010 licensing information at http://go.microsoft.com/fwlink/?LinkId=202848. Pricing and licensing information for public IM connectivity are available through Microsoft Volume Licensing programs. For details, see the Microsoft Volume Licensing page at http://go.microsoft.com/fwlink/?LinkId=144874. For details about specific requirements for public IM service providers, see the "Office Communications Server Public IM Connectivity Provisioning Guide" at http://go.microsoft.com/fwlink/?LinkId=155970. Note: You can configure support for public IM providers, even if you have not enabled federation for your organization. However, the provider support that you configure is in effect only when you have federation enabled for your organization. For details about enabling federation, see Enable or Disable Federation for Your Organization in the Deployment documentation or the Operations documentation. Additionally, support for IM service providers requires configuration of policies to support user access. For details about configuring policies to support access by users of IM service providers, see Configure Policies to Control Access by Users of IM Service Providers. Use the following procedure to configure IM provider support for one or more hosted or public IM service providers. To configure support for an IM service provider 1. From a user account that is a member of the RTCUniversalServerAdmins group (or
74
has equivalent user rights), or is assigned to the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click External User Access, click Providers, and then do one of the following: To create a new provider, click New, and then click Public or Hosted. Note: Select Hosted if your IM service provider is internal to your organization, running as hosted services. Some organizations allow external users to establish federation with internal servers as a hosting provider, similar to establishing federation with a public provider like MSN. In Provider name, create a unique name. In Access Edge (or FQDN), type the name of each individual server running the Access Edge service. 4. Do one of the following: To enable this provider, select the Enable communications with this provider check box, and then do one of the following: Click Allow communications only with users verified by this provider. Select the Allow communications only with users on recipients' contact lists check box. Select the Allow all communications with this provider check box. To prevent communications with this provider, clear the Enable communications with this provider check box. 5. To modify an existing provider, click the appropriate provider listed in the table, click Edit, and then click Show details. Then, do one of the following: To enable this provider, select the Enable communications with this provider check box, and then do one of the following: Click Allow communications only with users verified by this provider. Select the Allow communications only with users on recipients' contact lists check box. Select the Allow all communications with this provider check box. To prevent communications with this provider, clear the Enable communications with this provider check box. 6. Click Commit. To enable public user access, you must also enable support for federation in your organization. For details, see Enable or Disable Federation for Your Organization in the Deployment documentation or the Operations documentation. Support for IM service providers also requires configuration of policies to support user access.
75
For details about configuring policies to support access by users of IM service providers, see Configure Policies to Control Access by Users of IM Service Providers.
Configure Conferencing Policies to Support Anonymous Users By allowing anonymous participation in meetings you enable anonymous users (that is, users whose identity is verified through the meeting or conference key only) to join your meetings. By default, all users are prevented from inviting anonymous users to participate in a meeting. You control who can invite anonymous users by configuring a conferencing policy to support anonymous users, and applying that conferencing policy to specific users. Use the procedure in this section to configure a global policy to support participation of anonymous users in conferences. For details about creating and applying a conferencing policy to support participation of anonymous users in conferences, see Create or Modify Conferencing User Experience for a Site or Group of Users and Apply Conferencing Policies to Support Anonymous Users in the Deployment documentation or the Operations documentation. At the global level, you can specify whether or not you want to enable anonymous user access to conferences. At the user account level, you can control a users ability to invite anonymous users by specifying which conferencing policy to apply to individual users. To configure policies to allow anonymous participation in meetings 1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or is assigned to the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click External User Access. 4. In the Access Edge Configuration page, click the global policy, click Edit, and then click Show details. 5. In Edit Access Edge Configuration, select the Enable anonymous user access to conferences check box. 6. Click Commit. 7. In the left navigation bar, click Conferencing, and then do one of the following: a. To create a new site policy, click New, and then click Site policy. In Select a Site, click the appropriate site from the list and then click OK. b. To configure an existing policy, click the appropriate policy listed in the table, click Edit, then Show details. 8. In Conferencing Policies, select the Allow participants to invite anonymous users check box. 9. Click Commit.
76
To enable users to invite anonymous users to conferences, you must also enable support for anonymous users in your organization. For details, see Enable or Disable Anonymous User Access for Your Organization in the Deployment documentation or the Operations documentation. Additionally, you must apply the policy to users that you want to be able to invite anonymous users. For details, see Apply External User Access Policies to Users in the Deployment documentation or the Operations documentation.
Apply Policies for External User Access to Users If you configure user policies for external user access or conferencing policies to support anonymous users, you must assign the policies to users or user groups before support is available to the users. In This Section Apply External User Access Policies to Users Apply Conferencing Policies to Support Anonymous Users
Apply External User Access Policies to Users If a user has been enabled for Lync Server 2010, you can configure federation, remote user access, and public instant messaging (IM) connectivity in the Lync Server Control Panel by applying the appropriate policies to specific users or user groups. For example, if you created a policy to support remote user access, you must apply it to at least one user or user group before the user or user group can connect to Lync Server 2010 from a remote location and collaborate with internal users from the remote location. Note: To support for external user access, you must enable support for each type of external user access you want to support, and configure the appropriate policies and other options to control use. For details, see Configuring Support for External User Access in the Deployment documentation or Managing External Connectivity in the Operations documentation. Use the procedure in this topic to apply a previously created external user access policy to one or more user accounts or user groups. To apply an external user policy to a user account 1. From a user account that is assigned to the CsUserAdministrator role or the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click Users, and then search on the user account that you want to configure. 4. In the table that lists the search results, click the user account, click Edit, and then
77
click Show details. 5. In Edit Lync Server User under External access policy, select the user policy that you want to apply. Note: The <Automatic> settings apply the default server installation settings. These settings are applied automatically by the server.
Apply Conferencing Policies to Support Anonymous Users By default, all users are prevented from inviting anonymous users to participate in a meeting. You control who can invite anonymous users by configuring a conferencing policy to support anonymous users, and applying that conferencing policy to specific users. For details about how to configure a conferencing policies to support anonymous users, see Configure Conferencing Policies to Support Anonymous Users in the Deployment documentation or Managing External Connectivity the Operations documentation. Use the procedure in this section to apply a conferencing policy that you have already created to one or more users or user groups. Note: In addition to configuring and applying a policy to enable users to invite anonymous users, you must also enable support for anonymous users for your organization. For details, see Enable or Disable Anonymous User Access for Your Organization. To configure a user policy for anonymous participation in meetings 1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or is assigned to the CsAdministrator role, log on to any computer in your internal deployment. 2. Open a browser window, and then enter the Admin URL to open the Lync Server Control Panel. For details about the different methods you can use to start Lync Server Control Panel, see Open Lync Server Administrative Tools. 3. In the left navigation bar, click Conferencing, and then do one of the following: a. To create a new user policy, click New, and then click User policy. Create a unique name in the Name field that indicates what the user policy covers (for example, EnableAnonymous for a user policy that enables communications with anonymous users). b. To configure an existing user policy, click the appropriate policy listed in the table, click Edit, and then click Show details. 4. In the Conferencing Policies dialog box, select the Allow participants to invite anonymous users check box. 5. Click Commit. 6. In the left navigation bar, click Users, search on the user account that you want to configure.
78
7. In the table that lists the search results, click the user account, click Edit, and then click Show details. 8. In Edit Lync Server User under Conferencing policy, select the user policy with the anonymous user access configuration that you want to apply to this user. Note: The <Automatic> settings apply the default server installation settings and are applied automatically by the server. To enable users to invite anonymous users to conferences, you must also enable support for anonymous users in your organization. For details, see Enable or Disable Anonymous User Access for Your Organization in the Deployment documentation or the Operations documentation.
Verifying Your Edge Deployment

After completing the installation and configuration of your edge components, you need to verify the configuration and connectivity of servers and to verify connectivity for each type of external user that you support.
In This Section
Verify Connectivity Between Internal Servers and Edge Servers Verify Connectivity for External Users
Verify Connectivity Between Internal Servers and Edge Servers

In Microsoft Office Communications Server 2007 R2, a separate validation wizard was available to help validate connectivity between Edge Servers and internal servers. In Microsoft Lync Server 2010 validation of connectivity is done automatically when you install your Edge Servers. You can validate the replication of configuration information to the edge by running the Windows PowerShell Get-CsManagementStoreReplicationStatus cmdlet on the internal computer on which the Central Management store is located (or any domain joined computer on which Lync Server 2010 Core Components (OcsCore.msi) is installed. Initial results may indicate the status as "False" instead of "True" for replication. If so, run the Invoke-CsManagementStoreReplication cmdlet and allow time for the replication to complete before running the GetCsManagementStoreReplicationStatus again. You can verify external user connectivity separately, including using the Office Communications Server Remote Connectivity Analyzer to verify remote user connectivity. For details, see Verify Connectivity for External Users.
Verify Connectivity for External Users

Validating connectivity for external users requires ensuring connectivity from users to the server and port for the Access Edge service.
79
Test Connectivity of External Users and External access Tests for external user access should include each type of external user that your organization supports, including any or all of the following: Users from at least one federated domain, and test IM, presence, A/V and desktop sharing. Users of each public IM service provider that your organization supports (and for which provisioning has been completed). Anonymous users. Users within your organization who are logged into Lync remotely, but not using VPN. Listening on the necessary ports by using a telnet client from outside your network. Example: telnet ae.contoso.com 443 Perform the preceding test on ports you are using on the Edge Server or Edge Server pool depending on your deployment. Performing accurate external DNS resolution. From outside your network ping each of the external FQDNs of your Edge or Edge pool. Even if the ping fails you will see the IP addresses, which you can compare to the ones you have assigned.
These tests determine whether your Edge Server is:
80

LS Deploy Edge Dir

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

LS Deploy Edge Dir

Загружено:

Авторское право:

Доступные форматы

Microsoft Lync Server 2010 Edge Deployment Guide

Microsoft Lync Server 2010

Deploying Edge Servers

Edge Deployment Overview

Microsoft Lync Server 2010 Edge Deployment Guide

Deployment Process for External User Access

Defining Your Edge Topology

Prepare for setup.

Preparing for Installation of Servers in the Perimeter Network

Set Up Reverse Proxy Servers

Setup a Director (recommended).

Setting Up the Director

Set up Edge Servers.

Setting Up Edge Servers

Edge Deployment Tools

Deployment Best Practices for External User Access

Microsoft Lync Server 2010 Edge Deployment Guide

Preparing for Installation of Servers in the Perimeter Network

System Requirements for Edge Components

Microsoft Lync Server 2010 Edge Deployment Guide

Memory Disk Network

Microsoft Lync Server 2010 Edge Deployment Guide

Configure DNS for Edge Support

Microsoft Lync Server 2010 Edge Deployment Guide

Microsoft Lync Server 2010 Edge Deployment Guide

Set Up Hardware Load Balancers for Scaled Edge Topology

Configure Firewalls and Ports for External User Access

Microsoft Lync Server 2010 Edge Deployment Guide

A/V Firewall and Port Requirements

Windows Live Messenger 2011

Point to Point Audio/Video (A/V)

Open inbound Open outbound

Lync Server 2010

Open inbound Open outbound

Lync Server 2010

Application sharing/desktop sharing

Open inbound Open outbound

Lync Server 2010

Open inbound Open outbound

Office Communications Server 2007 R2

Open inbound Open outbound

Office Communications Server 2007 R2

Open inbound Open outbound

Office Communications Server 2007 R2 Office Communications Server 2007

Open inbound Open outbound

Open inbound Open outbound N/A

Office Communications Server 2007 Office

Microsoft Lync Server 2010 Edge Deployment Guide

Microsoft Lync Server 2010 Edge Deployment Guide

Request Edge Certificates

Microsoft Lync Server 2010 Edge Deployment Guide

Prepare for Support of Public IM Connectivity

Building an Edge and Director Topology

Microsoft Lync Server 2010 Edge Deployment Guide

Define the Director

Microsoft Lync Server 2010 Edge Deployment Guide

Microsoft Lync Server 2010 Edge Deployment Guide

Microsoft Lync Server 2010 Edge Deployment Guide

9. Publish the topology.

Defining Your Edge Topology

Microsoft Lync Server 2010 Edge Deployment Guide

Microsoft Lync Server 2010 Edge Deployment Guide

Microsoft Lync Server 2010 Edge Deployment Guide