Como usar o Windows Terminal Server (WTS) O RDP surgiu como um protocolo para istração remota dos servidores Windows, mas foi logo expandido e transformado em um protocolo de o remoto, dando origem ao Windows Terminal Services (WTS), que permite que vários usuários se conectem simultaneamente à mesma máquina Windows de forma a usar o sistema e rodar aplicativos. Todo o processamento é feito no servidor, permitindo que ele seja usado mesmo em máquinas antigas ou em terminais burros, com pouco poder de processamento. Embora seja uma forma prática de ar máquinas remotamente, o VNC possui duas graves limitações, que são o baixo desempenho quando usado através de conexões lentas (como uma rede wireless congestionada) ou via Internet e a falta de e a conexões simultâneas no Windows, o que limita bastante seu uso. No Linux, a ferramenta de o remoto mais utilizada é o SSH (que veremos a seguir), enquanto o Windows oferece um protocolo próprio de o remoto, o RDP, que permite o o tanto a partir de outras máquinas Windows quanto a partir de clientes Linux, como você pode ver no screenshot abaixo, onde temos uma máquina com o Ubuntu ando uma estação com o Windows XP:
O RDP é um protocolo bem mais eficiente que o VNC, que se baseia no envio de instruções em vez de bitmaps com screenshots da tela. O cliente recebe as instruções e as combina com ícones e outros elementos para montar novamente as janelas. Isso faz com que usar o servidor remotamente seja uma experiência muito parecida com usá-lo localmente, além de melhorar bastante a qualidade do o via Internet. Outro fator essencial é que ele permite que vários usuários se conectem simultaneamente ao
servidor, abrindo sessões independentes, o que é impossível ao usar o VNC para Windows. O RDP é usado desde a época do Windows NT. Ele surgiu como um protocolo para istração remota dos servidores Windows, mas foi logo expandido e transformado em um protocolo de o remoto, dando origem ao Windows Terminal Services (WTS), que permite que vários usuários se conectem simultaneamente à mesma máquina Windows de forma a usar o sistema e rodar aplicativos. Todo o processamento é feito no servidor, permitindo que ele seja usado mesmo em máquinas antigas ou em terminais burros, com pouco poder de processamento. Além da baixa utilização da rede, o algoritmo de compressão do RDP também consome menos recursos do servidor, o que permite o uso de mais terminais simultaneamente. De uma forma geral, um servidor equipado com um processador Core 2 Duo, Athlon X2 ou superior e 2 GB de memória RAM, pode atender 50 clientes simultâneos rodando aplicativos leves, ou de 15 a 25 clientes simultâneos rodando aplicativos mais pesados. O maior obstáculo é a questão do licenciamento, pois além da licença do servidor, você precisa de licenças para os clientes. Além disso, apenas as versões server do Windows, incluindo o Windows 2000 Server, 2003 Server e 2008 Server (com exceção do Windows Server 2003 Web Edition) oferecem o pacote completo, onde o número de sessões simultâneas é limitado apenas ao hardware do servidor e ao número de licenças. As máquinas com as versões domésticas do Windows XP e do Vista também podem ser adas remotamente, mas sem e a várias conexões simultâneas (quando você se loga remotamente, ele coloca a sessão local em espera e ao se logar localmente ele fecha a conexão remota). Uma solução para permitir mais conexões simultâneas em máquinas com o Windows XP é usar o XP Unlimited, que remove a barreira técnica, permitindo abrir um número indefinido de conexões, assim como no Windows 2003 Server. A versão demo disponível no http://www.xpunlimited.com/demo.html (apenas para uso não-comercial) permite três conexões simultâneas. Para liberar o uso de mais conexões, é necessário comprar a versão completa. Note que embora o XP Unlimited remova a limitação técnica, a questão do licenciamento fica nebulosa, já que em tese o Windows XP não poderia ser usado simultaneamente por mais de um usuário, sem que cada um tivesse uma licença. Verifique essa questão antes de considerar o uso em ambientes de produção. Outra opção para destravar o o de vários clientes simultaneamente é uma modificação do arquivo rv.dll, combinado com uma chave de registro. Na verdade, o limite no número de conexões é apenas uma trava artificialmente adicionada no sistema. Sem ela, mesmo o Windows XP a vários clientes simultâneos. Você pode baixar uma versão modificada do arquivo, juntamente com os scripts de instalação no: http://dot651.blog.com/1883945/. Para instalar, basta descompactar o arquivo e executar os scripts “Install RDP.bat” e “TS Reg Patch.reg”, que se encarregam de copiar a dll e inserir a chave no registro. Se o link estiver fora do ar, pesquise por “Unlimited Remote Desktop Connections” ou pelo arquivo “URDPC.zip”. Vale lembrar, entretanto, que usar a dll modificada viola
potencialmente o contrato de licença do Windows, por isso você deve usá-lo apenas para testes ou em ambiente doméstico. Em um ambiente de produção, o correto é utilizar um servidor com o Windows 2003 Server, acompanhado por um licensing server (servidor de licenciamento), que nada mais é do que um servidor Windows 2003 Server separado, rodando o serviço “Terminal Server Licensing”, que pode ser instalado através do Windows Components Wizard. É possível também instalar o serviço no próprio servidor principal, evitando assim a necessidade de usar uma máquina separada. Sem o licensing server, o servidor Windows vai fornecer licenças temporárias para os clientes, o que pode ser usado para fins de teste e avaliação. Entretanto, isso só funciona por um período de 120 dias; depois disso o Terminal Services deixa de funcionar até que o licensing server seja instalado. Como você pode ver, a única função do licensing server é verificar o licenciamento; uma norma burocrática que aumenta os custos e faz com que você tenha mais trabalho. Infelizmente é assim que as coisas funcionam dentro do mundo Windows. As licenças para os terminais são chamadas de CALs (Client Access License). Existem dois tipos de licença, por máquina (per device) e por usuário (per ) e você pode escolher qual dois dois sistemas usar através do “istrative Tools > Terminal Services Configuration > Server Settings > Licensing > Licensing Mode” (no servidor Windows). Ao usar o sistema por máquina, você compra uma licença para cada micro da rede e eles podem ser utilizados por um número indefinido de usuários (desde que um usuário por micro de cada vez). Ao optar pelo licenciamento por usuário, você adquire uma licença para cada usuário da rede, que a a poder se logar em qualquer máquina. Salvo exceções, se você possui mais usuários do que máquinas (como em um Cybercafé, onde cada cliente tem um separado, por exemplo), as licenças por máquina são mais vantajosas, enquanto em situações onde os usuários tem liberdade para se logar remotamente a partir de qualquer PC, as licenças por usuário são mais recomendáveis. Como de praxe, é recomendável se informar sobre a questão do licenciamento e calcular os custos antes de implantar o servidor. Veja mais detalhes no: http://.microsoft.com/default.aspx?scid=kb;en-us;823313.
Ativando o serviço Usando o Windows Terminal Server (WTS)
Voltando à parte técnica, para ativar o o remoto em uma máquina Windows, clique com o botão direito no “Meu Computador” e, no menu “Propriedades do Sistema”, e a aba “Remoto” e marque a opção “Área de trabalho remota”. Clique no botão “Selecionar usuários remotos” e indique quais s de o poderão ser usados remotamente. Por padrão, apenas o e o usuário atualmente logado (que você está utilizando para fazer a configuração) podem ar:
No Windows 2003 Server, abra o wizard “Configure Your Server” e ative a opção “Terminal Server” na página “Server Role”, o que vai instalar os arquivos necessários para ativar o serviço. Para que os usuários possam usar o terminal server, é necessário cadastrá-los no grupo “Remote Desktop s”. Você pode fazer isso através do “istrative Tools > Computer Management > Local s and Groups > Groups”. Clicando com o botão direito sobre o grupo, você tem a opção de adicionar usuários a ele:
Ao usar o Active Directory, você pode também ajustar algumas opções relativas às sessões remotas dentro da aba “Sessions” das propriedades de cada usuário no istrative Tools > Active Directory s and Computers. A principal observação nesse caso é que você deve usar servidores separados como controlador de domínio e como terminal server. Por segurança, ao ativar o uso do terminal server em um servidor configurado como controlador de domínio, o sistema bloqueia o o de todos os usuários, com exceção dos es. Nem todos os programas podem ser usados facilmente no servidor de terminais, já que é necessário que o programa possa ser executado por usuários sem privilégios istrativos, e o uso de múltiplas instâncias, entre outros detalhes, mas o número de aplicativos incompatíveis vem caindo bastante. Uma dica para minimizar os problemas é instalar os aplicativos usando o “Adicionar ou remover programas” do de controle em vez de simplesmente clicar sobre o instalador do programa. Isso faz com que o sistema execute algumas verificações adicionais, instalando o programa dentro das pastas correspondentes do sistema (e não mais dentro da pasta de documentos do usuário ou outra localização fora do padrão), além de ativar um conjunto de checagens relacionadas ao uso de múltiplas sessões do programa e ao compartilhamento do espaço de memória usado por ele; dois fatores fundamentais para que ele possa ser usado por diversos usuários simultaneamente. No Vista, a opção para ativar o WTS está escondida dentro do “ de Controle > Sistema > Configurações avançadas do sistema > Remoto”. Assim como no XP e no 2003 Server, você precisa definir senhas para as contas de usuário e indicar manualmente os usuários que devem ter o, usando o botão “Selecionar usuários”:
É importante enfatizar que apenas os usuários com senhas definidas podem ar as máquinas remotamente. Todos os s sem senha são automaticamente recusados.
Você pode definir as senhas na seção “Contas de usuário” do de Controle. No caso do 2003 Server, é necessário que os usuários que irão ar o servidor sejam incluídos no grupo “Remote Desktop”. Como todos os usuários utilizarão a mesma máquina, é importante ajustar os privilégios das contas, de forma que os usuários remotos não possam fazer modificações que afetem os outros usuários. Dar privilégios de para todos os usuários, como muitas vezes é feito em micros desktop, pode ser desastroso ao usar o Terminal Services. Em caso de problemas na ativação, e a opção “Ferramentas istrativas > Serviços” do de Controle e verifique se os serviços “Alocador Remote Procedure Call (RPC)” e “Serviços de terminal” estão ativados. Verifique também se a porta T 3389, usada pelo Terminal Services está aberta no firewall (em caso de dúvida, experimente desativar o firewall e refazer o teste).
Nos clientes Windows XP, você encontra o cliente RDP no “Iniciar > Todos os programas > órios > Comunicações > Conexão de área de trabalho remota”. Por padrão, o programa pede apenas o nome, domínio ou endereço IP do servidor onde se conectar, mas clicando no botão “Opções” você tem o a um conjunto mais generoso de opções:
O default é abrir a conexão em tela cheia e utilizar 16 bits de cor, mas você pode ajustar a resolução, fazendo com que o desktop remoto seja aberto em uma janela na aba “Exibição”. O Terminal Services permite redirecionar o fluxo de áudio da sessão diretamente para o cliente, além de permitir o o a impressoras, unidades de disco e dispositivos diversos instalados nas portas seriais do cliente. Continuando, a aba “Programas” permite especificar um programa que será aberto automaticamente ao abrir a conexão (um aplicativo de gerenciamento ou agenda de grupo que deve ser usado por todos os usuários, por exemplo) e a aba “Experiência” permite ajustar opções relacionadas à conexão, desativando animações e a exibição do papel de parede entre outras opções. O “Conexão de área de trabalho remota” não está disponível no XP Home e no Vista Home Basic. Neles, você pode instalar o Terminal Services Client, disponível no: http://.microsoft.com/kb/925876 No caso dos servidores 2003 ou 2008 Server, existe também um serviço de o via web, que fica disponível para os clientes através do endereço “http://servidor/tsweb”. Ele é baseado no uso de controles ActiveX, por isso só funciona corretamente no Internet Explorer, o que limita seu uso aos clientes Windows.
Clientes Linux
Usando o Windows Terminal Server (WTS)
Naturalmente, além de ser ado pelos clientes Windows, o servidor pode também ser ado pelos clientes Linux da rede. Esta é uma forma prática de disponibilizar alguns aplicativos Windows específicos para os usuários em máquinas Linux, sem precisar manter instalada uma cópia do Windows em dual-boot ou usar o VMware para rodá-lo em uma VM em cada máquina. Esta solução é muito usada por empresas que migram as estações de trabalho para Linux, mas precisam manter algumas cópias do Windows para rodar alguns aplicativos específicos. Ao invés de manter máquinas com o Windows, ou rodá-lo via VMware, pode fazer mais sentido manter um servidor Windows na rede, com o o remoto ativado e permitir que os usuários abram sessões remotas quando necessário. Nos clientes Linux, usamos o rdesktop, que pode ser tanto utilizado via linha de comando, quanto através do TSclient, Krdc ou outra das interfaces de o remoto que oferecem e a ele. O uso mais simples para o rdesktop é simplesmente ar o endereço IP ou domínio da máquina remota como argumento, como em: $ rdesktop 192.168.0.1
O problema é que ele vai utilizar todas as opções default, abrindo uma tela de 800×600 com 256 cores. O protocolo RDP v5 (usado no Windows XP e no 2003 server) a o uso de 16 bits de cor. Para ativar o recurso, inclua as opções “-5 -a 16″ (o -5 é a versão do protocolo e o -a 16 especifica os bits de cor), como em: $ rdesktop -5 -a 16 192.168.0.1
Para especificar a resolução, use a opção “-g”, seguida pela resolução desejada, como em: $ rdesktop -5 -a 16 -g 1000×700 192.168.0.1
Ao especificar a resolução, você pode usar qualquer número que adapte a janela ao seu desktop. Não é necessário se limitar às resoluções padrão. Para abrir a sessão em tela cheia, use a opção “-f”, como em: $ rdesktop -5 -a 16 -f 192.168.0.1
(pressione “Ctrl+Alt+Enter” para chavear entre o modo fullscreen e janela) Outra opção útil, sobretudo ao criar scripts de conexão é a opção “-u”, que permite especificar o usuário com o qual será aberta a conexão, de forma que ele já fique préselecionado na tela de . Um exemplo de uso seria: $ rdesktop -5 -a 16 -u gdh -f 192.168.0.1
Ao ar uma máquina XP ou 2003 server, você pode também redirecionar o som para o cliente, de forma que os sons dos aplicativos sejam tocados usando a placa de
som e caixas do seu micro, ao invés de no servidor. Funciona mesmo que o servidor não possua placa de som. Esse é um recurso que deve ser usado com cautela em redes com muitos clientes, ou via Internet, pois gera um fluxo de aproximadamente 800 kbits para cada cliente usando o som. Para ativar, adicione a opção “-r sound:local=/dev/dsp”, como em: $ rdesktop -5 -a 16 -r sound:local=/dev/dsp 192.168.0.1
Note que o “/dev/dsp” indica o dispositivo da placa de som no cliente. Se não funcionar da primeira vez, verifique as permissões de o (no cliente). Caso necessário, abra as permissões usando o comando “chmod 666 /dev/dsp” (como root, no cliente). É possível também “compartilhar” pastas no cliente, de forma que os arquivos sejam ados dentro da sessão remota. Você pode, por exemplo, editar documentos em uma pasta dentro do seu home, usando os programas instalados no servidor. Para isso, adicione a opção “-r disk:nome=pasta”, onde o “nome” indica como ele será visto dentro da sessão e a “pasta” é a pasta no cliente que está sendo “compartilhada”. Esta opção pode ser usada em combinação com as anteriores, como em: $ rdesktop -5 -a 16 -r sound:local=/dev/dsp -r disk:arquivo=/home/joao 192.168.0.1
As pastas compartilhadas aparecem dentro do “Meu Computador > Outros”, como se fossem compartilhamentos de rede montados:
Para compartilhar o CD-ROM, pendrive ou disquete, basta indicar a pasta onde eles ficam íveis, como em “-r disk:cdrom=/mnt/cdrom” ou “-r disk:pendrive=/mnt/pendrive”. A observação, nesse caso, é que você vai sempre precisar montar o CD-ROM ou pendrive no cliente para á-lo dentro da sessão remota. O comando simplesmente compartilha os arquivos íveis dentro da pasta. É possível, ainda, mapear a impressora, de forma que você consiga imprimir na impressora instalada no seu cliente Linux de dentro dos aplicativos na sessão remota. Se os clientes e o servidor estão na mesma rede local, é mais simples compartilhar a impressora via Cups ou Samba e instalá-la no servidor. O mapeamento de impressoras do RPD, por sua vez, permite usar as impressoras quando isso não é uma opção, como ao ar um servidor via Internet. Em primeiro lugar, a impressora deve estar instalada no cliente e você deve conseguir imprimir nela usando o lpr. Nas distribuições derivadas do Debian, instale o pacote “cupsys-bsd” (que substitui o lpr); caso contrário, nada vai funcionar. Ao conectar no servidor, é preciso especificar o nome da impressora, da forma como é vista pelos aplicativos no cliente e também o driver Windows (esta é a parte mais complicada…) que o servidor vai usar na hora de enviar trabalhos para ela, como em: $ rdesktop -5 -a 16 -r printer:e230=”Lexmark Optra E+ (MS)” 192.168.0.1
Para descobrir o driver da Impressora no Windows, abra o assistente de instalação de impressora, indique o fabricante e copie o nome que aparece no menu da esquerda:
No caso de impressoras paralelas, você pode também redirecionar a porta “/dev/lp0″. Nesse caso, você poderia instalar a impressora dentro da sessão remota, como se ela estivesse instalada no próprio servidor, adicionando o parâmetro “-r
lptport:LPT1=/dev/lp0” ao comando de conexão. É possível, ainda, redirecionar portas seriais, usando a opção “-r comport:COM1=/dev/ttyS0“. Como viu, o rdesktop a um grande número de opções, o que torna os comandos de o bastante longos. É aí que entra o TSclient, que permite especificar as opções através de uma interface muito mais amigável. Ele está disponível em várias distribuições; nas derivadas do Debian, você pode instalá-lo via apt-get. A página oficial é a http://gnomepro.com/tsclient/. Outra opção é criar ícones nos desktops dos usuários. O ícone pode disparar um comando com o rdesktop cuidadosamente personalizado, de forma a já abrir a janela de conexão com a resolução desejada e já especificando o usado e os parâmetros necessários para compartilhar a impressora e as pastas desejadas, de forma que o usuário tenha apenas o trabalho de clicar. No KDE, clique com o botão direito sobre o desktop e use a opção “Criar Novo > Link para Aplicativo”. O comando a executar vai no campo Aplicativo > Comando”. Um exemplo de comando a usar seria: “rdesktop -g 1024×768 -u gdh 192.168.0.1″:
TSclient (à esquerda) e propriedades do ícone de atalho com o comando para se conectar ao servidor diretamente
Mais dicas Usando o Windows Terminal Server (WTS)
Carlos 20/02/2008 // <![CDATA[// // <![CDATA[//
E.
Morimoto
Como comentei, o uso do Terminal Services, combinado com o rdesktop é uma boa opção para casos em que você precisa oferecer o uso de aplicativos Windows para os usuários da rede, ao usar Linux nos desktops, sem com isso precisar manter o sistema instalado em dual-boot em todas as máquinas, ou precisar usar máquinas virtuais com o VMware. Manter um único servidor com o Windows 2003, ou com o Windows XP (mais o XP Unlimited) acaba sendo uma solução muito mais simples e barata, sobretudo em casos em que os usuários precisam apenas de alguns serviços específicos. Quando falo em “servidor” você pode ter a idéia de se tratar de uma máquina parruda, com vários gigabytes de memória e discos em RAID, mas isso não vem ao caso. Se a idéia for que o servidor atenda apenas a um pequeno volume de os, ou que atenda apenas um usuário por vez (que seria o caso de uma máquina com o Windows XP, sem o XP Unlimited), você pode usar basicamente qualquer máquina com uma placa de rede onde você consiga instalar o sistema. Você pode inclusive usar alguma máquina antiga. No meu caso, por exemplo, uso esse resto de notebook, o “hp”:
Ele é um HP nx6110, com um Celeron 1.4, que foi aposentado depois que o LCD quebrou. Depois de doar a placa wireless e o drive de CD-ROM, ele acabou ficando com pouca utilidade. Apesar disso, ele funciona muito bem como mini-servidor, já que tem potência suficiente para rodar aplicativos básicos, consome pouca energia (por ser um notebook) e tem um nobreak embutido (a bateria).
Outra possibilidade com relação ao uso de micros antigos é transformá-los em clientes de um servidor WTS. O cliente a então a simplesmente carregar um cliente RDP para obter a tela de do servidor e rodar os aplicativos através dele, funcionando como um terminal burro. Uma boa opção é o AnywhereTS, um aplicativo Windows que gera uma imagem bootável, que permite inicializar os clientes via CD ou via rede, através de um servidor TFTP. Como todo o software é obtido via rede, os clientes não precisam sequer de um HD instalado. A imagem gerada é na verdade uma mini-distribuição Linux, que inicializa o cliente e usa o rdesktop para obter a tela de do servidor. O executável do AnywhereTS é na verdade apenas um configurador, que reúne as informações necessárias e gera a imagem:
O wizard precisa basicamente do endereço IP do servidor e do driver que será usado pela placa de vídeo, rede e som, além do layout de teclado que será usado nos clientes. No caso dos drivers, você pode usar a opção “Autodetect”, que faz com que o sistema de boot tente detectar os dispositivos durante a inicialização do sistema. Você pode gerar alguns CDs “genéricos” usando a detecção automática e deixar para criar imagens com os drivers indicados manualmente para inicializar os clientes problemáticos. CONTEÚDO EXTRAIDO DO SITE http://www.guiadohardware.net/tutoriais/wts/ Carlos E. Morimoto Fonte : http://linuxlive.blog.com/2010/07/10/usando-o-windows-terminal-server-wts/