Registro de VDA

Introducción

Nota:

En un entorno local, los VDA se registran con un Delivery Controller. En un entorno de servicio de Citrix Cloud, los VDA se registran con un Cloud Connector. En un entorno híbrido, algunos VDA se registran con un Delivery Controller, mientras que otros lo hacen con un Cloud Connector.

Antes de que se pueda usar un VDA, debe registrarse (establecer comunicación) con uno o varios Controllers o Cloud Connectors del sitio. El VDA encuentra un Controller o Connector comprobando una lista llamada ListofDDCs. La ListOfDDCs de un VDA contiene entradas DNS que dirigen ese VDA a los Controllers o Cloud Connectors del sitio. Para el 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 el registro de VDA?

• Desde una perspectiva de seguridad, el registro es una operación delicada. Se establece una conexión entre el Controller o Cloud Connector y el VDA. Para una operación tan delicada, el comportamiento esperado es rechazar la conexión si todo no está en perfecto estado. En efecto, se establecen dos canales de comunicación separados: VDA a Controller o Cloud Connector, y Controller o Cloud Connector a VDA. La conexión utiliza Kerberos, por lo que los problemas de sincronización de hora y pertenencia a dominios son implacables. Kerberos utiliza nombres principales de servicio (SPN), por lo que no se puede usar IP\hostname con equilibrio de carga.
• Si un VDA no tiene información precisa y actual del Controller o Cloud Connector a medida que se agregan y eliminan Controllers (o Cloud Connectors), el VDA podría rechazar los inicios de sesión intermediados por un Controller o Cloud Connector no listado. Las entradas no válidas pueden retrasar el inicio del software del sistema de escritorio virtual. Un VDA no aceptará una conexión de un Controller o Cloud Connector desconocido y no confiable.

Además de la ListofDDCs, la ListOfSIDs (identificadores de seguridad) indica qué máquinas de la ListofDDCs son de confianza. La ListofSIDs se puede utilizar para disminuir la carga en Active Directory o para evitar posibles amenazas de seguridad de un servidor DNS comprometido. Para obtener más información, consulte ListOfSIDs.

Si una ListofDDCs especifica más de un Controller o Cloud Connector, el VDA intenta conectarse a ellos en orden aleatorio. En una implementación local, la ListofDDCs también puede contener grupos de Controllers. El VDA intenta conectarse a cada Controller de un grupo antes de pasar a otras entradas de la ListofDDCs.

Citrix Virtual Apps and Desktops™ prueba automáticamente la conectividad con los Controllers o Cloud Connectors configurados durante la instalación del VDA. Se muestran errores si no se puede acceder a un Controller o Cloud Connector. Si ignora una advertencia de que no se puede contactar con un Controller o Cloud Connector (o si no especifica las direcciones del Controller o Cloud Connector durante la instalación del VDA), se le recordará con mensajes.

Métodos para configurar las direcciones de Controller o Cloud Connector

El administrador elige el método de configuración que se utilizará cuando el VDA se registre por primera vez (el registro inicial). Durante el registro inicial, se crea una caché persistente en el VDA. Durante los registros posteriores, el VDA recupera la lista de Controllers o Cloud Connectors de esta caché local, a menos que se detecte un cambio de configuración.

La forma más sencilla de recuperar esa lista durante los registros posteriores es mediante la función de actualización automática. La actualización automática está habilitada de forma predeterminada. Para obtener más información, consulte Actualización automática.

Existen varios métodos para configurar las direcciones de Controller o Cloud Connector en un VDA.

• Basado en políticas (LGPO o GPO)
• Basado en el registro (manual, Preferencias de directiva de grupo (GPP), especificado durante la instalación del VDA)
• Basado en la UO de Active Directory (detección de UO heredada)
• Basado en MCS (personality.ini)

Usted especifica el método de registro inicial al instalar un VDA. (Si inhabilita la actualización automática, el método que seleccione durante la instalación del VDA se utilizará para los registros posteriores.)

El siguiente gráfico muestra la página de Delivery Controller del asistente de instalación del VDA.

Página de Delivery Controller en el asistente de instalación del VDA(/es-es/citrix-virtual-apps-desktops/2507-ltsr/media/vda-install-controllers-all.png)

Basado en políticas (LGPO\GPO)

Citrix® recomienda usar GPO para el registro inicial del VDA. Tiene la prioridad más alta. (Aunque la actualización automática aparece como la prioridad más alta, la actualización automática se utiliza solo después del registro inicial.) El registro basado en políticas ofrece las ventajas de centralización del uso de la Directiva de grupo para la configuración.

Para especificar este método, complete los dos pasos siguientes:

• En la página de Delivery Controller del asistente de instalación del VDA, seleccione Hacerlo más tarde (avanzado). El asistente le recordará varias veces que especifique las direcciones de Controller, aunque no las esté especificando durante la instalación del VDA. (El registro del VDA es así de importante.)
• Habilite o inhabilite el registro de VDA basado en políticas a través de la directiva de Citrix con la configuración Virtual Delivery Agent Settings > Controllers. (Si la seguridad es su máxima prioridad, utilice la configuración Virtual Delivery Agent Settings > Controller SIDs.)

Esta configuración se almacena en HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs).

Basado en el registro

Para especificar este método, complete uno de los pasos siguientes:

• En la página Delivery Controller del asistente de instalación de VDA, seleccione Hacerlo manualmente. A continuación, introduzca el FQDN de un Controller instalado y haga clic en Agregar. Si ha instalado más Controllers, añada sus direcciones.
• Para una instalación de VDA desde la línea de comandos, utilice la opción /controllers y especifique los FQDN de los Controllers o Cloud Connectors instalados.

Esta información se almacena en el valor del registro ListOfDDCs bajo la clave del registro HKLM\Software\Citrix\VirtualDesktopAgent o HKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent.

También puede configurar esta clave del registro manualmente o utilizar las Preferencias de directiva de grupo (GPP). Este método podría ser preferible al método basado en directivas (por ejemplo, si desea un procesamiento condicional de diferentes Controllers o Cloud Connectors, como: usar XDC-001 para nombres de equipo que comiencen por XDW-001-).

Actualice la clave del registro 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 del registro HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent contiene las claves ListOfDDCs y FarmGUID, se utiliza ListOfDDCs para la detección de Controllers o Cloud Connectors. FarmGUID está presente si se especificó una OU del sitio durante la instalación del VDA. (Esto podría utilizarse en implementaciones heredadas).

Opcionalmente, actualice la clave del registro ListOfSIDs (para obtener más información, consulte ListOfSIDs:

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

Recuerde: Si también habilita el registro de VDA basado en directivas a través de la directiva de Citrix, esta anula la configuración que especifique durante la instalación del VDA, ya que es un método de mayor prioridad.

Basado en OU de Active Directory (heredado)

Este método se admite principalmente por compatibilidad con versiones anteriores y no se recomienda. Si aún lo utiliza, Citrix sugiere cambiar a otro método.

Para especificar este método, complete los dos pasos siguientes:

• En la página Delivery Controller del asistente de instalación de VDA, seleccione Elegir ubicaciones de Active Directory.
• Utilice 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 correcta. Esta configuración se puede configurar mediante la Directiva de grupo.

Basado en MCS

Si utiliza MCS para aprovisionar máquinas virtuales, MCS configura la lista de Controllers o Cloud Connectors. Esta función funciona con la actualización automática. Al crear el catálogo, MCS inyecta la lista de Controllers o Cloud Connectors en el archivo Personality.ini durante el aprovisionamiento inicial. La actualización automática mantiene la lista actualizada.

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.

Revisión y recomendaciones

Como práctica recomendada:

• Utilice el método de registro de directivas de grupo para el registro inicial.
• Utilice la actualización automática (habilitada de forma predeterminada) para mantener actualizada la lista de Controllers.
• En una implementación multizona, utilice la Directiva de grupo para la configuración inicial (con al menos dos Controllers o Cloud Connectors). Dirija los VDA a los Controllers o Cloud Connectors locales (en) su zona. Utilice la actualización automática para mantenerlos actualizados. La actualización automática optimiza automáticamente el ListofDDCs para los VDA en zonas satélite.

• Enumere más de un controlador en la clave de registro ListOfDDCs, separados por un espacio, para evitar problemas de registro si un Controller no está disponible. Por ejemplo:

   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-->
  

• Asegúrese de que todos los valores enumerados en ListofDDCs se asignen a un nombre de dominio completo válido para evitar retrasos en el registro de inicio.

Actualización automática

La actualización automática (introducida en XenApp y XenDesktop 7.6) está habilitada de forma predeterminada. Es el método más eficaz para mantener actualizados los registros de VDA. Aunque no se utiliza para el registro inicial, el software de actualización automática descarga y almacena el ListofDDCs en una caché persistente en el VDA cuando se produce el registro inicial. Este proceso se realiza para cada VDA. La caché también contiene información de la directiva de máquina, lo que garantiza que la configuración de la directiva se conserve entre reinicios.

La actualización automática es compatible cuando se utiliza MCS o Citrix Provisioning™ para aprovisionar máquinas, excepto para la caché del lado del servidor de Citrix Provisioning. La caché del lado del servidor no es un escenario común porque no hay almacenamiento persistente para la caché de actualización automática.

Para especificar este método:

• Habilite o deshabilite 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.

Cómo funciona:

• Cada vez que un VDA se vuelve a registrar (por ejemplo, después de reiniciar una máquina), la caché se actualiza. Cada Controller o Cloud Connector también comprueba 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 si se ha producido un cambio de directiva que afecta al registro de VDA, el Controller o Cloud Connector envía una lista actualizada a sus VDA registrados y la caché se actualiza. El VDA acepta conexiones de todos los Controllers o Cloud Connectors de su lista almacenada en caché más reciente.
• Si un VDA recibe una lista que no incluye el Controller o Cloud Connector con el que está registrado (es decir, ese Controller o Cloud Connector se eliminó del sitio), el VDA se vuelve a registrar, eligiendo entre los Controllers o Cloud Connectors de la ListofDDCs.

Ejemplo:

• Una implementación tiene tres Controllers: A, B y C. Un VDA se registra con el Controller B (que se especificó durante la instalación del VDA).
• Más tarde, se añaden dos Controllers (D y E) al sitio. En 90 minutos, los VDA reciben listas actualizadas y, a continuación, aceptan conexiones de los Controllers A, B, C, D y E. (La carga no se distribuye por igual a todos los Controllers hasta que se reinician los VDA).
• Más tarde, el Controller B se traslada a otro sitio. En 90 minutos, los VDA del sitio original reciben listas actualizadas porque ha habido un cambio de Controller desde la última comprobación. El VDA que se registró originalmente con el Controller B (que ya no está en la lista) se vuelve a registrar, eligiendo entre los Controllers de la lista actual (A, C, D y E).

En una implementación multizona, la actualización automática en una zona satélite almacena automáticamente en caché todos los Controllers locales primero. Todos los Controllers de la zona principal se almacenan en caché en un grupo de respaldo. Si no hay Controllers locales disponibles en la zona satélite, se intenta el registro con los Controllers de la zona principal.

Como se muestra en el siguiente ejemplo, el archivo de caché contiene nombres de host y una lista de identificadores de seguridad (ListofSIDs). El VDA no consulta los SID y, por lo tanto, reduce la carga de Active Directory.

Puede recuperar el archivo de caché con una llamada WMI. Sin embargo, se almacena en una ubicación que solo puede leer la cuenta SYSTEM.

Importante:

Esta información se proporciona únicamente con fines informativos. NO MODIFIQUE ESTE ARCHIVO. Cualquier modificación de este archivo o carpeta dará lugar a una configuración no admitida.

Get-WmiObject -Namespace "Root\Citrix\DesktopInformation" -Class "Citrix_VirtualDesktopInfo" -Property "PersistentDataLocation"

Si necesita configurar manualmente la ListofSIDs por motivos de seguridad (a diferencia de reducir la carga de Active Directory), no puede utilizar 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 la actualización automática suele tener la máxima prioridad entre todos los métodos de registro de VDA y anula la configuración de otros métodos, existe una excepción. Los elementos NonAutoListOfDDCs de la caché especifican el método de configuración inicial del VDA. La actualización automática supervisa esta información. Si el método de registro inicial cambia, el proceso de registro omite la actualización automática y utiliza el método de prioridad configurado más alto siguiente. Este proceso puede ser útil al mover un VDA a otro sitio (por ejemplo, durante la recuperación ante desastres).

Consideraciones de configuración

Vea una configuración común de registro de VDA.

Vea los pasos de registro de VDA.

Tenga en cuenta lo siguiente al configurar elementos que pueden afectar al registro de VDA.

Direcciones de Controller o Cloud Connector

Independientemente del método que utilice para especificar los Controllers o Cloud Connectors, Citrix recomienda usar una dirección FQDN. Una dirección IP no se considera una configuración de confianza, ya que es más fácil comprometer una IP que un registro DNS. Si rellena ListofSIDs manualmente, puede usar una IP en ListofDDCs. Sin embargo, se sigue recomendando FQDN.

Equilibrio de carga

Como se indicó anteriormente, el VDA distribuye automáticamente las conexiones entre todos los Controllers o Cloud Connectors en ListofDDCs. La funcionalidad de conmutación por error y equilibrio de carga está integrada en el Protocolo de intermediación de Citrix (CBP). Si especifica varios Controllers o Cloud Connectors en su configuración, el registro conmuta automáticamente por error entre ellos, si es necesario. Con la actualización automática, la conmutación por error automática se produce automáticamente para todos los VDA.

Por razones de seguridad, no puede utilizar un equilibrador de carga de red, como Citrix ADC. El registro de VDA utiliza la autenticación mutua Kerberos, donde el cliente (VDA) debe probar su identidad al servicio (Controller). Sin embargo, el Controller o Cloud Connector debe probar su identidad al VDA. Esto significa que el VDA y el Controller o Cloud Connector actúan como servidor y cliente al mismo tiempo. Como se indicó al principio de este artículo, hay dos canales de comunicación: VDA a Controller/Cloud Connector y Controller/Cloud Connector a VDA.

Un componente en este proceso se denomina Nombre principal de servicio (SPN), que se almacena como una propiedad en un objeto de equipo de Active Directory. Cuando su VDA se conecta a un Controller o Cloud Connector, debe especificar con quién quiere comunicarse. Esta dirección es un SPN. Si utiliza una IP con equilibrio de carga, la autenticación mutua Kerberos reconoce correctamente que la IP no pertenece al Controller o Cloud Connector esperado.

Para obtener más información, consulte:

• Introducción a Kerberos
• Autenticación mutua mediante Kerberos

La actualización automática reemplaza a CNAME

La función de actualización automática reemplaza la función CNAME (alias DNS) de las versiones de XenApp y XenDesktop anteriores a la 7.x. La funcionalidad CNAME está inhabilitada a partir de XenApp y XenDesktop 7. Utilice la actualización automática en lugar de CNAME. (Si debe usar CNAME, consulte CTX137960. Para que el alias DNS funcione de forma coherente, no utilice la actualización automática y CNAME al mismo tiempo).

Grupos de Controller/Cloud Connector

En algunos escenarios, es posible que desee procesar los Controllers o Cloud Connectors en grupos, con un grupo preferido y el otro grupo utilizado para la conmutación por error si todos los Controllers/Cloud Connectors fallan. Recuerde que los Controllers o Cloud Connectors se seleccionan aleatoriamente de la lista, por lo que la agrupación puede ayudar a aplicar un uso preferencial.

Estos grupos están pensados para usarse dentro de un solo sitio (no en varios sitios).

Utilice paréntesis para especificar grupos de Controllers/Cloud Connectors. Por ejemplo, con cuatro Controllers (dos principales y dos de respaldo), una agrupación podría ser:

(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).

Para XenDesktop 7.0 o posterior, hay un paso adicional que debe realizar para usar la función Grupos de registro. Debe Prohibir la directiva Habilitar actualización automática de Controller desde Studio.

ListOfSIDs

La lista de Controllers a los que un VDA puede contactar para el registro es la ListofDDCs. Un VDA también debe saber en qué Controllers confiar, ya que los VDA no confían automáticamente en los Controllers de la ListofDDCs. Los ListofSIDs (identificadores de seguridad) identifican los Controllers de confianza. Los VDA intentan registrarse solo con Controllers de confianza.

En la mayoría de los entornos, la ListofSIDs se genera automáticamente a partir de la ListofDDCs. Puede usar un seguimiento CDF para leer la ListofSIDs.

Generalmente, no es necesario modificar manualmente la ListofSIDs. Hay varias excepciones. Las dos primeras excepciones ya no son válidas porque hay tecnologías más nuevas disponibles.

• Roles separados para los Controllers: Antes de que se introdujeran las zonas en XenApp y XenDesktop 7.7, el ListofSIDs se configuraba manualmente cuando solo se usaba un subconjunto de Controllers para el registro. Por ejemplo, si utilizaba XDC-001 y XDC-002 como intermediarios XML, y XDC-003 y XDC-004 para el registro de VDA, especificaba todos los Controllers en el ListofSIDs, y XDC-003 y XDC-004 en el ListofDDCs. Esta no es una configuración típica ni recomendada. No la utilice en entornos más recientes. En su lugar, utilice zonas.
• Reducción de la carga de Active Directory: Antes de que se introdujera la función de actualización automática en XenApp y XenDesktop 7.6, el ListofSIDs se utilizaba para reducir la carga en los controladores de dominio. Al rellenar previamente el ListofSIDs, se puede omitir la resolución de nombres DNS a SID. Sin embargo, la función de actualización automática elimina la necesidad de este trabajo, ya que esta caché persistente contiene SID. Citrix recomienda mantener habilitada la función de actualización automática.
• Seguridad: En algunos entornos altamente protegidos, los SID de los Controllers de confianza se configuraban manualmente para evitar posibles amenazas de seguridad de un servidor DNS comprometido. Sin embargo, si hace esto, también debe inhabilitar la función de actualización automática. De lo contrario, se utiliza la configuración de una caché persistente.

Por lo tanto, a menos que tenga una razón específica, no modifique el ListofSIDs.

Si debe modificar el ListofSIDs, cree una clave de registro llamada ListOfSIDs (REG_SZ) en HKLM\Software\Citrix\VirtualDesktopAgent. El valor es una lista de SID de confianza, separados por espacios si tiene más de uno.

En el siguiente ejemplo, se utiliza un Controller para el registro de VDA (ListofDDCs), pero se utilizan dos Controllers para la intermediación (List OfSIDs).

Búsqueda de Controller durante el registro de VDA

Cuando un VDA intenta registrarse, el Agente de intermediación realiza primero una búsqueda DNS en el dominio local para asegurarse de que se puede acceder al Controller especificado.

Si esa búsqueda inicial no encuentra el Controller, el Agente de intermediación puede iniciar una consulta de reserva de arriba hacia abajo en AD. Esa consulta busca en 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 distribuida (DDoS) en el controlador de dominio.

La siguiente clave de registro controla si el Agente de intermediación utiliza la consulta de reserva de arriba hacia abajo cuando no puede localizar un Controller durante la búsqueda inicial.

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent

• Nombre: DisableDdcWildcardNameLookup
• Tipo: DWORD
• Valor: 0 (predeterminado) o cualquier valor distinto de cero

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 abajo. Este es el comportamiento predeterminado. Sin embargo, si se establece en cualquier valor distinto de cero, la búsqueda de reserva se deshabilita. Si la búsqueda inicial del Controller falla, el Agente de Broker deja de buscar.

Secuenciación de enlaces LDAP durante el registro de VDA mediante un controlador de dominio de solo lectura

Cuando un VDA se registra con un controlador de dominio de solo lectura (RODC), el Agente de Broker debe seleccionar qué enlace o enlaces del Protocolo ligero de acceso a directorios (LDAP) ignorar. Para realizar esta selección, el Agente de Broker requiere una clave de registro adecuada.

Si no se proporciona una clave de registro, o el campo de la clave de registro está vacío, el registro del VDA con el RODC tarda más porque se requiere pasar por la secuencia de enlace LDAP original.

Para modificar la secuencia de enlace LDAP, se ha agregado la clave de registro ListofIgnoredBindings a HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent. El uso de ListofIgnoredBindings le permite modificar la secuencia de enlace LDAP según sea necesario y, por lo tanto, acelerar el registro del VDA con un RODC.

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

El valor es una lista de opciones de ruta de enlace, cada una separada por una coma. La clave de registro ignora los valores que no reconoce como válidos.

Solucionar problemas de registro de VDA

Como se indicó anteriormente, un VDA debe registrarse con un Delivery Controller o Cloud Connector para ser considerado al iniciar sesiones intermediadas. Los VDA no registrados pueden provocar una subutilización de recursos que de otro modo estarían disponibles. Hay varias razones por las que un VDA podría no estar registrado, muchas de las cuales un administrador puede solucionar. Studio proporciona información de solución de problemas en el asistente de creación de catálogos y después de crear un grupo de entrega.

• Identificación de problemas durante la creación del catálogo de máquinas: En el asistente de creación de catálogos, después de agregar máquinas existentes, la lista de nombres de cuentas de equipo indica si cada máquina es adecuada para agregarla al catálogo. Pase el ratón por encima del icono junto a cada máquina para mostrar un mensaje informativo sobre esa máquina.

  Si el mensaje identifica una máquina problemática, puede eliminar esa máquina (mediante el botón Quitar) o agregarla. Por ejemplo, si un mensaje indica que no se obtuvo información sobre una máquina (quizás porque nunca se había registrado), podría optar por agregar la máquina de todos modos.

  El nivel funcional de un catálogo controla qué funciones del producto están disponibles para las máquinas del catálogo. El uso de funciones introducidas en nuevas versiones del producto podría requerir un nuevo VDA. Establecer un nivel funcional hace que todas las funciones introducidas en esa versión (y 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 con una versión anterior de VDA no podrán registrarse.

• Identificación de problemas después de crear grupos de entrega: Después de crear un grupo de entrega, Studio muestra detalles sobre las máquinas asociadas a ese grupo.

  El panel de detalles de un grupo de entrega indica el número de máquinas que deben registrarse pero no lo están. En otras palabras, puede haber una o más máquinas encendidas y que no están en modo de mantenimiento, pero que no están registradas actualmente con un Controller. Al ver una máquina “no registrada, pero que debería estarlo”, revise la pestaña Solucionar problemas en el panel de detalles para ver las posibles causas y las acciones correctivas recomendadas.

Más información sobre la solución de problemas de registro de VDA

• Para obtener más información sobre los niveles funcionales, consulte Versiones de VDA y niveles funcionales.

• Para obtener más información sobre la solución de problemas de registro de VDA, consulte CTX136668.

• También puede usar las comprobaciones de estado de Citrix Scout para solucionar problemas de registro de VDA e inicio de sesión. Para obtener más información, consulte Acerca de las comprobaciones de estado.