When trying to open the console of a guest machine in the desktop version of Infrastructure Client, I get the error "Error connecting to authd on host xxxx"
OS: Vista Business N x64 SP2, fully patched
Infrastructure Client: 2.5.0 build 81946
Server: ESX 3.5.0, 82663
Java: 6 update 14
I'm working from home and connecting to the office with Windows PPTP VPN.
I was previously working from home using XP inside VMware Fusion on my iMac and it worked fine from there. I just tested it again and it still works. I know, silly setup there...
Not sure if it matters, but ESX is setup with Active Directory authentication. Its NTP server is our domain controller; as it also is for my Vista and XP machines. I'm in a different time zone than the server, but so was the XP machine.
I tried disabling the Windows firewall and no luck. I don't think it's that since I'm having no problem with any other LAN services over the VPN.
I tried connecting directly to authd using "telnet <host> 903" and instantly got "220 VMware Authentication Daemon Version 1.10: SSL Required, ServerDaemonProtocol:SOAP, MKSDisplayProtocol:VNC"
Also tried disabling the ESX firewall.
So now I'm out of ideas. Anyone else have any?
If the SYN_SENT reply disappeared we know that TCP was able to connect to the server on all TCP ports so we know its not a firewall rule \ networking issue also that the service is up as it responded. What do your VI client logs say? Is there anything erroring?
Have a look at http://communities.vmware.com/thread/46632
This mentions amending /etc/vmware/config to vmauthd.server.alwaysProxy=TRUE also it mentions removing a registry key for the VI client? HKEY_CURRENT_USER\Software\VMware\Virtual Infrastructure Client\Preferences
try restarting the following service on the ESX server:
I tried restarting all of those services, though vmware-vpxa does not exist.
Still no luck. I also tried the proxy thing again and restarting the services I could and again, nothing.
It really feels like something is wrong with my VI Client or destop.
Is the right way to view the VI Client logs to do File > Export > Export Diagnostics Data?
If so, there's nothing useful there either.
Is this happening for all the Guest VM's running on the ESX host or for just this VM??
In the diag. reports look for viclient-support folder and vicleint.log file.... hopefully u would something in there that points u to the right direction!!!
It happens for every guest on the ESX host.
I looked at the log files and there is nothing useful in them.
It's just stuff like this over and over again
[viclient:SoapTran] 2009-07-30 16:40:12.753 Start Invoke 42 - PropertyCollector:ha-property-collector.WaitForUpdates ... [viclient:SoapTran] 2009-07-30 16:40:12.756 Start Invoke 43 - VirtualMachine:384.AcquireMksTicket ... [viclient:SoapTran] 2009-07-30 16:40:12.888 Finish Invoke 43 - Serial:0,003, Server:000,130 - VirtualMachine:384.AcquireMksTicket [viclient:SoapTran] 2009-07-30 16:40:16.326 Start Invoke 44 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]527b350d-4988-34ae-972c-2f57002137b5.Destroy ... [viclient:SoapTran] 2009-07-30 16:40:16.332 Start Invoke 45 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]52132bc5-c4dc-056e-bc4c-f947726a1094.Destroy ... [viclient:SoapTran] 2009-07-30 16:40:16.338 Start Invoke 46 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]52d847f6-afa9-567c-28ca-f2a1dc9f69ec.Destroy ... [viclient:SoapTran] 2009-07-30 16:40:16.437 Finish Invoke 44 - Serial:0,001, Server:000,110 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]527b350d-4988-34ae-972c-2f57002137b5.Destroy [viclient:SoapTran] 2009-07-30 16:40:16.439 Finish Invoke 45 - Serial:0,000, Server:000,107 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]52132bc5-c4dc-056e-bc4c-f947726a1094.Destroy [viclient:SoapTran] 2009-07-30 16:40:16.445 Finish Invoke 46 - Serial:0,000, Server:000,108 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]52d847f6-afa9-567c-28ca-f2a1dc9f69ec.Destroy [viclient:SoapTran] 2009-07-30 16:40:19.011 Finish Invoke 42 - Serial:0,001, Server:006,257 - PropertyCollector:ha-property-collector.WaitForUpdates [viclient:QuickInf] 2009-07-30 16:40:19.012 WaitForUpdates Version = 12 [viclient:SoapTran] 2009-07-30 16:40:19.012 Start Invoke 47 - PropertyCollector:ha-property-collector.WaitForUpdates ... [viclient:SoapTran] 2009-07-30 16:40:19.225 Finish Invoke 47 - Serial:0,001, Server:000,212 - PropertyCollector:ha-property-collector.WaitForUpdates [viclient:QuickInf] 2009-07-30 16:40:20.012 WaitForUpdates Version = 13 [viclient:SoapTran] 2009-07-30 16:40:20.012 Start Invoke 48 - PropertyCollector:ha-property-collector.WaitForUpdates ... [viclient:SoapTran] 2009-07-30 16:40:36.542 Start Invoke 49 - DiagnosticManager:ha-diagnosticmgr.GenerateLogBundles ... [viclient:SoapTran] 2009-07-30 16:40:36.673 Finish Invoke 49 - Serial:0,001, Server:000,130 - DiagnosticManager:ha-diagnosticmgr.GenerateLogBundles [viclient:SoapTran] 2009-07-30 16:40:36.675 Start Invoke 50 - PropertyCollector:ha-property-collector.CreateFilter ... [viclient:SoapTran] 2009-07-30 16:40:36.685 Finish Invoke 48 - Serial:0,005, Server:016,667 - PropertyCollector:ha-property-collector.WaitForUpdates [viclient:QuickInf] 2009-07-30 16:40:36.685 WaitForUpdates Version = 14 [viclient:SoapTran] 2009-07-30 16:40:36.685 Start Invoke 51 - PropertyCollector:ha-property-collector.WaitForUpdates ... [viclient:SoapTran] 2009-07-30 16:40:36.900 Finish Invoke 50 - Serial:0,000, Server:000,225 - PropertyCollector:ha-property-collector.CreateFilter [session[526e5880-f052-077b-2c9a-325705be585e]520e51b4-5e15-6e95-304d-b0f43c81a7db] [viclient:SoapTran] 2009-07-30 16:40:36.901 Finish Invoke 51 - Serial:0,001, Server:000,215 - PropertyCollector:ha-property-collector.WaitForUpdates [viclient:QuickInf] 2009-07-30 16:40:36.945 WaitForUpdates Version = 15 [viclient:SoapTran] 2009-07-30 16:40:36.945 Start Invoke 52 - PropertyCollector:ha-property-collector.WaitForUpdates ... [viclient:SoapTran] 2009-07-30 16:41:33.931 Finish Invoke 52 - Serial:0,002, Server:056,982 - PropertyCollector:ha-property-collector.WaitForUpdates [viclient:QuickInf] 2009-07-30 16:41:33.932 WaitForUpdates Version = 16 [viclient:SoapTran] 2009-07-30 16:41:33.932 Start Invoke 53 - PropertyCollector:ha-property-collector.WaitForUpdates ...
I am having similiar problems connecting to my ESX 3.5 infrastructure from the VI client or web ui. I am getting the error connecting to authd on host xxx.xxx.xxx.xxx
. Until recently I have been able to connect through the VI Client and
web ui. Nothing on the ESX server has been changed or updated. I am
running ESX on a Dell PowerEdge server with no attached SANS,
...etc. I am running ESX 3.5.0 build 64607 and VI client 2.5.0 build
64192. Virtual Center is not installed. The server and desktops are on
the same subnet. I have restarted the services associated with vmware:
mgmt-vmware, xinetd, and vmware-vmkauth. There are no reported errors
with these services. They start fine. I have successfully telneted to
port 902 and 903. I am able to ping the host through FQDN or IP
address. I can RDP to vmware image and access it. I can access the web
pages being hosted from the image.
I have tried different laptops to connect through the client and
web interface. I get mixed results. Some of the laptops were able to
connect through the client and web ui and others get the same authd
error. This leads me to believe that something on the laptop(s)(Microsoft) are
causing my issue. All of the laptops are using Windows XP SP2, IE 8,
.net 3.5 sp1. I have tried to find dll's that are different in version
#, but nothing has surfaced. Has anyone had problems with other
software on their laptops or desktops that host the VI client and
prevent it from viewing the vmware client console?
Any help would be greatily appreciated.
I also tried the "always use proxy" setting with no joy.
I am using Windows 7 x64. For grins, I ran compatiability check and set to use XP SP2 and the Client now works great.
Hope that could also help someone else, since this case is rather aged, but still Google finds it at the top of the list.
The true cause of the problem is detected.
My configuration: Windows XP SP3, VMware-viclient3.5u5 (VIC 2.5.0 Build 204931)
On my workstation, set a wide variety of software, perhaps you do the same thing:).
It was found that the client VpxClient.exe strange loads some DLL libraries (libeay32.dll ssleay32.dll)
My problem was due to the fact that I had installed php-5.3.2-Win32-VC6-x86.msi
After starting the VIC when i trying to open the console, loaded libraries (libeay32.dll ssleay32.dll)
Due to the fact that I have a folder c:\PHP\ have these files in the environment variable Path registered there way, the client VpxClient.exe loads libraries from there and we have the error. Process vmware-remotemks.exe not even start.
If i remove the "c:\PHP\" from the Path environment variable, then the problem disappears. Even though that is used in my particular case, a library of OpenVPN :). You may be the way that other realties.
Thanks to Mark Russinovich for the excellent Process Explorerutility and of course the divine Wireshark, which prompted to begin to look for the cause of the problem.
Good luck, I hope my troubles to anyone at will.
This fix worked for me.
I had installed PHP as well. And once I removed the c:\PHP5 from my path and did a restart of my computer, I was able to connect to my virtuals.
Wow nice find zalexua. I had the same issue except it was related to Nmap and not PHP. Nmap (or zenmap) apparently sets itseful up in the user path. Using your same technique, I was able to discover that, remove it from the path and viola! VI Client works again!
It took me a second to find the DLLs view in Process Explorer (View > Lower Pane Views > DLLs), and then you need to add the Path column to the DLLs view. But after that it was pretty simple. Again, well done. That's hugely helpful.
I have had this error recently with VIC 184.108.40.206258
In the registry under HKEY_CURRENT_USER\software\Virtual Infrastructure Client I renamed "preferences" and restarted the VIC.
All is now working without any problem
That's likely only a temporary solution. You can delete the entire registry key and have it work once. If you close the app and then run it again, you'll likely run into the authd issue all over again. I'm not really sure how the registry key relates to the other dlls in the path, but the only permanent solution for me was to remove the conflicting DLLs from the path with a little detective work in ProcessExplorer per zalexua's post.