Windows PowerShellO poder dos perfis

Don Jones

Sumário

Shells, hosts e perfis
Usando seu perfil
Fazendo um console personalizado
Mais truques sobre perfis
Cuidado com os perfis!

Se você lê essa coluna regularmente, já sabe que o Windows PowerShell suporta um sistema de perfis. Eles são essencialmente scripts do shell, com uma extensão de nome de arquivo .ps1, executada automaticamente quando o shell é executado. Eles fornecem uma maneira excelente de definir aliases personalizados, por exemplo. Você pode fazer com que, a cada vez que o shell for executado, o perfil define automaticamente seus aliases, tornando-os disponíveis sempre que você estiver usando o shell.

O shell define os quatro perfis diferentes a seguir:

• Um que se aplica a todos os shells e todos os usuários do computador.
• Um que se aplica a todos os usuários, mas apenas ao shell do Microsoft PowerShell.
• Um que se aplica ao usuário atual e a todos os shells.
• Um que se aplica ao usuário atual e apenas ao shell do Microsoft PowerShell.

O conceito de "todos os shells" pode ser um pouco confuso. A terminologia está enraizada em alguns conceitos de desenvolvimento antigos do Windows PowerShell que realmente não conseguiam chegar ao produto final. Hoje, o termo "todos os hosts" provavelmente seriam mais apropriados.

Shells, hosts e perfis

Sabe, o Windows PowerShell em si é um conjunto de assemblies do Microsoft .NET Framework. Gosto de me referir a essa parte do shell como o mecanismo do Windows PowerShell porque ela contém a funcionalidade que você geralmente considera como sendo o Windows PowerShell. Não existe uma maneira interna para os humanos interagirem com esse mecanismo, no entanto. Para você realmente usar o shell, o mecanismo deve ser carregado por um aplicativo de hospedagem (ou host).

O aplicativo powershell.exe que você provavelmente usou para executar é um host desse tipo. O aplicativo gpowershell.exe incluído com o CTP (Community Technology Preview) do Windows PowerShell 2.0 é outro host. Essa relação entre hosts e shells não é tão simples quanto eu a tornei aqui, mas minha explicação simplificada abrange o comportamento que você verá.

É importante entender que se você está interagindo com o shell por uma interface de linha de comando baseada em texto, você provavelmente está usando o host powershell.exe. Isso se aplica mesmo se você tiver iniciado o shell usando um atalho instalado por outro aplicativo, como o Shell de Gerenciamento do Exchange. O Shell de Gerenciamento do Exchange não é um aplicativo de hospedagem ou shell diferente. Em vez disso, ele é meramente o host powershell.exe normal iniciado usando um atalho que especifica um conjunto de snap-ins e scripts a serem pré-carregados. Esses snap-ins são o que permitem ao Exchange a funcionalidade de gerenciamento dentro do shell. Mas você ainda está usando o mesmo shell.

Os locais (no Windows Vista) dos perfis para o host powershell.exe são os seguintes:

• %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 Esse é para todos os usuários do computador e para todos os shells.
• %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 Esse é para todos os usuários do computador, mas é apenas para o shell do Microsoft.PowerShell.
• %UserProfile%\Documents\WindowsPowerShell\profile.ps1 Esse é apenas para o usuário atual e todos os shells.
• %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 Esse é apenas para o usuário atual e apenas para o shell do Microsoft.PowerShell.

Esses perfis não são criados por padrão. Eles apenas existem se você criá-los.

Cada aplicativo de hospedagem é responsável por carregar e executar o perfil correto. Se um determinado aplicativo de hospedagem "decide" não carregar nenhum perfil, ele, na verdade, não precisa. A execução do perfil não é feita pelo mecanismo do Windows PowerShell automaticamente.

A maneira mais fácil de controlar tudo isso é simplesmente abrir o shell, digitar $profile e pressionar Enter. Isso fornecerá a você todo o caminho que o shell está tentando usar como o que eu considero o perfil "primário" (é o perfil específico do shell por usuário). Você pode então criar ou modificar esse script e ele será executado a cada vez que o shell for iniciado.

Usando seu perfil

Um uso comum para um perfil é definir aliases personalizados, como sugeri anteriormente. Ou você pode adicionar PSDrives personalizados (são unidades essencialmente mapeadas que existem inteiramente no Windows PowerShell). Um uso menos comum é criar um tipo de supershell que possa fazer qualquer tarefa de gerenciamento que você possa precisar, com base nos produtos de software que você está usando no seu ambiente. Para explicar realmente o conceito do supershell, preciso primeiro fornecer um pouco de informações básicas.

O grupo de produtos da Microsoft que cria o Windows PowerShell é responsável por várias das outras principais tecnologias de gerenciamento, incluindo o MMC (console de gerenciamento da Microsoft). O MMC fornece uma boa analogia para exatamente como o Windows PowerShell funciona. Quando você executa o mmc.exe, começa com um console em branco que não é bom para muita coisa. Você adiciona os snap-ins do MMC para criar um console funcional.

Depois de configurar seu console da maneira desejada, você salva o console em um arquivo com uma extensão de nome de arquivo .msc. Esse arquivo de console salvo permite que você recarregue rapidamente seu console personalizado a qualquer momento.

Em vez de fazer consoles MMC personalizados, vários administradores apenas contam com os consoles que estão instalados com os produtos que eles gerenciam. O Exchange Server, por exemplo, cria um console que contém apenas o snap-in do Exchange Server. Usuários e Computadores do Active Directory é outro console pré-criado que contém um único snap-in.

O Windows PowerShell funciona quase que da mesma maneira. O ícone do Shell de Gerenciamento do Exchange instalado com as ferramentas de gerenciamento do Exchange Server 2007 é na verdade um atalho para o powershell.exe com instruções para carregar um arquivo de console. Os arquivos de console do shell possuem uma extensão de nome de arquivo .psc1 e contêm uma lista de snap-ins para pré-carregar (muito como um arquivo .msc contém uma lista de snap-ins que o MMC pré-carrega para você). No entanto, você não fica preso usando esses consoles de shell pré-criados. Você pode criar um console personalizado — assim como pode com o MMC — e usá-lo para realizar todas as suas tarefas de gerenciamento. Os perfis representam um papel principal em tornar isso possível.

Fazendo um console personalizado

Para fazer um console personalizado, você deve começar encontrando os nomes completos de cada snap-in com o qual deseja trabalhar. Verifique se todas as ferramentas de gerenciamento necessárias estão instaladas no seu computador. Em seguida, no Windows PowerShell, execute Get-PSSnapin –registered. Isso listará todos os snap-ins disponíveis registrados, embora não carregados. Em seguida, crie ou edite o perfil do Windows PowerShell apropriado. Adicione os comandos Add-PSSnapin para carregar cada snap-in que você deseja que esteja disponível sempre. Isso pode incluir snap-ins para Exchange Server, produtos System Center e snap-ins de terceiros, como as Extensões de Comunidade do PowerShell. Em seguida, salve seu perfil (lembre-se de assinar digitalmente o perfil se sua política de execução do Windows PowerShell exigir) e feche o shell. Reabra o shell e ele carregará automaticamente todos os snap-ins listados no seu perfil.

Outra técnica é carregar todos os seus snap-ins no shell (usando Add-PSSnapin e os nomes dos snap-ins) e, em seguida, executar Export-Console para criar um arquivo de console .psc1 que contenha todos os snap-ins que você está usando no momento. Você pode então usar esse arquivo de console .psc1 para criar um novo atalho do Windows PowerShell que especifica o parâmetro PSConsoleFile e seu arquivo .psc1 personalizado. Esse atalho usaria então seu console, carregando todos os snap-ins especificados automaticamente.

Mais truques sobre perfis

Eu uso meu perfil do Windows PowerShell para executar várias outras tarefas úteis cada vez que o shell é iniciado. Veja um pouco do que acontece quando o shell é iniciado no meu sistema:

1. Eu executo Get-Credential para minha conta de Administrador de Domínio, armazenando os resultados em uma variável chamada $cred. Isso disponibiliza $cred por todo o shell. Posso então transmiti-lo ao parâmetro –credential de vários cmdlets, como o cmdlet Get-WmiObject. Como $cred armazena a senha, posso usar esses cmdlets sem ser solicitado por uma senha.
2. Executo Cd C:\ para que o shell seja iniciado na raiz da unidade C: do computador.
3. Executo New-Alias de Out-File para criar um alias chamado "of". Isso para que eu possa usar "of" em vez de "Out-File". Eu uso muito isso, então ter um alias curto definido é muito prático.

Tento criar uma chave de teste na unidade HKLM: do shell, que representa a parte HKEY_LOCAL_MACHINE do Registro. Se um erro ocorrer, eu sei que o shell foi iniciado sem privilégios elevados. Eu normalmente exijo privilégios elevados para o trabalho que faço e essa é apenas uma maneira rápida para que eu saiba de antemão se possuo privilégios elevados antes de mergulhar em um trabalho sério.

Eu defino uma função personalizada chamada Ping-Address que aceita o nome de um computador ou endereço IP e retorna um valor de True ou False, dependendo se é possível alcançar o computador com ping. Uso muito essa função no meu trabalho, então, deixá-la definida no meu perfil a disponibiliza globalmente no meu shell.

Cmdlet do mês: Get-WmiObject

O observador astuto pode notar que estou falando de um cmdlet que apresentei antes, mas quero deixá-los com um recurso interessante que ele oferece. Muitas vezes, vejo os administradores tentarem recuperar informações do WMI (Instrumentação de Gerenciamento do Windows) de vários computadores, cujos nomes estão listados em um arquivo de texto, usando esta técnica:

Get-Content c:\computers.txt | ForEach-Object 
  { Get-WmiObject Win32_Service –comp $_ }

Embora essa técnica funcione, você não precisa realmente dela porque Get-WmiObject pode aceitar uma matriz de nomes de computadores para o parâmetro –computerName. Para atingir o mesmo efeito, você pode apenas usar isto:

Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)

Colocar o comando Get-Content em parênteses força o shell a executar o comando e colocar os resultados — uma matriz de nomes de computadores — no parâmetro –computerName.

Cuidado com os perfis!

Tenha em mente que o powershell.exe não é o único aplicativo que carrega os perfis Microsoft.PowerShell ou os perfis all-shells. Vários IDEs (ambientes de desenvolvimento integrado) que fornecem suporte a Windows PowerShell — incluindo PrimalScript da SAPIEN Technologies, PowerGUI da Quest Software e PowerShell Plus da ShellTools — também carregam esses mesmos perfis para fornecer uma experiência paralela ao host powershell.exe.

Um grande perfil que carrega muitos snap-ins pode fazer com que esses aplicativos sejam iniciados mais lentamente, porque existem muitas instruções para o mecanismo do Windows PowerShell executar antes que ele fique pronto para o aplicativo de hospedagem. Na verdade, mesmo o powershell.exe pode levar um tempo para ser inicializado se você tiver um script de perfil muito grande para executar.

Snap-ins que definem cmdlets com os mesmos nomes também podem causar colisões. Por exemplo, se dois snap-ins definem um cmdlet chamado Get-User, o Windows PowerShell não irá executar nenhum cmdlet até que você use o nome totalmente qualificado do cmdlet para especificar qual você deseja. Esse nome totalmente qualificado pode ficar feio, uma vez que nomes de snap-in podem ser bem longos. Quando me deparo com esse problema, eu normalmente apenas desisto da idéia de ter esses dois snap-ins carregados simultaneamente. Em vez disso, carregarei apenas o que eu uso mais no meu perfil e, em seguida, usarei como shell "fresco", separado quando eu precisar carregar e usar o outro snap-in.

Os perfis do Windows PowerShell podem proporcionar muita conveniência extra para o shell. Mas tenha em mente que se eles forem editados de modo mal-intencionado por um malware, os perfis poderão também causar muitos danos. Você pode proteger seu perfil assinando-o digitalmente e configurando o Windows PowerShell para usar sua política de execução AllSigned ou modificar as permissões do arquivo NTFS nos seus perfis — todos eles — para que sua conta de usuário normal não possa modificá-los.

Don Jones é autor de Windows PowerShell: TFM and VBScript, WMI, and ADSI Unleashed (Liberando o potencial de TFM e VBScript, WMI e ADSI). Para entrar em contato com ele, visite o site da Web PowerShellCommunity.org.