VMware vCenter Support Assistant can't resolve vCenter server name

The vCenter Support Assistant is a free Linux (SUSE) based virtual appliance to aid support requests in a vmware environment.

It's quite easy to setup but it has an odd quirk with DNS resolution.

By default, it will try to connect to the vCenter name you use in your vCenter vi-client, and it will ignore the name you use in the setup wizard to register with vCenter.

e.g. if you register with a FQDN for vCenter, but then use the short name in your Windows vi-client, it will report connectivity from virtual appliance to vCenter FAILS during it's diagnostics checks run at first login.

The solution is to manaually go into the linux console and etc the /etc/resolve.conf file and add a search suffic

1. Open Console
2. Login as root
3. edit the resolve.conf file
    vi /etc/resolve.conf
4. append the search suffix to the end of the file
    search yourdomain.com
5. save the file
    esc
    !wq!
6. rerun diagnostics

The last two checks should now pass.

Version of VCSA used was 5.1.1.  YMMV with other versions.

Validation of Dell OMSA Online Repository in VMware Update Manager Download Sources fails

Dell kindly provide an repository containing all the VMware OpenManage versions that you can point Vmware Update Manager to in order to get the right .VIB for your ESXi server

The Update Manager service needs to be able to access the repository url which is https://vmwaredepot.dell.com/index.xml.

If Vmware Update manager lives behind a firewall then the changes are you'll be pointing it a web proxy (In my case this was ISA 2006).  Even though it was allowed unauthenticated access, the validation step kept failing.

A bit of investigation of the firewall logs revealed an odd error:
995 The I/O operation has been aborted because of either a thread exit or an application request

A bit more digging revealed this article, pointing to Java as the culprit.  As Update Manager seems to have some Java components, I updated Java to the latest version (JRE7 Update 40), both x32 and x64 but this didn't resolve the issue.

Another read of the original answer from Jim Harrison led me to wonder if a non-SSL connection would work, so I modified the URL to http://vmwaredepot.dell.com/index.xml and hey presto! the validation succeeded.

The full Dell White Paper is located here:

Can't login after running sysprep?

When running sysprep, the password usually doesn't change unless you get clever with unattended installation scripts.

However if you're using a non-standard (e.g. renamed) local admin account, you may be unable to log on to it after running sysprep.  This is because sysprep actually renames the local admin account back to "Administrator" but leaves the password unchanged.

Just login with Administrator and your password and you should be able to log in ok (tested with Windows 2008 R2 but I'm sure all versions of Windows are the same).