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 en 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 sensible. Estás estableciendo una conexión entre el Controller o Cloud Connector y el VDA. Para una operación tan sensible, el comportamiento esperado es rechazar la conexión si no todo 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 horaria y pertenencia al dominio 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 Controller. 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 alcanzar 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), se te 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 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 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 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 seleccionas 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 de VDA.

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

Basado en políticas (LGPO\GPO)

Citrix® recomienda usar GPO para el registro inicial de 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 políticas 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 de VDA, selecciona Hacerlo más tarde (avanzado). El asistente te recordará varias veces que especifiques las direcciones del 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 políticas mediante la política 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 Hazlo 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 por 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 del registro ListOfDDCs bajo la clave del registro HKLM\Software\Citrix\VirtualDesktopAgent o HKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent.

También puedes configurar esta clave del registro manualmente o usar las 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 del registro ListOfDDCs, que enumera los FQDN de todos los Controllers o Cloud Connectors del sitio. (Esta clave es el equivalente de la OU de 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 usa ListOfDDCs para la detección de Controllers o Cloud Connectors. La clave 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 del 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 especifiques 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 por 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 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 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 del 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 tus registros de VDA actualizados. 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 directivas se mantenga tras los 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 política 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 produjo un cambio de política que afecta al registro del 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 recientemente.
  • 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 luego 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 copia de seguridad. 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 un archivo de caché de registro de 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.

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

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, hay 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 usa 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 común de registro de VDA.

Consulta los pasos de registro de VDA.

Ten 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 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, el FQDN sigue siendo recomendado.

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 especificas varios Controllers o Cloud Connectors en tu configuración, el registro se conmuta automáticamente entre ellos, si es necesario. Con la actualización automática, la conmutación por error automática ocurre automáticamente para todos los VDA.

Por razones de seguridad, no puedes usar un equilibrador de carga de red, como Citrix ADC. El registro de VDA usa la autenticación mutua de 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 llama Nombre Principal de Servicio (SPN), que se almacena como una propiedad en un objeto de equipo de Active Directory. Cuando tu VDA se conecta a un Controller o Cloud Connector, debe especificar con quién quiere comunicarse. Esta dirección es un SPN. Si usas una IP con equilibrio de carga, la autenticación mutua de Kerberos reconoce correctamente que la IP no pertenece al Controller o Cloud Connector esperado.

Para obtener más información, consulta:

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. Usa la actualización automática en lugar de CNAME. (Si debes usar CNAME, consulta CTX137960. Para que el alias DNS funcione de forma coherente, no uses la actualización automática y CNAME al mismo tiempo.)

Grupos de Controller/Cloud Connector

En ciertos escenarios, es posible que quieras 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. Recuerda 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 solo sitio (no en varios sitios).

Usa 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 debes realizar para usar la función Grupos de registro. Debes Prohibir la política Habilitar actualización automática del 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. La ListofSIDs (ID 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. Puedes 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 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 usabas XDC-001 y XDC-002 como intermediarios XML, y XDC-003 y XDC-004 para el registro de VDA, especificabas 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 uses en entornos más nuevos. En su lugar, usa 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, porque 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 configuraban manualmente para evitar posibles amenazas de seguridad de un servidor DNS comprometido. Sin embargo, si haces esto, también debes deshabilitar la función de actualización automática. De lo contrario, se usa la configuración de una caché persistente.

Por lo tanto, a menos que tengas una razón específica, no modifiques la ListofSIDs.

Si debes modificar la ListofSIDs, crea 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 tienes 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 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 Broker 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 hacia 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 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 hacer 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 de 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 de 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 de 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 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 una infrautilización de los 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. 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), puedes 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 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