My ramblings about all things technical


Deploying an Isolated Update Manager Download Service Architecture

During a recent customer engagement for a Virtual Infrastructure build out I was tasked with deploying an Isolated/Air Gap Update Manager Download Service architecture. If you do not know what an isolated Update Manager Download Service is then read this article first before carrying on. I came across a few hurdles during this deployment and so i waned to create a quick reference of what I followed for my future reference and to hopefully help anyone who gets the problems I was getting during the setup

  1. For this setup, I got a service account created that would be used for the installation of VUM and the UMDS.
  2. For my setup I setup VUM and UMDs on their own dedicated servers as you obviously have to do as the UMDS has to be in the DMZ.
  3. For the installation of UMDS I followed the following steps from the vSphere 5 Documentation Center.
  4. Next I installed VUM following the steps detailed from this vSphere 5 Documentation Center article.
    1. Note: The first hurdle I hit in this installation was that the SQL Client for SQL 2012 doesn’t work for the ODBC connections so I had to install the SQL 2008 Client from here for it to show the ODBC configuration when I went through each of the installations.
  5. Next was the configuration of UMDS and I followed this vSphere 5 Documentation Center article.
  6. Next was the creation of the IIS server for the UMDS so that VUM can contact and download the patches. I followed this vSphere 5 Documentation Center article.
  7. Next was the exporting of the downloaded patches to the UMDS folder under the IIS website (for mine I did a virtual directory to a folder on my data drive so that the c drive was not filled up with patches.)
    1. Note: For the exporting, I kept getting an error as detailed in this VMware Communities discussion I created. As detailed in the discussion the problem was I had to set the folder location as my default export store by running vmware-umds -S –default-export-store <your path to the UMDS folder>.
    2. Then you can export the patches to the folder location by running: vmware-umds –E <your path to the UMDS folder>.
  8. Now you can go into your vCenter and setup the UMDS as your shared repository location by pointing to the IIS website you created for the UMDS folder


    1. Note: For the downloading of the patches I kept getting a failure where the downloading patches task would get stuck at 50% for a few minutes and then fail stating “Cannot download patch definitions” as shown below.


2. The problem here was that the service account running the VUM service on the VUM server did not have full permissions to the folder. After reapplying the patches the downloading of the patches worked clip_image003

After going through all of the above steps, my air gap Update Manager Download Service was now setup clip_image004[1]

I hope that this saves someone the headaches I had along the way



Upgrading ESX,VMware Update Manager and Virtual Centre 4.0 to Version 4.1

Recently we decided we needed to take the plunge and start the upgrade process of our Virtual Centre,ESX hosts and Update Manager to Version 4.1. The upgrades were fairly straight forward due partly to us having to rebuild our Virtual Centre Server recently and therefore had already completed the pre-requisite of the virtual centre OS being x64 and the ODBC requirements.

The point of this posting is to summarise all the resources i used to prepare and make sure that the upgrades would run as smoothly as they did to my relief.

  • The VMware ESX 4.1 Release Notes were the first resources I used to fully understand all the new features of version 4.1 and to make sure all of our equipment met the Hardware, Software, and Guest Operating System Compatibility Lists
  • Next I went through the Upgrading to ESX 4.1 and vCentre Server 4.1 best practices to make sure I was obviously following the best practices for the upgrade 🙂 This was a really great resource for the upgrade and covered all the things I needed to tick off in my preparations.
  • The other resource that was amazing for reference and preparations was the vSphere Upgrade Guide for ESX and vCentre to version 4.1. It covers everything needed and i had it printed out beside me during the upgrades just in case.
  • This next resource was brilliant as it had a great table to make sure everything I needed to have done was done and the video in it showing how to do the upgrades via VMware Update Manager(the way I did my hosts)

Even though everything did go to plan I also looked around and read different blogs by people who had done the upgrades already and any snags they may have hit in the process. The best three that covered everything was

  1. Mike Laverick’s blog posting Upgrading to vSphere 4.1
  2. Duncan Epping’s small but so important posting all about the ODBC problems due to the VMware Update manager and vCentre needing to be installed on a x64 OS.
  3. Jeremy Waldrop’s VMware vCenter 4.1 Upgrade/Migration Gotchas

Well that’s everything I followed for my upgrade. Thankfully mine was really straight forward but with all the above resources I knew that I had covered everything i could to make sure I didn’t hit any problems during the upgrades.

Good luck with your upgrades 🙂


*WARNING* There is currently a known issue where the transaction logs for your SQL instance expand as detailed here :

There is also a known error with the Data Migration Tool to upgrade from vCenter Server 4.0 to vCenter Server 4.1 fails as detailed here:

Jonathan Medd has done a posting all about a problem he experienced after upgrading his vCentre database and Server to version 4.1. The vCentre service wouldn’t start and has detailed brilliantly how he fixed the problem here :


Host cannot download files from VMware vCenter Update Manager patch store. Check the network connectivity and firewall setup, and check esxupdate logs for details.


This error has been haunting me for quite some time now. When I tried to setup and get VMware update manager working late last year I came across the above problem. I did some fixes but none seemed to work and due to there being a very large amount of work happening I put it on the back burner. Now if you have read my blog posting about the distributed virtual switches you would have seen the need to keep your servers up to date on the latest patches as well as the obvious reasons of security and bug fixes.

So early March this year I decided I was going to get VMware Update Manager working so I didn’t have to use esxupdate to patch my vm’s. My previous problem I believed were down to me using an older version of VUM and possibly because I had it installed on a highly utilised Virtual Centre Server I decided to build a dedicated server for VUM and do it all to the exact specifications VMware tell you to and install the latest version.

Seeing as I have spent some time trying to get this problem fixed I have found some brilliant blog postings and tips for fixing this problem as well as others that stem from this error.

  • Jason Nash’s (@nash_j) blog posting was probably my first port of call when I tried to fix the problems I was having last year and I still checked the DNS settings this time to make sure everything was as it should be.
  • The next one was from a VMware communities posting someone had put up with problems sounding very close to the problem I was having. One of the replies recommended checking that the update manager port is open on the esx hosts firewall which is a very important part to check as by default this isn’t open and so can cause you problems with Update manager.
  • Next is the one I kept coming across and is the one I felt was causing my problems when I installed it previously. This is the problem where the port information in the vci-integrity.xml file is incorrect. For me this wasn’t the problem as it has now been fixed in Update Manager 4.0 Update 1 but if you are using the previous versions of update manager this is more than likely your problem and the steps should fix your problem. Personally I installed Update Manager 4.0 update 1 Patch 1 to make sure all the bugs I could possibly avoid I would.

There are also so many great resources of how to setup and manage VUM I decided it would be helpful  to list the links I used to to set it all up  as VMware have done some brilliant videos detailing the processes.

  • First set of steps I used was the video demo by VMware of  how to install vCenter Update Manager 4 Update1. (Warning these are videos that need to be downloaded and you will need Adobe Flash player to view them). I would also recommend using the VUM sizing estimator to make sure you allocate the correct amount of space for the database and patches repository. The first bit I had to/chose to do differently was inserting the ip address of the Update Manager server in the server name filed in the installation to make sure that if there are any problems with DNS the server is obviously still accessible. The next bit was for the creation of the ODBC DSN when creating the SQL server instance for the update manager database. Due to me installing it on a x64 machine I had to create the ODBC via the odbcad32.exe application as in the ESX and vCenter Server Installation Guide  , on page 72 it is tells you this which I noticed when installing my Virtual Centre server on a x64 server and this “fix” also applies to the database setup for Update Manager even though it doesn’t seem to be included in the latest documentation :

Even though vCenter Server is supported on 64-bit operating systems, the vCenter Server system must have a 32-bit DSN. This requirement applies to all supported databases. By default, any DSN created on a 64-bit system is 64 bit.

Thankfully now it’s all working correctly and I can finally use Update Manager.

Gregg Robertson