Cache de Host Local
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 tolerante a falhas do SQL Server, seguindo as melhores práticas de alta disponibilidade da Microsoft. (Para recursos de alta disponibilidade do SQL Server compatíveis, consulte Bancos de dados.) No entanto, problemas e interrupções de rede podem fazer com que os usuários não consigam se conectar aos seus aplicativos ou desktops.
O recurso Cache de Host Local 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 Cache de Host Local é 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.
Conteúdo dos dados
O Cache de Host Local inclui as seguintes informações, que são um subconjunto das informações no banco de dados principal:
- Identidades de pessoas e grupos que têm direitos atribuídos a recursos publicados do site.
- Identidades de pessoas que estão usando atualmente, ou que usaram recentemente, recursos publicados do site.
- Identidades de máquinas VDA (incluindo máquinas Remote PC Access) 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 servidores NetScaler Gateway e StoreFront™) envolvidas com o site.
- Datas, horários e tipos de atividades recentes das pessoas.
Como funciona
O gráfico a seguir ilustra os componentes do Cache de Host Local e os caminhos de comunicação 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 pessoas a VDAs que estão 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) as informações para um broker secundário no Controller. (O broker secundário também é conhecido como High Availability Service.)
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 do Cache de Host Local. O CSS garante que as informações no banco de dados do Cache de Host Local correspondam às informações no banco de dados do site. O banco de dados do Cache de Host Local é recriado a cada sincronização.
O Microsoft SQL Server Express LocalDB (usado pelo banco de dados do Cache de Host Local) é 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 do Cache de Host Local não pode ser compartilhado entre Controllers. Você não precisa fazer backup do banco de dados do Cache de Host Local. 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).
Durante uma interrupção
Quando uma interrupção começa:
- O broker secundário começa a ouvir e processar solicitações de conexão.
- Quando a interrupção começa, o broker secundário não tem 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 ouvir as informações de conexão, e o Brokering Principal retoma as operações de intermediação. 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 lançamento de novas sessões.
Você também pode acionar intencionalmente uma interrupção. Consulte Forçar uma interrupção para obter detalhes sobre por que 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.) Tendo 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 intermediará as operações 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 e registro VDA de entrada.
Se um broker secundário eleito falhar durante uma interrupção, outro broker secundário é eleito para assumir, e os VDAs se registram no 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 a intermediação, o que faz com que os VDAs se registrem novamente. Neste cenário, o desempenho pode ser afetado durante os registros.
Se você desligar um Controller durante operações normais e depois ligá-lo durante uma interrupção, o Cache de Host Local 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
EnableCssTestModecom 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
- Adicionar uma chave de registro
- Após executar esses comandos, você pode acessar:
- Todos os cmdlets
Get-Broker*.
- Todos os cmdlets
- Você deve primeiro:
- As credenciais do hypervisor 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 apenas 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 Remote PC Access 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.
- Pessoas que usam 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.
- As pessoas podem iniciar aplicativos e desktops apenas 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 que um reinício agendado comece para os VDAs em um grupo de entrega, os reinícios começarão quando a interrupção terminar. Isso pode ter resultados não intencionais. Para obter mais informações, consulte Reinícios agendados atrasados devido a interrupção do banco de dados.
- A preferência de zona não pode ser configurada. Se configurada, as preferências não são consideradas para o lançamento da sessão.
- Restrições de tag 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 tag são configuradas, e a opção de verificação de integridade avançada de uma loja StoreFront está habilitada, as sessões podem falhar intermitentemente ao iniciar.
Suporte a aplicativos e desktops
O Cache de Host Local suporta aplicativos e desktops hospedados em servidor, e desktops estáticos (atribuídos).
O Cache de Host Local suporta VDAs de desktop em grupos de entrega agrupados, da seguinte forma:
-
Por padrão, os VDAs de desktop gerenciados por energia em grupos de entrega agrupados (criados por MCS ou Citrix Provisioning™) que têm a propriedade
ShutdownDesktopsAfterUsehabilitada não estão disponíveis para novas conexões durante um evento de Cache de Host Local. Você pode alterar este padrão para permitir que esses desktops sejam usados durante o Cache de Host Local.No entanto, você não pode confiar no 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 $truePara cada grupo de entrega afetado, execute o seguinte comando do PowerShell:
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $trueA habilitação desse recurso no site e nos grupos de entrega não afeta como a propriedade
ShutdownDesktopsAfterUseconfigurada funciona durante as operações normais. Quando este 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
ReuseMachinesWithoutShutdownInOutageAllowedno nível do Site eReuseMachinesWithoutShutdownInOutageno nível do grupo de entrega, todas as tentativas de lançamento de sessão 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 longo intervalo 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, particularmente 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. Nos testes da Citrix, uma configuração 2x3 (2 soquetes, 3 núcleos) forneceu melhor desempenho do que as configurações 4x1 e 6x1.
Considerações sobre o armazenamento
À medida que as pessoas 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 é devolvido. No entanto, deve haver espaço suficiente 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 sobre o desempenho
Durante uma interrupção, um broker secundário lida com 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 lidar com muito mais solicitações do que o normal durante uma interrupção. Portanto, as demandas da CPU serão maiores. Cada broker secundário no site (zona) deve ser capaz de lidar com 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 efetivamente durante uma interrupção.
- Em uma implantação VDI de várias zonas, até 10.000 VDAs em cada zona podem ser tratados efetivamente durante uma interrupção, até um máximo de 40.000 VDAs no site. Por exemplo, cada um dos seguintes sites pode ser tratado efetivamente 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 retoma o controle.
Você pode diminuir o intervalo diminuindo 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 a rapidez com que os VDAs se registrem.
O tempo que leva 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 Cache de Host Local compartilhe o nome do recurso Cache de Host Local 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 Cache de Host Local é uma implementação tecnicamente totalmente diferente.
Gerenciar o 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 habilitado.
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 afeta 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 é habilitado.
Após uma atualização (para a versão 7.16 ou posterior), o Cache de Host Local é habilitado se houver menos de 10.000 VDAs em toda a implantação.
Habilitar e desabilitar o Cache de Host Local
-
Para habilitar o Cache de Host Local, digite:
Set-BrokerSite -LocalHostCacheEnabled $truePara determinar se o Cache de Host Local está habilitado, digite
Get-BrokerSite. Verifique se a propriedadeLocalHostCacheEnabledéTrue. -
Para desabilitar o Cache de Host Local, 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 Cache de Host Local a partir da versão 7.6) foi removido do produto e não está mais disponível.
Verificar se o Cache de Host Local está funcionando
Para verificar se o Cache de Host Local está configurado e funcionando corretamente:
- Certifique-se de que as importações de sincronização sejam concluídas com sucesso. 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, se necessário.
- No servidor Delivery Controller, navegue até
C:\Windows\ServiceProfiles\NetworkService. - Verifique se
HaDatabaseName.mdfeHaDatabaseName_log.ldfforam criados.
- No servidor Delivery Controller, navegue até
- Force uma interrupção nos Delivery Controllers. Depois de verificar se o Cache de Host Local 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.*
Config Synchronizer Service:
Durante operações normais, os seguintes eventos podem ocorrer quando o CSS importa os dados de configuração para o banco de dados do Cache de Host Local usando o broker do Cache de Host Local.
- 503: O Citrix Config Sync Service recebeu uma configuração atualizada. Este evento indica o início do processo de sincronização.
- 504: O Citrix Config Sync Service importou uma configuração atualizada. A importação da configuração foi concluída com sucesso.
- 505: O Citrix Config Sync Service falhou em uma importação. A importação da configuração não foi concluída com sucesso. 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 configuração anterior disponível, o serviço não poderá participar da intermediação de sessão durante uma interrupção. Neste caso, consulte a seção Solução de problemas e entre em contato com o Suporte Citrix.
- 507: O Citrix Config Sync Service abandonou uma importação porque o sistema está no modo de interrupção e o broker do Cache de Host Local está sendo usado para intermediação. 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 Configuration Service recebido do Configuration Service principal.
- 517: Houve um problema de comunicação com o Broker principal.
- 518: O script Config Sync foi abortado porque o Broker secundário (High Availability Service) não está em execução.
High Availability Service:
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 intermediação.
- 3503: Uma interrupção foi resolvida e as operações normais foram retomadas.
- 3504: Indica qual broker do Cache de Host Local é eleito, além de outros brokers do 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 consequentes tempestades frequentes de registro de VDA).
- Para testar um plano de recuperação de desastres.
- Para ajudar a garantir que o Cache de Host Local esteja funcionando corretamente.
- Ao substituir ou fazer manutenção no 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. Esta 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 os 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 Cache de Host Local 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 de 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 desabilitá-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 broker: 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.