Part III – Update Manager Patching Guide

This post is the third in a series dedicated to helping you set up your update infrastructure in vSphere 4.1. Part I is about installing and configuring Update Manager. Part II shows you how to install and configure the Update Manager Download Service. As the last in this series, this post will explain how to patch your ESX/ESXi hosts.

Download latest patches to UMDS server

From the UMDS server, open a command prompt. Change directories to the UMDS installation path. For example, cd “d:\Program Files (x86)\VMware\Infrastructure\Update Manager”, then type d: to change your working directory to the D: drive. Your output should look similar to that shown below.

In many cases, the UMDS program accepts the long and short versions of command-line switches. To start downloading patches, type vmware-umds.exe -D

or vmware-umds.exe –download

and press enter. The first download of patches will take a very long time. Successive downloads will be quicker. The UMDS export function and 7-zipping the patches and updates will take the same amount of time because there’s no way to separate new updates from previously downloaded updates.

Export patches from download location

After the patches have been downloaded, run the UMDS export command. Be sure you’re still in the UMDS installation directory. This command will export all downloaded patches and updates along with their metadata to the directory specified during the initial UMDS configuration. As with many UMDS program options, you can specify two switches, one short and one long. Both do the same thing. Run the command vmware-umds.exe –E

or vmware-umds.exe –export

7-zip patches and updates for transfer to VUM server

When you’ve completed downloading and exporting, you can zip up the patches and updates into DVD sized chunks for easy transfer to your air-gapped networks. You’ll need to install 7-zip or run the portable version.

When you run 7-zip, navigate to your UMDS download location. Select all the files in your download directory and click the Add button in the upper left hand corner. A second window opens. Click the “…” browse button in the upper right hand corner and select the directory you wish 7-zip to export your files to. In my case, I chose something easy like D:\. It automatically chooses the directory’s name as the name of your zipped file, which is fine for our purposes. The only other change you should make is to select the Split to volumes, bytes option to DVD. This will make it easy to burn the least amount of DVDs required for transferring. When your satisfied, click OK.

Give it a while to work. Now would be a good time to go get some coffee. When it’s done, you can transfer the 7-zipped files to the VUM server.

Transfer patches and updates to VUM server

From the UMDS server, you should have broken the updates into CD/DVD sized chunks with 7-zip. Go ahead and burn the DVDs you need and start transferring them to the VUM server. You can copy the 7-zip files directly into the VUMrepo directory and unzip them there, as well. Just delete the 7-zip files when you’re satisfied that everything unpacked ok. A special note with 7-zip is that if all the 7-zipped files are in the same directory, when you extract the first file the others will be unpacked, too.

You may need to cut and paste the packed files into the root of the VUMrepo directory. When you’re finished, your VUMrepo directory should look something like this.

When you do, you can go back to the Update Manager configuration tab and click Validate URL. If you have configured VUM to use a shared repository and have the VUMrepo directory listed correctly, you should get a view similar to below showing you’re connected to the repository.

Don’t make the same mistake I did!

The following mistake I made cost me two days of troubleshooting and a co-worker. The problem I had was that after making the following changes, my shared repository would show a green check mark and say Connected but would not download patch metadata when I clicked Download Now. The Patch Repository would still be empty but show a Download Completed status. While trying to optimize my air-gap networks, I made the following configuration changes.

On the Configuration tab of the Update Manager plug-in, I disabled the Patch Download Schedule because I did not want Update Manager to automatically look for updates. My reasoning was that when it came time to patch ESXi hosts, an administrator would manually copy the updates to the VUM server and manually press the Download button. This is perhaps a once a month occurrence and someone has to do it manually anyways, so, why do we need a schedule? Leave the Patch Download Schedule enabled! You can change the frequency to Once and Now, if you like, but leave it enabled.

The second mistake I made was to also disable the Notification Check Schedule. Do not disable it! Again, my reasoning was because it’s an air-gap network and patching is a manual process. There’s no need for Update Manager to notify an administrator about anything automatically. An admin will manually download patches, transfer them, scan and remediate hosts. There’s no need for automation in these air-gap networks.

Feel free to change the Virtual Machine Settings, ESX host/Cluster Settings, and vApp settings. Changing these did not affect Update Manager operations in my environment. When the above settings are correct, you should see the following listed in the vCenter Scheduled Tasks.

For your reference, I set these to Run Once and Now so that they didn’t run on their own. You’ll want to ensure your Patch Download Settings are correct and you can connect to your Update Manager repository before you run these, though.

Set Patch Download Settings

Before we run these scheduled tasks, ensure you show Connected to your shared repository. If you show Connected and your scheduled tasks show up, you don’t even need to press the Download Now button. Go back to your Scheduled Tasks and run them.

Run the Notification task first, then the Download task. The download task runs for a few seconds. You should be able to view your Patch Repository and see all your patches and updats.

That, my friends, is a beautiful sight after battling something so simple for so long.

Attach a baseline, if not already completed

In the upper right hand corner of the Update Manager plug-in, click on Compliance View.

Update Manager in this particular environment is only being used to patch and update ESXi hosts. We’re not patching or updating guest operating systems. We’ll leave that to WSUS and SCCM. In order to scan hosts appropriately, we’ll ensure a baseline is attached to the hosts at the cluster level so Update Manager has something against which to scan. If you’re doing this for the first time, from the Compliance View, select the Cluster object from the left hand pane. In the upper right hand corner, select Attach…

Check the boxes next to Critical Host Patches and Non-Critical Host Patches and click Attach. Now Update Manager has a baseline with which to scan hosts.

Scan the cluster

Again, from the upper right hand corner, select Scan…, ensure both Patches and Extensions and Upgrades are checked and click Scan. You should see a task running below.

When it completes, you should see the results in the pie chart area showing which hosts are in what state.

Stage the patches, if you wish, and remediate

Feel free to stage the patches. Staging will have the hosts download the patches from the VUM repository. They will not install any patches or updates, but simply download them and wait to be told to install them. If you skip the staging process, the hosts will obviously download the patches when told to remediate.

The remediation process will vMotion VMs off the hosts automatically as Update Manager patches one host at a time because we have DRS enabled on our cluster. DRS will abide by any VM/VM and VM/Host affinity or anti-affinity rules you have set. Just be sure to stick around during the remediation process and monitor your environment carefully.

You can remediate by using the upper left or lower right corners and the appropriate Remediate buttons. Update Manager will automatically restart the hosts if they need it. After remediation, DRS will try to apply any rules, once again, and move back VMs if it needs to. Just be patient for the DRS algorithm to run. It may take five minutes, or so, but it will work. Feel free to check out the DRS tab of the cluster for any faults.

Google