Error connecting to authd on host…

Recently I received this error, when I connected to my Virtual Center Server. At first on one ESX-Host, later on on all. I was shure I wouldn´t fix this until I need it. Now I need it urgently andasked troubleshooter #1 – Google. After eliminating any thoughts on serverside issues, I found an entry on Scott Lowe´s Blog. He had exactly the same problem, except he was using 3.0/3.0.2. My setup is running 3.5, with a mix of U-Versions (I know, should be up2date and the same patchlevel on all machines, but anyway…). He mentioned:

Strangely enough, this problem only seemed to affect VI client installations; we were able to connect without any problems from the VirtualCenter server itself.

Hmm… I gave it a try and realized, it was no problem to connect from my VC Server to any machine´s console. That leads me to the point where I realized, it´s a compatibility issue. I´m running VMware Infrastructure Client v2.5.0 Build 204931 on my computer, and VMware Infrastructure Client v2.5.0 Build 227637 on my server. Both connect to VMware Virtual Center v2.5.0 Build 227637.

To make a long story short: avoid differences in Buildnumber can avoid strange behaviour/malfunction. Easy solution for a major problem, but it took me a while to figure it out.

4 Responses to “Error connecting to authd on host…”

  1. [...] Error connecting to authd on host | An Admins life is hard enough [...]

    Tablet Computers Prices | iPad Wifi Problems said this on April 19th, 2010 at 03:31

  2. If I wipe out the VMWare registry keys on the client machines, I can connect to the consoles fine. But once I close the VI CLient program out and restart it, the authd problem comes back. I need a permanent solution.

    Reginald said this on Februar 9th, 2011 at 14:52

  3. A little persistence helps I guess. I originally found this “solution” a while back: http://communities.vmware.com/thread/223693 but I didn’t have PHP installed so I disregarded it. After revisiting (and finding the DLLs view in Process Explorer) I found that libeay32.dll and ssleay32.dll were also the cause of the problem. Except they weren’t loading from the PHP directory, they were loading from the Nmap directory which was in my user PATH environment variable. Removing that, all is good again.

    Reginald said this on Februar 9th, 2011 at 15:10

  4. Got it! Thanks a lot again for helnipg me out!

    Destrie said this on Mai 17th, 2011 at 03:41

Leave a Reply