Administração do Windows

Implantando aplicativos com os Serviços de Terminal

Greg Shields

Visão geral:

• As vantagens dos RemoteApps
• Disponibilizando aplicativos para os usuários
• Avaliando a implementação dos serviços de terminal
• Assegurando uma experiência positiva para o usuário

Conteúdo

Adeus, áreas de trabalho; olá, RemoteApps
Iniciando aplicativos pela Web
Iniciando aplicativos pela área de trabalho
A experiência do usuário
RemoteApps = Desempenho previsível
Você tem opções

Você pode encontrar muitas instruções na Internet e em sua livraria local sobre como instalar e usar os Serviços de Terminal. Mas o que faz muita falta em muitos desses produtos são informações sobre a melhor maneira de obter aplicativos remotos para seus usuários. Com um esforço mínimo, você pode implantar rapidamente, em seu ambiente, um servidor de terminal que hospede seu conjunto de aplicativos necessários. Contudo, fazer isso de modo a atender às expectativas dos usuários exige pensar um pouco mais.

Se você é um administrador de servidor de terminal, vamos voltar um pouco à sua infra-estrutura de aplicativos remotos e considerar o seguinte: Como você implanta os aplicativos? Você fornece aos usuários áreas de trabalho remotas ou TS RemoteApps? Os usuários acessam os aplicativos por meio de arquivos estáticos de protocolo RDP, página da Web ou atalhos da área de trabalho?

No final das contas, como você avalia a experiência dos usuários ao usar aplicativos dos serviços de terminal? Com os aprimoramentos dos Serviços de Terminal agora disponíveis no Windows Server 2008, as melhores respostas a essas importantes perguntas talvez surpreendam você.

Adeus, áreas de trabalho; olá, RemoteApps

Com um conjunto significativamente expandido de serviços e recursos, o Windows Server 2008 acaba com parte do sofrimento da administração de serviços de terminal. A lista do que é novo e do que foi alterado foi abordada na edição de novembro de 2008 da TechNet Magazine, em que Joshua Schnoll detalha os novos recursos obtidos com a migração para o Windows Server 2008 ("Virtualização de apresentação com os Serviços de Terminal aprimorados"). Desses recursos, comprovadamente o mais significativo é a nova capacidade do servidor de terminal de implantar aplicativos individuais para usuários em vez de áreas de trabalho completas.

Chamados de TS RemoteApps, esses aplicativos individuais aparecem para os usuários como se o aplicativo tivesse sido instalado diretamente em suas áreas de trabalho locais. Quando um usuário clica para iniciar um RemoteApp, ele vê em seu computador local apenas o aplicativo propriamente dito. Não há barra Iniciar nem áreas de trabalho duplicadas se intrometendo, o que deixa claro que você está interagindo com um sistema não-local. Dependendo da implementação e das expectativas dos usuários, um TS RemoteApp pode ser melhor do que implantar uma área de trabalho completa, simplesmente porque ele faz com que esses aplicativos pareçam uma parte normal da experiência na área de trabalho local.

No Windows Server 2008, criar um novo TS RemoteApp é um processo simples, usando-se o Gerenciador de TS RemoteApp encontrado em Ferramentas administrativas. Um clique no link Adicionar programas RemoteApp inicia o Assistente do RemoteApp, que consulta o armazenamento do WMI (Instrumentação de Gerenciamento do Windows) para identificar uma lista de aplicativos potenciais já instalados no servidor. Na Figura 1 é mostrado um exemplo dessa lista.

Figura 1 O Assistente do RemoteApp enumera os aplicativos instalados no servidor de terminal

Selecione na lista os aplicativos que deseja criar como RemoteApps e clique em Avançar. Se o aplicativo desejado não estiver disponível, clique no botão Procurar e localize o arquivo EXE principal. Esse é o arquivo EXE que você normalmente usa para iniciar o aplicativo. Conclua o assistente, e seu aplicativo remoto está pronto para implantação.

Se clicar com o botão direito do mouse para exibir as propriedades de seu novo RemoteApp, você verá que há algumas opções que podem ser ajustadas. Além de poder modificar o nome, o local, o ícone e informações do alias, você também pode inserir argumentos de linha de comando. Isso é útil para aplicativos que, no momento da inicialização, exijam um conjunto de argumentos para funcionar corretamente, mas também pode ser usado em conjunto com alguns aplicativos a fim de criar links para conteúdo remoto.

O que muitos administradores talvez não percebam imediatamente é que migrar para os TS RemoteApps permite mais do que meramente apresentar aplicativos na tela de um usuário. Com um pouco de mágica, também é possível usar os RemoteApps para iniciar automaticamente conteúdo pré-configurado.

Por exemplo, vamos supor que, em vez de implantar um aplicativo para os usuários, você queira implantar um documento específico. Em vez de criar um RemoteApp que conecte os usuários a um aplicativo Microsoft Office Word ou Access vazio, por exemplo, você quer conectá-los a determinado documento do Word ou banco de dados do Access. Nesses casos, você pode fazê-lo inserindo o nome do documento como argumento, após o EXE principal do aplicativo. Assim, se você quiser criar uma conexão com seu banco de dados PTO (banco de horas) baseado no Access 2007 e armazenado em \\fileServer\fileShare\CompanyPTO.accdb, basta criar um novo RemoteApp chamado "Banco de dados PTO" e inserir a localização do documento como argumento de linha de comando. Agora, quando um usuário clicar duas vezes para iniciar o aplicativo Banco de dados PTO, ele será direcionado automaticamente para o Access, com o banco de dados correto já pré-carregado.

Como você pode ver, criar conexões com um conteúdo remoto é outra forma de expandir a utilidade dos RemoteApps. Mesmo assim, para iniciar, os usuários ainda precisam, em todos os RemoteApps, de links para os ícones. Nas próximas seções, abordarei alguns modos pelos quais os serviços de terminal do Windows Server 2008 fazem isso.

Iniciando aplicativos pela Web

O serviço da nova função Acesso via Web TS permite a hospedagem de atalhos para o aplicativo em uma página da Web pré-configurada. O serviço dessa função integra-se aos servidores de terminal do ambiente para fornecer um local único ao qual os usuários podem ir para localizar e iniciar seus aplicativos. A Figura 2 mostra como essa página da Web aparece para os usuários.

Figura 2 A página da Web do Acesso via Web TS enumera os RemoteApps implantados

Para criar esse tipo de página, instale a função Acesso via Web TS em um servidor IIS e então adicione a conta de computador do servidor de Acesso via Web TS ao Grupo global de computadores do Acesso via Web TS no domínio. Observe que, em ambientes pequenos, você pode instalar o Acesso via Web TS em um servidor de terminal de uma solução de servidor único.

Depois de instalado o RemoteApp, a ativação dele para Acesso via Web TS é feita clicando-se com o botão direito do mouse no RemoteApp do Gerenciador de TS RemoteApp e selecionando Mostrar no Acesso via Web TS. Usuários com a versão 6.1, ou posterior, do cliente de área de trabalho remota podem então navegar até https://serverName/ts para exibir uma lista dos atalhos para os aplicativos. Um clique em qualquer um dos atalhos apresentados inicia automaticamente o RemoteApp.

O Acesso via Web TS é um modo fácil de apresentar uma interface amigável para a localização e inicialização de aplicativos. Isso é particularmente útil quando os aplicativos ou as versões mudam regularmente; a atualização do site envolve apenas ocultar o link para o aplicativo ou versão anterior no Acesso via Web TS e mostrar o novo link quando estiver instalado.

No entanto, essa ferramenta tem algumas limitações. Primeiro, não há mecanismo interno para limitar os aplicativos que um usuário pode acessar. Qualquer RemoteApp que tenha sido criado no servidor de terminal e estiver visível no Acesso via Web TS será visto por todos os usuários autenticados.

O segundo problema tem relação com o modo pelo qual os usuários normalmente trabalham com seus aplicativos. Quando você quer iniciar um aplicativo como o Word, com que freqüência de fato clica no atalho para o aplicativo? Aposto que não é muito freqüente. É mais provável que você clique duas vezes em um documento existente do Word, para iniciar o aplicativo com o documento pré-carregado.

Infelizmente, o Acesso via Web TS não tem suporte a esse método de iniciar aplicativos. Para aqueles que estão acostumados a clicar duas vezes em documentos para iniciar o aplicativo vinculado, o Acesso via Web TS talvez não seja uma solução aceitável. Não se assuste, no entanto, pois a seguir é abordada outra opção mais útil para esse caso.

Iniciando aplicativos pela área de trabalho

Para os usuários que queiram clicar duas vezes em documentos para iniciar o aplicativo, os serviços de terminal agora oferecem a possibilidade de "instalar" na área de trabalho o link para o aplicativo remoto. Esse processo, na verdade, inclui o arquivo RDP do RemoteApp em um pacote do Windows Installer — um arquivo MSI — que é instalado posteriormente nas áreas de trabalho do ambiente.

Esse

Ao mesmo tempo, o MSI instalado pode modificar as associações das extensões de arquivo na área de trabalho para redirecionar um arquivo que tenha sido clicado duas vezes para o RemoteApp associado, no servidor de terminal. A Figura 3 mostra como as associações das extensões de arquivo foram modificadas em um sistema cliente depois que um RemoteApp do Word foi instalado. Agora, clicar duas vezes em qualquer uma das extensões comuns de arquivos do Word iniciará o Word por meio da Conexão de Área de Trabalho Remota.

Figura 3 Associações de extensões de arquivo que foram alteradas para iniciar a Conexão de Área de Trabalho Remota

Para criar um pacote do Windows Installer a partir de um RemoteApp existente, em primeiro lugar navegue até o Gerenciador de TS RemoteApp. Clique com o botão direito do mouse no RemoteApp desejado e selecione Criar pacote do Windows Installer. Por padrão, todos os pacotes do Windows Installer criados são armazenados em C:\Arquivos de programas\Packaged Programs, mas esse local pode ser alterado no Assistente do RemoteApp. Também são configuráveis no assistente o nome e a porta do servidor que hospedará o RemoteApp, bem como a autenticação do servidor, as configurações de certificado e as configurações do Gateway do TS.

As configurações relativas ao local do aplicativo após a instalação em uma área de trabalho candidata são mostradas na Figura 4. Como você pode ver, é possível criar um atalho na área de trabalho, bem como em um local na pasta do menu Iniciar. A caixa de seleção mais importante dessa tela está na parte inferior. É a caixa de seleção para assumir as configurações do cliente (Take over client settings), e ela faz com que todas as associações das extensões de arquivo do RemoteApp na área de trabalho local sejam associadas ao servidor de terminal. Se você quiser a opção de clicar duas vezes em documentos para iniciar o aplicativo correspondente hospedado no TS, essa caixa de seleção deverá estar selecionada. Clique em Avançar e em Concluir para finalizar o assistente.

Figura 4 A criação de um pacote do Windows Installer permite a associação das extensões de arquivos cliente

Obviamente, a vantagem de usar a instalação na área de trabalho para conectar usuários a aplicativos é que isso não exige alteração no comportamento do usuário. Quando os aplicativos estiverem instalados, os usuários poderão clicar duas vezes nos documentos para iniciar os aplicativos, como sempre fizeram.

No entanto, esse método gera um inconveniente: a administração da área de trabalho extra. Cada RemoteApp usado dessa forma deve ser instalado em cada área de trabalho que solicite acesso. Esse processo é facilitado pela Instalação de Software da Diretiva de Grupo — que será abordado a seguir — mas ainda é uma dor de cabeça a mais no gerenciamento. Além disso, quando os aplicativos são alterados, é provável que os RemoteApps instalados em cada área de trabalho também precisem ser alterados.

Uma vez que um pacote do Windows Installer tenha sido criado, o processo de instalá-lo por meio da Instalação de Software da Diretiva de Grupo não é difícil de configurar. Primeiro, crie um compartilhamento de arquivo que possa ser acessado pela Diretiva de Grupo. Um bom lugar para esse compartilhamento de arquivo em um cenário de servidor de terminal único talvez seja a pasta padrão C:\Arquivos de programas\Packaged Programs do servidor de terminal. Assegure-se de que os direitos tenham sido adequadamente atribuídos à pasta e ao compartilhamento, para que os clientes possam acessar esse compartilhamento durante o processamento da Diretiva de Grupo. Em seguida, crie um novo GPO (Objeto de Diretiva de Grupo) e navegue até Configuração do computador|Diretivas |Configurações de software|Instalação de software. Clique com o botão direito do mouse em Instalação de software e escolha Novo|Pacote. Na caixa de diálogo resultante, localize o arquivo MSI criado para o RemoteApp. Quando for perguntado pelo método de implantação, escolha Avançado.

Nesse ponto, você tem uma opção. Como os RemoteApps têm instalações muito pequenas, que instalam na pasta C:\Arquivos de programas\RemotePackages pouca coisa a mais do que arquivos RDP e ícones, convém selecionar a opção para Desinstalar esse aplicativo caso ele saia do escopo de gerenciamento. Com essa opção selecionada, a qualquer momento em que o GPO seja alterado ou caso o computador seja levado para outra UO em que o GPO não se aplique, o RemoteApp será automaticamente removido do computador. Habilitar essa opção facilita o processo de remover um RemoteApp, já que os computadores e os aplicativos entram e saem do escopo de gerenciamento.

A experiência do usuário

Implantar aplicativos por meio desses mecanismos é ótimo, mas a administração de serviços de terminal é mais do que criar e implantar aplicativos. Igualmente importante é assegurar que sua implementação atenda às necessidades dos usuários. Em qualquer discussão sobre entrega de aplicativos, é essencial considerar uma métrica subjetiva de desempenho para capturar a qualidade da experiência do usuário. Embora seja difícil quantificar com medições objetivas, implementações eficazes de serviços de terminal devem analisar a satisfação total dos usuários como medida para definir o êxito.

Explicando: os usuários podem ser um grupo particularmente difícil de lidar, principalmente quando compartilham recursos no mesmo servidor. Nos serviços de terminal, vários usuários reúnem-se em um único servidor para compartilhar aplicativos instalados nele. A aglutinação de um grande número de usuários em pequenos grupos de servidores facilita o gerenciamento dos aplicativos devido à redução no total de aplicativos. Uma quantidade menor de aplicativos a gerenciar significa menos correções, um ambiente mais controlado e menos pontos de ação administrativa.

Essa consolidação de usuários exige que o administrador do servidor de terminal faça o papel de babá do sistema. O administrador bem-sucedido gerencia o farm de servidores de terminal observando o comportamento dos usuários no sistema e, proativamente, aplicando mudanças. Essas mudanças chegam como reconfigurações e bloqueios para garantir que o mau comportamento de um usuário não afete a experiência de outros.

Por exemplo, administradores eficientes de servidores de terminal configurarão alertas de desempenho para notificá-los quando a utilização do processador chegar a um nível muito alto e permanecer nele. Muitas vezes, esse tipo de comportamento indica que um processo levou um processador ao pico ou que um usuário iniciou uma ação que usa muitos recursos do sistema compartilhado. Rastrear e interromper o processo ofensivo é apenas o primeiro passo para resolver o incidente. Descobrir por que aquele processo se comportou daquela maneira é a solução de longo prazo para o problema.

Nesse tipo de situação, a idéia é assegurar que um aplicativo remoto funcione tão bem quanto se espera que funcione na área de trabalho local. A barra lateral, "Principais contadores de desempenho dos serviços de terminal", ilumina algumas medições do PerfMon que o colocarão na pista certa.

RemoteApps = Desempenho previsível

Um RemoteApp é, na verdade, uma sessão de serviços de terminal em que a largura e a altura da sessão são exatamente iguais às do aplicativo iniciado. O resultado é que o aplicativo remoto parece local porque os limites da sessão nunca ultrapassam os limites do próprio aplicativo.

A implementação da Microsoft para os RemoteApps é muito mais engenhosa do que a explicação anterior pode sugerir. Do ponto de vista dos recursos necessários para entrar em funcionamento, um RemoteApp implantado não é a mesma coisa que toda uma área de trabalho implantada. Iniciar uma área de trabalho remota exige a criação de uma instância do explorer.exe para operar o shell da área de trabalho, além de todos os processos configurados para iniciar com o explorer.exe, como os aplicativos da bandeja do sistema, os aplicativos auxiliares ou qualquer serviço ou processo que esteja associado à área de trabalho padrão.

A ativação de um RemoteApp, ao contrário, não exige o shell completo do explorer.exe nem todos os complementos. Na verdade, os RemoteApps substituem o explorer.exe por dois outros processos chamados rdpshell.exe e rdpinit.exe. São esses dois processos enxutos que trabalham como o shell alternativo e o aplicativo de logon do shell, usados para inicializar um RemoteApp.

A Figura 5 mostra um exemplo simplificado de um servidor de terminal em que dois usuários se conectaram e iniciaram o aplicativo Calculadora. O Usuário1 (User1) conectou-se via área de trabalho completa enquanto o Usuário2 (User2) conectou-se a uma instância do calc.exe previamente criada como RemoteApp. Embora se perceba que o Usuário2 precisa executar um número maior de processos para iniciar o RemoteApp da calculadora, a soma total do uso de memória desses processos é menor do que o necessário para o shell do Explorer do Usuário1, como se pode ver na Figura 6.

Figura 5 O Gerenciador de Tarefas mostra as diferenças, quanto ao uso de recursos, entre áreas de trabalho e RemoteApps

Esse consumo reduzido de RAM é apenas uma parte da discussão sobre desempenho. O impacto do comportamento do usuário sobre o processador também deve ser levado em consideração. Quando uma área de trabalho completa é implantada para um usuário, na verdade ele obtém a possibilidade de executar qualquer aplicativo que esteja instalado no servidor de terminal.

Sem os bloqueios adequados em funcionamento, um usuário leve que aproveita os serviços de terminal para escrever documentos no Word pode, a qualquer momento, se tornar um usuário pesado, caso ative outro aplicativo mais robusto, que exija mais recursos. Essa falta de previsibilidade comportamental faz do planejamento de recursos por usuário uma tarefa desafiadora. Ela também complica a administração do servidor de terminal, aumentando a possibilidade de o comportamento de um usuário afetar a experiência de outros.

Talvez não haja exemplo melhor dessa falta de previsibilidade do que o Internet Explorer. Instalado em todas as instâncias do Windows Server, esse aplicativo não requer muitos recursos para ser executado. Mas quando o Internet Explorer é usado para exibir um site mal escrito, que requeira inúmeros plug-ins, seu uso de recursos pode aumentar drasticamente. Um usuário que execute o Internet Explorer inesperada e inadequadamente em uma sessão de área de trabalho pode, por acidente, consumir em excesso os recursos disponíveis no servidor de terminal, piorando o desempenho dos outros.

Ao contrário das áreas de trabalho completas, a estrutura dos RemoteApps tende a conceder mais previsibilidade no uso de recursos. Um usuário que inicia um RemoteApp pode trabalhar apenas com aquele aplicativo específico e outros gerados pelo aplicativo inicial. Assim, sob o ponto de vista do desempenho, o comportamento do usuário tende a ser mais previsível.

Você tem opções

Essencialmente, a meta deste artigo é informar você das opções existentes para implantar aplicativos remotos para os usuários. Os novos recursos disponíveis nos serviços de terminal do Windows Server 2008 oferecem vários caminhos para os usuários se conectarem a aplicativos. Alguma combinação de hospedagem na área de trabalho e na Web com área de trabalho completa versus RemoteApp será a configuração correta para seu ambiente específico.

Principais contadores de desempenho dos serviços de terminal

Embora avaliar a experiência do usuário seja, de modo geral, uma atividade subjetiva que envolve entrevistas pessoais mais do que medições, existem alguns contadores de desempenho úteis, cuja avaliação pode ajudar a determinar o desempenho do servidor de terminal — o que interfere na satisfação dos usuários. Pense na possibilidade de avaliar os seguintes contadores de seus servidores de terminal:

Memória\MBytes Disponíveis Quando esse contador chega a um número muito pequeno, significa que os processos no servidor de terminal estão consumindo muito da memória física disponível. Aqui, números baixos não são necessariamente ruins, mas, quando combinados a uma contagem alta de threads e a um número alto de páginas por segundo, podem significar que muitos usuários estão tentando fazer coisas demais em um servidor de terminal.

Memória\Páginas/s Esse contador é relativo à taxa na qual a memória é lida ou gravada em disco. Aqui, um valor alto combinado a um valor baixo de MBytes Disponíveis pode significar que a memória disponível não é suficiente para a carga no servidor e pode, portanto, resultar em uma experiência insatisfatória para os usuários.

Processador\% Tempo de Processador Esse contador mostra efetivamente quanto do processador está sendo usado por trabalho produtivo. Você deve observar essa métrica com atenção, principalmente em sistemas multiprocessadores, já que ela pode indicar um processador travado ou apresentando picos.

Sistema\Threads Cada processo executado pelo servidor é composto de vários threads. O contador de threads é um número inteiro que representa a soma de todos os processos do sistema. Devido à quantidade de pessoas que usam simultaneamente os recursos do sistema, os servidores de terminal tendem a ter um número alto de threads e de processos. Quando esse valor é alto, é razoável presumir que há um grande número de tentativas simultâneas de atividade no servidor. Geralmente, um valor alto de threads resulta em uma contagem alta de Alternâncias de contexto, já que o servidor tenta lidar com as necessidades de cada processo.

Sistema\Alternâncias de contexto/s Ocorre um Alternância de contexto sempre que o processador altera o thread que está processando no momento. Há uma leve sobrecarga associada a cada alternância de contexto, de modo que um número alto aqui — assim como na contagem alta de threads — pode significar que há muitos usuários tentando, ao mesmo tempo, fazer muitas coisas.

Sistema\Comprimento da fila de processador Quando o processador não consegue acompanhar a carga, as solicitações começam a entrar em uma fila. O contador dessa fila é chamado de Comprimento da fila de processador. Quando esse contador chega a um valor alto, você pode assumir que os processadores do servidor estão sobrecarregados com solicitações — o que também pode indicar um impacto na experiência dos usuários.

Serviços de terminal\Sessões ativas e Serviços de terminal\Total de sessões Essas duas medições podem ajudar a avaliar efetivamente o uso de recursos em relação ao número de usuários que estão trabalhando no servidor de terminal. O primeiro contador avalia os usuários que estão trabalhando ativamente na sessão, enquanto o segundo inclui os usuários ociosos ou já desconectados. Esses dois contadores, combinados aos outros, são úteis para ajudar a identificar o número máximo de usuários com o qual o servidor pode lidar antes de ficar sobrecarregado e, em conseqüência disso, a experiência dos usuários ser prejudicada.

Os números reais dependerão da composição de seu hardware, dos aplicativos instalados e do número e tipo dos usuários do sistema. Portanto, determinar números exatos como limites pode ser enganoso. Em vez disso, como guia inicial para determinar em que momentos a experiência dos usuários talvez não seja boa, você deve buscar as variações em seus números ou os horários em que sua medição esteja fora dos limites normais de operação.

Greg Shields, MVP, é co-fundador e guru de TI da Concentrated Technology. Seu último livro, Windows Server 2008: What's New/What's Changed (Windows Server 2008: o que há de novo/o que mudou), está disponível pela editora SAPIEN. Conheça o Greg em www.ConcentratedTech.com.