Requisitos de DNS para URLs simples no Lync Server 2013
Tópico última modificação: 22-02-2013
O Lync Server 2013 dá suporte a URLs simples, que facilitam o ingresso em reuniões para seus usuários e facilitam o acesso às ferramentas administrativas do Lync Server para seus administradores. Para obter detalhes sobre URLs simples, consulte Planejamento de URLs simples no Lync Server 2013.
O Lync Server dá suporte às três URLs simples a seguir: Meet, Dial-In e Administração. Você precisa configurar URLs simples para Reunir e Discar, e Administração URL simples é opcional. Os registros DNS (Sistema de Nomes de Domínio) que você precisa para dar suporte a URLs simples dependem de como você definiu essas URLs simples e se deseja dar suporte à recuperação de desastre para URLs simples.
Opção de URL Simples 1
Na Opção 1, você cria uma NOVA URL base para cada URL simples.
Nota
Quando um usuário clica em um link de reunião de URL simples, o servidor que o registro DNS A resolve para determinar o software cliente correto a ser iniciado. Depois que o software cliente é iniciado, ele se comunica automaticamente com o pool em que a conferência está hospedada. Dessa forma, os usuários são direcionados para o servidor apropriado para o conteúdo de reunião, independentemente de qual servidor ou pool os registros DNS A de URL simples são resolvidos.
Opção de URL Simples 1
URL simples |
Exemplo |
Conhecer |
https://meet.contoso.com, https://meet.fabrikam.come assim por diante (um para cada domínio SIP em sua organização) |
Discagem |
https://dialin.contoso.com |
Administração |
https://admin.contoso.com |
Se você usar a Opção 1, deverá definir o seguinte:
Para cada URL simples meet, você precisa de um registro DNS A que resolva a URL para o endereço IP do Diretor, se você tiver um implantado. Caso contrário, ele deverá ser resolvido para o endereço IP do balanceador de carga de um pool de Front-Ends. Se você não tiver implantado um pool e estiver usando uma implantação de servidor Standard Edition, o registro DNS A deverá ser resolvido para o endereço IP de um servidor Standard Edition em sua organização.
Se você tiver mais de um domínio SIP em sua organização e usar essa opção, deverá criar o Meet simple URLs para cada domínio SIP e precisará de um registro DNS A para cada URL simples meet. Por exemplo, se você tiver contoso.com e fabrikam.com, criará registros DNS A para ambos https://meet.contoso.com e https://meet.fabrikam.com.
Como alternativa, se você tiver vários domínios SIP e quiser minimizar os requisitos de certificado e registro DNS para essas URLs simples, use a Opção 3, conforme descrito posteriormente neste tópico.
Para a URL simples de discagem, você precisa de um registro DNS A que resolva a URL para o endereço IP do Diretor, se você tiver um implantado. Caso contrário, ele deverá ser resolvido para o endereço IP do balanceador de carga de um pool de Front-Ends. Se você não tiver implantado um pool e estiver usando uma implantação de servidor Standard Edition, o registro DNS A deverá ser resolvido para o endereço IP de um servidor Standard Edition em sua organização.
A Administração URL simples é somente interna. Ele requer um registro DNS A que resolva a URL para o endereço IP do Diretor, se você tiver um implantado. Caso contrário, ele deverá ser resolvido para o endereço IP do balanceador de carga de um pool de Front-Ends. Se você não tiver implantado um pool e estiver usando uma implantação de servidor Standard Edition, o registro DNS A deverá ser resolvido para o endereço IP de um servidor Standard Edition em sua organização.
Opção de URL Simples 2
Com a Opção 2, as URLs de reunião, discagem e Administração simples têm uma URL base comum, como lync.contoso.com. Portanto, você precisa de apenas um registro DNS A para essas URLs simples, que resolve lync.contoso.com para o endereço IP de um pool de Diretores ou pool de Front-Ends. Se você não tiver implantado um pool e estiver usando uma implantação de servidor Standard Edition, o registro DNS A deverá ser resolvido para o endereço IP de um servidor Standard Edition em sua organização.
Observe que, se você tiver mais de um domínio SIP em sua organização, ainda deverá criar REUNIR URLs simples para cada domínio SIP e precisará de um registro DNS A para cada URL simples meet. Neste exemplo, enquanto três URLs simples são todas baseadas em lync.contoso.com, uma URL simples meet adicional para fabrikam.com é configurada com uma URL base diferente. Neste exemplo, você deve criar registros DNS A para ambos https://lync.contoso.com e https://lync.fabrikam.com. A Opção de URL Simples 3 mostra outra maneira de lidar com nomes e registros DNS A se você tiver vários domínios SIP.
Opção de URL Simples 2
URL simples |
Exemplo |
Conhecer |
https://lync.contoso.com/Meet, https://lync.fabrikam.com/Meete assim por diante (um para cada domínio SIP em sua organização) |
Discagem |
https://lync.contoso.com/Dialin |
Administração |
https://lync.contoso.com/Admin |
Opção de URL Simples 3
A opção 3 será mais útil se você tiver muitos domínios SIP e desejar que eles tenham URLs simples separadas, mas desejar minimizar os requisitos de certificado e registro DNS para essas URLs simples. Neste exemplo, você precisa de apenas um registro DNS A, que resolve lync.contoso.com endereço IP de um pool de Diretores ou pool de Front-Ends.
Opção de URL Simples 3
URL simples |
Exemplo |
Conhecer |
https://lync.contoso.com/contosoSIPdomain/Meet https://lync.contoso.com/fabrikamSIPdomain/Meet |
Discagem |
https://lync.contoso.com/contosoSIPdomain/Dialin |
Administração |
https://lync.contoso.com/contosoSIPdomain/Admin |
Opção de recuperação de desastre para URLs simples
Se você tiver vários sites que contêm pools de Front-End e seu provedor DNS der suporte a GeoDNS, poderá configurar seus registros DNS para URLs simples para dar suporte à recuperação de desastre, para que a funcionalidade de URL simples continue mesmo se um pool inteiro de Front-Ends ficar inativo. Esse recurso de recuperação de desastre dá suporte a URLs simples de Reunião e Discagem.
Para configurar isso, crie dois endereços GeoDNS. Cada endereço tem dois registros DNS A ou CNAME que são resolvidos para dois pools que são emparelhados para fins de recuperação de desastre. Um endereço GeoDNS é usado para acesso interno e é resolvido para o FQDN da Web interno ou o endereço IP do balanceador de carga para os dois pools. O outro endereço GeoDNS é usado para acesso externo e é resolvido para o FQDN da Web externo ou o endereço IP do balanceador de carga para os dois pools. A seguir está um exemplo para a URL de Reunião simples, usando os FQDNs para os pools.
Meet-int.geolb.contoso.com
Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
Meet-ext.geolb.contoso.com
Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
Em seguida, crie registros CNAME que resolvam a URL de Reunião simples (como meet.contoso.com) para os dois endereços GeoDNS.
Nota
Se sua rede usa o hairpinning (roteando todo o tráfego de URL simples por meio do link externo, incluindo o tráfego que vem de dentro de sua organização), você pode apenas configurar o endereço GeoDNS externo e resolver sua URL de Reunião simples para apenas esse endereço externo.
Ao usar esse método, você pode configurar cada endereço GeoDNS para usar um método round robin para distribuir solicitações para os dois pools ou para se conectar principalmente a um pool (como o pool localizado geograficamente mais próximo) e usar o outro pool somente em caso de falha de conectividade.
Você pode definir a mesma configuração para a URL simples de Discagem. Para fazer isso, crie registros adicionais como aqueles no exemplo anterior, substituindo dialin
meet
nos registros DNS. Para obter Administração URL simples, use uma das três opções listadas anteriormente nesta seção.
Depois que essa configuração for configurada, você deverá usar um aplicativo de monitoramento para configurar o monitoramento HTTP para observar falhas. Para acesso externo, monitore para garantir que as solicitações de descoberta automática HTTPS GET para o FQDN da Web externo ou o endereço IP do balanceador de carga para os dois pools sejam bem-sucedidas. Por exemplo, as solicitações a seguir não devem conter nenhum cabeçalho ACCEPT e devem retornar 200 OK.
HTTPS GET Pool1ExternalWebFQDN.contoso.com/autodiscover/autodiscoverservice.svc/root
HTTPS GET Pool2ExternalWebFQDN.contoso.com/autodiscover/autodiscoverservice.svc/root
Para acesso interno, você deve monitorar a porta 5061 no FQDN da Web interno ou no endereço IP do balanceador de carga para os dois pools. Se alguma falha de conectividade for detectada, o VIP para esses pools deverá fechar as portas 80, 443 e 444.