O objetivo dessa lista de verificação é informá-lo dos elementos necessários para uma implantação do Horizon Cloud on Microsoft Azure de primeira geração. Seguir essa lista de verificação permite a execução bem-sucedida do implantador de pod e a conclusão das tarefas do dia 1.
A partir de agosto de 2022, o Horizon Cloud Service - next-gen estará em disponibilidade geral e terá seu próprio guia, Uso do Horizon Control Plane next-gen.
Uma indicação de qual ambiente você tem, next-gen ou primeira geração, é o padrão que aparece no campo de URL do navegador depois que você faz login em seu ambiente e vê o rótulo Horizon Universal Console. Para um ambiente next-gen, o endereço de URL do console contém uma parte como /hcsadmin/. A URL do console de primeira geração tem uma seção diferente (/horizonadmin/).
Público-alvo da lista de verificação
Esta lista de verificação se destina principalmente a contas de clientes do Horizon Cloud que nunca tiveram uma implantação do Horizon Cloud on Microsoft Azure em seu ambiente de tenant antes da atualização do serviço em 2 de novembro de 2023. Esses tenants podem ser chamados de ambientes novos ou greenfield.
O conjunto descrito aqui é principalmente para implantações de produção. A avaliação e a maioria das implantações de prova de conceito geralmente podem ser manipuladas com um subconjunto, como ilustrado em Uma implantação simplificada de prova de conceito.
Algumas das seções listadas abaixo devem ser implementadas antes da execução do assistente de implantação de Novo Pod.
Alguns itens podem ser adiados até que a implantação seja concluída e esteja em operação.
Alguns itens são listados como opcionais, pois estão relacionados às escolhas que você faz para a implantação do Horizon Cloud on Microsoft Azure.
Por exemplo, você pode executar o assistente de Novo Pod sem escolher uma configuração do Unified Access Gateway e adicionar a configuração de gateway mais tarde. Nesse caso, você não precisaria cumprir os requisitos do Unified Access Gateway até esse momento posterior.
| Cumpra-os antes de executar o assistente de Novo Pod | Isso pode ser feito após a implantação do pod |
|---|---|
|
|
Algumas considerações importantes
Quando você está fazendo uma implantação de avaliação ou de prova de conceito do Horizon Cloud on Microsoft Azure, pode ser o proprietário da assinatura do Microsoft Azure que será usada para a implantação, ou pode estar fazendo a prova de conceito em nome de uma organização que possui a assinatura.
O proprietário da assinatura deve garantir que nenhuma das políticas do Microsoft Azure em vigor na assinatura do pod bloqueie, negue ou restrinja a criação dos componentes do pod.
O motivo para garantir isso é que, durante o processo de implantação do pod, o implantador do pod usa chamadas de API para criar recursos na assinatura especificada no assistente de Novo Pod. Se essa assinatura tiver políticas do Microsoft Azure em vigor que possam bloquear, negar ou restringir a criação dos componentes do pod, a implantação não será bem-sucedida e exigirá uma solicitação de suporte da VMware.
Um exemplo é que o implantador do pod requer que nenhuma das políticas do Microsoft Azure em vigor na assinatura do pod bloqueie, negue ou restrinja a criação de componentes na conta de armazenamento do Azure.
Antes de executar o assistente de Novo Pod, verifique com o proprietário da assinatura se as definições de Política Interna das Políticas do Microsoft Azure não bloqueiam, negam ou restringem a criação dos componentes do pod.
Requisitos de camada de controle do Horizon Cloud
| ☐ | A conta do VMware Customer Connect que foi configurada pela VMware para fazer login na camada de controle do Horizon Cloud. Para obter uma visão geral do relacionamento dessa conta com sua conta de tenant do Horizon Cloud, você pode consultar a página Implantações do Horizon Service e Pods de Integração. |
Requisitos de assinatura do Microsoft Azure
| ☐ | Assinatura válida do Microsoft Azure em um ambiente do Microsoft Azure com suporte (Azure Commercial, Azure China, ou Azure Government). Se você implantar o Unified Access Gateway externo em uma VNet separada usando sua própria assinatura, obtenha outra assinatura válida do Microsoft Azure no mesmo ambiente que o Microsoft Azure.
Observação: O
Horizon Cloud é compatível com a maioria das regiões do Microsoft Azure. Para obter a lista de regiões do Microsoft Azure que não têm suporte atualmente, consulte o
artigo da Base de Conhecimento da VMware Regiões do Microsoft Azure com Horizon Cloud Service on Microsoft Azure (77121).
|
| ☐ | Privilégios administrativos válidos do Microsoft Azure nessa assinatura do Microsoft Azure, para você usar o portal do Microsoft Azure e executar as etapas de preparação da implantação do pod. |
| ☐ | Registro do aplicativo e chave secreta do cliente do Horizon Cloud criados na assinatura do pod. Consulte Tenants de primeira geração: criar um Registro do aplicativo Horizon Cloud na assinatura do pod. Quando você ou sua organização usarem o recurso para implantar a configuração de gateway externo em uma assinatura separada da assinatura do pod, essa assinatura de gateway também precisará de um registro de aplicativo do Horizon Cloud e de uma chave secreta do cliente. |
| ☐ | A criação do registro do aplicativo do Horizon Cloud em uma assinatura cria automaticamente uma entidade de serviço, pelo comportamento padrão do Microsoft Azure. Para essa entidade de serviço, atribua uma função que permita que o Horizon Cloud faça chamadas à API na assinatura do pod. Normalmente, a função Como alternativa, a função pode ser personalizada e atribuída no nível de assinatura do pod. Ao implantar a configuração de gateway externo em um grupo de recursos existente em uma assinatura separada, você pode atribuir uma função personalizada ou a função Quando você ou sua organização quiserem que o registro do aplicativo do Horizon Cloud use uma função personalizada, consulte a página a seguir, que descreve as ações que a função personalizada deve ter: Quando sua organização prefere usar uma função personalizada.
Observação: A função deve ser atribuída diretamente à entidade de serviço do registro do aplicativo do
Horizon Cloud. Não há suporte para o uso de uma atribuição baseada em grupo de uma função para essa entidade de serviço.
|
| ☐ | Provedores de recursos necessários registrados em cada assinatura do Microsoft Azure. Consulte Registrar provedores de recursos. |
| ☐ | ID da assinatura, ID do diretório, ID do aplicativo e chave identificados para a assinatura que você especificará no assistente de implantação. |
| ☐ | A assinatura deve permitir o uso do tipo de conta Azure StorageV2. Verifique se suas políticas do Microsoft Azure não restringem nem negam a criação de conteúdo que requer o tipo de conta Azure StorageV2. |
| ☐ | A assinatura deve permitir a criação de grupos de recursos que não têm tags, a menos que você especifique tags de recursos personalizadas no assistente de implantação de pod. O processo de implantação do pod cria grupos de recursos na assinatura do pod sem tags, a menos que você especifique tags de recursos personalizadas no assistente. Se você não estiver planejando usar o recurso de tags de recursos personalizadas do assistente de implantação, deverá verificar se as suas políticas do Microsoft Azure permitem a criação dos grupos de recursos não marcados do pod na assinatura de destino. Se você não especificar tags de recursos personalizadas no assistente e sua assinatura do Microsoft Azure tiver algum tipo de requisito de tag de recurso, a implantação do pod falhará quando você tentar implantar um pod nessa assinatura, ou ela falhará durante a atualização do pod ou a adição de uma configuração de gateway a um pod. Para obter os nomes dos grupos de recursos criados pelo implantador, consulte Grupos de recursos que o implantador do pod cria. |
| ☐ | Opcional. Sua organização pode especificar que requer que você use um grupo de recursos específico e pré-criado nomeado pela organização para o Unified Access Gateway externo, em uma VNet e uma assinatura separadas da assinatura do pod, e a organização requer o uso de um grupo de recursos específico pré-criado nomeado pela organização; você usaria o recurso para implantar o Unified Access Gateway externo em seu próprio grupo de recursos nomeado. Sem usar esse recurso, o implantador do pod cria automaticamente um grupo de recursos com sua própria convenção de nomenclatura. O uso do recurso exige que você crie esse grupo de recursos nessa assinatura antes de executar o implantador do pod. Você também precisa garantir que as permissões necessárias estejam em vigor para o implantador do pod implantar a configuração do Unified Access Gateway nesse grupo de recursos, gerenciar a configuração e atualizar o software Unified Access Gateway no processo de atualização do pod padrão. Para obter detalhes sobre as permissões necessárias para incluir na função personalizada, consulte Quando sua organização prefere usar uma função personalizada. |
Requisitos de capacidade do Microsoft Azure
Quando a tabela a seguir se refere à capacidade do Microsoft Azure, nenhuma instalação manual é necessária. Contanto que as capacidades declaradas estejam disponíveis na assinatura, o implantador do pod instanciará automaticamente as VMs descritas.
Para capacidade envolvendo famílias de VMs, o portal do Microsoft Azure também usa o termo quota.
| ☐ | Capacidade do Microsoft Azure para os artefatos do pod principal do Horizon Cloud a serem implantados nessa assinatura. (essa lista exclui as capacidades necessárias para as configurações opcionais do Unified Access Gateway e para suas cargas de trabalho de área de trabalho e aplicativos previstas).
|
| ☐ | Opcional. Capacidade necessária ao especificar o uso do Unified Access Gateway para o pod.
Observação: O modelo de VM
A4_v2 só é suficiente para provas de conceito (PoCs), pilotos ou ambientes menores nos quais você sabe que não excederão 1.000 sessões ativas no pod.
Se a região da assinatura não fornecer os tamanhos |
Requisitos de rede
| ☐ | Rede virtual do Microsoft Azure (VNet) criada na região de destino do Microsoft Azure com espaço de endereço aplicável para cobrir as sub-redes necessárias. Consulte Horizon Cloud de primeira geração: configurar a rede virtual necessária no Microsoft Azure. Ao implantar o Unified Access Gateway externo na própria VNet, separada da do pod, crie essa VNet do Unified Access Gateway na mesma região do Microsoft Azure que a VNet do pod com o espaço de endereço aplicável para cobrir as sub-redes necessárias e emparelhe as duas VNets. |
| ☐ | 3 intervalos de endereços não sobrepostos no formato CIDR na VNet do pod, reservados para sub-redes.
Dica: Depois que o pod for implantado, você poderá editá-lo para adicionar sub-redes de tenant para uso com as VMs em seus farms e atribuições de área de trabalho. As sub-redes adicionais do tenant podem estar na mesma VNet na qual o pod está implantado ou em uma VNet emparelhada. Para obter detalhes, consulte
Visão geral do uso de várias sub-redes de tenant.
|
| ☐ | Ao implantar o Unified Access Gateway externo na própria VNet separada da do pod, três intervalos de endereços não sobrepostos no formato CIDR na VNet do Unified Access Gateway, reservados para sub-redes.
|
| ☐ | Servidores ou servidor NTP disponíveis e acessíveis a partir do pod do Horizon Cloud e das instâncias do Unified Access Gateway. |
| ☐ | Configure o servidor DNS da VNet (rede virtual), apontando para um servidor DNS válido que possa resolver os nomes externos e os nomes de máquinas internos. |
| ☐ | O acesso de saída à Internet nas VNets que você está usando para o pod e a implantação do gateway devem resolver e acessar nomes DNS específicos usando portas e protocolos específicos. Isso é necessário para a implantação e a continuidade das operações. Para obter a lista de nomes e portas DNS, consulte Requisitos de DNS e Requisitos de portas e protocolos. |
| ☐ | Opcional. Informações do servidor proxy, se necessário, para acesso de saída à Internet na VNet que é usada durante a implantação e a continuidade das operações do ambiente do Horizon Cloud. |
| ☐ | Opcional. O Microsoft Azure VPN/Express Route configurado, quando você deseja a rede entre a VNet e sua rede corporativa local. |
Requisitos de portas e protocolos
| ☐ | Portas e protocolos específicos são necessários para a integração de pods e a continuidade das operações do ambiente do Horizon Cloud. Consulte Portas e protocolos. |
Requisitos do Unified Access Gateway
Você pode executar o assistente de Novo Pod sem escolher uma configuração do Unified Access Gateway e adicionar a configuração de gateway mais tarde. Nesse caso, você não precisaria cumprir os requisitos do Unified Access Gateway até esse momento posterior. Por definição, um Unified Access Gateway externo permite que os clientes em redes externas iniciem as áreas de trabalho e aplicativos virtuais, enquanto um Unified Access Gateway interno permite que os clientes em redes internas tenham conexões do HTML Access (Blast) confiáveis. Para oferecer suporte a conexões de usuário final da Internet e à inicialização de suas áreas de trabalho e aplicativos virtuais, o pod deve ter um Unified Access Gateway externo configurado.
Se você selecionar as opções do Unified Access Gateway no assistente de Novo Pod, o assistente exigirá itens específicos abaixo.
| ☐ | FQDN para a configuração do Unified Access Gateway. |
| ☐ | Certificado ou certificados para o Unified Access Gateway no formato PEM correspondente ao FQDN.
Observação: Se o certificado ou os certificados que você fornecer para essa finalidade usarem as CRLs (listas de certificados revogados) ou as configurações de OCSP (protocolo de status de certificados on-line) que se referem a nomes DNS específicos, você deverá garantir que o acesso à internet de saída na VNet para esses nomes DNS seja resolvível e acessível. Durante a configuração do certificado fornecido na configuração do gateway do
Unified Access Gateway, o software do
Unified Access Gateway consultará esses nomes DNS para verificar o status de revogação do certificado. Se esses nomes DNS não estiverem acessíveis, a implantação do pod falhará durante a fase de
Conexão. Esses nomes são altamente dependentes da autoridade de certificação que você usou para obter os certificados e, portanto, não estão no controle da VMware.
|
| ☐ | Opcional, exceto quando você deseja que seus usuários finais usem a autenticação de dois fatores. Nesse caso, o Unified Access Gateway deve ser configurado para autenticação de dois fatores com um dos tipos de sistema de autenticação compatíveis para uso com implantações do Horizon Cloud on Microsoft Azure. A configuração deve incluir:
Observação: Depois que o pod é implantado e você configurou a autenticação de dois fatores nas configurações do
Universal Broker, algumas configurações adicionais são necessárias quando você também deseja que seus usuários finais internos ignorem o uso da autenticação de dois fatores. Quando um pod tem uma configuração do
Unified Access Gateway interno, essa configuração roteia as solicitações de conexão para áreas de trabalho virtuais e aplicativos para esses usuários finais internos. Quando você quiser que o
Universal Broker ignore a etapa de autenticação de dois fatores para seus usuários finais internos, depois que o pod for implantado e o
Universal Broker estiver configurado, insira os intervalos de endereços NAT de saída que correspondem ao seu tráfego de usuário final interno. Esses intervalos permitem que o
Universal Broker identifique o tráfego do cliente dos usuários finais internos distintos dos usuários finais externos com o objetivo de ignorar a autenticação de dois fatores. Para obter detalhes, consulte o tópico de documentação
Definir intervalos de rede interna para o Universal Broker
|
Fluxo de trabalho de implantação do pod
Os itens anteriores são aqueles necessários antes de iniciar o assistente de implantação do pod. Depois de garantir que você tenha os itens anteriores, siga as etapas 1 a 4 de implantação do pod em Tenants de primeira geração: implantações do Horizon Cloud on Microsoft Azure: sequência de alto nível para implantar o pod.
Depois que o pod for implantado com êxito, certifique-se de ter os itens descritos na seção a seguir, para que você possa concluir as etapas de chave restantes nesse fluxo de trabalho de alto nível.
Requisitos do Active Directory
O fluxo de trabalho de registro do Active Directory do console exige os seguintes itens. Para compreender totalmente esse fluxo de trabalho, consulte Como realizar seu primeiro registro de domínio do Active Directory no ambiente do Horizon Cloud.
| ☐ | Uma das seguintes configurações do Active Directory com suporte:
|
| ☐ | Níveis funcionais de domínio do Microsoft Windows Active Directory Domain Services (AD DS) compatíveis:
|
| ☐ | Todos os pods conectados à nuvem na mesma conta de cliente do Horizon Cloud devem ter linha de visão para o mesmo conjunto de domínios do Active Directory no momento em que você implanta esses pods. Esse requisito é aplicado não apenas aos pods adicionais que você implanta no Microsoft Azure após o primeiro pod, mas também a quaisquer pods do Horizon conectados por nuvem à mesma conta de cliente que usa o Horizon Cloud Connector. |
| ☐ |
Referência: Contas de serviço que o Horizon Cloud exige para suas operações |
| ☐ |
Referência: Contas de serviço que o Horizon Cloud exige para suas operações |
| ☐ |
Consulte Contas de serviço que o Horizon Cloud exige para suas operações para obter mais detalhes. No Microsoft Active Directory, quando você cria uma nova UO, pode ser que o sistema defina automaticamente o atributo |
| ☐ |
Consulte Contas de serviço que o Horizon Cloud exige para suas operações para obter mais detalhes. No Microsoft Active Directory, quando você cria uma nova UO, pode ser que o sistema defina automaticamente o atributo |
| ☐ | Grupos do Active Directory
O Horizon Cloud é compatível com o uso de grupos de segurança personalizados do Active Directory para logins de administrador e direitos de usuário final. Há suporte para grupos aninhados. A associação ao grupo é avaliada, solicitando o atributo computado tokenGroups, o que significa que o Horizon Cloud não tem limitações de profundidade de aninhamento, mas oferece suporte ao que está definido no seu Active Directory. Quando perguntada se há considerações adicionais ou limitações adicionais no contexto dos grupos do Active Directory e a combinação de Horizon Cloud mais Universal Broker e Workspace ONE Access Cloud, a resposta a essa pergunta é Não, nenhum. Se o seu ambiente de tenant tiver algum pod do Horizon Cloud no Microsoft Azure executando manifestos anteriores ao 1600.0, a conta de ingresso no domínio e quaisquer contas auxiliares de ingresso no domínio também deverão estar no grupo de administradores do Horizon Cloud ou em um grupo do Active Directory que tenha recebido a função de Superadministrador no Horizon Cloud. |
| ☐ | Unidade organizacional (OU) ou unidades organizacionais (UOs) do Active Directory para áreas de trabalho virtuais e áreas de trabalho com base em sessão RDS ou aplicativos publicados ou ambos. No Microsoft Active Directory, quando você cria uma nova UO, pode ser que o sistema defina automaticamente o atributo |
Se você quiser usar um Active Directory configurado para LDAPS, deverá solicitar a ativação dos recursos compatíveis do LDAPS com seu tenant do Horizon Cloud. Para obter mais detalhes, consulte Usar ambientes do Active Directory configurados para LDAPS.
Configuração do Universal Broker
Para a configuração do Universal Broker, preencha os itens da tabela a seguir que são aplicáveis às opções desejadas. Para obter detalhes completos, consulte Configurar o Universal Broker.
| ☐ | O acesso de saída à Internet nas VNets que você está usando para o pod deve resolver e acessar nomes DNS específicos usando portas e protocolos específicos. Isso é necessário para a configuração do Universal Broker e operações contínuas. Para obter a lista de nomes e portas DNS, consulte Tenants de primeira geração: Implantações do Horizon Cloud on Microsoft Azure: requisitos de resolução de nomes de host e nomes DNS e Tenants de primeira geração: pod do Horizon Cloud: requisitos de portas e protocolos. |
| ☐ | Dependendo dos tipos de conexões de usuário final que você deseja fornecer:
|
| ☐ | Opcional. Quando você deseja que o Universal Broker imponha a autenticação de dois fatores, os pods devem ter um Unified Access Gateway externo configurado para autenticação de dois fatores com um dos tipos de sistema de autenticação compatíveis para uso com implantações do Horizon Cloud on Microsoft Azure. O Universal Broker passa a solicitação de autenticação para o Unified Access Gateway, que se comunica com o servidor de autenticação e, em seguida, retransmite a resposta para o Universal Broker. Essa configuração do Unified Access Gateway externo requer os seguintes itens:
|
| ☐ | Opcional: um FQDN personalizado que os usuários finais usarão para acessar o serviço do Universal Broker e o certificado com base nesse FQDN. Se você quiser usar o FQDN de intermediação fornecido pela VMware, não será necessário um FQDN personalizado. |
Requisitos de registro DNS
Depois que o pod é implantado na nuvem do Microsoft Azure e, dependendo da sua situação de negócios e dos recursos que você deseja aproveitar, é importante configurar os registros no servidor DNS que mapeia nomes de domínio totalmente qualificados (FQDNs) para endereços IP relacionados ao pod. Para obter informações básicas sobre o mapeamento de registros DNS, consulte a página de documentação dos serviços de nuvem da Microsoft Configuração de um nome de domínio personalizado para um serviço de nuvem do Azure.
- Quando você configura o Universal Broker do tenant usando um FQDN personalizado
-
☐ Crie um registro DNS público que mapeie seu FQDN personalizado para o FQDN de intermediação fornecido pela VMware na configuração do Universal Broker. Consulte Configurar Universal Broker. - Quando o pod tem um Unified Access Gateway externo
-
☐ Crie um registro DNS público para o acesso do usuário final externo que corresponda ao FQDN na configuração do gateway externo. Esse registro DNS aponta esse FQDN para o balanceador de carga externo do Microsoft Azure na configuração do Unified Access Gateway externo do pod. Para obter informações básicas sobre o mapeamento de registros DNS, consulte a página de documentação da Microsoft Configuração de um nome de domínio personalizado para um serviço de nuvem do Azure.
- Quando o pod tem um Unified Access Gateway interno
-
☐ Crie um registro DNS interno para o acesso do usuário final interno que corresponda ao FQDN na configuração do gateway interno. Esse registro DNS pinta esse FQDN para o balanceador de carga interno do Microsoft Azure na configuração do Unified Access Gateway interno do pod.
Golden images, áreas de trabalho e farms do Horizon Cloud
Sua assinatura do Microsoft Azure deve acomodar os seguintes requisitos, dependendo dos tipos de golden images, áreas de trabalho VDI e farms RDS que você deseja provisionar com base no pod implantado.
Além disso, observe a matriz de suporte a seguir para o uso de modelos de VM de Geração 1, VM de Geração 2 da Microsoft Azure, com relação aos sistemas operacionais convidados Windows 10 e Windows 11.
| Modelo de VM do Azure | Windows 10 | Windows 11 |
|---|---|---|
| VM de Geração 1 | Com suporte | Sem suporte |
| VM de Geração 2 | Sem suporte | Com suporte |
| ☐ | Base para a golden image: uma ou mais das configurações compatíveis de VM do Microsoft Azure.
Ao usar o assistente automatizado para Importar VM do Marketplace do console para criar uma VM base, o sistema usa automaticamente um dos tamanhos de VM acima por padrão. A escolha padrão do sistema baseia-se em suas configurações internas e no sistema operacional (SO) específico. O sistema usa os modelos conforme indicado para imagens de pod único e imagens de vários pods. |
| ☐ | Seleção de modelo para as VMs de área de trabalho nas atribuições de área de trabalho VDI: qualquer uma das configurações de VM do Microsoft Azure disponíveis na região do Microsoft Azure, exceto aquelas não compatíveis com operações de área de trabalho do Horizon Cloud. Para ambientes de produção, o teste de dimensionamento da VMware recomenda o uso de modelos que tenham no mínimo 2 CPUs ou mais. |
| ☐ | Seleção de modelo para as VMs RDSH em farms: qualquer uma das configurações de VM do Microsoft Azure disponíveis na região do Microsoft Azure, exceto aquelas não compatíveis com operações de farm RDS do Horizon Cloud. Esse requisito também se aplica a uma VM que executa o Microsoft Windows 10 Enterprise de várias sessões ou o Windows 11 Enterprise de várias sessões quando essa VM é usada com o Horizon Cloud. Conforme descrito nas Perguntas frequentes sobre o Microsoft Windows Enterprise de várias sessões na documentação da Área de Trabalho Virtual do Microsoft Azure, o Microsoft Windows Enterprise de várias sessões é um tipo de Host de Sessão de Área de Trabalho Remota (RDSH) que permite várias sessões interativas simultâneas, que, anteriormente, eram fornecidas apenas pelos sistemas operacionais Microsoft Windows Server. Os fluxos de trabalho do Horizon Cloud que se aplicam a servidores RDS são aplicáveis ao Microsoft Windows Enterprise de várias sessões. Para ambientes de produção, o teste de dimensionamento da VMware recomenda o uso de modelos que tenham no mínimo 2 CPUs ou mais. |
Requisitos do Serviço de Gerenciamento de Imagens (IMS)
A partir da versão de julho de 2021, quando os pods do Horizon Cloud estiverem executando o manifesto 2632 ou posterior e seu ambiente de tenant tiver o Universal Broker ativado, os recursos do Serviço de Gerenciamento de Imagens do Horizon estarão disponíveis para uso com esses pods. O uso dos recursos de imagem de vários pods fornecidos pelo serviço tem requisitos adicionais. Para obter todos os detalhes dos requisitos do sistema para uso desses recursos, consulte a seção do Microsoft Azure Requisitos do sistema do Serviço de Gerenciamento de Imagens do Horizon. Um resumo dos requisitos adicionais na assinatura do pod e no registro do aplicativo do Horizon Cloud dessa assinatura e sua entidade de serviço ao usar imagens de vários pods são descritos na tabela a seguir.
| ☐ | As assinaturas usadas por esses pods que participam de imagens de vários pods devem estar em um único tenant do Microsoft Azure Active Directory (AAD). |
| ☐ | A entidade de serviço do registro do aplicativo do Horizon Cloud usada pelos pods que participam de imagens de vários pods deve atender a um dos seguintes requisitos:
Como os pods provavelmente estão em assinaturas diferentes, o requisito de acesso de leitura permite que a assinatura de cada pod participante tenha uma linha de visão para as assinaturas dos outros pods participantes. Essa linha de visão é necessária para que o serviço use os recursos da Galeria de Imagens Compartilhadas do Azure para a criação das imagens de vários pods. |
| ☐ | Quaisquer funções personalizadas usadas pelas entidades de serviço dos pods participantes devem incluir as permissões a seguir relacionadas ao uso da Galeria de Imagens Compartilhadas do Azure.
|
Licenciamento para os sistemas operacionais Microsoft Windows
Os itens estão relacionados aos sistemas operacionais Microsoft Windows nas suas VMs importadas, golden images, VMs do farm compatíveis com RDSH e VMs de área de trabalho virtual. Para obter a lista de sistemas operacionais Microsoft Windows compatíveis com o Horizon Cloud, consulte o Artigo 78170 da base de dados de conhecimento da VMware e o Artigo 70965 da base de dados de conhecimento da VMware.
O Horizon Cloud não fornece nenhum licenciamento de sistema operacional convidado necessário para o uso de sistemas operacionais Microsoft Windows que você utiliza durante o uso dos fluxos de trabalho do Horizon Cloud. Você, o cliente, tem a responsabilidade de possuir licenças válidas e elegíveis da Microsoft que lhe autorizem a criar, realizar fluxos de trabalho nas e operar as VMs de área de trabalho baseadas no Windows e as VMs RDSH que você escolhe usar em seu ambiente de tenant do Horizon Cloud. O licenciamento necessário depende do uso pretendido.
| ☐ | Licenciamento para um ou mais dos seguintes tipos: Microsoft Windows 7 Enterprise, Microsoft Windows 10, Microsoft Windows 11 (tipos de cliente de sessão única, VDI) |
| ☐ | Licenciamento para o Microsoft Windows 10 Enterprise de várias sessões ou o Microsoft Windows 11 Enterprise de várias sessões |
| ☐ | Licenciamento para um ou mais dos seguintes tipos: Microsoft Windows Server 2012 R2, Microsoft Server 2016, Microsoft Server 2019 |
| ☐ | Servidores de licenciamento Microsoft Windows RDS – para alta disponibilidade, são recomendados servidores de licenciamento redundantes |
| ☐ | CAL por usuário ou CAL por dispositivo do Microsoft RDS ou ambas |
Arquitetura de referência
Use os diagramas de arquitetura abaixo como referência.
