Prior to upgrading vCenter to 5.0, I always used my personal domain-admin username to log into the VI Client. Now, it times out with "The vSphere Client could not connect to the server <server>. The server <server> took too long to respond." I can log in using Administrator, so it's not a connectivity issue. Also, I can log into the server interactively using my username, so it's not a password issue.
My username is present under the Roles as an administrator.
Anyone else see this?
TIA,
Mark
log into vCenter with an account that is not timing out and see if you can change the AD timeout value. Administration-vCenter Server Settings-Active Directory. Maybe change it to 120 seconds.
I changed the timeout to 120, but the error pops up within about 30 seconds, so that doesn't seem to be the issue.
can you replicate this issue while trying to connect from a different end point device?
Yes, when I RDP into the vCenter server under my username and check "Use Windows Session Credentials", or if I enter them I get the same error.
I just tried setting the "Normal Operations" timeout to 120 (Administration-vCenter Server Settings-Timeout Settings). Now it just takes longer to get the error popup.
I'm not sure exactly what is going on. Is the vCenter Server busy doing anything? Have you tried restarting the vCenter Server Service. If you can connect to the vCenter Server using other accounts, i'm not quite sure why the behavior is different using your AD account.
I've restarted the service and rebooted both the domain controller and vCenter server several times. At one point I was able to log in with my ID, (I haven't tried any others at this point) but later I couldn't. In the AD settings I changed the "Validation Period" from 24 hours to 4 hours, we'll see later if that makes any difference.
Well, I found it. I was logging in on the DC, which worked just like expected. When I tried to log in on the vCenter server, it sat at "Applying User Settings" for quite a while. So I started diagnosing that, and one route pointed to DNS. Turns out there was an entry in the hosts file for the DC that pointed to the old globally-routable IP address for the DC before it got moved to a private address behind the firewall. Once I deleted that entry, logins were quick and I can also log in to vCenter using my username.