I have the VUM (vCenter Update Manager) Server installed on a seperate machine (vm of course) than my vCenter Server.
Now this of course is the most natural and logical way to patch your ESX servers, all you need to do it create your baselines, remediate your servers and hey presto, after a reboot you are fully patched. so this was working for a while on a test machine using an MSDE database. Now since this has become a essential part of the infrastructure it was time to move off of the MSDE and the test server.
So the plan was pretty simple:
Seems simple enough - don't you think? (but.... if life was simple we would not have job security!!!)
Now all should be fine and dandy. So I start up my VIC again and lo and behold - It does not work!
I was getting "the request failed because the server name could not be resolved". Hmm. DNS resolving works forward and reverse so what was the problem?
Like any good troubleshooter - reinstall the plugin was the next step. So 2 minutes later, I wanted to add in the plugin back in and I was presented with a new error message "The remote name could not be resolved: 'oldhostame.xx.xx.xx'". which led me to start thinking that vCenter did not update the name change of my VUM server.
I had to dig into the SQL database and find where the settings of the old hostname were still hiding. so to save you the digging, the entries were located in two locations:
I changed the entries to reflect the name change. Restarted the Virtual Center Service and the Update Manager service on the other server - and VOILA!
Hope you enjoyed the ride!
Now this of course is the most natural and logical way to patch your ESX servers, all you need to do it create your baselines, remediate your servers and hey presto, after a reboot you are fully patched. so this was working for a while on a test machine using an MSDE database. Now since this has become a essential part of the infrastructure it was time to move off of the MSDE and the test server.
So the plan was pretty simple:
- Rename the server to reflect the production task it was performing
- Move the database to production SQL 2005 server
Seems simple enough - don't you think? (but.... if life was simple we would not have job security!!!)
- Worked very easily, I mean renaming a windows server is something I can do with my eyes closed, my hands tied behind my back and with 4 big football players holding me back.
- Also pretty straight forward.
- Stop the Update Manager Service.
- Detach the Database from the MSDE instance - copy it to its new home.
- Attach the Database.
- Work some magic with credentials and security.
- Change the ODBC to point to the new server.
- And last but not least - start the service.
Now all should be fine and dandy. So I start up my VIC again and lo and behold - It does not work!
I was getting "the request failed because the server name could not be resolved". Hmm. DNS resolving works forward and reverse so what was the problem?
Like any good troubleshooter - reinstall the plugin was the next step. So 2 minutes later, I wanted to add in the plugin back in and I was presented with a new error message "The remote name could not be resolved: 'oldhostame.xx.xx.xx'". which led me to start thinking that vCenter did not update the name change of my VUM server.
I had to dig into the SQL database and find where the settings of the old hostname were still hiding. so to save you the digging, the entries were located in two locations:
[dbo].[VPX_EXT_CLIENT].[URL]
[dbo].[VPX_EXT_SERVER].[URL]I changed the entries to reflect the name change. Restarted the Virtual Center Service and the Update Manager service on the other server - and VOILA!
Hope you enjoyed the ride!