Product Announcements

vSphere Data Protection (VDP) – SSO server could not be found

I ran into the following error today while working with VDP: The SSO server could not be found. Please make sure the SSO configuration on the VDP appliance is correct. There is a KB article on this: http://kb.vmware.com/kb/2072033. After reading through the article and checking those items, the issue was still not resolved.

Some background info: It is my lab environment, which has a couple of DNS sources. I have vCenter Server running on Windows. The Windows server name was vc01.vmware.local and part of an Active Directory domain named vmware.local. The lab environment “outside” of my vmware.local domain is named pml.local. VDP is using a pml.local DNS server as its primary DNS server and a vmware.local DNS server as its secondary DNS server. I know – kind of crazy and no wonder I was having this issue. I tried a variety of combinations with my vmware.local DNS and the hosts file on the VDP appliance, with no luck. I even renamed my vCenter Server to the host name found in the pml.local DNS and re-registered the VDP appliance to vCenter Server using the new host name. The re-registration went fine, but when I tried to connect using the vSphere Web Client – still, no luck (same error).

The fix:

I logged onto the VDP appliance and ran this: tail -f /usr/local/avamar/var/vdr/server_logs/vdr-server.log

I then tried connecting to the VDP appliance using the vSphere Web Client. I observed the VDP appliance attempting to connect to SSO using the URL https://vc01.vmware.local:7444/sso-adminserver/sdk/vsphere.local . I added an entry in the hosts file on the VDP appliance for vc01.vmware.local and I was able to connect. Even though I renamed my vCenter Server, this did not change the URL for connecting to SSO. I verified this in the Advanced Settings for vCenter Server.

Lessons learned and reinforced:

  • DNS must be rock solid in a VMware environment (this has always been the case) – especially with VDP in the mix. You should be able to resolve host names across the entire environment by short name, fully qualified domain name (FQDN), forward lookup, and reverse lookup.
  • Always use fully qualified domain names when configuring VDP.
  • Time must also be in sync. Not the problem in my case, but just making sure everyone is aware.
  • Renaming vCenter Server (the host name) does not change URLs for connecting to SSO, the VIM API, etc.
  • It is possible to populate the /etc/hosts file in the VDP appliance to work around many name resolution issues, but this is not a recommended practice (see the next bullet point).
  • Keep things simple. In my case, it can’t be helped, but having a single source for name resolution is best.

@jhuntervmware