#citrix support

rodam no servidor StoreFront.

Os mais críticos: Credential Wallet. Esse serviço fornece armazenamento seguro para as credenciais do usuário. Se este serviço for interrompido, os usuários não poderão logar e acessar os seus desktops ou aplicações. Usuários logados no StoreFront serão incapazes de lançar novos aplicativos e sessões. Porém, usuários que já estão conectados nas suas aplicações e desktops não são afetados O serviço Credential Wallet é muito importante.

Próximo serviço crítico: World Wide Web Publishing. Este serviço que é o próprio IIS do Windows é quem fornece o acesso aos desktops e aplicativos. Se ele parar, o Storeweb está offline.

Serviço Subscriptions Store. Fornece armazenamento e replicação da Subscriptions do usuário ou das assinaturas que o usuário faz em relação às aplicações. A ideia é que o usuário pegue as aplicações. É uma espécie de Self-Service. Ele vai lá, ele precisa do aplicativo, ele pega dentro do StoreFront. E o StoreFront salva as subscrições, as suas assinaturas. Se esse serviço para, automaticamente o Citrix Receiver não poderá adicionar, remover ou reposicionar as aplicações dentro da loja do StoreFront. Os usuários terão que voltar a adicionar cada um dos aplicativos e todas as alterações feitas dentro da loja do StoreFront não serão salvas. Isso é bastante crítico.

Indo para a parte de Licensing Server e os serviços que rodam no Licensing Server: Licensing é o principal ou Citrix Licensing, ainda o Licensing WMI, Licensing Support, Peer Resolution e Web Services for Licensing.

De todos esses serviços, o Citrix Licensing é o mais crítico, pois ele fornece propriamente o serviço de licenciamento dos produtos Citrix. Se esse serviço parar de funcionar, o modo de licenciamento muda automaticamente para o Grace Period, por isso a importância de monitorar o serviço de licenciamento, o Citrix Licensing.

Após o Grace Period, que é de 30 dias, os usuários não conseguirão mais conectar nas aplicações e desktops publicados. Aqui uma observação: Grace period = 30 dias; Supplemental grace period = 15 dias. Nós já falamos de Supplemental grace period em aulas anteriores desse mesmo curso, tá? É só para não confundir.

Então esses são os serviços e a importância de cada um dos serviços dentro do Delivery Controller, do Virtual Delivery Agent, do StoreFront e do Citrix Licensing.

Vamos mostrar na prática a lista e os serviços que rodam no Delivery Controller. Vamos alternar para o nosso laboratório. Pronto! Estou aqui logado no servidor que é o meu Delivery Controller. Veja os serviços que nós falamos, desde o Citrix AD Identity Service, Citrix Broker Service e demais serviços. Todos estão aí com o status de running. Nós falamos que não é suficiente ver esses status, mas observar também a partir do Power Shell.

Por aqui eu posso ir pelos services do Windows ou o comando services.msc. Deixa eu demonstrar aqui para você: services.msc. Eu posso aqui gerenciar esses serviços, que são completamente integrados à parte de serviços do Windows.

O próximo passo é falarmos sobre a parte de Power Shell e verificação dos serviços a partir do Power Shell. Então, vejo vocês! Até a próxima aula! Tchau!

Citrix, crescer em termos de conhecimento e em termos de evolução da solução Citrix. Por isso que a gente tem que falar tanto de conceitos, da parte de serviços, de arquitetura, enfim.

E agora nós vamos falar sobre Power Shell, os comandos Citrix do Power Shell. É muito bacana. Praticamente tudo pode ser feito via Power Shell. O Power Shell é a interface de linha de comando da Microsoft que veio para ficar definitivamente, sabemos disso. Todos os produtos High End, todos os produtos líderes, tem integração com o PowerShell. O Citrix também tem. São centenas e centenas de comando que servem para monitorar, para verificar e para alterar o site do Citrix XenDesktop. Outros produtos como Microsoft Exchange e tantos outros também possuem suporte ao Power Shell. Por isso nós não podemos deixar de fora, temos que conhecer como podemos extrair e utilizar o Power Shell.

Antes de mais nada, você sabe que nós podemos abrir o Power Shell a partir da própria console do Citrix Studio. Nós falamos isso em algumas aulas anteriores e abrimos o Power Shell. A diferença é que quando você abre o Power Shell a partir do Citrix Studio, ele já carrega os módulos necessários do Citrix dentro do Power Shell. Porque o Power Shell é uma linha de comando modular. Quando você abre o Power Shell, ele carrega o módulo básico. E então quando você precisa interagir com o Citrix, você carrega os módulos do Citrix. Se você precisa interagir com, por exemplo, a parte de virtualização do VMware, você carrega como os módulos Power Shell do VMware. Mas, esse processo é muito fácil.

Eu enumerei aqui as etapas que precisam ser executadas para carregar os módulos necessários dentro do Power Shell. Inicialmente usamos o Power Shell a partir do próprio Delivery Controller. Porque ele possui os módulos instalados. O que precisamos fazer é abrir o Power Shell, rodar o comando Get-PSSnapin -Registered. Isso para visualizar todos os Snapins que estão registrados nesse servidor. Nessa listagem ele vai mostrar o Snapin Citrix.

Depois que a gente obtém o Snapin, vamos rodar o comando Add-PSSnapin Citrix* para que ele carregue todos os Snapins Citrix. A partir desse momento nós carregamos dentro da nossa sessão do Power Shell os módulos necessários para administrar e gerenciar o Citrix, o site do nosso Citrix.

E aí você pode brincar com o comando (Get-Command -Module Citrix*).count, só para ele mostrar para você quantos comandos tem disponível. Eu executei este comando e você pode ver aqui que nós temos 614 comandos nesse momento que estão disponíveis. É muita coisa! A gente vai ver alguns e depois você pode brincar para o resto da vida com tantos comandos Citrix integrados ao Power Shell.

Sabemos que temos 614 comandos. Quais são esses comandos? Para isso, nós vamos executar o comando Get-Command -Module Citrix* e, dessa forma, nós vamos obter a relação completa de todos os comandos para gerenciamento do Citrix via Power Shell. É essa lista enorme. Você não vai conseguir decorar todos esses comandos num primeiro momento, então vai conhecendo um por um. E as dicas que eu coloco aqui é justamente para você conhecer esses comandos.

No Power Shell, existe o comando chamado Get-Help que você usa para obter um manual naquele momento de cada um dos comandos. Então, por exemplo, se você executa Get-Help Get-XDSite -Full. Esse comando vai mostrar para você o manual do comando Get-XDSite. No Linux, para quem conhece, você teve o contato com o Linux, é como se você tivesse executando o comando man, que é de manual. Aqui no Power Shell, é o Get-Help (sempre tem um hífen para separar o Get ou o Add). Enfim, ok, você obtém então o manual e você pode ler os parâmetros aceitáveis por esse comando, qual a função dele, o que ele faz, os exemplos de uso e etc.

Depois nós vamos executar comandos como Get-XDSite, Get-BrokerCatalog, Get-AcctDBConnection. São todos comandos Citrix que retornam informações do nosso ambiente Citrix. Ao término da nossa parte conceitual, nós vamos para o Power Shell e vamos executar esses comandos. Por enquanto, saiba que ao abrir o Power Shell, você tem que adicionar o Snapin Citrix e na sequência você pode executar cada um dos 614 comandos disponíveis para o Power Shell.

O Power Shell é muito útil, tanto na parte de verificação de troubleshooting e verificação manual, como também na integração de alguma solução de gerenciamento ou ferramenta de monitoramento para que seja possível monitorar aspectos mais específicos do Citrix, de forma integrada com a sua ferramenta de monitoramento. Se você tem no seu ambiente, por exemplo, o Microsoft System Center Operations Manager, você pode integrar através do Power Shell, com o monitoramento avançado do seu ambiente Citrix. Eu faço até mesmo com ferramentas mais simples, como por exemplo, o PRTG.

E após carregar o Snapin Citrix, nós podemos obter alguns dos comandos que verificam o status de cada um dos serviços que nós já falamos. Aqui nesse slide nós temos os comandos de Power Shell para verificar o status dos serviços do nosso Delivery Controller. São eles: Get-BrokerServiceStatus, para ver o status do serviço do Broker; Get-ConfigServiceStatus, para a parte de Configuration; Get-HypServiceStatus, para o serviço Host Service; Get-AcctServiceStatus, para o serviço de AD Identity; Get-ProvServiceStatus, para o serviço MCS; Get-MonitorServiceStatus, para a parte de Monitoring; Get-AdminServiceStatus, para Delegated Admin; Get-LogServiceStatus, para a parte de Configuration Logging; Get-SFServiceStatus, para a parte de StoreFront; Get-EnvTestServiceStatus, para a parte de Test Service.

Então esses comandos vão muito além da parte de services do Windows. Ele não só indica se o serviço está em execução ou não. Ele é capaz de nos mostrar mais informações.

E vejam no próximo slide, através dessas duas tabelas, que eu tenho os status que são reportados para cada um desses comandos do Power Shell. Se nós formos na parte de services do Windows, nós só vamos ter o status running, stopped… só, basicamente esses. Aqui, não. Aqui nós vamos ter diversos status importantes. Eu destaquei em vermelho os status mais críticos em termos de problema e em amarelo alguns status que não deixam o ambiente indisponível.

Quais são esses status? OK, indica que o Broker está conectado ao banco de dados, que é um banco de dados válido e o serviço está em execução, ou seja, está tudo bem. Essa tabela de status não é só para o comando Get-BrokerServiceStatus, ele serve para cada um daqueles comandos anteriores em relação a Service Status. O status DBUnconfigured indica que o Broker não possui uma conexão configurada com o banco de dados. O status DBRejectedConnection indica que o banco de dados rejeitou o logon a partir do serviço do Broker. Isso significa que as credenciais de autenticação do banco de dados estão inválidas ou o banco de dados ainda não está instalado. InvalidDBConfigured significa que o schema está ausente.

DBNotFound indica que o banco de dados especificado nas configurações da conexão não pode ser localizado. O DBMissingOptionalFeature indica que o broker está conectado ao banco de dados, é um banco de dados válido, mas ele não possui todas as funcionalidades exigidas para um melhor desempenho. Então, nesse caso, recomenda-se a atualização do banco de dados. DBMissingMandatoryFeature indica que o Broker está conectado ao banco de dados, é um banco de dados válido, mas ele não possui todas as funcionalidades que são necessárias para o correto funcionamento do Broker. Isso significa que uma atualização do banco de dados é necessária.

DBNewerVersionThanService. Esse status indica que o Broker é muito antigo para usar este banco de dados, significa que uma nova versão do Broker é necessária. Isso acontece quando você atualiza a parte de banco de dados do Citrix, mas não atualiza o serviço do Broker. DBOlderVersionThanService é exatamente o contrário do que eu expliquei anteriormente, ou seja, o banco de dados é que é muito antigo para usar o Broker.

PendingFailure. É um status de falha transitória. Quando ocorre uma falha, primeiro ele fica como PendingFailure, até que o Broker identifica e determina uma falha permanente. Já o status Failed indica que a conectividade entre o Broker e o banco de dados foi perdida.

Além de todos esses status, que só são possíveis através dos comandos de Power Shell... e olha que beleza, a gente pode integrar isso a uma ferramenta de monitoramento. Então a gente pode ter esse status numa console de monitoramento. Eu faço isso constantemente. Isso é maravilho! Principalmente quando você quer entregar uma console de gerenciamento ou um Dashboard de gerenciamento e monitoramento para o seu coordenador, para o seu gerente. Fantástico! Isso é realmente muito interessante.

Ok, agora nós vamos lá para o Power Shell rodar alguns desses comandos.

 Delivery Controller. Veja que através da minha console do Citrix Studio, selecionando aqui o meu site, o CitrixStudio, que é NyttLab, no nosso caso, eu tenho uma aba Power Shell. E aí, no Power Shell, eu posso lançar o Power Shell a partir da console do Citrix Studio. Isso significa que ele já carrega as módulos necessários (Snapins) e eu tenho todos os comandos do Power Shell.

Porém, quando eu quero automatizar algumas integração em nível de Citrix e Power Shell, eu tenho que carregar isso manualmente. Então nós vamos abrir o Power Shell manualmente. Vamos aqui no menu Iniciar e localizar aqui o Power Shell. Está aqui o Windows Power Shell. Ok.

Estamos aqui diante do nosso Power Shell. Nesse momento eu não tenho carregado os módulos ou os Snapins do Citrix. Vamos listar aqui os nossos Snapins com o comando Get-PSSnapin. Eu utilizo muito a tecla TAB. Dentro do Power Shell, a tecla TAB completa o comando. E vamos usar o parâmetro -register. Isso! Esse comando vai trazer os Snapins que estão registrados nesse servidor.

A lista é grande, mas observem que eu tenho aqui alguns Snapins do tipo Citrix. Vejam, há vários Snapins: Citrix.Broker.Admin.V2, Citrix.Common.Commands, Citrix.Common.GroupPolicy, Citrix.Configuration.Admin.V2 e por aí vai! São diversos Snapins Citrix. Ok.

Eu vou então carregar todos. Vamos limpar aqui a tela do nosso Power Shell. Deixa eu só sair da pasta do usuário. Ok. Agora, vamos adicionar este Snapin com o comando Add-PSSnapins, sempre utilizando a tecla TAB para auxiliar na digitação, para ganharmos tempo. E eu vou adicionar todos os Snapins dos tipo Citrix. Eu vou usar aqui a palavra Citrix com asterisco no final. Enter. Neste momento ele carregou todos os Snapins Citrix.

Agora sim, para brincar eu vou usar aquele comando entre parênteses que é (Get-Comand -Module Citrix*).Count. É só para ele devolver aqui quantos comandos que existem dentro dos módulos do Citrix. Temos aí... 614 comandos. Muito bem. Vamos listá-los?

Get-Comand... tecla TAB sempre. Obtenha os comandos que são do módulo -module citrix*. Enter. Observem a lista imensa de comandos. Eu vou usar aqui o paginador pipe more, para que seja possível paginá-lo. Eu tenho então aqui o tipo de comando (Cmdlet), o nome do comando, por exemplo, Add-AdminRight, e eu tenho o nome do módulo respectivo para este comando. Nesse caso, é o módulo Citrix.DelegatedAdmin.Admin.V1. Então essa é a lista de todos os comandos.

Para obter o help, vamos usar o mesmo exemplo que a gente usou na parte conceitual. Eu uso o comando Get-Help, sempre usando a tecla TAB, espaço Catch-XDSight, que é o comando, com um parâmetro no final -full, para que tenha todo o manual deste comando. Vamos usar aqui o paginador pipe more para a gente conseguir paginar esse resultado. Então aqui nós temos o manual do comando Get-XDSight, o nome do comando, a sinopse do comando, obtenha os atributos do site do XenDesktop, a sintaxe do comando, a descrição do comando, os parâmetros válidos para este comando e aí vai, né? A saída do comando e o que ele retorna, os exemplos de uso e links relacionados. Veja que esse Get-Help pode ser muito útil.

Aliás, vamos usar esse comando, né? Get-XDSight. Vamos dar Enter. Veja que o comando Get-XDSight trouxe a lista dos meus Controllers. Eu só tenho um controlador, por enquanto. O banco de dados... eu tenho aqui o banco de dados do site, do logging e do monitoring. Nós já falamos em algumas aulas anteriores sobre banco de dados e também reforçamos que nós vamos aprender a fazer algumas configurações em relação ao banco de dados Citrix no curso mais avançado. Eu tenho o tipo de licença que é usado no meu site, que é Platinum. E eu tenho alguns atributos de metadatas do meu site. E ainda eu tenho aqui, por final, o nome do meu site do Citrix XenDesktop. Esse é o comando Get-XDSight que traz todas essas informações.

Vamos explorar aqui outro comando: Get-Acct. Observe que quando eu uso a tecla TAB, ele completa o comando. Então, pressionei TAB, ele trouxe Get-AcctADAccount. Aí eu vou pressionando TAB, ele traz o próximo comando Get-AcctDBConnection. Vamos rodar esse comando. Ele traz a string de conexão com o meu banco de dados. Então com esse comando eu consigo saber qual é o banco de dados que está atendendo o ambiente Citrix. É o servidor, no meu caso, MSQL1. E qual o nome do banco de dados ou o inicial Catalog Citrix NyttLab. E se as partes de segurança estão integradas. Nesse caso, está. Então esse é o comando Get-AcctDBConnection.

E eu posso explorar outros comandos, né? Get-ADAccount. Vamos rodar o comando Get-AcctADAccount com o paginador more. Ele traz a relação de máquinas que estão nos meus catálogos. Eu tenho aqui três máquinas. Então eu tenho três blocos de informações, um para cada máquina, onde eu tenho as seguintes informações: qual é o nome do meu pool (então é o nome meu catálogo: Windows 7, 32 bits), quais são os identificadores (UIDs, GUIDs) dessa máquina, qual é o nome da conta da máquina lá no Active Directory, qual é a OS ID da minha máquina, qual o domínio que ela pertence, qual o controlador de domínio que está gerenciando essa máquina (no meu caso, MDC1). E outros: se a máquina está bloqueada, qual que está o status da máquina. Eu tenho para todas as máquinas que são gerenciadas pelo XenDesktop essas informações. Porque funciona de forma integrada. Então o comando Get-AcctADAccount traz todas essas informações.

Dezenas e centenas de outros comandos podem ser usados. Vamos explorar aqui mais um: Get-Broker... vamos encontrá-lo aqui com a tecla TAB... Get-BrokerCatalog. Vamos listar aqui os nossos catálogos. Deixa eu paginar com o pipe more. Eu tenho dois catálogos. Este é o primeiro catálogo, eu tenho um bloco de informações para esse catálogo. O nome do catálogo: Windows 2012 R2 Catalog. Tipo de provisionamento: manual. PersistUserChange, as mudanças feitas pelo usuário são salvas localmente. E por aí vai! É um catálogo do tipo randômico, a alocação é randômica.

Vamos aqui para o segundo catálogo? Para a gente ver algumas diferenças. Meu segundo catálogo também é randômico. Cadê o nome do meu catálogo? Aqui, nome: Windows 7 32 bits. Esse é o catálogo que eu tenho integrado ao meu Hypervisor, ao meu XenServer. Esse é um catálogo também randômico. Tipo de provisionamento do meu catálogo: enquanto o primeiro catálogo estava como manual, aqui o meu catálogo de Windows 7 é gerenciado pelo Machine Creation Services, que é o serviço que gerencia a criação das máquinas virtuais. Tipo de sessão suportada por esse catálogo: Single Session. É Single Session por quê? Sendo o Windows Desktop, só suporta uma sessão por vez. PersistUserChange: enquanto o meu primeiro catálogo salvava localmente, esse catálogo simplesmente descarta todas as mudanças que são feitas na máquina. Isso significa que se o usuário logar no Virtual Desktop, instalar aplicativos, baixar arquivos localmente, assim que ele efetuar logoff, essa máquina é reiniciada e todas essas mudanças são descartadas. Este é um catálogo não persistente. Então este é o comando Get-BrokerCatalog, que mostra as informações dos meus catálogos.

Só para exemplificar um pouco do uso do Power Shell. É claro que existem centenas de comandos. Nós vamos ter em próximos cursos aulas mais específicas de Power Shell para tratar especificamente alguns comandos, algumas tarefas administrativas através de comando Power Shell. Nessa aula é tão somente para a gente ter uma visão básica de como usar o Power Shell e como utilizar os comandos Citrix através do Power Shell.

Então é isso. Essa é a nossa aula sobre o uso dos comandos Citrix dentro do Power Shell. Na próxima aula, vamos falar sobre os Logs do Citrix e como habilitá-los e as ferramentas super interessantes do Citrix para a gente poder fazer troubleshooting na nossa sessão e no nosso ambiente Citrix. Vejo você lá, heim? Tchau, até lá!!

 infra-estrutura Citrix é uma infra-estrutura complexa, especialmente porque ela é uma infra-estrutura que interage com todo o ambiente da sua rede: File Server, Storage, virtualização, Firewall, DMZ, balanceamento de carga, etc. Ela tem uma integração bem ampla.

Muitas vezes pode ser complexo para diagnosticar um problema, para tratar um chamado de suporte. Mas, não se preocupe. Você não está sozinho. A Citrix tem criado dezenas e dezenas de ferramentas de apoio. E uma das coisas mais interessantes que eu tenho visto nos últimos anos da Citrix - eu trabalho com Citrix já há uns dez ou doze anos -, mais recentemente, nos últimos três ou quatro anos, a Citrix tem sim investido no desenvolvimento de ferramentas e também na padronização de logs de eventos que podem ajudar na identificação de problema e na correção de problemas mais rápido.

Em se tratando de logs, vamos começar falando do EventViewer. Você sabe, o comando eventvwr.msc do Windows serve para abrir a parte de EventViewer. E lá nós temos diversos logs, especialmente em Application / System, nós temos onde normalmente a gente tem logs do Citrix.

Os primeiros logs. Mas, os logs do Citrix não estão limitados ao EventViewer. Mas, é ali onde a gente começa a analisar os logs do Citrix. Então no EventViewer nós temos diversos logs e uma das coisas legais é que a Citrix lançou um documento chamado Event Log Messages. Isso está documentado no CTX138739, de XenDesktop e XenApp, e no CTX126407, para a parte de BNIStack ou do Provisioning Service. Esses dois documentos trazem uma explicação mais detalhada de cada um dos tipos de logs gerados no EventViewer pelo serviço Citrix.

Eu coloquei aqui um print que mostra exatamente um determinado log. Eu tenho aqui um log, apenas um log informativo. Está aqui. Foi gerado nessa data, nesse horário, do serviço Citrix Configuration Service. O que tem nesse log? Primeiro tem o Event ID, que é o número padronizado de logs. Então o Event ID é o evento 1.200, do log Citrix Configuration Service. E no log contém a seguinte informação: The connection to the database has been restored (a conexão com o banco de dados foi restaurada). Isso representa que em algum momento houve uma falha, e agora nesse momento foi restaurada essa conexão.

O que é bacana é que nesse documento que eu falei, no CTX 138739, existe uma tabela que mostra, veja só essa tabela, o nome do arquivo é o EventLogMessages.PDF, existe uma tabela que explica cada um dos Events IDs. Então o Event ID 1200, eu tenho toda a explicação, é apenas um log informativo, representando que a conexão entre o Citrix Broker Service e o banco de dados foi restaurada. Esse Event ID tem a ver com Database Conectivity Restored, associado com o serviço do Citrix Broker. E ele é gerado na parte de log de aplicação, no Application Log. Então, combinando o Event Viewer com a tabela de logs, você tem uma forma mais interessante de identificar o verdadeiro significado daquele log. E existem alguns logs que - venhamos e convenhamos - são complexos para interpretar. Até porque o cara escreveu mal a mensagem.

Então isso é um negócio bacana, mas como eu falei, os logs do Citrix não estão limitados ao Event Viewer. É claro que o Event Viewer é um dos lugares onde podemos olhar na hora de fazer um troubleshooting de um determinado problema Citrix.