Just got a call from a systems administrator who applied Microsoft Patch 2744842 on his vCenter Server 4.1.0 U3 / Windows 2008R2 and ran into some issues after that. You might want to think twice before applying this new Microsoft Patch without proper testing. As you know this MS patch fixed some issues with Internet Explorer. After asking around on twitter if anyone else has had these issues, I got confirmation of only one more incident.
In one case the symptoms were that SOME hosts still show connected in vCenter, but when clicking the hosts tab at the cluster level, they don’t report any cpu or memory load and neither is the uptime reported. It was also noticed that DRS kept moving VMs between hosts who did report correct cpu and memory load.
Unfortunately I am not able to do some tests right now to confirm this issue, so if you have run into this issue or if you have NOT run into this, please let me know in the comments.
2744842 has caused issue with IE access to Tridium Niagara based systems. (java system integration software). Thanks for posting. Trying to track down possible fix.
Not seen this on vcenter 5 build 455964 with that IE patch applied..
Looks like a deinstall of the MS patch will not fix the vcenter problem.
vCenter 5.1 build 786111 seems unaffected. But then again, 1 host isnt really a real scenario. The environment we’ve seen runs on 4.1.0 build 491557 with Windows 2008 SP2. About a third of the hosts failed to communicate details to the vCenter server and seemed empty. The uptime of 0s gave away that something was wrong. As well as DRS trying to move VM’s much more frequent than we used to. Also Performance information on the affected hosts was missing since last night 23:00. At the same time the dreaded IE patch was installed on the vCenter server. Uninstalling the update immediately resolved the problem, the server wasnt even rebooted yet to make the necessary changes to the OS.
5.0.0 (455964) on 2008R2 SP1 seems unaffected, but thanks for the heads up, we made a snapshot prior to the update, just in case.
I opened an SR with VMware to find out if they had seen any instances of this. The one they had seen involved the SQL Reporting Services service and the SQL Server service being reset to Automatic startup by the patch. Apparently after the reboot the SQL Reporting Services service began using ports 80 and 443, causing the problem.
Hope that helps