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

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.

Todos os tipos de implantação

  • Todos os pods associados ao seu tenant do Horizon Cloud e conectados ao Horizon Cloud devem ter linha de visão para o mesmo conjunto de domínios do Active Directory. Se a frota de pods do seu tenant tiver uma combinação de tipos de pod, como os tipos de Horizon 8 e Horizon Cloud, além desse requisito de linha de visão, será necessária uma confiança unidirecional ou bidirecional entre todos os domínios registrados nesse mesmo tenant do Horizon Cloud.
    Observação: A linha de visão nesse contexto significa que um determinado pod deve ter acesso à rede a cada domínio para que ele possa entrar em contato com esse domínio para verificação de status.
  • 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.

Implantações: pods do Horizon Cloud no Microsoft Azure

Um pod Horizon Cloud é o tipo criado na tecnologia do gerenciador de Pod do Horizon Cloud.

  • 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.
    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:
      • Insira um nome de usuário e senha que atendam aos requisitos do Microsoft Azure para nomes de usuário e senhas de administradores 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.

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.

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

  • Embora o console não impeça o uso de imagens obtidas de origens diferentes do Azure Marketplace nos fluxos de trabalho do console, o uso dessas imagens não é compatível. Para obter suporte para o uso no Horizon Cloud on Microsoft Azure, todas as imagens de base importadas devem ser compiladas de VMs baseadas no Windows que são provenientes do Azure Marketplace. Mesmo se você tentar uma imagem obtida de outras origens, e o console não impedir que você a use nos fluxos de trabalho do console, o uso de tais imagens não será compatível.

    Além disso, se for uma imagem do Windows 11, ela deverá ser originada diretamente do Azure Marketplace e não poderá ter sido processada posteriormente. A importação de VM do Windows 11 de qualquer outra fonte, como Galeria de Imagens Compartilhadas (SIG), Imagens Gerenciadas do Azure, instantâneo de VM do Azure e similares, não tem suporte no momento.

  • No momento, as VMs do Azure da Geração 2 têm suporte para uso apenas com sistemas operacionais Windows 11 de sessão única e com sistemas operacionais Windows 11 Enterprise de várias sessões.
  • Atualmente, as VMs NVv4 compatíveis com GPU do Azure que usam os drivers gráficos AMD Radeon Instinct têm suporte para uso somente quando são importadas usando o método de importação personalizado. O método de importação personalizado também é chamado de importação manual nesta documentação. O assistente automatizado para Importar Máquina Virtual do Marketplace não fornece esse recurso atualmente.

    Além disso, atualmente o serviço não oferece suporte ao uso do Windows 11 com essas VMs NVv4 e os drivers gráficos AMD Radeon Instinct. Esse uso não foi qualificado.

  • O suporte do serviço para o Windows 11 tem algumas considerações, limitações e problemas conhecidos. Para obter esses detalhes, consulte Suporte para sistema operacional convidado Windows 11: considerações, limitações conhecidas e problemas conhecidos.
  • 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.

Implantações: pods do Horizon

Um pod do Horizon é o tipo de pod criado no software Horizon Servidor de Conexão. Para obter informações básicas sobre as diversas arquiteturas de implantação usadas para pods do Horizon, consulte Tenants de primeira geração: arquiteturas de implantação de pod do Horizon com o Horizon Cloud de primeira geração. Para obter informações detalhadas sobre os vários serviços de plano de nuvem, consulte o guia de administração.

As seguintes limitações aplicam-se à versão atual e são atualizadas conforme aplicável para cada versão do Horizon Cloud Service.

  • O recurso de atualização automatizada de Horizon Cloud Connector só é compatível com pods do Horizon implantados no local. Para atualizar uma instância do Horizon Cloud Connector que está emparelhada com um pod Horizon implantado em um ambiente de nuvem, siga as instruções em Atualizar manualmente o dispositivo virtual do Horizon Cloud Connector.
  • Atualmente, o Serviço de Gerenciamento de Imagens do Horizon (IMS) tem suporte para uso com um subconjunto dos modelos de implantação do Horizon descritos na Arquitetura de referência do Horizon da VMware Tech Zone. Para obter informações sobre os modelos de implantação específicos com suporte pelo IMS, consulte Requisitos do sistema IMS. A medida que mais modelos da Arquitetura de Referência do Horizon estão qualificados para suporte de IMS, os recém-suportados são adicionados à lista.

Workspace ONE Hub Services e Universal Broker: Integração

  • Esse recurso só está disponível para o VMware Workspace ONE® Access™ Cloud. Ele não é compatível com o VMware Workspace ONE Access no local.
  • Com essa integração, os usuários finais podem acessar suas áreas de trabalho e aplicativos do Horizon Cloud por meio do catálogo do Hub. Defina as configurações necessárias para o VMware Workspace ONE® Intelligent Hub, conforme descrito em Workspace ONE Access - Configurar o Intelligent Hub para Integração com o Horizon Cloud.
  • Nesta versão, essa integração oferece suporte ao acesso do usuário final usando estes clientes: catálogo do Hub baseado em navegador, Workspace ONE Intelligent Hub para Windows e Workspace ONE Intelligent Hub para macOS. A versão mínima dos aplicativos de áreas de trabalho do Windows e macOS necessários para esse suporte é 21.05.
  • O cache de senhas não é ativado por padrão em novos tenants do Workspace ONE Access. Se o True SSO não estiver ativado em seu ambiente do Horizon, você poderá ativar o cache de senhas para armazenar senhas de usuários em cache, de modo que eles não precisem digitar suas senhas novamente ao iniciar áreas de trabalho e aplicativos do Horizon Cloud. Para obter mais informações, consulte Configurar o cache de senhas para aplicativos virtuais (somente Workspace ONE Access Cloud).
  • As políticas de acesso definidas no Workspace ONE Access não se aplicam a aplicativos e áreas de trabalho de um ambiente do Horizon Cloud que tenha o Universal Broker ativado.
  • Não há suporte para a inicialização de mais de uma sessão de usuário final ao mesmo tempo em vários clientes no mesmo endpoint do cliente físico. Em outras palavras, os usuários finais não podem iniciar mais de uma sessão por endpoint de cliente físico para mais de um área de trabalho virtual atribuída ou aplicativo remoto, independentemente de a atribuição ser uma atribuição de área de trabalho VDI flutuante ou dedicada. Por exemplo, o sistema não consegue realizar essa experiência do usuário final: usar um sistema cliente físico conectado a dois monitores lado a lado e ter duas sessões de área de trabalho virtual separadas sendo executadas simultaneamente por meio desse mesmo sistema cliente, com um área de trabalho mostrada em um monitor e a outra área de trabalho no outro monitor. Essa limitação indica que o sistema funcionando conforme projetado.

Horizon Universal Console: advertências e limitações relacionadas

  • O console não obtém os nomes atualmente em vigor de seus usuários e grupos do Active Directory que já estão especificados nos detalhes de uma atribuição. Quando você altera o nome de um usuário ou grupo no Active Directory, o console continua a exibir o nome anterior do usuário ou grupo nos detalhes da atribuição de quando esse usuário ou grupo foi adicionado inicialmente à atribuição. Ao editar uma atribuição e procurar um usuário ou grupo no campo de pesquisa, os nomes efetivos atuais dos usuários ou grupos são exibidos no console. No entanto, mesmo depois de salvar a atribuição atualizada, você continuará a ver o nome inicial antigo exibido nos detalhes da atribuição. Essa limitação não tem impacto funcional.
  • 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.
  • Sua sessão autenticada (conectada) no console expirará após a configuração de tempo que está definida na página de 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 nos menus suspensos 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.