Recently I updated my vSphere 4.1 environment to vSphere 5. The main reason was so that I could start testing Windows 8 client and server, which currently aren’t supported on vSphere 4.x. Doing a major version upgrade apparently means that the tools also need to be updated. And since PowerShell can be used for that I thought I’d give it a try. So this is my “Hello, world!!” in PowerCLI. For starters you need to get PowerCLI from here. System requirements are Windows XP or later (including Server OS e.g. Windows Server 2008 R2), both 32bit and 64bit are supported. You also need .NET Framework 2.0 (SP1 reccomended) or later and of course PowerShell – both v1 and v2 are fine.

I’m running my script in the 64bit version of PowerCLI, but it should also work in the 32bit edition. Upon launching the tool, you see this:

The first step will be to connect to the vCenter server controlling my vSphere environment. The command needed for this is listed on top, it’s

Connect-VIServer

My vCenter is using a self-signed and therefore untrusted certificate. I’ll change that when and if I run out of things to do… The connection is established nonetheless. To get a list of commands available I could now use

Get-Help get-*

for example to list all the “get-” commands. On the other hand

Get-VM

would not only be the logical choice, but is also in the list of top commands shown in the first screenshot.

Now let’s examine a few machines in detail. First I’m going to put all VMs in a variable, then examine them. The variable will be “$VMs”, and the command is easy enough:

$VMs = get-vm

Now to see what information is readily available you can look at a few machines like this:

Just replace the index (0) in the square brackets with for example “2” to see the third machine etc. A better way to learn about the capabilities of ANY object in PowerShell (and in the end it comes down to basically everything in PowerShell being an object) is the

Get-Member

command.

The information we’re looking for is somewhat hidden in the “ExtensionData” property/object.

And one step further from there, let’s have a look at the information in “Guest”.

And there it is, “ToolsStatus” shows “toolsOK” for this machine, while they seem to be outdated on another machine. Using

Get-Command *tools*

I found out that there’s a command “Update-Tools” that can be used to update the tools.

Get-Help Update-Tools

lists the possible parameters. Since I don’t want to automatically restart the VMs after the upgrade I’m using the “-NoReboot” parameters. If you want to upgrade really big collections of VMs, have a look at the “-RunAsync” parameter, which will return after initiating the update on a machine and not wait for the command to complete. Instead it will continue with the update in the background.

The finished script looks like this:

$VMs = Get-VM
foreach ($vm in $VMs)
{
	$ToolsStatus = $vm.ExtensionData.Guest.ToolsStatus
	if ($ToolsStatus -ne "toolsOK")
	{
		Write-Host "Updating the tools of" $VM.Name
		$vm | Update-Tools -NoReboot  
	}
}

Don’t forget to connect to your vCenter server or to a vSphere host using “Connect-VIServer”!

… and in action:

The progress is also shown in the vSphere client:

And here’s a screenshot of the script running with the “-RunAsync” Parameter. There are some warnings popping up, so if you don’t want to see them use a filter to only show VMs with Windows operating systems.

Running the script with the “-RunAsync” parameter means every update is now basically its own independent task;

Get-Task

will show the individual task progress.

From here on you could go after individual tasks and see what the exact problem was when trying to update the tools. Each task has a “ObjectId” property which in turn can be linked to the “Id” property of a VM object:

I’ll let you figure out the rest… J