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

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.

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 os pods do Horizon ao Horizon Cloud, para os problemas conhecidos do software em execução nesses pods do Horizon, consulte as notas da versão nos seguintes locais, de acordo com a versão do software do Servidor de conexão do pod:

Para os problemas conhecidos do Serviço de Gerenciamento de Imagens (IMS) que envolvem recursos de IMS que estão disponíveis em produção para todos os clientes do Horizon Cloud, consulte a página de problemas conhecidos em Gerenciamento de imagens do Horizon a partir 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 à assinatura do Microsoft Azure

Depois de usar o Horizon Universal Console para atualizar a chave secreta para as configurações de assinatura do Azure de um pod, as VMs do gerenciador de pod deverão ser reiniciadas para que as novas credenciais entrem em vigor (2979394, 3007687, 3017415)
Devido a esse problema conhecido, depois de editar e salvar a configuração de Chave do Aplicativo na janela Gerenciar Assinatura do console, a chave secreta recém-inserida não entrará em vigor nas VMs do gerenciador de pods até que o serviço de gerenciamento seja reiniciado no Sistemas operacionais das VMs. Se o serviço de gerenciamento não for reiniciado, as chamadas de API usadas pelo serviço para trabalhar com recursos na assinatura começarão a falhar. Solução alternativa: se o pod estiver nessa situação em que sua chave secreta de assinatura precisa ser atualizada por algum motivo, como uma data de expiração próxima ou passada, abra uma solicitação de serviço para obter assistência do Suporte da VMware e das equipes do Horizon Cloud Operations para garantir a sequência de etapas são realizadas com êxito. Em um alto nível, as etapas são:
  1. No Portal do Azure, gere uma nova chave secreta.
  2. No Horizon Universal Console, siga as etapas padrão para atualizar a chave secreta usada pelo pod ou pods associados à chave antiga, conforme descrito na página Alterar, modificar e atualizar as informações de assinatura associadas aos pods implantados do Horizon Cloud.
  3. Peça ao suporte da VMware para reiniciar o serviço de gerenciamento em ambas as VMs do gerenciador de pods.

O comando específico para reiniciar o serviço de gerenciamento não é adequado para publicação pública aqui, pois apenas as equipes da VMware poderão executar esse comando. Essas equipes podem fazer referência ao problema interno 3007687-update-9.

Problemas conhecidos relacionados ao Cloud Connector

O status do Serviço de Monitoramento do Servidor de Conexão (CSMS) é exibido como Não Pronto na área Integridade do portal de configuração do Horizon Cloud Connector (3236634)
Conforme descrito no artigo 91124 da base de conhecimento da VMware, para o Horizon Cloud Connector versão 2.3, após o reinício do dispositivo do Horizon Cloud Connector ou após o reinício do cluster do Kubernetes do dispositivo, o status do CSMS será exibido como Não Pronto.

Esse problema foi resolvido no Horizon Cloud Connector a partir da versão 2.4. Para solucionar o problema nas versões anteriores, siga as etapas no artigo da base de conhecimento.

Problema de expiração do certificado (3083444)
Foi constatado que um certificado nas versões do Horizon Cloud Connector anteriores à 2.4 tem uma data de expiração de um ano a partir do momento da implantação do dispositivo. Quando esse certificado expirar, o Horizon Cloud Connector não poderá mais entrar em contato com a camada de controle do Horizon Cloud, tornando inoperáveis os serviços com base na nuvem fornecidos pelo Horizon Cloud Connector. Consulte a Base de conhecimento 90505 para obter mais detalhes e etapas para corrigir.

A partir do Horizon Cloud Connector versão 2.4, o sistema renova automaticamente os certificados antes da expiração.

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 à configuração do gateway de pods do Horizon Cloud

O recurso Horizon Universal Console para habilitar as configurações do servidor de syslog na configuração do gateway está desativado por padrão. (3005985, 3023935, 3026855)
Devido a um problema identificado com a chamada da API do sistema para atualizar a configuração do Unified Access Gateway com as informações do servidor de syslog, o recurso lançado anteriormente é desativado no console. Solução alternativa: nenhuma.

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.
A mensagem de erro "Falha ao se conectar ao servidor de conexão" é exibida quando o seu Horizon Client ou Horizon HTML Access no navegador começa a se conectar ao Universal Broker (2714266)
Esse problema afeta pods do Horizon Cloud no Microsoft Azure que estão executando o manifesto 2632.x, em tenants configurados para usar o Universal Broker para a intermediação de áreas de trabalho do usuário final. Outra manifestação desse problema é que você observa que ambos os itens a seguir ocorrem ao mesmo tempo:
  • Na página de detalhes do pod no qual a VM de área de trabalho reside, você vê a integridade da VM do gerenciador de pods relatada como Erro para todas as VMs do gerenciador de pods do pod.
  • A mensagem de erro "Esta área de trabalho não está disponível no momento. Tente se conectar a esta área de trabalho mais tarde ou entre em contato com o administrador do sistema." é exibida quando o Horizon Client ou o Horizon HTML Access no navegador começa a se conectar ao Universal Broker.
Esse problema poderá ocorrer intermitentemente para os pods do Horizon Cloud no Microsoft Azure que estão executando o manifesto 2632.x se a instância do gerenciador de pods tiver sido reinicializada. Às vezes, quando a instância do gerenciador de pods tiver sido reinicializada (uma situação rara, atípica), após a instância do gerenciador de pods ser acionada, e o Universal Broker tentar uma conexão com o pod, ela não poderá fazer uma conexão autenticada. Solução alternativa: nenhuma. Se você encontrar essa situação, abra uma solicitação de serviço para obter assistência e cite o número de relatório de problema interno 2714266.

Para pods no manifesto 2747.x e posteriores, esse problema foi resolvido.

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

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

Durante o processo de publicação de imagem, ocorre um erro de tempo limite, e a VM permanece ligada, e impede que o fluxo de publicação seja concluído com êxito (2954270, 2962049)
Esse problema é o resultado de um problema no hipervisor do Microsoft Azure que ocorre ao executar a etapa sysprep do processo de publicação. O problema ocorre em alguns modelos de VM do Azure. Para obter detalhes adicionais, consulte o artigo KB88343 da Base de Conhecimento da VMware.

Com base na recomendação da equipe do Microsoft Azure, para fornecer uma resolução aos clientes do Horizon Cloud, o modelo padrão de VM do Azure usado pelo assistente de Importação automatizada de VM do Marketplace do serviço é alterado na versão v2204 do serviço para usar o modelo Standard_DS2_v2 para a importação automatizada de VMs sem GPU do Windows 10 (sessão única e várias sessões):

  • Para imagens de pod único, o modelo de VM padrão da automação é alterado do modelo de VM Standard_D4_v3 usado anteriormente para usar o Standard_DS2_v2.
  • Para imagens de vários pods, o modelo de VM padrão da automação é alterado do modelo de Standard_D2_v2 usado anteriormente para usar Standard_DS2_v2.

A partir da versão v2204, inclua a quota para a série DSv2 do Azure nas assinaturas do Azure do seu pod.

As VMs e seus recursos relacionados podem não ser excluídos completamente da assinatura do Microsoft Azure. (2824239, 2681761, 2750176)
Esse problema foi resolvido para os manifestos do pod 2915.x ou posterior. Se ou quando esse problema ocorrer em pods de manifestos anteriores, poderão ocorrer problemas como a expansão de atribuições de VDI. Esse problema ocorre devido a um problema no Azure Resource Manager (ARM) da Microsoft e atraso na replicação do status dos recursos em várias regiões da nuvem do Microsoft Azure. Devido a esse problema do Microsoft ARM, alguns desses recursos relacionados à VM podem não ser excluídos e, portanto, desanexados de uma VM na assinatura do Azure. Exemplos de tais itens não anexados que podem ocorrer são discos e NICs. Solução alternativa: esse problema foi resolvido para pods que executam manifestos 2915.x ou posterior. Se você encontrar esse problema, registre uma solicitação de serviço (SR) para solicitar assistência com a limpeza dos dados obsoletos e agendar o upgrade do pod para evitar a recorrência do problema. Consulte o artigo 2006985 da KB para obter as etapas de preenchimento de SR.
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 for mostrado para uma VM importada na qual você não usou essa opção ou se você tiver criado a VM manualmente, consulte o Microsoft KB 2769827 e o artigo 615 do Microsoft MVP para obter as práticas recomendadas 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 parar e desativar o serviço tiledatamodelsvc na imagem. Em seguida, crie 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.

O upload de pacotes de aplicativo (arquivos .vhd) com o mesmo nome de arquivo para o mesmo local (compartilhamento de arquivos), capturados em momentos diferentes, pode impedir que o serviço App Volumes anexe aplicativos às Áreas de Trabalho VDI quando o usuário faz login (2783560)
Sempre que o App Volumes captura um pacote de aplicativo (arquivo .vhd), o sistema gera um GUID exclusivo para identificar a sessão de volume ou captura. Quando você tenta carregar um pacote de aplicativo para o compartilhamento de arquivos de preparação de pods do Horizon Cloud Azure com um nome de arquivo (.vhd) que foi carregado anteriormente, ocorre uma incompatibilidade entre os GUIDs já presentes nos pods do Horizon Cloud Azure e nos serviços de nuvem.

O serviço App Volumes Manager em execução nos pods do Horizon Cloud Azure importa periodicamente os pacotes de aplicativo do compartilhamento de arquivos. Quando você tenta importar os aplicativos da página de importação Inventário > Aplicativos do Horizon Universal Console, os pacotes de aplicativos recém-importados e seus GUIDs correspondentes não coincidem com os GUIDs presentes no serviço App Volumes Manager que executa os pods do Horizon Cloud Azure. Devido a essa incompatibilidade, os aplicativos atribuídos não são anexados aos usuários autorizados.

A remoção de alguns usuários ou grupos de uma atribuição do App Volumes no console pode remover os direitos de alguns dos usuários ou grupos restantes na atribuição (2704889)
Devido a esse problema, no cenário em que você criou uma atribuição do App Volumes que contém um conjunto de aplicativos e usuários ou grupos especificados, edita essa atribuição e remove alguns desses usuários ou grupos específicos, alguns dos usuários e grupos que permanecem configurados nessa atribuição descobrem que não veem os aplicativos em suas áreas de trabalho autorizadas.

Embora esse problema seja resolvido no manifesto do pod 2747 e posterior, você pode encontrar o problema em pods de versões anteriores do manifesto. Se encontrar esse problema, você poderá solucioná-lo criando uma nova atribuição do App Volumes com os aplicativos, usuários e grupos necessários e excluindo a atribuição do App Volumes criada anteriormente.

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.
Em uma implantação de várias sessões do Microsoft Windows 10 Enterprise, um trabalho de impressão pode terminar quando outro usuário faz login na mesma máquina.
Nesse ambiente, quando um usuário com uma atribuição de pacote de aplicativos contendo um driver de impressora faz login pela primeira vez, um trabalho de impressão em andamento para outro usuário nessa máquina de várias sessões pode entrar em um estado de erro. Para contornar esse problema, aguarde alguns minutos ou mais após o término do trabalho de impressão e tente novamente. Consulte o guia Administração do seu ambiente de tenant do Horizon Cloud e sua frota de pods integrados para obter informações relacionadas às práticas recomendadas.
Em uma implantação de várias sessões do Microsoft Windows 10 Enterprise, os usuários não atribuídos a um pacote de aplicativos recebem aspectos do aplicativo

Nesse ambiente, ocasionalmente, quando você não desativa as atualizações automáticas de um aplicativo durante o provisionamento, a parte atualizada do aplicativo se torna inadvertidamente visível para todos os usuários (não apenas para aqueles que receberam o aplicativo) na área de trabalho de várias sessões, como na forma de um atalho da área de trabalho e binários de aplicativo. Para contornar esse problema, para aplicativos com serviços de atualização automática, adicione o nome do serviço de aplicativo à configuração do Registro svservice de várias cadeias de caracteres DisableAppServicesList, para garantir que os serviços de atualização automática não sejam iniciados. Consulte o guia Administração do seu ambiente de tenant do Horizon Cloud e sua frota de pods integrados para obter informações relacionadas às práticas recomendadas.

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

Iniciar um desktop dedicado a partir de um Horizon Client usando uma opção de abrir recentes (ou uma opção equivalente, com base no tipo de cliente) pode não iniciar corretamente o desktop dedicado (SR23422432704, HCS-39121)
Vários Horizon Clients fornecem mecanismos pelos quais o cliente memoriza um aplicativo remoto ou desktop iniciado anteriormente e o usuário final pode iniciar esses desktops anteriormente abertos ou aplicativos publicados sem acessar a lista completa de desktops e aplicativos aos quais ele tem direito.

Por exemplo, no Horizon Client para iOS e no Horizon Client para Android, as telas rotuladas como Recentes fornecem acesso a esses desktops e aplicativos remotos iniciados anteriormente. Conforme descrito na documentação do Horizon Client para Mac, o Horizon Client para Mac fornece duas maneiras de abrir desktops e aplicativos remotos recentes: usando a opção Arquivo > Abrir Recentes do cliente e, se o cliente for adicionado ao Dock, usando o ícone no Dock. Conforme descrito na documentação do Horizon Client para Windows, o Horizon Client para Windows tem uma configuração de GPO para a integração de listas de atalhos, normalmente ativada por padrão, que permite que os usuários se conectem a desktops recentes e aplicativos publicados usando o ícone do Horizon Client na barra de tarefas do Windows.

No caso de um desktop dedicado provisionado pelo Horizon Cloud on Microsoft Azure, após a inicialização inicial do desktop, o Horizon Client poderá não armazenar a identidade correta do desktop em uma inicialização recente.

Devido a esse problema, quando o usuário final usar posteriormente um dos mecanismos recentes dos clientes descritos acima para abrir novamente o desktop, este talvez não seja iniciado.

Esse problema também poderá ocorrer se o Workspace ONE Access for usado com a implantação do Horizon Cloud on Microsoft Azure e o Horizon Client redirecionar o usuário ao Workspace ONE para orquestrar a inicialização do desktop dedicado. Quando o usuário final tiver iniciado o desktop diretamente do portal do Workspace ONE e, em seguida, tentar usar um dos mecanismos recentes do cliente para iniciar esse desktop, quando o cliente for redirecionado ao Workspace ONE para orquestrar a inicialização, o desktop talvez não seja iniciado devido a esse problema.

Solução alternativa: para evitar esse problema, sempre inicie o desktop selecionando-o diretamente na lista completa de desktops do cliente ou, onde o ambiente estiver configurado para exigir que todas as inicializações sejam realizadas a partir do portal do Workspace ONE, fazendo a inicialização por meio seleção do desktop no portal do Workspace ONE. Evite usar o mecanismo recente de um cliente (evite usar Arquivo > Abrir Recentes ou a lista Recentes ou qualquer um dos mecanismos recentes oferecidos pelos clientes).
Observação: Quando o redirecionamento do Workspace ONE está ativado para a implantação do Horizon Cloud on Microsoft Azure, um usuário final usa um mecanismo recente e a inicialização do desktop falha, um evento de auditoria do Workspace ONE é gravado para indicar essa falha.
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 de 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