How to find if a certain patch is applied to an ESX Host?

[PaulLJackson]

How can I find if a certain patch is applied to an ESX Host? Looping throught all of the hosts in my Virtual Center would be a bonus.

Thanks

[LucD]

For getting the list of patches applied to an ESX server have a look at .

If you want to run this on all the ESX servers in your VC you could use something like this.

Get-VIServer -Server <VC-server>
 
filter Get-Patches {
  if($_.State -eq "Disconnected") {return}
 
  $PatchList = "" | Select-Object VMHostname, Patches
  
  $pm = Get-View (Get-View (Get-VMHost -Name $_.Name).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") -or
         ($task.Info.State -eq "queued")){
    $task = Get-View $taskImpl
  }
  $PatchList.VMHostName = $_.Name
  $PatchList.Patches = $task.Info.Result
  $PatchList
}
 
Get-VMHost | Get-Patches | Out-Default

The filter Get-Patches returns an object with the properties VMHostName and Patches.

The Patches property is in fact an array of HostPatchManagerStatus objects.

You could easily format the output or do further testing on the contents of the array.

[LucD]

I had a further go at the script and I have added a simple output filter.

It shows some essential patch information.

Get-VIServer -Server <VC-server>
 
filter Get-Patches {
  if($_.State -eq "Disconnected") {return}
 
  $PatchList = "" | Select-Object VMHostname, Patches
  
  $pm = Get-View (Get-View (Get-VMHost -Name $_.Name).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") -or
         ($task.Info.State -eq "queued")){
    $task = Get-View $taskImpl
  }
  $PatchList.VMHostName = $_.Name
  $PatchList.Patches = $task.Info.Result
  $PatchList
}

filter Print-PatchInfo {
  Write-Host "Server : " $_.VMHostName
  
  foreach($patch in $_.Patches){
    Write-Host $patch.ID
	Write-Host " Applicable : " $patch.Applicable
	Write-Host " Installed  : " $patch.Installed
	Write-Host " Integrity  : " $patch.Integrity
	Write-Host " Restart    : " $patch.RestartRequired
	Write-Host " VM off req : " $patch.VmOffRequired
	Write-Host " Prequisites:"
	foreach($prereq in $patch.PrerequisitePatch){
      Write-Host "   " $prereq.Id
	}
  }
}
 
Get-VMHost | Get-Patches | Print-PatchInfo

[PaulLJackson]

When I run the attached PS file, I receive:

The first line in the PS file was changed to

Get-VIServer -Server omac-inesx01 The root user was used.

omac-inesx01 443

Get-View : Permission to perform this operation was denied.

At C:\Program Files\VMware\Infrastructure\VIToolkitForWindows\ESX-patch-report.

ps1:10 char:27

+ $pm = Get-View (Get-View <<<< (Get-VMHost -Name $_.Name).ID).configManager

.patchManager

You cannot call a method on a null-valued expression.

At C:\Program Files\VMware\Infrastructure\VIToolkitForWindows\ESX-patch-report.

ps1:14 char:37

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

Get-View : Cannot bind argument to parameter 'MoRef' because it is null.

At C:\Program Files\VMware\Infrastructure\VIToolkitForWindows\ESX-patch-report.

ps1:17 char:19

+ $task = Get-View <<<< $taskImpl

Server : omac-inesx01.intranet.hdr

Applicable :

Installed :

Integrity :

Restart :

VM off req :

Prequisites:

[LucD]

The script needs to connect (Get-VIServer) to the VC server.

It won't work with a connection to an ESX server.

[rolandt]

This is great but as written is specific to ESX 3.5.0. Can it be modified to work with ESX 3.0.2?

[LucD]

The method uses the repository from Update Manager and since that is available from ESX 3.5 (and 3i) onwards I'm afraid it won't work for older ESX versions.

[bleibold]

I know this thread is a bit old, but hoping someone is still looking at it. I am trying to get this script to run as it is exactly what I am looking for, but when ever it runs, I get an error on the tasks pain in VirtualCenter that says "metadata for patch missing."

I found the repository url in the vc-integrity.xml and used that, but I am wondering if that is my issue?

Any help would be appreciated.

Thanks!

[LucD]

Looks like you are not pointing at the correct URL.

The repository URL is composed as follows:

*) the name of the VC server

*) the port used for the VC server. Use the VIC and goto . This is "hostupdate\esx\esx-3.5.0" for patches for ESX 3.5 servers

Supposed the VC service runs on a server called MyVCServer, this will give this URL: "http://MyVCServer:80/vci/hostupdates/hostupdate/esx/esx-3.5.0".

Is the URL you are using in the script build up in this way ?

Btw I just ran the script in VITK 1.5 and it works without a problem.

[bleibold]

Thanks for the quick response. I did as you said.

went to <Administration><VirtualCenter Management Server Settings><Web Service> and use the port mentioned in the http field. The port listed is 80.

use the path you find in the vci-integrity.xml file under <docRootMap><docRootHostUpdates><namespace>. The default is "/vci/hostupdates". Here is what my .xml file has:

<docRootHostUpdates>

<namespace>/vci/hostupdates</namespace>

use the path from the base folder mentioned in the vco-integrity.xml file under <docRootMap><docRootHostUpdates><namespace>. This is "hostupdate\esx\esx-3.5.0" for patches for ESX 3.5 servers. Here is what I have there

<path>D:\Program Files\VMware\Infrastructure\VMware Update Manager\Data\</path>

based on that, I used the following url:

Still got the metadata for patch missing error. I know I must be missing something her, but I used pretty much all the defaults (with the exception of installing on the D: drive).

Any idea on what I am missing?

Thanks!

[LucD]

The URL looks correct.

I'm also storing the patch repository on the D-drive, so that shouldn't be a problem.

Did you install and enable the Update Manager plugin in your VIC ?

If you right-click an ESX server and select "Scan for Updates" does that work ?

Or do you also get a message about the meta-data ?

[bleibold]

Yes, Update Manager plugin is installed on the VirtualCenter server and enabled.

Manual scan for updates works fine. Not sure what I have wrong here, but must be missing something...

[LucD]

And I suspect the "Remediate" task completes as well ?

It looks more and more as if one of the downloaded patches hasn't been downloaded correctly/completely.

[bleibold]

The remediate task has worked in the past couple of weeks, but haven't run it lately.

I have a test instance of VC on another server, so I pointed the script at that one, just changed the VC server name and ESX host name and it worked fine. So it appears to be something specific to the one VC server, just not sure what. Should I try to download the most recent updates maybe?

[LucD]

Yes, try to download the latest updates.

Isn't that a scheduled task in your VC ?

Check the UM logs in C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Logs.

Perhaps there is a message that explains what is happening.

For example, if there is less than 500 Mb free space available the patch downloads will fail.

[bleibold]

Yes, it is a scheduled task, but I have it set to run once per month. I kicked it off manually and got an error. So I stopped the Update Manager service, stopped the VirtualCenter service, restarted the VirtualCenter serivce, then restarted the Update Manager service. Then logged back into the VIC and was able to sucessfully run the download job. I got 29 new patches.

I tried the script again and it failed. There are 11 ESX servers mananged by this instacne of VC and I had only been trying one. I then tried to run the scan against a different one on this same VC and it worked! So I went through and tried them all. 4 of the 11 work fine, the other 7 get the same error (metadata missing). They are all exactly the same version and build and all configured the same way, so that's confusing. They all work if I run the scan manually but not via the script.

I checked the logs on a sucessfull run from the script and found it updated two logs, the 2009_04_08.request.log and the vmware-vci-log4cpp.log. When I checked the same logs after a failed run, neither had any new entries, so it's like nothing is getting logged as far as Update Manager is concerned.

[LucD]

Since the script seems to work for 4 out of 11 ESX servers I think the vc-integrity.xml file is ok.

The "metadata is missing" message seems to be a catch-all message from the Update Service.

There are quit a lot entries if you look for that message in the VMTN communities.

Some things you could try:

*) restart the VMware Update Manager Service on the VC

*) check the FW rules on the ESX servers to see if the updateManager rule is enabled

*) if your connections do not go over port 80 you will have to update the updateManager FW rule accordingly (with esxcfg-firewall)

[bleibold]

Bingo! Update Manager was not enabled in the firewall on 7 of my 11 servers for some reason. Not sure why as they were all built pretty much the same way. And not sure why the scan and remediation worked via the VIC, it must scan differently than the script does, but regardless, after checking the box for update manager on all hosts, the script now works on them all.

Thanks for your help.

Now I just need to find a way to run this via a script and create some type of report for our security/audting folks and I'll be set. I've been messing with the "start-transcript" and that seems to work, probably not the most elegant way to do it, but I am a newbie to powershell.

[PaulLJackson]

I initially tried connecting to the Virtual Center which didn't work. I didn't realize this was specific to 3.5. I wanted this script so I could use it to upgrade all of my machines to 3.5. I guess I should have said that.

Thanks for the effort.