Windows PowerShellUma espiada no gerenciamento remoto da versão 2.0

Don Jones

Esta coluna baseia-se em uma versão de pré-lançamento do Windows PowerShell. Todas as informações deste artigo estão sujeitas a alterações.

Sumário

Dois tipos de comunicação remota
Síncrona versus assíncrona
Espaços de execução reutilizáveis
Comunicação remota do tipo fan-in
O aplicativo arrasador na versão 2.0

Você teve a oportunidade de experimentar o mais recente CTP (Community Technology Preview) do Windows PowerShell 2.0? A versão mais recente, CTP2, possui um gerenciamento remoto aprimorado, e esta é uma ótima chance de começar a se familiarizar com os novos recursos que ela oferece. Antes de começar, pare um instante para

baixá-la em go.microsoft.com/fwlink/?LinkID=119707.

Primeiro, permita-me esclarecer alguns pontos importantes. Um CTP é um código pré-beta que a Microsoft fornece para permitir que usuários ansiosos como eu tenham uma idéia do que ela pretende fazer com a próxima versão de um aplicativo. Cada etapa ou compilação (como se costuma dizer neste setor) pode ser completamente diferente das compilações anteriores. Isso porque a equipe de desenvolvimento coleta comentários, revisa-os cuidadosamente e faz as alterações no aplicativo com base nesses comentários do usuário. Essa metodologia traz uma importante vantagem e uma importante advertência sobre seu uso do CTP.

A vantagem é que, ao usar o CTP, você pode fornecer comentários (por meio do site connect.microsoft.com) sobre o produto durante seu desenvolvimento, ocasião em que a equipe pode fazer alguma coisa a respeito! Se você esperar pela versão beta ou, pior, pela versão RC, dificilmente seus comentários serão incorporados. Durante o CTP, tudo pode acontecer e a equipe pode fazer alterações grandes e abrangentes, se necessário.

Isso nos leva à advertência. O CTP não está pronto para produção. Sim, o Windows PowerShell™ 2.0 CTP2 pode ser um dos produtos mais estáveis de pré-lançamento que você já viu, mas lembre-se de que a próxima compilação dele pode ser um aplicativo completamente diferente. Portanto, não comece a contar com o CTP2, porque a próxima versão poderá exigir que você comece do zero.

Observe que o CTP não pode ser instalado em paralelo com o Windows PowerShell 1.0. Para uma configuração ideal, o sistema também deve ter o Microsoft® .NET Framework 3.5 instalado para habilitar todos os recursos disponíveis. Caso contrário, alguns recursos serão limitados.

Além disso, como o CTP é um código muito recente, a Microsoft, até agora, deu mais ênfase ao funcionamento do aplicativo nos sistemas operacionais mais recentes, isto é, Windows Vista® e Windows Server® 2008. A compatibilidade do SO atual não corresponde à compatibilidade do SO que você pode esperar para o código final lançado. O transporte de pacotes entre versões recebe atenção em uma fase posterior no ciclo de desenvolvimento.

Dois tipos de comunicação remota

No mundo do gerenciamento remoto, normalmente encontramos dois tipos de comunicação remota: fan-in e fan-out. A comunicação remota do tipo fan-in engloba vários administradores que fazem conexões shell seguras com um único servidor. O Windows PowerShell foi projetado para permitir isso de maneira segura e particionada para que, por exemplo, uma empresa de hospedagem com o Exchange Server possa fornecer a seus clientes acesso administrativo às suas partes em um servidor. Com a comunicação remota do tipo fan-in, você obtém acesso seguro, remoto e interativo à cópia do Windows PowerShell (versão 2.0 apenas!) instalada em um servidor remoto.

A comunicação remota do tipo fan-out é quando você envia, de uma só vez, um conjunto de comandos a um grupo inteiro de servidores remotos. Os comandos realizam "fan-out" da sua estação de trabalho para o grupo de servidores em paralelo. Os comandos são executados em cada servidor, e os resultados, na forma de objetos do Windows PowerShell, são retornados à sua estação de trabalho para que você possa revisá-los e trabalhar com eles. O Windows PowerShell oferece suporte a duas importantes tecnologias de comunicação remota do tipo fan-out: o Windows® Management Instrumentation (WMI) e o Windows Remote Management (WinRM), que primeiro foi fornecido com o Windows Server 2008 e depois foi atualizado no Windows PowerShell 2.0 CTP.

Síncrona versus assíncrona

Na verdade, o Windows PowerShell 1.0 também tinha alguns recursos básicos do tipo fan-out vinculados ao WMI. Por exemplo, você podia criar facilmente uma matriz de nomes de computador e recuperar uma classe WMI de cada uma delas:

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem 
    –computer $names

Executar métodos, como reiniciar um computador, exigia um pouco mais de trabalho já que a versão 1.0 não oferecia nenhuma maneira de executar métodos WMI em massa. Contudo, isso mudou na versão 2.0 CTP graças ao cmdlet Invoke-WmiMethod:

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot

Essa técnica, porém, apresenta um problema. Ela é síncrona, o que significa que os computadores são contatados individualmente e você precisa esperar a conclusão de cada um para executar outros comandos. Mas o CTP apresenta um novo conceito (trabalhos em segundo plano) que permite que comandos como esse sejam executados em segundo plano. Em sua forma mais simples, você pode executar um comando WMI em segundo plano simplesmente adicionando o parâmetro –AsJob:

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob

É possível revisar o status do trabalho resultante executando Get-PSJob e exibir os resultados finais do trabalho executando Receive-PSJob. (Falarei com mais detalhes sobre o gerenciamento de trabalhos em uma futura coluna.) Entretanto, o cmdlet Invoke-Command fornece um meio mais fácil de executar comandos em segundo plano, como este:

$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob

Isso realmente envia por push o comando Get-WmiObject para cada computador especificado e o executa localmente. Em geral, ele é executado muito mais rápido e sem precisar contar com as conexões RPC (chamada de procedimento remoto) do WMI. Em vez disso, Invoke-Command utiliza WinRM, que por padrão usa a porta 80 ou 443. Essas portas facilitam a navegação em firewalls e são totalmente configuráveis. Invoke-Command também oferece suporte a parâmetros adicionais para credenciais alternativas e limitação, permitindo trabalhar com centenas de computadores, mas deixar apenas alguns executando em paralelo. Assim, é possível evitar sobrecarga de excesso e congestionamento.

Espaços de execução reutilizáveis

Se você planeja gerenciar remotamente um determinado conjunto de computadores mais de uma vez, deve considerar o uso de espaços de execução em vez de simples listas de nomes de computador. No Windows PowerShell, um espaço de execução é apenas uma instância do mecanismo do shell, quer ele seja executado no seu computador como a janela de console do shell ou em segundo plano em um computador remoto. É fácil iniciar um espaço de trabalho remoto:

$names = @("server1","server2","server2")
New-RunSpace –computer $names

Como os espaços de trabalho usam WinRM, também usam a porta 80 (ou 443, se você especificar o parâmetro –UseSSL) por padrão. Eles também podem aceitar credenciais alternativas e assim por diante. Se você recuperar os objetos dos espaços de execução resultantes, poderá passá-los para Invoke-Command, e o Windows PowerShell enviará por push o comando para os computadores nos quais esses espaços de execução existem:

$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob

A vantagem disso é que os espaços de execução permanecem ativos enquanto o shell está aberto, por isso, você pode simplesmente reutilizá-los para comandos adicionais.

Comunicação remota do tipo fan-in

Os espaços de execução também são essenciais à comunicação remota do tipo fan-in. Por exemplo, a Figura 1 mostra que criei um espaço de execução em um computador remoto, recuperei uma referência para esse espaço de execução e usei o cmdlet Push-Runspace para ativá-lo. Nesse ponto, executo comandos no computador remoto, da mesma forma que seria possível com utilitários como o SSH ou outros de shell remoto. A execução de Pop-Runspace recupera o meu espaço de execução "local" original, e o prompt do shell me ajuda a manter o controle sobre onde estou no momento.

Figura 1 Usando o espaço de execução para executar comandos em um computador remoto (clique na imagem para ampliá-la)

A seqüência exata dos comandos que executei é a seguinte:

PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>

Esta técnica é chamada de fan-in porque vários administradores podem abrir espaços de execução interativos remotos no mesmo servidor e ao mesmo tempo (eles realizam "fan-in" de suas estações de trabalho individuais para o servidor). Um novo modelo de segurança no Windows PowerShell 2.0 permite criar shells e cmdlets restritos, portanto, cada administrador pode ser impedido de fazer modificações globais. Eles são limitados à sua própria área do shell. Essas novas técnicas de segurança exigem certo desenvolvimento de software personalizado em uma linguagem orientada ao .NET Framework. Isso está além do escopo da coluna sobre o Windows PowerShell, mas é bom saber que esses recursos existem.

O aplicativo arrasador na versão 2.0

O Windows PowerShell 2.0 CTP possui uma lista notável de novos recursos. Na minha opinião, a comunicação remota é um aplicativo arrasador. Todo administrador, em quase qualquer ambiente, pode se beneficiar com ele.

Você deve se familiarizar com esses recursos para poder oferecer suas sugestões à equipe de produtos. Deseja que as portas padrão WinRM sejam gerenciadas por meio da Diretiva de Grupo? Os cmdlets devem funcionar de maneira diferente? Existem problemas de desempenho? O WinRM é fácil de configurar? Você pode ajudar enviando sugestões para connect.microsoft.com ou pode compartilhar seus comentários com os ganhadores do Prêmio MVP, inclusive comigo (para me contatar, poste seus comentários nos fóruns em ScriptingAnswers.com). Portanto, participe e ajude a criar o aplicativo arrasador para a próxima geração do Windows PowerShell!

Cmdlet do mês: Select-Object

Experimente isto: Get-Service | ConvertTo-HTML | Out-File Services.htm. Agora, veja o arquivo HTML resultante no seu navegador da Web. Há muita informação, não é mesmo? Se ao menos houvesse um meio de reduzir um pouco essa quantidade selecionando as informações que o interessam. É exatamente isso o que Select-Object faz para você. Por exemplo, digamos que você deseja uma lista de nomes de serviço e seus status atuais. Você pode usar isto: Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm.

Não se esqueça, porém, de que Select-Object descarta o objeto original (neste caso, serviços) e produz um objeto personalizado (literalmente um tipo de objeto PSCustom) que contém apenas as propriedades que você especificou. Qualquer funcionalidade do objeto original deixa de ser acessível, portanto, provavelmente você desejará manter Select-Object próximo ao fim do pipeline, trabalhando com o objeto original por tanto tempo quanto possível.

Don Jones é co-autor de Windows PowerShell v2.0: TFM e o instrutor por trás do curso em sala de aula "Forças Especiais" do ScriptingAnswers.com (scriptinganswers.com/training.asp). Você pode contatá-lo pelo email jeepdon@mac.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução total ou parcial sem permissão.