Este tópico lista os problemas conhecidos que você pode encontrar ao usar o serviço e as soluções alternativas conhecidas, se houver.

Este tópico da documentação inclui os problemas conhecidos do Horizon Cloud Connector. No entanto, mesmo que você use o Horizon Cloud Connector para conectar pods do Horizon ao Horizon Cloud, os problemas conhecidos do software em execução nesses pods do Horizon estão descritos em outra documentação. Os problemas conhecidos das versões de software dos pods do Horizon estão incluídos nas notas da versão do próprio produto de software Horizon. Os documentos do software Horizon versão 7.x podem ser acessados por links na página de documentação do VMware Horizon 7. Os documentos do software Horizon versão 2006 (também chamado de Horizon 8) podem ser acessados por links na página de documentação do VMware Horizon.

Para qualquer problema conhecido referente ao Serviço de Gerenciamento de Imagens (Image Management Service, IMS), consulte a página de problemas conhecidos em Gerenciamento de imagens do Horizon da nuvem.

Observação: Os números entre parênteses indicados em cada problema conhecido se referem aos sistemas de controle de problemas internos da VMware.

Problemas conhecidos relacionados ao login

Mesmo que você tenha criado uma senha para sua conta do My VMware que contenha uma barra invertida (\), haverá falha no login no Horizon Cloud com essas credenciais (2595757)
Quando você usa as credenciais do My VMware para fazer login no Horizon Cloud, não há suporte para senhas que contenham barras invertidas. Para ver a lista de caracteres especiais com suporte, faça login em my.vmware.com e navegue até a seção Alterar Senha do seu perfil. Essa página exibirá os caracteres especiais compatíveis. Solução alternativa: redefina a senha da conta do My VMware para uma nova e verifique se ela não tem nenhuma barra invertida (\).

Problemas conhecidos relacionados ao Active Directory

O bloqueio de conta de BIND primária não será detectado até que você realize uma ação que envolva o Active Directory no console administrativo. (2010669)
Devido a esse problema, um administrador conectado ao console administrativo baseado na Web não verá uma notificação de bloqueio de conta de BIND primária até que uma ação que envolva o Active Directory seja executada na interface do usuário, como durante a pesquisa do Active Directory para adicionar usuários a atribuições. Os serviços subjacentes detectam apenas uma conta de serviço bloqueada quando fazem uma solicitação para se comunicar com o Active Directory para autenticação ou pesquisa (usuário ou grupo). Solução alternativa: nenhuma.
É preciso até 15 minutos para que o console administrativo baseado na Web reflita um estado de bloqueio ou desbloqueio da conta de domínio de BIND primária. (2009434)
O objeto de conexão do sistema para o Active Directory é armazenado em cache por 15 minutos. Como resultado, ele pode levar 15 minutos entre o momento quando a conta de BIND primária vai para o estado bloqueado e o sistema gera a notificação para o administrador. Por outro lado, depois que o administrador limpa a condição bloqueada da conta, ele pode levar até 15 minutos para que o sistema pare de notificar sobre a conta agora limpa. Solução alternativa: nenhuma.
Para farms em um pod do Microsoft Azure, reutilizar o mesmo nome do farm com um domínio diferente na mesma floresta do Active Directory pode levar a falhas de ingresso no domínio devido à duplicação dos nomes de provedor de serviços (SPNs). (1969172)
Devido a um novo recurso para os controladores de domínio no Microsoft Windows Server 2012 R2 e superior, uma verificação de SPN duplicado no controlador de domínio faz com que haja falhas no ingresso no domínio. Consulte o artigo 3070083 no Microsoft KB. Soluções:
  • Evite reutilizar nomes de farm.
  • Conforme descrito no artigo do Microsoft KB, desative as verificações de SPN duplicado no domínio do Active Directory.
Ao usar os Serviços de Domínio do Azure AD, o fluxo de trabalho de registro do Active Directory falha na etapa de ingresso no domínio com um erro que a permissão Redefinir Senha não possui. (2218180)
A equipe do Horizon Cloud verificou que a inclusão das permissões necessárias à conta de ingresso no domínio funciona da mesma maneira ao usar os Serviços de Domínio do Azure Active Directory (AD) com seu pod, assim como em outras implantações de domínio do Active Directory. Consulte o tópico Criar uma UO (unidade organizacional) em um domínio gerenciado Azure Active Directory Domain Services na documentação da Microsoft que descreve os computadores AADDC de contêineres integrados e consulte também a observação importante no início desse tópico sobre como ativar a sincronização de hash de senha no Azure AD Domain Services. Antes de definir as permissões na conta de serviço de ingresso no domínio, é importante que você siga a documentação da Microsoft sobre como ativar a sincronização de hash de senha nos Serviços de Domínio do Azure AD para as contas de serviço de ingresso no domínio. Se você continuar tendo um erro de permissão de ingresso no domínio no fluxo de trabalho Registrar Active Directory após seguir a documentação da Microsoft, entre em contato com o suporte da VMware e diga o número de relatório de problema 2218180.

Problemas conhecidos relacionados ao Cloud Connector

A configuração do host sem proxy especificada no campo Nenhum Proxy Para ao implantar o modelo OVF não é salva no dispositivo implantado (2454245, 2466306, 2467017, DPM-5388)
Esse problema foi resolvido no Horizon Cloud Connector versão 1.6 ou mais recente. Ao executar o fluxo de trabalho Implantar Modelo OVF no seu ambiente vSphere, você tem a opção de especificar uma configuração de host sem proxy no campo Sem Proxy Para. No entanto, devido a esse problema conhecido, as configurações inseridas não são capturadas nos arquivos de configuração do dispositivo implantado. Como resultado, o dispositivo implantado não honra a configuração especificada do host sem proxy.

Problemas conhecidos relacionados ao Universal Broker

O cliente Horizon Universal Broker no Horizon Cloud Connector não consome atualizações relacionadas ao proxy que você faz no dispositivo do conector após a implantação inicial do dispositivo (HD-35551)
Esse problema foi resolvido no Horizon Cloud Connector versão 1.6 ou mais recente. O cliente Horizon Universal Broker no dispositivo do conector pega os detalhes do proxy durante a primeira inicialização do dispositivo. Como a primeira inicialização é executada apenas durante a primeira vez em que o dispositivo é ligado após a implantação do modelo OVF, todas as alterações subsequentes nas configurações de proxy do dispositivo não são consumidas pelo cliente do Horizon Universal Broker. Colocar esse problema conhecido junto com o problema conhecido acima sobre a configuração sem proxy durante a implantação do modelo OVF significa que qualquer host relacionado ao Horizon Universal Broker não pode ser definido como hosts sem proxy.

Problemas conhecidos relacionados a imagens, farms e atribuições

Os problemas conhecidos listados aqui se aplicam aos pods implantados no Microsoft Azure.

Para pods implantados nas assinaturas de nuvem do Governo do Microsoft Azure, o uso do recurso de criptografia de disco em farms e atribuições de área de trabalho falha. (2572579)
Quando seu pod está localizado em nuvens do Microsoft Azure Governamental e você tenta criar uma atribuição de farm ou VDI com o recurso de criptografia de disco selecionado, o processo de criação falha com o erro Azure error encrypting the VM. Solução alternativa: nenhuma.
Na guia Servidores de um farm existente, todas as opções do Modo de Logon do Usuário dão uma mensagem de erro informando que o Horizon Agent deve ser atualizado. (2528295)
O uso do console administrativo para definir o Modo de Logon do Usuário depende da detecção da versão 20.1.0 do agente em execução na VM do farm. No entanto, essa versão do agente talvez ainda não esteja disponível na camada de controle da nuvem para atualizar os agentes nas suas VMs existentes no farm. Solução alternativa: nenhuma. Quando a versão 20.1.0 do agente está disponível no plano de nuvem e seus pods são atualizados para a versão do manifesto que pode consumir essa versão do agente, você pode atualizar as VMs do farm para esse agente a fim de usar as opções do modo de Logon do Usuário.
Às vezes, algumas VMs de área de trabalho de uma grande atribuição de área de trabalho VDI flutuante relatam status desconhecido do agente. (DPM-3201)
Em atribuições de área de trabalho VDI flutuante com um grande número de VMs de área de trabalho, devido a um problema conhecido, um pequeno número dessas VMs de área de trabalho pode entrar em um estado de agente desconhecido, pois alguns serviços do Windows, como o serviço Blast do Horizon Agent ou o serviço do Microsoft Azure, não iniciam ou estão lentos para iniciar. Como resultado, no console administrativo, a coluna de Status do Agente para essas VMs de área de trabalho exibe o estado "Desconhecido" com erros de agente relatados. Solução alternativa: no console, use a ação Reiniciar para reiniciar as VMs.
O assistente de Importação de VM do Marketplace cria imagens do Windows Server 2012 sem a Experiência de Área de Trabalho ativada. (2101856)
Devido a um problema conhecido, quando você usa o assistente automatizado Importação de VM do Marketplace para criar uma imagem com um sistema operacional Windows Server 2012, a Experiência de Área de Trabalho não está ativada na imagem resultante. Solução alternativa: você deve ativar manualmente a Experiência de Área de Trabalho na imagem resultante. Observe também que, no sistema operacional Windows Server 2012, para instalar o Horizon Agent com a opção de Redirecionamento de Scanner requer a Experiência de Área de Trabalho ativada no sistema operacional.
Ao publicar (também conhecido como selar) uma VM importada, o processo pode resultar em tempo limite atingido ou outras falhas na publicação devido a falhas do sysprep. (2036082, 2080101, 2120508, 2118047)
Depois que você clica em Converter em Área de Trabalho em uma VM importada e em Publicar para torná-la uma imagem publicada (selada), várias operações são realizadas na VM. Essas operações incluem executar o processo de Preparação do Sistema do Windows (sysprep), desligar a VM etc. Devido a problemas conhecidos da indústria com o processo de sysprep do Windows e a personalização de máquinas virtuais, às vezes, o processo de publicação falha por várias razões. Na página Atividade, você pode ver mensagens semelhantes a "Erro de tempo limite. Foram aguardados 20 minutos para que a máquina virtual fosse desligada." e outra mensagem de falha do sysprep.

De modo geral, você pode evitar esses problemas com sysprep ao criar a VM usando o assistente de Importação de Máquina Virtual do Marketplace e selecionado Sim na alternância Otimizar Imagem do Windows do assistente. Se esse erro aparecer para uma VM importada na qual você não usou essa opção ou se você criou a VM manualmente, consulte os artigos KB 2079196 da VMware, KB 2769827 da Microsoft e o artigo 615 do Microsoft MVP para ver as boas práticas de configuração da VM da imagem e minimizar as chances de ter problemas com sysprep ao publicar a imagem. Se os problemas com sysprep persistirem, consulte as informações nos artigos Decisão para otimizar a imagem do Windows ao usar o assistente de Importação de Máquina Virtual do Marketplace e Uso da opção Remover Aplicativos da Windows Store ao usar o assistente de Importação de Área de Trabalho para ver como o assistente automatizado Importação de VM do Marketplace reduz as chances de problemas com sysprep. Se aparecerem erros de tempo limite na página Atividade, tente esta solução alternativa: na página Imagens, use a ação Converter Imagem em Área de Trabalho na imagem. Quando a página Atividade indicar que o sucesso da conversão da imagem em uma área de trabalho, acesse a página VMs Importadas. Conecte-se à VM e execute as boas práticas descritas nos KBs. Depois que a página VMs Importadas relatar que a VM está ligada, selecione a VM e clique em Converter em Imagem para executar novamente o processo de publicação.

Durante a criação do farm, às vezes, as VMs de servidor ficam presas na etapa de personalização. (2010914, 2041909)
Às vezes, durante o processo de sysprep nas VMs de servidor do farm, um serviço do Windows chamado tiledatamodelsvc impede que o sysprep acesse os arquivos do Windows necessários para concluir o processo de personalização do sysprep. Como resultado, as VMs de servidor do farm não serão movidas após a etapa de personalização. O log de erros do sysprep contém a linha "Erro SYSPRP setupdigetclassdevs falhou com o erro 0". Solução alternativa: se você encontrar esse problema e essa mensagem de erro aparecer no arquivo de log de erros do sysprep, tente desativar o serviço tiledatamodelsvc na imagem e criar o farm.
O status do agente pode ser exibido como "indefinido" na página VMs Importadas após a duplicação de uma imagem ou criação manual de uma imagem no Microsoft Azure. (2002798)
Quando você usa o botão Duplicar na página Imagens para clonar uma imagem publicada ou quando cria manualmente a VM da imagem no Microsoft Azure, a VM resultante é listada na página VMs Importadas. Devido a esse problema, mesmo quando a VM está totalmente ligada, o status do agente pode ser exibido como "indefinido". No entanto, quando você seleciona a VM e escolhe Converter em Imagem para publicá-la, a interface do usuário relata o agente no estado "Ativo". Solução alternativa: nenhuma. Se os fluxos de trabalho Redefinir o Emparelhamento do Agente, Nova Imagem ou Converter em Imagem relatarem o agente como "Ativo", você poderá ignorar o status "indefinido" na página VMs Importadas.

Problemas conhecidos relacionados ao App Volumes em pods do Microsoft Azure

Os problemas conhecidos listados aqui se aplicam aos pods implantados no Microsoft Azure.

Quando seu ambiente possui vários pods no Microsoft Azure, o processo de Captura às vezes pode entrar em um estado desconhecido após a conclusão do processo. (2600573)
Quando seu ambiente possui vários pods com os quais você está usando App Volumes, às vezes, após a execução do processo de captura, o console indica que a captura está em um estado desconhecido, mesmo que o processo de captura na VM tenha sido concluído. Para solucionar esse problema, importe novamente o pacote de aplicativos em Inventário > Aplicativos > Novo > Importar. Como resultado, o pacote de aplicativos é importado com sucesso como um aplicativo separado e a atribuição e o lançamento de aplicativos subsequentes funcionam.

Problemas conhecidos relacionados à atualização do agente

Os problemas conhecidos listados aqui se aplicam aos pods implantados no Microsoft Azure.

Quando você tenta uma atualização de agente em uma imagem que tem uma atualização pendente do Windows, o processo de atualização pode falhar. (2234964)
Se a imagem precisar de uma atualização para o sistema operacional Windows, ao contrário de uma pequena atualização que não seja do sistema operacional, isso pode fazer com que os recursos do sistema operacional fiquem offline e não estejam disponíveis para a atualização do agente. Solução alternativa: aguarde até que a atualização do Windows seja concluída e repita a atualização do agente. Para confirmar que todas as atualizações do Windows foram concluídas, você pode colocar a imagem offline, executar todas as atualizações pendentes e publicar novamente a imagem antes de iniciar a atualização do agente.

Problemas conhecidos relacionados aos relatórios e monitoramento

Os problemas conhecidos listados aqui se aplicam aos pods implantados no Microsoft Azure.

No relatório de Atividade do Usuário, a média semanal exibida (horas) não é intuitiva. (1817065)
Devido a esse problema, as estatísticas semanais oscilam com o tempo porque a lógica de cálculo está dividindo a duração da semana atual por sete (7), sem arredondar para uma semana inteira. Por exemplo, quando você seleciona os últimos 30 dias, os dados para as semanas concluídas ficam inalterados, mas os dados para a semana atual são divididos por sete (7). A lógica atual é a média semanal (h) = média diária (horas) * 7 dias. O resultado é a média semanal dos últimos 30 dias = (duração total / 30 dias) * 7 dias. Solução alternativa: nenhuma
O relatório de Integridade de Área de Trabalho não reflete um nome de farm recém-atualizado ou uma atribuição de área de trabalho VDI até uma hora após a alteração do nome. (1756889)
Se você alterar o nome de um farm ou o nome de uma atribuição de área de trabalho VDI, levará uma hora para que o menu suspenso Atribuição e a coluna Atribuição do relatório de Integridade de Área de Trabalho reflitam o novo nome. Solução alternativa: aguarde uma hora para o novo nome aparecer no relatório.
A formatação em alguns dos arquivos CSV que você pode exportar a partir das telas de interface do usuário dos Relatórios não corresponde às tabelas na tela. (2015500)
Algumas das subtelas da página Relatórios fornecem um recurso para exportar os dados exibidos em formato CSV. Devido a esse problema, a formatação nos arquivos CSV exportados dos relatórios de Integridade de Área de Trabalho, de Simultaneidade e de Histórico da Sessão não coincide exatamente com os que você vê exibidos na tela. Por exemplo, a coluna de títulos pode ser diferente e os arquivos CSV podem ter mais colunas de dados que as tabelas na tela. Solução alternativa: nenhuma.

Problemas conhecidos relacionados a gerenciamento de identidade, Workspace ONE Access e True SSO

Os problemas conhecidos listados aqui se aplicam aos pods implantados no Microsoft Azure.

Quando um pod de versões de manifesto anteriores a 1763 é atualizado para o manifesto 1763 ou mais recente, e esse pod tem o RADIUS de dois fatores configurado em suas instâncias do Unified Access Gateway e também está integrado ao Workspace ONE Access, observe que a inicialização de uma área de trabalho do Workspace ONE Access usando o navegador exibirá o formulário de login do RADIUS com o campo de nome de usuário já preenchido com o UPN do usuário. (2248160)
Esse sintoma ocorre devido a uma alteração que foi lançada no VMware Horizon HTML Access 4.10. Quando o pod no Microsoft Azure de uma versão anterior do Horizon Cloud está configurado com instâncias do Unified Access Gateway e autenticação de dois fatores com RADIUS, e você configura esse pod para usar o Workspace ONE Access, antes de iniciar uma área de trabalho do Workspace ONE Access usando o navegador, o formulário de login do RADIUS solicita o nome e o código de acesso do usuário. O usuário final digitaria o nome de usuário e o código de acesso no formulário. No entanto, devido a esse problema, depois de atualizar esse pod para esta versão, usando as mesmas etapas de inicialização da área de trabalho, o formulário de logon do RADIUS possui o campo de nome de usuário pré-preenchido com o UPN do usuário do domínio. Esse comportamento ocorre apenas ao usar o navegador para iniciar a área de trabalho. Ele não ocorre ao usar o Horizon Client. Solução alternativa: se essa situação acontecer, o usuário final poderá limpar o campo de nome de usuário pré-preenchido e inserir suas informações. Geralmente, na maioria dos ambientes integrados ao Workspace ONE Access, a autenticação de dois fatores é configurada no Workspace ONE Access, e não nas instâncias subjacentes do Unified Access Gateway, o que não gera problema.
Poderá haver falha ao iniciar uma segunda área de trabalho do Workspace ONE Access usando o Horizon Client com o erro: “Você não tem autorização para essa área de trabalho ou aplicativo”. (1813881, 2201599)
Esse sintoma ocorre na seguinte situação. O usuário possui direitos a duas atribuições de VDI dedicadas por meio de um direito de grupo. As duas atribuições de área de trabalho VDI dedicada são listadas em Workspace ONE Access quando o usuário faz login. O usuário inicia a primeira área de trabalho usando o Horizon Client. Essa área de trabalho se conecta. Em seguida, o usuário tenta iniciar a outra área de trabalho a partir da outra atribuição, também usando o Horizon Client. A inicialização dessa outra área de trabalho falha com um erro indicando que o usuário não está autorizado. No entanto, esse problema é visto apenas para a primeira tentativa na segunda área de trabalho. Se o usuário iniciar a segunda área de trabalho usando o navegador, as tentativas subsequentes de iniciar a segunda área de trabalho usando o Horizon Client serão bem-sucedidas. Solução alternativa: nessa situação, tente iniciar a segunda área de trabalho usando o navegador.
O Workspace ONE Access não exibe os nomes de exibição dos aplicativos remotos que você definiu no Console Administrativo do Horizon Cloud. (2131583)
Esse problema é resolvido ao usar o Workspace ONE Access Connector versão 19.03. Devido a um problema conhecido nas versões do Workspace ONE Access Connector anteriores à 19.03, quando o Workspace ONE Access exibe os aplicativos remotos que você sincroniza com o Horizon Cloud, o Workspace ONE Access não mostra os nomes de exibição que você definiu para esses aplicativos remotos no Horizon Cloud. O Horizon Cloud envia os nomes de exibição ao Workspace ONE Access, mas o Workspace ONE Access usa os launchIDs dos aplicativos remotos no lugar deles. Como resultado, o Workspace ONE Access exibe os nomes básicos dos aplicativos remotos.

Problemas conhecidos relacionados à interface de usuário

Salvo indicação em contrário no texto do problema conhecido, os problemas conhecidos listados aqui se aplicam aos pods implantados no Microsoft Azure.

O conteúdo da janela Ajuda > Sobre do console administrativo não é exato.
Quando você clica em Ajuda > Sobre no console, as informações na janela não são precisas. Devido a esse problema, o texto é codificado para mostrar sempre a versão 2.2, em vez de indicar os dados precisos e relevantes sobre o ambiente do tenant ou sobre o ambiente da camada de controle de nuvem no qual você está trabalhando. Solução alternativa: nenhuma.
Mesmo que um pod no manifesto 2298.0 ou mais recente deva ter uma configuração de pelo menos um gateway para operações compatíveis, o console administrativo não impedirá que você exclua a configuração de único gateway do pod e o deixe em um estado incompatível.
O console administrativo inclui um fluxo de trabalho no qual você pode excluir a configuração de gateway existente do pod para reimplantar o gateway com uma nova configuração de implantação. Esse fluxo de trabalho é fornecido porque, no momento, o console não dispõe de uma opção para usar o fluxo de trabalho Editar Pod para atualizar a configuração de implantação do gateway, mesmo que o fluxo de trabalho Editar Pod possa ser usado para atualizar a configuração de software do gateway em qualquer point-in-time.

Agora, um pod no manifesto 2298 ou mais recente deve ter uma configuração de pelo menos um gateway para ter operações compatíveis. Quando você exclui essa configuração de único gateway do pod para atualizar a configuração de implantação do gateway, conforme descrito no parágrafo anterior, o console exibe uma mensagem de aviso. No entanto, o console não impede a exclusão do único gateway implantado no pod porque isso é feito para a finalidade do caso de uso, conforme descrito no parágrafo anterior. A expectativa é que você reimplante a configuração do gateway logo em seguida, com novas opções para a implantação do gateway que a configuração excluída não tinha. O problema é que atualmente o console permite excluir a configuração de único gateway de um pod em que pelo menos um gateway é necessário para operações compatíveis, mas ele não exige a reimplantação de um novo gateway no pod logo em seguida. Se você deixar o pod sem uma configuração de gateway, a configuração dele será incompatível.

Solução alternativa: para ter uma configuração compatível, você deve garantir que cada pod do manifesto 2298.0 ou mais recente tenha configuração de pelo menos um gateway. Uma das configurações a seguir deve ser implantada no pod:

  • Um gateway externo
  • Um gateway interno
  • Gateways externos e internos

Se você excluir a configuração de único gateway de um pod do manifesto 2298.0 ou mais recente para alterar uma configuração de gateway que só pode ser alterada excluindo e reimplantando o gateway, você deverá reimplantar um novo gateway no pod para que a configuração permaneça compatível. A equipe de atendimento do VMware Horizon está trabalhando em melhorias que não exigirão mais que o console forneça um fluxo de trabalho para excluir um gateway implantado no caso de uso de alteração da configuração de implantação do gateway. Neste momento, a capacidade de excluir a configuração de único gateway do pod usando o console será impedida.

No Cartão de Usuário, quando você clica em Redefinir em uma sessão de área de trabalho VDI em um pod do Microsoft Azure, uma mensagem de erro é exibida mesmo quando a VM foi redefinida com êxito. (2567272)
Devido a esse problema, mesmo que a operação de redefinição seja iniciada com êxito e a VM seja eventualmente redefinida, o Console Administrativo exibirá uma caixa de mensagem de erro. A mensagem implica que o sistema não foi capaz de concluir sua solicitação, mesmo que a VM seja realmente redefinida. Esse problema pode surgir em uma sessão de área de trabalho de uma atribuição de área de trabalho VDI flutuante. Solução alternativa: nenhuma. A operação de redefinição é iniciada com êxito, e a VM é eventualmente redefinida. Feche a caixa de mensagem de erro exibida.
O gráfico Segmentos de Logon exibido no painel da sessão não possui dados.
Esse problema se aplica a todos os tipos de pods. O serviço VMware Logon Monitor fornece os dados para o gráfico Segmentos de Logon que aparece no painel da sessão. No entanto, essa versão não suporta o uso do serviço VMware Logon Monitor e, por padrão, o Horizon Agents Installer desativa o serviço VMware Logon Monitor em todas as instalações realizadas pelo instalador. Como resultado, mesmo que nenhum dado seja relatado que o gráfico Segmentos de Logon pode exibir, você verá que o gráfico Segmentos de Logon ainda está visível no painel da sessão. Solução alternativa: nenhuma.
Ao usar o console administrativo em uma guia de navegador, se você tentar inicializar um área de trabalho de desconectado que tenha em outra guia no mesmo navegador, o portal do HTML Access também será encerrado e você deverá fazer login novamente no portal do HTML Access. (2118293)
Normalmente, quando você inicia uma área de trabalho e se desconecta dela sem fazer logout da área de trabalho, você permanece conectado ao portal do HTML Access e pode se reconectar à área de trabalho desconectada sem precisar inserir as credenciais no portal do HTML Access. Devido a esse problema, se você estiver em uma janela do navegador na qual você está conectado ao console em uma guia do navegador e usar outra guia do navegador para fazer login no portal do HTML Access e iniciar uma área de trabalho, quando você se desconectar dessa área de trabalho e tentar se reconectar a ela, o portal do HTML Access fará logoff. Em seguida, você deve inserir novamente as credenciais para o portal do HTML Access antes de poder se reconectar à área de trabalho. Solução alternativa: para evitar esse problema, faça login no console administrativo usando uma janela de navegador separada para o portal do HTML Access. Esse comportamento ocorre somente se você também está conectado ao console na guia de navegador, na mesma janela do navegador na qual você também está usando o portal do HTML Access.
Na tela Cartão de Usuário de um usuário específico, as atribuições de área de trabalho VDI dedicadas são removidas da guia Atribuições após a primeira inicialização do usuário da área de trabalho dedicada a partir dessa atribuição. (1958046)
Quando um usuário é especificado em uma atribuição de área de trabalho VDI dedicada como um usuário individual, não por meio de um grupo do Active Directory, essa atribuição de área de trabalho VDI dedicada é exibida na guia Atribuições da tela Cartão de Usuário para apenas esse usuário até a primeira inicialização do usuário de uma área de trabalho dedicada dessa atribuição. Após a primeira inicialização do usuário de uma atribuição de área de trabalho VDI dedicada, a guia Atribuições do cartão de usuário não exibe mais essa atribuição de área de trabalho VDI dedicada para esse usuário. A primeira inicialização do usuário faz com que esse usuário reivindique uma área de trabalho dedicada específica do pool subjacente definido por essa atribuição e o sistema mapeia essa área de trabalho dedicada específica para esse usuário específico. Quando esse mapeamento é feito, essa área de trabalho dedicada específica obtém o estado Atribuído e é listada na guia Áreas de Trabalho do cartão de usuário para esse usuário.

Solução alternativa: em vez de depender da guia Atribuições do cartão de usuário para ver as áreas de trabalho VDI dedicadas já inicializadas e atribuídas a um usuário específico, você pode usar a guia Áreas de Trabalho. Se você precisar localizar a atribuição de área de trabalho VDI dedicada específica na qual esse mapeamento de área de trabalho do usuário é feito, obtenha o nome da área de trabalho na guia Área de Trabalho do cartão de usuário e use o recurso de pesquisa por VMs na faixa superior para listar esta VM da área de trabalho específica. Nos resultados da pesquisa por VMs, clique no nome para abrir a página de atribuição específica que tem essa área de trabalho dedicada em particular. Em seguida, você pode localizar o usuário nos detalhes da atribuição.

A tela Novidades será exibida mesmo se você tiver selecionado anteriormente a opção para não continuar mostrando-a. (2075825)
Esse problema se aplica a ambientes com qualquer tipo de pod. Devido a esse problema, se você limpar o cache do navegador ou se usar um navegador diferente ao qual você selecionou anteriormente a opção para não mostrar a tela Novidades, a tela poderá ser exibida quando você fizer logon no console administrativo. O sinalizador que indica se a tela Novidades vai ser exibida é armazenado no cache local do navegador, em vez de por usuário. Solução alternativa: nenhuma.
Mesmo que o processo de criação de imagem não tenha sido concluído completamente, a tela Introdução exibe Concluído para a etapa Criar Imagem. (2100467)
Devido a esse problema, a etapa Criar Imagem está marcada como concluída prematuramente. Solução alternativa: use a página Atividade para verificar se o processo de criação de imagem foi concluído.
Ao usar o console administrativo, você pode ver espaços reservados em vez de cadeias de caracteres de texto real ou você clica em um botão em uma página e nada acontece. (2045967)
Esse problema se aplica a ambientes com qualquer tipo de pod. A VMware atualiza periodicamente o ambiente de gerenciamento na nuvem que hospeda o console baseado na Web. Esse problema pode ocorrer quando o conteúdo estático foi armazenado em cache no navegador antes da atualização mais recente na nuvem. É um problema temporário que sumirá quando o cache do navegador for apagado. Solução alternativa: tente fazer logout do console, limpar o cache do navegador, reiniciar o navegador e fazer login novamente no console.
Os nomes de aplicativo são exibidos em caracteres minúsculos quando os usuários finais os acessam pelo Workspace ONE Access. (1967245)
Quando seu ambiente Horizon Cloud está integrado ao Workspace ONE Access, os usuários finais acessam suas áreas de trabalho e aplicativos atribuídos pelo Workspace ONE Access. Devido a esse problema conhecido, os usuários veem os nomes de aplicativo exibidos com caracteres minúsculos, independentemente do caso real usado nos nomes de aplicativo. Esta limitação é devido à maneira como o Workspace ONE Access cria IDs de inicialização do Horizon Cloud usando REST APIs mais antigas do Horizon Cloud. Solução alternativa: nenhuma.
As porcentagens de uso de memória informadas para relatórios de integridade da área de trabalho e usadas para os alertas de integridade da área de trabalho se baseiam na porcentagem de memória confirmada, que é igual à memória física mais o tamanho do arquivo de paginação, e não em uma porcentagem de apenas a memória física. (2015772)
A memória confirmada de uma VM de área de trabalho é calculada como a memória física mais o tamanho do arquivo de paginação. Ao calcular a porcentagem de uso de memória em uma área de trabalho, o sistema considera a porcentagem usada desse total (memória física mais tamanho do arquivo de paginação). Os alertas de integridade da área de trabalho e o relatório de uso de memória nos relatórios de integridade da área de trabalho usam esse cálculo de porcentagem. No entanto, quando você faz logon em uma VM de área de trabalho e abre o Gerenciador de Tarefas do Windows para exibir o uso da memória no sistema operacional Windows da área de trabalho, o Gerenciador de Tarefas do Windows exibe a porcentagem com base somente na memória física. Como resultado, a porcentagem de uso de memória exibida pelo Gerenciador de Tarefas do Windows da área de trabalho não coincide com a porcentagem de uso de memória exibida nos relatórios de Integridade da Área de Trabalho ou no alerta de integridade da área de trabalho. Solução alternativa: tenha em mente essa diferença se você fizer uma comparação entre a porcentagem de uso de memória relatada pelo Gerenciador de Tarefas do Windows de uma área de trabalho e a porcentagem de uso de memória que consta no relatório Integridade da Área de Trabalho do console e nos alertas de integridade da área de trabalho.
Se o uso da CPU de uma VM de área de trabalho estiver em ou perto de 100%, o alerta da área de trabalho não será disparado. (1446496)
Se um aplicativo ou algo na VM da área de trabalho fizer com que o uso da CPU da VM alcance 100%, o agente da área de trabalho falhará em enviar a mesma quantidade de amostras de dados que geralmente envia para o Horizon Cloud porque a CPU está muito ocupada. Como resultado da baixa contagem de amostras retornada, o cálculo que o sistema usa para disparar o alerta da área de trabalho é afetado. Solução alternativa: nenhuma.

Problemas conhecidos relacionados a usuário final, Horizon Agent, Horizon Client

Os problemas conhecidos listados aqui se aplicam aos pods implantados no Microsoft Azure.

Para uma VM com o Microsoft Windows 10 Enterprise Multi-Session 2004 ou versões posteriores, os recursos de Sincronização de e Dimensionamento de exibição de DPI apresentam problemas (2587685, DPM-6352)
Devido à incapacidade de consultar o DPI atual em VMs executando o Microsoft Windows 10 Enterprise Multi-Session 2004 ou posterior, esses recursos com essas VMs não funcionam conforme documentado na documentação do Horizon Client. Os recursos de Sincronização e Dimensionamento de exibição de DPI não funcionam para reconexões de sessão PCoIP. O recurso de dimensionamento de DPI não funciona para as reconexões de sessão de transmissão. Solução alternativa: faça logout da sessão e faça login novamente.
Para uma VM que executa o sistema operacional empresarial Microsoft Windows 10 1903 ou posterior, os recursos de Sincronização e dimensionamento de exibição de DPI apresentam problemas (2589129)
Devido à incapacidade de consultar o DPI atual em VMs executando o sistema operacional cliente Microsoft Windows 10 Enterprise 1903 ou posterior, ao reconectar uma sessão PCoIP ou Blast, os recursos não funcionam conforme documentado na documentação do Horizon Client. Solução alternativa: faça logout da sessão e faça login novamente.
Às vezes, ao iniciar uma área de trabalho VDI usando o VMware HTML Access, uma mensagem de erro sobre a desconexão é exibida e, em seguida, o lançamento é bem-sucedido. (2243471)
As máquinas virtuais de área de trabalho VDI têm um tempo limite de conexão de sessão padrão e, quando esse tempo é atingido, a sessão é desconectada. Às vezes, ao iniciar uma área de trabalho, se a sessão do HTML Access do usuário final expirou no momento em que o tempo limite de conexão de sessão padrão da área de trabalho é atingido, a área de trabalho inicialmente lançará esse erro e continuará a inicialização da área de trabalho. Solução alternativa: nenhuma.
Quando uma atribuição de área de trabalho VDI tiver selecionado a criptografia de disco e um modelo de VM de um ou dois núcleos, e a VM subjacente da área de trabalho estiver desligada, a opção de repetição automática do Horizon Client pode falhar ao se fazer uma conexão. (2167432)
Quando uma VM da área de trabalho VDI é desligada devido às configurações de gerenciamento de energia da atribuição da área de trabalho VDI, a VM precisa ser ligada e se preparar para que seja possível estabelecer uma conexão de usuário final com aquela área de trabalho. Quando o cliente de um usuário final tenta se conectar a uma VM de atribuição de área de trabalho VDI e a VM é desligada, o sistema começa a ligar essa VM. Para VMs não criptografadas, a VM normalmente está pronta para aceitar uma conexão de cliente em menos de 10 minutos. No entanto, uma VM criptografada com um ou dois núcleos geralmente leva mais de 10 minutos para se preparar para aceitar uma conexão. A opção Nova Tentativa do Cliente do Horizon Client tem um limite máximo de 12 minutos. Devido a esse limite máximo da opção Nova Tentativa do Cliente, quando o usuário final especifica para o cliente repetir automaticamente a conexão enquanto a VM subjacente da área de trabalho está sendo ligada e preparada, mas a conexão não é feita em 12 minutos, a nova tentativa automática do cliente é interrompida. Como uma VM criptografada geralmente leva mais de 12 minutos até ficar pronta para receber a conexão do cliente, o usuário final pode ver que a nova tentativa automática do Horizon Client não consegue concluir a conexão com a VM de área de trabalho criptografada. Solução alternativa: para ter uma criptografia de disco de uma atribuição de área de trabalho VDI, selecione um modelo de VM com mais de dois núcleos. Caso contrário, se sua atribuição de área de trabalho VDI tiver criptografia de disco e tiver um modelo de VM com um ou dois núcleos, informe aos usuários finais que eles podem enfrentar esse problema usando a opção Nova Tentativa do Cliente com essas VMs de áreas de trabalho criptografadas.
Para uma área de trabalho virtual de uma atribuição de área de trabalho VDI dedicada, o link de atalho na página Recente do Horizon Client pode não iniciar a área de trabalho. (1813881, HD-3686, DPM-1140)
As versões iOS e Android do Horizon Client possuem uma página Recente que exibe links para áreas de trabalho iniciadas recentemente. Quando o usuário inicia pela primeira vez uma área de trabalho virtual de pool dedicado, a área de trabalho é iniciada normalmente e o cliente cria um ícone de inicialização na página Recente. No entanto, quando o usuário se desconecta de uma área de trabalho e depois tenta iniciar a área de trabalho na página Recente, a área de trabalho não é iniciada, pois o ícone de inicialização está usando uma versão mais curta do nome da área de trabalho. Solução alternativa: inicie a área de trabalho na página principal do cliente, e não na página Recente.
Pods com a versão 1976.0 do manifesto e VMs do farm com o agente nível 19.4: os usuários são desconectados das sessões de área de trabalho e de aplicativo remoto após uma hora ao usar os protocolos HTML Access (Blast) e PCoIP. (2519400)
Este problema acontece devido a um problema nos serviços de terminal da Microsoft nos sistemas com várias sessões do Microsoft Windows 10 Enterprise. Para áreas de trabalho baseadas em sessão e aplicativos remotos provisionados em farms RDSH com base no sistema operacional Microsoft Windows 10 Enterprise, quando um usuário final se reconecta a uma área de trabalho ou sessão do aplicativo remoto existente usando o protocolo HTML Access (Blast) ou PCoIP, depois de uma hora, a sessão do usuário é desconectada à força. Não há perda de dados. Mesmo que o usuário possa se reconectar novamente e a sessão esteja no mesmo estado em que estava no momento da desconexão, esse comportamento se repete e a sessão reconectada é novamente desconectada à força após uma hora.

Esse problema é resolvido usando o Horizon Agents Installer (HAI) 20.1 ou posterior. Quando o seu pod 1976.0 for atualizado para o manifesto 1976.1 ou posterior, o assistente de Importação de Máquina Virtual do Marketplace instalará automaticamente o software do agente que tem essa correção. Se o seu pod ainda estiver no nível de manifesto 1976.0, a execução do assistente continuará a instalar o software do agente com o problema. No entanto, quando você sela a VM, a página Imagens mostrará o ponto azul, significando que você pode usar o recurso Atualizar Agente para atualizar o agente para o nível com a correção.

Pods com versões do manifesto anteriores à 2298: ao alternar os protocolos no cliente, se você escolher a opção Conectar, em vez de Fazer Logout e Reconectar, o cliente poderá não responder. (2528014)
Esse problema é resolvido nos pods que são atualizados para a versão do manifesto 2298 ou mais recente. Este problema acontece ao alternar protocolos no cliente após o estabelecimento de uma sessão para um farm RDSH usando um protocolo. Quando você inicia a área de trabalho ou o aplicativo usando um protocolo, desconecta a sessão, usa o menu do cliente para alternar para um protocolo diferente e inicia a mesma área de trabalho ou aplicativo, o cliente apresenta uma caixa de diálogo que informa que a área de trabalho está aberta no servidor, mas executando um protocolo diferente e mostra uma opção para conectar ou fazer logout e reconectar. Se você selecionar o botão Conectar, a caixa de diálogo será exibida pela segunda vez e, se você selecionar Conectar novamente, o cliente não responderá.
Quando você usa o recurso Agente de Atualização para atualizar imagens que têm uma versão do agente anterior à 18.2.2, o processo de atualização pode falhar (2200962)
As imagens que você criou em nós no nível de manifesto anterior a 965 podem enfrentar esse problema. Às vezes, a imagem tem valores de registro RunOnce que bloqueiam a conclusão do processo de atualização do agente. Solução alternativa: execute a atualização do agente novamente, adicionando o seguinte argumento de linha de comando à guia Linha de Comando do assistente de Atualização de Agente: VDM_SUPPRESS_RUNONCE_CHECK=1