LS Deploy Edge Dir

Microsoft Lync Server 2010 Edge Deployment Guide

Microsoft Lync Server 2010Published: March 2011

This document is provided “as-is”. Information and views expressed in this document, including

URL and other Internet Web site references, may change without notice. You bear the risk of

using it.

Some examples depicted herein are provided for illustration only and are fictitious. No real

association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any

Microsoft product. You may copy and use this document for your internal, reference purposes.

This document is confidential and proprietary to Microsoft. It is disclosed and can be used only

pursuant to a non-disclosure agreement.

Copyright © 2011 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveSync, ActiveX, DirectX, Excel, Forefront, Groove, Hyper-V,

Internet Explorer, Lync, MSDN, MSN, OneNote, Outlook, PowerPoint, RoundTable, SharePoint,

Silverlight, SQL Server, Visio, Visual C++, Visual Studio, Windows, Windows Live, Windows

Media, Windows PowerShell, Windows Server, and Windows Vista, are trademarks of the

Microsoft group of companies. All other trademarks are property of their respective owners.

Contents

Deploying Edge Servers..............................................................................................................1

Edge Deployment Overview.....................................................................................................1

Deployment Process for External User Access.....................................................................2

Edge Deployment Tools........................................................................................................7

Deployment Best Practices for External User Access...........................................................7

Preparing for Installation of Servers in the Perimeter Network.................................................8

System Requirements for Edge Components.......................................................................8

Hardware and Software Requirements for Edge Components..........................................8

Supported Server Collocation for Edge Components......................................................10

Configure DNS for Edge Support........................................................................................10

Configure DNS Records for Edge Support......................................................................10

Configure the DNS Suffix for Edge Servers.....................................................................11

Set Up Hardware Load Balancers for Scaled Edge Topology.............................................12

Configure Firewalls and Ports for External User Access.....................................................12

Determining External A/V Firewall and Port Requirements.............................................12

Request Edge Certificates..................................................................................................16

Request Certificates from a Public CA............................................................................17

Request Certificates from an Internal Enterprise CA.......................................................17

Prepare for Support of Public IM Connectivity....................................................................18

Building an Edge and Director Topology................................................................................18

Define the Director..............................................................................................................19

Define a Single Director in Topology Builder...................................................................19

Define a Multiple Director Pool in Topology Builder.........................................................20

Defining Your Edge Topology..............................................................................................21

Define the Topology for a Single Edge Server.................................................................22

Define the Topology for a DNS Load Balanced Edge Pool..............................................24

Define the Topology for a Hardware Load Balanced Edge Pool......................................28

Publish Your Topology.........................................................................................................31

Setting Up the Director...........................................................................................................32

Install the Local Configuration Store...................................................................................32

Install Lync Server 2010 on the Director.............................................................................33

Configure Certificates for the Director.................................................................................33

Start Services on the Director.............................................................................................34

Test the Director.................................................................................................................. 35

Configure Automatic Client Sign-In To Use the Director......................................................35

Setting Up Edge Servers........................................................................................................36

Set Up Network Interfaces for Edge Servers......................................................................36

Install Prerequisite Software on Edge Servers....................................................................38

Export Your Topology and Copy It to External Media for Edge Installation.........................38

Install Edge Servers............................................................................................................38

Set Up Edge Certificates.....................................................................................................39

Certificate Requirements for External User Access.........................................................40

Set Up Certificates for the Internal Edge Interface..........................................................41

Set Up Certificates for the External Edge Interface.........................................................45

Set Up Certificates for the Reverse Proxy.......................................................................49

Start Edge Servers.............................................................................................................49

Set Up Reverse Proxy Servers...........................................................................................49

Configure Web Farm FQDNs..........................................................................................51

Configure Network Adapters............................................................................................51

Request and Configure a Certificate for Your Reverse HTTP Proxy................................53

Configure Web Publishing Rules for a Single Internal Pool.............................................53

Verify or Configure Authentication and Certification on IIS Virtual Directories.................56

Create DNS Records for Reverse Proxy Servers............................................................56

Verify Access through Your Reverse Proxy.....................................................................56

Configuring Support for External User Access.......................................................................57

Enable or Disable External User Access for Your Organization..........................................59

Enable or Disable Remote User Access for Your Organization.......................................59

Enable or Disable Federation for Your Organization.......................................................60

Enable or Disable Anonymous User Access for Your Organization.................................62

Configure Communications with External Users.................................................................63

Manage Remote User Access.........................................................................................64

Manage Federated Partner User Access.........................................................................66

Configure Policies to Control Federated User Access.....................................................66

Control Access by Individual Federated Domains...........................................................68

Manage IM Provider Support...........................................................................................70

Configure Policies to Control Access by Users of IM Service Providers..........................70

Specify Supported IM Service Providers.........................................................................71

Configure Conferencing Policies to Support Anonymous Users......................................74

Apply Policies for External User Acces to Users.............................................................75

Apply External User Access Policies to Users.................................................................76

Apply Conferencing Policies to Support Anonymous Users............................................76

Verifying Your Edge Deployment............................................................................................78

Verify Connectivity Between Internal Servers and Edge Servers........................................78

Verify Connectivity for External Users.................................................................................78

Deploying Edge ServersDeploying edge components for Microsoft Lync Server 2010 makes it possible for external users

who are not logged into your organization’s 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 OverviewTo 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

1

http://go.microsoft.com/fwlink/?LinkId=205566

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.

2


Edge Server Deployment Process

Phase Steps Permissions Documentation

Create the appropriate edge

topology and determine the

appropriate components.

Run Topology Builder to

configure Edge Server settings

and create and publish the

topology, and then use Lync

Server Management Shell to

export the topology

configuration file.

Domain Admins group and

RTCUniversalServerAdmins group

Note:

You can define a topology using

an account that is a member of the

local users group, but publishing a

topology requires an account that

is a member of the Domain

Admins group and the

RTCUniversalServerAdmins

group.

Defining Your Edge Topology

Prepare for setup. 1. Ensure that system

prerequisites are met.

2. Configure IP 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

As appropriate to your organization Preparing for Installation of

Servers in the Perimeter

Network

3



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 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

Administrators group

Set Up Reverse Proxy Servers

4



proxy server.

Setup a Director

(recommended).

(Optional) Install and configure

one or more Directors in the

internal network.

Administrators group Setting Up the Director

Set up Edge Servers. 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.

4. Configure the Edge Servers.

5. Request and install certificates

for each Edge Server.

6. Start the Edge Server

services.

Administrators group Setting Up Edge Servers

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

RTCUniversalServerAdmins group or

user account that is assigned to the

CSAdministrator role

Configuring Support for

External User Access

5



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

connect, including remote

users, users in federated

domains, public IM users, and

anonymous users, as

appropriate to your

deployment.

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

Remote users

Verifying Your Edge

Deployment

6


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 completed the building of 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.

7


Preparing for Installation of Servers in the Perimeter NetworkBefore 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

8


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 12 GB recommended

Disk Local storage with at least 30 GB free disk

space

Network 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.

9





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 the DNS Suffix for Edge Servers


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, and 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.

Note:

10


The external DNS for external DNS lookups by remote users and federated

partners, the perimeter network (also known as DMZ, demilitarized zone, and

screened subnet) DNS for records required by the Edge Servers, or the internal

DNS for lookups by 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.

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 DNS suffix to the 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.

11


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.

12


A/V Firewall and Port Requirements

Federation with Feature TCP/443 UDP/3478 RTP/UDP 50.000-

59,999K

RTP/TCP 50,000-

59,999K

Windows Live Messenger

5.0

Point to Point

Audio/Video (A/V)

Open inbound Open inbound

Open outbound

Do not open in either

direction

Open outbound

Lync Server 2010 Lync Server 2010 Open inbound Open inbound

Open outbound


direction

Open outbound

Lync Server 2010 Application

sharing/desktop sharing

Open inbound Open inbound

Open outbound


direction

Open outbound

Lync Server 2010 File transfer Open inbound Open inbound

Open outbound


direction

Open outbound

Office Communications

Server 2007 R2

A/V Open inbound Open inbound

Open outbound


direction

Open outbound


Server 2007 R2

Desktop sharing Open inbound Open inbound

Open outbound


direction

Open outbound


Server 2007 R2

File transfer N/A N/A N/A N/A


Server 2007

A/V Open inbound Open inbound Open inbound

Open outbound

Open inbound

Open outbound


Server 2007

Desktop sharing N/A N/A N/A N/A

Office Communications File transfer N/A N/A N/A N/A

13


Federation with Feature TCP/443 UDP/3478 RTP/UDP 50.000-

59,999K

RTP/TCP 50,000-

59,999K

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.

Note:

Regarding the 50,000-59,999 port range, the best practice for Lync Server 2010 is to open it outbound, to "Any" for RDP/TCP for the A/V

Edge external interface if corporate policy allows.

14


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.

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.

15


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 and port do not change but the

destination IP address changes from 63.123.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 workstation’s public IP address to that of the A/V Edge’s public IP

address. And the destination IP remains the workstation’s 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 Edge’s external interface IP address (10.45.16.10) to its public IP

address (63.123.155.30).

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.

16


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. 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 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.

17


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 "Office Communications

Server Public IM Connectivity Provisioning Guide" at http://go.microsoft.com/fwlink/?

LinkId=155970.

If you are implementing audio/video (A/V) federation with Windows Live Messenger, you must

also modify the Microsoft Lync Server 2010 encryption level. By default, the encryption level is

Required. You must change this setting to Supported. 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 command:

Set-CsMediaConfiguration –EncryptionLevel SupportEncryption

See Also

Set-CsMediaConfiguration

Building an Edge and Director TopologyBuilding 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.

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.

18




In This Section

Define the Director


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 load-

balanced 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.

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 Save Topology As, type the name and location of the local copy of the existing

topology, and then click Save.

19


4. Expand the site in which you plan to add the Director, right-click Director pools, and then

click New Director Pool.

5. In Define the Director pool FQDN, do the following:

In Pool FQDN, type the FQDN for the Director pool.

Click Single computer pool, and then click Next.

6. In Define the file share, 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.

7. In Specify the Web Services URL, 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 it 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.

To successfully publish, enable, or disable a topology when adding or removing a server role, you

should be logged in as a user who is a member of the RTCUniversalServerAdmins and

Domain Admins groups. It is also possible to delegate the proper 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)



2. On the welcome page, click Download Topology from Existing Deployment.

20


3. In Save Topology As, he 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 Define the Director pool FQDN, do the following:

In Pool FQDN, type the FQDN for the Director pool.

Click Multiple computer pool, and then click Next.

6. In Define the computers in this pool, do the following:

Specify the computer FQDN of the first pool member, and then click Add.

Repeat the previous step for each computer that you want to add. When you are

finished, click Next.

7. In Define the file share, 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 Specify the Web Services URL, 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 it to the external Web Services virtual directory on that

Director pool.

9. Publish the 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

21


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.



Domain Admins groups. It is also possible to 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.

Important:

You cannot run Topology Builder from an Edge Server. You must run it from either your

Front End pool or Standard Edition servers.

Note:

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, so you can skip the following procedure. You do,

however, need to make the previously defined and published topology available to your

Edge Server, which you do by using the procedure in Export Your Topology and Copy It

to External Media for Edge Installation.

To define the topology for a single Edge Server



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:

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.

22


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 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 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

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:

23


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. 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. 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 AV Edge service.

12. In Define the next hop, in the Next hop pool drop-down list box, 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.

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..





24




Important:

You cannot run Topology Builder from an Edge Server. You must run it from your Front

End pool or Standard Edition servers.

Note:



need to do define it and publish it again, so you can skip the following procedure. You do,


Edge Servers, which you do by using the procedure in Export Your Topology and Copy It

to External Media for Edge Installation.

To define the topology for a DNS load balanced Edge Server pool



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.



In FQDN, type the fully qualified domain name (FQDN) that you have chosen for the

internal side of the Edge pool.

Note:


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



DNS 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 Edges 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:


25




the same Edge pool or single Edge Server. For instance, if your deployment







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.


If in Select features you chose to use a single FQDN and IP Address for the SIP


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). 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 example, 443) for all three services.

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.

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:



26







12. Click Next.

13. In Define the external IP addresses, do the following:



Edge Server in SIP Access.


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 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 AV 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.



selecting the names of the internal pool(s) that is to use this Edge Server for


Note:



27




is already associated with another Edge server, it will change the association.

20. Click Finish.


Define the Topology for a Hardware 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 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

Edge Servers.







Important:

You cannot run Topology Builder from an Edge Server. You must run it from your Front

End pool or Standard Edition servers.

Note:



need to define it and publish it again, so you can skip the following procedure. You do,


Edge Servers, which you can do by using the procedure in Export Your Topology and

Copy It to External Media for Edge Installation.

To define the topology for a hardware load balanced Edge Server pool



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.



In FQDN, type the fully qualified domain name (FQDN) you have chosen for the

internal side of the Edge pool.

28


Note:


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




DNS 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.

If you plan to enable federation, select the Enable federation (port 5061) check box.

Note:




the same Edge pool or single Edge Server. For instance, if your deployment







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.


If in Select features you chose to use a single FQDN and IP address for the SIP


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). By selecting this option, you can help prevent potential connectivity

issues and simplify the configuration because you can then use the same

29


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 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.

Note:

These will be the publicly facing virtual IP (VIP) FQDNs for the pool.

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:








12. Click Next.

13. In Define the external IP addresses, do the following:



Edge Server in SIP Access.


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

30


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. 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.



selecting the names of the internal pool(s) that is to use this Edge Server for


Note:





is already associated with another Edge Server, it will change the association.

19. Click Finish.


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



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.

31


Setting Up the DirectorIf 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

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 as minimally 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.

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.

32


8. When the local server configuration installation is complete, click Finish.

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

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.

8. On the Name and Security Settings page, you can specify a Friendly Name, accept

the 2048-bit key length, and then click Next.

33


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.

4. Below Step 4: Start Services, click Services Status (Optional).

34


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 Installing and Using Administrative Tools.

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).

35


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 ServersThe 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 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

36


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 (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.

37


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

38


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 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.

39


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

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

Edge internal interface. This leaves the Edge internal interface, which 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.

Following are the requirements for the public certificate used for access and web conferencing

Edge external interfaces, and the A/V authentication Edge internal interface:

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 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).

40



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).

Note:

The order of the FQDNs in the subject alternative names list does not matter.

If you are deploying multiple, load-balanced Edge Servers at a site, the A/V Edge external

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.

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.

If you are deploying multiple, load-balanced Edge Servers at a site, the A/V authentication

certificate that is installed on each Edge Server must be from the same CA and must use the

same private key. This means that the certificate must be exportable, if it is to be used on more

than one Edge Server. It must also be exportable if you request the certificate from any computer

other than the Edge Server.

Set Up Certificates for the Internal Edge Interface

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.

41


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. With your enterprise root CA offline and your enterprise subordinate (that is, issuing) CA

server online, 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:

If you are using a Windows Server 2008 or Windows Server 2008 R2 enterprise

CA, you must use https, not http.

3. 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.

42


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 Communications

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.

3. On the Certificate Request page, click Edge Internal.

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).

43


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.

14. On the Certificate Request File page, do the following:

To view the generated certificate signing request (CSR) file, click View.


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,

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 certifcate’s private key check box and

44


specify the password.

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

After setting up certificates for the internal interface, you are ready to set up the certificates for the

external interface.

Each Edge Server requires a public certificate on the interface between the perimeter network

and the Internet, and the certificate’s subject alternative name must contain the external names of

the Access Edge service and Web Conferencing Edge service fully qualified domain names

(FQDNs).



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.

45



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


Notes:

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, use 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 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.

In Bit length, specify the bit length (typically, the default of 2048).

46


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.

15. On the Certificate Request File page, do the following:

To view the generated certificate signing request (CSR) file, click View.


16. Copy the output file to a location where you can submit it to the public CA.

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.

47


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, type the full path and file name of the certificate that you

requested for the external interface of the Edge Server (or, click Browse to locate and

select the file).

5. If you are configuring an Edge Server pool, export the certificate with its private key, copy

it to the other Edge Servers, and import it into the computer store on each Edge Server.

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


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

48


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 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).



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).

49


5. In the Services Microsoft Management Console (MMC) on the server, verify that all of

the Lync Server 2010 services are running.


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 user’s home

pool. Some of the features that require external access through a reverse proxy include the

following:

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.

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, proxy requests to these URLs to the external Web Services virtual directory on the Director.

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 user’s home pool, it will redirect them onward to the Web Services

on the user’s 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.

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

50


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.

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



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.

51


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.

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.

52


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 certificate’s

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, and the dial-in simple URL as shown

in the following table.

Value Example

Subject name Pool FQDN webext.contoso.com

Subject alternative name Pool FQDN webext.contoso.com

Important:

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.

meet.contoso.com

Subject alternative name Dial-in simple URL dialin.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.

53


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.

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..

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 an 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

54


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

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

55


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.

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.

56


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.

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 AccessAfter 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 Administering Lync Server 2010 in the Operations

documentation, Lync Server Management Shell in the Operations documentation, and Installing

and Using Administrative Tools in the Operations documentation.

To support external user access, you must do both of the following:

57


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

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.

58


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.

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

organization’s 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.

59


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.




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 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. 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.

60


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 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 communications with users of federated domains, including

public IM providers. 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. 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.

To enable or disable federated user access for your organization






61




Configuration.


details.


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 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

62


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








Configuration.


details.


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.

63


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.

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 Acces 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.

64


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

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







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.

65


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


Manage Federated Partner User Access

Configuring support for users of federated domains requires that you do both of the following:

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

66


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








Policy.


To configure the global policy to support federated user access, click the global

policy, click Edit, and then click Show details.





policy covers (for example, EnableFederatedUsers for a user policy that enables

communications for federated domain users).




Description.


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


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

67


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.

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







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:

68


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 domain’s 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


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 Access in the Deployment documentation or the Operations documentation.

To add an external domain to the list of blocked domains







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

69


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

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 user’s 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.

70


To configure an external access policy to support public user access








Policy.


To configure the global policy to support public user access, click the global policy,






policy covers (for example, EnablePublicUsers for a user policy that enables

communications for public users).




Description.


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



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

71


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


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=202714. 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.

The network address of the IM service provider’s 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 recipient’s

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.

72





http://go.microsoft.com/fwlink/?linkid=197275


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


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







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.


To enable this provider, select the Enable communications with this provider

73





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



Support for IM service providers also 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.

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.

74


At the user account level, you can control a user’s ability to invite anonymous users by

specifying which conferencing policy to apply to individual users.

To configure policies to allow anonymous participation in meetings







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,


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.

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 Acces 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

75


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.




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 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.

76


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







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,


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.

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.

77


Verifying Your Edge DeploymentAfter 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

PowerShellGet-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 Get-CsManagementStoreReplicationStatus 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.

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.

These tests determine whether your Edge Server is:

Listening on the necessary ports by using a telnet client from outside your network.

Example: telnet ae.contoso.com 443

78


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 FQDN’s 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.

79

LS Deploy Edge Dir

Documents

Transcript of LS Deploy Edge Dir