Windows PowerShellIndo mais fundo
Don Jones
O Windows PowerShell está repleto de recursos que costumam passar despercebidos por muitos administradores. Se for mais fundo, você encontrará alguns recursos incríveis. É verdade, sempre me vejo descobrindo novos recursos associados a um determinado cmdlet que pensava já conhecer por completo.
Nas aulas sobre o Windows PowerShellTM que ministro, eu recomendo aos administradores a criação de um calendário com o cmdlet do dia para eles próprios – semelhante a um calendário com a palavra do dia que você compra por aí. Dessa forma, em todas as manhãs da semana (eu deixo eles tirarem folga aos fins de semana), eles passam alguns minutos se familiarizando com todos os recursos de um cmdlet. O Windows PowerShell acompanha cerca de 130 cmdlets, o que significa ser possível aprender praticamente tudo o que o Windows PowerShell é capaz de fazer em aproximadamente seis meses, caso você siga o calendário. Nesse ponto, você estará pronto para todos os cmdlets do Exchange Server 2007.
Na coluna deste mês, quero mostrar alguns exemplos do que você pode descobrir e o que é possível obter bastando reservar alguns minutos para explorar os recursos mais avançados de diversos cmdlets.
Melhores relatórios HTML
Um cmdlet pouco usado é ConvertTo-HTML. Esse cmdlet inteligente pode aceitar uma coleção de objetos de entrada – serviços, processos, objetos da WMI (Instrumentação de Gerenciamento do Windows® ) ou o que quer que seja – e transformá-los em uma tabela HTML. Em seguida, é possível orientar o HTML a Out-File, e você tem uma página HTML pronta para ser postada em um servidor Web da intranet. Por exemplo, você pode agendar esta linha simples para ser executada em todas as manhãs:
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML | Out-File C:\ServiceAlert.html
Ela criará um relatório HTML, como o mostrado na Figura 1, dos serviços que devem ser iniciados automaticamente, mas que não estão em execução.
Figure 1** An HTML report of services that aren't running **(Clique na imagem para aumentar a exibição)
É claro que você talvez queira produzir um relatório que seja um pouco mais atrativo. Felizmente, o cmdlet ConvertTo-HTML produz HTML limpo, o que significa que ele não tem nenhuma formatação incorporada no código HTML criado. De acordo com as regras do HTML, você jamais deve aplicar a formatação no HTML (bem, você deve usar o mínimo possível). Na verdade, você deve aplicar a formatação em uma CSS (folha de estilo em cascata) externa e vinculá-la ao HTML. Ao final, é possível criar o link usando ConvertTo-HTML.
A CSS é vinculada à seção <HEAD> de um arquivo HTML. Olhando a ajuda de ConvertTo-HTML, você verá que sua sintaxe inclui alguns parâmetros que talvez tenham passado despercebidos:
ConvertTo-Html [[-property] <Object[]>] [-inputObject <psobject>] [-body <string[]>] [-head <string[]>] [-title <string>] [<CommonParameters>]
O parâmetro –head lhe permite especificar um código HTML adicional a ser inserido na seção <HEAD> do script. Agora eu posso tranqüilamente modificar meu programa one-liner para se vincular a um arquivo CSS existente que contém a formatação que desejo aplicar à tabela HTML:
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML -title "Services" -head "<link rel='stylesheet' href='styles.css' type='text/ css' />" | Out-File C:\ServiceAlert.html
Aqui, eu usei o parâmetro –head para inserir um link para um arquivo CSS localizado na mesma pasta do arquivo HTML de saída. Também usei o parâmetro –title para definir o título da página da Web. O resultado é mostrado na Figura 2. O texto do arquivo Style.CSS que usei é semelhante ao seguinte:
Figure 2** An HTML report that is formatted with a CSS file **(Clique na imagem para aumentar a exibição)
body { background-color:#EEEEEE; } body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt } th { font-weight:bold; background-color:#CCCCCC; } td { background-color:white; }
Filtragem mais simples
Cmdlet do mês
Neste mês, estou analisando um par de cmdlets: Start-Transcript e Stop-Transcript. Ambos são usados no controle do registro em log das transcrições do Windows PowerShell – ou seja, ele coloca em um arquivo de texto especificado por você tudo o que aparece na janela do console. É bem simples. Execute Start-Transcript e dê a ele um nome de arquivo antes de começar. Em seguida, execute Stop-Transcript para interromper o registro em log e feche o arquivo. Isso proporciona uma ótima maneira de deixar de usar o shell ad hoc e passar ao script formal – assim que tiver as linhas de comando funcionando no shell, basta copiar e colá-las do arquivo de transcrição que você acabou de criar. Ou, é claro, editar toda a transcrição de acordo com o script real. O colega MVP Jeffery Hicks chegou a escrever um script que analisa as transcrições e as transforma em arquivos PS1 do Windows PowerShell. É possível encontrar esse script em blog.sapien.com/current/2006/11/28/powershell-transcripts.html.
Vejamos agora o cmdlet Get-WMIObject: A sua sintaxe, conforme a lista na ajuda interna do Windows PowerShell, dá uma dica sobre seus recursos ignorados:
Get-WmiObject [-class] <string> [[-property] <string[]>] [-namespace <string>] [-computerName <string[]>] [-filter <string>] [-credential <PSCredential>] [<CommonParameters>]
Um erro comum que os novos usuários do Windows PowerShell cometerão é a emissão de um comando WMI como este:
Gwmi Win32_NTLogEvent –comp Server2
Esse comando recuperará as entradas do log de eventos de Server2 – todas elas. Server2 demorará para processar e transmitir essa tarefa, e também levará um certo tempo até que o Windows PowerShell faça alguma coisa de utilidade com uma coleção tão grande.
Uma abordagem melhor é fazer com que Server2 encontre e envie os eventos nos quais você está realmente interessado. É claro que você poderia fazer isso com uma consulta de linguagem WQL. Alguns consideram essa sintaxe de consulta difícil, mas o Windows PowerShell permite que você especifique apenas a parte da filtragem de uma consulta WQL, usando o parâmetro –filter:
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
Isso recuperará todos os eventos – de qualquer log – com a identificação do evento 1024. Observe que os critérios do filtro usam = como operador de comparação, e não o operador –eq do Windows PowerShell. Isso porque, como o filtro está sendo passado ao serviço WMI do computador remoto para processamento, os critérios precisam estar na sintaxe da WMI, e não na sintaxe do Windows PowerShell.
Na verdade, há um parâmetro –filter em outros cmdlets como, por exemplo, Get-ChildItem, o cmdlet por trás de aliases como Dir e Ls. Na maioria dos casos, o parâmetro –filter passa os critérios do filtro diretamente para a tecnologia subjacente, resultando naquilo que eu gosto de chamar de filtragem da origem, que é normalmente mais rápida do que trazer todos os objetos e executá-los por meio do cmdlet Where-Object para filtrar aqueles indesejados.
Cmdlets despercebidos
Certamente, esta abordagem diária de estudo dos cmdlets lhe ajudará a compreender melhor aqueles que você imaginava já conhecer. Mas um outro bom motivo para ter um calendário com o cmdlet do dia é evitar deixar completamente despercebidos cmdlets que você talvez jamais descobrisse. Um dos meus favoritos e que muitos deixam de usar é Resolve-Path. Dado um caminho curinga, ele retornará uma coleção de nomes de arquivo e pasta correspondentes ao caminho. Ele é semelhante ao cmdlet Get-ChildItem (ou seja, os aliases Dir ou Ls conhecidos), mas em vez de retornar todos os objetos de arquivo e pasta, ele retorna cadeias de caracteres simples que podem ser orientados a outros cmdlets para filtragens ou processamentos posteriores. O uso dele é bem simples:
Resolve-Path C:\P*
Essa linha simples retornará caminhos como, por exemplo, C:\Arquivos de Programas, C:\Processes.txt, etc. A Figura 3 mostra dois exemplos desse cmdlet em uso.
Figure 3** Using the handy, though overlooked, Resolve-Path cmdlet **(Clique na imagem para aumentar a exibição)
Começar do começo
Quando você estiver pronto para dar início à experiência do cmdlet do dia, execute Gcm, um alias de Get-Command. Você terá uma lista de todos os cmdlets conhecidos pelo Windows PowerShell, inclusive aqueles adicionados por meio de snap-ins como, por exemplo, o Shell de Gerenciamento do Exchange Server 2007, as Extensões de Comunidade do PowerShell etc. Basta escolher o primeiro da lista – o meu foi Add-Content – e ler sua ajuda:
Help Add-Content –full
Como desejará a ajuda completa – e não a ajuda padrão mais concisa –, você poderá obter uma descrição completa do que cada parâmetro faz, ver alguns exemplos do uso do cmdlet e descobrir outras informações detalhadas. Pare uns 5 ou 10 minutos para testar o cmdlet. (Talvez você queira usar uma máquina virtual para não ficar colocando o seu ambiente de produção em jogo.) Recomendo que você reserve uns 10 minutos por semana – e mais ou menos o mesmo tempo diariamente, para que isso se torne um hábito. Não demorará muito para que você tenha uma compreensão avançada de toda a funcionalidade e recursos que o Windows PowerShell tem a oferecer.
Don Jones é o guru de scripts da SAPIEN Technologies e co-autor do Windows PowerShell: TFM (SAPIEN Press, 2007). Para entrar em contato com ele, visite www.ScriptingAnswers.com.
© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..