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 Universal Broker ambiente do 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 de Horizon Cloud muda do uso da intermediação de pod único para o uso do Universal Broker aos recursos do agente de suas atribuições de usuário final. Como o novo agente em todo o tenant, 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 usar atualmente 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 Universal Broker?
Quando você faz a transição para o uso Universal Broker, 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 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 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 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 SDDC baseada em vSphere, 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
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, 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
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. Se o seu caso de uso exigir um recurso ao qual Universal Broker não oferece suporte, considere manter seu ambiente de tenant usando a intermediação de pod único até que Universal Broker ofereça suporte ao recurso. Para obter uma lista das limitações atuais do Universal Broker, consulte Universal Broker - Considerações de 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 Universal Broker).
Essa é uma visão geral de alto nível dos processos que ocorrem durante e antes da transição.
- 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 Universal Broker durante a transição.
- 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.
- Quando a transição estiver prestes a começar, você será solicitado a efetuar logout do console e fazer login novamente.
- 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 por 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.
- Durante a segunda etapa da transição, o serviço de 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 obter uma lista detalhada das alterações feitas no ambiente do tenant após a transição do agente, consulte Novidades no ambiente do tenant após a transição para o Universal Broker.
Após concluir a transição, você poderá começar a aproveitar os benefícios oferecidos por um ambiente Universal Broker do. 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 plenamente os recursos do Universal Broker. Por exemplo, você pode adicionar pods a uma atribuição existente ou ajustar as configurações do site para ajustar como Universal Broker aloca recursos aos seus usuários. Para obter informações detalhadas, consulte Criar e gerenciar atribuições em seu ambiente Universal Broker e Trabalhando com sites em um ambiente Universal Broker.
- Se houver uma integração existente entre seu tenant Horizon Cloud e Omnissa Access, você deverá atualizar a integração para acomodar o uso de Universal Broker. Para obter instruções completas, consulte Horizon Cloud ambiente com Universal Broker - Integrar o tenant aos serviços Omnissa Access e Intelligent Hub.
Observação: Conforme confirmado pela equipe de produto do Access, quando Universal Broker é usado com seus Horizon Cloud em implantações do Microsoft Azure, o recurso Coleções de Aplicativos Virtuais do produto Access não é compatível com essa configuração. A razão é porque Universal Broker é a tecnologia de intermediação mais moderna do que a antiga intermediação por pod, o que significa que a integração do Universal Broker com o Access substitui o uso das Coleções de Aplicativos Virtuais por pod herdadas para Horizon Cloud em implantações do Microsoft Azure. Portanto, Universal Broker não tem um conceito de Coleções de Aplicativos Virtuais para Horizon Cloud em implantações do Microsoft Azure, que faz uso de Coleções de Aplicativos Virtuais com o Universal Broker e o Horizon Cloud em configurações do Microsoft Azure como não compatíveis.
Quando Universal Broker estiver configurado para o seu Horizon Cloud em implantações do Microsoft Azure e você planejar usar os serviços Access e Intelligent Hub com esses Horizon Cloud em implantações do 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 Access e Intelligent Hub usando os recursos modernos dos serviços integrados Universal Broker e Access and 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 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 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 Universal Broker e 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 de Universal Broker já definidas aos pods do Horizon Cloud.
-
A menos que seus pods de Horizon Cloud atendam aos critérios de manifesto de pod mínimo e ativação da opção de 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 Universal Broker.)
-
Se os pods do Horizon Cloud não atenderem a esses critérios para que o RSA SecurID seja configurado em seus gateways externos, se você quiser usar a autenticação de dois fatores com todos os pods da sua frota - pods do Horizon e pods do Horizon Cloud, cada pod terá que ter um Unified Access Gateway externo com RADIUS autenticação de dois fatores configurada nele.
Requisitos para pods do Horizon Cloud
Verifique se os seus pods Horizon Cloud no Microsoft Azure atendem aos seguintes requisitos.
-
Seu tenant tem pelo menos um pod Horizon Cloud. Um pod 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 o tenant do Horizon Cloud e o 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 de Universal Broker, conforme descrito em Horizon Cloud ambiente com Universal Broker – Integrar o tenant aos serviços Access e 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 seus pods 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 configuraçã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 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 de Universal Broker de nenhum dos pods do Horizon na sua frota de pods, o console solicitará Universal Broker configurações. Quando você planeja definir as configurações de autenticação de dois fatores nas configurações de Universal Broker, cada pod deve ter uma instância de Unified Access Gateway externa 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 Universal Broker.)
Os requisitos dependem de seus pods Horizon Cloud atenderem aos critérios para ter o tipo de RSA SecurID configurado em seus gateways externos:
- Quando seus pods 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 de Unified Access Gateway externas 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 que o RSA SecurID seja configurado em seus gateways externos, se você quiser usar a autenticação de dois fatores com todos os pods de sua frota (pods do Horizon e pods do Horizon Cloud), deverá configurar todas as instâncias de Unified Access Gateway externas 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 do Unified Access Gateway interno, 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.
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 de 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 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 Horizon Cloud.
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 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 Universal Broker. Universal Broker roteia 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 conclui a transição do 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 pelo sistema 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. Certifique-se de 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 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 |
|
| Seu ambiente consiste em vários pods e você deseja configurar um novo FQDN como o FQDN Universal Broker |
|
Agendar e concluir a transição de agente de pod único para 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 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 do 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
- 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.
- Na página Agente , clique no link Agendar .
O assistente de configuração para Universal Broker é exibido. Você deve concluir as etapas deste assistente para configurar Universal Broker para seus pods no Microsoft Azure e agendar a transição para Universal Broker.
- 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.
-
Para Tipo, selecione Nome de domínio completo (FQDN) Fornecido pelo Omnissa ou Personalizado .
-
Especifique configurações adicionais para o tipo de FQDN selecionado.
- Se você tiver selecionado o tipo Fornecido pelo Omnissa , especifique as configurações da seguinte maneira.
| Configuração | Descrição |
|---|---|
| Subdomínio | 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 pelo sistema para formar o FQDN de intermediação.
Observação: algumas cadeias de caracteres não são permitidas ou estão reservadas pelo sistema. Esta categoria de strings inclui palavras genéricas como 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. |
| FQDN de Intermediação | Esse campo somente leitura exibe o FQDN configurado. O FQDN usa o formato https://your-sub-domain.firstgen.omnissahorizon.com.
Forneça esse FQDN aos seus usuários finais para permitir que eles se conectem ao serviço Universal Broker usando Horizon Client. 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 |
|---|---|
| FQDN de Intermediação | Insira o FQDN personalizado que os usuários finais usarão para acessar o serviço Universal Broker. Seu FQDN personalizado funciona como um alias para o FQDN fornecido pelo sistema gerado automaticamente que conclui 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 pelo sistema que representa o endereço de conexão interna do serviço Universal Broker. Por exemplo, o registro pode mapear |
| Certificado |
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 serviço Universal Broker usa esse certificado para estabelecer sessões de conexão confiáveis com clientes. |
| Senha | Insira a senha para o arquivo de certificado PFX. |
| FQDN fornecido pelo Omnissa | Esse campo somente leitura exibe o FQDN fornecido pelo sistema que é gerado automaticamente para o serviço de intermediação. O FQDN tem o formato https://auto-generated-string.firstgen.omnissahorizon.com.
Esse FQDN fornecido pelo sistema 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 esse FQDN fornecido pelo sistema. 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 pelo sistema. Por exemplo, o registro pode mapear |
-
Quando você terminar de definir as configurações de FQDN, clique em Avançar para ir para a próxima página do assistente.
-
(Opcional) Na página Autenticação do assistente, configure a autenticação de dois fatores.
Por padrão, Universal Broker autentica os usuários exclusivamente por meio de seu nome de usuário e senha Active Directory. 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 Universal Broker, você deve primeiro configurar o serviço de autenticação apropriado em cada instância de Unified Access Gateway externa em cada pod participante. As configurações de instâncias de Unified Access Gateway externas devem ser idênticas dentro dos pods participantes e entre eles.
Por exemplo, se você quiser usar RADIUS autenticação, deverá configurar o serviço RADIUS em cada instância do Unified Access Gateway externo 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 Universal Broker depende de Unified Access Gateway para o tráfego de protocolo entre Horizon Client e 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 nesse pod.
| Configuração | Descrição |
|---|---|
| Autenticação de Dois Fatores | 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. |
| Manter Nome de Usuário | Ative essa opção para manter o nome de usuário Active Directory do usuário durante a autenticação para Universal Broker. Quando ativado:
|
| Tipo |
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 senha 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:
: Combinação de pods do Horizon e Horizon Cloud em implantações do Microsoft Azure: em uma frota combinada, quando RADIUS é selecionado aqui, as solicitações de autenticação de RADIUS dos usuários são tentadas por meio das instâncias do 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 seus Horizon Cloud em implantações do Microsoft Azure estarem configurados com RSA SecurID em seus gateways externos: |
| Mostrar Texto da Dica | 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. |
| Texto da Dica Personalizado |
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 Digite seu nome de usuário e senha do DisplayHint, em que DisplayHint é a cadeia de caracteres de texto que você especifica nessa caixa de texto.
Observaçã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: Digite seu nome de usuário e senha de domínio da empresa abaixo para nome de usuário e senha. |
| Autenticação de Dois Fatores |
Ative essa alternância para ignorar a autenticação de dois fatores para usuários de rede interna que se conectam ao serviço Universal Broker. Verifique se você especificou os intervalos de IP públicos pertencentes à rede interna, conforme descrito em Definir intervalos de rede interna para Universal Broker.
|
| Intervalo de IPs Públicos | 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. 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 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.
- Na página Configurações do assistente de configuração, defina as configurações de 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 |
|---|---|
| Intervalo de Pulsação do Client | Controla o intervalo, em minutos, entre Horizon Client heartbeats e o estado da conexão do usuário com Universal Broker. Essas heartbeats relatam para Universal Broker quanto tempo ocioso passou durante a sessão de conexão 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. |
| Usuário ocioso do Client | Tempo ocioso máximo, em minutos, permitido durante uma sessão de conexão entre Horizon Client e Universal Broker. Quando o tempo máximo é atingido, o período de autenticação do usuário expira, e 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. |
| Sessão do Agente do Client | O tempo máximo, em minutos, permitido para uma sessão de conexão Horizon Client antes que a autenticação do usuário expire. A hora começa quando o usuário se autentica 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 exija comunicação com Universal Broker, Horizon Client solicitará que ele insira novamente as credenciais 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. |
| Tempo Limite de Cache da Credencial do Cliente | 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.
- 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.
- Reveja as configurações na página Resumo e, em seguida, clique em Concluir para salvar a configuração do Universal Broker e as configurações de agendamento.
É 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 Horizon Cloud Suporte. Observe que o Suporte Horizon Cloud 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.
- 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 seus pods Horizon Cloud 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 SDDC baseada em vSphere, o serviço de 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.
- 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.
- 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 por 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, Horizon Cloud Suporte 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 Horizon Cloud Suporte remediar a causa da falha, você poderá usar o link na página Agente para reagendar a transição.
- Depois de fazer login novamente no console, permita que o serviço de 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 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 de 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 por Universal Broker e a transição é concluída.
Importante: Se a configuração do Universal Broker falhar, 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, abra uma solicitação de suporte conforme descrito no artigo KB 2006985.
O que fazer agora
- Se houver uma integração existente entre o tenant do Horizon Cloud e o Access, você deverá atualizar a integração para acomodar o uso de Universal Broker. Para obter instruções completas, consulte Horizon Cloud Ambiente com Universal Broker - Integrar o tenant aos Serviços Access e Intelligent Hub.
- Modifique seu site e as configurações de atribuição de VDI de várias nuvens para usar plenamente 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 Universal Broker. Para obter informações detalhadas, consulte Criando e gerenciando atribuições de várias nuvens em seu ambiente de tenant do Horizon Cloud e Trabalhando com sites em um ambiente Universal Broker.
Novidades no seu ambiente de tenant após a transição para o Universal Broker
Este artigo descreve as alterações que você pode esperar em seu ambiente de tenant de 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 Universal Broker, consulte Universal Broker - Considerações de 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 de 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 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 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 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 Desktops 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 o Horizon Cloud em implantações do Microsoft Azure tiver uma integração de pré-transição existente com o Access, você deverá atualizar a integração para um estado pós-transição para acomodar o uso de Universal Broker. Para obter instruções completas, consulte Horizon Cloud ambiente com Universal Broker - Integrar o tenant aos serviços Omnissa Access e Intelligent Hub.
Observe que, ao atualizar essa integração, você precisará usar o fluxo de trabalho de limpeza do Horizon Universal Console 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 Access e Intelligent Hub usando os recursos modernos dos serviços integrados Universal Broker e Access and Intelligent Hub, em vez do recurso de Coleções de Aplicativos Virtuais herdados por pod. Conforme confirmado pela equipe de produto do Access, quando Universal Broker é usado com seus Horizon Cloud em implantações do Microsoft Azure, o recurso Coleções de Aplicativos Virtuais do produto Access não é compatível com essa configuração. A razão é porque Universal Broker é a 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 Access substitui o uso das Coleções de Aplicativos Virtuais por pod herdadas. Portanto, Universal Broker não tem um conceito de Coleções de Aplicativos Virtuais para Horizon Cloud em implantações do Microsoft Azure.
Importante: O recurso de proteção contra exclusão para interrupções de inventário 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.
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.
Esta página foi útil?