In this chapter, you will learn to:

• Install the vCenter Update Manager PowerCLI Snap-in
• Work with Baselines

• Creating a Baseline
• Updating a Baseline
• Attaching and Detaching Baselines

• Work with Upgrades and Patches

• Scanning a Host
• Staging Patches to a Host
• Remediating a Host
• Including Patching as Part of Host Deployment

• Report the Security Status

• Understanding Datacenter Compliance
• Reporting on Specific Baseline Compliance
• Reporting on Required Patches

• Applying Patches Without vSphere Update Manager

• ZIP Files
• VIB Files

Whatever operating system or application an administrator is responsible for, it is always highly important to keep it up-to-date by applying software updates from the vendor. ESXi is no different in this respect, and VMware provides a management tool known as vCenter Update Manager (VUM) to assist with this process. The tool can be used to manage hosts, guests, and virtual appliances. A separate set of PowerCLI cmdlets is available for download that enables automation for VUM. Additionally, we will demonstrate how to automate ESXi host patching for use when VUM is not available.

Finally, VMware removed VM Operating System patching in vSphere 5.0. Consequently, in this chapter we will focus on ESXi patching, although there will be some coverage of updating VMware Tools and VM Hardware upgrades for VMs.

Install the vCenter Update Manager PowerCLI Snap-in

Before you can use the VUM PowerCLI Snap-in, you must first download and install it. It is a separate download to the core PowerCLI Module, and typically you must match the two in terms of release version in order to function correctly.

Once the VUM PowerCLI cmdlets have been installed, make them available to your existing PowerShell session with the following line:

Add-PSSnapin VMware.VumAutomation

To save the effort of having to do this every time, consider adding the same line into your PowerShell profile. The PowerShell profile is a script file that is executed each time a PowerShell session is opened. Consequently, it is useful to add items to your profile that you frequently need, such as third-party modules and snap-ins like PowerCLI, or functions you have created yourself.

By default, the PowerShell profile .ps1 file does not exist; you can create one with the following:

New-Item -Path $profile -Type file -Force

To edit the profile file, which will start out as blank, you can open it in Notepad:

notepad $profile

Now add modules, snap-ins, functions, or other items into the file; save and close it; and then the next time you open a PowerShell session, everything in the profile file will execute.

Work with Baselines

Once vCenter Update Manager has been installed and configured, and the patch repository has been populated with the available patches, the first step when working with VUM is to create a set of baselines. Baselines determine the set of patches to be applied to a host or guest machine. We will consider two types of baselines: static and dynamic. The essential difference between the two is that static baselines are not updated when new patches are downloaded to the patch repository, whereas dynamic baselines are updated when newly downloaded patches fall into the criteria specified when the dynamic baseline was created.

Creating a Baseline

Included in the set of Update Manager cmdlets is the New-PatchBaseline cmdlet, which you can use in conjunction with the Get-Patch cmdlet to create all the baselines needed in your organization.

First, let’s retrieve a set of patches to add to a new static baseline. This baseline will contain patches for host machines from VMware for ESXi 5.5 that have been released since October 1, 2014. Listing 14-1 demonstrates how to retrieve that set of patches.

Listing 14-1: Retrieving a set of VUM patches

$Patches = Get-Patch -TargetType Host -Vendor VMware* -Product '
 'embeddedESX 5.5.0' -After "01 Oct 2014"

The $Patches variable will contain content similar to this:

Name                 ReleaseDate Severity  IdByVendor          
----                 ----------- --------  ----------          
Updates esx-base     15/10/2014  Important ESXi550-201410101-SG
Updates esx-base     15/10/2014  Critical  ESXi550-201410401-BG
Updates misc-drivers 15/10/2014  Important ESXi550-201410402-BG
Updates sata-ahci    15/10/2014  Important ESXi550-201410403-BG
Updates xhci-xhci    15/10/2014  Important ESXi550-201410404-BG
Updates tools-light  15/10/2014  Important ESXi550-201410405-BG
Updates net-vmxnet3  15/10/2014  Important ESXi550-201410406-BG
Updates esx-base     02/12/2014  Important ESXi550-201412401-BG

Now that your required patches are stored in the $Patches variable, these patches can be provided as part of a new static baseline created with New-PatchBaseline (Listing 14-2).

Listing 14-2: Creating a static patch baseline

New-PatchBaseline -Static -TargetType Host -Name '
 'ESXi - Current (Static)' -Description '
 'ESXi 5.5 patches since 01Oct2014 - 22Jan2015' '
 -IncludePatch $Patches

In a similar vein, you could create a new dynamic baseline, which essentially starts out the same as the static one. This baseline would be for host machines from VMware for ESXi that have been released since October 1, 2014 (Listing 14-3).

Listing 14-3: Creating a dynamic patch baseline

New-PatchBaseline -Dynamic -TargetType Host -Name '
 'ESXi - Current (Dynamic)' -Description '
 'ESXi patches up to the current date' -SearchPatchVendor '
 'VMware*' -SearchPatchProduct 'embeddedESX 5.5.0' '
 -SearchPatchStartDate "01 Oct 2014"

While on October 6, 2014 these two baselines would contain the same patches, three months down the line the static baseline would still contain the same list of patches, but the dynamic baseline would have been updated with any new patches that met the search criteria and would have been downloaded into the Update Manager repository. The patching approach taken by your organization will naturally lend itself to either or both of these types of baselines.

The download schedule for new patches is typically once a day. Should you need to initiate a one-off download outside of this schedule, a Download-Patch cmdlet is available. Executing Download-Patch -RunAsync generates a task object, which consequently can be managed with any of the PowerCLI *-Task cmdlets. For instance, running Get-Task returns details of the Download-Patch task:

Get-Task

Name                 State   % Complete Start Time   Finish Time
----                 -----   ---------- ----------   -----------
Download patch defi. Success        100 10:04:10 PM  10:04:21 PM

So far, this process wouldn’t have saved the system administrator much effort and the purpose of this book is automation, saving time, and generally making an administrator’s life easier. So it’s useful to see how these initial learning points can be extended to larger automation possibilities. Consider the scenario where a system administrator now needs to create multiple baselines, not just one. For simplicity’s sake, baselines have been detailed into a CSV file with six columns: Name, Description, TargetType, SearchPatchVendor, SearchPatchProduct, and SearchPatchStartDate. Table 14-1 and Table 14-2 list the contents of a typical baseline.

The asterisks in the SearchPatchVendor column make it easier to search for all of the possible options for a vendor that has multiple categories in VUM.

By using the standard PowerShell cmdlet Import-Csv to read the data from the CSV file, the objects created can be piped into the New-PatchBaseline cmdlet to create all of the baselines simultaneously (Listing 14-4).

Listing 14-4: Creating baselines from CSV data

Import-Csv C:ScriptsBaselines.csv | ForEach-Object '
 {New-PatchBaseline -Dynamic -TargetType $_.TargetType -Name '
 $_.Name -Description $_.Description -SearchPatchVendor '
 $_.SearchPatchVendor -SearchPatchProduct '
 $_.SearchPatchProduct -SearchPatchStartDate '
 $_.SearchPatchStartDate}

This example has only three baselines, but it would be exactly the same code for 20 or 50 baselines. In addition, it is quite likely that with multiple vCenter Servers the same baselines would need to be created in each one, so running this one-line command against each of the vCenter Servers would further extend the automation.

Before moving on to examine updating baselines, it is worth noting that in addition to the patch baselines, upgrade baselines are available. These can involve either a host being upgraded from, say, ESXi 5.1 to ESXi 5.5, or the built-in upgrade baselines for VM Tools or Hardware Version. It’s worth noting that the cmdlet Get-Baseline returns both upgrade baselines, such as those just mentioned, and any patch update baselines created already. The cmdlet Get-PatchBaseline, however, only returns patch update baselines and will not return upgrade baselines. In order to return just upgrade baselines, use the code in Listing 14-5.

Listing 14-5: Retrieving upgrade baselines

Get-Baseline -BaselineType Upgrade | 
 Format-Table Name,BaselineType

The output will be similar to this:

Name                                            BaselineType
----                                            ------------
VA Upgrade to Latest (Predefined)                    Upgrade
VMware Tools Upgrade to Match Host (Predefined)      Upgrade
VM Hardware Upgrade to Match Host (Predefined)       Upgrade

Updating a Baseline

Once you’ve created baselines, either static or dynamic, you can manipulate them and keep them up-to-date for any new requirements with the Set-PatchBaseline cmdlet.

Let’s take an example where the static baseline created earlier in the chapter for hosts contains a patch (ESXi550-201410401-BG) that causes issues in your organization. You now need to update your baseline to exclude this patch.

First, retrieve a new set of patches minus the one causing the issue. Then, update the static baseline to remove this patch from the list of patches to be deployed, by applying the updated set of patches to the baseline (Listing 14-6).

Listing 14-6: Updating patches in a baseline

$UpdatedPatches = Get-Patch -TargetType Host -Vendor VMware* '
 -Product 'embeddedESX 5.5.0' -After 01.10.2014 | 
 Where-Object {$_.IdByVendor -ne 'ESXi550-201410401-BG'}
Get-PatchBaseline -Name 'ESXi - Current (Static)' | 
 Set-PatchBaseline -IncludePatch $UpdatedPatches

The number of patches now present in this baseline is seven, one less than the previous eight:

((Get-PatchBaseline '
 -Name 'ESXi - Current (Static)').CurrentPatches).count

Other properties or search criteria used to create baselines can also be modified using the Set-PatchBaseline cmdlet.

Attaching and Detaching Baselines

You have learned how to automate the creation of baselines, but they are not much use until they are attached to a host or VM. To be able to scan a host or VM to discover what patches are required and subsequently deploy them, you must first have one or more baselines attached. You can attach a baseline directly to a host or VM or allow the baseline to be inherited from a parent object such as a cluster or datacenter.

The Attach-Baseline cmdlet is used to connect a baseline with a vCenter Server object. Although it is possible to attach a baseline directly to all hosts in a cluster, it is easier to attach the baseline at the cluster level and let the hosts inherit it. This means that any new hosts in the cluster will automatically inherit the correct baseline as well.

To attach a baseline at a cluster level, simply return the cluster object and attach the baseline to that object (Listing 14-7).

Listing 14-7: Attaching a baseline to a cluster

Get-Cluster Cluster01 | Attach-Baseline -Baseline '
 (Get-PatchBaseline 'ESXi - Current (Dynamic)')

When a baseline is no longer required, use the Detach-Baseline cmdlet (Listing 14-8).

Listing 14-8: Detaching a baseline from a cluster

Get-Cluster Cluster01 | Detach-Baseline -Baseline
 (Get-PatchBaseline 'ESXi - Current (Dynamic)')

Work with Upgrades and Patches

Now that you have patch baselines created and attached, either directly to hosts or indirectly via cluster and datacenter objects, it’s time to look at how to deploy those patches to hosts.

Scanning a Host

To determine which patches a host needs to have installed, you must first scan it against an attached baseline(s). The Scan-Inventory cmdlet can accept pipeline input from the typical Get-VMHost or Get-Cluster cmdlets or, in fact, from the Get-Inventory cmdlet.

As with the VUM GUI, you have the option to specify the type of scan to carry out: host patch, host upgrade, host VDS upgrade, VM patch (for backward compatibility), VM hardware upgrade, VM tools upgrade, and Virtual Appliance upgrade. In Listing 14-9, we scan all the hosts in Cluster01 for patch updates of previously attached baselines.

Listing 14-9: Scanning a cluster for host patches

Get-Cluster Cluster01 | Scan-Inventory -UpdateType HostPatch

The obvious first question that springs to mind after a scan completes is whether the hosts or VMs in question are compliant against the attached baselines. The Get-Compliance cmdlet can be used to retrieve this information. It returns results for any attached baseline. The example in Listing 14-10 retrieves compliance data for each of the hosts in Cluster01. Note that we use the -Detailed parameter to find out the exact number of patches required. Later in this chapter, we will use this cmdlet again to produce a more extensive compliance report.

Listing 14-10: Retrieving a cluster’s patch compliance

Get-Cluster Cluster01 | Get-Compliance -Detailed

The output would be similar to that shown next:

Entity    Baseline       Status   Compl  NotCompl Unkno  NotApp
                                  iantPa iantPatc wnPatc licable
                                  tches  hes      hes    Patches
------    --------       ------   ------ -------- ------ -------
vesxi05   Critical Host. Compl... 0      0        0      61
vesxi05   Non-Critical . Compl... 0      0        0      82
vesxi05   ESXi - Curren. Compl... 4      5        0      15
vesxi06   Critical Host. Compl... 0      0        0      61
vesxi06   Non-Critical . Compl... 0      0        0      82
vesxi06   ESXi - Curren. Compl... 4      5        0      15

Staging Patches to a Host

Once you have determined which patches a host requires, the next steps involve getting those patches down to the host and installing them. You can accomplish this using either a one- or a two-step process. The process known in VUM as Remediate places a host in Maintenance mode, copies the patches to the host, and installs them (rebooting the host as necessary)—all in one task. An alternative method first stages the patches to a host (copies the patch files onto the host) and then installs them via a Remediate task at a later time and date. This method is useful when the system administrator has a limited maintenance window to carry out all the necessary patching. By staging the patches in advance, you save time working on each host and make greater use of the maintenance window.

Use the Stage-Patch cmdlet for this task. The one-liner in Listing 14-11 copies all the patches in the ESXi - Current (Dynamic) baseline to all the hosts in Cluster01.

Listing 14-11: Staging patches to hosts in a cluster

Get-Cluster Cluster01 | Stage-Patch -Baseline '
 (Get-Baseline 'ESXi - Current (Dynamic)')

Remediating a Host

Once a host has been scanned against one or more patch baselines (and possibly had patches staged to it), it’s time to remediate that host against the required baselines. Use the Remediate-Inventory cmdlet for this task. It is possible to remediate an individual host, as well as submit a task to remediate the entire cluster, datacenter, or folder. The task first places each host in Maintenance mode, evacuating VMs in the process; copies the patches to the host; installs them; and finally reboots the host if the patches require it.

To remediate all the hosts in Cluster01 against the baseline ESXi - Current (Dynamic), execute the command presented in Listing 14-12.

Listing 14-12: Remediating all hosts in a bluster

Get-Cluster Cluster01 | Remediate-Inventory -Baseline '
 (Get-Baseline 'ESXi - Current (Dynamic)')

There are some additional advanced parameters for the Remediate-Inventory task. First, the host-specific parameters include the following:

• HostRetryDelaySeconds
• HostNumberofRetries
• HostFailureAction
• HostDisableMediaDevices
• HostPreRemediationPowerAction

These are essentially the options presented when you step through the wizard in the GUI (Figure 14-1).

There are also some advanced cluster parameters:

• ClusterDisableDistributedPowerManagement
• ClusterDisableHighAvailability
• ClusterDisableFaultTolerance
• ClusterEnableParallelRemediation

When initiating a Remediate-Inventory against a cluster object, these additional parameters allow the disabling of Distributed Power Management (DPM), High Availability (HA), or Fault Tolerance (FT), which has the potential to make for smoother patching depending on requirements in your environment. They map to the options in the wizard shown in Figure 14-2.

Including Patching as Part of Host Deployment

So far, we have only discussed patching ESXi hosts, typically in clusters, which already exist and can be updated during maintenance windows. However, how about giving consideration to deployment of new hosts and ensuring that they go into service at the same patch level as existing hosts?

Your normal method of deployment might involve constantly updating build images on DVD or USB media or other deployment scenarios, such as an ESX Deployment Appliance (EDA) or an Ultimate Deployment Appliance (UDA). Perhaps it would be better to include patching to a known baseline as part of a postbuild configuration script. That task would be a simple case of putting a few of the cmdlets you used earlier in the chapter into the configuration script.

When you use a baseline in VUM, the current patch level can be easily maintained and new hosts can be remediated against that baseline. We are then further heading to the goal of this book, which is enabling you to automate and save as much time as possible on administration tasks.

For example, add the code in Listing 14-13 to the end of a host configuration script and the host will always be deployed at the latest patch level.

Listing 14-13: Applying patch baselines in a host configuration script

$NewVMHost = Get-VMHost NewHostName
$Baseline = Get-PatchBaseline 'ESXi - Current (Dynamic)'
$NewVMHost | Attach-Baseline -Baseline $Baseline
$NewVMHost | Scan-Inventory -UpdateType HostPatch
$NewVMHost | Remediate-Inventory -Baseline $Baseline

Report the Security Status

Thus far in this chapter, we have looked at creating and updating baselines, scanning, and patching systems. Naturally, it’s useful both before and after patching cycles to find out the compliance status of the systems within the organization that you are responsible for. Knowing the security status is essential not only for planning patching work, but for providing those reports that managers are always looking to get.

Understanding Datacenter Compliance

The VUM set of cmdlets includes Get-Compliance, which allows you to report on host and VM compliance against their attached baselines. You can run this cmdlet against a top-level datacenter object and generate a report for all hosts and VMs and their compliance status against any attached baseline.

Execute the code in Listing 14-14 to generate a compliance report for all hosts and VMs in Prod01.

Listing 14-14: Generating a compliance report

Get-Compliance -Entity (Get-Datacenter 'Prod01')

Get-Compliance returns a compliance status result for each attached baseline. So if multiple baselines are attached, there will be multiple rows of data for that host or virtual machine. Sample output would be along the lines of the following output:

Entity     Baseline                               Status
------     --------                               ------
VM01       VMware Tools Upgrade to Match Host     Compliant
VM01       VM Hardware Upgrade to Match Host      NotCompliant
VM02       VMware Tools Upgrade to Match Host     Compliant
VM02       VM Hardware Upgrade to Match Host      NotCompliant
vesxi05    ESXi 5.5 - Current                     NotCompliant
vesxi06    ESXi 5.5 - Current                     Compliant

This, of course, was output to the PowerShell console. Most likely, you are required to produce a more typical report format such as CSV or XML. To do so, select the properties required for your report and use one of the standard PowerShell cmdlets, like Export-CSV, to generate the final report, as we did:

Get-Compliance -Entity (Get-Datacenter 'Prod01') |
  Select-Object Entity,Baseline,Status |
  Export-CSV ComplianceStatus.csv -NoTypeInformation -UseCulture

Notice, however, that if you select the same three properties (in this case, Entity, Baseline, and Status) with both Get-Compliance and Select-Object and then use the Export-CSV cmdlet to generate a report, the report will look like the one shown in Figure 14-3—not quite what you expected.

For a new PowerCLI / PowerShell user, this can be quite confusing. The expectation would be that, by selecting properties that you saw in the console, the required information should output to a report exactly the same. What happened is that the cmdlet developers specified, as part of the PowerCLI package, the format for the console output for each cmdlet. Every PowerShell cmdlet, or pipeline concatenation of cmdlets, is processed under the hood and, as a final step, piped to Out-Default. For instance:

Get-Compliance -Entity (Get-Datacenter 'Datacenter01')

returns exactly the same output in the console as

Get-Compliance -Entity (Get-Datacenter 'Datacenter01') |
 Out-Default

Consequently, the Out-Default cmdlet determines how to format the output of the previous cmdlet in the pipeline to the console.

To do this, Out-Default looks to see if there is a registered view for the output type; registered views define which properties to display by default and how to format them. These are defined in a PS1XML file supplied by the cmdlet developers as part of the installation of the VUM PowerCLI Snap-in. For instance, the PS1XML file for the PowerCLI VUM cmdlets is <InstallPath>vSphere PowerCLIVMware.VumAutomation.Format.ps1xml. You can examine it to see how the output to the console has been defined.

All is not lost for our report, though; we must simply work a bit harder and use what are known as calculated properties to get the desired output for the Baseline column in the CSV file. When using Select-Object, you can create your own property by using this syntax:

Select-Object @[Name='PropertyName';Expression={Scriptblock}}

(Name and Expression can be shortened to N and E, respectively). So in Listing 14-15, we created our own Baseline property using the -ExpandProperty parameter of the Select-Object cmdlet to expand the Baseline object and then pick the Name property.

Listing 14-15: Exporting a compliance report to CSV

Get-Compliance -Entity (Get-Datacenter 'Prod01') |
  Select-Object Entity,
  @{N='Baseline';E={($_.Baseline.Name}},Status |
  Export-CSV ComplianceStatus.csv -NoTypeInformation -UseCulture

Now, the CSV report (Figure 14-4) looks more like we expected!

Reporting on Specific Baseline Compliance

Up to this point, we have looked at the big picture—patching compliance at the datacenter level. Although that is useful, you will encounter requirements to create more granular reports and look at individual clusters, hosts, or VMs. Get-Compliance can accept any of these types of objects as an entity, including from the pipeline, so it’s very simple to find the required information. You can also use the -Baseline parameter to narrow the search further and report on specific baselines.

Examining the compliance status of all hosts in Cluster01 for the patch baseline ESXi - Current is a straightforward task. Retrieve the cluster with the Get-Cluster and pipe the results into Get-Compliance with a specified baseline (Listing 14-16).

Listing 14-16: Generating a host compliance report for a cluster

Get-Cluster 'Cluster01' | Get-Compliance -Baseline '
 (Get-PatchBaseline 'ESXi - Current (Dynamic)')

Typical output would be similar to this:

Entity     Baseline                    Status
------     --------                    ------
esx01      ESXi - Current (Dynamic)    Compliant
esx02      ESXi - Current (Dynamic)    NotCompliant
esx03      ESXi - Current (Dynamic)    Compliant
esx04      ESXi - Current (Dynamic)    Compliant
esx05      ESXi - Current (Dynamic)    NotCompliant
esx06      ESXi - Current (Dynamic)    Compliant

The same principle can be applied to VMs. Let’s examine the compliance status of all the VMs in Cluster01 for the baseline VMware Tools Upgrade to Match Host (Predefined) (Listing 14-17).

Listing 14-17: Generating a VM compliance report for a cluster

Get-Cluster 'Cluster01' | Get-Compliance -Baseline '
 (Get-Baseline 'VMware Tools Upgrade to Match Host (Predefined)')

Typical output would be similar to this:

Entity     Baseline                                Status
------     --------                                ------
VM01       VMware Tools Upgrade to Match Host…     Compliant
VM02       VMware Tools Upgrade to Match Host…     Compliant
VM03       VMware Tools Upgrade to Match Host…     NotCompliant

Both of these one-line commands will return basic compliance status: Compliant, NotCompliant, Unknown, or Incompatible. Again, this information is useful for a high-level view. But what if more detail is required? Fortunately, the PowerCLI developers have given the Get-Compliance cmdlet the -Detailed parameter. Let’s look at these same two examples again, but this time with the addition of the -Detailed parameter. We’ll start with the compliance check of hosts in Cluster01 in Listing 14-18. This time, the number of required patches is displayed.

Listing 14-18: Generating a detailed host compliance report for a cluster

Get-Cluster 'Cluster01' | Get-Compliance -Baseline '
 (Get-PatchBaseline 'ESXi - Current (Dynamic)') -Detailed

Typical output would be similar to this:

Entity Baseline         Status   Compli NotCom  Unknow  NotAppli
                                 antPat pliant  nPaches cablePat
                                 ches   Patches         ches
------ --------         ------   ------ ------  ------- --------
esx01  ESXi - Curren... Compl... 4      0       0       0
esx02  ESXi - Curren... NotCo... 0      4       0       0
esx03  ESXi - Curren... Compl... 4      0       0       0
esx04  ESXi - Curren... Compl... 4      0       0       0
esx05  ESXi - Curren... NotCo... 0      4       0       0
esx06  ESXi - Curren... Compl... 4      0       0       0

Let’s do a similar check for the VMs in Cluster01. This time the VMToolsStatus is displayed as well (Listing 14-19).

Listing 14-19: Generating a detailed VM compliance report for a cluster

Get-Cluster 'Cluster01' | Get-Compliance -Baseline '
 (Get-Baseline 'VMware Tools Upgrade to Match '
  Host (Predefined)') -Detailed

Typical output would be similar to this:

Entity   Baseline               Status         VMToolsStatus
------   --------               ------         -------------
VM01     VMware Tools Upgrade   Compliant      GuestTools
         to Match Host (Prede…                 Current
VM02     VMware Tools Upgrade   Compliant      GuestTools
         to Match Host (Prede…                 Current
VM03     VMware Tools Upgrade   NotCompliant   GuestTools
         to Match Host (Prede…                 NeedUpgrade

Reporting on Required Patches

When planning maintenance windows and the work to be carried out, teams are often required to provide detailed information about the patches they are planning to install in advance. Although the VUM GUI can provide detailed information about the patches, there is no way to export the data into a common report type. Of course, you can use the VUM PowerCLI cmdlets to help you get this information; the Get-Compliance cmdlet is especially useful.

Let’s take an example where you need to prepare a list of patches to apply to ESXi 5.5 servers during the next patching window. Via the vSphere Update Manager Client, you can access information, but there is no way to extract it for a distributable report.

To retrieve this same information using the Get-Compliance cmdlet, retrieve compliance data from a host that has had the baseline in question attached and scanned against. In particular, look at the NotCompliantPatches. Then, select the properties you wish to export for the report, including a calculated property named Version, and export the results to a CSV file (Listing 14-20).

Listing 14-20: Generating a detailed noncompliant patch report for a host

(Get-Compliance -Entity esx01 -Detailed).NotCompliantPatches |
 Select-Object Name,IDByVendor,Description,@{N='Version';
  E={$_.Product.Version}},ReleaseDate |
 Export-Csv patches.csv -NoTypeInformation -UseCulture

The information produced in our result is displayed in Figure 14-5.

Applying Patches Without vSphere Update Manager

So far in this chapter, we have covered automating patch deployment via vSphere Update Manager. However, for a number of reasons vSphere Update Manager might not be available. If that is the case, then there are two methods that you can use. For patches in ZIP format, you can use the PowerCLI cmdlet Install-VMHostPatch. For VIB files, you can use PowerCLI’s implementation of the ESXi command-line tool, esxcli.

ZIP Files

Many VMware patches are distributed in ZIP format, which is supported by the PowerCLI Core cmdlet Install-VMHostPatch. There are a few different ways to make the patch file accessible to the ESXi host to be updated. If the patch needs to be deployed to more than one host, then it makes good sense to first copy that patch to a shared datastore that is available to all the hosts requiring the patch. Listing 14-21 demonstrates how to copy a folder containing patch files for vSphere 5.5 U2 to a shared datastore.

Listing 14-21: Copying a patch file to a shared datastore

$Datastore = Get-Datastore "NFS10"
New-PSDrive -Location $Datastore -Name ds -PSProvider '
 VimDatastore -Root ""
New-Item -ItemType Directory '
 ds:Patchesupdate-from-esxi5.5-5.5_update02
Copy-DatastoreItem -Item '
 C:Scriptsupdate-from-esxi5.5-5.5_update02* -Recurse '
 -Destination ds:Patchesupdate-from-esxi5.5-5.5_update02

Now that the patch files are available to ESXi hosts via a shared datastore, you can run the commands in Listing 14-22 to install the patch. Note that Install-VMHostPatch requires the full path to the metadata.zip file in the folder containing the patch files.

Listing 14-22: Installing a patch with Install-VMHostPatch

$Datastore = Get-Datastore "NFS10"
$FilePath = 'Patches/update-from-esxi5.5-5.5_update02/metadata.zip'
$DataStoreURL = $Datastore.ExtensionData.Info.Url -Replace 'ds://'
$FullPath = $DatastoreURL + $FilePath
$VMHost = Get-VMHost vesxi10.sunnydale.local
$VMHost | Set-VMHost -State Maintenance -Confirm:$false
$VMHost | Install-VMHostPatch -HostPath $FullPath
$VMHost | Restart-VMHost -Confirm:$false

VIB Files

Patches and plug-ins from VMware and other third-party vendors may be distributed in VIB format. Typically, the documentation for installing VIB files supplied by VMware or the third party will involve using the ESXi command-line tool esxcli. You can use the PowerCLI cmdlet Get-EsxCli to access the same functionality.

Again, the VIB file should first be made accessible to each ESXi host that needs it via a shared datastore. Use the code in Listing 14-21 to make the VIB available. Listing 14-23 then demonstrates how to use Get-EsxCli to install an example third-party Broadcom tg3 async driver, available from the VMware Download website, which has been uploaded to a shared datastore.

Listing 14-23: Installing Broadcom driver with Get-EsxCli

$Datastore = Get-Datastore "NFS10"
$FilePath = 'Patches/Broadcom/async/'
 net-tg3-3.133d.v55.1-1OEM.550.0.0.1198611.x86_64.vib'
$DataStoreURL = $Datastore.ExtensionData.Info.Url '
 -Replace 'ds://'
$FullPath = $DatastoreURL + $FilePath
$VMHost = Get-VMHost vesxi10.sunnydale.local
$VMHost | Set-VMHost -State Maintenance -Confirm:$false
$EsxCli = $VMHost | Get-EsxCli
$EsxCli.software.vib.update($null,$false,$false,$false,$false,'
 $true,$null,$null,$FullPath)
$VMHost | Restart-VMHost -Confirm:$false