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

Limitações relacionadas às implantações de pods do Horizon Cloud no 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.
  • 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.
  • 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.
    Observação: A partir da atualização do plano de nuvem de 15 de dezembro de 2020, ter FQDNs diferentes para as configurações do gateway externo do pod e do gateway interno é compatível. Antes de 15 de dezembro de 2020, o sistema aplicava o mesmo FQDN para um pod de manifesto 2298 e posteriores. Agora, é a sua escolha se você deseja que os gateways do pod usem FQDNs diferentes ou o mesmo FQDN. Se você quiser usar o mesmo FQDN em ambos os gateways, após a implantação do pod, 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 de 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.
  • Atualmente, não há suporte para a edição ou atualização das configurações de proxy em um pod depois que o pod é implantado no Microsoft Azure. Além disso, não há suporte para a adição de uma configuração de proxy a um pod implantado sem configurações de proxy.
  • Os recursos do NSX Cloud nesta versão não são compatíveis com o Microsoft Windows Server 2019.
  • 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 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:
      • Digite 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.

Limitações relacionadas às atualizações de pods do Horizon Cloud no Microsoft Azure

  • 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 tais farms e atribuições de áreas de trabalho VDI, as sessões desconectadas também têm o logoff feito imediatamente e o trabalho em andamento do usuário é perdido nessas mesmas condições. Depois que o processo de atualização for concluído, esses 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.
  • Quando pods em execução em manifestos anteriores ao manifesto 2474 da versão de outubro de 2020 forem atualizados para o 2474 ou posteriores, se você tiver usado o Portal do Microsoft Azure para adicionar de forma manual tags diretamente a recursos ou grupos de recursos criados pelo Horizon Cloud na sua assinatura (como criar tags personalizadas no farm ou grupos de recursos das atribuições de área de trabalho VDI) quando esses pods foram atualizados, o processo de atualização do pod não preservará as tags personalizadas que você adicionou diretamente usando o Portal do Microsoft Azure. Essas tags personalizadas serão removidas. Após a atualização do pod, você deverá usar os recursos do Horizon Universal Console posteriormente para editar os farms e as atribuições de área de trabalho VDI para que o sistema aplique essas tags aos grupos de recursos desses farms e atribuições de área de trabalho VDI. Usar o recurso Tags de Recursos do Azure do console é o método suportado de adicionar tags de recursos nos grupos de recursos criados pelo pod para farms e atribuições de área de trabalho VDI. Em cada um dos tópicos de documentação a seguir, leia as descrições dos campos Tags de Recursos do Azure localizados neles. Os mesmos campos são usados ao editar um farm ou uma atribuição de área de trabalho VDI.

Limitações relacionadas a VMs importadas, golden images, farms ou atribuições de área de trabalho VDI em pods do Horizon Cloud no Microsoft Azure

  • O uso de True SSO com áreas de trabalho de sessão, aplicativos remotos ou áreas de trabalho VDI com base em imagens que executam o Windows 10 versão 2004, o Windows 10 versão 20H2, o Windows Server versão 2004 ou o Windows Server versão 20H2 requer a instalação de um patch da Microsoft nesses sistemas operacionais. O patch corrige um problema da Microsoft que impede a autenticação de True SSO com esses sistemas operacionais. Para obter detalhes, consulte o KB 79644 da VMware que faz referência ao KB 4598291 do Microsoft Update.
  • 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.
  • Atualmente, não há suporte para o 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.
  • 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.
  • 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.
  • Se você iniciar a conversão de uma á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.
  • 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.