Corrupted vCenter Management Webservices monitor

Sometimes after renaming your vCenter server or performing an upgrade of vCenter the vCenter Management Webservices monitoring can get correpted. The most visible symptoms of this problem is within the vCenter Service Status of the Administration section of the VI client:

vCenter Management Webservices shows an Alert with a message of

“Unable to retrieve health data from https://servername.mydomain.local:8443/vws/Query/Health“

This error can be corrected with the following procedure:

1. On the vCenter server go to Start -> All programs -> ADAM -> ADAM ADSI Edit
2. Right click on the ADAM ADSI edit and select connect to
3. Ensure the following is selected under connection settings:

   Connection name: VC
   Server name: localhost
   port: 389
   Distinguished name is selected and name is dc=virtualcenter, dc=vmware, dc=int
   Click OK to connect

4. You need to delete :CN=<VCGUID>,OU=ComponentSpecs, OU=Health, dc=virtualcenter,dc=vmware,dc=int
5. After deleting this container you will need to restart the vCenter service and the webaccess.

A new container will be created and the error mentioned above will be corrected.

You will also notice that the storage management service monitor does not show up anymore. Don’t worry. After a couple of minutes the monitor will return.

vSphere Upgrade and Microsoft ISA Server

I am currently upgrading a customer environment to vSphere 4. All hosts are already running on ESXi 4 and I am in the process of upgrading the VMware tools on all virtual machines. Yesterday I run into a problem with a Microsoft ISA Server virtual machine after upgrading the VMware Tools to vSphere level.

The Windows eventlog reported the following events:

- Timeout (30000 milliseconds) waiting for the MSSQL$MSFW service to connect.

- The Microsoft Firewall service depends on the MSSQL$MSFW service which failed to start because of the following error: The service did not respond to the start or control request in a timely fashion.

For some reason the SQL server instance would not start without reporting any additional error information.

Lucky enough, I found this recent blog article. Apparently the VMware Tools 3.5 and older tools use the msvcp71.dll, and VMware Tools 4.0 does not. When upgrading the VMWare 3.5 tools, the VMware 3.5 tools are uninstalled along with msvcp71.dll from both the VMWare Tools directory and the Windows System32 directory.

SQL server relies on msvcp71.dll and won’t start because the dll has gone. Restoring the msvcp71.dll to the system32 fixed the problem!

In this case Microsoft ISA server was affected, but any program relying on msvcp71.dll could be affected.