Registro de VDA

Introdução

Nota:

Em um ambiente local, os VDAs se registram em um Delivery Controller. Em um ambiente de serviço 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) com um ou mais Controllers ou Cloud Connectors no site. O VDA encontra um Controller ou Connector verificando uma lista chamada ListofDDCs. O ListOfDDCs em um VDA contém entradas DNS que apontam esse VDA para Controllers ou Cloud Connectors no site. Para balanceamento de carga, o VDA distribui automaticamente as 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 sensível. Você está estabelecendo uma conexão entre o Controller ou Cloud Connector e o VDA. Para uma operação tão sensível, o comportamento esperado é rejeitar a conexão se tudo 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, então problemas de sincronização de tempo e associação de domínio são implacáveis. O Kerberos usa Nomes de Entidade de Serviço (SPNs), então você não pode usar IP\hostname balanceado por carga.
• Se um VDA não tiver informações precisas e atuais do Controller ou Cloud Connector à medida que você adiciona e remove Controllers (ou Cloud Connectors), o VDA poderá rejeitar inicializações de sessão que são intermediadas por um Controller ou Cloud Connector não listado. Entradas inválidas podem atrasar a inicialização do software do sistema de desktop virtual. Um VDA não aceitará uma conexão de um Controller ou Cloud Connector desconhecido e não confiável.

Além do ListofDDCs, o ListOfSIDs (IDs de Segurança) indica quais máquinas no ListofDDCs são confiáveis. O ListofSIDs pode ser usado para diminuir a carga no Active Directory ou para evitar possíveis ameaças de segurança de um servidor DNS comprometido. Para mais informações, consulte ListOfSIDs.

Se um ListofDDCs especificar mais de um Controller ou Cloud Connector, o VDA tenta se conectar a eles em ordem aleatória. Em uma implantação local, o ListofDDCs também pode conter grupos de Controller. O VDA tenta se conectar a cada Controller em um grupo antes de passar para outras entradas no ListofDDCs.

O Citrix Virtual Apps and Desktops™ testa automaticamente a conectividade com os Controllers ou Cloud Connectors configurados durante a instalação do VDA. Erros são exibidos se um Controller ou Cloud Connector não puder ser alcançado. Se você ignorar um aviso de que um Controller ou Cloud Connector não pode ser contatado (ou quando você não especifica endereços de Controller ou Cloud Connector durante a instalação do VDA), mensagens o lembrarão.

Métodos para configurar endereços de 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 deste cache local, a menos que uma alteração de configuração seja detectada.

A maneira mais fácil de recuperar essa lista durante os registros subsequentes é usando o recurso de atualização automática. A atualização automática é habilitada por padrão. Para mais informações, consulte Atualização automática.

Existem vários métodos para configurar endereços de 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 UO legada)
• Baseado em MCS (personality.ini)

Você especifica o método de registro inicial ao instalar um VDA. (Se você desabilitar 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 usar GPO para o registro inicial do VDA. Ele tem a prioridade mais alta. (Embora a atualização automática seja 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 as vantagens de centralização do uso da Política de Grupo para configuração.

Para especificar este método, conclua as duas etapas a seguir:

• Na página Delivery Controller do assistente de instalação do VDA, selecione Fazer mais tarde (avançado). O assistente o lembrará várias vezes para especificar 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.)
• Habilite ou desabilite o registro de VDA baseado em política por meio da política Citrix com a configuração Virtual Delivery Agent Settings > Controllers. (Se a segurança for sua principal prioridade, use a configuração Virtual Delivery Agent Settings > Controller SIDs.)

Esta configuração é armazenada em HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs).

Baseado em registro

Para especificar este método, conclua uma das seguintes etapas:

• Na página Delivery Controller no assistente de instalação do VDA, selecione Fazer manualmente. Em seguida, insira o FQDN de um Controller instalado e clique em Adicionar. 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 os FQDNs dos Controllers ou Cloud Connectors instalados.

Esta informação é armazenada no valor de registro ListOfDDCs sob a chave de registro HKLM\Software\Citrix\VirtualDesktopAgent ou HKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent.

Você também pode configurar esta 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 processamento condicional de diferentes Controllers ou Cloud Connectors, como: usar XDC-001 para nomes de computador que começam com XDW-001-).

Atualize a chave de registro ListOfDDCs, que lista os FQDNs de todos os Controllers ou Cloud Connectors no site. (Esta chave é o equivalente à OU do site do Active Directory.)

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)

Se o local de registro HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent contiver as chaves ListOfDDCs e FarmGUID, ListOfDDCs será usado para a descoberta de Controller ou Cloud Connector. FarmGUID está presente se uma OU de site foi especificada durante a instalação do VDA. (Isso pode ser usado em implantações legadas.)

Opcionalmente, atualize a chave de registro ListOfSIDs (para mais informações, consulte ListOfSIDs:

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)

Lembre-se: Se você também habilitar o registro de VDA baseado em política através da política Citrix, isso substituirá as configurações que você especificar durante a instalação do VDA, porque é um método de prioridade mais alta.

Baseado em OU do Active Directory (legado)

Este método é suportado principalmente para compatibilidade com versões anteriores e não é recomendado. Se você ainda o estiver usando, a Citrix sugere mudar para outro método.

Para especificar este método, conclua as duas etapas a seguir:

• Na página Delivery Controller no assistente de instalação do VDA, selecione Escolher locais do Active Directory.
• Use o script Set-ADControllerDiscovery.ps1 (disponível em cada Controller). Além disso, configure a entrada de registro FarmGuid em cada VDA para apontar para a OU correta. Esta configuração pode ser feita usando a Política de Grupo.

Baseado em MCS

Se você usa o MCS para provisionar VMs, o MCS configura a lista de Controllers ou Cloud Connectors. Este 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 atualizada.

Para especificar este método, na página Delivery Controller do assistente de instalação do VDA, selecione Deixar o Machine Creation Services™ fazer isso.

Revisão e recomendações

Como melhor prática:

• Use o método de registro de Política de Grupo para o registro inicial.
• Use a atualização automática (habilitada por padrão) para manter sua lista de Controllers atualizada.
• Em uma implantação multizona, use a Política de Grupo para a configuração inicial (com pelo menos dois Controllers ou Cloud Connectors). Aponte os VDAs para Controllers ou Cloud Connectors locais (em) sua zona. Use a atualização automática para mantê-los atualizados. A atualização automática otimiza automaticamente o ListofDDCs para VDAs em zonas satélites.

• Liste mais de um controller na chave de registro ListOfDDCs, separados por um espaço ou uma 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-->
  

• Certifique-se de que todos os valores listados em ListofDDCs mapeiem 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) é habilitada por padrão. É o método mais eficiente para manter seus registros de VDA atualizados. Embora não seja usada para o registro inicial, o software de atualização automática baixa e armazena o ListofDDCs em um cache persistente no VDA quando o registro inicial ocorre. Este processo é feito para cada VDA. O cache também contém informações de política da máquina, o que garante que as configurações de política sejam mantidas após as reinicializações.

A atualização automática é suportada ao usar MCS ou 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 este método:

• Habilite ou desabilite a atualização automática por meio de uma política Citrix que contenha a configuração Virtual Delivery Agent Settings > Enable auto update of Controllers. Esta configuração é habilitada por padrão.

Como funciona:

• Cada vez que um VDA se registra novamente (por exemplo, após a reinicialização de uma 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 uma alteração de política que afete o registro do VDA tiver ocorrido, o Controller ou 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 em sua lista mais recentemente armazenada em cache.
• Se um VDA receber uma lista que não inclui o Controller ou Cloud Connector ao qual ele está registrado (em outras palavras, esse Controller ou Cloud Connector foi removido do site), o VDA se registra novamente, escolhendo entre os Controllers ou Cloud Connectors em ListofDDCs.

Exemplo:

• Uma implantação tem três Controllers: A, B e C. Um VDA se registra com o Controller B (que foi especificado durante a instalação do VDA).
• Mais tarde, dois Controllers (D e E) são adicionados ao site. Em 90 minutos, os VDAs recebem listas atualizadas e, em seguida, aceitam conexões dos Controllers A, B, C, D e E. (A carga não é distribuída igualmente para todos os Controllers até que os VDAs sejam reiniciados.)
• Mais tarde ainda, o Controller B é movido para outro site. Em 90 minutos, os VDAs no site original recebem listas atualizadas porque houve uma alteração de Controller desde a última verificação. O VDA que originalmente se registrou com o 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 armazena em cache automaticamente 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, a tentativa de registro é feita com os Controllers na zona primária.

Conforme 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 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 informativos. 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ê precisar configurar manualmente ListofSIDs por motivos de segurança (distinto da redução da carga do Active Directory), você não poderá 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 maior prioridade 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 for alterado, o processo de registro ignora a atualização automática e usa o próximo método de prioridade configurado mais alto. Esse processo pode ser útil ao mover 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 de VDA.

Visualize as etapas de registro do VDA.

Considere o seguinte ao configurar itens que podem afetar o registro do VDA.

Endereços de Controller ou Cloud Connector

Independentemente do método que você usa 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, pois é mais fácil comprometer um IP do que um registro DNS. Se você preencher o ListofSIDs manualmente, poderá usar um IP em um ListofDDCs. No entanto, o FQDN ainda é recomendado.

Balanceamento de carga

Conforme observado anteriormente, o VDA distribui automaticamente as conexões entre todos os Controllers ou Cloud Connectors no ListofDDCs. A funcionalidade de failover e balanceamento de carga é incorporada ao Citrix Brokering Protocol (CBP). Se você especificar vários Controllers ou Cloud Connectors em sua configuração, o registro fará o failover automaticamente entre eles, 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 do VDA usa autenticação mútua Kerberos, onde o cliente (VDA) deve provar sua identidade ao serviço (Controller). No entanto, o Controller ou Cloud Connector deve provar sua identidade ao VDA. Isso significa que o VDA e o Controller ou Cloud Connector estão agindo como servidor e cliente ao mesmo tempo. Conforme 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 neste processo é chamado de Service Principal Name (SPN), 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 deseja se comunicar. Este endereço é um SPN. Se você usar um IP balanceado por carga, a autenticação mútua Kerberos reconhecerá corretamente que o IP não pertence ao Controller ou Cloud Connector esperado.

Para obter mais informações, consulte:

• Introdução ao Kerberos
• Autenticação mútua usando Kerberos

A atualização automática substitui o CNAME

O recurso de atualização automática substitui a função CNAME (DNS alias) das versões do XenApp e XenDesktop anteriores à 7.x. A funcionalidade CNAME é desabilitada a partir do XenApp e XenDesktop 7. Use a atualização automática em vez do CNAME. (Se você precisar usar o CNAME, consulte CTX137960. Para que o aliasing de DNS funcione de forma consistente, não use a atualização automática e o CNAME ao mesmo tempo.)

Grupos de Controller/Cloud Connector

Em certos cenários, você pode querer processar Controladores ou Cloud Connectors em grupos, com um grupo sendo preferencial e o outro grupo usado para failover se todos os Controladores/Cloud Connectors falharem. Lembre-se de que os Controladores ou Cloud Connectors são selecionados aleatoriamente da lista, então o agrupamento pode ajudar a impor o uso preferencial.

Esses grupos são destinados ao uso dentro de um único site (não em vários sites).

Use parênteses para especificar grupos de Controladores/Cloud Connectors. Por exemplo, com quatro Controladores (dois primários e dois de backup), um agrupamento pode ser:

(XDC-001.cdz.lan XDC-002.cdz.lan) (XDC-003.cdz.lan XDC-004.cdz.lan)

Neste exemplo, os Controladores do primeiro grupo (001 e 002) são processados primeiro. Se ambos falharem, os Controladores do segundo grupo (003 e 004) são processados.

Para o XenDesktop 7.0 ou superior, há uma etapa extra que você precisa realizar para usar o recurso Registration Groups. Você precisa Prohibit a política Enable Auto Update of Controller do Studio.

ListOfSIDs

A lista de Controladores que um VDA pode contatar para registro é a ListofDDCs. Um VDA também deve saber em quais Controladores confiar; os VDAs não confiam automaticamente nos Controladores na ListofDDCs. Os ListofSIDs (Security IDs) identificam os Controladores confiáveis. Os VDAs tentam se registrar apenas com Controladores confiáveis.

Na maioria dos ambientes, o ListofSIDs é gerado automaticamente a partir do ListofDDCs. Você pode usar um rastreamento CDF para ler o ListofSIDs.

Geralmente, não há necessidade de modificar manualmente o ListofSIDs. Existem várias exceções. As duas primeiras exceções não são mais válidas porque novas tecnologias estão disponíveis.

• Funções separadas para Controladores: Antes que as zonas fossem introduzidas no XenApp e XenDesktop 7.7, o ListofSIDs era configurado manualmente quando apenas um subconjunto de Controladores era usado para registro. Por exemplo, se você estivesse usando XDC-001 e XDC-002 como brokers XML, e XDC-003 e XDC-004 para registro de VDA, você especificava todos os Controladores no ListofSIDs, e XDC-003 e XDC-004 no ListofDDCs. Esta não é uma configuração típica ou recomendada. Não a use em ambientes mais recentes. Em vez disso, use zonas.
• Reduzindo a carga do Active Directory: Antes que o recurso de atualização automática fosse introduzido no XenApp e XenDesktop 7.6, o ListofSIDs era usado para reduzir a carga nos controladores de domínio. Ao pré-popular o ListofSIDs, a resolução de nomes DNS para SIDs pode ser ignorada. No entanto, o recurso de atualização automática elimina a necessidade desse trabalho, porque este cache persistente contém SIDs. A Citrix recomenda manter o recurso de atualização automática ativado.
• Segurança: Em alguns ambientes altamente seguros, os SIDs de Controladores confiáveis eram configurados manualmente para evitar possíveis ameaças de segurança de um servidor DNS comprometido. No entanto, se você fizer isso, também deverá desativar o recurso de atualização automática. Caso contrário, a configuração do cache persistente será usada.

Portanto, a menos que você tenha um motivo específico, não modifique o ListofSIDs.

Se você precisar modificar o 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ços se você tiver mais de um.

No exemplo a seguir, um Controlador é usado para registro de VDA (ListofDDCs), mas dois Controladores são usados para intermediação (List OfSIDs).

Pesquisa de Controlador durante o registro de VDA

Quando um VDA tenta se registrar, o Agente Broker primeiro executa uma pesquisa DNS no domínio local para garantir que o Controlador especificado possa ser alcançado.

Se essa pesquisa inicial não encontrar o Controlador, o Agente Broker pode iniciar uma consulta de fallback de cima para baixo no AD. Essa consulta pesquisa todos os domínios e se repete frequentemente. Se o endereço do Controlador for inválido (por exemplo, o administrador inseriu um FQDN incorreto ao instalar o VDA), a atividade dessa consulta pode potencialmente levar a uma condição de negação de serviço distribuída (DDoS) no controlador de domínio.

A seguinte chave de registro controla se o Agente Broker usa a consulta de fallback de cima para baixo quando não consegue localizar um Controlador durante a pesquisa inicial.

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent

• Nome: DisableDdcWildcardNameLookup
• Tipo: DWORD
• Valor: 0 (padrão) ou qualquer valor diferente de zero

Quando definido como 0, a pesquisa de fallback é ativada. Se a pesquisa inicial pelo Controller falhar, a pesquisa de fallback de cima para baixo é iniciada. Este é o comportamento padrão. No entanto, se definido como qualquer valor diferente de zero, a pesquisa de fallback é desativada. Se a pesquisa inicial pelo Controller falhar, o Broker Agent para de procurar.

Sequenciamento de ligação LDAP durante o registro de VDA usando um controlador de domínio somente leitura

Quando um VDA se registra com um controlador de domínio somente leitura (RODC), o Broker Agent deve selecionar qual ligação ou ligaçõ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 com o RODC leva mais tempo porque é necessário passar pela sequência de ligação LDAP original.

Para modificar a sequência de ligação 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 ligação LDAP conforme necessário e, assim, acelerar o registro do VDA com um RODC.

• Nome: ListofIgnoredBindings
• Tipo: REG_SZ
• Valores: DefaultPath, DomainPath, PDCPath

O valor é uma lista de opções de caminho de ligaçã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 de VDA

Conforme observado anteriormente, um VDA deve ser registrado com um Delivery Controller ou Cloud Connector para ser considerado ao iniciar sessões intermediadas. VDAs não registrados podem resultar na subutilização de recursos que de outra forma estariam disponíveis. Existem várias razões pelas quais um VDA pode não estar registrado, muitas das quais um administrador pode solucionar. O Studio fornece informações de solução de problemas no assistente de criação de catálogo e depois que você cria um Grupo de Entrega.

• Identificando problemas durante a criação do catálogo de máquinas: No assistente de criação de catálogo, depois de adicionar máquinas existentes, a lista de nomes de contas de computador indica se cada máquina é adequada para ser adicionada ao catálogo. Passe o mouse sobre o ícone ao lado de cada máquina para exibir uma mensagem informativa sobre essa máquina.

  Se a mensagem identificar uma máquina problemática, você pode remover essa máquina (usando o botão Remover) ou adicionar a máquina. Por exemplo, se uma mensagem indicar que as informações sobre uma máquina não foram obtidas (talvez porque ela nunca tenha sido registrada), você pode optar por adicionar a máquina de qualquer forma.

  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 do produto pode exigir um novo VDA. Definir um nível funcional torna todos os recursos introduzidos nessa versão (e posteriores, se o nível funcional não mudar) disponíveis para as máquinas no catálogo. No entanto, as máquinas nesse catálogo com uma versão anterior do VDA não poderão se registrar.

• Identificando 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 a esse grupo.

  O painel de detalhes de um Grupo de Entrega indica o número de máquinas que deveriam estar registradas, mas não estão. Em outras palavras, pode haver uma ou mais máquinas ligadas e que não estão em modo de manutenção, mas que não estão atualmente registradas em um Controller. Ao visualizar uma máquina “não registrada, mas que deveria estar”, revise a guia Solucionar problemas no painel de detalhes para possíveis causas e 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 de VDA, consulte CTX136668.

• Você também pode usar as verificações de integridade do Citrix Scout para solucionar problemas de registro de VDA e inicialização de sessão. Para obter detalhes, consulte Sobre as verificações de integridade.