Registro de VDA
Introdução
Nota:
Em um ambiente local, os VDAs se registram em um Delivery Controller. Em um ambiente de serviço do Citrix Cloud, os VDAs se registram em um Cloud Connector. Em um ambiente híbrido, alguns VDAs se registram em um Delivery Controller, enquanto outros se registram em um Cloud Connector.
Antes que um VDA possa ser usado, ele deve se registrar (estabelecer comunicação) em um ou mais Controllers ou Cloud Connectors no site. O VDA encontra um Controller ou Connector consultando uma lista chamada ListofDDCs. A ListOfDDCs em um VDA contém entradas DNS que apontam o VDA a Controllers ou Cloud Connectors no site. Para o balanceamento de carga, o VDA distribui automaticamente conexões entre todos os Controllers ou Cloud Connectors na lista.
Por que o registro de VDA é tão importante?
- Do ponto de vista da segurança, o registro é uma operação confidencial. Você está estabelecendo uma conexão entre o Controller ou o Cloud Connector e o VDA. Por ser uma operação tão sigilosa, o comportamento esperado é rejeitar a conexão se algo não estiver em perfeita ordem. Você está efetivamente estabelecendo dois canais de comunicação separados: VDA para Controller ou Cloud Connector e Controller ou Cloud Connector para VDA. A conexão usa Kerberos, portanto, problemas de sincronização de horário e associação de domínio são inevitáveis. O Kerberos usa nomes de entidade de serviço (SPN), portanto, você não pode usar IP ou nome de host com balanceamento de carga.
- Se um VDA não tiver informações precisas e atuais do Controller ou do Cloud Connector à medida que você adiciona e remove Controllers (ou Cloud Connectors), o VDA rejeitará inicializações de sessão que sejam intermediadas por um Controller ou Cloud Connector que não esteja listado. Entradas inválidas podem atrasar a inicialização do software do sistema de área de trabalho virtual. Um VDA não aceitará uma conexão de um Controller ou Cloud Connector desconhecido e não confiável.
Além da ListofDDCs, a ListOfSIDs (IDs de segurança) indica quais máquinas na ListofDDCs são confiáveis. A ListofSIDs pode ser usada para diminuir a carga no Active Directory ou para evitar possíveis ameaças de segurança de um servidor DNS comprometido. Para obter mais informações, consulte ListOfSIDs.
Se uma ListofDDCs especificar mais de um Controller ou Cloud Connector, o VDA tentará se conectar a eles em ordem aleatória. Em uma implantação local, a ListofDDCs também pode conter grupos de Controllers. O VDA tenta se conectar a cada Controller em um grupo antes de se mover para outras entradas na ListofDDCs.
O Citrix Virtual Apps and Desktops testa automaticamente a conectividade com Controllers ou Cloud Connectors configurados durante a instalação do VDA. São exibidos erros se um Controller ou Cloud Connector não puder ser acessado. Se você ignorar um aviso de que um Controller ou Cloud Connector não pode ser contatado (ou quando você não especifica os endereços do Controller ou do Cloud Connector durante a instalação do VDA), serão exibidas novas mensagens.
Métodos para configurar endereços do Controller ou Cloud Connector
O administrador escolhe o método de configuração a ser usado quando o VDA se registra pela primeira vez (o registro inicial). Durante o registro inicial, um cache persistente é criado no VDA. Durante os registros subsequentes, o VDA recupera a lista de Controllers ou Cloud Connectors do cache local, a menos que uma alteração de configuração seja detectada.
A maneira mais fácil de recuperar a lista durante os registros subsequentes é usando o recurso de atualização automática. A atualização automática está ativada por padrão. Para obter mais informações, consulte Atualização automática.
Existem vários métodos para configurar os endereços do Controller ou Cloud Connector em um VDA.
- Baseado em política (LGPO ou GPO)
- Baseado em registro (manual, preferências de política de grupo (GPP), especificado durante a instalação do VDA)
- Baseado em UO do Active Directory (descoberta de unidade organizacional herdada)
- Baseado em MCS (personality.ini)
Você especifica o método de registro inicial ao instalar um VDA. (Se você desativar a atualização automática, o método selecionado durante a instalação do VDA será usado para registros subsequentes.)
O gráfico a seguir mostra a página Delivery Controller do assistente de instalação do VDA.
Baseado em política (LGPO/GPO)
A Citrix recomenda o uso de GPO para o registro inicial do VDA. Ele tem a maior prioridade. (Embora a atualização automática esteja listada como a prioridade mais alta, a atualização automática é usada somente após o registro inicial.) O registro baseado em política oferece a vantagem de centralizar o uso da Política de Grupo na configuração.
Para especificar esse método, realize as duas etapas a seguir:
- Na página Delivery Controller no assistente de instalação do VDA, selecione Do it later (advanced). O assistente solicita várias vezes que você especifique os endereços do Controller, mesmo que você não os esteja especificando durante a instalação do VDA. (O registro do VDA é muito importante.)
- Ative ou desative o registro do VDA baseado em política através da política da Citrix com o parâmetro
Virtual Delivery Agent Settings > Controllers. (Se a segurança for sua maior prioridade, use o parâmetroVirtual Delivery Agent Settings > Controller SIDs.)
Esta configuração é armazenada em HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs).
Baseado em registro
Para especificar esse método, realize uma das etapas a seguir:
- Na página Delivery Controller no assistente de instalação do VDA, selecione Do it manually. Insira o FQDN de um Controller instalado e clique em Add. Se você instalou mais Controllers, adicione seus endereços.
- Para uma instalação de VDA por linha de comando, use a opção /controllers e especifique o FQDNs dos Controllers ou Cloud Connectors instalados.
Essas informações são armazenadas no valor do registro ListOfDDCs sob a chave do registro HKLM\Software\Citrix\VirtualDesktopAgent ou HKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent.
Você também pode configurar essa chave de registro manualmente ou usar as preferências de política de grupo (GPP). Este método pode ser preferível ao método baseado em política (por exemplo, se você quiser o processamento condicional de diferentes Controllers ou Cloud Connectors, como, por exemplo, usar XDC-001 para nomes de computadores que começam com XDW-001-).
Atualize a chave do registro ListOfDDCs, que lista os FQDNs de todos os Controllers ou Cloud Connectors no site. (Esta chave é o equivalente à unidade organizacional (UO) do site do Active Directory.)
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
Se o local do registro HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent contém as chaves ListOfDDCs e FarmGUID, ListOfDDCs é usado para a descoberta do Controller ou do Cloud Connector. FarmGUID estará presente se uma UO do site foi especificada durante a instalação do VDA. (Isso pode ser usado em implantações legadas.)
Opcionalmente, atualize a chave do registro ListOfSIDs (para obter mais informações, consulte ListOfSIDs:
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)
Lembre-se: se você também ativar o registro de VDA baseado em política através da política da Citrix, isso substituirá as configurações especificadas durante a instalação do VDA, pois esse é o método de maior prioridade.
Baseado em UO do Active Directory (legado)
Este método é suportado principalmente para compatibilidade com versões anteriores, não sendo recomendado. Se você ainda estiver usando, a Citrix sugere mudar para outro método.
Para especificar esse método, realize as duas etapas a seguir:
- Na página Delivery Controller no assistente de instalação do VDA, selecione Choose locations from Active Directory.
- Use o script
Set-ADControllerDiscovery.ps1(disponível em cada Controller). Além disso, configure a entrada de registroFarmGuidem cada VDA para apontar para a UO correta. Esse parâmetro pode ser configurado usando a Política de Grupo.
Baseado em MCS
Se você planeja usar apenas o MCS para provisionar VMs, você pode instruir o MCS para configurar a lista de Controllers ou Cloud Connectors. Esse recurso funciona com a atualização automática. Ao criar o catálogo, o MCS injeta a lista de Controllers ou Cloud Connectors no arquivo Personality.ini durante o provisionamento inicial. A atualização automática mantém a lista em dia.
Este método não é recomendado para uso em ambientes grandes. Você pode usar esse método se:
- Tem um ambiente pequeno
- Não moverá VDAs entre sites
- Usa apenas o MCS para provisionar VMs
- Não deseja usar a Política de Grupo
Para especificar esse método, na página Delivery Controller no assistente de instalação do VDA, selecione Let Machine Creation Services do it.
Revisão e recomendações
Como prática recomendada:
- Use o método de registro da política de grupo para o registro inicial.
- Use a atualização automática (ativada por padrão) para manter a sua lista de Controllers atualizada.
- Em uma implantação de várias zonas, use a Política de Grupo para a configuração inicial (com pelo menos dois Controllers ou Cloud Connectors). Aponte VDAs para Controllers ou Cloud Connectors locais, para dentro de suas zonas. Use a atualização automática para mantê-los atualizados. A atualização automática otimiza automaticamente a
ListofDDCspara VDAs em zonas satélite. -
Inclua mais de um controlador na chave do registro
ListOfDDCs, separado por um espaço ou vírgula, para evitar problemas de registro se um Controller não estiver disponível. Por exemplo:DDC7x.xd.local DDC7xHA.xd.local 32-bit: HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ) <!--NeedCopy--> - Assegure-se de que todos os valores listados em
ListofDDCsmapeiam para um nome de domínio totalmente qualificado válido para evitar atrasos no registro de inicialização.
Atualização automática
A atualização automática (introduzida no XenApp e XenDesktop 7.6) é ativada por padrão. É o método mais eficiente para manter seus registros de VDA atualizados. Embora não seja usado para o registro inicial, o software de atualização automática baixa e armazena a ListofDDCs em um cache persistente no VDA quando o registro inicial ocorre. Esse processo é feito para cada VDA. O cache também contém informações da política da máquina, o que garante que as configurações da política sejam mantidas em todas as reinicializações.
A atualização automática é suportada usando o MCS ou o Citrix Provisioning para provisionar máquinas, exceto para o cache do lado do servidor do Citrix Provisioning. O cache do lado do servidor não é um cenário comum porque não há armazenamento persistente para o cache de atualização automática.
Para especificar esse método:
- Ative ou desative a atualização automática através de uma política da Citrix contendo o parâmetro
Virtual Delivery Agent Settings > Enable auto update of Controllers. Essa configuração é ativada por padrão.
Como funciona:
- Cada vez que um VDA se registra novamente (por exemplo, após uma reinicialização da máquina), o cache é atualizado. Cada Controller ou Cloud Connector também verifica o banco de dados do site a cada 90 minutos. Se um Controller ou Cloud Connector tiver sido adicionado ou removido desde a última verificação, ou se ocorreu uma alteração de política que afeta o registro do VDA, o Controller ou o Cloud Connector envia uma lista atualizada para seus VDAs registrados e o cache é atualizado. O VDA aceita conexões de todos os Controllers ou Cloud Connectors na sua lista armazenada em cache mais recentemente.
- Se um VDA receber uma lista que não inclui o Controller ou o Cloud Connector no qual está registrado (em outras palavras, o Controller ou o Cloud Connector foi removido do site), o VDA se registra novamente, escolhendo entre os Controllers ou Cloud Connectors na
ListofDDCs.
Exemplo:
- Uma implantação tem três Controllers: A, B e C. Um VDA se registra no Controller B (que foi especificado durante a instalação do VDA).
- Mais tarde, dois Controllers (D e E) são adicionados ao site. Dentro de 90 minutos, os VDAs recebem listas atualizadas e aceitam as conexões dos Controllers A, B, C, D e E. (A carga não é distribuída uniformemente a todos os Controllers até que os VDAs sejam reiniciados.)
- Mais tarde, o Controller B é movido para outro site. Dentro de 90 minutos, os VDAs no site original recebem listas atualizadas porque houve uma alteração no Controller desde a última verificação. O VDA que se registrou originalmente no Controller B (que não está mais na lista) se registra novamente, escolhendo entre os Controllers na lista atual (A, C, D e E).
Em uma implantação multizona, a atualização automática em uma zona satélite automaticamente armazena em cache todos os Controllers locais primeiro. Todos os Controllers na zona primária são armazenados em cache em um grupo de backup. Se nenhum Controller local na zona satélite estiver disponível, tenta-se realizar o registro em Controllers na zona primária.
Como mostrado no exemplo a seguir, o arquivo de cache contém nomes de host e uma lista de IDs de segurança (ListofSIDs). O VDA não consulta os SIDs, o que reduz a carga do Active Directory.
Você pode recuperar o arquivo de cache com uma chamada WMI. No entanto, ele é armazenado em um local que é legível apenas pela conta SYSTEM.
Importante:
Esta informação é fornecida apenas para fins de esclarecimento. NÃO MODIFIQUE ESTE ARQUIVO. Quaisquer modificações neste arquivo ou pasta resultam em uma configuração não suportada.
Get-WmiObject -Namespace "Root\Citrix\DesktopInformation" -Class "Citrix_VirtualDesktopInfo" -Property "PersistentDataLocation"
Se você precisa configurar a ListofSIDs manualmente por motivos de segurança (não para reduzir a carga do Active Directory), não é possível usar o recurso de atualização automática. Para obter detalhes, consulte ListOfSIDs.
Exceção à prioridade de atualização automática
Embora a atualização automática geralmente tenha a prioridade mais alta de todos os métodos de registro de VDA e substitua as configurações de outros métodos, há uma exceção. Os elementos NonAutoListOfDDCs no cache especificam o método de configuração inicial do VDA. A atualização automática monitora essas informações. Se o método de registro inicial mudar, o processo de registro ignora a atualização automática e usa o próximo método configurado de prioridade mais alta. Esse processo é útil quando você move um VDA para outro site (por exemplo, durante a recuperação de desastres).
Considerações de configuração
Visualize uma configuração comum de registro do VDA.
Veja as etapas de registro do VDA.
Considere o seguinte ao configurar itens que podem afetar o registro do VDA.
Endereços do Controller ou Cloud Connector
Independentemente do método usado para especificar Controllers ou Cloud Connectors, a Citrix recomenda usar um endereço FQDN. Um endereço IP não é considerado uma configuração confiável, porque é mais fácil comprometer um IP do que um registro DNS. Se você preencher o ListofSIDs manualmente, poderá usar um IP em um ListofDDCs. Contudo, o FQDN continua a ser o recomendado.
Balanceamento de carga
Como observado anteriormente, o VDA distribui conexões automaticamente a todos os Controllers ou Cloud Connectors na ListofDDCs. A funcionalidade de failover e balanceamento de carga é incorporada ao Citrix Brokering Protocol (CBP). Se você especificar vários Controllers ou Cloud Connectors na sua configuração, o registro fará o failover entre eles automaticamente, se necessário. Com a atualização automática, o failover automático ocorre automaticamente para todos os VDAs.
Por motivos de segurança, você não pode usar um balanceador de carga de rede, como o Citrix ADC. O registro de VDA usa a autenticação mútua Kerberos, onde o cliente (VDA) deve provar sua identidade para o serviço (Controller). No entanto, o Controller ou Cloud Connector devem provar sua identidade para o VDA. Isso significa que o VDA e o Controller ou Cloud Connector estão atuando como servidor e cliente ao mesmo tempo. Como observado no início deste artigo, existem dois canais de comunicação: VDA para Controller/Cloud Connector e Controller/Cloud Connector para VDA.
Um componente nesse processo é chamado SPN (nome de entidade de serviço), que é armazenado como uma propriedade em um objeto de computador do Active Directory. Quando seu VDA se conecta a um Controller ou Cloud Connector, ele deve especificar com quem ele deseja se comunicar. Esse endereço é um SPN. Se você usar um IP com balanceamento de carga, a autenticação mútua Kerberos reconhece corretamente que o IP não pertence ao Controller ou Cloud Connector esperado.
Para obter mais informações, consulte:
A atualização automática substitui CNAME
O recurso de atualização automática substitui a função CNAME (alias DNS) das versões XenApp e XenDesktop anteriores à 7.x. A funcionalidade CNAME foi desativada, começando com o XenApp e XenDesktop 7. Use a atualização automática em vez de CNAME. (Se você precisar usar o CNAME, consulte CTX137960. Para que o alias de DNS funcione consistentemente, não use atualização automática e CNAME ao mesmo tempo.)
Grupos de Controllers/Cloud Connectors
Em determinados cenários, você pode processar Controllers ou Cloud Connectors em grupos, sendo um grupo o preferencial e o outro grupo usado para failover, se todos os Controllers/Cloud Connectors falharem. Lembre-se de que Controllers ou Cloud Connectors são selecionados aleatoriamente na lista, portanto, o agrupamento pode ajudar a forçar um uso preferencial.
Esses grupos são destinados ao uso em um único site (não em vários sites).
Use parênteses para especificar grupos de Controllers/Cloud Connectors. Por exemplo, com quatro Controllers (dois primários e dois backups), um agrupamento pode ser:
(XDC-001.cdz.lan XDC-002.cdz.lan) (XDC-003.cdz.lan XDC-004.cdz.lan)
Neste exemplo, os Controllers no primeiro grupo (001 e 002) são processados primeiro. Se os dois falharem, os Controllers no segundo grupo (003 e 004) são processados.
Para o XenDesktop 7.0 ou superior, há uma etapa extra que você precisa executar para usar o recurso de Grupos de registro. Você precisa proibir a política Enable Auto Update of Controller do Studio usando Prohibit.
ListOfSIDs
A lista de Controllers que um VDA pode contatar para o registro é a ListofDDCs. Um VDA também deve saber em quais Controllers confiar: os VDAs não confiam automaticamente nos Controllers na ListofDDCs. A ListofSIDs (IDs de segurança) identifica os Controllers confiáveis. Os VDAs tentam se registrar somente em Controllers confiáveis.
Na maioria dos ambientes, a ListofSIDs é gerado automaticamente a partir da ListofDDCs. Você pode usar um rastreamento CDF para ler a ListofSIDs.
Geralmente, não há necessidade de modificar manualmente a ListofSIDs. Existem várias exceções. As duas primeiras exceções não são mais válidas porque há tecnologias mais recentes disponíveis.
-
Funções separadas para Controllers: antes de as zonas serem introduzidas no XenApp e XenDesktop 7.7, a
ListofSIDsera configurada manualmente quando apenas um subconjunto de Controllers era usado para o registro. Por exemplo, se estivesse usando XDC-001 e XDC-002 como agentes XML, e XDC-003 e XDC-004 para o registro do VDA, você especificaria todos os Controllers naListofSIDs, e XDC-003 e XDC-004 naListofDDCs. Esa não é uma configuração típica ou recomendada. Não use em ambientes mais novos. Em vez disso, use zonas. -
Reduzir a carga do Active Directory: antes de o recurso de atualização automática ser introduzido no XenApp e XenDesktop 7.6, a
ListofSIDsera usada para reduzir a carga nos controladores de domínio. Ao preencher previamente aListofSIDs, pode-se ignorar a resolução de nomes DNS para SIDs. No entanto, o recurso de atualização automática elimina a necessidade desse trabalho, porque o cache persistente contém SIDs. A Citrix recomenda manter o recurso de atualização automática ativado. - Segurança: em alguns ambientes altamente protegidos, os SIDs dos Controllers confiáveis foram configurados manualmente para evitar possíveis ameaças à segurança por um servidor DNS comprometido. No entanto, se fizer isso, você também deve desativar o recurso de atualização automática. Caso contrário, a configuração do cache persistente é usada.
Portanto, a menos que você tenha um motivo específico, não modifique a ListofSIDs.
Se precisar modificar a ListofSIDs, crie uma chave de registro chamada ListOfSIDs (REG_SZ) em HKLM\Software\Citrix\VirtualDesktopAgent. O valor é uma lista de SIDs confiáveis, separados por espaço, se houver mais de um.
No exemplo a seguir, um Controller é usado para o registro do VDA (ListofDDCs), e dois Controllers são usados para intermediar (List OfSIDs).
Pesquisa de Controller durante o registro do VDA
Quando um VDA tenta se registrar, o Broker Agent executa primeiramente uma pesquisa de DNS no domínio local para assegurar que o Controller especificado pode ser acessado.
Se essa pesquisa inicial não encontrar o Controller, o Broker Agent pode iniciar uma consulta de fallback de cima para baixo no AD. Essa consulta pesquisa todos os domínios e é repetida frequentemente. Se o endereço do Controller for inválido (por exemplo, o administrador inseriu um FQDN incorreto ao instalar o VDA), a atividade da consulta pode levar a uma possível condição de negação de serviço distribuído (DDoS) no controlador de domínio.
A chave de registro a seguir controla se o Broker Agent usa a consulta de fallback de cima para baixo quando não consegue localizar um Controller durante a pesquisa inicial.
HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent
- Nome:
DisableDdcWildcardNameLookup - Tipo:
DWORD - Valor:
1(padrão) ou0
Quando definida como 1, a pesquisa de fallback é desativada. Se a pesquisa inicial do Controller falhar, o Broker Agent para de procurar. Essa é a configuração padrão.
Quando definida como 0, a pesquisa de fallback é ativada. Se a pesquisa inicial do Controller falhar, a pesquisa de fallback de cima para baixo é iniciada.
Sequenciamento de associação LDAP durante o registro do VDA usando um controlador de domínio somente leitura
Quando um VDA se registra em um controlador de domínio somente leitura (RODC), o Broker Agent deve selecionar quais associações ou associações do Light Directory Access Protocol (LDAP) ignorar. Para fazer essa seleção, o Broker Agent requer uma chave de registro adequada.
Se uma chave de registro não for fornecida ou o campo da chave de registro estiver vazio, o registro do VDA no RODC demorará mais, pois é necessário passar pela sequência de associação do LDAP original.
Para modificar a sequência de associação do LDAP, a chave de registro ListofIgnoredBindings foi adicionada a HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent. O uso de ListofIgnoredBindings permite modificar a sequência de associação do LDAP conforme necessário, e, assim, acelerar o registro do VDA em um RODC.
- Nome:
ListofIgnoredBindings - Tipo:
REG_SZ - Valores:
DefaultPath,DomainPath,PDCPath
O valor é uma lista de opções de caminho de associação, cada uma separada por uma vírgula. A chave de registro ignorará quaisquer valores que não reconheça como válidos.
Solucionar problemas de registro do VDA
Como observado anteriormente, um VDA deve ser registrado em um Delivery Controller ou Cloud Connector para ser considerado ao iniciar sessões intermediadas. Os VDAs não registrados podem resultar na subutilização de recursos disponíveis. Há várias razões para que um VDA não possa ser registrado, muitas das quais um administrador pode resolver. O Studio fornece informações sobre solução de problemas no assistente de criação de catálogo e depois que você cria um grupo de entrega.
-
Identificação de problemas durante a criação do catálogo de máquinas: no assistente de criação de catálogo, depois de você adicionar as máquinas existentes, a lista de nomes de contas de computador indica se as máquinas são adequadas para adicionar ao catálogo. Passe o mouse sobre o ícone ao lado de cada máquina para exibir uma mensagem informativa sobre a máquina.
Se a mensagem identificar uma máquina problemática, você pode remover essa máquina (usando o botão Remove) ou adicionar a máquina. Por exemplo, se uma mensagem indicar que as informações sobre uma máquina não puderam ser obtidas (talvez porque ela nunca foi registrada), você pode optar por adicionar a máquina.
O nível funcional de um catálogo controla quais recursos do produto estão disponíveis para as máquinas no catálogo. O uso de recursos introduzidos em novas versões de produtos pode exigir um novo VDA. Definir um nível funcional disponibiliza todos os recursos introduzidos nessa versão (e posterior, se o nível funcional não for alterado) para as máquinas no catálogo. No entanto, as máquinas nesse catálogo com uma versão anterior do VDA não podem se registrar.
-
Identificação de problemas após a criação de grupos de entrega: depois de criar um grupo de entrega, o Studio exibe detalhes sobre as máquinas associadas ao grupo.
O painel de detalhes de um grupo de entrega indica o número de máquinas que deveriam estar registradas, mas que não estão. Em outras palavras, pode haver uma ou mais máquinas que estão ligadas e não estão no modo de manutenção, mas que não estão registradas atualmente em um Controller. Ao visualizar uma máquina “não registrada, mas que deveria estar”, consulte a guia Troubleshoot no painel de detalhes para ver as possíveis causas e as ações corretivas recomendadas.
Mais informações sobre a solução de problemas de registro de VDA
-
Para obter mais informações sobre níveis funcionais, consulte Versões de VDA e níveis funcionais.
-
Para obter mais informações sobre a solução de problemas de registro VDA, consulte CTX136668.
-
Você também pode usar verificações de integridade do Citrix Scout para solucionar problemas de registro de VDA e início de sessão. Para obter detalhes, consulte Sobre verificações de integridade.
Neste artigo
- Introdução
- Métodos para configurar endereços do Controller ou Cloud Connector
- Atualização automática
- Considerações de configuração
- ListOfSIDs
- Pesquisa de Controller durante o registro do VDA
- Sequenciamento de associação LDAP durante o registro do VDA usando um controlador de domínio somente leitura
- Solucionar problemas de registro do VDA