ESX Patch Reporting Utility

[davidm3281]

Hello -

I know I can do an "esxupdate -query" to see a list of all patches installed on ESX.

I need a better way to do this. I need some sort of utility or program that can extract this information and create a report -- better yet, a way to do this across multiple ESX hosts.

Our auditors want to see our patch policy and procedures and produce reports showing that we're doing it and when. There is management oversight as well.

Manually trying to copy/paste the results using PUTTY is very cumbersome.

In fact, the results are not quite the same across all our boxes anyway, to try and put them all on the same worksheet. I.E., one ESX host may have been initially installed with ESX 3.01, later upgraded to ESX 3.02, and later upgraded to ESX 3.5. Another ESX host that is newer may have gone straight to 3.02 or 3.5. It looks like some of the older boxes actually have more modules installed.

Any help with this would be appreciated.

[halr9000]

Grab plink which is a part of the putty package.

$VMrpm = plink user@server -pw <PASSWORD> rpm -qa VM*

Hal Rottenberg

Co-Host, PowerScripting Podcast (http://powerscripting.net)

[davidm3281]

The problem is that we do not allow root login remotely.

So PLINK doesn't really work for us.

There has to be a way to do this with Powershell and VC API.

[halr9000]

The problem is that we do not allow root login remotely.

So PLINK doesn't really work for us.

But you have to admit, it does solve the copy/paste problem!

You might consider making a service account which has sudo access to rpm.

There has to be a way to do this with Powershell and VC API.

I'm not saying it can't be done, but a brief glance seems to indicate to me that the VI API does not include means to check for component versions. I know you can get the overall version of ESX, but I've not seen how to grab those RPM versions.

Hal Rottenberg

Co-Host, PowerScripting Podcast (http://powerscripting.net)

[admin]

This can be done using the HostPatchManager managed object, specifically by using the ScanHostPatch_Task method. It's not the most straightforward interface, unfortunately, and I don't have a sample at hand. If someone wants to give it a try, feel free to jump in, otherwise we'll see about getting a sample script developed and maybe posted to the PowerShell blog.

[LucD]

It is indeed not straightforward.

The sample script below shows how it could be done but it has a few prerequisites.

1) the script assumes that the VI Update Manager (UM) depot is present

2) it assumes that all patches are downloaded and available in the UM depot

3) if does not take into account any proxy that could be between you and the VC

Get-VIServer -Server <VC-server>

$pm = Get-View (Get-View (Get-VMHost -Name <ESX-hostname>).ID).configManager.patchManager
$repository = New-Object VMware.Vim.HostPatchManagerLocator
$repository.url = "http://<VC-server>:<VC-hhtp-port>/vci/hostupdates/hostupdate/esx/esx-3.5.0"

$taskImpl = $pm.ScanHostPatch_Task($repository,"*")

# Wait for task to finish
$task = Get-View $taskImpl
while ($task.Info.State -eq "running"){$task = Get-View $taskImpl}

# Display the results
foreach($patch in $task.Info.Result){
  Write-Host $patch.Id $patch.Installed $patch.Applicable
}

Some annotations:

- the repository URL is composed of

1) the VC-server - ex http://vcserver

2) the VC http port - ex :81

3) Apache path to the UM depot folder - ex /vci/hostupdates

4) path to the depot folder for the specific ESX version -ex /hostupdate/esx/esx-3.5.0

In my test environment that gives: http://app1.test.local:81/vci/hostupdates/hostupdate/esx/esx-3.5.0 for a scan of an ESX 3.5 host.

- the path to the specific ESX version can normally be found on your VC in the folder C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Data

- I didn't use the Wait-Task cmdlet since there appear to be some problems with that. Instead I rolled my own loop to wait till the task is complete

The script is definitely open for improvements.

- get the ESX version of the target host and compose the URL automatically

- handle other return states from the task. Now it supposes the task completes successfully.

- pretty-print the results

- report more properties for each patch. See HostPatchManagerStatus for all the available fields