Publicação de proxy inverso

 

Tópico modificado em: 2012-07-22

Com o Microsoft Office Communications Server 2007 R2, era necessário publicar até cinco sites usando um servidor proxy reverso:

1. Arquivos de catálogo de endereços

2. Expansão do grupo de distribuição

3. Conteúdo de reunião

4. Arquivos de atualização do Phone Edition

5. Communicator Web Access

Para publicar em todos os cinco sites com o Office Communications Server 2007 R2, normalmente era necessário usar dois certificados de Proxy reverso:

• Nome da entidade = ExternalWebFarmFQDN (por exemple, webext.contoso.com)

• Nome da entidade = CWAExternalFQDN (por exemplo, cwa.contoso.com)

O Microsoft Lync Server 2010 software de comunicação suporta a publicação das mesmas informações e agora suporta a publicação externa de URLs simples para reuniões online. Além disso, a funcionalidade Communicator Web Access ainda existe, mas foi renomeada como Microsoft Lync Web App e está disponível como um serviço em um Servidor Front-End Standard Edition ou em cada Servidor Front-End em um pool Front-End, em vez de ficar em um servidor físico dedicado. O cliente agora é chamada de cliente do Lync Web App em vez de cliente do Communicator Web Access e suporta a funcionalidade reduzida (por exemplo, não há Lista de contatos ou recurso de A/V).

Dependendo de como você configurou a publicação de proxy reverso do Office Communications Server 2007 R2, as alterações nos requisitos de publicação do Lync Server 2010 podem aumentar o número de certificados públicos ou entradas de nome alternativo da entidade necessários, além do número de registros DNS (sistema de nomes de domínio). Por exemplo, se o formato de URL simples escolhido for dialin.<nome de domínio SIP> e meet.<nome de domínio SIP>, você precisará de dois registros DNS A – um para dialin.<nome de domínio SIP> e outro para meet.<nome de domínio SIP>. Isso além de outros registros DNS necessários para o proxy reverso.

Um formato opcional para URLs simples é o uso de uma entrada de domínio base comum, como join.<nome de domínio SIP>/dialin e join.<nome de domínio SIP>/meet. A vantagem desse formato de URL simples é que você precisa somente de um registro DNS A para as URLs simples meet e dialin. Além disso, você usa somente um entrada SAN curinga - *.<nome de domínio SIP>.

Requisitos de certificado de proxy reverso do Lync Server 2010

Nome da função/entidade	Nome alternativo da entidade	Usado para publicar	Exemplo de sintaxe de nome de entidade
externalWebServicesFQDN	N/D	Arquivos de Catálogo de endereços Expansão do Grupo de distribuição Conteúdo da conferência Arquivos de atualização de dispositivo	webext.contoso.com webdirext.contoso.com Observação: Normalmente, ExternalWebServicesFQDN = o FrontEndWebExternalFQDN e – se utilizado - DirectorWebExternalFQDN
URL/AdminFQDN simples	N/D	AdminFQDN não é publicado externamente. Ele é usado somente internamente.	N/D
URL/DialinFQDN simples	N/D	Informações sobre a conferência discada	dialin.contoso.com
URL/MeetFQDN simples	N/D	URL da reunião	meet.contoso.com
URL simples alternativo para discagem		Informações sobre a conferência discada	Join.contoso.com/dialin
URL simples alternativo para discagem		URL da reunião	Join.contoso.com/meet
Entradas com curinga para URLs simples (opcional)		Reunião e discagem	*.contoso.com

Observação:

O valor externalWebServicesFQDN é usado para usuários do Lync Server 2010. Em cenários de coexistência, é provável que já exista um valor de externalWebFarmFQDN para pools Office Communications Server 2007 R2 ou Office Communications Server 2007 existentes, mas os valores de FQDN são independentes. AdminFQDN não pode publicar externamente por motivos de segurança. DialinFQDN, MeetFQDN e AdminFQDN são conhecidos como URLs simples no Lync Server 2010 e é possível salvar um certificado dependendo como ele é definido. Esta tabela supõe que você escolheu URLs simples dedicadas para cada função. Para obter detalhes sobre como selecionar um formato de URL simples, consulte Opções de URLs simples.

Importante:

Se você criou e publicou URLs simples dedicadas (por exemplo, uma para cada função) e configurou um pool de Servidores Front-End com base nessa configuração, não será possível alterar o uso de uma URL simples para todas as funções (por exemplo, join.contoso.com/meet), a menos que você execute a configuração novamente em cada Servidor Front-End no pool. O mesmo requisito se aplica se estiver convertendo um formato de URL simples para o uso de URLs simples dedicadas.