Registro de VDA
Introducción
Para poder utilizar un VDA, este debe registrarse en (o establecer comunicación con) uno o varios Controllers o Cloud Connectors del sitio. (En una implementación local de XenApp y XenDesktop, los VDA se registran en los Controllers. En una implementación de XenApp y XenDesktop Service, los VDA se registran en Cloud Connectors.) El VDA busca un Controller o un Connector en una lista llamada ListofDDCs. En un VDA, la lista ListOfDDCs consta de entradas DNS que le indican los Controllers o Cloud Connectors del sitio. Para conseguir un equilibrio de carga, el VDA distribuye automáticamente las conexiones entre todos los Controllers o Cloud Connectors de la lista.
¿Por qué es tan importante que el VDA se registre?
- Desde el punto de vista de la seguridad, el registro es una operación confidencial: se establece una conexión entre el Delivery Controller o Cloud Connector y el VDA. Para una operación confidencial, el comportamiento esperado es rechazar la conexión si algo no se cumple a la perfección. Se establecen dos canales independientes de comunicación: del VDA al Controller o Cloud Connector y del Controller o Cloud Connector al VDA. La conexión utiliza Kerberos, de modo que los problemas de sincronización horaria y los problemas de pertenencia a dominios son obstáculos que impiden la conexión. Kerberos utiliza nombres principales de servicio (SPN), por lo que no se puede usar IP ni nombre de host con carga equilibrada.
- Si un VDA no tiene una información precisa acerca de los Controllers o Cloud Connectors (una información que se actualiza a medida que agrega o quita Controllers o Cloud Connectors en un sitio), ese VDA podría rechazar inicios de sesión si interviene como intermediario un Controller o Cloud Connector que no conste en la información. Las entradas no válidas pueden retrasar el inicio del software del sistema de escritorios virtuales. Un VDA no puede aceptar una conexión desde un Controller o Cloud Connector desconocido con el que no haya una relación de confianza.
Además de la lista ListOfDDCs, la lista ListOfSIDs (identificadores de seguridad) indica qué máquinas de la lista ListOfDDCs son de confianza. La ListOfSIDs se puede utilizar para reducir la carga de Active Directory o para evitar las posibles amenazas de seguridad que presente un servidor DNS interceptado. Para obtener más información, consulte ListOfSIDs.
Si en una ListOfDDCs se especifica más de un Controller o Cloud Connector, el VDA intenta conectarse a ellos aleatoriamente. En una implementación loca, la lista ListOfDDCs también puede contener grupos de Controllers. El VDA intenta conectarse a cada Controller del grupo antes de pasar a otras entradas de la ListOfDDCs.
XenApp y XenDesktop comprueban automáticamente la conectividad a los Controllers o Cloud Connectors configurados durante la instalación de VDA. Si no se puede establecer conexión con un Controller o Cloud Connector, se muestran errores. Si ignora un mensaje de advertencia que indica que no se puede contactar con a un Controller o Cloud Connector (o si no especifica direcciones durante la instalación de VDA), los mensajes se lo recuerdan.
Métodos para configurar direcciones de Controller o Cloud Connector
El administrador es quien selecciona el método de configuración a utilizar cuando el VDA se registra por primera vez. Esto se denomina registro inicial. Durante ese registro inicial, se crea una memoria caché persistente en el VDA. Durante los registros subsiguientes, el VDA obtiene la lista de Controllers o Cloud Connectors desde esa memoria caché local, a menos que se detecte un cambio de configuración.
La forma más fácil de recuperar esa lista en los registros subsiguientes es mediante la función de actualización automática. De forma predeterminada, la actualización automática está habilitada. Para obtener más información, consulte Actualización automática.
Existen varios métodos para configurar direcciones de Controller o Cloud Connector en un VDA.
- Método basado en directivas (LGPO o GPO)
- Método basado en el Registro (manual, GPP, direcciones especificadas durante la instalación de VDA)
- Método basado en unidades organizativas de Active Directory (detección de OU antiguas)
- Método basado en MCS (personality.ini)
El método de registro inicial se indica cuando se instala un VDA. (Si se inhabilita la actualización automática, el método seleccionado durante la instalación del VDA también se utilizará para los registros posteriores.)
En la siguiente imagen, se muestra la página Delivery Controller del Asistente de instalación de VDA.
Método basado en directivas (LGPO o GPO)
Citrix recomienda usar GPO para el registro inicial del VDA. Tiene la prioridad más alta (aunque la actualización automática se haya indicado antes como la máxima prioridad, solo se usa después del registro inicial). El registro basado en directivas ofrece las ventajas de las directivas de grupo centralizadas para la configuración.
Para especificar este método, complete los dos siguientes pasos:
- En la página Delivery Controller del Asistente de instalación de VDA, seleccione Hacerlo más tarde (Avanzado). El asistente le recordará varias veces que indique direcciones de Controller, incluso aunque no las indique durante la instalación del VDA. (Se lo recuerda porque el registro del VDA es sumamente importante.)
- Habilite o inhabilite el registro del VDA basado en directivas mediante la directiva de Citrix desde
Virtual Delivery Agent Settings > Controllers. (Si la seguridad es su prioridad principal, utilice el parámetroVirtual Delivery Agent Settings > Controller SIDs.)
Esta configuración se almacena en HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs).
Método basado en el Registro
Para especificar este método, complete uno de los siguientes pasos:
- En la página Delivery Controller del Asistente de instalación de VDA, seleccione Hacerlo manualmente. Introduzca el nombre de dominio completo (FQDN) de un Controller instalado y, a continuación, haga clic en Agregar. Si ha instalado más Controllers, agregue sus direcciones respectivas.
- Para una instalación de VDA desde la línea de comandos, use la opción /controllers y especifique los FQDN de los Controllers o Cloud Connectors instalados.
Esta información se almacena en el valor de Registro ListOfDDCs en la clave de Registro HKLM\Software\Citrix\VirtualDesktopAgent o HKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent.
También puede configurar esta clave de Registro de forma manual o utilizar las preferencias de directiva de grupo (GPP). Este método puede ser preferible al método basado en las directivas (por ejemplo, si quiere condicionar el procesamiento de Controllers o Cloud Connectors diferentes, como usar XDC-001 para nombres de equipo que empiezan por XDW-001-).
Actualice la clave de Registro de ListOfDDCs, que enumera los FQDN de todos los Controllers o Cloud Connectors del sitio (esta clave es el equivalente de la OU del sitio de Active Directory).
HKEY_LOCAL_MACHINE\Software\Citrix\\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
Si la ubicación HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent del Registro contiene las claves ListOfDDCs y FarmGUID, ListOfDDCs se utiliza para la detección de Controllers o Cloud Connectors. FarmGUID está presente si la OU de un sitio se especificó durante la instalación del VDA (puede usarlo en implementaciones antiguas).
Si lo prefiere, puede actualizar la clave del registro de ListOfSIDs (para obtener más información, consulte ListOfSIDs):
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)
Recuerde:
Si habilita también el registro de VDA basado en directivas mediante la directiva de Citrix, esa configuración sobrescribe los parámetros especificados durante la instalación de VDA, porque es un método de mayor prioridad.
Método basado en unidades organizativas de Active Directory (antiguo)
Este no es el método recomendado; se admite principalmente para la compatibilidad con versiones anteriores. Si aún lo utiliza, Citrix recomienda cambiar a otro método.
Para especificar este método, complete los dos siguientes pasos:
- En la página Delivery Controller del Asistente de instalación de VDA, seleccione Elegir ubicaciones desde Active Directory.
- Use el script
Set-ADControllerDiscovery.ps1(disponible en cada Controller). Además, configure la entrada del Registro FarmGuid en cada VDA para que apunte a la OU correspondiente. Esta configuración puede configurarse mediante la directiva de grupo.
Para obtener más información, consulte Detección basada en unidades organizativas de Active Directory.
Método basado en MCS
Si solo va a usar MCS para aprovisionar las VM, puede indicar a MCS que configure la lista de Controllers o Cloud Connectors. Esta función funciona con la actualización automática: MCS inserta la lista de Controllers o Cloud Connectors en el archivo Personality.ini durante el aprovisionamiento inicial (al crear el catálogo de máquinas). La actualización automática mantiene la lista actualizada.
No se recomienda este método para entornos de gran tamaño. Puede usar este método si:
- Dispone de un entorno pequeño
- No mueve agentes VDA de un sitio a otro
- Solo usa MCS para aprovisionar las VM
- No quiere usar la directiva de grupo
Para especificar este método:
- En la página Delivery Controller del asistente de instalación de VDA, seleccione Dejar que Machine Creation Services lo haga.
Recomendaciones
Recomendaciones:
- Use el método del registro basado en la directiva de grupo para el registro inicial.
- Use la actualización automática (habilitada de forma predeterminada) para mantener actualizada su lista de Controllers.
- En una implementación de varias zonas, use la directiva de grupo para la configuración inicial (con al menos dos Controllers o Cloud Connectors). Apunte los agentes VDA a los Controllers o Cloud Connectors locales de la zona. Utilice la actualización automática para mantenerlos actualizados. La actualización automática optimiza automáticamente la lista ListOfDDCs para agentes VDA en las zonas satélite.
Actualización automática
Introducida desde XenApp y XenDesktop 7.6, la actualización automática está habilitada de forma predeterminada. Es el método más eficaz para mantener actualizados los registros de VDA. A pesar de que la actualización automática no se utilice para el registro inicial, el software de la actualización automática descarga y almacena la lista ListOfDDCs en una caché persistente en el VDA cuando se produce el registro inicial. Esto se lleva a cabo para cada VDA (esta memoria caché también contiene información de directivas de máquina que garantizan que las configuraciones de directiva se conserven después de reiniciar).
Se admite la actualización automática cuando se utiliza MCS o PVS para aprovisionar las máquinas, salvo para la caché del servidor PVS (que no es un caso frecuente porque no hay almacenamiento persistente para la caché de actualización automática).
Para especificar este método:
- Habilite o inhabilite la actualización automática a través de una directiva de Citrix que contenga la configuración:
Virtual Delivery Agent Settings > Enable auto update of Controllers. Esta configuración está habilitada de forma predeterminada.
Funcionamiento:
- La memoria caché se actualiza cada vez que el VDA se registra (por ejemplo, después de un reinicio de máquina). Todos los Controllers o Cloud Connectors consultan a su vez la base de datos del sitio cada 90 minutos. Si se ha agregado o quitado un Controller o Cloud Connector desde la última comprobación, o bien si se ha producido un cambio de directiva que afecte al registro de VDA, el Controller o Cloud Connector envía una lista actualizada a sus VDA registrados y la memoria caché se actualiza. El VDA acepta conexiones provenientes de todos los Controllers o Cloud Connectors de la lista más reciente que contenga en su memoria caché.
- Si un VDA recibe una lista que no incluye el Controller o Cloud Connector en el que está registrado (en otras palabras, el Controller o Cloud Connector se quitó del sitio), el VDA vuelve a registrarse en algún Controller o Cloud Connector que sí conste en la lista ListOfDDCs.
Por ejemplo:
- Una implementación contiene tres Controllers: A, B y C. Un VDA se registra en el Controller B (el cual se especificó durante la instalación del VDA).
- Más tarde, dos Controllers (D y E) se agregan al sitio. En los 90 minutos siguientes, los VDA reciben listas actualizadas y aceptan conexiones provenientes de los Controllers A, B, C, D y E (la carga no se reparte equitativamente entre todos los Controllers hasta que se reinicien los VDA).
- Posteriormente, se traslada al Controller B a otro sitio. En los 90 minutos siguientes, los VDA del sitio original reciben listas actualizadas porque se ha producido un cambio de Controllers desde la última comprobación. El VDA que se registró en su momento en el Controller B (que ya no está en la lista) vuelve a registrarse y elige entre los Controllers de la lista actual (A, C, D y E).
En una implementación de varias zonas, la actualización automática de una zona satélite almacena automáticamente en caché primero todos los Controllers locales. Todos los Controllers de la zona principal se almacenan en caché en un grupo de seguridad. Si no hay disponible ningún Controller local de la zona satélite, el VDA intenta registrarse en un Controller de la zona principal.
Como se muestra en el siguiente ejemplo, el archivo de memoria caché contiene nombres de host y una lista de identificadores de seguridad (ListOfSIDs). El VDA no consulta identificadores SID, lo que reduce la carga de Active Directory.
Puede obtener el archivo de caché con una llamada WMI. No obstante, ese archivo se guarda en una ubicación que solo puede leer la cuenta de sistema. Esta información se ofrece únicamente para fines informativos. NO MODIFIQUE ESTE ARCHIVO. Cualquier modificación en este archivo o carpeta resulta en una configuración no compatible.
Get-WmiObject -Namespace “Root\Citrix\DesktopInformation”
-Class “Citrix_VirtualDesktopInfo” -Property “PersistentDataLocation”
Si necesita configurar manualmente la lista ListOfSIDs por razones de seguridad (a diferencia de motivos como la reducción de carga de Active Directory), no puede usar la función de actualización automática. Para obtener más información, consulte ListOfSIDs.
Excepción a la prioridad de actualización automática
Aunque normalmente la actualización automática tiene la prioridad más alta de todos los métodos de registro de VDA y anula la configuración de los demás métodos, existe una excepción. Los elementos NonAutoListOfDDCs en la memoria caché especifican el método inicial de configuración de VDA. La actualización automática supervisa esta información. Si cambia el método de registro inicial, el proceso de registro omite la actualización automática y usa el siguiente método de configuración de prioridad más alta. Esto puede ser útil cuando se mueve un VDA a otro sitio (por ejemplo, durante la recuperación ante desastres).
Consideraciones sobre la configuración
Direcciones de Controller o Cloud Connector
Independientemente del método que utilice para especificar Controllers o Cloud Connectors, Citrix recomienda usar una dirección FQDN. Una dirección IP no se considera una configuración de confianza, porque es más fácil interceptar una IP que un registro DNS. Si rellena manualmente la lista ListOfSIDs, puede usar una IP en una lista ListOfDDCs. Aun así, se recomienda el FQDN.
Equilibrio de carga
Como se ha indicado anteriormente, el VDA distribuye automáticamente las conexiones entre todos los Controllers o Cloud Connectors de la lista ListOfDDCs. La funcionalidad de equilibrio de carga y conmutación por error se ha integrado en el protocolo Citrix Brokering Protocol (CBP). Si especifica varios Controllers o Cloud Connectors en la configuración, el registro conmuta por error automáticamente entre ellos, si fuera necesario. Con la actualización automática, la conmutación por error automática se produce automáticamente para todos los VDA.
Por motivos de seguridad, no puede usar ningún equilibrador de carga de red, como Citrix ADC. En el registro del VDA, se utiliza la autenticación mutua de Kerberos, donde el cliente (VDA) debe demostrar su identidad al servicio (Controller). No obstante, el Controller o Cloud Connector también debe demostrar su identidad al VDA. Eso significa que el VDA y el Controller o Cloud Connector actúan como cliente y servidor al mismo tiempo. Como se ha indicado al principio de este artículo, hay dos canales de comunicación: VDA a Controller o Cloud Connector y Controller o Cloud Connector a VDA.
Existe un componente en este proceso que se denomina Service Principal Name (nombre principal de servicio o SPN), que se almacena como una propiedad en un objeto de equipo de Active Directory. Cuando el VDA intenta conectarse a un Controller o Cloud Connector, debe especificar “con quién” quiere comunicarse. Esta dirección es un nombre SPN. Si utiliza una dirección IP con carga equilibrada, la autenticación mutua de Kerberos reconoce correctamente que la dirección IP no pertenece al Controller o Cloud Connector que debería.
Para obtener más información, consulte:
- Introducción a Kerberos: https://blogs.technet.microsoft.com/askds/2008/03/06/kerberos-for-the-busy-admin/
- Autenticación mutua mediante Kerberos: https://docs.microsoft.com/en-us/windows/win32/ad/mutual-authentication-using-kerberos?redirectedfrom=MSDN
La actualización automática reemplaza CNAME
La función de actualización automática sustituye a la función CNAME (alias de DNS) desde versiones de XenApp y XenDesktop anteriores a 7.x. La función CNAME se inhabilitó a partir de XenApp y XenDesktop 7. Utilice la actualización automática en lugar de CNAME. (Si le es necesario usar CNAME, consulte CTX137960. Para que el alias de DNS funcione de manera coherente, no use la actualización automática y CNAME al mismo tiempo.)
Grupos de Controllers o Cloud Connectors
Es posible que quiera procesar Controllers o Cloud Connectors en grupos. Con los grupos, se prefiere un grupo, y el otro grupo se utiliza para conmutaciones por error si fallan todos los Controllers o Cloud Connectors. Recuerde que los Controllers o Cloud Connectors se seleccionan aleatoriamente de la lista; por tanto, agruparlos puede fomentar la preferencia de un grupo sobre otro.
Use paréntesis para especificar grupos de Controllers o Cloud Connectors. Por ejemplo, con cuatro Controllers (dos primarios y dos de seguridad), puede tener la siguiente agrupación:
(XDC-001.cdz.lan XDC-002.cdz.lan) (XDC-003.cdz.lan XDC-004.cdz.lan).
En este ejemplo, los Controllers del primer grupo (001 y 002) se procesan primero. Si ambos fallan, se procesan los Controllers del segundo grupo (003 y 004).
ListOfSIDs
La lista de Controllers con los que un VDA puede contactar para el registro se llama ListOfDDCs. Asimismo, un VDA también debe saber en qué Controllers puede confiar; los VDA no confían automáticamente en los Controllers de la lista ListOfDDCs. La lista ListOfSIDs (identificadores de seguridad) identifica a los Controllers de confianza. Los agentes VDA solo intentarán registrarse en los Controllers de confianza.
En la mayoría de los entornos, la lista ListOfSIDs se genera automáticamente a partir de la lista ListOfDDCs. Puede usar un rastro CDF para leer la lista ListOfSIDs.
Por lo general, no es necesario modificar manualmente la lista ListOfSIDs. Sin embargo, existen varias excepciones a ello. Las dos primeras excepciones ya no son válidas, porque están disponibles tecnologías más recientes.
- Separar roles para los Controllers: Antes de que se introdujeran las zonas en XenApp y XenDesktop 7.7, la lista ListOfSIDs se configuraba manualmente cuando solo se utilizaba un subconjunto de los Controllers para el registro. Por ejemplo: si se utilizaba XDC-001 y XDC-002 como brokers XML, y XDC-003 y XDC-004 para el registro de VDA, se especificaban todos los Controllers en la lista ListOfSIDs, y XDC-003 y XDC-004 se indicaban en la lista ListOfDDCs. Esta no es una configuración típica ni recomendada, y no debe utilizarse en entornos más recientes. En su lugar, use las zonas.
- Reducir la carga de Active Directory: Antes de que se introdujera la función de actualización automática en XenApp y XenDesktop 7.6, la lista ListOfSIDs se utilizaba para reducir la carga de los controladores de dominio. Al prerrellenar la lista ListOfSIDs, es posible que se omita la resolución de nombres DNS en identificadores SID. No obstante, la función de actualización automática elimina la necesidad de esta tarea, porque la memoria caché persistente contiene los identificadores SID. Citrix recomienda mantener habilitada la función de actualización automática.
- Seguridad: En algunos entornos muy protegidos, los SID de los Controllers de confianza se configuraban manualmente para evitar las posibles amenazas a la seguridad que podía representar un servidor DNS interceptado. Sin embargo, si hace esto, también debe desactivar la función de actualización automática. De lo contrario, se utiliza la configuración de la memoria caché persistente.
Por lo tanto, a menos que tenga un motivo concreto, no modifique la lista ListOfSIDs.
Si le es necesario modificar la lista ListOfSIDs, cree una clave de Registro denominada ListOfSIDs (REG_SZ) en HKLM\Software\Citrix\VirtualDesktopAgent. El valor es una lista de los SID de confianza, separados por espacios, si tiene más de uno.
En el siguiente ejemplo, se usa un Controller para el registro de VDA (ListOfDDCs), pero se utilizan dos Controllers para la intermediación (ListOfSIDs).
Búsqueda del Controller durante el registro de VDA
Cuando un VDA intenta registrarse, Broker Agent realiza primero una búsqueda DNS en el dominio local para asegurarse de que se puede acceder al Controller especificado.
Si en esa búsqueda inicial no se encuentra el Controller, Broker Agent puede iniciar una consulta de reserva de arriba hacia abajo en AD. Esa consulta examina todos los dominios y se repite con frecuencia. Si la dirección del Controller no es válida (por ejemplo, el administrador introdujo un FQDN incorrecto al instalar el VDA), la actividad de esa consulta puede provocar una condición de denegación de servicio distribuido (DDoS) en el controlador de dominio.
La siguiente clave del Registro controla si Broker Agent utiliza la consulta de reserva de arriba hacia abajo cuando no puede encontrar un Controller durante la búsqueda inicial.
HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent
- Name:
DisableDdcWildcardNameLookup - Tipo:
DWORD - Valor:
1(predeterminado) o0
Cuando se establece en 1, la búsqueda de reserva está inhabilitada. Si la búsqueda inicial del Controller falla, Broker Agent deja de buscar. Esta es la opción predeterminada.
Cuando se establece en 0, la búsqueda de reserva está habilitada. Si la búsqueda inicial del Controller falla, se inicia la búsqueda de reserva de arriba hacia abajo.
Solucionar problemas en el registro de VDA
Como se ha indicado anteriormente, un VDA debe registrarse en un Delivery Controller para que se le tenga en cuenta al iniciar sesiones con broker. Los VDA no registrados pueden derivar en una infrautilización de los recursos disponibles. Existen diversos motivos por los que un VDA puede no registrarse, y un administrador puede solucionar muchos de ellos. Studio ofrece información para solucionar problemas en el Asistente para la creación de catálogos, después de que cree un grupo de entrega.
Identificar problemas durante la creación del catálogo de máquinas:
En el Asistente para la creación de catálogos de máquinas, después de agregar las máquinas existentes, la lista de nombres de cuenta de equipo indicará si cada máquina es adecuada para agregarla al catálogo. Pase el puntero sobre el icono situado junto a cada máquina para ver un mensaje informativo sobre esa máquina.
Si el mensaje indica una máquina problemática, puede quitarla (mediante el botón Quitar) o agregarla. Por ejemplo, si un mensaje indica que no se ha podido obtener información acerca de una máquina (posiblemente porque nunca se registró en un Delivery Controller), puede optar por agregarla de todos modos.
Con el nivel funcional de un catálogo, decide qué funciones de producto están disponibles para las máquinas del catálogo. Para poder usar las funciones introducidas en las nuevas versiones de producto, es posible que necesite un nuevo VDA. Establecer un nivel funcional permite que todas las funcionalidades introducidas en esa versión (y versiones posteriores, si el nivel funcional no cambia) estén disponibles para las máquinas del catálogo. Sin embargo, las máquinas de ese catálogo que tengan una versión anterior de VDA no podrán registrarse.
Identificar problemas después de crear los grupos de entrega:
Después de crear un grupo de entrega, Studio muestra información sobre las máquinas asociadas a ese grupo. El panel de detalles de un grupo de entrega indica la cantidad de máquinas que deberían estar registradas, pero no se han registrado. En otras palabras, una o varias máquinas que están activadas y no están en modo de mantenimiento, pero no están actualmente registradas en el Controller. Al ver una máquina que “no está registrada, pero debería estarlo”, consulte el panel de detalles de la ficha Solución de problemas para buscar las posibles causas y las acciones correctivas recomendadas.
Para obtener más información acerca de los niveles funcionales, consulte la sección Versiones de VDA y niveles funcionales en Crear catálogos de máquinas.
Para obtener más información sobre la solución de problemas de registro de VDA, consulte CTX136668.
También puede usar Citrix Health Assistant para solucionar problemas de inicio de sesiones y registro de VDA. Para obtener más información, consulte CTX207624.
En este artículo
- Introducción
- Métodos para configurar direcciones de Controller o Cloud Connector
- Método basado en directivas (LGPO o GPO)
- Método basado en el Registro
- Método basado en unidades organizativas de Active Directory (antiguo)
- Método basado en MCS
- Recomendaciones
- Actualización automática
- Consideraciones sobre la configuración
- ListOfSIDs
- Búsqueda del Controller durante el registro de VDA
- Solucionar problemas en el registro de VDA