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.
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:
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
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
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:
Local machine
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:
This is a fairly typical list of command options at this level.
You can then use USERACCOUNT GET /? to see the commands for GET:
The following properties are available:
The following GET switches are available:
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.
Example:
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:
[TABLE]
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.
