WMIC: Leveraging the power of WMI

We’ve covered different pieces of WMI in previous posts, but we have yet to discuss the Windows Management Instrumentation Command-Line (WMIC) in detail. The WMIC provides administrators easy access to the WMI infrastructure. Prior to the WMIC, you could only access the management infrastructure via the providers or an API. Since the ultimate goal of WMI is to make life easier for system and application administrators, this obviously presented a problem.

The WMIC environment allows interactive queries or scripting. It is interoperable with existing shell and utility commands and can be extended by scripts and other administration-oriented applications. WMIC is included with Windows XP and later operating systems. However, since WMIC works locally and remotely, it is possible to run WMIC commands against Windows 2000 systems remotely so long as the particular action is supported by WMI on the target machine. Beyond the ability to use WMIC against local and remote systems, there are other significant benefits:

WMIC leverages existing OS WMI providers and can leverage additional providers that are added to the system

WMIC can generate output in multiple formats such as .TXT, .CSV, .HTML and .XML

WMIC has very powerful functionality natively available, however it is an extensible tool

So that should be enough of the marketing fluff around WMIC. How exactly do you use it? There are two modes of use for WMIC – Interactive or Scripting. In Interactive mode, WMIC provides and ‘environment’ for scripting. The environment allows you to enter commands and view the results in the immediate display – just like the standard command line interface you are accustomed to. The Interactive environment also allows the use of the discoverable help which is context sensitive. In the screenshots below, you can see the WMIC Interactive environment, which is launched by running WMIC from a command prompt, followed by examples of the help features:

So now let’s look at WMIC in action in Interactive mode. In these examples, I am going to get information about two systems – the local and the remote. There is a command set to retrieve Operating System information as shown below:

So I know that I can probably use the OS GET command, but what data can I retrieve? Let’s look at the context sensitive help:

That’s quite an exhaustive list. I think I want to get the following information about my systems – Name of the system, what OS is installed and the build number:

By the way, those are not misspellings in the output – the symbols for ® and ™ don’t really translate into command line output. So, this format is fairly readable, but if we were to add more properties, the output could become very confusing. Enter the /format switch. In this case, rather than the default table format, I want to see this information in list format:

Pretty easy, right? So now let’s run the same command for a remote machine:

As you can see, we specify the name of the remote system with the /NODE switch. If the value being passed has special characters such as a hyphen or a slash, you need to enclose the switch value in double quotes. Also remember that you will need to create an exception on your system to allow WMI to be accessed remotely in the Windows firewall, or whatever local firewall you may be using.

So those are some basic information gathering pieces – but what about if we want to actually do something on the system – for example, launch an executable, such as the Calculator? There is a command set called PROCESS that can be used to do just that:

And there we have our Calculator application launched, including the Process ID for CALC.EXE

As you can see, WMIC is very powerful – and that’s in Interactive mode where we have to enter one command at a time. WMIC commands can also be run from scripts – let’s take a look at a fairly simple example to capture the same information that I captured in Interactive mode about my secondary system – BANGANALYZE-380. I created a simple batch file called WMIC_Test.bat with a single command, as shown below:

What advantage does this have over powershell? Both look like you need to be more of a programmer than an admin to get the power out of them, so I don't know which would I should learn.

Scott Bateman

20 Jun 2008 6:27 AM

One major benefit of WMIC over powershell is the ability to look at information on remote machines using the /node: command.

For a good example of where WMIC is far superior, just try using powershell to check the OS version installed on 3 different machines. You'll find yourself using the powershell WMI methods which are much harder to get to and require a lot more typing than WMIC.

ABHIJAY .KS

10 Nov 2008 8:44 AM

THIS ONE IS OF GREAT HELP FOR ME.

THANKS

Stephen Galbincea

12 Mar 2009 9:22 PM

I am trying to form a query in WMIC that will return a list of machines that have a particular program installed, such as Windows Search 4. I have a text file that I have created with a list of all the machines on the domain that I am inputting as the nodes, but I am having trouble formulating the query and getting it to output the list of machines to another text file. My goal here is to then take that list of machines and run an uninstall command on just those machines as opposed to running it against all nodes on our network. Any advice is welcome!