VMware Update Manager (commonly abbreviated to VUM) is currently the companies primary method updating both VMware ESX hosts, and all so “upgrading” the VMs “virtual hardware” and small software package installed to the guest operating system called “VMware Tools”. As new versions of VMware ESX are released, the version of the VM evolves accordingly. This referred to as virtual machine “compatibility” levels. VUM can be used to update VMware ESX from one sub-release to another, and it can also be used to whole sale upgrades from one release to another as well.

VUM may not be appropriate for all methods of deploying VMware ESX. If the organization for instance has opted for stateless “Auto Deploy” model then VUM would not be applicable. Auto Deploy boots the ESX host across the network using a “image” and profile. In this model if a new version of ESX is release the image is merely replaced, and the host placed in maintenance mode, and rebooted. The first boot cause the new image to be loaded across the network and made resident in memory. VUM usage is more relevant to an scenario where ESX has been “installed” to disk. With this said, some organizations scripted installation are so sophisticated – they find it as easy to merely re-install the host when need additions are released. Alternatively, occasionally organizations opt for a twin-track approach using VUM for patching the ESX host within a sub-release, but opting to redeploy when new major release is shipped.

Like vCenter, VUM requires backend database – and allocation of disk space for storing the download of patches and updates. In our case we opted to install VUM to the same Windows instance that vCenter executes on – and separate D: drive has been created to hold the downloads. VUM does require access to the internet for downloading updates, but in highly secure environments it is possible to have the VUM service “offline”, and move these patches from separate internet connected system.

Unlike vCenter, VUM is 32-bit application – and as such requires 32-bit DSN to communicate to the VUM database.

When VUM is installed it will ask for location for downloading and saving patches. The location selected should have at least 120GB or greater otherwise you will receive a warning during the installation.

Screen Shot 2013-11-06 at 20.38.19.png

 

Creating a 32-bit DSN

1. Login as the VUM Service Account. In this example it is called “vumdbuser-nj”. Ensure this account has local administrator rights to complete the installation

2. Open the 32-bit ODBC Manager located at C:\Windows\SysWOW64 and is called odbcad32.exe

3. Select the System DSN tab and Click Add

4. From the long list select SQL Server Native Driver

5. In the Create a New Data Source to SQL Server, type a friendly name for the DSN Connection, and the name of the SQL Server

Screen Shot 2013-11-06 at 18.19.03.png

6. Select “with Integrated Windows Authentication

Screen Shot 2013-11-06 at 18.20.32.png

7. Ensure the default database is the VUM Database in SQL Server

Screen Shot 2013-11-06 at 18.21.42.png

Installing VMware Update Manager

1. Open the main autorun.exe to view the VMware vCenter Installer

2. Under the VMware vCenter Support Tools, select vSphere Update Manager and Click the Install button

Screen Shot 2013-11-06 at 18.25.36.png

3. In this simple install we will have a single repository, rather than multiple VUM Server sharing a repository

Screen Shot 2013-11-06 at 18.48.07.png

4. Next we need to register the VUM server with vCenter, as well specifying an administrative account to complete the registration. This dialog box defaults to the IP address of the vCenter (when same Windows instance is being used). Many administrators prefer to use a FQDN instead.

Screen Shot 2013-11-06 at 18.53.57.png

5. Select the option to Use a supported database, and from the pull-down list select the DSN Connection earlier

Screen Shot 2013-11-06 at 20.33.46.png

6. Click Next to the Authentication Settings.

Screen Shot 2013-11-06 at 20.33.58.png

7. Set the connection information. This dialog box defaults to an IP address. Many administrator prefer to use the FQDN in case they need to change the IP address at later stage.

Screen Shot 2013-11-06 at 20.37.28.png

8. Adjust the paths to the location for the software, and the patches…

Screen Shot 2013-11-06 at 20.38.42.png

Note: One aspect of the VUM installation that some people have observed is the inability of the installer to set the “service account” used by VUM when using Windows Authentication for SQL. This can result in the service starting, but not being able to access the database correctly. To fix this issue one merely needs to change the “Service Account” back the VUM Service to be the user account used to carry out the installation and access the database. The service account can be modified using the Services MMC, and locating the “VMware vSphere Update Manager Service” in the list. Next browse for the account in Active Directory, and supply the password – click yes to the message the grant the account the right to logon as service.

Screen Shot 2013-11-25 at 10.48.43.png

Installing VMware Update Manager Plug-in

VUM has not been integrated to the vSphere Web Client, instead it is managed by the now legacy vSphere Client. A plug-in needs to be installed to extend the functionality of the vSphere Client to allows its management.

1. Open the vSphere Client, and log into the vCenter

2. From Plug-ins menu, select Manage Plug-ins

3. This should show the plug-in manager, that will show the VMware vSphere Update Manager, and blue link to download and install the plug-in.

Screen Shot 2013-11-06 at 21.09.48.png

4. At the end of the install, the plug-in will attempt to connect to the VUM server, accept the default certificate that is presented.

Screen Shot 2013-11-06 at 21.16.51.png

Note: This should add an Update Manager icon to the “Solutions and Application” portion of the vSphere Client:

Screen Shot 2013-11-06 at 22.08.17.png