Windows Management Instrumentation (WMI) really came into its own in Windows Server 2003.While it was available...
programmatically in Windows 2000, it wasn't available to us common folk until Windows XP and Windows Server 2003 were released.
WMI can be used with Active Directory to locate and gather information from objects in an enterprise. Microsoft's goal for WMI is to provide a standard method for Windows management tasks.
There are three required elements for WMI:
OS support -- The operating system must support the instrumentation. While this was first available natively from Microsoft starting with Windows 2000, there was an add-on for Windows NT 4.0.
- Providers -- Providers are components that convert the data between native and WMI APIs and data structures. Windows 2003 introduced many new providers not available in Windows 2000. The provider converts a request for information from the WMI format to the native API. There are a number of WMI providers, such as clusters, trusts, DNS and Active Directory functions such as replication. You can see which providers are available since each has a descriptive file stored in the directory %WinDir%\system32\wbem with the extension .MOF. Editing the file will have a description to tell you the provider. For instance, in the DNSprov.MOF file, we seestring ContainerName;
[Key, Propagated ("MicrosoftDNS_Domain.Name" ):
- Applications and user interfaces -- This is the big one. The providers and OS support is useless without a way to use them. Windows Server 2003 and Windows XP introduced the Windows Management Instrumentation Command-line (WMIC) native tool, which allows you to access information with relative ease. No programming, no special skills needed.
I remember being very impressed with WMIC the first time I came upon it. My co-worker had constructed a command, executed from the WMIC, that queried the Cluster Administrator, got the status of a cluster group, output it to an HTML format, saved it to a Web server and refreshed it every 10 minutes. When executed, this displayed the cluster status in a simple table format that he could access via the Web. Thus he had a simple Web application to monitor his cluster -- all from a single WMIC command.
Now the question is, if you are not a programmer, is this still a great tool? The answer is absolutely. It means that without knowing any of the constructs or anything about providers, you can still get information about a computer.
Getting started with WMIC
To get started, go to a command prompt of any Windows Server 2003 or XP computer and type WMIC. The first time you do this, it installs the WMIC interface, which takes about 30 seconds:
Please wait while WMIC is being installed
At the WMIC prompt, enter /? to get a list of the commands. Note that you will see commands to extract information about the local machine and some domain information such as accounts, groups, etc. Without addressing any providers or perusing namespaces, there is a lot of information available.
Here are some very useful commands. I often have administrators execute these simple commands to give me specific information to help in troubleshooting:
Bootconfig Boot Directory, partition information, Temp Directory, drive OS Boot device, build version, caption, service pack DiskDrive Signature, size, physical characteristics Group Local and domain groups Partition Disk partition information Logon Logon session information Pagefile File name, install date, usage Bios Version, description CPU Description, mfr, max clock speed Memphysical Description, capacity, hot swappable Useraccount Local and user account management QFE List of hotfixes including install date, installed by, QFE#
As I noted previously, use the command /? to find more help. You can use it on sub-commands to get more information.
For instance, Useraccount /? will provide the following list of commands for Useraccount:
USERACCOUNT - User account management.
HINT: BNF for Alias usage.
(<alias> [WMIObject] | <alias> [<path where>] | [<alias>] <path where>) [<verb clause>]
USERACCOUNT ASSOC [<format specifier>]
USERACCOUNT CALL <method name> [<actual param list>]
USERACCOUNT CREATE <assign list>
USERACCOUNT GET [<property list>] [<get switches>]
USERACCOUNT LIST [<list format>] [<list switches>]
USERACCOUNT SET [<assign list>]
This is a fairly typical list of command options at this level.
GET will return information on specific properties
LIST lists useraccount information in several formats
SET defines properties
You can then use USERACCOUNT GET /? to see the commands for GET:
GET [<property list>] [<get switches>]
NOTE: <property list> ::= <property name> | <property name>, <property list>
The following properties are available:
Property Type Operation AccountType N/A N/A Description N/A N/A Disabled N/A N/A Domain N/A N/A FullName N/A N/A InstallDate N/A N/A LocalAccount N/A N/A Lockout N/A N/A Name N/A N/A PasswordChangeable N/A N/A PasswordExpires N/A N/A PasswordRequired N/A N/A SID N/A N/A
The following GET switches are available:
/VALUE - Return value. /ALL (default) - Return the data and metadata for the attribute. /TRANSLATE:<table name> - Translate output via values from <table name>. /EVERY:<interval> [/REPEAT:<repeat count>] - Returns value every (X interval) seconds, If /REPEAT specified the command is executed <repeat count> times. /FORMAT:<format specifier> - Keyword/XSL filename to process the XML results.
The /Format GET switch allows you to output the data in various formats including XML, table, etc. The /Every switch collects the data on time intervals.
WMIC UserAccount GET name,PasswordExpires /Value
This returns all the domain user accounts, but restricts the output to the attributes "name" and PasswordExpires. You can also use the SET command to define attributes.
It should be obvious that WMIC allows a manual manipulation of WMI commands and associated APIs. Applications and software tools access these commands and APIs programmatically. It probably doesn't make sense to use WMIC to define user account attributes, but the example above demonstrates how it is done.
Using the QFE command
One of the most useful commands I've found at this level is the QFE command. QFE is a Microsoft acronym for Quick Fix Engineering, more commonly referred to as a hotfix. This also includes security patches. When troubleshooting a problem, often information is found signaling that a hotfix was produced to correct the problem. However, with all the hotfixes and security patches, how can you tell which one has been applied? One way to find such a list is to use the NetDiag tool: NetDiag /v. This will give a simple list of KBs, but with no description, no date installed and no information about the account used to install the QFE.
Using WMIC QFE, however, provides valuable information about hotfixes and security patches. You can run it on your laptop and get quite a list. A sample is shown here. The command used to generate this CSV output is:
WMIC QFE GET /format:CSV >QFE.CSV
|MORONI,Windows XP Hotfix - KB873333,Update,KB873333,,Administrator,7/7/2005,,SP3,|
|MORONI,Windows XP Hotfix - KB873339,Update,KB873339,,Administrator,7/7/2005,,SP3,|
|MORONI,Windows XP Hotfix - KB883667,Update,KB883667,,hpadmin,10/24/2005,,SP3,|
|MORONI,Security Update for Windows XP (KB883939),Update,KB883939,,Administrator,7/7/2005,,SP3,|
|MORONI,Windows XP Hotfix - KB884575,Update,KB884575,,hpadmin,10/24/2005,,SP3,|
|MORONI,Windows XP Hotfix - KB885250,Update,KB885250,,Administrator,7/7/2005,,SP3,|
|MORONI,Windows XP Hotfix - KB885835,Update,KB885835,,Administrator,7/7/2005,,SP3,|
|MORONI,Windows XP Hotfix - KB885836,Update,KB885836,,Administrator,7/7/2005,,SP3,|
|MORONI,Windows XP Hotfix - KB885855,Update,KB885855,,hpadmin,10/24/2005,,SP3,|
|MORONI,Microsoft .NET Framework 1.0 Hotfix (KB886906),Update,M886906,,Hewlet Packard,7/7/2005,,1.0,|
|MORONI,Microsoft .NET Framework 1.0 Service Pack 3 (KB867461),Update,S867461,,Hewlet Packard,7/7/2005,,1.0,|
|MORONI,Microsoft .NET Framework 1.1 Hotfix (KB886903),Update,M886903,,Hewlet Packard,7/7/2005,,1.1,|
|MORONI,Microsoft .NET Framework 1.1 Service Pack 1 (KB867460),Update,S867460,,Hewlet Packard,7/7/2005,,1.1,|
|MORONI,FIX: ASP stops responding when calling Response.Redirect to another server using msxml4 sp2,,Q827429,,Gary Olsen,10/17/2006,,,|
|MORONI,FIX: ASP stops responding when calling Response.Redirect to another server using msxml4 sp2,,Q927978,,Gary Olsen,11/14/2006,,,|
Note that we see the KB number of the hotfix, the name of the account it was installed under, the date of the installation and, in some cases, the description of the hotfix.
While the example here forces the output to a .csv so you can manipulate it in Excel, you can simply run WMIC QFE >qfe.txt and look at the qfe.txt file. That will give you positive proof of whether a given hotfix was installed and, if it was, you can see who installed it and when.
Using WMI to filter Group Policy
In addition to using WMIC to gather information, Group Policy permits the application of a WMI filter to Group Policyyou can apply a WMI filter to Group Policy as well. For instance, you could build a WMI query to determine the amount of memory on the machine, or the OS, and filter the application of that policy based on whether the machines had a certain OS or a certain memory size. (In a future article, I will go into more detail on this.)
WMIC isn't the answer to all your needs in querying for data, but it can give you the same data extracted by tools. While this article focused on some simplistic applications, you can use it to query Active Directory, clusters and anything else that has WMI providers to gather information. Microsoft's TechNet is a great resource for WMI provider information and there are a number of books written on WMI. I certainly recommend exploring more about how WMI can meet your administrative needs.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Windows Server-File Systems.