Tenants de primeira geração: solução de problemas se você encontrar problemas de implantação de pod do Horizon Cloud de primeira geração ou de vinculação de domínio pela primeira vez

Se a rede do seu ambiente não estiver configurada corretamente para uso com o pod do Horizon Cloud de primeira geração no Microsoft Azure, o processo para compilar o pod poderá ficar congelado em um estado PENDENTE ou a ação de pós-implantação para realizar o BIND de domínio em seu ambiente do Active Directory poderá falhar. As duas causas mais comuns relacionadas à rede são falha ao abrir as portas de saída necessárias e falha ao ativar o DNS para resolver os endereços internos e externos. Seguindo as etapas de solução de problemas aqui, você pode executar alguns testes para verificar se as portas de saída necessárias estão abertas e se o DNS pode resolver os endereços internos e externos.

Importante: Essas informações aplicam-se apenas quando você tem acesso a um ambiente de tenant de primeira geração na camada de controle de primeira geração. Conforme descrito em KB-92424, a camada de controle de primeira geração atingiu o fim da disponibilidade (EOA). Consulte esse artigo para obter detalhes.

Os requisitos gerais de rede para implantar com êxito um pod estão descritos na lista de verificação de pré-requisitos e são descritos em Tenants de primeira geração: defina as configurações do servidor DNS necessárias pela topologia de VNet que você usará para os pods do Horizon Cloud no Microsoft Azure e Tenants de primeira geração: Implantações do Horizon Cloud on Microsoft Azure: requisitos de resolução de nomes de host e nomes DNS. Se a rede do seu ambiente não atender a esses requisitos, você encontrará um ou estes dois problemas:

Problemas Causas comuns

Problemas	Causas comuns
A página Introdução mostra o pod no estado pendente e que nunca muda para o estado conectando. Geralmente um pod fica no estado pendente por cerca de 10 minutos (exceto ao implantar um pod na nuvem do Microsoft Azure China, o que leva mais tempo). Até mesmo quando o pod tiver sido implantado com êxito, quando você tentar registrar seu Active Directory, haverá falha na etapa de BIND de domínio com o erro `Unable to register Active Directory`	As portas de saída necessárias não estão abertas ou estão bloqueadas pelo seu ambiente de firewall. Se as portas de saída necessárias não estiverem abertas ou estiverem bloqueadas por um firewall, isso impedirá que o software de pod baixe para o ambiente de nuvem do Microsoft Azure e se conecte novamente à camada de controle de nuvem do Horizon Cloud de forma segura. Como resultado, ocorre o problema de estado pendente. O servidor DNS do VNet não está configurado corretamente para apontar para um servidor DNS válido que possa resolver os dois nomes de máquina interno e externo. Embora o servidor DNS do VNet esteja apontando corretamente para um servidor DNS, esse servidor DNS não pode resolver os dois nomes de máquina interno e externo. Se nenhuma resolução DNS para nomes de máquina externos for fornecida para o VNet, poderá ocorrer o problema de estado pendente e de BIND de domínio. Por exemplo, se o DNS não puder ser resolvido no Active Directory nos Controladores de Domínio, a etapa de BIND de domínio falhará. Para obter detalhes sobre a configuração de DNS do VNet, consulte Tenants de primeira geração: defina as configurações do servidor DNS necessárias pela topologia de VNet que você usará para os pods do Horizon Cloud no Microsoft Azure.

A página Introdução mostra o pod no estado pendente e que nunca muda para o estado conectando. Geralmente um pod fica no estado pendente por cerca de 10 minutos (exceto ao implantar um pod na nuvem do Microsoft Azure China, o que leva mais tempo).
Até mesmo quando o pod tiver sido implantado com êxito, quando você tentar registrar seu Active Directory, haverá falha na etapa de BIND de domínio com o erro Unable to register Active Directory

As portas de saída necessárias não estão abertas ou estão bloqueadas pelo seu ambiente de firewall. Se as portas de saída necessárias não estiverem abertas ou estiverem bloqueadas por um firewall, isso impedirá que o software de pod baixe para o ambiente de nuvem do Microsoft Azure e se conecte novamente à camada de controle de nuvem do Horizon Cloud de forma segura. Como resultado, ocorre o problema de estado pendente.
O servidor DNS do VNet não está configurado corretamente para apontar para um servidor DNS válido que possa resolver os dois nomes de máquina interno e externo.
Embora o servidor DNS do VNet esteja apontando corretamente para um servidor DNS, esse servidor DNS não pode resolver os dois nomes de máquina interno e externo.

Se nenhuma resolução DNS para nomes de máquina externos for fornecida para o VNet, poderá ocorrer o problema de estado pendente e de BIND de domínio. Por exemplo, se o DNS não puder ser resolvido no Active Directory nos Controladores de Domínio, a etapa de BIND de domínio falhará. Para obter detalhes sobre a configuração de DNS do VNet, consulte Tenants de primeira geração: defina as configurações do servidor DNS necessárias pela topologia de VNet que você usará para os pods do Horizon Cloud no Microsoft Azure.

Para executar alguns testes que verificarão se a configuração de DNS pode resolver os nomes internos e externos e verificarão se as portas de saída necessárias estão abertas, você pode implantar uma pequena máquina virtual (VM) de teste em sua assinatura do Microsoft Azure e usar essa VM para executar esses testes de rede. Veja a sequência de alto nível das etapas de solução de problemas:

Crie um par de chaves SSH.
Crie a VM de teste na sua assinatura do Microsoft Azure.
Conecte-se a essa VM de teste.
Execute os testes de rede.
Quando o teste é feito, exclua a VM de teste e todos os artefatos relacionados ao teste que foram criados no seu ambiente do Microsoft Azure durante esta solução de problemas.

Observação: Se você não excluir os artefatos relacionados ao teste e usar posteriormente a ação Excluir do console para excluir o pod, poderão ocorrer resultados inesperados. Ao excluir um pod, o sistema verifica as sub-redes do pod para verificar se tudo o que estiver conectado às sub-redes pertence ao pod, de acordo com o ID do pod. Se o sistema determinar que VMs adicionais, discos de VM, IPs ou outros artefatos estão conectados às sub-redes do pod, o sistema não poderá excluir o pod de forma clara.

Para obter detalhes sobre como executar os testes de solução de problemas, consulte as seções a seguir.

Importante: Embora todos esses testes manuais sejam bem-sucedidos, se você estiver direcionando todo o tráfego para fora por meio de sua rede local e permitir apenas a passagem do tráfego autenticado, mas não tiver fornecido valores para usar um proxy no assistente de implantação de pod, a implantação do pod poderá ficar bloqueada no estado pendente. Se essa descrição corresponder à sua situação, você deverá excluir o pod da página Introdução, executar novamente o assistente de implantação de pod e especificar as informações de proxy necessárias.

Solução de problemas de implantação de pod do Horizon Cloud: criar um par de chaves SSH

Como parte dessa solução de problemas, uma VM Linux de teste é implantada em sua assinatura do Microsoft Azure. Para autenticar a VM Linux de teste, você precisa de um par de chaves SSH. Crie o par de chaves no sistema que você usa para o SSH se conectar à VM de teste. Essa etapa será opcional se você já tiver um par de chaves nesse sistema.

Para criar esse par de chaves SSH, você pode usar um sistema Microsoft Windows ou Linux. As etapas para os dois tipos de sistemas estão descritas aqui. Selecione as etapas mais apropriadas para sua situação.

Criar um par de chaves SSH em um sistema do Microsoft Windows

Use estas etapas quando você estiver usando um sistema do Microsoft Windows para o SSH se conectar à VM de teste do Linux sendo implantada em sua assinatura do Microsoft Azure.

Quando você criar a VM de teste no Microsoft Azure, usará o conteúdo do arquivo de chave pública gerado. Se você já tiver um par de chaves SSH existente no sistema do Microsoft Windows que será usado para se conectar com a VM de teste, poderá ignorar essa etapa e prosseguir com a criação da VM de teste, conforme descrito em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure.

Ao seguir essas etapas, você gera o par de chaves SSH, copia o conteúdo do arquivo de chave pública para que possa usá-lo ao criar a VM de teste e carrega a chave privada para a ferramenta PuTTY Pageant. Pageant é um agente de autenticação de SSH que pode conter as chaves privadas na memória. Ao manter a chave privada na memória, a chave privada é aplicada automaticamente em qualquer sessão de SSH do sistema do Microsoft Windows, tornando-a mais fácil de ser usada.

Pré-requisitos

Um sistema do Microsoft Windows não tem o software de par de chaves SSH instalado por padrão. Verifique se o software de geração de par de chaves SSH está instalado no sistema que você está planejando usar. Você pode usar qualquer software de geração de par de chaves SSH. As etapas abaixo descrevem como usar o software PuTTY no Microsoft Windows para criar o par de chaves SSH. Você pode obter o software PuTTY em www.putty.org. Após a instalação, o conjunto de ferramentas PuTTY está disponível. A seguinte captura de tela mostra um exemplo das ferramentas PuTTY no menu Iniciar.

Captura de tela das ferramentas PuTTY conforme são exibidas no menu Iniciar do Microsoft Windows 10

Procedimento

No seu sistema do Microsoft Windows, inicie PuTTYgen (o gerador de chaves do PuTTY).
A janela PuTTY Key Generator é exibida. Como destacado na seguinte captura de tela, o objetivo é gerar um par de chaves públicas-privadas, do tipo RSA SSH-2 e ter 2048 bits.
Verifique se a opção SSH-2RSA está selecionada, se 2048 está definido como o número de bits e clique em Gerar. A janela muda para a janela Chave que exibe uma barra de progresso.
Siga as orientações na tela para mover o cursor aleatoriamente na área em branco abaixo da barra de progresso. Como diz a interface do usuário do PuTTY, mover o cursor na área adiciona aleatoriedade necessária ao processo.
Salve a chave privada no sistema inserindo uma senha da chave e clique em Salvar chave privada.

Observação: Usar uma senha da chave é uma prática recomendada opcional. No entanto, se você clicar em Salvar chave privada sem inserir uma senha da chave, uma janela pop-up perguntará se você deseja salvar a chave privada sem uma senha da chave.

A chave privada é salva como um arquivo PPK. Depois de clicar em Salvar chave privada, você pode navegar para um diretório no sistema local, digitar um nome de arquivo e salvar o arquivo.
Use o botão Salvar chave pública para salvar a chave pública em uma localização da qual você pode copiar quando você cria a VM de teste.
Inicie o Pageant, o agente de autenticação de SSH do PuTTY.
Em um sistema Windows 10, o ícone do Pageant será carregado na bandeja do sistema.
Adicione a chave privada ao Pageant clicando com o botão direito do mouse nesse ícone de bandeja do sistema, clicando em Adicionar Chave e usando a janela de seleção de arquivo para navegar e selecione o arquivo de chave privada (PPK) salvo.

Observação: Se você tiver especificado uma senha da chave quando salvou o arquivo de chave privada anteriormente, uma caixa será exibida para você digitar essa senha.

Resultados

Nesse ponto, a chave privada é carregada no Pageant. Você pode usar a opção Exibir Chaves no menu de ação para ver a chave na lista de chaves carregadas. Quando você inicia uma sessão de SSH usando PuTTY, o PuTTY irá recuperar a chave automaticamente do Pageant e usará a chave para autenticar sem a necessidade de digitar sua senha. Mais tarde, quando você terminar as sessões SSH em execução e desejar desligar o Pageant, use a opção Sair do menu clique de clique direito do mouse do ícone da bandeja do Pageant.

O que Fazer Depois

Crie a VM de teste seguindo as etapas em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure.

Criar um par de chaves SSH em um sistema Linux

Siga estas etapas ao usar um sistema Linux para se conectar por SSH à VM de teste Linux que você estiver implantando na sua assinatura do Microsoft Azure.

Nas etapas para a criação da VM de teste no Microsoft Azure, você usará o conteúdo do arquivo de chave pública gerada. Se você já tiver um par de chaves SSH existente no sistema do Linux que você usará para se conectar à VM de teste, você poderá ignorar essa etapa e prosseguir com a criação da VM de teste, conforme descrito em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure.

Pré-requisitos

Antes de executar estas etapas, garanta que não vai substituir um par de chaves de SSH existente que você deseja manter para outros fins. Em um sistema Linux, os arquivos de chaves SSH públicas e privadas são criados, via de regra, no diretório ~/.ssh/id_rsa do Linux. Se houver um par de chaves SSH no diretório e você usar o mesmo nome de arquivo ao executar esse comando, ou se você especificar um local diferente no comando e um par de chaves SSH já existir no local, o par existente será substituído.

Procedimento

No sistema Linux, abra um shell bash.
No shell bash, digite o seguinte comando:
```
ssh-keygen -t rsa -b 2048
```
Siga as instruções na tela sobre como inserir um arquivo no qual salvar a chave, inserir um código de acesso e confirmá-lo.
Vejamos um exemplo das instruções na tela, no qual mykey foi inserido como o arquivo para salvar a chave.
```
-bash-4.1$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/mts-cm/home/user1/.ssh/id_rsa): mykey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
```
Observação: Usar um código de acesso de chave é uma prática recomendada opcional.
A chave privada é salva no arquivo que você especificar e a chave pública é salva em um arquivo com o mesmo nome e uma extensão .pub. Usando-se o exemplo acima de inserir mykey como o arquivo, o exemplo de saída seria:
```
Your identification has been saved in mykey.
Your public key has been saved in mykey.pub.
```

O que Fazer Depois

Crie a VM de teste seguindo as etapas em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure.

Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure

Você usará uma máquina virtual (VM) do Linux de teste no seu ambiente do Microsoft Azure para executar os testes que verificam a conectividade de rede configurada para o seu pod do Horizon Cloud.

Pré-requisitos

Verifique se você tem a chave pública SSH que criou conforme descrito em Solução de problemas de implantação de pod do Horizon Cloud: criar um par de chaves SSH. Você fornecerá essa chave pública no assistente de criação de VM para que a máquina virtual confie nas conexões SSH provenientes do sistema que tem a chave privada correspondente.

Verifique se você tem o nome da rede virtual (VNet) que é o mesmo que está usando para implantar seu pod, conforme descrito em Horizon Cloud de primeira geração: configurar a rede virtual necessária no Microsoft Azure.

Se você não tiver usado a opção do assistente para Adicionar Pod a fim de usar suas próprias sub-redes nomeadas para o pod e, em vez disso, tiver digitado os CIDRs das sub-redes, o implantador de pod criará a sub-rede de gerenciamento do pod. No ponto em que o processo de implantação falhou, o processo pode já ter criado a sub-rede de gerenciamento do pod na VNet.

Se o implantador já tiver criado essa sub-rede de gerenciamento, será recomendável implantar a VM de teste nessa sub-rede. Para identificar se a sub-rede de gerenciamento do pod existe na VNet, faça login no portal do Microsoft Azure, navegue até essa VNet e examine a lista de sub-redes que ele tem. Se o implantador do pod criar automaticamente as sub-redes do pod (você não usou a opção de usar suas próprias sub-redes nomeadas para o pod), a sub-rede de gerenciamento do pod terá um nome com o padrão vmw-hcs-podID-net-management, em que podID é o UUID do pod. Caso contrário, a sub-rede de gerenciamento do pod será aquela que você criou para a implantação do pod.
Se o processo de implantação com falha não criou a sub-rede de gerenciamento do pod na VNet, você pode escolher qualquer sub-rede disponível na VNet ou criar uma nova sub-rede para a VM de teste usar.

Procedimento

Faça login no portal do Microsoft Azure.
No portal, crie uma VM de computação do Azure Martketplace e baseie essa VM em um tipo de modelo do Ubuntu Server LTS.
No momento da redação deste artigo, o Ubuntu Server 20.04 LTS estava disponível para escolha no Azure Marketplace.

Ao criar essa VM Linux de teste, siga a UI do assistente e configure as opções necessárias. Configure os itens a seguir conforme indicado abaixo.


Opção	Descrição
Inscrição	Corresponder ao que você selecionou no assistente para Adicionar Pod para seu pod.
Grupo de recursos	A escolha recomendada é criar um novo grupo de recursos para a VM de teste. Siga o prompt na tela para criar um novo grupo de recursos. Embora você possa usar um grupo de recursos existente com essa VM de teste, recomenda-se usar um grupo de recursos específico para a VM de teste porque é mais fácil excluir a VM e seus artefatos relacionados excluindo o grupo de recursos inteiro ao terminar de executar os testes.
Região	Corresponder ao que você selecionou no assistente para Adicionar Pod para seu pod.
Tamanho	Como essa deve ser uma VM de curta duração, usada apenas para concluir os testes de verificação, você pode escolher qualquer tamanho. No entanto, como tamanhos menores geralmente têm custos associados mais baixos no Microsoft Azure, é comum escolher um tamanho pequeno para a VM de teste, como um modelo de 2 vCPU.
Nome do usuário	Anote esse nome porque você precisará usá-lo mais tarde.
Tipo de Autenticação	Selecione Chave pública SSH.
Origem de chave pública SSH	Selecione Usar chave pública existente. O campo de chave pública SSH será exibido com essa seleção, e você poderá colar em sua chave pública SSH.
Chave pública SSH	Nesse campo, cole a chave pública SSH que você criou quando criou o par de chaves SSH. O conteúdo colado deve começar com a linha `---- BEGIN SSH2 PUBLIC KEY ----` e terminar com a linha `---- END SSH2 PUBLIC KEY ----` da sua chave pública.
Portas de entrada públicas	Permita a porta SSH (22) selecionada para que você possa realizar o teste com essa VM de teste.
Rede virtual	Selecione a mesma VNet que foi usada para a implantação do pod com falha.
Sub-rede	Se você já tentou implantar o pod e o processo falhou, a sub-rede de gerenciamento do pod pode ter sido criada na rede virtual. Se a sub-rede estiver lá, recomenda-se selecionar essa sub-rede para esta VM de teste. Clique na opção Sub-rede para navegar até as sub-redes que existem na rede virtual selecionada. Talvez você precise passar o mouse sobre a sub-rede para ver seu nome completo na dica de ferramenta. Se o processo de implantação do pod não tiver criado a sub-rede de gerenciamento do pod na VNet, selecione a sub-rede na sua VNet que você identificou para usar para a VM de teste (conforme descrito nos pré-requisitos acima). Observação: Se o pod tiver sido implantado com êxito, mas você não conseguir solucionar os problemas de ingresso no domínio, talvez você queira selecionar a sub-rede de área de trabalho do pod para a VM de teste, em vez da sub-rede de gerenciamento, pois as operações de ingresso no domínio são usadas com as imagens da área de trabalho que se conectam à essa sub-rede de área de trabalho.
IP Público	Selecione essa opção para que a VM de teste criada tenha um endereço IP público atribuído a ela. Ter um endereço IP público permite que você se conecte a ela por meio da rede de longa distância (WAN). Observação: Usar um IP público pode não ser tecnicamente viável em sua configuração de rede. Se você não puder criar a VM de teste com um IP público, precisará ter conectividade de rede do seu sistema local para a sub-rede que selecionou no campo Sub-rede ou precisará se conectar a algumas outras máquinas na sua rede e, em seguida, estabelecer uma conexão de entrada com a VM de teste.

Na etapa final do assistente, verifique se as principais informações (assinatura, local regional, rede virtual e sub-rede) correspondem às que você está usando para seu pod e envie para criar a VM.

Usar SSH para se conectar à VM de teste

Faça uma conexão SSH (Secure Shell) com a VM de teste para que você possa executar os testes de conectividade de rede em seu ambiente do Microsoft Azure.

Usar SSH para se conectar à VM de teste de um sistema do Microsoft Windows

Estabeleça esta conexão do sistema do Microsoft Windows com a chave privada que corresponda à chave pública especificada quando criou a VM de teste.

Pré-requisitos

Verifique se que você tem o endereço IP e o nome de usuário da VM de teste que especificou quando criou a VM.

Em um sistema do Microsoft Windows, PuTTY normalmente é usado. Para que o PuTTY possa carregar sua chave privada com mais facilidade quando você inicia a sessão do SSH, antes de iniciar o PuTTY, inicie o Pageant conforme descrito em Criar um par de chaves SSH em um sistema do Microsoft Windows e adicione a chave privada SSH à lista de chaves do Pageant. A chave privada SSH deve corresponder com a chave pública especificada durante a criação da VM de teste. Quando a chave privada for carregada para o Pageant, a sessão de SSH do PuTTY usará essa chave privada automaticamente.

Procedimento

Inicie o PuTTY ().
A janela Configuração do PuTTY é aberta.
Na janela Configuração do PuTTY, especifique o nome do host, selecione SSH e clique em Abrir.
No campo Nome do Host da janela Configuração do PuTTY, digite uma cadeia de caracteres no padrão
```
testvm_username@testvmip
```
substituindo o nome de usuário e o endereço IP da VM de teste por testvm_username e testvmip na cadeia de caracteres.
Importante: Depois de clicar em Abrir, quando esta é a primeira vez que você se conecta à VM de teste, uma mensagem de segurança do PuTTY é exibida, informando que a chave do host do servidor não está armazenada em cache e exibe a impressão digital da chave rsa2 do servidor. Você pode continuar a estabelecer a conexão clicando em Sim para adicionar a chave do host do servidor ao cache do PuTTY ou em Não para se conectar sem adicionar a chave ao cache do PuTTY. Se você achar que a conexão possa não ser com a VM de teste, clique em Cancelar para abandonar a conexão e retornar para a janela Configuração do PuTTY para verificar sua entrada de nome de host.
A seguinte captura de tela é uma ilustração da janela usando este exemplo:
```
[email protected]
```

Resultados

Quando a conexão SSH é estabelecida, uma janela de linha de comando é exibida.

O que Fazer Depois

Agora que você está conectado à VM de teste, pode executar os testes para verificar a conectividade da rede em seu ambiente do Microsoft Azure. Siga as etapas descritas em Executar os testes para verificar a rede no seu ambiente do Microsoft Azure.

Conexão por SSH à VM de teste a partir de um sistema Linux

Você faz essa conexão a partir do sistema Linux que tem a chave privada que corresponde à chave pública especificada por você quando criou a VM de teste.

Pré-requisitos

Verifique se você tem o endereço IP da VM de teste e o nome de usuário que especificou ao criar a VM.

Procedimento

Abra um shell bash.
No prompt do shell bash $, insira o comando ssh como se vê abaixo, substituindo o endereço IP da VM de teste e o nome de usuário por ipvmdeteste e vmdeteste_nomedeusuário no comando:
```
ssh vmdeteste_nomedeusuário@ipvmdeteste
```
Por exemplo, usando os detalhes da VM de teste dos exemplos em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure, o exemplo de comando se pareceria com o seguinte:
```
ssh [email protected]
```

Resultados

Quando é estabelecida a conexão SSH, aparece uma janela de linha de comando parecida com a seguinte captura de tela.

O que Fazer Depois

Agora que você está conectado à VM de teste, já pode executar os testes para verificar a conectividade de rede em seu ambiente do Microsoft Azure. Siga as etapas descritas em Executar os testes para verificar a rede no seu ambiente do Microsoft Azure.

Executar os testes para verificar a rede no seu ambiente do Microsoft Azure

Executar estes testes para verificar se estas duas áreas relacionadas à rede estão configuradas corretamente: se o DNS pode resolver os endereços interno e externo e se as portas de saída necessárias estão abertas. Execute esses testes usando sua VM de teste.

O pod depende de o DNS resolver os endereços interno e externo. Os dois primeiros teste aqui verificam se o DNS configurado no seu ambiente de rede pode resolver os FQDNs conhecidos para os endereços interno e externo.

Pré-requisitos

Antes de executar esses testes, verifique se você criou uma VM de teste na sua assinatura do Microsoft Azure e tem uma conexão SSH com ela, conforme descrito em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure e Usar SSH para se conectar à VM de teste.

Obtenha os endereços IP e nomes de domínio totalmente qualificados (FQDNs) para servidores internos à sua rede e que você espera que sejam acessíveis pelo VNet, como seu Controlador de Domínio do Active Directory. Você usará essas informações no teste de verificação de DNS.

Procedimento

Verifique se o DNS está funcionando em seu ambiente para resolver os FQDNs internos usando o comando dlg para consultar um nome de domínio conhecido que é interno para seu VNet no Microsoft Azure.
Na janela de conexão SSH, emita o comando dig para consultar o nome de domínio de um servidor que você sabe que é interno à sua rede, como seu Controlador de Domínio do Active Directory.
```
dig internal-domain-name
```
Onde internal-domain-name é o nome de domínio completo de um servidor que você sabe é interno à sua rede.
dig (Domain Information Groper) é uma ferramenta de linha de comando para solução de problemas de rede. Ao executar este comando usando um nome de host interno, o resultado verifica se a sua configuração de DNS pode resolver os endereços internos corretamente. Se a sua configuração de DNS puder resolver o internal-domain-name usado no comando, a saída do comando retornará o endereço IP correto associado a esse nome de domínio.
Por exemplo, suponha que o VNet esteja configurado com um servidor interno do Active Directory que possui um Controlador de Domínio do Active Directory com a entrada DNS skylo.local e o endereço IP 192.168.0.15. Emitir dig skylo.local deveria verificar se a configuração de DNS do VNet pode resolver esse nome de servidor interno skylo.local:
```
testvmadmin@HCS-testingVM:~$ dig skylo.local

; <<>> DiG 9.10.3-P4-Ubuntu <<>> skylo.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64899
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;skylo.local.                   IN      A

;; ANSWER SECTION:
skylo.local.            600     IN      A       192.168.0.15

;; Query time: 1 msec
;; SERVER: 192.168.0.15#53(192.168.0.15)
;; WHEN: Mon Mar 26 20:58:01 UTC 2018
;; MSG SIZE  rcvd: 56

testvmadmin@HCS-testingVM:~$
```
O teste é bem-sucedido quando a ANSWER SECTION indica que o nome do host fornecido foi resolvido para o endereço IP que você espera para esse nome de host.
Observação: Às vezes, o DNS não é 100% confiável, e algumas solicitações são resolvidas corretamente, enquanto outras falham. Se a emissão do comando falhar na primeira vez, execute o comando para dez a vinte iterações e consulte se você obteve respostas confiáveis a cada vez.
Verifique se o DNS está funcionando em seu ambiente para resolver FQDNs externos usando o comando dlg para consultar um nome de domínio externo conhecido.
Na janela de conexão SSH, emita o comando dig para consultar um nome de domínio externo padrão do setor, como vmware.com ou microsoft.com.
```
dig external-domain-name
```
Onde external-domain-name é um nome de domínio totalmente qualificado que é externo ao seu VNet. Por exemplo, emitir dig vmware.com verificaria se a configuração de DNS do VNet pôde possível resolver o nome externo:
```
testvmadmin@HCS-testingVM:~$ dig vmware.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> vmware.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38655
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;vmware.com.                    IN      A

;; ANSWER SECTION:
vmware.com.             150     IN      A       107.154.105.19
vmware.com.             150     IN      A       107.154.106.19

;; Query time: 28 msec
;; SERVER: 192.168.0.15#53(192.168.0.15)
;; WHEN: Mon Mar 26 21:14:29 UTC 2018
;; MSG SIZE  rcvd: 71

testvmadmin@HCS-testingVM:~
```
No exemplo acima, a ANSWER SECTION indica que o nome de domínio externo vmware.com foi resolvido corretamente para dois endereços IP.
Observação: Você pode repetir esse teste usando vários nomes de domínio externos, como azure.com ou microsoft.com, para verificar se o DNS pode resolver nomes externos diferentes.
Se os testes de DNS não funcionarem, verifique as suas configurações de rede e o servidor DNS. Verifique que você adicionou seu servidor DNS ao seu VNet.
Importante: Se você achar que precisará adicionar o seu servidor DNS ao seu VNet ou que precisará alterar a configuração do servidor DNS do VNet, deverá reiniciar todas as VMs que estão conectadas a esse VNet para que elas detectem a alteração. Se você alterar a configuração do servidor DNS do VNet e não reiniciar que todas as VMs conectadas a esse VNet, as alterações não serão propagadas corretamente no VNet.
Verifique se as portas de saída necessárias estão disponíveis usando o comando netcat.
O Horizon Cloud requer que algumas portas de saída sejam abertas, para que o software do pod possa ser baixado com segurança para o seu ambiente do Microsoft Azure e para que o pod possa conectar de volta com a camada de controle do Horizon Cloud. Conforme descrito em Tenants de primeira geração: Implantações do Horizon Cloud on Microsoft Azure: requisitos de resolução de nomes de host e nomes DNS, as seguintes portas TCP de saída precisam ser abertas da sub-rede de gerenciamento do pod: portas 80, 443 e 11371. Ao executar o comando netcat, conforme indicado no comando a seguir, você pode verificar se essas portas de saída estão abertas conforme necessário.
Na janela de conexão SSH, execute os comandos a seguir (um por porta).
Observação: O comando a seguir para testar a porta 11371 especifica packages.microsoft.com para testar essa conexão, enquanto as duas outras linhas testam a conexão de saída com a camada de controle do Horizon Cloud.
```
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 80
Connection to cloud.horizon.vmware.com 80 port [tcp/http] succeeded!
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 443
Connection to cloud.horizon.vmware.com 443 port [tcp/https] succeeded!
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 packages.microsoft.com 11371
Connection to packages.microsoft.com 11371 port [tcp/hkp] succeeded!
```
Quando uma porta é aberta corretamente, o comando netcat retorna a linha succeeded! para seu teste.
Se os comandos netcat retornarem falhas, verifique suas conexões de rede do Microsoft Azure, seus Grupos de Segurança de Rede na sua assinatura e todos os firewalls que você possa ter em funcionamento. Verifique se a sua configuração de rede atende aos requisitos de DNS, portas e protocolo que o pod precisa para a implantação, conforme descrito em Tenants de primeira geração: Implantações do Horizon Cloud on Microsoft Azure: requisitos de resolução de nomes de host e nomes DNS.

Resultados

Se os testes acima forem bem-sucedidos, você será capaz de implantar com êxito o seu pod.

Observação: Se você estiver configurando recursos opcionais para uso com o seu pod, como o True SSO ou a autenticação de dois fatores com um servidor de autenticação, portas adicionais poderão ser necessárias para essas finalidades. Você pode usar as técnicas de teste acima da porta de saída para verificar se essas portas estão abertas corretamente.

O que Fazer Depois

Quando você concluir o teste, deverá excluir a VM de teste e todos os seus artefatos relacionados, como seu disco de VM, endereço IP, NIC, do seu ambiente do Microsoft Azure. Idealmente, você deveria ter criado um grupo de recursos para a VM de teste e poderá simplesmente excluir esse grupo de recursos para excluir todos os artefatos da VM. Siga as etapas em Excluir a VM de teste depois de concluir os testes.

Importante: Se você não excluir todos os artefatos da VM de teste do seu ambiente do Microsoft Azure e tiver conectado a VM a uma das sub-redes do pod, se tentar excluir o pod do ambiente do Horizon Cloud usando a ação Excluir no pod, o sistema poderá não ser capaz de excluir totalmente o pod devido a esses artefatos conectados restantes. Por padrão, quando você usa a ação Excluir para excluir um pod, o Horizon Cloud exclui esses grupos de recursos e sub-redes que ele criou para o pod. O Microsoft Azure impedirá a exclusão de sub-redes que ainda estão em uso. Se os artefatos da sua VM de teste estiverem conectados às sub-redes do pod, essas sub-redes não podem ser excluídas e a exclusão de pod ficará incompleta. Para evitar essa situação, certifique-se de que todos os artefatos da VM de teste sejam excluídos depois de você implantar o pod com êxito.

Excluir a VM de teste depois de concluir os testes

Quando você tiver concluído os testes para verificar a sua configuração de rede do Microsoft Azure e não precisar mais da VM de teste, deverá excluir a VM e todos os seus artefatos relacionados do seu ambiente do Microsoft Azure.

Procedimento

Faça login no portal do Microsoft Azure.
Use um dos seguintes métodos para excluir a VM de teste, dependendo de como você a implantou.
- Se você tiver implantado a VM de teste em seu próprio grupo de recursos e você não estiver usando esse grupo para outros fins, poderá excluir o grupo de recursos inteiro.
  Cuidado: Para evitar a exclusão indesejada de outros itens, certifique-se de que o grupo de recursos contenha apenas a VM de teste e seus objetos associados, como seus adaptadores de rede e disco, antes de excluir o grupo de recursos.
- Se você precisar excluir a VM de teste sem excluir um grupo de recursos inteiro, poderá usar a caixa de pesquisa do portal para procurar o nome da VM de teste. Os resultados dessa pesquisa listarão a VM e todos os seus objetos associados (disco, interfaces de rede, endereço IP público etc.). Exclua cada objeto individualmente.