Entender o processo de transição do agente de pod único para o Universal Broker

Este tópico introduz o processo de transição de agente para o tenant do Horizon Cloud e os benefícios que você pode obter ao realizar a transição. Saiba mais sobre as diferenças entre um agente de pod único e um ambiente do Universal Broker e o que você pode esperar antes, durante e depois da transição do agente.

O que é o processo de transição de agente?

Quando você conclui a transição do agente, seu ambiente de tenant do Horizon Cloud muda do uso da intermediação de pod único para o uso do Universal Broker para recursos do agente de suas atribuições de usuário final. Como o novo agente em todo o tenant, o Universal Broker gerencia as solicitações de conexão dos usuários e as encaminha para o melhor recurso disponível da atribuição solicitada.

O processo de transição de agente faz as alterações a seguir nas atribuições de usuário final.

• As atribuições de área de trabalho VDI são convertidas em atribuições de várias nuvens intermediadas pelo Universal Broker. Uma atribuição de várias nuvens pode incluir áreas de trabalho VDI de vários pods.
• As atribuições de aplicativos e áreas de trabalho com base em sessão permanecem inalteradas. Uma atribuição de aplicativo ou área de trabalho com base em sessão pode incluir recursos somente de um único pod, mas a atribuição agora é intermediada pelo Universal Broker.

O recurso de transição estará disponível para você se seu ambiente atualmente usar a intermediação de pod único e atender aos pré-requisitos descritos em Horizon Cloud: requisitos do sistema para a transição para o Universal Broker.

Por que você deve fazer a transição para o Universal Broker?

Quando você faz a transição para usar o Universal Broker, a mais recente tecnologia de intermediação com base na nuvem da VMware, obtém os principais benefícios a seguir.

Atribuições de usuário final com áreas de trabalho VDI de vários pods

Com a intermediação de pod único, todas as áreas de trabalho em uma atribuição de VDI devem vir do mesmo pod. A intermediação da área de trabalho é feita por pod.

Com o Universal Broker, você pode criar uma atribuição de áreas de trabalho VDI de vários pods, também conhecida como uma atribuição de várias nuvens. Um usuário final pode acessar a atribuição e receber uma área de trabalho de qualquer pod incluído nessa atribuição. Para obter mais informações, consulte Introdução ao VMware Horizon Service Universal Broker e seus subtópicos.

Você também pode continuar a usar suas atribuições de área de trabalho e aplicativo baseadas em sessão como antes. A diferença é que as áreas de trabalho e os aplicativos baseados em sessão dessas atribuições serão intermediados pelo Universal Broker em vez de intermediação por pod.

FQDN de conexão única para todos os recursos remotos

Com a intermediação de pod único, os usuários finais devem se conectar ao nome de domínio totalmente qualificado (FQDN) de cada pod individualmente para acessar atribuições desse pod. A intermediação é feita por pod.

Com o Universal Broker, os usuários podem acessar todas as atribuições conectando-se a apenas um FQDN, que você define nas definições de configuração do .Universal Broker. Por meio do FQDN único, os usuários podem acessar atribuições de todos os pods participantes, incluindo os pods Horizon Cloud nos pods do Microsoft Azure e do Horizon em uma plataforma baseada em VMware SDDC, de qualquer site em seu ambiente. Não é necessária nenhuma rede interna entre os pods.

Conectividade e conscientização do pod global para desempenho ideal

O Universal Broker mantém a conectividade direta com cada pod participante de atribuições de várias nuvens e permanece ciente do status de disponibilidade de cada pod. Como resultado, o Universal Broker pode gerenciar as solicitações de conexão dos usuários finais e encaminhá-las para os recursos virtuais diretamente desses pods. Não há necessidade de GSLB (balanceamento de carga de servidor global) ou de qualquer comunicação de rede entre pods que possa resultar em problemas de desempenho e latência reduzidos.

Intermediação inteligente

O Universal Broker pode intermediar recursos de atribuições para usuários finais pela rota de rede mais curta, com base no reconhecimento de seus locais geográficos e topologia de pod.

Há algum motivo para não fazer a transição?

Esta versão do Universal Broker tem algumas limitações de recursos conhecidas. Se o seu caso de uso exigir um recurso ao qual o Universal Broker não oferece suporte, considere manter seu ambiente de tenant usando a intermediação de pod único até que o Universal Broker ofereça suporte ao recurso. Para obter uma lista das limitações atuais do Universal Broker, consulte Universal Broker - Considerações sobre recursos e limitações conhecidas.

O que acontece durante a transição de agente?

O fluxo de trabalho de transição consiste em vários estágios. Para obter instruções detalhadas passo a passo sobre como realizar a transição, consulte Agendar e concluir a transição de agente de pod único para o Universal Broker.

Essa é uma visão geral de alto nível dos processos que ocorrem durante e antes da transição.

1. Para iniciar o fluxo de trabalho, é necessário agendar primeiro uma data e hora para que a transição seja realizada. Junto com essa tarefa de agendamento, defina as opções de configuração que serão usadas para configurar o serviço do Universal Broker durante a transição.
2. Pelo menos 15 minutos antes da hora de início agendada, conclua todas as operações em andamento no console e salve todas as alterações que você deseja manter. Feche todos os assistentes de configuração e caixas de diálogo. Além disso, verifique se todos os pods no Microsoft Azure estão online, íntegros e prontos.
3. Quando a transição estiver prestes a começar, você será solicitado a efetuar logout do console e fazer login novamente.
4. Durante a primeira etapa da transição, você pode esperar o seguinte:
   • Você não pode acessar nenhum dos controles de edição do console, e o console exibe uma faixa informando que a transição está em andamento.
   • Todos os seus pods no Microsoft Azure são adicionados a um site chamado Site-Padrão.
   • Suas atribuições de área de trabalho VDI são convertidas em atribuições de várias nuvens intermediadas pelo Universal Broker. Nas configurações de atribuição padrão, a afinidade de conexão é definida como Site mais Próximo, e o escopo é definido como No Site.
   • Suas atribuições de área de trabalho e aplicativo baseadas em sessão permanecem inalteradas. Após a transição, os recursos nessas atribuições serão intermediados pelo Universal Broker.
   • Todas as atribuições permanecem disponíveis para os seus usuários finais e todas as sessões de usuário ativas permanecem abertas e totalmente operacionais durante esse período.
   Observação: Essa etapa da transição normalmente leva cerca de 10 minutos, mas poderá levar até uma hora se o seu ambiente de tenant contiver um alto número de atribuições.

   Quando essa etapa da transição estiver concluída, você será solicitado a sair do console e fazer login novamente.

5. Durante a segunda etapa da transição, o serviço Universal Broker conclui seu processo de configuração e fica totalmente ativado. Você pode acessar todas as operações de edição no console, exceto criar e editar atribuições.
   Observação: Essa etapa da transição normalmente leva até 30 minutos. No entanto, dependendo das condições do seu sistema e da rede e do número total de atribuições e mapeamentos dedicados de usuário a área de trabalho em seu ambiente, essa etapa pode levar várias horas para ser concluída.

   Quando essa fase da transição for concluída, a página Configurações > Agente mostrará o status Ativado com um ponto verde.

   Nesse ponto, a transição geral do agente está concluída.

O que você pode esperar após a transição de agente?

Para ver uma lista detalhada das alterações feitas no ambiente do tenant após a transição de agente, consulte Novidades no seu ambiente de tenant após a transição para Universal Broker.

Após concluir a transição, você poderá começar a aproveitar os benefícios oferecidos por um ambiente do Universal Broker. A lista a seguir fornece uma breve visão do que fazer em seguida e links para páginas detalhadas.

• Modifique seu site e as configurações de atribuição de VDI de várias nuvens para usar todos os recursos do Universal Broker. Por exemplo, você pode adicionar pods a uma atribuição existente ou ajustar as configurações do site para definir como o Universal Broker aloca recursos aos seus usuários. Para obter informações detalhadas, consulte Criação e gerenciamento de atribuições em seu ambiente do Universal Broker e Trabalhando com sites em um ambiente Universal Broker.
• Se houver uma integração existente entre seu tenant do Horizon Cloud e o Workspace ONE Access, você deverá atualizar a integração para acomodar o uso do Universal Broker. Para obter instruções completas, consulte Ambiente do Horizon Cloud com o Universal Broker: integrar o tenant ao Workspace ONE Access e aos serviços do Intelligent Hub.
  Observação: Conforme confirmado pela equipe do produto VMware Workspace ONE Access, quando o Universal Broker é usado com suas implantações do Horizon Cloud on Microsoft Azure, o recurso Coleções de Aplicativos Virtuais do produto VMware Workspace ONE Access não é compatível com essa configuração. A razão é porque o Universal Broker é uma tecnologia de intermediação mais moderna do que a antiga intermediação por pod, o que significa que a integração do Universal Broker ao Workspace ONE Access substitui o uso das Coleções de Aplicativos Virtuais por pod herdadas para implantações do Horizon Cloud on Microsoft Azure. Portanto, o Universal Broker não tem um conceito de Coleções de Aplicativos Virtuais para implantações do Horizon Cloud on Microsoft Azure, que faz uso de Coleções de Aplicativos Virtuais com as configurações do Universal Broker e do Horizon Cloud on Microsoft Azure como não compatíveis.

  Quando o Universal Broker estiver configurado para suas implantações do Horizon Cloud on Microsoft Azure e você planejar usar os serviços Workspace ONE Access e Intelligent Hub com essas implantações do Horizon Cloud on Microsoft Azure, no processo de integração como parte da ação Limpar do console, será necessário limpar quaisquer Coleções de Aplicativos Virtuais existentes que essas implantações possam ter. A conclusão das atividades de limpeza fará com que os mesmos aplicativos continuem a funcionar nos serviços Workspace ONE Access e Intelligent Hub usando os recursos modernos do Universal Broker integrado e dos serviços Workspace ONE Access e Intelligent Hub.

Horizon Cloud: requisitos do sistema para a transição para o Universal Broker

Este artigo descreve os requisitos aos quais seu ambiente de tenant do Horizon Cloud deve atender para que você possa agendar e concluir a transição de seu tenant de usar a intermediação de pod único para o Universal Broker. Ele também orienta você nas etapas de planejamento e preparação para oferecer suporte ao novo FQDN de conexão para o Universal Broker.

Para oferecer suporte ao processo de transição e às operações em andamento de atribuições de várias nuvens intermediadas pelo Universal Broker após a transição, verifique se o seu ambiente de tenant atende aos seguintes requisitos.

Cuidado: Se a frota de pods do seu tenant contiver uma mistura de pods do Horizon que já usam o Universal Broker e os pods do Horizon Cloud usando intermediação de pod único, você deverá ter consideração especial para corresponder as configurações de autenticação de dois fatores nas configurações do Universal Broker já definidas aos pods do Horizon Cloud.

• A menos que seus pods do Horizon Cloud atendam aos critérios de manifesto de pod mínimo e ativação da opção RSA SecurID no ambiente de tenant, esses pods oferecem suporte apenas à autenticação RADIUS. (Para obter mais informações, consulte Práticas recomendadas ao implementar a autenticação de dois fatores em um ambiente do Universal Broker.)
• Se os pods do Horizon Cloud não atenderem a esses critérios para ter o RSA SecurID configurado em seus gateways externos, se você quiser usar a autenticação de dois fatores com todos os pods da sua frota - ambos os pods do Horizon e Horizon Cloud pods, cada pod terá que ter um Unified Access Gateway externo com autenticação de dois fatores RADIUS configurada nele.

Requisitos para pods do Horizon Cloud

Verifique se os seus pods do Horizon Cloud no Microsoft Azure atendem aos seguintes requisitos.

• Seu tenant tem pelo menos um pod do Horizon Cloud. Um pod do Horizon Cloud é baseado na tecnologia de gerenciador de pods, que está em execução no Microsoft Azure.
• Todos os pods do Horizon Cloud do tenant estão em execução no manifesto do pod 2298.0 ou posterior. Os requisitos a seguir também se aplicam a certos casos de uso.
  • Se você tiver uma integração existente entre seu tenant do Horizon Cloud e o Workspace ONE Access, todos os pods deverão estar em execução no manifesto 2474.0 ou posterior. Depois de concluir a transição do agente, você deve atualizar a integração para acomodar o uso do Universal Broker, conforme descrito em Ambiente do Horizon Cloud com o Universal Broker: integrar o tenant ao Workspace ONE Access e aos serviços do Intelligent Hub.
  • Se você quiser usar o recurso de cancelamento de tarefa ou o recurso de proteção contra exclusão após a transição do agente, todos os pods do Horizon Cloud deverão estar em execução no manifesto 2474.0 ou posterior. Esses recursos não terão suporte se os pods estiverem em execução nos manifestos anteriores ao 2474.0.
  Importante: Verifique se todos os pods do Horizon Cloud estão on-line, íntegros e prontos. O serviço Universal Broker deve se comunicar com esses pods e realizar algumas etapas de configuração neles para concluir o processo de transição. Se qualquer um desses pods estiver offline ou indisponível, você não poderá agendar a transição. Se você agendar a transição, mas qualquer um dos pods mais tarde ficar offline ou ficar indisponível enquanto a transição estiver em andamento, a instalação do Universal Broker falhará.
• Nenhum upgrade de pod está agendado para ocorrer ao mesmo tempo que a transição.
• A localização do pod é configurada selecionando uma localização válida nas opções do menu no assistente de configuração do pod. Se a localização do pod foi configurada digitando-a manualmente em um campo de texto, a transição falhará.
  Observação: Esse problema que envolve um local digitado manualmente é mais provável de ocorrer para pods que foram implantados inicialmente antes de março de 2019 (versão 1.9 do serviço). A partir da versão de março de 2019, os locais devem ser selecionados por menu com base nos valores no banco de dados de nomes de cidades mundiais do sistema.

  Para reduzir a probabilidade de execução nesse cenário em que a transição falha devido à localização configurada do pod, navegue até a página Capacidade do console e examine o valor da coluna Localização para cada pod do Horizon Cloud. Se o valor da coluna Localização parecer um nome digitado manualmente, use a ação Editar no pod, vá para a etapa Detalhes do Pod e edite o campo Localização para definir seu valor para um dos valores de nome de cidade do sistema.

• Durante o fluxo de trabalho de transição, se o seu tenant ainda não tiver configurações do Universal Broker de nenhum dos pods do Horizon na sua frota de pods, o console solicitará as configurações do Universal Broker. Quando você planeja definir as configurações de autenticação de dois fatores nas configurações do Universal Broker, cada pod deve ter uma instância externa do Unified Access Gateway e essa instância deve ser configurada com o tipo de autenticação de dois fatores apropriado. (Para obter informações de base, consulte Práticas recomendadas ao implementar a autenticação de dois fatores em um ambiente do Universal Broker.)

  Os requisitos dependem de os pods do Horizon Cloud atenderem aos critérios para ter o tipo RSA SecurID configurado em seus gateways externos:

  • Quando seus pods do Horizon Cloud atendem aos critérios de manifesto de pod mínimo e ativação da opção RSA SecurID no ambiente de tenant, você deve configurar todas as instâncias externas do Unified Access Gateway em todos os pods para usar o mesmo serviço de autenticação. Isso inclui todos os pods do Horizon do tenant que estão no estado gerenciado. O resultado resultante é ter todos usando um tipo de autenticação correspondente: todos usando RADIUS ou todos usando RSA SecurID.
  • Quando os pods do Horizon Cloud não atenderem a esse critério para ter o RSA SecurID configurado em seus gateways externos, se você quiser usar a autenticação de dois fatores com todos os pods de sua frota (pods Horizon e pods do Horizon Cloud), deverá configurar todas as instâncias externas do Unified Access Gateway em todos os pods para usar o mesmo serviço de autenticação RADIUS. Isso inclui todos os pods do Horizon do tenant que estão no estado gerenciado.

Observação: Se um pod incluir apenas uma instância interna do Unified Access Gateway, o Universal Broker substituirá a política de rede definida na guia Intervalos de rede da página Agente e roteará todos os usuários para essa instância do Unified Access Gateway, independentemente do endereço IP deles.

DNS, portas e requisitos de protocolo para oferecer suporte ao Universal Broker

Verifique os requisitos a seguir.

• Cada pod configurado de forma que os nomes DNS necessários para sua instância Universal Broker regional sejam resolvíveis e alcançáveis. Consulte a tabela "Requisitos de DNS de operações e implantação de pods" em Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure.
• Cada pod configurado com as portas e protocolos necessários, conforme descrito na seção "Portas e protocolos exigidos pelo Universal Broker", em Requisitos de portas e protocolos para um pod do Horizon Cloud no manifesto da versão de setembro de 2019 ou posterior.

Requisitos de FQDN para oferecer suporte ao Universal Broker

Com intermediação de pod único, os usuários finais se conectam ao nome de domínio totalmente qualificado (FQDN) de cada pod individualmente para acessar atribuições desse pod.

Após a transição para o Universal Broker, os usuários podem acessar qualquer atribuição, de qualquer pod em qualquer site em seu ambiente, conectando-se a um FQDN do serviço de nuvem do Universal Broker. O Universal Broker encaminha cada solicitação de usuário para o FQDN individual do pod mais apropriado que pode atender à solicitação.

Você designa o FQDN do Universal Broker nas definições de configuração do Universal Broker conforme descrito em Agendar e concluir a transição de agente de pod único para o Universal Broker. Você pode criar o FQDN prefixando seu subdomínio válido para o domínio padrão fornecido pela VMware ou pode configurar um FQDN totalmente personalizado.

Observação: Se você optar por configurar um FQDN personalizado, tenha em mente que esse FQDN representa sua empresa ou organização. Garanta que você é o proprietário do nome de domínio especificado no FQDN personalizado, pode fornecer um certificado que valida esse domínio e tem a autorização adequada para usar o FQDN personalizado. O FQDN personalizado para o Universal Broker deve ser exclusivo e distinto dos FQDNs de todas as instâncias do Unified Access Gateway em seus pods.

Planejamento e preparação para a transição do agente

Como a transição do agente envolve alterações importantes no seu fluxo de trabalho de rede e atribuição, execute as ações necessárias para preparar seu ambiente e usuários para o novo fluxo de trabalho. Consulte o seguinte guia de planejamento para obter as etapas de preparação e gerenciamento de alterações apropriadas com base no seu caso de uso de transição.

Caso de uso de transição	Etapas de planejamento e preparação
Seu ambiente consiste em um único pod e você deseja usar o FQDN existente desse pod como o FQDN do Universal Broker	Durante o estágio de configuração do do processo de agendamento de transição, designe o FQDN existente do pod como o FQDN personalizado para o serviço do Universal Broker. Agende a transição para uma data e hora que causem interrupções mínimas nas cargas de trabalho de atribuição dos usuários finais. Notifique e prepare seus usuários para a próxima transição. Lembre-os de salvar o trabalho e fazer logoff das sessões de conexão ativas à medida que o tempo de transição se aproximar. Pouco antes da transição, atribua um novo endereço IP e FQDN ao pod. Após a conclusão da transição, informe aos usuários finais que eles podem retomar suas sessões de conexão usando o antigo FQDN do pod, que agora é o FQDN do Universal Broker.
Seu ambiente consiste em vários pods e você deseja configurar um novo FQDN como o FQDN do Universal Broker	Atualize seus runbook para incluir os procedimentos necessários a serem seguidos antes, durante e após o processo de transição. Durante o estágio de configuração do do processo de agendamento de transição, configure o novo FQDN para o serviço do Universal Broker. Agende a transição para uma data e hora que causem interrupções mínimas nas cargas de trabalho de atribuição dos usuários finais. Aguarde por um tempo adequado para permitir o treinamento do usuário e a reconfiguração do software cliente, de acordo com a escala das implantações de pod. Notifique e prepare seus usuários para a próxima transição. Lembre-os de salvar o trabalho e fazer logoff das sessões de conexão ativas à medida que o tempo de transição se aproximar. Durante ou logo após a transição, reconfigure o Horizon Client nos sistemas do cliente dos usuários para se conectar ao novo FQDN do Universal Broker, em vez dos FQDNs dos pods individuais. Informe os usuários finais de que eles agora devem usar o novo FQDN de conexão do agente e, como resultado, poderão obter acesso universal a todos os pods no seu ambiente.

Agendar e concluir a transição de agente de pod único para o Universal Broker

Este tópico orienta você nas etapas de agendamento, preparação e conclusão da transição para o Universal Broker. Consulte o procedimento a seguir para saber como configurar o serviço do Universal Broker, definir a data de início e a hora da transição e percorrer sem problemas os estágios do processo para realizar uma transição bem-sucedida.

Uma faixa de notificação com Agendar aparece na parte superior da Horizon Universal Console quando a transição de agente está pronta para ser agendada.

Observação: Se a faixa mostrar uma condição de erro que impeça que a transição seja agendada, isso indicará que você provavelmente não atende a um ou mais dos pré-requisitos da transição. Clique em Exibir Erros na faixa e, em seguida, clique no ícone de erro ao lado do link Transição obrigatória na página Agente para exibir os detalhes sobre a condição de erro. Você deve seguir as etapas necessárias para limpar a condição de erro antes de agendar a transição.

Pré-requisitos

Verifique se o seu ambiente de tenant atende a todos os pré-requisitos descritos em Horizon Cloud: requisitos do sistema para a transição para o Universal Broker.

Procedimento

1. Clique em Agendar na faixa de notificação para a transição de agente.
   
   
   
   Essa ação redireciona você para a página do Agente. A página indica que o Agente de Pod Único está ativado no momento para o seu tenant e fornece um link para agendar a transição de agente.

   
   
   
2. Na página Agente, clique no link Agendar.
   O assistente de configuração para o Universal Broker é exibido. Você deve concluir as etapas deste assistente para configurar o Universal Broker para os pods no Microsoft Azure e agendar a transição para o Universal Broker.

   
   
   
3. Na página FQDN do assistente, defina as configurações para o FQDN de conexão de intermediação. Essas configurações definem o endereço de conexão dedicado que seus usuários finais usam para acessar os recursos alocados pelo Universal Broker.
   Observação: Quando você modifica uma configuração de subdomínio ou de FQDN, pode levar algum tempo para a alteração entrar em vigor em todos os servidores DNS.
   1. Para Tipo, selecione um nome de domínio completo (FQDN) Fornecido pela VMware ou Personalizado.
   2. Especifique configurações adicionais para o tipo de FQDN selecionado.
      • Se você tiver selecionado o tipo Fornecido pela VMware, especifique as configurações da seguinte maneira.

        Configuração	Descrição
        Sub Domain	Insira o nome DNS exclusivo de um subdomínio válido na sua configuração de rede que representa sua empresa ou organização. Esse subdomínio é prefixado no domínio fornecido pela VMware para formar o FQDN de intermediação. Observação: Algumas cadeias de caracteres não são permitidas ou estão reservadas pelo sistema. Essa categoria de cadeia de caracteres inclui palavras genéricas como book, termos de propriedade da empresa conhecidos, como gmail e protocolo. Termos de codificação e código aberto, como php e sql. O sistema também impede uma categoria de padrões dessas cadeias de caracteres, como mail0, mail1, mail2, etc. No entanto, quando você digita um nome não permitido nesse campo, o sistema não valida a entrada nesse momento. Somente quando você chega à etapa final de resumo do assistente, o sistema valida o nome que você digitou aqui e exibirá um erro se a sua entrada corresponder a um dos nomes não permitidos. Se isso acontecer, digite um nome diferente e mais exclusivo aqui.
        Brokering FQDN	Esse campo somente leitura exibe o FQDN configurado. O FQDN usa o formato https://<seu subdomínio>vmwarehorizon.com. Forneça esse FQDN aos seus usuários finais para permitir que eles se conectem ao serviço Universal Broker usando o Horizon Client. O Universal Broker gerencia a validação de DNS e SSL desse FQDN.

      • Se você tiver selecionado o tipo Personalizado, especifique as configurações da seguinte maneira.

        Configuração	Descrição
        Brokering FQDN	Insira o FQDN personalizado que os usuários finais usarão para acessar o serviço do Universal Broker. Seu FQDN personalizado funciona como um alias para o FQDN fornecido pela VMware gerado automaticamente que realiza a conexão com o serviço. Você deve ser o proprietário do nome de domínio especificado no seu FQDN personalizado e fornecer um certificado que possa validar esse domínio. Observação: Seu FQDN personalizado, também conhecido como URL de conexão, representa sua empresa ou organização. Certifique-se de ter autorização apropriada para usar esse FQDN personalizado. Observação: O FQDN personalizado deve ser exclusivo e distinto dos FQDNs de todas as instâncias do Unified Access Gateway nos pods. Importante: Você deve criar um registro CNAME no servidor DNS que mapeia seu FQDN personalizado para o FQDN fornecido pela VMware representando o endereço de conexão interna do serviço do Universal Broker. Por exemplo, o registro pode mapear vdi.examplecompany.com para <cadeia de caracteres gerada automaticamente>.vmwarehorizon.com.
        Certificate	Clique em Procurar e carregue o certificado (no formato PFX protegido por senha) que valida seu FQDN de intermediação. O certificado deve atender a todos os seguintes critérios: O certificado deve ser válido por pelo menos 90 dias O certificado deve ser assinado por uma autoridade de certificação confiável O Nome Comum (SN) do certificado ou qualquer um dos seus Nomes Alternativos da Entidade (SANs) devem corresponder ao FQDN O conteúdo do certificado deve estar em conformidade com o formato padrão X.509 O arquivo PFX deve conter a cadeia de certificados inteira e a chave privada: certificado de domínio, certificados intermediários, certificado da CA raiz, chave privada. O serviço Universal Broker usa esse certificado para estabelecer sessões de conexão confiáveis com clientes.
        Password	Insira a senha para o arquivo de certificado PFX.
        VMware Provided FQDN	Esse campo somente leitura exibe o FQDN fornecido pela VMware que é criado automaticamente para o serviço de intermediação. O FQDN obtém o formato https://<cadeia de caracteres gerada automaticamente>.vmwarehorizon.com. O FQDN fornecido pela VMware não é visível para os usuários finais e representa o endereço de conexão interna do serviço Universal Broker. Seu FQDN personalizado funciona como um alias para o FQDN fornecido pela VMware. Importante: Você deve configurar uma associação de alias criando um registro CNAME no servidor DNS que mapeia seu FQDN personalizado para o FQDN fornecido pela VMware. Por exemplo, o registro pode mapear vdi.examplecompany.com para <cadeia de caracteres gerada automaticamente>.vmwarehorizon.com.

        
        

        

        
        
   3. Quando você terminar de definir as configurações de FQDN, clique em Avançar para ir para a próxima página do assistente.
4. (Opcional) Na página Autenticação do assistente, configure a autenticação de dois fatores.
   Por padrão, o Universal Broker autentica os usuários exclusivamente por meio do nome de usuário e senha do Active Directory deles. Você pode implementar a autenticação de dois fatores especificando um método de autenticação adicional. Para obter mais informações, consulte Práticas recomendadas ao implementar a autenticação de dois fatores em um ambiente Universal Broker.
   Importante: Para usar a autenticação de dois fatores para o Universal Broker, você deve primeiro configurar o serviço de autenticação apropriado em cada instância externa do Unified Access Gateway para cada pod participante. As configurações de instâncias externas do Unified Access Gateway devem ser idênticas dentro dos pods participantes e entre eles.

   Por exemplo, se você quiser usar a autenticação RADIUS, deverá configurar o serviço RADIUS em cada instância externa do Unified Access Gateway em todos os pods e pods do Horizon participantes no Microsoft Azure.

   Não exclua nenhuma instância do Unified Access Gateway dentro dos pods participantes. Como o Universal Broker depende do Unified Access Gateway para o tráfego de protocolos entre o Horizon Client e os recursos virtuais, os usuários não poderão acessar recursos provisionados de um pod participante se você excluir a instância do Unified Access Gateway desse pod.

   Configuração	Descrição
   Two-Factor Authentication	Para usar a autenticação de dois fatores, ative essa alternância. Quando você ativa a alternância, aparecem opções adicionais para configurar a autenticação de dois fatores.
   Maintain User Name	Ative essa alternância para manter o nome de usuário do Active Directory do usuário durante a autenticação no Universal Broker. Quando ativado: O usuário deve ter as mesmas credenciais de nome de usuário para o método de autenticação adicional que para a autenticação do Active Directory no Universal Broker. O usuário não pode alterar o nome de usuário na tela de logon do cliente. Se essa alternância estiver desativada, o usuário poderá digitar outro nome de usuário na tela de logon.
   Type	Especifique o método de autenticação que o Universal Broker deve usar com os usuários finais, além do nome de usuário e da senha do Active Directory. A interface do usuário exibe duas opções: RADIUS e RSA SecurID. Essa configuração se aplica a todo o tenant. O comportamento no cliente do usuário final dependerá da composição da frota de pods do tenant e do tipo de autenticação de dois fatores configurado nos gateways dos pods, da seguinte maneira: Somente pods do Horizon O tipo selecionado aqui é aquele usado no cliente. Somente pods do Horizon Cloud Selecione o tipo que corresponde ao que está configurado nos gateways externos dos pods. Combinação de pods do Horizon e implantações do Horizon Cloud on Microsoft Azure Em uma frota combinada, quando RADIUS é selecionado aqui, as solicitações de autenticação RADIUS dos usuários são tentadas por meio das instâncias de Unified Access Gateway de ambos os tipos de pod. Em uma frota combinada, quando RSA SecurID é selecionado aqui, o comportamento do cliente depende do fato de suas implantações do Horizon Cloud on Microsoft Azure estarem configuradas com RSA SecurID em seus gateways externos. Se suas implantações do Horizon Cloud on Microsoft Azure não tiverem o tipo RSA SecurID configurado em seus gateways e RSA SecurID for selecionado aqui, as solicitações de autenticação RSA dos usuários serão tentadas apenas por meio das instâncias do Unified Access Gateway dos pods do Horizon. As tentativas de solicitações de autenticação com nome de usuário e senha do Active Directory serão feitas por meio das instâncias do Unified Access Gateway de pods do Horizon ou pods do Horizon Cloud. Se suas implantações do Horizon Cloud on Microsoft Azure tiverem o tipo RSA SecurID configurado, as solicitações de autenticação RSA dos usuários serão tentadas por meio das instâncias do Unified Access Gateway de ambos os tipos de pod.
   Show Hint Text	Habilite essa opção para configurar uma cadeia de caracteres de texto exibida na tela de login do cliente para ajudar a solicitar ao usuário as credenciais para o método de autenticação adicional.
   Custom Hint Text	Insira a cadeia de texto que você deseja exibir na tela de logon do cliente. A dica especificada aparece para o usuário final como Enter your DisplayHint user name and password, em que DisplayHint é a cadeia de caracteres de texto que você especifica nessa caixa de texto. Observação: O Universal Broker não permite os seguintes caracteres no texto de dica personalizado: & < > ' “ Se você incluir qualquer um desses caracteres não permitidos no texto de dica, as conexões de usuário com o FQDN do Universal Broker falharão. Essa dica pode ajudar a orientar os usuários a inserir as credenciais corretas. Por exemplo, especificar a frase Nome de usuário e senha de domínio da empresa abaixo para resultaria em um aviso para o usuário final que diz: Enter your Company user name and domain password below for user name and password.
   Skip Two-Factor Authentication	Ative essa alternância para ignorar a autenticação de dois fatores para usuários de rede interna que se conectam ao serviço do Universal Broker. Verifique se você especificou os intervalos de IP públicos pertencentes à rede interna, conforme descrito em Faixas de rede internas definidas para Universal Broker. Quando essa alternância está ativada, os usuários internos devem digitar apenas suas credenciais do Active Directory para se autenticar no serviço Universal Broker. Os usuários externos devem inserir as credenciais do Active Directory e suas credenciais para o serviço de autenticação adicional. Quando essa alternância está desativada, os usuários internos e externos devem inserir suas credenciais do Active Directory e suas credenciais para o serviço de autenticação adicional.
   Public IP Ranges	Esse campo é visível quando a opção Ignorar Autenticação de Dois Fatores está ativada. Quando um ou mais intervalos de IP públicos já estão especificados na guia Intervalos de Rede da página Agente, esse campo é somente leitura e lista esses intervalos de IP. Quando a guia Intervalos de Rede da página Agente não tem intervalos de IP públicos já especificados, você pode usar esse campo para especificar os intervalos de IP públicos que representam sua rede interna, com o objetivo de ignorar os prompts de autenticação de dois fatores para o tráfego proveniente desses intervalos . O Universal Broker considera qualquer usuário que se conecta de um endereço IP em um desses intervalos para ser um usuário interno. Para obter mais detalhes sobre a finalidade de especificar esses intervalos, consulte Definir intervalos de rede interna para o Universal Broker.

   Quando você terminar de configurar a autenticação de dois fatores, clique em Avançar para prosseguir para a próxima página do assistente.
5. Na página Configurações do assistente de configuração, configure Durações para Horizon Client.
   Essas configurações de tempo limite se aplicam à sessão de conexão entre o Horizon Client e a área de trabalho atribuída alocada pelo Universal Broker. Essas configurações não se aplicam à sessão de logon do usuário para o sistema operacional convidado da área de trabalho atribuída. Quando o Universal Broker detecta as condições de tempo limite especificadas por essas configurações, ele fecha a sessão de conexão do Horizon Client do usuário.

   Configuração	Descrição
   Client Heartbeat Interval	Controla o intervalo, em minutos, entre as heartbeats do Horizon Client e o estado da conexão do usuário para o Universal Broker. Essas heartbeats relatam para o Universal Broker quanto tempo ocioso passou durante a sessão de conexão do Horizon Client. O tempo ocioso é medido quando não ocorre nenhuma interação com o dispositivo de endpoint que executa o Horizon Client. Esse tempo ocioso não é afetado pela inatividade na sessão de logon para o sistema operacional convidado que se baseia na área de trabalho atribuída do usuário. Em implantações de área de trabalho grandes, aumentar o Intervalo de Pulsação do Cliente pode reduzir o tráfego de rede e melhorar o desempenho.
   Client Idle User	Tempo ocioso máximo, em minutos, permitido durante uma sessão de conexão entre o Horizon Client e o Universal Broker. Quando o tempo máximo é atingido, o período de autenticação do usuário expira, e o Universal Broker fecha todas as sessões ativas do Horizon Client. Para reabrir uma sessão de conexão, o usuário deve inserir novamente as credenciais de autenticação na tela de logon do Universal Broker. Observação: Para evitar a desconexão inesperada de usuários de suas áreas de trabalho atribuídas, defina o tempo limite Usuário Ocioso do Cliente como um valor que tenha pelo menos o dobro do Intervalo de Pulsação do Cliente.
   Client Broker Session	O tempo máximo, em minutos, permitido para uma sessão de conexão do Horizon Client antes que a autenticação do usuário expire. A hora começa quando o usuário é autenticado no Universal Broker. Quando o tempo limite da sessão é atingido, o usuário pode continuar a trabalhar na área de trabalho atribuída. No entanto, se ele executar uma ação, como alterar alguma configuração, que exige comunicação com o Universal Broker, o Horizon Client solicitará que ele insira novamente as credenciais do Universal Broker. Observação: O tempo limite da Sessão do Agente do Cliente deve ser maior ou igual à soma do valor do Intervalo de Pulsação do Cliente e do tempo limite do Usuário Ocioso do Cliente.
   Client Credential Cache	Controla se as credenciais de logon do usuário devem ser armazenadas no cache do sistema do cliente. Insira 1 para armazenar as credenciais do usuário no cache. Insira 0 se você não quiser armazenar as credenciais do usuário no cache.

   Quando você terminar de definir as configurações de Durações, clique em Avançar para ir para a próxima página do assistente.
6. Na página Agendar do assistente, use os controles para especificar uma Data e Hora de Início para que a transição de agente seja realizada.
   
   

   

   
   
   Você pode agendar uma hora de início que seja pelo menos uma hora antes da sua hora local atual e até três meses antes da data atual. A hora de início deve ocorrer no início da hora.
   Ao definir a hora de início, permita um tempo suficiente para que a transição prossiga sem interrupção.
   Quando terminar, clique em Avançar para prosseguir para a próxima etapa do assistente de configuração do Universal Broker.
   Observação: Se o console exibir uma mensagem informando que a hora de início especificada não está disponível, retorne para as configurações de Data e Hora de Início para especificar uma hora diferente para sua transição.
7. Examine as configurações na página Resumo e, em seguida, clique em Concluir para salvar e aplicar a configuração do Universal Broker e as configurações de agenda.
   É exibida uma mensagem confirmando que você agendou a transição com êxito.
   
   

   

   
   
   Após o agendamento da transição:

   • A página Agente exibe detalhes sobre a próxima transição. Se ainda faltar mais de uma hora até a hora de início, você poderá reagendar a transição clicando no link Agendar .
   • Se quiser cancelar uma transição agendada ou reagendar uma transição que começa em menos de uma hora, você deverá entrar em contato com o Suporte da VMware. Observe que o Suporte da VMware não pode cancelar ou reagendar uma transição que começa em menos de 15 minutos.
   • O console continua a exibir uma faixa de notificação sobre a próxima transição até que a hora de início seja atingida. Ao clicar em Exibir Detalhes na faixa, você é redirecionado para a página Agente.
   • As mensagens de notificação e lembrete sobre a próxima transição são enviadas para a conta de e-mail principal registrada para seu tenant.
8. Conclua as tarefas de preparação a seguir pelo menos 15 minutos antes do início da transição. Durante a transição, você não pode acessar nenhuma das operações de edição do console.
   • Conclua todas as operações em andamento no console e salve todas as alterações que você deseja manter.
   • Feche todos os assistentes de configuração e caixas de diálogo.

   Importante: Verifique se todos os Horizon Cloud pods no Microsoft Azure estão online e em estado íntegro e pronto para a duração da transição. O serviço Universal Broker deve se comunicar com os pods e realizar algumas etapas de configuração neles para concluir o estágio de ativação do agente da transição. Se qualquer um dos pods estiver offline ou indisponível, haverá falha na transição.

   Importante: Se você tiver um ambiente híbrido que consiste em pods do Horizon Cloud em pods do Microsoft Azure e pods do Horizon em uma plataforma baseada em VMware SDDC, o serviço Universal Broker não estará disponível para os pods do Horizon durante a transição. Além disso, não é possível alterar o estado de um pod do Horizon de monitorado para gerenciado durante esse período.
9. Logo antes do início da transição, siga as instruções no prompt na tela para fazer logoff do console e fazer login novamente.
   
   

   

   
   
10. Permita que a primeira etapa da transição prossiga sem interrupção.
    Durante essa fase da transição:

    • Você não pode acessar nenhum dos controles de edição do console, e o console exibe uma faixa informando que a transição está em andamento.
      
      
      
      
    • Todos os seus pods no Microsoft Azure são adicionados a um site chamado Site-Padrão.
    • Suas atribuições de área de trabalho VDI são convertidas em atribuições de várias nuvens intermediadas pelo Universal Broker. Nas configurações de atribuição padrão, a afinidade de conexão é definida como Site mais Próximo, e o escopo é definido como No Site.
    • Suas atribuições de área de trabalho e aplicativo baseadas em sessão permanecem inalteradas. Após a transição, os recursos nessas atribuições são intermediados pelo Universal Broker.
    • Todas as atribuições permanecem disponíveis para os seus usuários finais e todas as sessões de usuário ativas permanecem abertas e totalmente operacionais durante esse período.
    Observação: Essa etapa da transição normalmente leva cerca de 10 minutos, mas poderá levar mais tempo se o seu ambiente de tenant contiver um grande número de atribuições. Você pode monitorar o progresso clicando em Exibir Status na faixa de notificação. Se esse estágio não for concluído dentro de uma hora, a transição atingirá o tempo limite e será marcada como uma falha.

    A mensagem a seguir é exibida quando essa fase da transição é concluída.
    

    

    
    

    Observação: Se ocorrer uma falha durante essa fase da transição, o Suporte da VMware receberá uma notificação automática e investigará e remediará a causa da falha. Você pode exibir mais informações na página Agente e nas mensagens de notificação enviadas para a conta de e-mail principal registrada para seu tenant. Depois que o Suporte da VMware remediar a causa da falha, você poderá usar o link na página Agente para reagendar a transição.
11. Depois de fazer login novamente no console, permita que o serviço do Universal Broker conclua seu processo de configuração e seja totalmente ativado.
    Normalmente, leva até 30 minutos para que as definições de configuração tenham efeito total no serviço Universal Broker, já que os registros de DNS são propagados nos servidores DNS em todas as regiões globais. No entanto, dependendo das condições do seu sistema e da rede e do número total de atribuições e mapeamentos dedicados de usuário a área de trabalho em seu ambiente, esse processo pode levar várias horas para ser concluído. Se o processo não for concluído dentro de quatro horas, a transição atingirá o tempo limite e será marcada como uma falha.

    Durante essa fase da transição, você pode acessar todas as operações de edição no console, exceto criar e editar atribuições. Além disso, o serviço do Universal Broker fica indisponível durante esse tempo para a intermediação de atribuições.

    Quando a configuração é concluída com êxito, uma mensagem de notificação é exibida no console sob o ícone de sino, e a página Configurações > Agente mostra o status Ativado com um ponto verde.

    Suas atribuições agora são intermediadas pelo Universal Broker e a transição é concluída.

    
    
    

    Importante: Se houver falha na configuração do Universal Broker, a página Configurações > Agente mostrará o status Erro com um ícone de alerta vermelho. Para corrigir a falha de configuração e configurar o serviço Universal Broker, entre em contato com o Suporte da VMware, conforme descrito no Artigo 2006985 da Base de Dados de Conhecimento (Knowledge Base, KB) da VMware.

O que Fazer Depois

• Se houver uma integração existente entre seu tenant do Horizon Cloud e o Workspace ONE Access, você deverá atualizar a integração para acomodar o uso do Universal Broker. Para obter instruções completas, consulte Ambiente do Horizon Cloud com o Universal Broker: integrar o tenant ao Workspace ONE Access e aos serviços do Intelligent Hub.
• Modifique seu site e as configurações de atribuição de VDI de várias nuvens para usar todos os recursos do Universal Broker. Por exemplo, você pode adicionar mais pods a uma atribuição existente ou ajustar as configurações do site para ajustar as atribuições dos agentes do Universal Broker. Para obter informações detalhadas, consulte Criar e gerenciar atribuições de várias nuvens em seu ambiente de tenant do Horizon Cloud e Trabalhar com sites em um ambiente do Universal Broker.

Novidades no seu ambiente de tenant após a transição para Universal Broker

Este artigo descreve as alterações que você pode esperar em seu ambiente de tenant do Horizon Cloud depois de concluir com êxito a transição do Agente de Pod único para o Universal Broker. As alterações incluem alguns comportamentos de recursos novos e algumas limitações de recursos.

Para obter mais informações sobre determinadas limitações de recursos em um ambiente do Universal Broker, consulte Universal Broker - Considerações sobre recursos e limitações conhecidas.

Alterações nas atribuições do usuário final

• Todos os seus pods no Microsoft Azure são adicionados a um site chamado Site-Padrão.
• As atribuições de área de trabalho VDI são convertidas em atribuições de várias nuvens intermediadas pelo Universal Broker. Nas configurações de atribuição padrão, a afinidade de conexão é definida como Site mais Próximo, e o escopo é definido como No Site.
  Observação: Um usuário específico pode receber no máximo uma área de trabalho atribuída de uma atribuição dedicada intermediada pelo Universal Broker, mesmo se a atribuição incluir áreas de trabalho de vários pods.
  Importante: Se um usuário tiver recebido anteriormente várias áreas de trabalho atribuídas de uma atribuição dedicada em um ambiente de Agente de Pod único, ele não poderá acessar essas áreas de trabalho após a transição para um ambiente do Universal Broker. Para acessar as áreas de trabalho atribuídas, o usuário pode se conectar diretamente ao FQDN do pod em vez de usar o FQDN do Universal Broker.
• As atribuições de área de trabalho e de aplicativo com base em sessão agora são intermediadas pelo Universal Broker.

Alterações nos pools de áreas de trabalho com nomes idênticos

Se qualquer pool da área de trabalho nos seus pods tiver o mesmo nome antes da transição do agente, eles serão editados para terem nomes distintos. Essa alteração garante que você possa adicionar pools de áreas de trabalho nomeados exclusivamente de pods diferentes a uma única atribuição intermediada pelo Universal Broker.

Por exemplo, suponha que você tenha o seguinte cenário antes da transição do agente:

• O Pod1 continha um pool chamado TestPoolName.
• O Pod2 continha um pool também chamado TestPoolName.

Após a transição, os nomes do pool de exemplo mudam da seguinte maneira:

• No Pod1, o nome do pool permanece como TestPoolName.
• No Pod2, o pool é renomeado para TestPoolName1.

Alterações no prefixo de nomes de VM

Em um ambiente de Agente de Pod único antes da transição, o prefixo de nomes de VM de um pool podia ter no máximo 11 caracteres personalizáveis. Para formar o nome do pool, um número sequencial (com um máximo de quatro dígitos) é anexado ao prefixo de 11 caracteres.

Após a transição para o Universal Broker, o prefixo de nomes de VM pode consistir em no máximo nove caracteres personalizáveis. Quaisquer prefixos de nomes de VM que anteriormente tinham mais de nove caracteres são automaticamente truncados após a transição.

Para formar o nome do pool em um ambiente do Universal Broker, os seguintes caracteres são anexados ao prefixo de nove caracteres: dois caracteres alfanuméricos aleatórios ou alfabéticos, seguidos por um número sequencial (com um máximo de quatro dígitos).

Se várias atribuições usarem o mesmo prefixo de nomes de VM, você poderá encontrar um erro ao tentar editar uma das atribuições. Para resolver o erro, altere o prefixo de nomes de VM da atribuição no assistente de Edição.

Observação: Se um pool da área de trabalho estiver configurado com a opção Máximo de Áreas de Trabalho definida como 0, o prefixo do nome da VM e o nome do pool aparecerão inalterados no Horizon Universal Console após a transição. Para atualizar o console para exibir o novo prefixo de nome da VM e o nome do pool, faça uma atualização na atribuição transferida usando o assistente Editar.

Considerações de recursos após a transição

As considerações a seguir se aplicam a determinados recursos após a transição para o Universal Broker.

• Não há suporte para atribuições de personalização (também conhecidas como atribuições de Redirecionamento de URL).
• O recurso de cancelamento de tarefa não terá suporte se os pods estiverem sendo executados antes do manifesto 2474.0. Para usar esse recurso, você deve fazer upgrade de seus pods para o manifesto 2474.0 ou posterior.
• Se as implantações do Horizon Cloud on Microsoft Azure tiverem uma integração de pré-transição existente com o Workspace ONE Access, você deverá atualizar a integração para um estado pós-transição para acomodar o uso do Universal Broker. Para obter instruções completas, consulte Ambiente do Horizon Cloud com o Universal Broker: integrar o tenant ao Workspace ONE Access e aos serviços do Intelligent Hub.

  Observe que, ao atualizar essa integração, você precisará usar o fluxo de trabalho de Horizon Universal Console limpeza para limpar quaisquer Coleções de Aplicativos Virtuais existentes que essas implantações possam ter. O fluxo de trabalho de limpeza fará com que os mesmos aplicativos continuem a funcionar nos serviços Workspace ONE Access e Intelligent Hub usando os recursos modernos do Universal Broker integrado, dos serviços Workspace ONE Access e Intelligent Hub, em vez do recurso de Coleções de Aplicativos Virtuais herdados por pod. Conforme confirmado pela equipe do produto VMware Workspace ONE Access, quando o Universal Broker é usado com suas implantações do Horizon Cloud on Microsoft Azure, o recurso Coleções de Aplicativos Virtuais do produto VMware Workspace ONE Access não é compatível com essa configuração. A razão é porque o Universal Broker é uma tecnologia de intermediação mais moderna do que a antiga intermediação por pod, o que significa que a integração do Universal Broker ao Workspace ONE Access substitui o uso das Coleções de Aplicativos Virtuais por pod herdadas. Portanto, o Universal Broker não tem um conceito de Coleções de Aplicativos Virtuais para implantações do Horizon Cloud on Microsoft Azure.

Importante: O recurso de proteção contra exclusão para interrupções de inventário não será compatível se os pods estiverem sendo executados antes do manifesto 2474.0. Para usar esse recurso, você deve fazer upgrade de seus pods para o manifesto 2474.0 ou posterior.

Por exemplo, se os seus pods estavam sendo executados antes do manifesto 2474.0 e tinham a proteção contra exclusão ativada antes da transição, o recurso deixará de funcionar após a transição. Se você fizer upgrade dos pods para o manifesto 2474.0 ou posterior, o recurso de proteção contra exclusão ficará funcional novamente.