Gallery

Managing with WMI

Posted on 12 Jul 2007 at 17:52

Thomas Lee rounds off the basics of .NET by examining how Windows Management Instrumentation can be used in effective systems management.

Accessing WMI remotely

One of the more interesting aspects of WMI is the ability to use WMI information on remote systems. PowerShell's Get-WMIObject cmdlet enables you to specify the computer name from which to retrieve class information, as you can see in:

PSH [D:\foo]: get-wmiobject -cred $cred -computername smallguy.kapoho.net `

-class win32_computersystem

Domain : kapoho.net

Manufacturer : Dell Computer Corporation

Model : Dimension 4600i

Name : SMALLGUY

PrimaryOwnerName : thomas lee

TotalPhysicalMemory : 266293248

One of the issues that arises when dealing with WMI remotely is that of credentials. In the sample script above, I called Get-WMIObject and passed its credentials in the variable $cred. You can easily obtain these credentials by using the Get-Credential cmdlet, as follows:

PSH [D:\foo]: $cred=get-credential

PSH [D:\foo]: $cred | fl *

UserName : kapoho\tfl

Password : System.Security.SecureString

When you call the Get-Credential cmdlet, PowerShell pops up the familiar credential dialog you can see below, and once you've obtained credentials for the remote system you pass them using the -cred switch to the Get-WMIObject cmdlet, as above.

WMI, as you might have already gleaned from this column, is an extremely powerful mechanism and, like any such weapon, can be dangerous in the wrong hands. In general, you want to provide WMI ability only to administrators, but there are cases where some classes might be useful to non-admins, or to people you don't want to make an admin! You can configure WMI security using the WMI MMC snap-in wmimgmt.msc. By default, only "authenticated users" can access WMI infrastructure on the local machine. Remote access requires the user to be a member of the "Administrators" group. You can use the wmimgt.msc console to change these settings, but be very careful if you do, and be sure to test all changes in the WMI security settings carefully and completely.

Network Access Protection and WMI

One of the more exciting features of Longhorn and Vista is NAP (Network Access Protection). The idea of NAP is simple - client computers define their own "health" and present a statement of health whenever they try to access another system or get access to your network. Systems deemed unhealthy are denied access, while healthy systems are allowed access, subject to the normal authorisation process.

NAP makes use of WMI to determine the statement of health, using a WMI class in the root\securitycenter namespace. You can access one of the health indicators, the antivirus product, using the AntiVirusProduct class:

PSH [D:\foo]: gwmi -namespace root\securitycenter -class AntiVirusProduct

companyName : McAfee, Inc.

displayName : McAfee VirusScan Enterprise

enableOnAccessUIMd5Hash :

enableOnAccessUIParameters :

instanceGuid : {918A2B0B-2C60-4016-A4AB-E868DEABF7F0}

onAccessScanningEnabled : True

pathToEnableOnAccessUI :

pathToUpdateUI :

productUptoDate : True

updateUIMd5Hash :

updateUIParameters :

versionNumber : 8.5.0.781

Like the .NET Framework itself, WMI provides a vast array of classes, methods and properties that I've only been able to touch on in this article. You can use these powerful components to manage your computer systems, locally or remotely, but do use them with care. As I've demonstrated, you can access the WMI classes using PowerShell, and you can also use the features supported by WMI in conjunction with other .NET components to create scripts that are rich and useful, and also produce good-looking output. As an administrator in a Microsoft shop, knowing how to access WMI can be very helpful and adds a powerful new tool to your toolkit.