The Install-VMHostPatch help Example 2 is:
C:\PS>$host | Install-VMHostPatch -WebPath http://myInternalWebServer/esx40/ESX400-200906001/metadata.zip
However in PowerShell $host is a special read-only variable and can't be used to store a VMHostImpl object. So I think the example should read:
C:\PS>$host1 | Install-VMHostPatch -WebPath http://myInternalWebServer/esx40/ESX400-200906001/metadata.zip
Regards, Robert
Today I found the same problem in both examples of the Get-VMHostFirmware cmdlet.
The examples in the help of the Set-VMHostFirmware cmdlet even are missing the $ in front of the variable. E.g. Example 1 is:
C:\PS>Set-VMHostFirmware -VMHost Host -DestinationPath 'c:\' -BackupConfiguration
And should be:
C:\PS>Set-VMHostFirmware -VMHost $Host1 -DestinationPath 'c:\' -BackupConfiguration
Hello, RvdNieuwendijk-
Good attention to detail on your part to catch the typo on Example 2 for Install-VMHostPatch.
The Set-VMHostFirmware examples are technically valid as written, though, aren't they? One could have a VMHost named "host", and could be passing the VMHost's name to the cmdlet (not passing a variable, but a string), rather than a VMHost inventory item.
Granted, not many people would be naming their hosts "host" or "host1", but for those who do, the examples should work as written.
I agree that the Set-VMhostFirmware examples are technical valid as you can use hostnames instead of VMHostImpl objects. But I think that the PowerCLI examples should be consistent over all the cmdlets. Imho it is strange to use objects in one example and names in another.
I am for consistency, too.
Though, a somewhat beneficial side-effect of the inconsistencies in this case is that they show a few different ways in which the cmdlets can be used...
I totally agree. But in this case it would be nicer if all the examples were for one cmdlet so you could see the different ways at a glimpse.