Requisitos técnicos para mobilidade

Requisitos do Site

A sua topologia deve atender aos seguintes requisitos para dar suporte ao Serviço de Mobility e o Serviço de Descoberta Automática:

• O FQDN interno da web do Pool de Front-Ends deve ser diferente do FQDN externo da web do Pool de Front-Ends.

• O FQDN interno da web somente deve resolver à rede corporativa e ser acessível a partir dela .

• O FQDN da Web Externo (exceto para a URL do Serviço de Mobilidade, que é abordado pelas solicitações de usuário interno e externo) deve apenas resolver e ser acessível pela Internet.

• Para um usuário que está dentro da rede corporativa, a URL do Serviço de Mobility deverá ser direcionada ao FQDN externo da web. Este requisito é para o Serviço de Mobility e se aplica somente a esta URL.

• Para um usuário que está fora da rede corporativa, a solicitação deve ir ao FQDN externo da web do Pool de Front-Ends ou da Diretor.

• Se você tiver um ambiente DNS inconsistente e os clientes de dispositivo móvel se terão conexões sem fio, será necessário configurar o FQDN externo da web no DNS interno com o endereço de IP público.

Requisitos de DNS

Sua topologia deve atender aos requisitos de DNS descritos nas seções a seguir para dar suporte ao Serviço de Mobility e o Serviço de Descoberta Automática.

Requisitos da Descoberta Automática e Notificação de Push

Se você oferecer suporte à descoberta automática, será necessário criar os seguintes registros DNS para cada domínio SIP:

• Um registro DNS interno para suportar usuários móveis que se conectam de dentro da rede da organização

• Um registro DNS externo ou público para suportar usuários móveis que se conectam pela Internet

• Um registro DNS, externo ou público para suportar a Notificação de Push

A URL de descoberta automática interna não deve ser endereçável de fora da rede. A URL de descoberta automática externa não deve ser endereçável de dentro da rede. No entanto, se você não puder atender este requisito para a URL externa, a funcionalidade do cliente móvel não deve ser afetada, porque a primeira tentativa sempre é com a URL interna.

Os registros DNS podem ser registros CNAME ou registros A (host).

É preciso criar os seguintes registros DNS internos:

Registros DNS internos

Tipo de registro	Nome do host	Resolve para
A (Host)	lyncweb.contoso.com ( exemplo de URL de serviços da web externos)	Registro localizado no DNS interno que resolve ao endereço IP externo da URL dos serviços web externos, por exemplo https://lyncweb.contoso.com

E um dos seguintes registros DNS internos adicionais:

Tipo de registro	Nome do host	Resolve para
CNAME	lyncdiscoverinternal.<domíniodosip>	FQDN de serviços da web interno do seu Pool de diretores, se tiver um, ou do seu Pool de Front-Ends se não tiver um Diretor
A (host)	lyncdiscoverinternal.<domíniodosip>	Endereço IP do Web Services interno (endereço IP virtual (VIP) se você usar um balanceador de carga) do seu Pool de diretores, se tiver um, ou do seu Pool de Front-Ends se você não tiver um Diretor

É necessário criar um dos seguintes registros DNS externos:

Registros DNS externos

Tipo de registro	Nome do Host	Resolve para
CNAME	lyncdiscover.<domíniodosip>	FQDN do Web Services externo do seu Pool de diretores, se tiver um, ou do seu Pool de Front-Ends se não tiver um Diretor
A (host)	lyncdiscover.<domíniodosip>	Endereço IP público ou externo do proxy reverso

Observação:
O tráfego externo passa pelo proxy reverso.

Observação:

Os clientes de dispositivo móvel não suportam vários certificados de SSL (Secure Sockets Layer) de domínios diferentes. Portanto, não há redirecionamento CNAME para diferentes domínios por HTTPS. Por exemplo, um registro DNS CNAME para lyncdiscover.contoso.com que redireciona a um endereço de director.contoso.net não é suportado por HTTPS. Na topologia, um cliente de dispositivo móvel precisa usar HTTP para a primeira solicitação, para que o redirecionamento de CNAME seja resolvido por HTTP. As solicitações subseqüentes usam HTTPS. Para oferecer suporte a esse cenário, você precisará configurar o proxy inverso com uma regra de publicação na web para a porta 80 (HTTP). Para obter detalhes, consulte "Para criar uma regra de publicação na web para a porta 80" in Configurando o proxy inverso para mobilidade. O redirecionamento de CNAME ao mesmo domínio é suportado por HTTPS. Nesse caso o certificado do domínio de destino aborda o domínio de origem.

Tipo de Registro	Definição	Resolver para
SRV	_sipfederationtls._tcp.<nome de domínio SIP> para registro de Host A do Serviço de Borda de Acesso	por exemplo, _sipfedrationtls._tcp.contoso.com com porta definida de TCP 5061 para sip.contoso.com Importante: Um registro SRV deve apontar para um A no mesmo domínio SIP

Requisitos de Firewall e de Porta

O Serviço de Mobility requer as seguintes duas portas de escuta de Serviços Web em Servidores Front-End ou em servidores Standard Edition. Você define manualmente essas portas durante o processo de implantação usando o cmdlet do Set-CsWebServer. Para obter detalhes, consulte Configurando portas de servidor interno para mobilidade.

Você também deve criar uma regra de permissão para TCP 5061 para deferação com o provedor online para Notificação de Push. Para obter detalhes, consulte Arquitetura de referência.

• Porta 5086, usada para escutar solicitações de mobilidade de dentro da rede corporativa. Esta é uma porta SIP usada pelo processo interno do serviço de Mobility.

• Porta 5087, usada para escutar solicitações de mobilidade da Internet. Esta é uma porta SIP usada pelo processo externo do serviço de Mobility.

Se você oferecer suporte a notificações de envio e deseja que os dispositivos móveis da Apple recebam notificações de envio pela rede Wi-Fi, você precisa abrir a porta 5223 em sua rede corporativa Wi-Fi. A porta 5223 é uma porta TCP de saída usada pela APNS (Apple Push Notification Service). O dispositivo móvel ou o serviço de notificação podem iniciar a conexão, que requer disponibilidade de porta de saída na rede WiFi da empresa. Para obter detalhes, consulte http://support.apple.com/kb/TS1629?viewlocale=pt_BR?viewlocale=pt_BR e https://developer.apple.com/library/ios/#technotes/tn2265/_index.html

Requisitos de Certificação

Se você oferecer suporte à descoberta automática para clientes móveis do Lync, precisará alterar as listas de nome alternativo da entidade em certificados para oferecer suporte a conexões seguras de clientes móveis. Você precisa solicitar e atribuir novos certificados, adicionando as entradas de nome alternativo da entidade descritas nesta seção para cada Servidor Front-End e Diretor que executa o Serviço de Descoberta Automática. A abordagem recomendada é também de alterar as listas de nomes alternativos da entidade de certificados para os proxies reversos. Será necessário adicionar entradas de nome alternativo da entidade para cada domínio SIP na organização.

Reemitir certificados usando uma autoridade de certificação interna é normalmente um processo simples, mas a adição de várias entradas de nome alternativo da entidade a certificados públicos usados pelo proxy reverso pode ser cara. Se você tiver muitos domínios SIP, tornando a adição de nomes alternativos da entidade muito cara, é possível configurar o proxy inverso para fazer a solicitação inicial do Serviço de Descoberta Automática pela porta 80 usando HTTP, em vez da porta 443 usando HTTPS (configuração padrão). A solicitação é redirecionada para a porta 8080 no Diretor ou Pool de Front-Ends. Quando você publicar a solicitação inicial do Serviço de Descoberta Automática na porta 80, você não precisará alterar certificados de proxy reverso, pois a solicitação usa HTTP em vez de HTTPS. Essa abordagem é aceita, mas não recomendada.

Observação:
Para obter mais detalhes sobre como usar a porta 80 para a solicitação inicial, consulte "Processo de Descoberta Automática Inicial usando a Porta 80" em Requisitos do serviço de descoberta automática na documentação de Planejamento para Usuários Externos.

Observação:

Se a infra-estrutura do Lync Server 2010 usa certificados internos que são emitidos por uma CA (autoridade de certificação interna) e você planeja oferecer suporte a dispositivos móveis com conexão sem fio, a cadeia do certificado raiz da autoridade de certificação interna deve ser instalada nos dispositivos móveis ou você deve alterar para um certificado público na infra-estrutura do Lync Server.

Esta seção descreve os nomes alternativos da entidade necessários para os seguintes certificados:

• Servidor de Borda ou Pool do servidor de borda

• Diretor ou Pool de diretores

• Servidor Front-End ou Pool de Front-Ends

• Proxy reverso

Requisitos do Certificado do Pool de Diretores

Observação:
Como alternativa, é possível usar SAN=*.<sipdomain> apenas para registros de Descoberta Automática (lyncdiscover e lyncdicoverinternal).

Requisitos do Certificado do Pool de Front-Ends

Observação:
Como alternativa, é possível usar SAN=*.<sipdomain> aoenas para registros de Descoberta Automática (lyncdiscover e lyncdicoverinternal).

Requisitos do Certificado (CA público) do Proxy Reverso

Observação:
Você atribui este certificado para o Ouvinte SSL no proxy inverso.

Requisitos de IIS (Serviços de Informações da Internet)

Recomendamos o uso do IIS 7.5 para mobilidade. O instalador do Serviço de Mobility define alguns sinalizadores ASP.NET para melhorar o desempenho. O IIS 7.5 é instalado por padrão no Windows Server 2008 R2 e o instalador do Serviço de Mobility altera automaticamente as configurações do ASP.NET. Se você usar o IIS 7.0 no Windows Server 2008, será necessário alterar essas configurações manualmente. Para obter detalhes, consulte Instalando os serviços de descoberta automática e mobilidade.

Requisitos do Balanceador de Carga de Hardware

Se o ambiente inclui um Pool de Front-Ends, os IPs virtuais (VIPs) os Serviços Web no balanceador de carga de hardware usado para o tráfego de Serviços da Web deve ser configurado para persistência baseada em cookie. A persistência baseada em cookie garante que várias conexões de um único cliente sejam enviados a um servidor para manter o estado da sessão. Os cookies devem atender a requisitos específicos. Para obter detalhes sobre os requisitos de cookie, consulte Requisitos de balanceamento de carga.

Se você planeja suportar clientes móveis do Lync através da rede Wi-Fi interna, é necessário configurar VIPS de serviços da Web internos para persistência baseada em cookie, como descrito para os VIPs de Serviços Web externos. Nessa situação, você não deve usar persistência de source_addr para os VIPs de Serviços Web internos no balanceador de carga de hardware. Para obter detalhes, consulte Requisitos de balanceamento de carga.

Requisitos de Proxy reverso

Se você oferecer suporte à descoberta automática para clientes de dispositivos móveis do Lync, será necessário criar uma nova regra de publicação na web da seguinte maneira:

• Se você decidir atualizar as listas de nomes alternativos da entidade em certificados de proxy reverso e usar HTTPS para a solicitação inicial do Serviço de Descoberta Automática, você precisa criar uma nova regra de publicação da web para lyncdiscover. <sipdomain> . Verifique se existe uma regra de publicação na web para a URL de serviços da Web externa no Pool de Front-Ends.

• Se você decidir usar HTTP para a solicitação inicial do Serviço de Descoberta Automática para que não seja necessário atualizar a lista de nomes alternativos da entidade em certificados de proxy reverso, você precisará criar uma nova regra de publicação na web para a porta 80 (HTTP).