WMIC Wildcard Search using like and %

This is a quick post to provide some detail on using the wildcard search for WMIC.  This feature of the command structure will allow you to use like conditions in a where clause to look for objects that match a specific pattern.  For those of you comfortable with the SQL syntax for the same task, this will be quite familiar.

Background – Regular WHERE clause

First, let’s look at using WMIC without wildcards for comparison.  All of the statements below are run while at the WMIC command prompt.  To get to the WMIC command prompt, simply go to a Windows command window and type WMIC.

Command to show you all of your services

  • service

Command to show you all of your services that are running

  • service where state=”Running”

Command to show you specific data about your services that are running

  • service where state=”Running” get Name, DisplayName, PathName, ProcessID

Filtering it Down – the LIKE Operator

So you’ll notice that the list of services you have running is a bit difficult to sift through as there are a lot of them.  You can always export this list to a text file by calling WMIC with that command line and piping to a text file, but when you are looking for a specific set of data, I like elaborating on the where clause.  The key thing to keep in mind here is that you need to enclose the full where clause in double quotes to keep it as a single string.  As you’ll notice above, it is possible to use state=”Running” by just not using any spaces in the clause, however that doesn’t work with like.

For example, this will not work

  • service where PathNamelike”%SQL%” get Name, DisplayName, PathName, ProcessID

But this will

  • service where “PathName like ‘%SQL%'” get Name, DisplayName, PathName, ProcessID

The body of the where clause needs to be wrapped in quotes to make it a contiguous statement that does not get confused as multiple arguments.  There are a couple of interesting conveniences that should be noted about WMIC in general

  1. Using single or double quotes seems to be largely interchangeable
  2. Keywords and commands are not case sensitive

So the trick is that you need to use a slightly different and more complex syntax in order to use the like and % functionality.  Taking this command syntax full circle, you can use the more complex syntax all of the time to avoid confusion

  • service where “state = ‘Running'”

Using this wildcard filtering functionality is one of the most powerful uses of WMIC that applies to your everyday tasks.  You can combine this with the other powerful WMI functionality such as killing processes, starting or stopping services, etc.  So if you wanted to stop all of the services on your server that are running a particular application (we’ll say Widget.exe), you could do something like this:

  • service where “PathName like ‘%Widget.exe%'” call StopService

WMIC continues to be very useful in my work, so I hope you find this post helpful in your activities!

Advertisements

WMIC – A Hidden Gem

Often times I find myself applying “developer-type” solutions to IT administrator problems.  Naturally I was excited as PowerShell a.k.a Monad a.k.a Poshwas gaining notoriety.  I had visions of a tool that would let me peek into services, filesystems, performance counters, etc. for all of my servers including database, application, web, etc.  Much to my dismay, I quickly found that PowerShell only works locally!  Total bummer, but it is a 1.0 product, so I am sure Microsoft had to do some feature triage. Things like AD and WMI took a back seat as there are other ways to get that data.

This means that the best way to query a server for administrative details such as OS version, patches, CPU, memory, running processes, services, etc is still to use Windows Management Instrumentation (WMI).  In my opinion, using PowerShell 1.0 to call WMI is using a sledgehammer to kill a fly.  This is fine, and it will certainly do the trick.  However, if you don’t already know how to wield a sledgehammer, you may be explaining to your boss why it took 4 days to get a working script that one can do without PowerShell in 5 minutes.  Enter WMIC – the command line tool for WMI.

It is amazing this thing doesn’t get more play, because it is awesome and comes built into most recent versions of Windows including Windows XP.   WMIC is simple, elegant and very powerful.  You can accomplish a tremendous amount in just one command line.  This is much more straightforward, in my opinion, that using .NET or even PowerShell to crack open the functionality and data contained within WMI.

To show you how easy and awesome WMIC is, I invite you to try the following steps. Note there is no step to download anything because as long as you are using any modern version of Windows, it is included in the OS:

  • Go to a command prompt and type the following command
  • C:\Documents and Settings\your_id> WMIC

  • This will bring you to the WMIC command prompt. Now type
  • wmic:root\cli> process

Notice the horizontal scrollbar in your results — there is a lot of information provided! This is essentially task manager on steriods. Better yet, it can be scripted out to a text file… on a schedule… etc… Pause for a minute and think about all of the things you can do with this. Now get ready to have your socks rocked off by the number of different items you can get information on. We used the “process” command to get information about the active running processes, but check this out (from within the wmic command prompt):

  • At the WMIC command prompt type
  • wmic:root\cli> /?

Have fun exploring!!! Please post any comments here of useful tricks you have found using WMIC. Here are some other useful resources you may want to check out for more information on WMIC:

http://technet.microsoft.com/en-us/library/bb742610.aspx

http://www.net-security.org/dl/articles/WMIC.pdf

    TeamCity – A Better CCNet?

    I have heard some buzz about a product from JetBrains called TeamCity.  Some very influential technologists such as Roy Osherove seem to like the capabilities, so it is definitely worth a look.  This looks like a good competitor to CruiseControl.NET, so I think I am going to give it a spin.  I’ll update the blog here with my findings as I go along.  The installation sounds to be smoother than CCNet (which can be a bit painful), and some of the features on the TeamCity website look terrific.

    More to come, but if you have any experiences with TeamCity, please share them here in the comments.  My only concern at this point is that it looks like it may cater to more of a “Java” based crowd?  Sometimes tools with a Java history just don’t “feel” right to me and seem to take a long time to get the hang of for teams that are primarily involved with .NET.

    JSON Lives

    It has always been interesting to me how long it can take a technology to become truly rooted in the minds and toolsets of the software development community.  This mandatory waiting period for technological stability seems to be just long enough that most of the fads fall through the cracks.  Many tech buzzwords get thrown around, and there is no shortage of hype.  Web 2.0, AJAX, WCF, WF, Ruby on Rails, NUnit, TDD, Scrum, Agile, Pair Programming… If you take all of the topics of PWOP productions over the past year, I see a bunch of stuff that is undeniably cool, but typically not what I use in my day-to-day work.  With a few notable exceptions, a majority of the newer technologies have not made it into corporate IT departments just yet.  Actuarial types like to see the riff-raff settle out before they build their infrastructure on top of it.

    Most of what you see fly though your RSS reader or pop up on your iPod are curious glances at interesting ideas that will ultimately be a blip on the radar screen of 21st century computing.  To provide an example: I am a huge fan of CruiseControl.NET, but I believe it’s days are numbered.  It is only a matter of time before Microsoft refines TFS, integrates it into Visual Studio, and makes it cheap enough that you’d have to be a zealot to ignore it’s utility.  Does anybody remember Netscape?

    Now I am not trying to make a point that Microsoft eventually gobbles everything up, and they are masterfully elegant at copying other people’s great ideas.  Everyone already knows that.  My point is that it is possible to expend a whole bunch of brain cycles on stuff that does nothing more than… take up your brain cycles.  So how do you pick the winners?  How do you know what to learn today so that 2 years down the road you will be the expert in the technology that is threaded through the fabric of all things software?  How could I have known 10 years ago that time would be better spent learning XML than COM?

    I don’t know.

    But what I do know is that I like the simplicity and the light natured format of JSON (JavaScript Object Notation).  It seems like something that satisfies the requirements of what 95% of XML is used for, without the verbosity.  The simplicity of a URL querysting like name value pair with just enough governance and convention to provide some stability.

    JSON is essentially made up of objects, arrays, and values.  Values can come in any of the following flavors:

    • string
    • number
    • object
    • array
    • true
    • false
    • null

    So you are probably starting to see the recursive nature in that values can be objects and arrays.

    var tacos = {
    "breakfast":
    [ {"meat":"sausage","filler":"egg","quantity":1}
    
    ,{"meat":"bacon","filler":"egg","quantity":1}]
    
    "dinner" :
    [ {"meat":"beef","filler":"beans","quantity":2}
    
    ,�à {"meat":"chicken","filler":"lettuce","quantity":1}]
    }
    

    Although there are several ways to describe this in XML, the most common would probably be

    <tacos>
    
    <breakfast>
    
    <meat>sausage</meat><filler>egg</filler><quantity>1</quantity>
    
    <meat>bacon</meat><filler>egg</filler><quantity>1</quantity>
    
    </breakfast>
    
    <dinner>
    
    <meat>beef</meat><filler>beans</filler><quantity>2</quantity>
    
    <meat>chicken</meat><filler>lettuce</filler><quantity>1</quantity>
    
    </dinner>
    
    </tacos>
    
    

    Of course there are various ways to represent this in XML, but the example above shows how XML can be quite a bit more verbose than JSON.  The JSON example has 223 characters while the XML example has 304.  That is about a 25% savings by using the JSON data format.  Because of the importance of quick response times for background http requests, JSON has taken off in the AJAX community more quickly than in other circles (which is ironic because the X in AJAX means XML :)).

    So is JSON worth spending time on?  Will it develop schema support as robust as XML and develop into the next superstar that shows up as the format for configuration files in Visual Studio 2010?

    What do you think?

    Scott Hanselman Endorses Visual Basic?

    Auditorily enjoying my morning dose of podcasts, I found myself listening to Hanselminutes yesterday, specifically the show on LINQ to XML.  Now it seems that Carl Franklin has always been a great host of the show, but is it just me or has the dynamic changed now that Scott Hanselman has gone to work for Microsoft?  I digress…Visual Basic - A legend in it’s own right

    At any rate, my point is that Scott gave some interesting props to Visual Basic having been a long-time C# proponent.  So now I have a dilemma: Do I buy into his rationale or is he just selling the kool-aid that he has drank?  Why the sudden change of heart.  At least he still used the term “silly” to describe VB 🙂

    Recently, I have gained a strong  appreciation for simplicity in auxiliary tools.  In essence, providing idiot proof ways to do simple things.  In a full scale enterprise application, you are always going to have a high degree of complexity, but what about those little helper tools that surround the core application?  Are these candidates for VB?  Some of the syntactical points Hanselman made combined with some of the new features presented in .NET 2.0 for VB may be pretty cool.  I have no idea because I haven’t worked with true Visual Basic since using VB4 with my Dad on his electronic endcap idea in 1995.  I always have had an affinity for the simplicity of classic ASP, even if it does tempt you to write crappy code.

    So the next time you need to spin up that test app to help with some random task, which project type in Visual Studio are you gonna choose?