Requisitos técnicos para mobilidade

 

Tópico modificado em: 2013-03-05

Os usuários de dispositivos móveis encontram vários cenários de aplicativos de dispositivos móveis que requerem planejamento especial. Por exemplo, um usuário pode começar a usar um aplicativo de celular enquanto estiver fora do trabalho por meio da rede 3G, alternar para rede Wi-Fi corporativa ao chegar no trabalho e alternar para 3G novamente quando deixar o edifício. Você precisa planejar seu ambiente para suportar tais transições da rede e garantir uma experiência de usuário consistente. Esta seção descreve os requisitos de infra-estrutura que você precisa atender para oferecer suporte a aplicativos de celular e a descoberta automática de recursos de dispositivos móveis.

Quando você usa a descoberta automática, os dispositivos móveis usam o Domain Name System (DNS) para localizar os recursos. Durante a pesquisa de DNS, primeiro há uma tentativa de conexão ao FQDN (nome de domínio totalmente qualificado) que está associado ao registro DNS interno (lyncdiscoverinternal.<sipdomain>). Se uma conexão não pode ser feita usando o registro DNS interno, uma tentativa de conexão usando o registro DNS externo (lyncdiscover.<sipdomain>). Um dispositivo móvel que é interno à rede se conecta à URL interna do Serviço Descoberta Automática e um dispositivo móvel que é externo à rede se conecta à URL externa do Serviço de Descoberta Automática. As solicitações externas vão através do proxy reverso. O serviço de Descoberta Automática do Microsoft Lync Server 2010 retorna todas as URLs de serviços Web para o pool inicial do usuário, incluindo URLs do Serviço de Mobility. No entanto, a URL interna do serviço de dispositivos móveis e a URL externa do serviço de de dispositivos móveis estão associados com o FQDN de Serviços Web externos. Portanto, independentemente de um dispositivo móvel ser interno ou externo à rede, o dispositivo sempre conecta ao Serviço de Mobility do Microsoft Lync Server 2010 externamente através do proxy reverso.

Observação:
Embora os aplicativos de celular também podem conectar-se a outros serviços do Lync Server, como o Serviço de Catálogo de Endereços, este requisito para enviar todas as solicitações da web de aplicativos de celular para o mesmo FQDN externo da web se aplica somente ao Serviço de Mobility. Outros serviços não exigem essa configuração.

O diagrama a seguir ilustra o fluxo de solicitações da web de aplicativo de dispositivos móveis para o Serviço de Mobility e o Serviço de Descoberta Automática.

Fluxo de solicitações do aplicativo de celular do Serviço de Mobility e o Serviço de Descoberta Automática

Para ofrecer suporte aos usuários de dispositivos móveis de dentro e fora da rede corporativa, os FQDNs de web interno e externo devem atender a alguns pré-requisitos. Além disso, talvez você precise atender a outros requisitos, dependendo dos recursos escolhidos para implementar:

• Novos registros DNS CNAME ou A para descoberta automática

• Registro SRV de DNS, para federação com o Push Notification Clearing House

• Novas portas para servidores internos

• Nova regra de firewall, se você quiser dar suporte a notificações de envio através de sua rede Wi-Fi

• Nomes alternativos da entidade em certificados de servidor interno e certificados de proxy reverso para descoberta automática

• Servidor Front-End alterações na configuração do balanceador de carga de hardware para a persistência baseada em cookie

• Nova regras de publicação da web no proxy inverso para a descoberta automática

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.

Requisito de URL do Serviço de Mobility

Em uma configuração padrão, um usuário que está conectado à rede interna via Wi-Fi sempre será retornado a URL externa do Serviço de Mobility para seu pool inicial. O dispositivo do usuário deve ser capaz de consultar a zona DNS interna e resolver o FQDN de Serviços Web externos do Lync ao endereço IP da interface externa do proxy inverso. O usuário deve fazer uma conexão de saída fixa ao Serviço de Mobility através do proxy reverso.

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

Descrição	Entrada do nome alternativo da entidade
Serviço de Borda de Acesso	SAN=sip.<domíniodosip>

Requisitos do Certificado do Pool de Diretores

Descrição	Entrada do nome alternativo da entidade
URL do Serviço de Descoberta Automática Interno	SAN=lyncdiscoverinternal.<domíniodosip>
URL externa do Serviço de Descoberta Automática	SAN=lyncdiscover.<domíniodosip>

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

Descrição	Entrada do nome alternativo da entidade
URL do Serviço de Descoberta Automática Interno	SAN=lyncdiscoverinternal.<domíniodosip>
URL externa do Serviço de Descoberta Automática	SAN=lyncdiscover.<domíniodosip>

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

Descrição	Entrada do nome alternativo do assunto
URL externa do Serviço de Descoberta Automática	SAN=lyncdiscover.<domíniodosip>

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).