Há muito tempo atrás, prometi falar acerca da utilização de WMI no Monad. Pois bem, é chegada a altura de cumprir essa promessa

O WMI (Windows  Management Instrumentation) foi lançado no final dos anos 90 e tinha como principal objectivo automatizar as tarefas administrativas efectuadas numa máquina. Até ao seu lançamento, essas tarefas administrativas eram feitas sempre (em última análise) através da win 32 API. Na prática, a WMI não é mais do que uma framework de objectos COM que permite o fácil acesso aos recursos expostos pelo SO.

Vamos começar com um exemplo simples: obter a memória existente num computador. Para tal, temos apenas de executar o seguinte comando:

MSH c:\>get-wmiobject Win32_logicalMemoryConfiguration

Name                 totalvirtualmemory totalphysicalmemory  totalpagefilespace
----                 ------------------ -------------------  ------------------
LogicalMemoryCon...             3568752             1047920             2520832

Aqueles que conhecem o WMI já devem ter reconhecido algo familiar: a classe Win32_LogicalMemoryConfiguration. Uma classe WMI representa um recurso de uma máquina (no exemplo anterior, a classe win32_logicalmemoryconfiguration permite aceder á memória existente na máquina onde o comando é executado). A utilização de WMI necessita (quase) sempre de três passos: em primeiro lugar, é necessário estabelecer a ligação ao serviço WMI no computador desejado; em seguida, é necessário obter um (ou mais) objecto(s)  associado(s) ao recurso que contém a informação pretendida. Finalmente, temos de aceder às propriedades dos objectos retornados pelo passo 2 para obtermos os dados pretendidos. Para melhor apreciarmos o Monad, vamos ver as linhas necessárias para obter a memória através de um script vbs:

set wbemServices = GetObject( “winmgmts:\\nome do computador” )
set wbemobjectset = wbemServices.InstancesOf( “Win32_LogicalMemoryConfiguration”)

foreach wbemobject in wbemobjcset
   wscript.echo wbemObject.TotalPhysicalMemory
next

No Monad não temos de escrever tanto para obter o mesmo resultado (algo que, para alguém preguiçoso como eu, é sempre positivo ).

De volta ao WMI, é importante recordar que as classes que representam os recursos são mantidas no interior de vários namespaces. Como seria de esperar, o cmdlet get-wmiobject permite identificar o namespace através da opção -namespace. Já agora, é importante salientar (especialmente para os que, como eu, não costumam usar o WMI) que a classe usada no exemplo anterior está colocada no interior de um namespace -neste caso, a classe encontra-se no interior do namespace root\cimv2 que é usado por predefinição. Portanto, se quiséssemos ser precisos, poderíamos ter obtido os mesmos resultados através do comando seguinte:

O parâmetro -list pode ser usado sempre que for necessário obter uma listagem de todas as classes existentes no interior de um namespace. Portanto, se quisermos ver todas as classes mantidas no interior do namespace, podemos recorrer ao seguinte comando:

MSH c:\>get-wmiobject -list

No seguimento dos conceitos apresentados, não será surpresa se afirmar que o comando anterior apresenta as classes existentes no interior do namespace predefinido (ou seja, as classes mantidas no namespace root\cimv2). Se  estivermos interessados em apresentar as classes existentes noutro namespace, então devemos utilizar o parâmetro -list em conjunto com o parâmetro -namespace.

Este cmdlet apresenta ainda outros parâmetros interessantes, como por exemplo, o parâmetro -cedential. Este parâmetro permite-nos definir as credenciais que serão associadas ao comando. Este parâmetro dá imenso jeito já que permite-nos impersonalizar um utilizador para executar a operação pretendida (algo que dá sempre jeito se estiverem a usar uma conta não administrativa – se não o estão a fazer neste momento, então está na hora de começarem  – ou se precisarem de executar o comando sobre outra máquina). O parâmetro pode receber um objecto do MshCredential que é capaz de guardar o par nome de utilizador/palavra-chave que identificam a conta de um utilizador. A construção deste objecto pode ser feita de várias formas.

A forma mais simples de usar este parâmetro consiste em associá-lo apenas so nome de utilizador. Neste caso, temos apenas de fazer o seguinte:

MSH c:\>get-wmiobject Win32_logicalMemoryConfiguration -namespace root\cimv2 -credential Maquina\utilizador

A execução do comando anterior resulta na apresentação de um diálogo que permite a introdução da palavra-chave associada ao utilizador Maquina\utilizador. Apesar de interessante, esta solução não é adequada quando pretendemos executar várias acções num script. Nestas situações, podemos obter as credenciais de um utilizador e mantê-las numa variável que será usada posteriormente:

MSH c:\>$mycredentials = get-credential

MSH c:\>get-wmiobject Win32_logicalMemoryConfiguration -namespace root\cimv2 -credential $mycredentials

…

No exemplo anterior, as credenciais introduzidas pelo utilizador são mantidas na variável $mycredentials (como era de esperar, o cmdlet get-credential retorna um objecto do tipo MshCredential). A utilização desta estratégia permite reutilizar as credenciais introduzidas nos comandos executados posteriormente. De volta ao cmdlet get-wmiobject, para referir que a indicação da máquina onde o comando é executado é determinada pelo parâmetro -computer. Assim, se desejarmos obter a memória do computador OMEGA, teríamos de recorrer a uma instrução semelhante à seguinte:

MSH c:\>get-wmiobject Win32_logicalMemoryConfiguration -computer OMEGA

Apesar do exemplo não o indicar, é bem provável que a correcta execução deste comando só seja possível através do envio de credenciais. Para terminar a apresentação deste cmdlet, falta apenas apresentar dois parâmetros: -property e -filter. O parâmetro -property recebe um array de strings que indicam as propriedades que devem ser seleccionadas do objecto retornado pelo comando. Por exemplo, vamos supor que estamos apenas interessados em obter a memória virtual existente na máquina. Nesse caso, podemos executar apenas o seguinte comando:

MSH c:\>get-wmiobject win32_logicalmemoryconfiguration -property totalvirtualmemory

TotalVirtualMemory : 3568752
__GENUS            : 2
__CLASS            : Win32_LogicalMemoryConfiguration
__SUPERCLASS       :
__DYNASTY          :
__RELPATH          :
__PROPERTY_COUNT   : 1
__DERIVATION       : {}
__SERVER           :
__NAMESPACE        :
__PATH             :

O exemplo anterior é duplamente interessante: em primeiro lugar, permite-nos demonstrar os passos necessários à obtenção de algumas propriedades associadas ao objecto retornado pelo wmi. Para além disso, permite-nos ainda perceber que, ao contrário do que poderíamos pensar inicialmente, a propriedade totalvirtualmemory também devolve um objecto (prometo que nos posts futuros vou falar acerca das várias opções de formatação disponibilizadas por esta shell). Para terminar, temos ainda de falar acerca do parâmetro filter. Este parâmetro permite-nos definir um filtro capaz de, como o próprio nome indica, filtrar os dados devolvidos pelo cmdlet get-wmiobject.

Bem, parece-me que por hoje já chega  Apenas dois links para aqueles que queiram obter mais informação em relação ao use do WMI:

http://msdn.microsoft.com/library/en-us/dnclinic/html/scripting06112002.asp

Now playing: Moonspell - Abysmo