Cache de Host Local

Last published : Nov 13, 2026
Para garantir que o banco de dados do site Citrix Virtual Apps and Desktops esteja sempre disponível, a Citrix recomenda iniciar com uma implantação de SQL Server tolerante a falhas, seguindo as melhores práticas de alta disponibilidade da Microsoft. (Para recursos de alta disponibilidade do SQL Server suportados, consulte Bancos de Dados.) No entanto, problemas e interrupções de rede podem resultar na impossibilidade de os usuários se conectarem aos seus aplicativos ou desktops.
O recurso Local Host Cache permite que as operações de intermediação de conexão em um site continuem quando ocorre uma interrupção. Uma interrupção ocorre quando a conexão entre um Delivery Controller™ e o banco de dados do site falha em um ambiente Citrix® local. O Local Host Cache é ativado quando o banco de dados do site fica inacessível por 90 segundos.
A partir do XenApp e XenDesktop 7.16, o recurso de leasing de conexão (um recurso de alta disponibilidade predecessor em versões anteriores) foi removido do produto e não está mais disponível.
Related information
Gerenciar

Conteúdo dos dados

O Local Host Cache inclui as seguintes informações, que são um subconjunto das informações no banco de dados principal:
  • Identidades de usuários e grupos que têm direitos atribuídos a recursos publicados do site.
  • Identidades de usuários que estão usando atualmente, ou que usaram recentemente, recursos publicados do site.
  • Identidades de máquinas VDA (incluindo máquinas de Acesso Remoto para PC) configuradas no site.
  • Identidades (nomes e endereços IP) de máquinas cliente Citrix Receiver™ sendo ativamente usadas para se conectar a recursos publicados.
Ele também contém informações para conexões atualmente ativas que foram estabelecidas enquanto o banco de dados principal estava indisponível:
  • Resultados de qualquer análise de endpoint de máquina cliente realizada pelo Citrix Receiver.
  • Identidades de máquinas de infraestrutura (como NetScaler Gateway e servidores StoreFront™) envolvidas com o site.
  • Datas, horários e tipos de atividade recente dos usuários.

Como funciona

O gráfico a seguir ilustra os componentes do Local Host Cache e os caminhos de comunicação durante as operações normais.
Diagrama dos caminhos de comunicação do Local Host Cache durante operações normais

Durante operações normais

  • O broker principal (Citrix Broker Service) em um Controller aceita solicitações de conexão do StoreFront. O broker se comunica com o banco de dados do site para conectar usuários a VDAs registrados no Controller.
  • O Citrix Config Synchronizer Service (CSS) verifica com o broker aproximadamente a cada 5 minutos para ver se alguma alteração foi feita. Essas alterações podem ser iniciadas pelo administrador (como alterar uma propriedade de grupo de entrega) ou ações do sistema (como atribuições de máquina).
  • Se uma alteração de configuração ocorreu desde a verificação anterior, o CSS sincroniza (copia) informações para um broker secundário no Controller. (O broker secundário também é conhecido como Serviço de Alta Disponibilidade.)
    Todos os dados de configuração são copiados, não apenas os itens que foram alterados desde a verificação anterior. O CSS importa os dados de configuração para um banco de dados Microsoft SQL Server Express LocalDB no Controller. Este banco de dados é referido como o banco de dados Local Host Cache. O CSS garante que as informações no banco de dados Local Host Cache correspondam às informações no banco de dados do site. O banco de dados Local Host Cache é recriado a cada sincronização.
    O Microsoft SQL Server Express LocalDB (usado pelo banco de dados Local Host Cache) é instalado automaticamente quando você instala um Controller. (Você pode proibir esta instalação ao instalar um Controller a partir da linha de comando.) O banco de dados Local Host Cache não pode ser compartilhado entre Controllers. Você não precisa fazer backup do banco de dados Local Host Cache. Ele é recriado toda vez que uma alteração de configuração é detectada.
  • Se nenhuma alteração ocorreu desde a última verificação, nenhum dado é copiado.
O gráfico a seguir ilustra as alterações nos caminhos de comunicação se o broker principal perder contato com o banco de dados do site (uma interrupção começa).
Diagrama dos caminhos de comunicação do Local Host Cache durante uma interrupção

Durante uma interrupção

Quando uma interrupção começa:
  • O broker secundário começa a escutar e processar solicitações de conexão.
  • Quando a interrupção começa, o broker secundário não possui dados de registro VDA atuais, mas quando um VDA se comunica com ele, um processo de registro é acionado. Durante esse processo, o broker secundário também obtém informações de sessão atuais sobre esse VDA.
  • Enquanto o broker secundário está lidando com as conexões, o Brokering Principal continua a monitorar a conexão. Quando a conexão é restaurada, o Brokering Principal instrui o broker secundário a parar de escutar informações de conexão, e o Brokering Principal retoma as operações de brokering. Na próxima vez que um VDA se comunicar com o Brokering Principal, um processo de registro é acionado. O broker secundário remove quaisquer registros VDA restantes da interrupção anterior. O CSS retoma a sincronização de informações quando descobre que ocorreram alterações de configuração na implantação.
No caso improvável de uma interrupção começar durante uma sincronização, a importação atual é descartada e a última configuração conhecida é usada.
O log de eventos fornece informações sobre sincronizações e interrupções.
Não há limite de tempo imposto para operar no modo de interrupção.
A transição entre o modo normal e o modo de interrupção não afeta as sessões existentes. Ela afeta apenas o início de novas sessões.
Você também pode acionar intencionalmente uma interrupção. Consulte Forçar uma interrupção para obter detalhes sobre o porquê e como fazer isso.

Sites com vários Controllers

Entre suas outras tarefas, o CSS fornece rotineiramente ao broker secundário informações sobre todos os Controllers na zona. (Se sua implantação não contiver várias zonas, esta ação afeta todos os Controllers no site.) Com essas informações, cada broker secundário conhece todos os brokers secundários pares em execução em outros Controllers na zona.
Os brokers secundários se comunicam entre si em um canal separado. Esses brokers usam uma lista alfabética de nomes FQDN das máquinas em que estão sendo executados para determinar (eleger) qual broker secundário será responsável pelas operações de broker na zona se ocorrer uma interrupção. Durante a interrupção, todos os VDAs se registram no broker secundário eleito. Os brokers secundários não eleitos na zona rejeitam ativamente as solicitações de conexão de entrada e de registro de VDA.
Se um broker secundário eleito falhar durante uma interrupção, outro broker secundário é eleito para assumir, e os VDAs se registram com o broker secundário recém-eleito.
Durante uma interrupção, se um Controller for reiniciado:
  • Se esse Controller não for o broker eleito, a reinicialização não terá impacto.
  • Se esse Controller for o broker eleito, um Controller diferente é eleito, fazendo com que os VDAs se registrem. Depois que o Controller reiniciado é ligado, ele assume automaticamente o brokering, o que faz com que os VDAs se registrem novamente. Nesse cenário, o desempenho pode ser afetado durante os registros.
Se você desligar um Controller durante as operações normais e depois ligá-lo durante uma interrupção, o Local Host Cache não poderá ser usado nesse Controller se ele for eleito como o broker.
Os logs de eventos fornecem informações sobre as eleições.

O que está indisponível durante uma interrupção e outras diferenças

Não há limite de tempo imposto para operar no modo de interrupção. No entanto, a Citrix recomenda restaurar a conectividade o mais rápido possível.
Durante uma interrupção:
  • Você não pode usar o Studio.
  • Você tem acesso limitado ao PowerShell SDK.
    • Você deve primeiro:
      • Adicionar uma chave de registro EnableCssTestMode com um valor de 1: New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
      • Usar a porta 89: Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ContollerDNSName, DesktopGroupName, RegistrationState
    • Depois de executar esses comandos, você pode acessar:
      • Todos os cmdlets Get-Broker*.
  • As credenciais do hipervisor não podem ser obtidas do Host Service. Todas as máquinas estão no estado de energia desconhecido e nenhuma operação de energia pode ser emitida. No entanto, as VMs no host que estão ligadas podem ser usadas para solicitações de conexão.
  • Uma máquina atribuída pode ser usada somente se a atribuição ocorreu durante operações normais. Novas atribuições não podem ser feitas durante uma interrupção.
  • O registro e a configuração automáticos de máquinas de Acesso Remoto para PC não são possíveis. No entanto, as máquinas que foram registradas e configuradas durante a operação normal são utilizáveis.
  • Os usuários de aplicativos e desktops hospedados em servidor podem usar mais sessões do que seus limites de sessão configurados, se os recursos estiverem em zonas diferentes.
  • Os usuários podem iniciar aplicativos e desktops somente de VDAs registrados na zona que contém o broker secundário atualmente ativo/eleito. Lançamentos entre zonas (de um broker secundário em uma zona para um VDA em uma zona diferente) não são suportados durante uma interrupção.
  • Se ocorrer uma interrupção do banco de dados do site antes do início de uma reinicialização agendada para VDAs em um grupo de entrega, as reinicializações começarão quando a interrupção terminar. Isso pode ter resultados indesejados. Para obter mais informações, consulte Reinicializações agendadas atrasadas devido a interrupção do banco de dados.
  • Preferência de zona não pode ser configurada. Se configuradas, as preferências não são consideradas para o lançamento da sessão.
  • Restrições de tags, onde as tags são usadas para designar zonas, não são suportadas para lançamentos de sessão. Quando tais restrições de tags são configuradas e a opção verificação avançada de integridade de uma loja StoreFront está habilitada, as sessões podem falhar intermitentemente ao iniciar.

Suporte a aplicativos e desktops

O Local Host Cache oferece suporte a aplicativos e desktops hospedados em servidor e desktops estáticos (atribuídos).
O Local Host Cache oferece suporte a VDAs de desktop em grupos de entrega agrupados, da seguinte forma:
  • Por padrão, VDAs de desktop gerenciados por energia em grupos de entrega agrupados (criados por MCS ou Citrix Provisioning™) que têm a propriedade ShutdownDesktopsAfterUse habilitada não estão disponíveis para novas conexões durante um evento de Cache de Host Local. Você pode alterar esse padrão para permitir que esses desktops sejam usados durante o Cache de Host Local.
    No entanto, você não pode depender do gerenciamento de energia durante a interrupção. (O gerenciamento de energia é retomado após o retorno das operações normais.) Além disso, esses desktops podem conter dados do usuário anterior, pois não foram reiniciados.
  • Para substituir o comportamento padrão, ele deve ser habilitado em todo o site e para cada grupo de entrega afetado. Execute os seguintes cmdlets do PowerShell.
    Em todo o site:
    Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
    Para cada grupo de entrega afetado, execute o seguinte comando PowerShell:
    Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
    Habilitar esse recurso no site e nos grupos de entrega não afeta como a propriedade ShutdownDesktopsAfterUse configurada funciona durante as operações normais. Quando esse recurso está habilitado, os VDAs não reiniciam automaticamente após a conclusão do evento LHC. Os VDAs de desktop gerenciados por energia em grupos de entrega agrupados podem reter dados de sessões anteriores até que o VDA seja reiniciado. Isso pode ocorrer quando um usuário faz logoff do VDA durante operações não-LHC ou a reinicialização pode ser acionada manualmente.
Importante:
Sem habilitar ReuseMachinesWithoutShutdownInOutageAllowed no nível do Site e ReuseMachinesWithoutShutdownInOutage no nível do grupo de entrega, todas as tentativas de iniciar sessões para VDAs de desktop gerenciados por energia em grupos de entrega agrupados falharão durante um evento de Cache de Host Local.

Considerações sobre o tamanho da RAM

O serviço LocalDB pode usar aproximadamente 1,2 GB de RAM (até 1 GB para o cache do banco de dados, mais 200 MB para executar o SQL Server Express LocalDB). O broker secundário pode usar até 1 GB de RAM se uma interrupção durar por um período prolongado com muitos logons ocorrendo (por exemplo, 12 horas com 10 mil usuários). Esses requisitos de memória são adicionais aos requisitos normais de RAM para o Controller, então você pode precisar aumentar a capacidade total de RAM.
Se você usar uma instalação do SQL Server Express para o banco de dados do site, o servidor terá dois processos sqlserver.exe.

Considerações sobre a configuração de núcleos de CPU e soquetes

A configuração da CPU de um Controller, especialmente o número de núcleos disponíveis para o SQL Server Express LocalDB, afeta diretamente o desempenho do Cache de Host Local, ainda mais do que a alocação de memória. Essa sobrecarga da CPU é observada apenas durante o período de interrupção, quando o banco de dados está inacessível e o broker secundário está ativo.
Embora o LocalDB possa usar vários núcleos (até 4), ele é limitado a apenas um único soquete. Adicionar mais soquetes não melhorará o desempenho (por exemplo, ter 4 soquetes com 1 núcleo cada). Em vez disso, a Citrix recomenda usar vários soquetes com vários núcleos. Em testes da Citrix, uma configuração 2x3 (2 soquetes, 3 núcleos) proporcionou melhor desempenho do que as configurações 4x1 e 6x1.

Considerações sobre armazenamento

À medida que os usuários acessam recursos durante uma interrupção, o LocalDB cresce. Por exemplo, durante um teste de logon/logoff executado a 10 logons por segundo, o banco de dados cresceu 1 MB a cada 2-3 minutos. Quando a operação normal é retomada, o banco de dados local é recriado e o espaço é liberado. No entanto, espaço suficiente deve estar disponível na unidade onde o LocalDB está instalado para permitir o crescimento do banco de dados durante uma interrupção. O Cache de Host Local também incorre em mais E/S durante uma interrupção: aproximadamente 3 MB de gravações por segundo, com várias centenas de milhares de leituras.

Considerações de desempenho

Durante uma interrupção, um broker secundário gerencia todas as conexões, então em sites (ou zonas) que fazem balanceamento de carga entre vários Controllers durante operações normais, o broker secundário eleito pode precisar manipular muito mais solicitações do que o normal durante uma interrupção. Portanto, as demandas de CPU serão maiores. Cada broker secundário no site (zona) deve ser capaz de manipular a carga adicional imposta pelo banco de dados do Cache de Host Local e todos os VDAs afetados, porque o broker secundário eleito durante uma interrupção pode mudar.
Limites de VDI:
  • Em uma implantação VDI de zona única, até 10.000 VDAs podem ser tratados de forma eficaz durante uma interrupção.
  • Em uma implantação VDI multizona, até 10.000 VDAs em cada zona podem ser tratados de forma eficaz durante uma interrupção, até um máximo de 40.000 VDAs no site. Por exemplo, cada um dos seguintes sites pode ser tratado de forma eficaz durante uma interrupção:
    • Um site com quatro zonas, cada uma contendo 10.000 VDAs.
    • Um site com sete zonas, uma contendo 10.000 VDAs e seis contendo 5.000 VDAs cada.
Durante uma interrupção, o gerenciamento de carga dentro do site pode ser afetado. Os avaliadores de carga (e especialmente as regras de contagem de sessões) podem ser excedidos.
Durante o tempo que leva para todos os VDAs se registrarem em um broker secundário, esse serviço pode não ter informações completas sobre as sessões atuais. Assim, uma solicitação de conexão de usuário durante esse intervalo pode resultar no lançamento de uma nova sessão, mesmo que a reconexão a uma sessão existente fosse possível. Este intervalo (enquanto o "novo" broker secundário adquire informações de sessão de todos os VDAs durante o novo registro) é inevitável. As sessões que estão conectadas quando uma interrupção começa não são impactadas durante o intervalo de transição, mas novas sessões e reconexões de sessão podem ser.
Este intervalo ocorre sempre que os VDAs devem se registrar:
  • Uma interrupção começa: Ao migrar de um broker principal para um broker secundário.
  • Falha do broker secundário durante uma interrupção: Ao migrar de um broker secundário que falhou para um broker secundário recém-eleito.
  • Recuperação de uma interrupção: Quando as operações normais são retomadas e o broker principal reassume o controle.
Você pode diminuir o intervalo reduzindo o valor do registro HeartbeatPeriodMs do Citrix Broker Protocol (padrão = 600000 ms, que são 10 minutos). Este valor de heartbeat é o dobro do intervalo que o VDA usa para pings, então o valor padrão resulta em um ping a cada 5 minutos.
Por exemplo, o seguinte comando altera o heartbeat para cinco minutos (300000 milissegundos), o que resulta em um ping a cada 2,5 minutos:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000
Tenha cuidado ao alterar o valor do heartbeat. Aumentar a frequência resulta em maior carga nos Controllers durante os modos normal e de interrupção.
O intervalo não pode ser totalmente eliminado, não importa quão rapidamente os VDAs se registrem.
O tempo necessário para sincronizar entre brokers secundários aumenta com o número de objetos (como VDAs, aplicativos, grupos). Por exemplo, sincronizar 5000 VDAs pode levar 10 minutos ou mais para ser concluído.

Diferenças das versões do XenApp 6.x

Embora esta implementação do Local Host Cache compartilhe o nome do recurso Local Host Cache no XenApp 6.x e versões anteriores do XenApp, há melhorias significativas. Esta implementação é mais robusta e imune à corrupção. Os requisitos de manutenção são minimizados, como a eliminação da necessidade de comandos dsmaint periódicos. Este Local Host Cache é uma implementação tecnicamente diferente.

Gerenciar Cache de Host Local

Para que o Cache de Host Local funcione corretamente, a política de execução do PowerShell em cada Controller deve ser definida como RemoteSigned, Unrestricted ou Bypass.

SQL Server Express LocalDB

O software Microsoft SQL Server Express LocalDB que o Cache de Host Local usa é instalado automaticamente quando você instala um Controller ou atualiza um Controller de uma versão anterior à 7.9. Apenas o broker secundário se comunica com este banco de dados. Você não pode usar cmdlets do PowerShell para alterar nada sobre este banco de dados. O LocalDB não pode ser compartilhado entre Controllers.
O software de banco de dados SQL Server Express LocalDB é instalado independentemente de o Cache de Host Local estar ativado.
Para evitar sua instalação, instale ou atualize o Controller usando o comando XenDesktopServerSetup.exe e inclua a opção /exclude "Local Host Cache Storage (LocalDB)". No entanto, lembre-se de que o recurso Cache de Host Local não funcionará sem o banco de dados, e você não pode usar um banco de dados diferente com o broker secundário.
A instalação deste banco de dados LocalDB não tem efeito sobre se você instala o SQL Server Express para uso como banco de dados do site.
Para obter informações sobre como substituir uma versão anterior do SQL Server Express LocalDB por uma versão mais recente, consulte Substituir SQL Server Express LocalDB.

Configurações padrão após a instalação e atualização do produto

Durante uma nova instalação do Citrix Virtual Apps and Desktops (versão mínima 7.16), o Cache de Host Local é ativado.
Após uma atualização (para a versão 7.16 ou posterior), o Cache de Host Local é ativado se houver menos de 10.000 VDAs em toda a implantação.

Ativar e desativar o Cache de Host Local

  • Para ativar o Cache de Host Local, digite:
    Set-BrokerSite -LocalHostCacheEnabled $true
    Para determinar se o Local Host Cache está ativado, digite Get-BrokerSite. Verifique se a propriedade LocalHostCacheEnabled é True.
  • Para desativar o Local Host Cache, digite:
    Set-BrokerSite -LocalHostCacheEnabled $false
Lembre-se: A partir do XenApp e XenDesktop 7.16, o leasing de conexão (o recurso que precedeu o Local Host Cache a partir da versão 7.6) foi removido do produto e não está mais disponível.

Verificar se o Local Host Cache está funcionando

Para verificar se o Local Host Cache está configurado e funcionando corretamente:
  • Certifique-se de que as importações de sincronização sejam concluídas com êxito. Verifique os logs de eventos.
  • Certifique-se de que o banco de dados SQL Server Express LocalDB foi criado em cada Delivery Controller. Isso confirma que o broker secundário pode assumir o controle, se necessário.
    • No servidor Delivery Controller, navegue até C:\Windows\ServiceProfiles\NetworkService.
    • Verifique se HaDatabaseName.mdf e HaDatabaseName_log.ldf foram criados.
  • Force uma interrupção nos Delivery Controllers. Depois de verificar se o Local Host Cache funciona, lembre-se de colocar todos os Controllers de volta no modo normal. Isso pode levar aproximadamente 15 minutos.

Logs de eventos

Os logs de eventos indicam quando ocorrem sincronizações e interrupções. Nos logs do visualizador de eventos, o modo de interrupção é referido como modo HA.*
Serviço de Sincronização de Configuração:
Durante as operações normais, os seguintes eventos podem ocorrer quando o CSS importa os dados de configuração para o banco de dados do Local Host Cache usando o broker do Local Host Cache.
  • 503: O Serviço de Sincronização de Configuração do Citrix recebeu uma configuração atualizada. Este evento indica o início do processo de sincronização.
  • 504: O Serviço de Sincronização de Configuração do Citrix importou uma configuração atualizada. A importação da configuração foi concluída com êxito.
  • 505: O Serviço de Sincronização de Configuração do Citrix falhou em uma importação. A importação da configuração não foi concluída com êxito. Se uma configuração bem-sucedida anterior estiver disponível, ela será usada se ocorrer uma interrupção. No entanto, ela estará desatualizada em relação à configuração atual. Se não houver nenhuma configuração anterior disponível, o serviço não poderá participar do balanceamento de sessão durante uma interrupção. Nesse caso, consulte a seção Solução de problemas e entre em contato com o Suporte Citrix.
  • 507: O Serviço de Sincronização de Configuração do Citrix abandonou uma importação porque o sistema está em modo de interrupção e o broker do Cache de Host Local está sendo usado para o brokering. O serviço recebeu uma nova configuração, mas a importação foi abandonada porque ocorreu uma interrupção. Este é o comportamento esperado.
  • 510: Nenhum dado de configuração do Serviço de Configuração recebido do Serviço de Configuração primário.
  • 517: Houve um problema de comunicação com o Broker primário.
  • 518: O script de Sincronização de Configuração foi abortado porque o Broker secundário (Serviço de Alta Disponibilidade) não está em execução.
Serviço de Alta Disponibilidade:
Este serviço também é conhecido como broker do Cache de Host Local.
  • 3502: Ocorreu uma interrupção e o broker do Cache de Host Local está realizando operações de brokering.
  • 3503: Uma interrupção foi resolvida e as operações normais foram retomadas.
  • 3504: Indica qual agente de Cache de Host Local é eleito, além de outros agentes de Cache de Host Local envolvidos na eleição.

Forçar uma interrupção

Você pode querer forçar deliberadamente uma interrupção.
  • Se sua rede estiver caindo e voltando repetidamente. Forçar uma interrupção até que os problemas de rede sejam resolvidos evita a transição contínua entre os modos normal e de interrupção (e as frequentes tempestades de registro de VDA resultantes).
  • Para testar um plano de recuperação de desastres.
  • Para ajudar a garantir que o Local Host Cache esteja funcionando corretamente.
  • Ao substituir ou fazer a manutenção do servidor de banco de dados do site.
Para forçar uma interrupção, edite o registro de cada servidor que contém um Delivery Controller. Em HKLM\Software\Citrix\DesktopServer\LHC, crie e defina OutageModeForced como REG_DWORD para 1. Essa configuração instrui o broker do Cache de Host Local a entrar no modo de interrupção, independentemente do estado do banco de dados. Definir o valor como 0 tira o broker do Cache de Host Local do modo de interrupção.
Para verificar eventos, monitore o arquivo de log Current_HighAvailabilityService em C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityService.

Solução de problemas

Várias ferramentas de solução de problemas estão disponíveis quando uma importação de sincronização para o banco de dados do Local Host Cache falha e um evento 505 é postado.
Rastreamento CDF: Contém opções para os módulos ConfigSyncServer e BrokerLHC. Essas opções, juntamente com outros módulos do broker, provavelmente identificarão o problema.
Relatório: Se uma importação de sincronização falhar, você pode gerar um relatório. Este relatório para no objeto que causa o erro. Este recurso de relatório afeta a velocidade de sincronização, então a Citrix recomenda desativá-lo quando não estiver em uso.
Para habilitar e produzir um relatório de rastreamento CSS, digite o seguinte comando:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1
O relatório HTML é postado em C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html.
Após a geração do relatório, digite o seguinte comando para desabilitar o recurso de relatório:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
Exportar a configuração do agente: Fornece a configuração exata para fins de depuração.
Export-BrokerConfiguration | Out-File <file-pathname>
Por exemplo, Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.