Use as informações nesta página em conjunto com Novidades das Notas da Versão. Além dos itens listados no documento Notas da Versão, esta página é voltada para aqueles que já tinham pods conectados à nuvem integrados em seu ambiente antes da data de atualização do serviço (outubro de 2020) ou que têm experiência anterior com os recursos e os fluxos de trabalho do Horizon Cloud. Esta página descreve como os novos recursos e as alterações podem afetar você e os pods. Somente estão descritas as alterações significativas feitas nos recursos e nos fluxos de trabalho. Alterações secundárias, como novos layouts e esquemas de cores no console administrativo que não alteram significativamente os fluxos de trabalho, não são detalhadas aqui.

Para ver as informações atualizadas sobre os diversos fluxos de trabalho que você executa no ambiente de tenant do Horizon Cloud, leia os tópicos de documentação encontrados nos guias individuais vinculados na página de documentação do Horizon Cloud Service.

Importante: Para obter informações fundamentais para entender os termos usados nesta página, consulte as informações no documento Notas da Versão antes de ler as informações nesta página. O documento Notas da Versão tem informações relevantes, como o número do manifesto mais recente dos pods implantados no Microsoft Azure. Além disso, tenha em mente que os fatos principais descritos na seção a seguir são verdadeiros em cada versão do Horizon Cloud.

As seções a seguir remetem a setembro de 2019. Informações semelhantes sobre versões anteriores não estão disponíveis para publicação.

Cinco fatos principais sobre cada versão do Horizon Cloud

  • Todos os novos recursos baseados no plano de nuvem que não dependem do nível da versão do manifesto do pod, do nível da versão do Horizon Cloud Connector, do nível da versão do pod do Horizon ou das diferenças regionais da camada de controle são fornecidos automaticamente aos clientes novos e atuais. Por exemplo, um novo recurso que não depende de novas interfaces de programação de aplicativos para chamadas de interface de programação de aplicativos entre o plano de nuvem e os pods ou relacionadas ao Horizon Cloud Connector ficará visível e poderá ser explorado pelos clientes atuais, a menos que indicado abaixo ou observado em contrário nos guias do produto. Para ilustrar este aspecto, um recurso desse tipo é o envio de feedback avançado do console. Mesmo que este ícone de feedback tenha sido lançado em 9 de julho de 2020, o ícone e o fluxo estão disponíveis para uso por ambientes de tenant que existiam antes de 9 de julho de 2020, mesmo antes de atualizar os pods ou o Horizon Cloud Connector para as versões mais recentes.
  • A partir do dia em que a versão do manifesto é lançada na camada de controle de nuvem, o implantador de pods no Microsoft Azure sempre implanta os pods com a última versão do manifesto.
  • Os pods já implantados existentes no tenant do serviço antes do dia em que uma nova versão do manifesto do pod é lançada no plano de nuvem continuarão sendo executados na versão do manifesto existente até que sejam atualizados para o manifesto totalmente novo da versão. Os seguintes fatos são verdadeiros:
    • Novos recursos do serviço que não dependem de interfaces de programação de aplicativos que exigem o nível de manifesto mais recente estarão disponíveis para os pods atuais.
    • Novos recursos do serviço que dependem de interfaces de programação de aplicativos no nível de manifesto mais recente não estarão disponíveis para os pods atuais até que eles sejam atualizados.
    • Alguns recursos novos do serviço podem depender da região do plano de nuvem onde a sua conta do tenant está localizada. Esses recursos são indicados na documentação, quando aplicável. Sua região da camada de controle é indicada no e-mail Bem-vindo ao Serviço do Horizon enviado quando a conta do cliente é criada, conforme descrito em Integração com o Horizon Cloud para Microsoft Azure, o Horizon Local e o Horizon no VMware Cloud on AWS.
  • O assistente de Importação de VM do Marketplace do console usa o Horizon Agents Installer (HAI) que está integrado ao manifesto do pod. Como resultado, os pods implantados com a última versão do manifesto terão o HAI mais recentes integrado a eles, e a execução do assistente de Importação de VM e a seleção de um pod no nível mais recente instalarão os agentes com base no HAI mais recente. Para os pods que ainda não foram atualizados para o nível de manifesto mais recente, o assistente de Importação de VM do Marketplace usa a versão do HAI que estava disponível no momento em que os respectivos manifestos do pod foram criados.
  • Os pods do Horizon são integrados ao Horizon Cloud em dois casos de uso principais: para ativar o uso de uma licença de assinatura com esses pods e para permitir o uso de serviços hospedados em nuvem que o Horizon Cloud oferece aos pods do Horizon. Cada pod é integrado usando o Horizon Cloud Connector. A integração dos pods do Horizon com Horizon Cloud começou com os ambientes Horizon 7 versão 7.6 e Horizon Cloud Connector 1.0 para ativar as licenças de assinatura nos pods do Horizon. Depois disso, a cada nova versão do Horizon combinada com uma nova versão do Horizon Cloud Connector, são disponibilizados serviços adicionais hospedados na nuvem para pods do Horizon conectados à nuvem que executam a versão mais recente do Horizon emparelhada com a versão mais recente do Horizon Cloud Connector. Recomendamos que os clientes com versões anteriores do Horizon Cloud Connector atualizem para esta versão mais recente para aproveitar os novos recursos e as correções de segurança e de resiliência. Consulte também a ferramenta Matrizes de interoperabilidade de produtos VMware para ver a matriz de versões do software do pod do Horizon compatíveis com o Horizon Cloud Connector. Se você estiver executando uma combinação de versão do Servidor de Conexão do Horizon e do Horizon Cloud Connector que não faz mais parte dessa matriz, atualize-a o mais rápido possível para uma combinação compatível.

Outubro de 2020 - v2010

Use as seguintes informações quando você tiver pods conectados à nuvem com data anterior a outubro de 2020 e para saber os efeitos sobre a sua experiência em relação aos recursos descritos na seção Novidades das Notas da Versão de outubro de 2020.

Novas versões dos seguintes binários de chave foram apresentadas em outubro de 2020: uma nova versão de manifesto de pod para pods implantados pelo serviço, novas versões do Horizon Cloud Connector, Universal Broker Plugin Installer e o Horizon Agents Installer (HAI).

Essa lista é baseada nos itens listados na seção Novidades de outubro de 2020 da página Notas da Versão.

Novos itens relacionados ao Horizon Cloud Connector e seu uso com pods do Horizon
  • Horizon Cloud Connector versão 1.8 é lançada nos formulários OVA e VHD.
  • O Horizon Cloud Connector 1.8 fornece a capacidade de selecionar um perfil de implantação para ativá-lo com o suporte à licença de assinatura somente ou com recursos do Horizon Cloud. Essa seleção é feita durante a implantação do dispositivo.
  • O Horizon Cloud Connector agora é compatível com os pods do Horizon implantados no Azure VMware Solution (AVS). Atualmente, esse suporte é para o uso da sua licença de assinatura com essas implantações. O conjunto completo de serviços hospedados na nuvem ainda não é fornecido para esses tipos de implantação.
Novos itens relacionados aos pods implantados pelo serviço no Microsoft Azure
Os pods do Horizon Cloud no Microsoft Azure agora oferecem suporte à capacidade de especificação de tags de recursos do Azure personalizadas durante uma implantação de pod ou de gateway. O implantador do pod aplica as tags especificadas aos grupos de recursos que o implantador do pod cria. Para obter uma descrição dos grupos de recursos que o implantador do pod cria, consulte Grupos de recursos criados para um pod implantado no Microsoft Azure. Esse novo recurso não depende da versão do manifesto do pod.

Julho de 2020 - v3.1

Use as seguintes informações quando você tiver pods conectados à nuvem com data anterior a julho de 2020 e para saber os efeitos sobre a sua experiência em relação aos recursos descritos na seção Novidades das Notas da Versão de julho de 2020.

Especificamente sobre os pods do Horizon conectados à nuvem existentes
Lançamento do Horizon Cloud Connector 1.7. Para ver os recursos, consulte a seção Novidades de julho de 2020 nas Notas da Versão.
Especificamente sobre os pods existentes no Microsoft Azure
Para os novos recursos a seguir descritos na seção Novidades do documento Notas da Versão de julho de 2020 que serão usados com um pod existente, esse pod deve primeiro ser atualizado para o manifesto 2298.0 ou mais recente para aproveitar as vantagens dos recursos.
  • Várias sub-redes de tenants para uso com farms e atribuições de área de trabalho VDI. Esse recurso ainda não está disponível para uso com atribuições de área de trabalho de várias nuvens, usadas em um tenant configurado com o Universal Broker.
  • Uso do balanceamento de carga de sessão avançado em farms do RDSH.
  • Capacidade de cancelar tarefas de expansão de área de trabalho e farm que estejam no estado em fila ou em execução, com suporte para atribuição automática de áreas de trabalho e redimensionamento de farms. Esse recurso ainda não está disponível para uso com atribuições de área de trabalho de várias nuvens, usadas em um tenant configurado com o Universal Broker.
  • Para fornecer tempos de login de usuário final aprimorados, foi reduzido o tempo necessário para uma VM chegar ao estado pronto para o agente em VMs de área de trabalho provisionadas por pods que estão desligadas e precisam ser ativadas para atender à solicitação de um usuário final por uma área de trabalho.
  • Uso dos recursos do App Volumes: os pods devem ser atualizados para a versão do manifesto desta versão, e sua conta de cliente deve estar localizada em uma das seguintes regiões de camada de controle do Horizon Cloud: USA-2 (PROD1_NORTHCENTRALUS2_CP1), Europe-2 (PROD1_NORTHEUROPE_CP1) ou Australia-2 (PROD1_AUSTRALIAEAST_CP1). Sua região de camada de controle está indicada no e-mail de boas-vindas ao Horizon Cloud Service.

Ao implantar uma configuração de gateway no seu pod, além do tamanho da VM Standard_A4_v2 nas versões anteriores, agora existe a opção de usar o tamanho da VM Standard_F8s_v2, que oferece mais vCPUs em cada instância do Unified Access Gateway. Para pods existentes, esse novo recurso está disponível ao editar o pod para adicionar uma nova configuração de gateway a esse pod.

Itens adicionais relevantes para os clientes atuais
Um aprimoramento para enviar comentários sobre o produto agora está disponível na barra de cabeçalho do console para todos os clientes existentes.

Os pods que podem ter o recurso HA (alta disponibilidade) agora são compatíveis com o Microsoft Azure Governamental (US Gov - Virgínia, US Gov - Arizona e US Gov - Texas). Se você tiver um pod existente no Microsoft Azure Governamental para o qual deseja esse recurso, entre em contato com o representante da VMware para ativá-lo.

Março de 2020 - v3

Use as seguintes informações quando você tiver pods conectados à nuvem com data anterior a março de 2020 e para saber os efeitos sobre a sua experiência em relação aos recursos descritos na seção Novidades das Notas da Versão de março de 2020.

Especificamente sobre os pods do Horizon conectados à nuvem existentes
O lançamento do Horizon Cloud Connector 1.6.x conta com uma ferramenta de diagnóstico de linha de comando para você verificar a integridade dos componentes do sistema do pod do Horizon e dos serviços necessários para o Horizon Cloud Connector emparelhar corretamente o pod com o Horizon Cloud. Antes de fazer login no portal de configuração baseado na Web e executar o assistente de configuração de pod, você pode executar essa ferramenta de diagnóstico para verificar as coisas que possam impedir um resultado bem-sucedido. Se houver problemas descobertos, a ferramenta informará o nome do componente, os detalhes e as etapas de correção recomendadas.
Especificamente sobre os pods existentes no Microsoft Azure
Para os novos recursos a seguir descritos na seção Novidades do documento Notas da Versão de março de 2020 que serão usados com um pod existente, esse pod deve primeiro ser atualizado para o manifesto 1976.0 ou mais recente para aproveitar as vantagens dos recursos, salvo indicação em contrário.
  • Para oferecer suporte a configurações avançadas de implantação, ao usar uma assinatura separada para a configuração externa do Unified Access Gateway, você pode implantar os recursos do Unified Access Gateway em um grupo de recursos existente criado pelo cliente, em vez do padrão criado pelo implantador de pod. Para que um pod existente aproveite esse novo recurso, é necessário primeiro atualizá-lo para a versão 1763 ou posterior do manifesto (manifesto de dezembro de 2019). Em seguida, você precisa atender a todos os requisitos documentados para usar uma assinatura separada, uma VNet e um grupo de recursos personalizado para a configuração do gateway externo, incluindo o emparelhamento dessa VNet com a VNet do pod e a criação do grupo de recursos nessa assinatura. Na sequência, você deve excluir a configuração do Unified Access Gateway externo existente do pod, usando o fluxo de trabalho do console para excluir esse gateway externo existente. Quando a exclusão for concluída, você poderá executar o fluxo de trabalho Editar Pod para adicionar o gateway externo usando a nova opção para colocar o Unified Access Gateway externo no seu grupo de recursos existente.
  • Suporte para que os administradores especifiquem que os nomes das atribuições de área de trabalho VDI dedicadas sejam exibidos nos clientes de usuário final depois que uma VM de área de trabalho VDI é atribuída ao usuário final, em vez de exibir o nome da VM da área de trabalho. Anteriormente, depois que um usuário final exigia uma VM de área de trabalho VDI específica, o cliente exibia o nome da VM da área de trabalho por padrão e esse comportamento não era configurável. Essa opção não altera o que é exibido para essas conexões de usuário final que estão passando pelo Workspace ONE Access. O Workspace ONE Access sempre exibe o nome de atribuição da área de trabalho VDI dedicada e, quando o usuário final inicializa a VM de área de trabalho no Workspace ONE Access, o nome da área de trabalho aparece no cliente do usuário final. Mesmo que você veja a opção desse recurso na página Configurações Gerais, um pod deve executar a versão 1976.0 do manifesto, ou mais recente, para aproveitar esse recurso.
  • O manifesto 1976.0 ou posterior do pod permite que os administradores coloquem uma VM do farm individual no modo de manutenção, de forma que o administrador possa realizar as ações de manutenção na VM. Antes que você possa explorar esse recurso para definir um modo de manutenção por VM, o pod deve estar executando a versão de manifesto desta versão. Além disso, devido a um problema conhecido no console, mesmo que as opções desse recurso sejam exibidas na guia Servidores do farm no console, as opções da interface do usuário não definirão o modo até que os agentes nas VMs do farm estejam executando a versão 20.1.0 ou posterior.
Itens adicionais relevantes para os clientes atuais
Aprimoramentos nos relatórios disponíveis na página Relatórios e na página Painel do console. Os dados nesses relatórios são fornecidos pelo Serviço de Monitoramento da Nuvem. Os pods existentes podem aproveitar esse recurso.

Dezembro de 2019 - v2.2

Use as seguintes informações quando você tiver pods conectados à nuvem com data anterior a dezembro de 2019 e para saber os efeitos sobre a sua experiência em relação aos recursos descritos na seção Novidades das Notas da Versão de dezembro de 2019.

Especificamente sobre os pods do Horizon conectados à nuvem existentes
A partir desta versão:
  • Alguns itens que estão dentro do seu controle podem impedir uma atualização automática bem-sucedida do Cloud Connector, como espaço de datastore insuficiente no seu ambiente vCenter para acomodar a atualização. A partir desta versão, se a atualização automatizada estiver ativada na sua conta de tenant do Horizon Cloud, esses itens serão identificados no console para que você possa solucioná-los e limpá-los.
  • As atualizações automáticos do Horizon Cloud Connector agora são compatíveis com os pods do Horizon implantados no VMware Cloud on AWS.
  • Melhorias na tela de sucesso da integração do Horizon Cloud Connector incluem a exibição do status de integridade dos componentes do Connector e uma opção para ativar e desativar o SSH no dispositivo do Horizon Cloud Connector.
Especificamente sobre os pods existentes no Microsoft Azure
Para os novos recursos a seguir descritos na seção Novidades do documento Notas da Versão de dezembro de 2019 que serão usados com um pod existente, esse pod deve primeiro ser atualizado para o manifesto 1763.0 ou mais recente para aproveitar as vantagens dos recursos, salvo indicação em contrário.
  • Para oferecer suporte a configurações avançadas de implantação, o implantador de pod inclui opções para:
    • Usar uma VNet separada para as instâncias de Unified Access Gateway da configuração do gateway externo, separada da VNet do pod e dos elementos do pod principal. O VNets deve ser emparelhado.
    • Usar uma assinatura separada para a configuração do Unified Access Gateway externo, separada da assinatura usada para os elementos principais do pod. Como uma VNet é definida como escopo para uma assinatura, o cenário de implantação de assinatura separada também é o cenário da VNet individual. O VNets deve ser emparelhado.
    • Para que um pod existente aproveite esse recurso, o pod deve primeiro ser atualizado para o manifesto 1763.0 ou mais recente. Em seguida, você precisa atender a todos os requisitos documentados para usar uma VNet separada para a configuração do gateway externo, incluindo o emparelhamento dessa VNet com a VNet do pod. Na sequência, você deve excluir a configuração do Unified Access Gateway externo existente do pod, usando o fluxo de trabalho do console para excluir esse gateway externo existente. Quando a exclusão for concluída, você poderá executar o fluxo de trabalho Editar Pod para adicionar o gateway externo usando as novas opções.
  • A partir do manifesto desta versão, você pode usar tipos de disco SSD para atribuições de área de trabalho VDI e farms RDSH.
  • A partir do manifesto desta versão, você pode personalizar os tamanhos de disco do SO para atribuições de área de trabalho VDI e farms RDSH. Em manifestos do pod anteriores, seus tamanhos de disco de SO foram definidos para serem os mesmos da imagem de base publicada, que tinha 127 GB por padrão e não pôde ser alterado.
  • Novo nesta versão, no assistente Importar VM do Marketplace, você verá uma alternância que fornece a capacidade de omitir a integração da VM resultante a um domínio do Active Directory. Antes, esse fluxo de trabalho ingressou na VM no domínio por padrão, e você não podia alterar esse comportamento. Essa nova alternância está disponível para os pods existentes antes da versão de manifesto desta versão.
  • Com o redesign da página capacidade nesta versão, a exibição Tipo foi removida. Com a remoção do modo de exibição Tipo da página Capacidade, há duas alterações relevantes sobre os itens que antes eram acessados nesse modo de exibição: a ação de exibir o uso atual do pod dos limites do Microsoft Azure da respectiva assinatura foi movida para a página de detalhes do pod, e a ação Remover Assinatura que estava presente nesse modo de exibição foi totalmente removida.
Itens adicionais relevantes para os clientes atuais
  • Aprimoramentos nos relatórios disponíveis na página Relatórios do Console Administrativo. Os dados nesses relatórios são fornecidos pelo Serviço de Monitoramento da Nuvem.
  • Aprimoramentos na página Capacidade do Console Administrativo do Horizon Cloud. Em vez de precisar analisar a página de detalhes de um pod para modificar os detalhes configuráveis do pod ou para excluir um pod do seu ambiente de tenant, você pode agora iniciar o pod de edição e remover fluxos de trabalho de pod da própria página Capacidade. Como resultado dessa reformulação, os fluxos de trabalho para modificar as informações de localização que foram feitas anteriormente usando a exibição de Localização da página Capacidade são agora opções dentro dos fluxos de trabalho de Editar Pod. Por exemplo, para especificar um novo nome de localização, use a ação Editar em um pod, e você pode especificar um novo nome de localização como uma opção desse fluxo de trabalho Editar Pod. Observe que não está mais disponível o fluxo de trabalho da visualização de Local anterior para remover as informações de assinatura salvas do Microsoft Azure quando todos os pods associados da assinatura foram excluídos.
  • O nome do produto anteriormente conhecido como VMware Identity Manager agora se chama VMware Workspace ONE™ Access.
  • O Horizon Agents Installer não instala mais um DaaS Agent inativo. Na versão anterior, o HAI instalou o MSI do DaaS Agent no sistema operacional convidado, mas ele estava inativo e não era usado. Nesta versão, o MSI não é instalado.

Setembro de 2019 - v2.1

Use as seguintes informações quando você tiver pods conectados à nuvem com data anterior a setembro de 2019 e para saber os efeitos sobre a sua experiência em relação aos recursos descritos na seção Novidades das Notas da Versão de setembro de 2019.

Especificamente sobre os pods do Horizon conectados à nuvem existentes
A partir desta versão:
  • A atualização automática agora é compatível com as versões 1.3 e 1.4 do Cloud Connector. É recomendável que os clientes com versões anteriores do Cloud Connector atualizem para a versão mais recente a fim de aproveitar esse recurso.
  • Serviços de Monitoramento de Nuvem (Cloud Monitoring Services, CMS) com detalhes de uso da sessão fornecidos como parte do Horizon Cloud Service.
Especificamente sobre os pods existentes no Microsoft Azure
Para os novos recursos a seguir descritos na seção Novidades do documento Notas da Versão de setembro de 2019 que serão usados com um pod existente, esse pod deve primeiro ser atualizado para o manifesto 1600.0 ou mais recente para aproveitar as vantagens dos recursos, salvo indicação em contrário.
  • A arquitetura do pod foi alterada nesta versão. Todos os pods na versão do manifesto da versão de setembro de 2019 têm um balanceador de carga do Microsoft Azure do pod e uma instância do servidor da base de dados do Microsoft Azure para PostgreSQL (camada com memória otimizada para Gen 5). Isso significa que, antes de atualizar os pods existentes para a versão do manifesto desta versão, você deve garantir que a sua configuração de rede existente atenda aos protocolos, portas e DNS necessários para acomodar o balanceador de carga do Microsoft Azure do pod e a instância do servidor de base de dados do Microsoft Azure para PostgreSQL. Se você tiver firewalls ou grupos de segurança de rede que bloqueiem portas e protocolos específicos, compare sua configuração de rede atual com as informações nos tópicos a seguir e atualize sua configuração de rede adequadamente.
  • Esta versão oferece alertas avançados de erros de atualização do pod que exigem ações do cliente para solucioná-los. Alguns itens que estão completamente dentro do seu controle podem evitar uma atualização de pod bem-sucedida, como a falta de núcleos suficientes na assinatura associada do pod para criar a VM do jumpbox que coordena a atualização do pod. A partir desta versão, esses itens são identificados no console para que você possa resolvê-los e limpá-los.
  • A partir desta versão, você pode revisar as seguintes configurações relacionadas ao gateway em um pod já implantado: adicionar configurações de autenticação de dois fatores a um gateway que não tem essas configurações, editar as configurações de autenticação de dois fatores do gateway, alterar o configuração de tempo limite de intermediação da sessão. Em versões anteriores, era preciso configurar a autenticação de dois fatores RADIUS quando o pod era implantado pela primeira vez e não podia alterar essas configurações depois. Outra novidade nesta versão é que você pode excluir gateways de um pod já implantado e implantar um novo pod para ter um gateway externo sem um endereço IP público no balanceador de carga do Azure e, no lugar dele, um endereço IP privado nesse balanceador de carga.
  • Suporte para definir tags de recursos do Microsoft Azure ao criar uma nova atribuição de área de trabalho VDI dedicada ou flutuante ou um novo farm para Horizon Cloud on Microsoft Azure.
  • A alta disponibilidade agora está disponível. Para oferecer suporte à alta disponibilidade para pods no Microsoft Azure, a arquitetura do pod foi atualizada para usar o serviço de base de dados do Microsoft Azure para PostgreSQL (camada com memória otimizada para Gen 5), um balanceador de carga do Microsoft Azure e um conjunto de disponibilidade. Para um pod que foi implantado recentemente nesta versão, você tem a opção de ativar a alta disponibilidade para esse pod no momento da implantação ou ativar a alta disponibilidade mais tarde. No caso dos pods que existiam antes desta versão, antes de ativá-los para alta disponibilidade, você deve primeiro atualizá-los para o manifesto 1600.0 ou mais recente e também atualizar os agentes nas imagens, nos farms e nas atribuições de área de trabalho VDI dos pods para o nível desta versão. Quando as atualizações do pod e do agente forem concluídas, você poderá ativar a alta disponibilidade no pod editando-o na respectiva página de detalhes no Console administrativo. Esse novo recurso traz requisitos adicionais para ativar o endpoint do serviço Microsoft.SQL na sub-rede de gerenciamento do pod quando o pod usa as sub-redes que você mesmo cria e para permitir o acesso de saída na porta 5432.

    Na versão de setembro de 2019, o recurso HA (alta disponibilidade) para pods no Microsoft Azure apenas é compatível com pods implantados nas regiões comerciais (globais padrão) do Microsoft Azure. Atualmente, o recurso de HA do pod não é compatível com pods implantados no Microsoft Azure China, no Microsoft Azure Alemanha e no Microsoft Azure Governamental (US Gov – Virgínia, US Gov – Arizona e US Gov – Texas). A equipe da VMware está trabalhando na inclusão do suporte para o recurso de HA aos pods nos ambientes de nuvem mencionados acima. Se você tem um pod no Microsoft Azure China, no Microsoft Azure Alemanha ou no Microsoft Azure Governamental e deseja atualizá-lo para a versão de manifesto desta versão sem o recurso de HA, entre em contato com seu representante da VMware para obter ajuda.

    Antes de atualizar um pod existente em uma das regiões globais padrão do Microsoft Azure para o manifesto 1600 ou mais recente, como a nova arquitetura do pod usa o serviço de base de dados do Microsoft Azure para PostgreSQL, você deve garantir que os seguintes itens estejam disponíveis:

  • Para aumentar a resiliência do processo de emparelhamento do Horizon Agent, esta versão traz uma evolução mais detalhada da mudança das funções do DaaS Agent para o Horizon Agent. O DaaS Agent agora foi incorporado ao Horizon Agent. Mesmo que o fluxo de trabalho automatizado Importar imagem e a instalação manual do Horizon Agents Installer instalem o MSI do DaaS Agent no sistema operacional convidado como faziam nas versões anteriores, a partir desta versão, o DaaS Agent está inativo e não é usado. No entanto, o serviço para o DaaS Agent ainda aparece na lista de Serviços do Windows. Não inicie esse serviço ou poderão ocorrer resultados inesperados.
  • Mover as funções do DaaS Agent para o Horizon View Agent alterou a Importação de Imagem automatizada do fluxo de trabalho do Azure Marketplace e as etapas para compilar manualmente uma VM de base. Anteriormente, a VM de base resultante do fluxo de trabalho automatizado era emparelhada com a nuvem no final do fluxo de trabalho, enquanto para uma VM criada manualmente, você tinha que fazer o bootstrap e emparelhar a VM manualmente. Para as VMs de base em um pod novo ou atualizado para esta versão de lançamento, agora a VM de base resultante é listada na página VMs Importadas com o status do agente Não Emparelhado. Para emparelhar a VM, você pode:
    • Executar a ação Redefinir o Emparelhamento do Agente na VM listada na página VMs Importadas, caso queira emparelhá-la com a nuvem antes de personalizá-la.
    • Executar a ação Nova Imagem na VM diretamente, caso a VM tenha todas as personalizações desejadas e você esteja pronto para publicá-la. Neste caso, o fluxo de trabalho de Nova Imagem executará primeiro o processo de emparelhamento para ativar o agente e, em seguida, você poderá preencher o restante dos campos e clicar em Publicar para publicar a imagem.
  • Com a mudança das funções do DaaS Agent para o Horizon View Agent, o fluxo de trabalho Redefinir o Emparelhamento do Agente agora está disponível para uso nas VMs importadas, nas VMs de servidor do farm e nas VMs de área de trabalho em atribuições de áreas de trabalho VDI dedicada. Nos detalhes de um farm ou da atribuição de área de trabalho VDI dedicada, se aparecer um estado de erro na coluna Status do Agente de uma VM de servidor do farm ou de uma VM de área de trabalho, você poderá usar a ação Redefinir o Emparelhamento do Agente no console para reparar o estado de emparelhamento da VM. (A ação não está disponível para atribuições de área de trabalho VDI flutuante.) Na página VMs Importadas, você pode usar a ação Redefinir o Emparelhamento do Agente para emparelhar inicialmente uma VM ainda não emparelhada ou reparar o estado de emparelhamento de uma VM já emparelhada.
  • O recurso de criptografia de disco agora usa o AzureDiskEncryption v2.2 mais recente, que inclui suporte à criptografia de disco para VMs com proxy no convidado configurado para conexão com a Internet. Para aproveitar esse novo suporte, atualize os agentes das suas VMs para a versão 19.3.0 ou posterior.
  • Orientação atualizada para usar os modelos de VM que têm no mínimo duas (2) CPUs para seus farms e atribuições de área de trabalho VDI. Testes de dimensionamento da VMware demonstraram que, para ambientes de produção, usar um mínimo de 2 CPUs evita problemas inesperados de conexão de usuário final. Mesmo que o sistema não impeça você de escolher um modelo de VM com uma única CPU, você deve usar tais modelos de VM para testes ou prova de conceitos somente.
  • Aprimoramentos de usabilidade para a página Tipos e Tamanhos de VM.
Itens adicionais relevantes para os clientes atuais
  • Melhor usabilidade e otimização da visualização de mapa interativo de Painel Unificado, incluindo reflexo mais preciso da funcionalidade de localização e zoom do pod.
  • Aprimoramentos nos relatórios disponíveis na página Relatórios do Console Administrativo. Os dados nesses relatórios são fornecidos pelo Serviço de Monitoramento da Nuvem.
  • Para pods do Horizon 7 conectados à nuvem, são exibidos detalhes adicionais na página de detalhes de um pod. O pod e o Cloud Connector devem estar na versão mais recente para ver esse recurso.
  • O nome do produto anteriormente conhecido como VMware User Environment Manager™ agora é chamado de VMware Dynamic Environment Manager™.