Windows PowerShell 3.0 – primeira impressão

Qualquer pessoa, seja um profissional da área de TI ou um usuário de computador, que faz uso de um sistema operacional, para realizar quaisquer tarefas, das mais simples às mais complexas, mesmo sem saber, faz uso constante dos chamados “shells“. Ora, seja para obter acesso ao sistema de arquivos, executar comandos diversos ou abrir mão da grande gama de softwares hoje disponíveis, a digitação de comandos em um prompt ou o simples clique domouse em um ícone/atalho para abrir um aplicativo específico, representa o uso de um shell.

Na definição de Kopczynski (2008, p. 4), um “shell é uma interface que permite aos usuários interagir com o sistema operacional”. Para determinados sistemas operacionais, um shell se resume em uma interface de linha de comando (também chamada de command-line interface, ou CLI). São exemplos desses sistemas o UNIX, o Linux e o VMS (Open Virtual Memory System ou apenas VMS). Em uma definição livre, o Wikipédia (Wikipedia, 2013) conceitua VMS como:

“OpenVMS é um sistema operacional (SO) multiusuário, multiprocessado que utiliza memória virtual e foi projetado para processamento em lote (batch), em tempo real e processamento transacional. O sistema oferece elevada disponibilidade através de cluster, ou seja, a habilidade para distribuir em múltiplas máquinas físicas a carga do sistema. Isto permite que o sistema seja tolerante à falhas”.

Já para sistemas como Windows e Mac OS, o shell é justamente sua interface gráfica (GUI, ouGraphical User Interface, do inglês). Também há os shells de dispositivos de rede, comoswitches e roteadores, bem como appliances. Para estes, é mais comum o uso de interfaces Web, que disponibilizam um acesso intuitivo e simples, através de qualquer conexão de rede que seja capaz de utilizar um navegador de internet (Web Browser).

O uso de um CLI tem suas vantagens e desvantagens. Como grande benefício, os shells CLI possibilitam a montagem de inúmeros comandos encadeados, o que permite a criação de sequências de tarefas poderosas e extremamente úteis para várias tarefas que envolvem o gerenciamento de ambientes computacionais. Através do pipelining (ou uso do caractere pipe “|”), os resultados do primeiro comando (ou suas saídas) servem como entrada para os comandos posteriores, inseridos após o pipe. Assim, uma tarefa que exigiria a abertura de um console/janela de uma aplicação e uma série de alterações em caixas de diálogo, listas de opções, botões e seleção de arquivos, poderia ser realizada em um piscar de olhos com um comando previamente estruturado. Por outro lado, o uso desse tipo de tecnologia exige um conhecimento mais abrangente sobre os comandos a serem utilizados, bem como a ordem em que deverão aparecer na linha onde deverão rodar.

Assim, para aproveitar-se dos robustos benefícios que os shells CLI nos oferecem, mas, ao mesmo tempo, não ter que se lembrar de todos os comandos e variáveis disponíveis, bem como da ordem de digitação, dos pontos, vírgulas, aspas duplas e simples, espaços, chaves e colchetes, o armazenamento dos comandos mais utilizados pode ser imensamente útil e funcional. E quando menciono isso, refiro-me ao mais simples possível. Ou seja, a uma velha, temida e poderosa ferramenta: o notepad.exe. Ou seja, copie os comandos que mais utiliza e aqueles que podem lhe ser úteis e apenas cole-os em arquivos de texto. Depois, quando for utiliza-los, basta alterar as variáveis, copiar as linhas e colar o conteúdo no console do PowerShell.

História dos shells (Kopczynski, 2008, p. 12-15)
Antes de entrar no quesito PowerShell, vamos falar rapidamente de suas origens. Tudo começou “há muito, muito tempo atrás, em uma galáxia muito, muito distante”, onde o UNIX dominava o universo dos sistemas e utilizava-se indiscriminadamente da arma mais poderosa até então inventada: o Bourne shell. Depois de algum tempo, surgiu um aprimoramento conhecido como Korn Shell. Por se tratar de um produto proprietário, os “rebeldes” do código aberto (Linux e FreeBSD) precisavam de algo que pudesse ser utilizado sem custos. Assim surgiu o Bourne Again Shell. Nesse meio tempo, a DEC (Digital Equipment Corporation) lançou o VMS (Virual Memory System), com um shell conhecido como DCL (Digital Command Language) para competir com o UNIX.

Em algum outro lugar da “galáxia”, a IBM lançou seu PC (Personal Computer). A Microsoft fez com que seu DOS (Disk Operating System) fosse executado nestes PCs, agindo tanto comokernel como shell, com várias funcionalidades de shells de outros fabricantes.

Depois de algum tempo, a Microsoft dando início à formação de um novo império, criou Windows: o primeiro sistema operacional com um GUI Shell, que é a base de todos os shellsda empresa até os dias atuais.

Com o intuito e melhorar o trabalho com o GUI Shell, a Microsoft disponibilizou o ambiente DOSShell, através de um novo executável, com um conjunto mais robusto de funcionalidades, que tiraria o reinado do command.com: nascia o cmd.exe. Essa mudança trouxe benefícios, mas limitou todos os scripts à sintaxe do DOSShell para coletar e executar comandos. Assim, para corrigir a falha e facilitar o gerenciamento dos sistemas Windows, a empresa introduziu, em 1998 o WSH (Windows Script Host), que daria início ao desenvolvimento de outras linguagens, conhecidas como WSH-compliant: o JScript, o Perl, o Python, o Kixstart, o Object REXX, dentre outras.

Contudo, por ainda não haver uma linguagem padrão para a criação de scripts, o seu desenvolvimento e aplicação ainda eram um desafio aos administradores. A criação do WSH trouxe, com certeza, vários benefícios, mas também inúmeros problemas e brechas de segurança. A questão era a seguinte: apesar de disponibilizar um bom modelo de objeto e o acesso a uma grande quantidade de automação de interfaces, o WSH não era exatamente umshell, pois para utiliza-lo era necessário o uso conjunto do Wscript.exe e do Cscript.exe. Além disso, ele não oferecia compatibilidade com o CLI Shell, amplamente utilizado por administradores UNIX e Linux. Assim, como tinham que ser escritos em uma linguagem compatível, várias vulnerabilidades de segurança também eram criadas.

A partir disso, o time de PowerShell, liderado por Jeffrey Snover (também conhecido como “O Arquiteto do PowerShell”), desenvolveu um shell forte, seguro e robusto, baseado no CLI Shell, com total acesso à parte interna do Windows, através de objetos .NET Framework, COM (Component Object Model), dentre outros.

Assim, nasceu o PowerShell. Um ambiente de execução familiar, fácil e seguro, que combinou o poder do WSH com todos os poderosos recursos de um shell. A base para a criação de scripts com esse recurso não depende da instalação de um tradutor de linguagem para funcionar. Além disso, seus scripts funcionam em qualquer sistema Windows.

E assim, hoje podemos usar o Windows PowerShell para automatizar praticamente todas as tarefas de administração. Sua natureza orientada para objetos oferece mais poder aos administradores de sistemas. E desde sua primeira versão, ele vem sendo aprimorado e potencializado para o uso com vários produtos, tanto Microsoft quanto de empresas terceiras. Como exemplo, podemos citar a substituição do cmd.exe, do WSH e de ferramentas CLI pelo PowerShell.

Windows PowerShell: definição e recursos
Segundo artigo do TechNet (Biblioteca TechNet, Windows PowerShell, 2013):

“… o Windows PowerShell é um shell de linha de comando e linguagem de script, baseado em tarefas, criado especialmente para a administração de sistemas. Criado em uma estrutura .NET, ele ajuda os profissionais de TI e usuários a controlar e automatizar a administração do sistema operacional Windows e os aplicativos que são executados em Windows”.

Ainda segundo o Technet (Biblioteca TechNet, Windows PowerShell, 2013), o Windows PowerShell apresenta os seguintes recursos:

• Cmdlets para a execução de tarefas comuns de administração de sistema, como gerenciamento de registro, serviços, processos e logs de eventos, usando o WMI (Windows Management Instrumentation);
• Uma linguagem de script baseada em tarefas e com suporte para scripts existentes e ferramentas de linha de comando;
• Design consistente de cmdlets e repositórios de dados do sistema, que se utilizam de sintaxes e convenções de nomenclatura comuns. Assim a saída de um cmdlet pode ser usada como a entrada para outro cmdlet;
• Navegação simples, baseada em comandos do sistema operacional. Isso permite aos usuários navegar pelo registro e outros repositórios de dados usando as mesmas técnicas usadas para navegar pelo sistema de arquivos;
• Recursos de manipulação de objetos potentes. Objetos que podem ser diretamente manipulados ou enviados para outras ferramentas ou bancos de dados; e,
• Interface extensível, que permite a provedores de software independentes e desenvolvedores empresariais a criação de ferramentas padronizadas e utilitários para administrar seus softwares.

A seguir, deixarei uma lista, em ordem alfabética, de command-lets (cmd-lets) do Windows PowerShell 3.0, dividida em tarefas. Tenho certeza de que este material poderá ser imensamente útil na administração de seu ambiente, permitindo a automatização de várias tarefas (Biblioteca TechNet. Suporte do Windows PowerShell para Windows Server 2012). Em artigos futuros, irei apresentar com mais detalhes algumas explicações e exemplos dos cmd-lets mais comuns, usados na administração de ambientes.

AD CS Administration Cmdlets AD CS Deployment Cmdlets AD DS Administration Cmdlets AD DS Deployment Cmdlets AD FS Cmdlets AD RMS Administration Cmdlets AD RMS Deployment Cmdlets App Installation Cmdlets AppLocker Cmdlets Best Practices Analyzer Cmdlets BitLocker Cmdlets BITS Cmdlets BranchCache Cmdlets CIM Cmdlets Cluster-Aware Updating Cmdlets Data Center Bridging (DCB) Quality of Service (QoS) Cmdlets Deduplication Cmdlets DFSN Cmdlets DHCP Cmdlets DirectAccess Client Cmdlets DISM Cmdlets DNS Client Cmdlets DNS Server Cmdlets DTC Diagnostics Cmdlets DTC Management Cmdlets Failover Clusters Cmdlets FSRM Cmdlets Group Policy Cmdlets Hyper-V Cmdlets International Settings Cmdlets IPAM Cmdlets iSCSI Cmdlets iSCSI Target Cmdlets KDS Cmdlets Windows Azure Backup Cmdlets Memory Management Agent (MMAgent) Cmdlets MSMQ Cmdlets MultiPath I/O (MPIO) Cmdlets Net TCP/IP Cmdlets NetWNV Cmdlets Network Adapter Cmdlets Network Connectivity Status Cmdlets Network Load Balancing Cmdlets Network Quality of Service (QoS) Cmdlets Network Security Cmdlets Network Switch Team Cmdlets Network Transition Cmdlets NFS Cmdlets NIC Teaming (NetLBFO) Cmdlets NPS Cmdlets PKI Client Cmdlets Print Management Cmdlets Remote Access Cmdlets Remote Desktop Cmdlets Scheduled Tasks Cmdlets Secure Boot Cmdlets Server Core Cmdlets Server Manager Cmdlets Server Manager Tasks Cmdlets Server Migration Cmdlets SMB Share Cmdlets SMB Witness Cmdlets SMI-S Cmdlets Storage Cmdlets Storage Spaces Cmdlets Troubleshooting Pack (TP) Cmdlets Trusted Platform Module (TPM) Cmdlets User Access Logging (UAL) Cmdlets VAMT Cmdlets VPN Client Cmdlets Windows Data Access Components (WDAC) Cmdlets Web Server (IIS) Administration Cmdlets WHEA Cmdlets Windows Assessment Services Cmdlets Windows Azure Backup Cmdlets Windows Developer License Cmdlets Windows PowerShell Web Access Cmdlets Windows Server Backup Cmdlets Windows Server Update Services (WSUS) Cmdlets

Para conhecer mais sobre os aperfeiçoamentos do Windows PowerShell 3.0, lançado com o Windows 8 e o Windows Server 2012, baixe o Evaluation Guide, Windows Server 2012, em formato PDF (URL para download, clique aqui). Aproveite e baixe a versão 180-day trial do Windows Server 2012, disponível nos formatos ISO ou VHD (URL para download, clique aqui).

Links e Recursos relacionados.
A seguir, há uma lista de URLs sobre o Windows PowerShell que pode ser muito útil para consultas:

–> Blog do Time do Windows PowerShell – Para abrir, dê um clique na imagem.

http://nilsoncara.files.wordpress.com/2013/04/042913_0005_windowspowe1.png?w=387&h=206

–> Windows PowerShell 2.0 SDK – Fornece conteúdo de referência usado para desenvolver cmdlets, providers e aplicativos de host. Clique aqui para abrir a URL.

–> Windows PowerShell Reference – Página com vários links de referência de conteúdos relacionados ao assunto. Clique aqui para abrir a URL.

–> Site do Windows PowerShell (Script Center) – clique aqui para abrir a URL.

–> Ajuda Online do Windows PowerShell – clique aqui para abrir a URL.

–> Windows PowerShell Software Development Kit (SDK) – clique aqui para abrir a URL.

 

REFERÊNCIAS

OPCZYNSKI, Tyson. Windows PowerShell Autorizado. Rio de Janeiro: Ciência Moderna, 2008.

Wikipédia. OpenVMS. Disponível em: <http://pt.wikipedia.org/wiki/OpenVMS%3E>. Acesso em: 28 abr. 2013.

Biblioteca TechNet. Windows PowerShell. Disponível em: <http://technet.microsoft.com/pt-BR/library/bb978526%3E;. Acesso em: 28 abr. 2013.

Biblioteca TechNet. Suporte do Windows PowerShell para Windows Server 2012. Disponível em: <http://technet.microsoft.com/pt-br/library/hh801904.aspx%3E;. Acesso em: 28 abr. 2013.

Nilson A. de Cara.