Caché de host local

Para garantizar que la base de datos del sitio de Citrix Virtual Apps and Desktops esté siempre disponible, Citrix recomienda empezar con una implementación de SQL Server tolerante a fallos, siguiendo las mejores prácticas de alta disponibilidad de Microsoft. (Para conocer las funciones de alta disponibilidad de SQL Server compatibles, consulte Bases de datos.) Sin embargo, los problemas e interrupciones de la red pueden impedir que los usuarios se conecten a sus aplicaciones o escritorios.

La función Caché de host local permite que las operaciones de intermediación de conexiones en un sitio continúen cuando se produce una interrupción. Se produce una interrupción cuando la conexión entre un Delivery Controller™ y la base de datos del sitio falla en un entorno Citrix® local. La Caché de host local se activa cuando la base de datos del sitio está inaccesible durante 90 segundos.

A partir de XenApp y XenDesktop 7.16, la función de arrendamiento de conexiones (una función de alta disponibilidad predecesora en versiones anteriores) se eliminó del producto y ya no está disponible.

Contenido de los datos

La Caché de host local incluye la siguiente información, que es un subconjunto de la información de la base de datos principal:

• Identidades de usuarios y grupos a los que se asignan derechos a los recursos publicados desde el sitio.
• Identidades de los usuarios que están utilizando actualmente, o que han utilizado recientemente, recursos publicados desde el sitio.
• Identidades de las máquinas VDA (incluidas las máquinas de acceso remoto a PC) configuradas en el sitio.
• Identidades (nombres y direcciones IP) de las máquinas cliente de Citrix Receiver™ que se utilizan activamente para conectarse a los recursos publicados.

También contiene información para las conexiones actualmente activas que se establecieron mientras la base de datos principal no estaba disponible:

• Resultados de cualquier análisis de punto final de máquina cliente realizado por Citrix Receiver.
• Identidades de las máquinas de infraestructura (como los servidores NetScaler Gateway y StoreFront™) implicadas en el sitio.
• Fechas, horas y tipos de actividad reciente de los usuarios.

Cómo funciona

El siguiente gráfico ilustra los componentes de la caché de host local y las rutas de comunicación durante las operaciones normales.

Durante las operaciones normales

• El broker principal (Citrix Broker Service) en un Controller acepta las solicitudes de conexión de StoreFront. El broker se comunica con la base de datos del sitio para conectar a los usuarios con los VDA registrados en el Controller.
• El servicio Citrix Config Synchronizer (CSS) comprueba con el broker aproximadamente cada 5 minutos si se han realizado cambios. Esos cambios pueden ser iniciados por el administrador (como cambiar una propiedad de grupo de entrega) o acciones del sistema (como asignaciones de máquinas).

• Si se produjo un cambio de configuración desde la comprobación anterior, el CSS sincroniza (copia) la información en un broker secundario en el Controller. (El broker secundario también se conoce como servicio de alta disponibilidad).

  Se copian todos los datos de configuración, no solo los elementos que cambiaron desde la comprobación anterior. El CSS importa los datos de configuración en una base de datos de Microsoft SQL Server Express LocalDB en el Controller. Esta base de datos se conoce como base de datos de la caché de host local. El CSS garantiza que la información de la base de datos de la caché de host local coincida con la información de la base de datos del sitio. La base de datos de la caché de host local se vuelve a crear cada vez que se produce una sincronización.

  Microsoft SQL Server Express LocalDB (utilizado por la base de datos de la caché de host local) se instala automáticamente al instalar un Controller. (Puede prohibir esta instalación al instalar un Controller desde la línea de comandos). La base de datos de la caché de host local no se puede compartir entre Controllers. No es necesario hacer una copia de seguridad de la base de datos de la caché de host local. Se vuelve a crear cada vez que se detecta un cambio de configuración.

• Si no se han producido cambios desde la última comprobación, no se copian datos.

El siguiente gráfico ilustra los cambios en las rutas de comunicación si el broker principal pierde el contacto con la base de datos del sitio (comienza una interrupción).

Durante una interrupción

Cuando comienza una interrupción:

• El broker secundario comienza a escuchar y procesar las solicitudes de conexión.
• Cuando comienza la interrupción, el broker secundario no tiene datos de registro de VDA actuales, pero cuando un VDA se comunica con él, se activa un proceso de registro. Durante ese proceso, el broker secundario también obtiene información de sesión actual sobre ese VDA.
• Mientras el agente secundario gestiona las conexiones, el Brokering Principal sigue supervisando la conexión. Cuando se restablece la conexión, el Brokering Principal indica al agente secundario que deje de escuchar la información de conexión y reanuda las operaciones de intermediación. La próxima vez que un VDA se comunique con el Brokering Principal, se activa un proceso de registro. El agente secundario elimina cualquier registro de VDA restante de la interrupción anterior. El CSS reanuda la sincronización de la información cuando detecta que se han producido cambios de configuración en la implementación.

En el improbable caso de que se produzca una interrupción durante una sincronización, la importación actual se descarta y se utiliza la última configuración conocida.

El (#event-logs) proporciona información sobre las sincronizaciones y las interrupciones.

No hay un límite de tiempo impuesto para operar en modo de interrupción.

La transición entre el modo normal y el modo de interrupción no afecta a las sesiones existentes. Solo afecta al inicio de nuevas sesiones.

También puede provocar una interrupción intencionadamente. Consulte (#force-an-outage) para obtener más información sobre por qué y cómo hacerlo.

Sitios con varios Controllers

Entre otras tareas, el CSS proporciona rutinariamente al agente secundario información sobre todos los Controllers de la zona. (Si su implementación no contiene varias zonas, esta acción afecta a todos los Controllers del sitio). Al tener esa información, cada agente secundario conoce a todos los agentes secundarios pares que se ejecutan en otros Controllers de la zona.

Los agentes secundarios se comunican entre sí a través de un canal independiente. Esos agentes utilizan una lista alfabética de nombres FQDN de las máquinas en las que se ejecutan para determinar (elegir) qué agente secundario realizará las operaciones de intermediación en la zona si se produce una interrupción. Durante la interrupción, todos los VDA se registran con el agente secundario elegido. Los agentes secundarios no elegidos de la zona rechazan activamente las solicitudes de conexión entrantes y de registro de VDA.

Si un agente secundario elegido falla durante una interrupción, se elige otro agente secundario para que lo reemplace, y los VDA se registran con el agente secundario recién elegido.

Durante una interrupción, si se reinicia un Controller:

• Si ese Controller no es el agente elegido, el reinicio no tiene ningún impacto.
• Si ese Controller es el agente elegido, se elige un Controller diferente, lo que provoca que los VDA se registren. Después de que el Controller reiniciado se encienda, asume automáticamente la intermediación, lo que provoca que los VDA se registren de nuevo. En este escenario, el rendimiento puede verse afectado durante los registros.

Si apaga un Controller durante las operaciones normales y luego lo enciende durante una interrupción, la caché de host local no se puede utilizar en ese Controller si es elegido como agente.

Los (#event-logs) proporcionan información sobre las elecciones.

Qué no está disponible durante una interrupción y otras diferencias

No hay un límite de tiempo impuesto para operar en modo de interrupción. Sin embargo, Citrix recomienda restaurar la conectividad lo antes posible.

Durante una interrupción:

• No puede usar Studio.

• Tiene acceso limitado al SDK de PowerShell.

  • Primero debe:
    • Agregar una clave de registro EnableCssTestMode con un valor de 1: New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
    • Usar el puerto 89: Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ControllerDNSName, DesktopGroupName, RegistrationState
  • Después de ejecutar esos comandos, puede acceder a:
    • Todos los cmdlets Get-Broker*.
• Las credenciales del hipervisor no se pueden obtener del Servicio de host. Todas las máquinas están en estado de energía desconocido y no se pueden emitir operaciones de energía. Sin embargo, las máquinas virtuales en el host que están encendidas se pueden usar para solicitudes de conexión.
• Una máquina asignada solo se puede usar si la asignación se realizó durante las operaciones normales. No se pueden realizar nuevas asignaciones durante una interrupción.
• La inscripción y configuración automáticas de las máquinas de acceso remoto a PC no son posibles. Sin embargo, las máquinas que se inscribieron y configuraron durante el funcionamiento normal son utilizables.
• Los usuarios de aplicaciones y escritorios alojados en servidores pueden usar más sesiones de las que permiten sus límites de sesión configurados, si los recursos se encuentran en zonas diferentes.
• Los usuarios solo pueden iniciar aplicaciones y escritorios desde VDA registrados en la zona que contiene el broker secundario actualmente activo/elegido. Los inicios entre zonas (desde un broker secundario en una zona a un VDA en una zona diferente) no son compatibles durante una interrupción.
• Si se produce una interrupción de la base de datos del sitio antes de que comience un reinicio programado para los VDA en un grupo de entrega, los reinicios comienzan cuando finaliza la interrupción. Esto puede tener resultados no deseados. Para obtener más información, consulte Reinicios programados retrasados debido a una interrupción de la base de datos.
• Preferencia de zona no se puede configurar. Si se configura, las preferencias no se tienen en cuenta para el inicio de la sesión.
• Restricciones de etiquetas, donde las etiquetas se utilizan para designar zonas, no son compatibles con los inicios de sesión. Cuando se configuran dichas restricciones de etiquetas y se habilita la opción comprobación de estado avanzada de un almacén de StoreFront, las sesiones pueden fallar intermitentemente al iniciarse.

Compatibilidad con aplicaciones y escritorios

LHC admite los siguientes tipos de VDA y modelos de entrega:

Nota:

Habilitar el acceso a VDA de escritorio con administración de energía en grupos de entrega agrupados no afecta cómo funciona la propiedad ShutdownDesktopsAfterUse configurada durante las operaciones normales. Cuando el acceso a estos escritorios durante LHC está habilitado, los VDA no se reinician automáticamente una vez que finaliza el evento LHC. Los VDA de escritorio con administración de energía en grupos de entrega agrupados pueden retener datos de sesiones anteriores hasta que los VDA se reinicien. Un reinicio de VDA puede ocurrir cuando un usuario cierra sesión en el VDA durante operaciones que no son de LHC o cuando los administradores reinician el VDA.

Habilitar LHC para VDA agrupados de SO de sesión única con administración de energía mediante Web Studio

Con Web Studio, puede hacer que esas máquinas estén disponibles para nuevas conexiones durante los eventos de LHC por grupo de entrega:

• Para habilitar esta función durante la creación de un grupo de entrega, consulte Crear grupos de entrega.
• Para habilitar esta función para un grupo de entrega existente, consulte Administrar grupos de entrega.

Nota:

Esta configuración solo está disponible en Web Studio para grupos de entrega de escritorios agrupados que entregan VDA con administración de energía.

Habilitar LHC para VDA agrupados de SO de sesión única con administración de energía mediante PowerShell

Para habilitar LHC para VDA en un grupo de entrega específico, siga estos pasos:

1. Habilite esta función a nivel de sitio ejecutando este comando:

   Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

2. Habilite LHC para un grupo de entrega ejecutando este comando con el nombre del grupo de entrega especificado:

   Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true

Para cambiar la disponibilidad predeterminada de LHC para los grupos de entrega agrupados recién creados con VDA administrados por energía, ejecute el siguiente comando:

Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true

Consideraciones sobre el tamaño de la RAM

El servicio LocalDB puede usar aproximadamente 1,2 GB de RAM (hasta 1 GB para la caché de la base de datos, más 200 MB para ejecutar SQL Server Express LocalDB). El agente secundario puede usar hasta 1 GB de RAM si una interrupción dura un intervalo prolongado con muchos inicios de sesión (por ejemplo, 12 horas con 10 000 usuarios). Estos requisitos de memoria se suman a los requisitos normales de RAM para el Controller, por lo que es posible que deba aumentar la cantidad total de capacidad de RAM.

Si utiliza una instalación de SQL Server Express para la base de datos del sitio, el servidor tendrá dos procesos sqlserver.exe.

Consideraciones sobre la configuración de núcleos de CPU y sockets

La configuración de la CPU de un Controller, en particular el número de núcleos disponibles para SQL Server Express LocalDB, afecta directamente al rendimiento de Local Host Cache, incluso más que la asignación de memoria. Esta sobrecarga de CPU solo se observa durante el período de interrupción cuando la base de datos no es accesible y el agente secundario está activo.

Aunque LocalDB puede usar varios núcleos (hasta 4), está limitado a un solo socket. Añadir más sockets no mejorará el rendimiento (por ejemplo, tener 4 sockets con 1 núcleo cada uno). En su lugar, Citrix recomienda usar varios sockets con varios núcleos. En las pruebas de Citrix, una configuración de 2x3 (2 sockets, 3 núcleos) proporcionó un mejor rendimiento que las configuraciones de 4x1 y 6x1.

Consideraciones sobre el almacenamiento

A medida que los usuarios acceden a los recursos durante una interrupción, la LocalDB crece. Por ejemplo, durante una prueba de inicio/cierre de sesión que se ejecuta a 10 inicios de sesión por segundo, la base de datos creció 1 MB cada 2-3 minutos. Cuando se reanuda el funcionamiento normal, la base de datos local se vuelve a crear y se devuelve el espacio. Sin embargo, debe haber suficiente espacio disponible en la unidad donde está instalada la LocalDB para permitir el crecimiento de la base de datos durante una interrupción. Local Host Cache también incurre en más E/S durante una interrupción: aproximadamente 3 MB de escrituras por segundo, con varios cientos de miles de lecturas.

Consideraciones de rendimiento

Durante una interrupción, un broker secundario gestiona todas las conexiones, por lo que en sitios (o zonas) que equilibran la carga entre varios Controllers durante las operaciones normales, el broker secundario elegido podría tener que gestionar muchas más solicitudes de lo normal durante una interrupción. Por lo tanto, las demandas de CPU serán mayores. Cada broker secundario del sitio (zona) debe ser capaz de gestionar la carga adicional impuesta por la base de datos de la caché de host local y todos los VDA afectados, ya que el broker secundario elegido durante una interrupción puede cambiar.

Límites de VDI:

• En una implementación VDI de una sola zona, se pueden gestionar eficazmente hasta 10 000 VDA durante una interrupción.
• En una implementación VDI multizona, se pueden gestionar eficazmente hasta 10 000 VDA en cada zona durante una interrupción, con un máximo de 40 000 VDA en el sitio. Por ejemplo, cada uno de los siguientes sitios se puede gestionar eficazmente durante una interrupción:
  • Un sitio con cuatro zonas, cada una con 10 000 VDA.
  • Un sitio con siete zonas, una con 10 000 VDA y seis con 5000 VDA cada una.

Durante una interrupción, la administración de la carga dentro del sitio puede verse afectada. Los evaluadores de carga (y, especialmente, las reglas de recuento de sesiones) pueden superarse.

Durante el tiempo que tardan todos los VDA en registrarse con un broker secundario, es posible que ese servicio no tenga información completa sobre las sesiones actuales. Por lo tanto, una solicitud de conexión de usuario durante ese intervalo puede resultar en el inicio de una nueva sesión, aunque fuera posible la reconexión a una sesión existente. Este intervalo (mientras el broker secundario “nuevo” adquiere información de sesión de todos los VDA durante el nuevo registro) es inevitable. Las sesiones que están conectadas cuando comienza una interrupción no se ven afectadas durante el intervalo de transición, pero las nuevas sesiones y las reconexiones de sesión sí podrían verse afectadas.

Este intervalo se produce cada vez que los VDA deben registrarse:

• Comienza una interrupción: Al migrar de un broker principal a un broker secundario.
• Fallo del broker secundario durante una interrupción: Al migrar de un broker secundario que falló a un broker secundario recién elegido.
• Recuperación de una interrupción: Cuando se reanudan las operaciones normales y el broker principal recupera el control.

Puede reducir el intervalo disminuyendo el valor del registro HeartbeatPeriodMs del Protocolo de broker de Citrix (valor predeterminado = 600000 ms, que son 10 minutos). Este valor de latido es el doble del intervalo que utiliza el VDA para los pings, por lo que el valor predeterminado da como resultado un ping cada 5 minutos.

Por ejemplo, el siguiente comando cambia el latido a cinco minutos (300000 milisegundos), lo que resulta en un ping cada 2,5 minutos:

New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000

Tenga precaución al cambiar el valor de latido. Aumentar la frecuencia provoca una mayor carga en los Controllers tanto en modo normal como en modo de interrupción.

El intervalo no se puede eliminar por completo, por muy rápido que se registren los VDA.

El tiempo que tarda en sincronizarse entre los brokers secundarios aumenta con el número de objetos (como VDA, aplicaciones, grupos). Por ejemplo, sincronizar 5000 VDA puede tardar 10 minutos o más en completarse.

Diferencias con respecto a las versiones de XenApp 6.x

Aunque esta implementación de la caché de host local comparte el nombre de la función de caché de host local en XenApp 6.x y versiones anteriores de XenApp, existen mejoras significativas. Esta implementación es más robusta e inmune a la corrupción. Los requisitos de mantenimiento se minimizan, como la eliminación de la necesidad de comandos dsmaint periódicos. Esta caché de host local es una implementación técnicamente diferente.

Administrar la caché de host local

Para que la caché de host local funcione correctamente, la política de ejecución de PowerShell en cada Controller debe establecerse en RemoteSigned, Unrestricted o Bypass.

SQL Server Express LocalDB

El software Microsoft SQL Server Express LocalDB que utiliza la caché de host local se instala automáticamente al instalar un Controller o al actualizar un Controller desde una versión anterior a la 7.9. Solo el broker secundario se comunica con esta base de datos. No se pueden usar cmdlets de PowerShell para cambiar nada de esta base de datos. La LocalDB no se puede compartir entre Controllers.

El software de base de datos SQL Server Express LocalDB se instala independientemente de si la caché de host local está habilitada.

Para evitar su instalación, instale o actualice el Controller mediante el comando XenDesktopServerSetup.exe e incluya la opción /exclude "Local Host Cache Storage (LocalDB)". Sin embargo, tenga en cuenta que la función de caché de host local no funcionará sin la base de datos, y no puede usar una base de datos diferente con el broker secundario.

La instalación de esta base de datos LocalDB no afecta a si instala SQL Server Express para usarlo como base de datos del sitio.

Para obtener información sobre cómo reemplazar una versión anterior de SQL Server Express LocalDB por una versión más reciente, consulte Reemplazar SQL Server Express LocalDB.

Configuración predeterminada después de la instalación y actualización del producto

Durante una nueva instalación de Citrix Virtual Apps and Desktops (versión mínima 7.16), la Caché de host local está habilitada.

Después de una actualización (a la versión 7.16 o posterior), la Caché de host local se habilita si hay menos de 10 000 VDA en toda la implementación.

Habilitar y deshabilitar la Caché de host local

• Para habilitar la Caché de host local, introduzca:

  Set-BrokerSite -LocalHostCacheEnabled $true

  Para determinar si la Caché de host local está habilitada, introduzca Get-BrokerSite. Compruebe que la propiedad LocalHostCacheEnabled sea True.

• Para deshabilitar la Caché de host local, introduzca:

  Set-BrokerSite -LocalHostCacheEnabled $false

Recuerde: A partir de XenApp y XenDesktop 7.16, el arrendamiento de conexiones (la función que precedió a la Caché de host local a partir de la versión 7.6) se eliminó del producto y ya no está disponible.

Verificar que la Caché de host local funciona

Para verificar que la Caché de host local está configurada y funciona correctamente:

• Asegúrese de que las importaciones de sincronización se completen correctamente. Compruebe los registros de eventos.
• Asegúrese de que la base de datos SQL Server Express LocalDB se haya creado en cada Delivery Controller. Esto confirma que el agente secundario puede tomar el control, si es necesario.
  • En el servidor Delivery Controller, vaya a C:\Windows\ServiceProfiles\NetworkService.
  • Verifique que se hayan creado HaDatabaseName.mdf y HaDatabaseName_log.ldf.
• Forzar una interrupción en los Delivery Controllers. Después de verificar que la caché de host local funciona, recuerde volver a poner todos los Controllers en modo normal. Esto puede tardar aproximadamente 15 minutos.

Registros de eventos

Los registros de eventos indican cuándo se producen sincronizaciones e interrupciones. En los registros del visor de eventos, el modo de interrupción se denomina modo HA.

Servicio de sincronización de configuración:

Durante las operaciones normales, pueden ocurrir los siguientes eventos cuando el CSS importa los datos de configuración a la base de datos de la caché de host local mediante el agente de caché de host local.

• 503: El servicio Citrix Config Sync recibió una configuración actualizada. Este evento indica el inicio del proceso de sincronización.
• 504: El servicio Citrix Config Sync importó una configuración actualizada. La importación de la configuración se completó correctamente.
• 505: El servicio Citrix Config Sync falló una importación. La importación de la configuración no se completó correctamente. Si hay una configuración anterior correcta disponible, se utiliza si se produce una interrupción. Sin embargo, estará desactualizada con respecto a la configuración actual. Si no hay ninguna configuración anterior disponible, el servicio no puede participar en la intermediación de sesiones durante una interrupción. En este caso, consulte la sección Solucionar problemas y póngase en contacto con el soporte de Citrix.
• 507: El servicio Citrix Config Sync abandonó una importación porque el sistema está en modo de interrupción y el agente de caché de host local se está utilizando para la intermediación. El servicio recibió una nueva configuración, pero la importación se abandonó porque se produjo una interrupción. Este es el comportamiento esperado.
• 510: No se recibieron datos de configuración del servicio de configuración del servicio de configuración principal.
• 517: Hubo un problema de comunicación con el Broker principal.
• 518: El script de sincronización de configuración se abortó porque el Broker secundario (Servicio de alta disponibilidad) no se está ejecutando.

Servicio de alta disponibilidad:

Este servicio también se conoce como agente de caché de host local.

• 3502: Se produjo una interrupción y el agente de caché de host local está realizando operaciones de intermediación.
• 3503: Se resolvió una interrupción y se reanudaron las operaciones normales.
• 3504: Indica qué broker de caché de host local ha sido elegido, además de otros brokers de caché de host local implicados en la elección.
• 3507: Proporciona una actualización de estado de la caché de host local cada 2 minutos, lo que indica que el modo de caché de host local está activo en el broker elegido. Contiene un resumen de la interrupción, incluida la duración de la interrupción, el registro de VDA y la información de la sesión.
• 3508: Anuncia que la caché de host local ya no está activa en el broker elegido y que se han restaurado las operaciones normales. Contiene un resumen de la interrupción, incluida la duración de la interrupción, el número de máquinas que se registraron durante el evento de caché de host local y el número de inicios correctos durante el evento de LHC.
• 3509: Notifica que la caché de host local está activa en el/los broker(s) no elegido(s). Contiene una duración de la interrupción cada 2 minutos e indica el broker elegido.
• 3510: Anuncia que la caché de host local ya no está activa en el/los broker(s) no elegido(s). Contiene la duración de la interrupción e indica el broker elegido.

Forzar una interrupción

Es posible que desee forzar deliberadamente una interrupción.

• Si su red se interrumpe y se restablece repetidamente. Forzar una interrupción hasta que se resuelvan los problemas de red evita la transición continua entre los modos normal y de interrupción (y las consiguientes tormentas frecuentes de registro de VDA).
• Para probar un plan de recuperación ante desastres.
• Para ayudar a garantizar que la caché de host local funciona correctamente.
• Mientras se reemplaza o se realiza el mantenimiento del servidor de la base de datos del sitio.

Para forzar una interrupción, edite el registro de cada servidor que contenga un Delivery Controller. En HKLM\Software\Citrix\DesktopServer\LHC, cree y establezca OutageModeForced como REG_DWORD en 1. Esta configuración indica al broker de caché de host local que entre en modo de interrupción, independientemente del estado de la base de datos. Establecer el valor en 0 saca al broker de caché de host local del modo de interrupción.

Para verificar los eventos, supervise el archivo de registro Current_HighAvailabilityService en C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityService.

Solucionar problemas

Hay varias herramientas de solución de problemas disponibles cuando falla una importación de sincronización a la base de datos de la caché de host local y se publica un evento 505.

Rastreo CDF: Contiene opciones para los módulos ConfigSyncServer y BrokerLHC. Esas opciones, junto con otros módulos de intermediación, probablemente identificarán el problema.

Informe: Si falla una importación de sincronización, puede generar un informe. Este informe se detiene en el objeto que causa el error. Esta función de informe afecta la velocidad de sincronización, por lo que Citrix recomienda deshabilitarla cuando no esté en uso.

Para habilitar y producir un informe de rastreo CSS, introduzca el siguiente comando:

New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1

El informe HTML se publica en C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html.

Una vez generado el informe, introduzca el siguiente comando para deshabilitar la función de informes:

Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0

Exportar la configuración del intermediario: Proporciona la configuración exacta para fines de depuración.

Export-BrokerConfiguration | Out-File <file-pathname>

Por ejemplo, Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.

Comandos de PowerShell de la caché de host local

Puede administrar la caché de host local (LHC) en sus Delivery Controllers mediante comandos de PowerShell.

El módulo de PowerShell se encuentra en la siguiente ubicación en los Delivery Controllers:

C:\Program Files\Citrix\Broker\Service\ControlScripts

Importante:

Ejecute este módulo solo en los Delivery Controllers.

Importar módulo de PowerShell

Para importar el módulo, ejecute lo siguiente en su Delivery Controller.

cd C:\Program Files\Citrix\Broker\Service\ControlScripts Import-Module .\HighAvailabilityServiceControl.psm1

Comandos de PowerShell para administrar LHC

Los siguientes comandos le ayudan a activar y administrar el modo LHC en los Delivery Controllers.

Nota:

• Utilice el puerto 89 al ejecutar los cmdlets Get-Broker* en el Delivery Controller. Por ejemplo:
  • Get-BrokerMachine -AdminAddress localhost:89
• Cuando no está en modo LHC, el Broker LHC del Delivery Controller solo contiene información de configuración.
• Durante el modo LHC, el Broker LHC del Delivery Controller elegido contiene la siguiente información:
  • Estados de los recursos
  • Detalles de la sesión
  • Registros de VDA
  • Información de configuración