Publicación de proxy inverso

 

Última modificación del tema: 2012-07-22

Con Microsoft Office Communications Server 2007 R2, era necesario publicar hasta cinco sitios web con un servidor proxy inverso:

1. Archivos de la libreta de direcciones

2. Expansión de los grupos de distribución

3. Contenido de reuniones

4. Archivos de actualización de Phone Edition

5. Communicator Web Access

Para publicar los cinco sitios web con Office Communications Server 2007 R2, normalmente era necesario usar dos certificados de proxy inverso:

• Nombre de sujeto = ExternalWebFarmFQDN (por ejemplo, webext.contoso.com)

• Nombre de sujeto = CWAExternalFQDN (por ejemplo, cwa.contoso.com)

El software de comunicaciones de Microsoft Lync Server 2010 permite publicar la misma información y ahora también admite la publicación externa de direcciones URL sencillas para reuniones en línea. Asimismo, continúa existiendo la funcionalidad de Communicator Web Access pero ahora se denomina Microsoft Lync Web App y está disponible como servicio en un servidor front-end Standard Edition o en cada servidor front-end en un grupo de servidores front-end, en lugar de en un servidor físico dedicado. Ahora se hace referencia al cliente como cliente de Lync Web App, en lugar de como cliente de Communicator Web Access, y se admite la funcionalidad reducida (por ejemplo, no existe la lista de contactos ni la capacidad de A/V).

Dependiendo de cómo se haya configurado la publicación del servidor proxy inverso de Office Communications Server 2007 R2, los cambios en los requisitos de publicación de Lync Server 2010 pueden aumentar el número de certificados públicos o las entradas de nombre alternativo de sujeto necesarias, así como el número de registros del sistema de nombres de dominio (DNS). Por ejemplo, si el formato de dirección URL sencilla elegido es dialin. <nombre de dominio SIP> y meet.<nombre de dominio SIP>, necesitará dos registros A de DNS: uno para dialin.<nombre de dominio SIP> y otro para meet.<nombre de dominio SIP>. Todo ello además de otros registros DNS necesarios para el proxy inverso.

Un formato opcional para las direcciones URL sencillas es el uso de una entrada de dominio de base común, como join.<nombre de dominio SIP>/dialin y join.<nombre de dominio SIP>/meet. La ventaja de este formato es que solo se necesita un registro A de DNS para las dos direcciones URL sencillas. Además, solo se utiliza una entada SAN de comodín - *.<nombre de domino SIP>.

Requisitos de certificados de proxy inverso de Lync Server 2010

Nombre de rol o sujeto	Nombre alternativo de sujeto	Usado para publicar	Ejemplo de sintaxis de nombre de sujeto
externalWebServicesFQDN	N/D	Archivos de la libreta de direcciones Expansión de los grupos de distribución Contenido de conferencias Archivos de actualización de dispositivos.	webext.contoso.com webdirext.contoso.com Nota Normalmente, ExternalWebServicesFQDN = FrontEndWebExternalFQDN y, si se usa, DirectorWebExternalFQDN
Dirección URL sencilla o AdminFQDN	N/D	AdminFQDN no se publica de forma externa. Solo se usa internamente.	N/D
Dirección URL sencilla o DialinFQDN	N/D	Información de conferencia de acceso telefónico local	dialin.contoso.com
Dirección URL sencilla o MeetFQDN	N/D	Dirección URL de reunión	meet.contoso.com
Alternar direcciones URL sencillas para Dialin		Información de conferencia de acceso telefónico local	Join.contoso.com/dialin
Alternar direcciones URL sencillas para Dialin		Dirección URL de reunión	Join.contoso.com/meet
Entradas de comodín para direcciones URL sencillas (opcional)		Meeting y Dial-in	*.contoso.com

Nota

• El valor externalWebServicesFQDN se usa para los usuarios de Lync Server 2010. En escenarios de coexistencia es probable que ya haya un valor externalWebFarmFQDN para los grupos de servidores de Office Communications Server 2007 R2 o Office Communications Server 2007 existentes, pero los valores de FQDN son independientes entre sí.

• AdminFQDN tiene bloqueada la publicación externa por motivos de seguridad.

• En Lync Server 2010, se hace referencia a DialinFQDN, MeetFQDN y AdminFQDN como direcciones URL sencillas, y es posible guardar un certificado según cómo estén definidos. En esta tabla se da por supuesto que ha elegido direcciones URL sencillas dedicadas para cada rol. Para obtener más información sobre la selección de un formato de dirección URL sencilla, consulte Opciones de dirección URL sencilla.

Importante:

Si crea y publica direcciones URL sencillas dedicadas (por ejemplo, una para cada rol) y, a continuación, instala un grupo de servidores front-end basado en dicha configuración, no podrá pasar a usar una sola dirección URL para todos los roles (por ejemplo, join.contoso.com/meet), a menos que vuelva a ejecutar la instalación en cada servidor front-end del grupo de servidores. El mismo requisito se aplica si realiza la conversión desde un único formato de dirección URL sencilla para usar direcciones URL sencillas dedicadas.