Registro de VDA
Introdução
Observação:
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. A 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, portanto, problemas de sincronização de tempo e associação de domínio são implacáveis. O Kerberos usa Service Principal Names (SPNs), então você não pode usar IP\hostname com balanceamento de carga.
- Se um VDA não tiver informações precisas e atuais do Controller ou Cloud Connector ao adicionar e remover 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 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 Controller. O VDA tenta se conectar a cada Controller em um grupo antes de passar para outras entradas na 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 especificar 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 desse 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 obter 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 OU do Active Directory (descoberta de OU herdada)
- 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 lembra 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çãoVirtual Delivery Agent Settings > Controller SIDs.)
Essa configuração é armazenada em HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs).
Baseado em registro
Para especificar este método, conclua uma das etapas a seguir:
- Na página Delivery Controller do 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 os endereços deles.
- Para uma instalação de VDA por linha de comando, use a opção
/controllerse especifique os FQDNs dos Controllers ou Cloud Connectors instalados.
Essas informações são armazenadas 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 essa chave de registro manualmente ou usar as Preferências de Política de Grupo (GPP). Esse 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. (Essa 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. O FarmGUID está presente se uma OU do 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 obter 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 por meio da política Citrix, isso substituirá as configurações especificadas durante a instalação do VDA, pois é 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 do 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 registroFarmGuidem cada VDA para apontar para a OU correta. Essa 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. 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 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 da 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 multi-zona, 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 (na) sua zona. Use a atualização automática para mantê-los atualizados. A atualização automática otimiza automaticamente a
ListofDDCspara VDAs em zonas satélites. -
Liste mais de um Controller na chave de registro
ListOfDDCs, separados por um espaço, 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
ListofDDCsmapeiem para um nome de domínio totalmente qualificado (FQDN) 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 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 de política de 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 contém a configuração
Virtual Delivery Agent Settings > Enable auto update of Controllers. Essa 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 foi 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 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 armazenada em cache mais recentemente.
- Se um VDA receber uma lista que não inclui o Controller ou Cloud Connector com o 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 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).
- Posteriormente, 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 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 multi-zona, 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, o registro será tentado 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 e, portanto, 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 só pode ser lido pela conta SYSTEM.
Importante:
Esta informação é fornecida apenas para fins informativos. NÃO MODIFIQUE ESTE ARQUIVO. Qualquer modificação neste arquivo ou pasta resulta em uma configuração não suportada.
Get-WmiObject -Namespace "Root\Citrix\DesktopInformation" -Class "Citrix_VirtualDesktopInfo" -Property "PersistentDataLocation"
Se você precisar configurar manualmente a ListofSIDs por motivos de segurança (distinto da redução da carga do Active Directory), 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 prioridade mais alta de todos os métodos de registro de VDA e substitua as configurações para 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 ignorará a atualização automática e usará o próximo método de prioridade mais alta configurado. 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 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 a ListofSIDs manualmente, poderá usar um IP em uma 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 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 em sua configuração, o registro fará 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 nesse processo é chamado 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. Esse endereço é um SPN. Se você usar um IP com balanceamento de 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:
A atualização automática substitui o CNAME
O recurso de atualização automática substitui a função CNAME (alias DNS) 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 CNAME, consulte CTX137960. Para que o aliasing DNS funcione de forma consistente, não use atualização automática e CNAME ao mesmo tempo.)
Grupos de Controller/Cloud Connector
Em certos cenários, você pode querer processar Controllers ou Cloud Connectors em grupos, com um grupo sendo preferencial e o outro grupo usado para failover se todos os Controllers/Cloud Connectors falharem. Lembre-se de que os Controllers 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 Controllers/Cloud Connectors. Por exemplo, com quatro Controllers (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 Controllers do primeiro grupo (001 e 002) são processados primeiro. Se ambos falharem, os Controllers do segundo grupo (003 e 004) são processados.
Para XenDesktop 7.0 ou superior, há uma etapa extra que você precisa executar para usar o recurso “Registration Groups”. Você precisa “Proibir” a política “Enable Auto Update of Controller” do Studio.
ListOfSIDs
A lista de Controllers que um VDA pode contatar para registro é a ListofDDCs. Um VDA também deve saber em quais Controllers confiar, porque 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 apenas em Controllers confiáveis.
Na maioria dos ambientes, a ListofSIDs é gerada 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 tecnologias mais recentes estão disponíveis.
-
Funções separadas para Controllers: Antes da introdução das zonas no XenApp e XenDesktop 7.7, a
ListofSIDsera configurada manualmente quando apenas um subconjunto de Controllers era usado para registro. Por exemplo, se você estivesse usando XDC-001 e XDC-002 como XML brokers, e XDC-003 e XDC-004 para registro de VDA, você especificava todos os Controllers naListofSIDs, e XDC-003 e XDC-004 naListofDDCs. Esta não é uma configuração típica ou recomendada. Não a use em ambientes mais recentes. Em vez disso, use zonas. -
Redução da carga do Active Directory: Antes da introdução do recurso de atualização automática no XenApp e XenDesktop 7.6, a
ListofSIDsera usada para reduzir a carga nos controladores de domínio. Ao pré-preencher aListofSIDs, 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 esse cache persistente contém SIDs. A Citrix recomenda manter o recurso de atualização automática habilitado. - Segurança: Em alguns ambientes altamente seguros, os SIDs de Controllers 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á desabilitar o recurso de atualização automática. Caso contrário, a configuração de um cache persistente será usada.
Portanto, a menos que você tenha um motivo específico, não modifique a ListofSIDs.
Se você 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ços se você tiver mais de um.
No exemplo a seguir, um Controller é usado para registro de VDA (ListofDDCs), mas dois Controllers são usados para intermediação (List OfSIDs).
Pesquisa de Controller durante o registro do VDA
Quando um VDA tenta se registrar, o Broker Agent primeiro executa uma pesquisa DNS no domínio local para garantir que o Controller especificado possa ser alcançado.
Se essa pesquisa inicial não encontrar o Controller, o Broker Agent poderá iniciar uma consulta top-down de fallback no AD. Essa consulta pesquisa todos os domínios e se repete com frequência. Se o endereço do Controller for inválido (por exemplo, o administrador inseriu um FQDN incorreto ao instalar o VDA), a atividade dessa consulta poderá levar a uma condição de negação de serviço distribuída (DDoS) no controlador de domínio.
A chave de registro a seguir controla se o Broker Agent usa a consulta top-down de fallback quando não consegue localizar um Controller 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 é habilitada. Se a pesquisa inicial pelo Controller falhar, a pesquisa top-down de fallback será iniciada. Este é o comportamento padrão. No entanto, se definido como qualquer valor diferente de zero, a pesquisa de fallback é desabilitada. Se a pesquisa inicial pelo Controller falhar, o Broker Agent para de procurar.
Sequenciamento de vinculaçã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 qual vinculação ou vinculaçõ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 levará mais tempo porque é necessário passar pela sequência de vinculação LDAP original.
Para modificar a sequência de vinculaçã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 vinculaçã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 vinculação, cada uma separada por uma vírgula. A chave de registro ignora os valores que não reconhece como válidos.
Solucionar problemas de registro de VDA
Conforme observado anteriormente, um VDA deve ser registrado em 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 adicioná-la. 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 maneira.
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 devem ser registradas, mas não estão. Em outras palavras, pode haver uma ou mais máquinas ligadas e nã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.
Neste artigo
- Introdução
- Métodos para configurar endereços de Controller ou Cloud Connector
- Atualização automática
- Considerações de configuração
- ListOfSIDs
- Pesquisa de Controller durante o registro do VDA
- Sequenciamento de vinculação LDAP durante o registro do VDA usando um controlador de domínio somente leitura
- Solucionar problemas de registro de VDA