Microsoft Lync Server 2010– External User Access–Acceso Externo de clientes.

octubre 3rd, 2011 | Posted by Peter Diaz Rosales in Lync

Una de las ventajas de implementar Microsoft Lync Server 2010 es la flexibilidad de la plataforma, entre muchas cosas es poder conectarse desde cualquier lugar y tener la posibilidad de conectar con mensajería instantánea publica como Yahoo, Google Gtalk, Windows Live y AOL.

Esta guía descriptiva (en ingles) nos proporciona los requisitos y premisas a tomar en cuenta para la implementación de este servicio en nuestro Microsoft Lync Server 2010, dicho servicio se configura en el servidor Edge y se llama mensajería publica instantánea (IM).

Sin mas comparto el capitulo llamado Introducción al Acceso Externo de los usuarios (Overview of External User Access):

Descargar la guía – Download (inglés):

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

Overview of External User Access

In this documentation, we use the term external user to refer to a user who signs in to your Lync Server 2010 deployment from outside the firewall. External users that you can authorize to use Lync Server 2010 to communicate with internal users (that is, users who sign in to Lync Server 2010 from inside the firewall) can include the following:

· Remote users Users within your organization who sign in to Lync Server from outside the firewall using a Virtual Private Network (VPN) when they are not connected to the organization’s network (for example, business travelers and telecommuters).

· Federated users Users who have an account with a trusted customer or partner organization. When you have established a trust relationship with this type of organization’s domain, you can authorize users in that domain to access your Lync Server deployment. This trust relationship is called federation and is not related to or dependent upon an Active Directory trust relationship.

· Public IM users Users of public instant messaging (IM) services, including any or all of the following: Windows Live, AOL, and Yahoo!, as well as XMPP-based providers and servers, such as Google Talk and Jabber. A public IM service provider is a specific type of federated partner. Support for public IM users has specific requirements that are different from the requirements for users of other federated partners. Customers that do not have a volume license for Lync Server 2010 will require a separate license if they choose to configure public IM connectivity with Windows Live Messenger, AOL, and Yahoo! For details, see http://go.microsoft.com/fwlink/?linkid=197275.

· Anonymous users Users who do not have a user account in your organization’s Active Directory Domain Services (AD DS)or in a supported federated domain, but who have received invitations to participate remotely in an on-premises conference.

Your edge deployment authenticates these types of users and controls external access for the following types of communication:

· IM and presence Authorized external users can participate in IM conversations and conferences, as well as obtain information about one another’s presence status.

· Web conferencing. Authorized external users can participate in conferences that are hosted on your Lync Server deployment. Remote users, federated users, and anonymous users can be enabled for participation in Web conferencing, but conferencing support for public IM users is limited. Depending on the options that you select, Web conferencing-enabled users can participate in desktop and application sharing and can act as meeting organizers or presenters.

· A/V conferencing. Authorized external users can share audio and video in conferences that your Lync Server deployment provides.

In order to control communications across the firewall, you can create global policies that define how users inside and outside your firewall communicate with each other. You can also configure settings and create and apply policies for individual internal users or for specific types of external users to control communications with external users. For example, you can allow users in federated domains to access IM and presence but not A/V conferencing or Web conferencing.

External Communications Capabilities

Lync Server 2010 provides communications capabilities for users inside and outside of your organization. The type of communications that are supported depends on the type of user. The following table summarizes the communications capabilities by type of user. The following sections in this document provide more detail.

Summary of External User Access Capabilities by User Type

Scenario	Remote user	Federated user	PIC/Interop	Anonymous user
Presence	Yes	Yes	Yes	No
Instant messaging (IM) peer-to-peer	Yes	Yes	Yes	No
IM conferencing	Yes	Yes	No	Yes
Collaboration	Yes	Yes	No	Yes
Audio/video (A/V) peer-to-peer	Yes	Yes	Yes* for the new version of Windows Live Messenger	No
A/V Conferencing	Yes	Yes	No	Yes
File Transfer	Yes	Yes	No	No

* For PIC A/V peer-to peer support, you must use the new version of Windows Live Messenger. In this scenario, only audio is supported.

Capabilities Available to Internal Users

With your authorization, users who are logged on to your intranet can communicate with external users in the following ways:

· IM and presence Users can participate in one-on-one IM conversations with public IM users and IM Conferences with remote and federated users, as well as view the presence of remote, federated and public IM users. They can also add remote users, federated users, and public IM users to their Contact lists.

· Web conferencing Meeting organizers can invite remote users, federated users, and anonymous users to conferences as either presenter or attendee. Presenters can share applications or their desktop with federated users, and they can give federated users control.

· A/V conferencing Meeting organizers can specify that meeting audio and video for conferences be hosted on your internal Lync Server deployment.

Capabilities Available to Remote Users

· IM and presence Users can send instant messages and view presence status without using a virtual private network (VPN) to log on to the internal network. They can add users from federated partners and users of supported public IM service providers to their contact list, and they can view those users’ presence status, even while they are signed in remotely.

· Web conferencing Users can participate in conferences as if they were logged on to the internal network.

· A/V conferencing Users can participate in A/V conferences as if they were logged on to the internal network.

Essentially remote users have the same capabilities as internal users.

Capabilities Available to Federated Users

The functionality available to federated users depends on the option you choose during deployment. You can choose either of these options:

· IM and presence only Users can participate in IM conversations with individual Lync Server users in your organization and access presence information, but they cannot participate in Lync Server-based IM multi-party conferences, it is strictly peer to peer conferencing. You can choose this option whether or not you deploy conferencing support internally.

· IM and presence, Web conferencing, and A/V conferencing Users can participate in IM conversations with individual Lync Server users in your organization and access presence information, as well as participate in Web conferences and A/V conferences (if they are supported by your Lync Server deployment). Federated users have access to the full feature set, except for the Lync Server 2010 address book

Capabilities Available to Public IM Users

The functionality available to federated and public IM users depends on the option you choose during deployment. You can choose either of these options:

· IM and presence, Web conferencing, and A/V conferencing In addition to peer-to-peer IM conferencing and viewing presence, public IM users can participate in A/V conferencing with Windows Live Messenger users.

Some conferencing features, including file transfer and application sharing, are not available for public IM users. The availability of features to public IM users depends on their public IM service provider. For example, A/V conferencing is available to public IM users only if they are Windows Live users. You can specify whether you want the edge topology to support IM and presence only or IM and presence, Web conferencing, and A/V conferencing as part of the deployment process, but you can change this option after deployment.

Capabilities Available to Anonymous Users

Anonymous users can participate in IM, Web conferences and audio conferences that are hosted on your internal deployment. Anonymous users require an invitation to gain access to these features.
Planning for External User Access

The basic functionality provided by a Lync Server 2010, Edge Server has not changed significantly from Office Communications Server 2007 R2, but the deployment options have. For example, the following options are new:

· Topology Builder approach to planning and installation

· DNS load balancing of both internal and external Edge interfaces

· Support for Network Address Translation (NAT) of the A/V Edge for multiple Edge servers in a pool

· A single public certificate can be applied to Edge interfaces / services that require a certificate

This document focuses on the impact these new options have on planning.

Planning Process

Lync Server 2010 places emphasis on the planning process and typically, the more time you devote to planning your Edge environment, the less time you’ll spend deploying it. There are four basic steps to planning but we will focus only on the first; the other three are covered in the Edge Deployment documentation:

Data Collection
Edge Planning Tool
Topology Builder
Run Setup

Data Collection

In Lync Server 2010, you can run the Microsoft Lync Server 2010, Planning Tool without documenting your existing and proposed IP addresses and Edge server FQDN’s, but it is significantly harder to do so without causing configuration errors. For example, a common mistake is to reuse FQDN’s from an existing Edge deployment for your Lync Server 2010 Edge deployment.

Note

Once you’ve run the Planning Tool and exported it to Topology Builder, it cannot be modified. You have to start over. By documenting your Edge environment, you avoid losing this information.

Therefore, the recommended approach is to use the drawing below to guide you through gathering the various FQDN and IP addresses that you need to enter into the Planning Tool. By documenting the current and proposed configuration, you can put the values in the proper context for your production environment. And, you are forced to think about how you will configure coexistence and new features such as simple URLs, file shares, dedicated A/V conferencing servers, and DNS load balancing.

Data Collection Template for Lync Server 2010 Single Consolidated Edge Environment

Data Collection Template for Lync Server 2010 Scaled Consolidated Edge (DNS Load Balanced) Environment

Data Collection Template for Lync Server 2010 Scaled Consolidated Edge (Hardware Load Balanced) Environment

Choosing a Topology

When you choose a topology, you can pick from the following supported topology options:

Single consolidated Edge using network address translation (NAT)
Scaled consolidated Edge using NAT and Domain Name System (DNS) load balancing
Scaled consolidated Edge using public IP and hardware load balancing

The following table summarizes the functionality available with the three supported Lync Server 2010 topologies. The column headings indicate the functionality available for a given Edge configuration option. Using the Scaled Edge (DNS load balancer) option as an example, you can see that it supports high availability, requires network address translation of Edge external interfaces, does not support publicly routable IP addresses, reduces cost because a hardware load balancer isn’t required and does not support failover for Exchange UM, public instant messaging (IM) connectivity (PIC) and federation with earlier versions of Office Communications Server.

Summary of Edge server Topology Options

	High availability	NAT allowed	Additional public IP required	Cost	Failover for Exchange UM (remote user), PIC and federation with older version of OCS
Single Edge	No	Yes	No	Yes	No
Scaled Edge (DNS load balancer)	Yes	Yes	No	Yes	No
Scaled Edge (Hardware load balancer)	Yes	No	Yes	No	Yes

Note:

The NAT Allowed and Additional Public IP required columns pertain only to the Edge external interfaces. A Yes in the NAT Allowed column means that the associated Edge Server topology supports the use of NAT on the Edge external interfaces. If you decide to use NAT, you must use it on all three external interfaces. A Yes in the Additional Public IP required column means that you will need extra public IP addresses to deploy the associated Edge Server topology.

The primary decision points for topology selection are High Availability and load balancing; and the requirement for high availability can influence the load balancing decision.

· High availability If you need high availability, deploy at least two Edge servers in a pool. A single Edge pool will support up to ten Edge servers. If more capacity is required, you can deploy multiple Edge pools. As a general rule, 10% of a given user base will need external access.

· DNS load balancing DNS load balancing is the recommended approach for load balancing Lync Server 2010 Edge servers when using NAT for the Edge external interfaces.

· Hardware load balancing Hardware load balancing is supported for load balancing Lync Server 2010 Edge servers when using publicly routable IP addresses for the Edge external interfaces. For example, you would use this approach in situations where failover is required for any of the following applications:

o PIC

o External access to Exchange 2007 UM or Exchange 2010 UM

o Federation with companies running Office Communications Server 2007 R2 or Office Communications Server 2007

These three applications will continue to operate but they are not DNS load balancing aware and will only connect to the first Edge Server in the pool; and if that server is unavailable, the connection will fail.