Citrix Virtual Apps and Desktops

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 en el 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. Estás estableciendo 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. Estás estableciendo de forma efectiva 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 tiempo y pertenencia a dominios son implacables. Kerberos utiliza Nombres de Entidad de Servicio (SPN), por lo que no puedes usar IP\nombre de host con equilibrio de carga.
  • Si un VDA no tiene información precisa y actualizada del Controller o Cloud Connector a medida que agregas y quitas 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 (ID de seguridad) indica qué máquinas de la ListofDDCs son de confianza. La ListOfSIDs se puede usar 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, consulta 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 ignoras una advertencia de que no se puede contactar con un Controller o Cloud Connector (o si no especificas las direcciones del Controller o Cloud Connector durante la instalación del VDA), los mensajes te lo recordarán.

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

El administrador elige el método de configuración que se usará 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, consulta Actualización automática.

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

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

Especificas el método de registro inicial cuando instalas un VDA. (Si deshabilitas la actualización automática, el método que selecciones durante la instalación del VDA se usa para los registros posteriores.)

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

Página Delivery Controller en el asistente de instalación del VDA

Basado en directivas (LGPO\GPO)

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

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

  • En la página Delivery Controller del asistente de instalación del VDA, selecciona Hacerlo más tarde (avanzado). El asistente te recordará varias veces que especifiques las direcciones de Controller, aunque no las estés especificando durante la instalación del VDA. (El registro de VDA es así de importante.)
  • Habilita o deshabilita el registro de VDA basado en directivas a través de la directiva de Citrix con la configuración Virtual Delivery Agent Settings > Controllers. (Si la seguridad es tu máxima prioridad, usa 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, completa uno de los pasos siguientes:

  • En la página Delivery Controller del asistente de instalación de VDA, selecciona Hacerlo manualmente. Luego, introduce el FQDN de un Controller instalado y haz clic en Agregar. Si has instalado más Controllers, agrega sus direcciones.
  • Para una instalación de VDA desde la línea de comandos, usa la opción /controllers y especifica los FQDN de los Controllers o Cloud Connectors instalados.

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

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

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

  • Opcionalmente, actualiza la clave de registro ListOfSIDs (para obtener más información, consulta ListOfSIDs:

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

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

Basado en OU de Active Directory (heredado)

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

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

  • En la página Delivery Controller del asistente de instalación de VDA, selecciona Elegir ubicaciones de Active Directory.
  • Usa el script Set-ADControllerDiscovery.ps1 (disponible en cada Controller). Además, configura la entrada de 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 usas 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, selecciona Dejar que Machine Creation Services™ lo haga.

Revisión y recomendaciones

Como práctica recomendada:

  • Usa el método de registro de directiva de grupo para el registro inicial.
  • Usa la actualización automática (habilitada de forma predeterminada) para mantener tu lista de Controllers actualizada.
  • En una implementación multizona, usa la directiva de grupo para la configuración inicial (con al menos dos Controllers o Cloud Connectors). Dirige los VDA a los Controllers o Cloud Connectors locales (en) su zona. Usa la actualización automática para mantenerlos actualizados. La actualización automática optimiza automáticamente la ListofDDCs para los VDA en zonas satélite.
  • Enumera más de un Controller 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úrate 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 eficiente para mantener actualizados tus registros de VDA. Aunque no se usa para el registro inicial, el software de actualización automática descarga y almacena la 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 directivas de máquina, lo que garantiza que la configuración de las directivas se conserve entre reinicios.

  • La actualización automática es compatible cuando se usa 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:

  • Habilita o deshabilita 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:

  • 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 quitó 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 agregan 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 aún, el Controller B se mueve 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 en caché automáticamente 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 ID de seguridad (ListofSIDs). El VDA no consulta los SID y, por lo tanto, reduce la carga de Active Directory.

  • Ejemplo de archivo de caché de registro de un VDA

Puedes 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 MODIFIQUES ESTE ARCHIVO. Cualquier modificación de este archivo o carpeta da como resultado una configuración no compatible.

```
DDC7x.xd.local DDC7xHA.xd.local
  • 32-bit: HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs

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

    ```

Si necesitas configurar manualmente la ListofSIDs por motivos de seguridad (a diferencia de reducir la carga de Active Directory), no puedes usar la función de actualización automática. Para obtener más información, consulta ListOfSIDs.

Excepción a la prioridad de actualización automática

Aunque la actualización automática suele tener la máxima prioridad de 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 siguiente método de prioridad configurado más alto. Este proceso puede ser útil cuando mueves un VDA a otro sitio (por ejemplo, durante la recuperación ante desastres).

Consideraciones de configuración

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

Consulta los pasos de registro de VDA.

Considera lo siguiente al configurar elementos que pueden afectar al registro de VDA.

Direcciones de Controller o Cloud Connector

Independientemente del método que uses 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 comprometer una IP que un registro DNS. Si rellenas la ListofSIDs manualmente, puedes usar una IP en una ListofDDCs. Sin embargo, se sigue recomendando el FQDN.

Equilibrio de carga

Como se mencionó anteriormente, el VDA distribuye automáticamente las conexiones entre todos los Controllers o Cloud Connectors en la 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 se produce de forma automática para todos los VDA.

Por razones de seguridad, no puede usar 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 mencionó 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:

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á deshabilitada a partir de XenApp y XenDesktop 7. Use 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 use la actualización automática y CNAME al mismo tiempo.)

Grupos de Controller/Cloud Connector

En ciertos escenarios, es posible que desee procesar Controllers o Cloud Connectors en grupos, con un grupo preferido y el otro grupo utilizado para una 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 destinados a usarse dentro de un único sitio (no en varios sitios).

Use 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 superior, 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 con 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. La ListofSIDs (identificadores de seguridad) identifica 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 recientes disponibles.

  • Roles separados para Controllers: Antes de que se introdujeran las zonas en XenApp y XenDesktop 7.7, la ListofSIDs se configuraba manualmente cuando solo se usaba un subconjunto de Controllers para el registro. Por ejemplo, si usaba XDC-001 y XDC-002 como intermediarios XML, y XDC-003 y XDC-004 para el registro de VDA, especificaba todos los Controllers en la ListofSIDs, y XDC-003 y XDC-004 en la ListofDDCs. Esta no es una configuración típica ni recomendada. No la use en entornos más recientes. En su lugar, use 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, la ListofSIDs se usaba para reducir la carga en los controladores de dominio. Al rellenar previamente la 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 seguros, los SID de los Controllers de confianza se configuraron manualmente para evitar posibles amenazas de seguridad de un servidor DNS comprometido. Sin embargo, si hace esto, también debe deshabilitar 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 la ListofSIDs.

Si debe modificar la 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 usa un Controller para el registro de VDA (ListofDDCs), pero se usan dos Controllers para la intermediación (List OfSIDs).

Ejemplo de diferentes Controllers utilizados para el registro y la intermediación

Búsqueda de Controller durante el registro de VDA

Cuando un VDA intenta registrarse, el Agente de Broker 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 Broker puede iniciar una consulta descendente de reserva 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 potencialmente una condición de denegación de servicio distribuida (DDoS) en el controlador de dominio.

La siguiente clave del Registro controla si el Agente de Broker utiliza la consulta descendente de reserva 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 descendente de reserva. Este es el comportamiento predeterminado. Sin embargo, si se establece en cualquier valor distinto de cero, la búsqueda de reserva está deshabilitada. Si la búsqueda inicial del Controller falla, el Agente de Broker deja de buscar.

Secuencia de enlace 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 del Registro adecuada.

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

Para modificar la secuencia de enlace LDAP, se ha agregado la clave del Registro ListofIgnoredBindings a HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent. El uso de ListofIgnoredBindings te 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 del Registro ignora los valores que no reconoce como válidos.

Solucionar problemas de registro de VDA

Como se ha señalado 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 la infrautilización de recursos que, de otro modo, estarían disponibles. Existen varias razones por las que un VDA podría no estar registrado, muchas de las cuales un administrador puede solucionar. Studio proporciona información para la solución de problemas en el asistente de creación de catálogos y después de que crees un grupo de entrega.

  • Identificación de problemas durante la creación de catálogos de máquinas: En el asistente de creación de catálogos, después de que agregues máquinas existentes, la lista de nombres de cuentas de equipo indica si cada máquina es adecuada para agregarla al catálogo. Pasa 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, puedes quitar esa máquina (mediante el botón Quitar) o agregar la máquina. 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ías 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 VDA nuevo. 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 que crees un grupo de entrega, Studio muestra los detalles de 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 debe estarlo”, revisa la ficha Solucionar problemas en el panel de detalles para conocer 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, consulta Versiones de VDA y niveles funcionales.

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

  • También puedes 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, consulta Acerca de las comprobaciones de estado.