{"id":13481,"date":"2011-06-29T00:01:00","date_gmt":"2011-06-29T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2011\/06\/29\/dont-write-wmi-scripts-use-a-powershell-module\/"},"modified":"2011-06-29T00:01:00","modified_gmt":"2011-06-29T00:01:00","slug":"dont-write-wmi-scripts-use-a-powershell-module","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/dont-write-wmi-scripts-use-a-powershell-module\/","title":{"rendered":"Don’t Write WMI Scripts, Use a PowerShell Module"},"content":{"rendered":"

Summary<\/b>: Learn how to use a free Windows PowerShell module to avoid writing WMI scripts to get common administrator information.<\/p>\n

 <\/p>\n

Microsoft Scripting Guy Ed Wilson here. One of the things that is really cool about Windows PowerShell modules, is that you can mix and match them. In this way, a module, a pair of modules, or an entire collection of modules becomes the tools for a bespoke script solution. I can tailor the solution to meet my exact needs, and to provide access to exactly the information I need.<\/p>\n

If I am the author of the module, I can use it for my own needs, store it in my personal modules directory, and I have a tool to use. In addition to personal use, if I share the module with my co-workers, I now have a tool to use across the network. It is easy to share a module, and there are more than 100 modules in the Scripting Guys Script Repository.<\/p>\n

With Windows PowerShell, quite often I can find a module that contains the capability I need, which means I avoid writing a script. To garner maximum return on my time, when I need to write a script, I should write a module.<\/p>\n

However, as I indicated earlier, many times I do not need to write anything because a module already exists. For example, an excellent module is the one written by Microsoft PowerShell MVP Richard Siddaway. Richard wrote a module that he calls PAM–the PowerShell Admin Modules. The PAM consists of a number of modules. To install, all you need to do is to first unblock the compressed (.zip) file that arrives when downloaded via codeplex<\/a>. Next, copy all the folders into the modules directory. It is very important to first unblock the download files, or the module will never work properly (not just the PAM–any module; see this Scripting Wife article for the details of blocked files, and a cool workaround<\/a>).<\/p>\n

To find decent information about the installed operating system on a computer (either local or remote), use the Get-OsInfo<\/strong> advanced function from the PAM. The command and the associated results appear here.<\/p>\n

PS C:\\> Get-OSInfo <\/p>\n

Caption                 : Microsoft Windows 7 Enterprise<\/p>\n

ServicePackMajorVersion : 1<\/p>\n

ServicePackMinorVersion : 0<\/p>\n

BuildNumber             : 7601<\/p>\n

Code Set                : Latin I<\/p>\n

Country Code            : USA<\/p>\n

Install Date            : 8\/7\/2009 1:26:32 PM<\/p>\n

Locale                  : English – United States<\/p>\n

OSArchitecture          : 64-bit<\/p>\n

OS Language             : English – United States<\/p>\n

OS Type                 : WINNT<\/p>\n

BootDevice              : \\Device\\HarddiskVolume1<\/p>\n

SystemDevice            : \\Device\\HarddiskVolume2<\/p>\n

Version                 : 6.1.7601<\/p>\n

WindowsDirectory        : C:\\Windows<\/p>\n

The information returned by the Get-OSInfo<\/strong> function is extremely useful. Now, do I have to use Get-OSInfo<\/strong>? No, in fact, until PAM came along, I used WMI to retrieve the information. The information is readily available from the Win32_OperatingSystem<\/strong> class. Here is the command I generally used.<\/p>\n

PS C:\\> Get-WmiObject win32_operatingsystem<\/p>\n

 <\/p>\n

SystemDirectory : C:\\Windows\\system32<\/p>\n

Organization    : Microsoft IT<\/p>\n

BuildNumber     : 7601<\/p>\n

RegisteredUser  :<\/p>\n

SerialNumber    : 00392-918-5000002-85165<\/p>\n

Version         : 6.1.7601<\/p>\n

The problem with the above output, is that several of the properties in which I am interested do not appear directly. This is easily addressed by sending the output to the Format-List<\/strong> cmdlet and using the wildcard character (an asterisk) to retrieve all of the property information. The revised command becomes the one that appears here.<\/p>\n

Get-WmiObject win32_operatingsystem | Format-List *<\/p>\n

The command and associated output appear in the following figure.<\/p>\n

\"Image<\/a><\/p>\n

One problem is the output is very extensive. In addition, some of the properties do not return any information, and others, such as InstallDate<\/strong>, return the information in an unusable fashion. This is the great thing about a Windows PowerShell Module: Richard picked out the information that is commonly utilized, cleaned up the output, and then packaged it in a form that is easily consumable for other people. Therefore, my choice now is as follows: do I write a long command that does not return the information I need and that returns it in a fashion I cannot use, or do I type a simple command —Get-OsInfo<\/strong>–and receive only the information I seek? Hmm…it is not much of a choice is it?<\/p>\n

In addition, because Richard wrote his advanced function in an intelligent manner and he returns objects, I can further manipulate the information to retrieve exactly what I need. For example, one of the things I like to know is when the operating system was installed. It’s not like it used to be when I used to reinstall Windows every six months, but a fresh installation does solve lots of strange problems. With an automated deployment, it can be done quicker than it takes to troubleshoot some problems. To get this information, I use the Get-OsInfo<\/strong> function as appears here.<\/p>\n

PS C:\\> (Get-OSInfo).’install date’ <\/p>\n

Friday, August 07, 2009 1:26:32 PM<\/p>\n

There are two things of note here. The first one is that because the property name has a space in it, I need to place quotation marks around it. I use single quotation marks, but double quotation marks would work as well. The following command illustrates this approach.<\/p>\n

PS C:\\> (Get-OSInfo).”install date” <\/p>\n

Friday, August 07, 2009 1:26:32 PM<\/p>\n

So why did I use single quotation marks? On my laptop, they are easier to type (do not have to hold down Shift as I do when typing double quotation marks.) <\/p>\n

Now, if I want to figure out how many days it has been since the operating system was installed, I can use the New-TimeSpan<\/strong> cmdlet and pass it the ‘install date’<\/strong> property from the Get-OsInfo<\/strong> advanced function. The command and associated output appears here.<\/p>\n

PS C:\\> New-TimeSpan -Start (Get-OSInfo).’install date’<\/p>\n

 <\/p>\n

Days              : 684<\/p>\n

Hours             : 21<\/p>\n

Minutes           : 15<\/p>\n

Seconds           : 40<\/p>\n

Milliseconds      : 269<\/p>\n

Ticks             : 591741402692880<\/p>\n

TotalDays         : 684.885882746389<\/p>\n

TotalHours        : 16437.2611859133<\/p>\n

TotalMinutes      : 986235.6711548<\/p>\n

TotalSeconds      : 59174140.269288<\/p>\n

TotalMilliseconds : 59174140269.288<\/p>\n

This output is not precisely the answer to my question (about the number of days) because it returns more information than just days. Using dotted notation, I can easily only return the days by using the following command:<\/p>\n

PS C:\\> (New-TimeSpan -Start (Get-OSInfo).’install date’).days<\/p>\n

684<\/p>\n

PS C:\\><\/p>\n

I asked Richard about the PAM project, and here is what he had to say:<\/p>\n

“The PowerShell Admin Modules (PAM) are currently on version 0.6 (6 releases), comprise eight modules, and supply a total of 49 functions. Additions to the range are in the pipeline in terms of extra modules and in some cases extra functions.<\/p>\n

I’ve been blogging, writing and speaking about Windows PowerShell since 2006 so why add the PAM project to the list. There are a number of reasons:<\/p>\n