How to check the VMware Tools version across your Windows Server 2008 R2 farm…

I was on a conference call today where someone asked if the server administration team could quickly get a “read” on the VMware Tools version across the server farm.  An ESXi upgrade was being deployed and the team wanted a quick way to see what VMs needed to catch up with the deployment.

Fortunately, I had a bunch of PowerShell snippets lying about that would fit the bill nicely.  Of course, there are a few different ways to accomplish this, depending upon which resources that you are permitted to access; but using PowerShell in a loop with a list of your server names is a quick and easy way to get it done.

So first, a little set up…  Imagine that we are inside a PowerShell script, in a foreach loop (or a function called by that loop) that is calling each computer (our Windows 2008 R2 servers) in a list.  At the time you hit this snippet of code, the current server name in the loop is in the variable $ComputerName, and the output file for the report is $outfile


    write "" | Out-File $outfile -append
    $vmtoolstatus = Get-WmiObject -class Win32_Product -computername $ComputerName | Where-Object {$_.Name -match "VMWare Tools"} |select Name,version
    if ("X$vmtoolstatus" -eq "X")
      write "VMware Tools **NOT** found." | Out-File $outfile -append
      write "WMware tools presence/version info:" | Out-File $outfile -append
      $vmtoolstatus | Out-File $outfile -append


All we’re really doing here is to query the product list for the tools, and if present report the version. And the result look something like this for each item in the loop:

WMware tools presence/version info:
Name                                                        version                                                  
----                                                        -------                                                    
VMware Tools                                      

Simple, but effective and functional. 

I hope it helps!



2012-06-20T22:40:00+00:00 June 20th, 2012|Uncategorized|

About the Author:

Jeremy is just a regular guy that likes to occasionally tell the world about stuff.

Fatal error: Uncaught exception 'GuzzleHttp\Exception\ClientException' with message 'Client error: `POST` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} ' in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promi in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113