< Kapil Mathur is in the process of learning PowerShell to work with WMI and wrote up his findings to date – jps> Automating admin scenarios using PowerShell The preferred scripting language for the WMI world has been vbscript. But if you are a windows administrator writing WMI scripts, chances are that you have been hearing another name lately- PowerShell. To compare the scripting experience in between the two, I tried out my hand at automating some admin scenarios by converting “vbscript” scripts into “PowerShell” scripts. I took two scripts from Alain Lissoir’s book “Leveraging Windows Management Instrumentation (WMI) Scripting” (http://www.lissware.net ) and rewrote them into PowerShell. The scripts covered the following areas – Inventory – viewing dcom application settings (getting the data, extracting useful properties and displaying/storing them somewhere.) Configuration – This script based tool is a complex network configuration script which can configure 15 different network settings like enableDHCP, enableStaticIP, setDNSDomain etc. So here’s my experience with PowerShell vis-à-vis vbscript so far – Inventory scripts are about, getting some data (fromWMI in our case), extracting the relevant data (specific instances and properties) and then either displaying them or storing them somewhere. In all these tasks, PowerShell does pretty well. Let me demonstrate – Display – Alain had written a displayFormattedPropertyFunction() to display formatted properties (length ~100 lines.) This whole formatting thing is encapsulated and taken care of by wmi adapter object and cmdlets like fomat-list,format-table. So user gets all formatting absolutely free! If there is a need to export these objects somewhere, in vbs you have to get all the properties of the object and write them one by one in xml or csv for example. In PowerShell, you just call cmdlets like export-csv, export-xml after extracting the relevant data using select-object. Zero parsing! For the network configuration scenario Length of vbscript ~ 500, length of PowerShell script ~ 200 . Agreed you can’t take numbers at face value but it is plenty of motivation for me to switch to PowerShell. And I am yet to learn many powerrshell tricks. String processing abilties – Inspite of all the hype around the ability to handle objects, there will be cases where string parsing would still be needed (like a script which takes SDDL as input and then does something on it will need to parse the string.) So how does PowerShell fare here? PowerShell has excellent string parsing abilities due to inherent support of .net string object and select-string cmdlet. So if you take a comma separated input, all you do is call $value.split(“,”) and you get an array of strings. Array support – Some WMI methods take arrays as inputs, so this is important to us. Arrays in PowerShell are neat. I don’t have to think about allocating some memory before and then reallocate space using redim (in vbscript). I just go on adding to my array using a ‘+’ operator! Eg. – $IPAddresses = “125.125.125.125”,”200.200.200.200″ $IPAddresses = $ IPAddresses + “250.250.250.250” Or if you want to create a string array of some size and initialize it, you write – [string[]]$IPAddresses = @(“cool”)*$ParsedValue.length Comparison with wsf – One of the good things about the wsh world is wsf format. You can define named and typed paramters or include other scripts in your script at no cost. Well, PowerShell matches wsf’s features and there is no additional xml file to define as well. Just use the name of the parameter inside the script (param($EnableDHCP)) as the named parameter (somescript.ps1 –EnableDHCP ). Dynamic Typecasting – Two examples for this – In vbscript to convert to int, I use var2= cint(var1). In PowerShell, I simply assign the type $var2 = [int]var1 To get a wmiclass object all I do is – $NetworkClass = [WmiClass]\\.\root\cimv2:Win32_NetworkAdapterConfiguration

In another post, I’ll cover the wmi based monitoring story with PowerShell. Kapil Mathur