I have exactly the same problem. did you find an answer?
Can you try removing VUM agter deleting the DSN manually?
Tried that, didn't work. I ended up reverting the VC server, which is virtual, back to a snapshot then reinstalling. The databases are on a separate server so it had no effect on tthe VM's.
Is it possible that the DSN is also in use by something else?
Also, bear in mind that 32bit and 64 bit DSNs need to be viewed in different locations.
No, the DSN is not in use by anything else. I get your point about the 32 and 64 bit DSNs, Update Manager requires a 32 bit DSN, I had not checked that before I reverted to snapshot. I know it had been working perfectly before I tried to upgrade multiple VMS using RVTools, which killed my VC server service. When I restarted the service, Update Manager wouldn't work.
We had the same problem.
Basically it's trying to remove a DSN that doesn't exist. Give it what it wants -
Open up the 32bit ODBC administrator.
Create a new System DSN and called it 'VMWare Update Manager' and set it as MS Access. When the properties appear for the Access database, click 'Create' and make a new database (give it any name, the details are irrelevant as it's the DSN that matters).
Once you have done this, try the uninstall again. It should work.
Just had this issue while trying to remote VUM 5.5 from a Windows server (not needed anymore after migrating environment to 6.7)
Solved after using the original vSphere 5.5 installer to re-run VUM installation, which actually triggered the removal process successfully