Para que você tenha o melhor desempenho em toda a sua jornada com o Horizon Cloud, lembre-se destas limitações conhecidas.

Limitações aplicáveis a todos os tipos de implantação

  • O console administrativo baseado na Web não é compatível com o navegador Apple Safari. Alguns recursos da interface do usuário poderão não funcionar corretamente. No Mac OS, em vez do Apple Safari, você pode usar os navegadores Firefox ou Chrome.
  • Todos os pods associados à sua conta de cliente do Horizon Cloud e conectados ao Horizon Cloud devem ter uma linha de visão com o mesmo conjunto de domínios do Active Directory e confiança unidirecional ou bidirecional configurada junto com essa linha de visão.

Limitações aplicáveis às implantações do Microsoft Azure

  • Devido a limitações de como VNets do Microsoft Azure lidam com operações de criação e exclusão de sub-redes simultâneas, a execução de operações simultâneas relacionadas a pods que exigem a modificação da mesma VNet ao mesmo tempo pode resultar em falha na conclusão dessas operações. Para evitar esse problema, evite executar operações de implantação, exclusão ou edição de pods que envolvam sub-redes ao mesmo tempo em que os pods estão usando a mesma VNet. Veja a seguir alguns exemplos de operações relacionadas a pod simultâneas que envolvem modificar a VNet, em que pode haver chances de ações de sub-rede simultâneas na VNet, resultando em falhas para concluir as operações:
    • Quando você não cria suas sub-redes com antecedência, deixa o implantador de pods criar essas sub-redes usando CIDRs e depois inicia a criação de dois pods simultaneamente na mesma VNet. As sub-redes estão sendo adicionadas à VNet para ambas as criações de pod simultaneamente.
    • Quando um pod está sendo implantado e você inicia a exclusão de outro pod na mesma VNet. As sub-redes são adicionadas à VNet para o pod de implantação ao mesmo tempo em que as sub-redes do outro pod estão sendo excluídas da mesma VNet.
    • Quando você editar um pod para adicionar uma configuração de gateway externo à VNet desse pod usando blocos CIDR enquanto outro pod está em processo de exclusão. As sub-redes são adicionadas à VNet para a configuração do gateway ao mesmo tempo em que as sub-redes do outro pod estão sendo excluídas da VNet.
  • O uso do recurso de criptografia de disco para farms e atribuições de área de trabalho VDI não é permitido no momento em pods nas nuvens do Microsoft Azure Governamental.
  • A expansão do tamanho das sub-redes do pod após a implantação do pod não é suportada no momento. Antes de implantar um pod, você deve garantir que os espaços de endereço das sub-redes especificadas no assistente de implantação sejam grandes o suficiente para acomodar o uso esperado. Nota:
    Observação: Para solucionar essa limitação, um novo recurso que foi disponibilizado nos pods do manifesto 2298.0 e mais recente permite a adição de sub-redes de tenant para uso por seus farms e atribuições de áreas de trabalho VDI depois que o pod é implantado. Esse recurso fornece flexibilidade para adicionar sub-redes de tenants localizadas na mesma VNet do pod ou em uma VNet emparelhada para uso pelo seu farm e VMs de área de trabalho após a implantação do pod. Para obter mais detalhes, consulte o Guia de Administração.
  • Esta versão não oferece suporte ao uso dos seguintes recursos do Horizon Agent: serviço VMware Logon Monitor. Por padrão, o Horizon Agents Installer desativa o serviço VMware Logon Monitor em todas as instalações que executam o instalador.
  • Durante o processo de atualização de um pod de um nível de software anterior para o mais recente, os usuários finais com sessões conectadas ao nó que está sendo atualizado terão essas sessões ativas desconectadas. Não ocorrerá perda de dados, exceto se o farm RDSH ou a atribuição de área de trabalho VDI que processa as sessões tiver a opção Fazer Logoff das Sessões Desconectadas definida como Imediatamente. Para esses farms e atribuições de áreas de trabalho VDI, as sessões desconectadas também têm o logout feito imediatamente, e o trabalho em andamento do usuário é perdido nessas condições. Após o término do processo de atualização, os usuários poderão se reconectar. Em geral, o processo de atualização do pod leva menos de meia hora. No entanto, algumas atualizações de pod podem levar mais tempo.
  • Vários pods não podem compartilhar o mesmo nome de domínio totalmente qualificado definido em suas configurações de Unified Access Gateway. Cada pod configurado com instâncias do Unified Access Gateway precisa ter seu próprio nome de domínio totalmente qualificado (FQDN) exclusivo. O FQDN não pode conter sublinhados. A partir da versão de manutenção de julho de 2020, a implantação de um novo pod do manifesto 2298.0 ou mais recente requer o uso do mesmo FQDN em ambas as configurações internas e externas do Unified Access Gateway no pod. Como os dois gateways terão o mesmo FQDN, configure o DNS dividido (Sistema de nome de domínio dividido) para resolver o endereço do gateway como o gateway externo ou o gateway interno, dependendo da rede de origem da consulta de DNS do cliente do usuário final. Em seguida, o mesmo FQDN usado no cliente do usuário final poderá rotear para o gateway externo quando o cliente estiver na Internet e rotear para o gateway interno quando o cliente estiver na sua rede interna.
  • Sua sessão autenticada (conectada) no console administrativo baseado na Web atingirá o tempo limite após a configuração de tempo definida na página Configurações Gerais do console. O padrão é 30 minutos. Se você tem pelo menos um pod conectado à nuvem, pode alterar o padrão para um valor que varia de 30 a 180 minutos. Na maioria dos casos, quando o tempo configurado é atingido, o sistema desconecta você automaticamente e mostra uma mensagem informando que é necessário fazer login outra vez. No entanto, às vezes o sistema encerra a sessão autenticada e não o desconecta explicitamente. Quando isso acontece, ao tentar realizar algumas tarefas no console, podem ser exibidas mensagens de erro que não refletem com precisão o estado atual, como quando o assistente de implantação de nó falha em validar suas entradas de assinatura, os valores não são exibidos nas listas suspensas e a página Farms informa que nenhum nó está disponível para a criação de um farm e as mensagens de erro informam: "Não há service_sessions do tipo identity_node fornecidas". Se você começar a ver esse comportamento e estiver usando o console por 30 minutos ou mais, faça logout manualmente e, em seguida, faça logon novamente.
  • Não há suporte para o recurso de redirecionamento de USB ao usar o VMware Horizon Client para Android para acessar áreas de trabalho virtuais e aplicativos remotos atendidos por seu ambiente do Horizon Cloud.
  • Para golden images compatíveis com GPU baseadas em sistemas operacionais do tipo servidor, as versões 2016 e 2019 do Microsoft Windows Server são recomendadas para evitar a limitação do número de sessões de usuário final. Devido a uma limitação de driver NVIDIA no Windows Server 2012 R2, o número máximo de sessões para cada servidor de área de trabalho RDS é 20.
  • Os recursos do NSX Cloud nesta versão não são compatíveis com o Microsoft Windows Server 2019.
  • Se você tiver uma imagem do usando o Microsoft Windows 10 1709 (RS3) e quiser atualizá-la para o Windows 10 1803 (RS4) ou Windows 10 1809 (RS5), primeiro atualize esse Windows 10 1709 para a versão mais recente do Horizon Agent 19.4 antes de prosseguir com a atualização do sistema operacional do Windows.
  • Por padrão, quando você usar o assistente de Importação de Máquina Virtual do Marketplace para criar uma imagem com um sistema operacional Windows Server 2012, a imagem resultante não terá a Experiência de Área de Trabalho ativada. Se você quiser que a imagem resultante tenha a Experiência de Área de Trabalho, deverá ativar manualmente a Experiência de Área de Trabalho na imagem resultante.
  • Quando você implanta um pod do Horizon Cloud on Microsoft Azure depois de já ter configurado o True SSO para os pods implantados antes, o sistema não emparelha automaticamente o novo pod com os servidores de Registro. Você deverá repetir manualmente as etapas para exportar o pacote de emparelhamento e importá-lo nos servidores de Registro. Para ver as etapas, consulte o tópico Configurar o True SSO para uso com seu ambiente Horizon Cloud e os subtópicos.
  • Em uma personalização de redirecionamento de URL, os padrões de URL são tratados com diferenciação entre maiúsculas e minúsculas quando eles são interceptados pelo Horizon Client. Por exemplo, o redirecionamento de URL não ocorrerá para os padrões de URL especificados como *GOOGLE.com e *Google.com, mesmo que o padrão *google.com seja redirecionado. O redirecionamento para os usuários finais não acontecerá se o padrão especificado não corresponder ao caso de caractere real usado nos sistemas de arquivos de destino.
  • O sistema obtém os dados dos relatórios de Utilização, Simultaneidade, Histórico de Sessão e Principais Aplicativos uma vez por dia, em um horário específico do UTC. Os dados dos relatórios de Utilização e Simultaneidade são obtidos às 2 AM UTC, os dados do relatório de Histórico de Sessão são obtidos às 2:10 AM UTC e os dados do relatório de Principais Aplicativos são obtidos às 2:30 AM UTC. Como resultado, as informações relatadas que são exibidas no console administrativo podem não refletir os dados coletados entre a hora da última obtenção e a hora na qual você está visualizando os relatórios no console. Por exemplo, como a lógica para os dados de Usuários e Simultaneidade de Pico no relatório de Simultaneidade é calculada diariamente, para a qual os dados são obtidos, os dados da atividade do usuário em 23 de abril são calculados no ponto de tempo 2 AM UTC de 24 de abril (o dia seguinte). Depois que esse ponto de tempo passa e o sistema obtém os dados coletados, os dados de 23 de abril são exibidos no relatório. Se um dos seus usuários finais iniciar uma sessão após o ponto de tempo 2 AM UTC de 23 de abril, os dados dessa sessão do usuário não serão refletidos no relatório na tela até depois de 2 AM UTC de 24 de abril.
  • Em fluxos de trabalho que resultam na criação de VMs pelo sistema, como a criação de farms, imagens e atribuições, se você tentar inserir um nome maior do que o permitido pelo sistema para o item a ser criado, o sistema impedirá que você digite mais que o número permitido de caracteres. O número de caracteres permitido para o nome do item depende do fluxo de trabalho.
  • Em um ambiente de vários pods do Microsoft Azure, você não pode reutilizar nomes que usou em um pod durante a criação de itens em outro pod. O motivo para essa limitação é que os pods no ambiente de vários pods compartilham o mesmo domínio do Active Directory e a mesma VNet. Como resultado, se os nomes forem compartilhados em tais ambientes de vários pods, poderá ocorrer um comportamento inesperado. Essa limitação se aplica a nomes de imagem, farms e atribuições de área de trabalho VDI. Use sempre nomes exclusivos para suas imagens, farms e atribuições de área de trabalho VDI.
  • Siga estas regras ao inserir caracteres no console administrativo:
    • Utilize somente caracteres ASCII padrão em senhas e nomes de usuário, e na senha quando estiver baixando o arquivo de bootstrap SSL do DaaS. Se você utilizar caracteres que não sejam ASCII para estes itens, poderá provocar resultados inesperados.
    • Ao inserir nomes para imagens importadas, farms, atribuições e outros ativos que resultam na criação de uma VM no Microsoft Azure, não insira mais de 12 caracteres para o nome.
    • Não use vírgulas em senhas de usuário.
    • Ao usar o assistente de Importação de VM para criar uma VM da imagem de base do Microsoft Azure Marketplace:
      • Insira um nome de usuário e uma senha que respeitem as exigências do Microsoft Azure para nomes de usuário e senhas de administrador de VM. Consulte a página de perguntas frequentes do Microsoft Azure para obter mais detalhes.
      • Não insira um nome para a imagem que termina com hífen (-).
      • Não inclua um caractere de sublinhado (_) no nome da imagem.
  • Se você iniciar a conversão de um área de trabalho para uma imagem, mas cancelar antes da conclusão da tarefa, uma segunda tentativa de converter o desktop para uma imagem poderá falhar. Para evitar esse problema, você deve desligar a área de trabalho e ligá-la novamente antes de tentar convertê-la uma segunda vez.