Configure the vSphere Web Client to Bypass vCenter Single Sign On

You can configure the vSphere Web Client to bypass the vCenter Single Sign On server. This allows the vSphere Web Client to connect directly to vCenter Server 5.0 systems that are registered with the vSphere Web Client.

If your environment contains both vCenter Server 5.0 and vCenter Server 5.1 system, you can use this setting to access the vCenter Server 5.0 systems if the vCenter Single Sign On Server becomes unavailable.

vCenter Single Sign On is required to connect to vCenter Server 5.1 systems. If you configure the vSphere Web Client to bypass Single Sign On, you cannot use it to connect to any vCenter Server 5.1 systems until you undo this configuration change.

Procedure

1	On the computer where the vSphere Web Client is installed, locate the webclient.properties file. The location of this file depends on the operating system on which the vSphere Web Client is installed. Operating System File path Windows 2003 %ALLUSERPROFILE%Application Data\VMware\vSphere Web Client Windows 2008 %ALLUSERPROFILE%\VMware\vSphere Web Client vCenter Server Appliance /var/lib/vmware/vsphere-client
2	Edit the file to include the line sso.enabled = false.
3	Restart the vSphere Web Client service. ■ On Windows operating systems, restart the VMware vSphere Web Client service. ■ On the vCenter Server Appliance, restart the vSphere-client service by typing service vsphere-client restart.

After you have restarted the vSphere Web Client, you can select the vCenter Server 5.0 system to log in to from the login page.

What to do next

To return the vSphere Web Client to using vCenter Single Sign On, edit the webclient.properties file to remove the sso.enabled = false line, and restart the vSphere Web Client service.

Thanks to Vmware Documentation

Configure the vSphere Web Client Timeout Value

By default, vSphere Web Client sessions terminate after 120 minutes of idle time, requiring the user to log in again to resume using the client. You can change the timeout value by editing the webclient.properties file.

Procedure

1	On the computer where the vSphere Web Client is installed, locate the webclient.properties file. The location of this file depends on the operating system on which the vSphere Web Client is installed. Operating System File path Windows 2003 %ALLUSERSPROFILE%Application Data\VMware\vSphere Web Client Windows 2008 %ALLUSERSPROFILE%\VMware\vSphere Web Client vCenter Server Appliance /var/lib/vmware/vsphere-client
2	Edit the file to include the line session.timeout = value where value is the timeout value in minutes. To set the client to never time out, specify a negative or 0 value for the timeout. For example, to set the timeout value to 60 minutes, include the line session.timeout = 60.
3	Restart the vSphere Web Client service. ■ On Windows operating systems, restart the VMware vSphere Web Client service. ■ On the vCenter Server Appliance, restart the vSphere-client service.

Thanks to Vmware Documentation

Configure vCenter Administrator as an SSO admin

If you want to configure vCenter Administrator as an SSO admin then 

1. Login to vSphere Web Client via this URL

https://webclientserverIP/FQDN:9443/vsphere-client

username = admin

password = sso admin account password configured by you during the SSO installation

2. Then Click on the Administration at Home Screen and then Follow the Steps given in this Screenshot

3. In this Example i have given the rights to vCenter Server Local Administrator as an SSO Administrator
like this even you can provide the rights to (SSO Users, vCenter Local Users and Domain Users) as well.

That's Done !!!!!!

ESXi/ESX host disconnects from vCenter Server after adding or connecting it to the inventory (2040630)

Symptoms

• An ESXi/ESX host disconnects from vCenter Server.
• After adding or reconnecting an ESXi/ESX to the vCenter Server inventory, it disconnects 30 to 90 seconds after the task completes.
• Changing the uplink switch port VLAN information for the new IP of the ESXi host before changing the IP of the ESXi host results in the host showing as disconnected in vCenter Server.
• Changing the IP address of the ESXi host using the DCUI without first removing the host from the vCenter Server inventory results in the host showing up as disconnected in vCenter Server.

Purpose

This article helps identify issues with heartbeat traffic between vCenter Server and ESXi/ESX hosts.

The steps provided in this article and the included Knowledge Base article links help determine if heartbeat packets are being dropped or lost.

Cause

This issue is caused by dropped, blocked, or lost heartbeat packets between the vCenter Server and the ESXi/ESX host.

If there is an incorrect configuration of the vCenter Server managed IP address, the host receives the heartbeat from vCenter Server but cannot return it.

It is important to remember that the default heartbeat port is UDP 902, and these packets must be sent between vCenter Server and the ESXi/ESX host for the host to stay connected and remain in the vCenter Server inventory.

If the host is not connecting to vCenter Server at all, the cause may be another network issue.

Resolution

To troubleshoot this issue, ensure that bidirectional heartbeat communications are functioning correctly.

The default port for this communication is UDP 902, but be sure to verify the configured port in the vpxa.cfg file on the host. This file also defines the IP address which manages the host.

Confirm vCenter Server managed IP address

Confirm the vCenter Server managed IP address continuity throughout the environment.

1. Determine the managed IP address of the vCenter Server:
   
   
   1. Connect to the vCenter Server with the vSphere Client.
   2. Go to Administration > vCenter Server Settings > Advanced Settings.
   3. Make note of the IP address in the ManagedIP row.
      
2. Determine the IP address configured for vCenter Server:
   
   
   1. From a console or RDP session to the vCenter Server desktop, open a command prompt.
   2. Run the command:
      
      ipconfig
      
   3. Make note of the IP address and ensure that it matches the managed IP address found in step 1.
      
3. Determine the IP address and port that the ESXi/ESX host is using for heartbeat traffic:
   
   
   1. Connect to the ESXi/ESX host using the vSphere Client.
   2. When the Warning pop-up appears, make note of the IP address which is managing the host.
   3. Connect to the same host using SSH.
   4. Check the vpxa.cfg file for the heartbeat traffic port by running the command:
      
      
      • On ESXi 5.x:
        
        grep -i serverport /etc/vmware/vpxa/vpxa.cfg
        
      • On ESXi/ESX 4.1 and earlier:
        
        grep -i serverport /etc/opt/vmware/vpxa/vpxa.cfg
        
   5. Ensure that the port number matches the default heartbeat port of 902.
   6. Check the vpxa.cfg file for the managed IP address by running the command:
      
      
      • On ESXi 5.x:
        
        grep -i serverIp /etc/vmware/vpxa/vpxa.cfg
        
      • On ESXi/ESX 4.1 and earlier:
        
        grep -i serverIp /etc/opt/vmware/vpxa/vpxa.cfg
        
   7. Ensure that the IP address matches the managed IP address found in step 1.

Connectivity

Test connectivity between vCenter Server and the ESXi/ESX host via the heartbeat network.

Using telnet and netcat, test connectivity over the heartbeat network via the configured heartbeat port (default 902). For more information, see:

• Troubleshooting network and TCP/UDP port connectivity issues on ESXi/ESX (2020669)
• TCP and UDP Ports required to access vCenter Server, ESXi/ESX hosts, and other network components (1012382)

Congestion

Test network congestion:

• To test whether UDP heartbeat packets are being received by vCenter Server within the 60-second timeout period, seeESXi/ESX host disconnects from vCenter Server 60 seconds after connecting (1029919).
• If packets are delayed due to network congestion, see ESXi/ESX host keeps disconnecting and reconnecting when heartbeats are not received by vCenter Server (1005757).
• If NAT is configured, see ESXi hosts connected to vCenter Server using NAT disconnect after 30 to 60 seconds (2019865).

Other troubleshooting areas

• Check the NIC firmware and driver levels on the affected host and compare these with other hosts. For more information, see Determining Network/Storage firmware and driver version in ESXi/ESX 4.x and 5.x (1027206).
• Check the Address Resolution Protocol and Neighbor Discovery cache for inconsistencies. For more information, seeDisplaying the ARP and Neighbor Discovery cache for VMkernel network interfaces (2000130).
• Capture a network trace and analyze for inconsistency. For more information, see Capturing a network trace in ESXi using Tech Support Mode or ESXi Shell (1031186).

Additional Information

For more information on the vpxa.cfg file, see ESXi 5.0 hosts are marked as Not Responding 60 seconds after being added to vCenter Server (2020100).

For more information on similar issues, see:

• vCenter Server IP address change causes ESX hosts to disconnect (1001493)
• Verifying the vCenter Server Managed IP Address (1008030)

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2040630

ESXi/ESX host disconnects from vCenter Server 60 seconds after connecting (1029919)

Symptoms

• An ESXi/ESX host is successfully added to the vCenter Server inventory but enters a Not Responding or Disconnectedstate after one minute.
• You can use the vSphere Client to successfully connect to the ESXi/ESX host directly.
• In the vpxd.log file, you see entries similar to:
  
  2012-04-02T13:07:49.438+02:00 [02248 info 'Default' opID=66183d64] [VpxLRO] -- BEGIN task-internal-252 -- -- vim.SessionManager.acquireSessionTicket -- 52fa8682-47e0-2566-fb05-6192cb2c22f9(5298e245-ffb6-f7f8-e8a0-dedfbe369255)
  2012-04-02T13:07:49.579+02:00 [02068 info 'Default'] [VpxLRO] -- BEGIN task-internal-253 -- host-94 -- VpxdInvtHostSyncHostLRO.Synchronize --
  2012-04-02T13:07:49.579+02:00 [02068 warning 'Default'] [VpxdInvtHostSyncHostLRO] Connection not alive for host host-94
  2012-04-02T13:07:49.579+02:00 [02068 warning 'Default'] [VpxdInvtHost::FixNotRespondingHost] Returning false since host is already fixed!
  2012-04-02T13:07:49.579+02:00 [02068 warning 'Default'] [VpxdInvtHostSyncHostLRO] Failed to fix not responding host host-94
  2012-04-02T13:07:49.579+02:00 [02068 warning 'Default'] [VpxdInvtHostSyncHostLRO] Connection not alive for host host-94
  2012-04-02T13:07:49.579+02:00 [02068 error 'Default'] [VpxdInvtHostSyncHostLRO] FixNotRespondingHost failed for host host-94, marking host as notResponding
  2012-04-02T13:07:49.579+02:00 [02068 warning 'Default'] [VpxdMoHost] host connection state changed to [NO_RESPONSE] for host-94
  2012-04-02T13:07:49.610+02:00 [02248 info 'Default' opID=66183d64] [VpxLRO] -- FINISH task-internal-252 -- -- vim.SessionManager.acquireSessionTicket -- 52fa8682-47e0-2566-fb05-6192cb2c22f9(5298e245-ffb6-f7f8-e8a0-dedfbe369255)
  2012-04-02T13:07:49.719+02:00 [02068 info 'Default'] [VpxdMoHost::SetComputeCompatibilityDirty] Marked host-94 as dirty.

Cause

This issue may occur if heartbeat packets are not received from the host before the one minute timeout period expires. These heartbeat packets are UDP packets sent over port 902.

This issue may also occur when the Windows firewall is enabled and the ports are not configured.

Resolution

To resolve this issue, check the Windows Firewall on the vCenter Server machine. If ports are not configured, disable the Windows Firewall.

If ports are configured, verify if network traffic is allowed to pass from the ESXi/ESX host to the vCenter Server system, and that it is not blocking UDP port 902.

To perform a basic verification from the guest operating system perspective:

1. Click Start > Run, type wf.msc, and click OK. The Windows Firewall with Advanced Security Management console appears.
2. In the left pane, click Inbound Rules.
3. Right-click the VMware vCenter Server -host  heartbeat rule and click Properties.
4. In the Properties dialog, click the Advanced tab.
5. Under Profiles, ensure that the Domain option is selected.

You can use Wireshark to verify if the network allows bi-directional traffic.

Note: VMware does not endorse or recommend any particular third-party utility.

To verify if bi-directional traffic is allowed:

1. Download Wireshark from http://www.wireshark.org/ and install it on the vCenter Server system.
2. On ESXi, enable Tech Support Mode. For more information on enabling Tech Support Mode, see:
   
   
   • For ESXi 4.1 and 5.x: Using Tech Support Mode in ESXi 4.1 and ESXi 5.x (1017910)
   • For ESXi 4.0: Tech Support Mode for Emergency Support (1003677)
3. Download the Python script attached to this article (udp_client.py) to the ESXi/ESX system in question.
4. Edit the udp_client.py script on the ESXi/ESX host with a text editor. Modify the line, "host = '192.168.1.1'" and replace 192.168.1.1 with the IP address of the vCenter Server system.
5. Start Wireshark on the vCenter Server system.
   
   
   1. In the Filter field, enter ip.src==IP_of_host and udp.port==902. Replace IP_of_host with the IP address of the ESXi/ESX host in question.
   2. Click Apply.
   3. From the Capture menu, select Interfaces and click Start next to the NIC used for vCenter Server IP traffic.
      
6. From the ESXi/ESX host, run this command:
   
   python udp_client.py
   
   The total number of packets sent, the port, and the destination address are displayed.
   
7. On the vCenter Server system, watch the Wireshark screen for any packets showing up that match the filter applied.
8. If no packets are received, this indicates that something is blocking UDP traffic over port 902 from the ESXi/ESX host to the vCenter Server system. Inspect the physical networking environment and any software-based firewall on the vCenter Server system.

Ensure that these ports are open in the firewall between vCenter Server and the ESXi/ESX hosts:

• 902 - UDP & TCP
• 443 - TCP

For more information, see TCP and UDP Ports required to access vCenter Server, ESX hosts, and other network components (1012382).

Additional Information

This article does not assist you in troubleshooting ESXi 3.5 hosts that are disconnecting from vCenter Server after one minute as a Python interpreter is not installed on ESXi 3.5.

For more information on a similar issue, see ESXi/ESX host disconnects from vCenter Server after adding or connecting it to the inventory (2040630).

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1029919

Repointing and reregistering VMware vCenter Server 5.1.x and components(2033620)

I was getting this message and I resolved this Issue by using this KB Article. This might be helpful for all of you as well

Details

After certain changes to your vSphere deployment topography, you might need to repoint or reregister vCenter Server components with the vCenter Inventory Service or vCenter Single Sign-On and the vCenter Lookup Service to ensure that the components can continue to communicate.

Caution: The procedures in this article are supported by VMware only when used with the guidance of VMware Technical Support.

If a vCenter Single Sign-On instance fails or is corrupted, any associated vCenter Servers, Inventory Service instances, and vSphere Web Client instances lose access to vSphere. In this case, you have several options:

• If you do not have another Single Sign-On instance, you can create a new Single Sign-On instance.
• If your Single Sign-On instance is corrupted, and you have a current, uncorrupted backup of the Single Sign-On database and configuration, you can restore Single Sign-On to a new host machine. For information about creating, backing up, or restoring a Single Sign-On instance, see the vSphere 5.1 Installation and Setup Guide on the VMware vSphere Documentation page.
• If your deployment has another Single Sign-On instance, you can repoint vCenter Server components to that instance.

Similarly, when you relocate a vCenter Server instance or make certain changes to the vCenter Inventory Service, you must reregister vCenter Server with vCenter Inventory Service.

Solution

If you are responding to a failed Single Sign-On instance, perform the procedures in this order:

1. Remove the Inventory Service account
   
   Note: This is required only if you are reregistering the vCenter Inventory Service to the same Single Sign-On instance that the vCenter Inventory Service was originally registered to.
2. Reregister vCenter Inventory Service with vCenter Single Sign-On
3. Register vCenter Server with a different vCenter Single Sign-On instance
4. Reregister vCenter Server with the Inventory Service
5. Register the vSphere Web Client with a different vCenter Single Sign-On instance

Remove the Inventory Service account

This procedure is required only if you reregister vCenter Inventory Service to the same Single Sign-On instance that Inventory Service was originally registered to. When you reregister Inventory Service to the same Single Sign-On instance, you must first remove the Inventory Service account from the Single Sign-On application users. Otherwise, the reregistration will fail with the error, AlreadyRegistered.

To remove the Inventory Service account:

1. In the vSphere Web Client, go to Administration.
2. In SSO Users and Groups, click Application Users.
3. Delete the Inventory Service account.

Reregister vCenter Inventory Service with vCenter Single Sign-On

During vCenter Inventory Service installation or upgrade, the Inventory Service is registered with a vCenter Single Sign-On instance, and the Inventory Service stores the location of the vCenter Single Sign-On instance. When you relocate a vCenter Single Sign-On instance or switch to a different Single Sign-On instance, update the corresponding Inventory Service instance. If a Single Sign-On instance fails or is corrupted, you can also use this procedure to repoint the Inventory Service to a different Single Sign-On instance.

If changes occur to any of these entities, reregister the Inventory Service with vCenter Single Sign-On using:

• IP address of the vCenter Single Sign-On instance
• vCenter Inventory Service host DNS or IP address
• vCenter Inventory Service certificates

Note: If you are reregistering the Inventory Service to the same Single Sign-On instance, you must first remove the Inventory Service account from the Single Sign-On application users. For more information, see the Remove the Inventory Service account section. 
To reregister the Inventory Service with vCenter Single Sign-On:

1. Open a command prompt on the Inventory Service host machine.
2. Change directory to:
   
   C:\Program Files\VMware\Infrastructure\Inventory Service\scripts
   
   Note: If you installed vCenter Inventory Service in a different location from the default C:\Program Files\, adjust the path.
   
   Note: Typically, short names are not disabled. However, if you have disabled short names on your system, or have removed short names for the folder where the Inventory Service and vCenter Server are installed, follow these steps:
   
   
   1. Open the regTool.cmd file with a text editor. The regTool.cmd file is located at:
      
      installation_path\Inventory Service\sso
   2. In the line beginning with set LOG4J_CONF=, enclose %TOOLDIR% in quotations marks:
      
      "%TOOLDIR%"
   3. Save and close the file.
3. Run the is-change-sso.bat command to update the stored configuration information of the Inventory Service:
   
   is-change-sso.bat ssoServerUrl "ssoAdminuser" "ssoAdminPassword"
   
   Use this example as a model:
   
   is-change-sso.bat https://machinename.corp.com:7444/lookupservice/sdk "admin@System-Domain" "SSO_pw1!"
   
   In this example, 7444 is the default HTTPS port number for vCenter Single Sign-On. If you use a custom port, replace the port number in the example with the port number you use. The quotation marks are required to escape special characters in the Single Sign-On user name and password.
4. Restart the Inventory Service:
   
   net stop vimQueryService
net start vimQueryService

The vCenter Inventory Service URL configuration is now updated and the Inventory Service is reregistered with vCenter Single Sign-On.

Note: If you are reregistering the Inventory Service to the same Single Sign-On instance, you must also reregister vCenter Server with the Inventory Service. For more information, see the Reregister vCenter Server with the Inventory Service section.

Register vCenter Server with a different vCenter Single Sign-On instance

During installation or upgrade, vCenter Server is registered with the Lookup Service for a vCenter Single Sign-On instance. You can change this registration to the Lookup Service for a different Single Sign-On instance. You might register vCenter Server to a different vCenter Single Sign-On instance if the original Single Sign-On instance fails, or if you add a new Single Sign-On node and want to associate vCenter Server with the new node.

Note: When you register vCenter Server to a new Single Sign-On instance, you lose these permissions:

• All permissions created for users from the Single Sign-On system identity source
• All permissions granted to users from identity sources that are not present in the new Single Sign-On instance
• All permissions granted to local operating system users

To register vCenter Server to a different vCenter Single Sign-On instance:

1. Open a command prompt on the vCenter Server host machine as administrator.
2. Change directory to:
   
   C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregtool
   
   Note: If you have installed vCenter Server in a location other than the default C:\Program Files\ folder, adjust the path. Also, in the repoint.cmd file, ensure that JAVA_HOME points to the correct location of your vCenter Server installation.
3. Unzip the sso_svccfg.zip file.
   
   Note: Best practice is to unzip these files into a new folder and change directory to the new folder before executing the next step.
4. Run this command to register vCenter Server to a different Single Sign-On instance:
   
   repoint.cmd configure-vc --lookup-server lookup_service_url --user single_sign_on_admin_user --password single_sign_on_admin_password --openssl-path "path_to_OpenSSL_bin_directory/"
   
   Note: If you installed vCenter Server in a location other than the default, you must add this option to the repointcommand:
   
   --vc-install-dir "path_to_vCenter_Server_install_directory"
   
   The openssl-path path must be enclosed in quotation marks and followed by a trailing forward slash. The openssl-path parameter is required to update the trust store with the new Lookup Service and Single Sign-On certificates. If you do not provide it, the command will execute successfully, but you must manually update the certificate trust store. See the information about updating the certificate trust store for vCenter components in the VMware tech note, Replacing Default vCenter 5.1 and ESXi Certificates.
   
   Use this example as a model:
   
   repoint.cmd configure-vc --lookup-server https://machinename.corp.com:7444/lookupservice/sdk --user "admin@System-Domain" --password "SSO_pw1!" --openssl-path "C:\Program Files\VMware\Infrastructure\Inventory Service\bin/"
   
   In this example, 7444 is the default HTTPS port number for vCenter Single Sign-On. If you use a custom port, replace the port number in the example with the port number you use. The quotation marks are required to escape special characters in the Single Sign-On user name and password.
   
   Notes:
   
   • If you receive the error The system cannot find the path specified, verify that the %JAVA_HOME% location in the repoint.cmd script (by default, set to: C:\Program Files\VMware\Infrastructure\jre) exists, is populated with data, and points to the correct JRE folder. If it is not, check for C:\Program Files\VMware\Infrastructure\jre1, and if this exists, update the script to point to the correct JAVA_HOMElocation and try the command again.
     
     For example, change:
     
     set CMD="%JAVA_HOME%\bin\java"
     to:
     
     set CMD="directory\Program Files\VMware\Infrastructure\jre\bin\java.exe" 
   • If you receive the error Abnormal command failure: exception `Cannot locate configuration source C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregt ool\vcsso.properties', create the folder structure C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregtool and copy thevcsso.properties file in to the ssoregtool folder.
5. Restart the VMware VirtualCenter Server and the VMware VirtualCenter Management Webservices services:
   
   
   1. In the Administrative Tools control panel, click Services.
   2. Right-click VMware VirtualCenter Server and click Restart.
   3. Right-click VMware VirtualCenter Management Webservices and click Restart.

The vCenter Server is now registered with the new Single Sign-On instance.

Reregister vCenter Server with the Inventory Service

During installation or upgrade, vCenter Server is registered with the vCenter Inventory Service, and the Inventory Service stores the location of vCenter Server. When you relocate a vCenter Server instance or make changes to the vCenter Inventory Service, you must update the corresponding Inventory Service instance.

Reregister the Inventory Service with vCenter Server if any of these entities change:

• vCenter Inventory Service certificate
• vCenter Server IP address or host name
• vCenter Inventory Service address or host name

You must also reregister vCenter Server with the Inventory Service if you reinstall the Inventory Service on the same machine and if any of these conditions apply:

• You overwrite the Inventory Service database during the reinstallation
• You reinstall the Inventory Service with a different path to the installation directory
• You change the Inventory Service port number

To reregister vCenter Server with the Inventory Service:

1. Open a command prompt.
2. Change directory to:
   
   C:\Program Files\VMware\Infrastructure\VirtualCenter Server\isregtool
   
   Note: If you installed the vCenter Inventory Service in a location other than the default C:\Program Files\, adjust the path.
3. Run the register-is.bat command to update the stored configuration information of the Inventory Service:
   
   register-is.bat vCenter_Server_URL Inventory_Service_URL Lookup_Service_URL
   
   Use this example as a model:
   
   register-is.bat https://machinename.corp.com:443/sdk https://machinename.corp.com:10443 https://machinename.corp.com:7444/lookupservice/sdk
   
   In this example, 443, 10443, and 7444 are the default HTTPS port numbers for vCenter Server, the Inventory Service, and vCenter Single Sign-On respectively. If you use custom ports, replace the port numbers in the example with the port numbers you use. The server FQDN should be used rather than an IP address for machinename.corp.com. If an IP address is used, you may see the SslHandshakeFailed=1 error.
4. Restart vCenter Server.

The vCenter Inventory Service URL configuration is now updated and vCenter Server is reregistered with the Inventory Service.

Register the vSphere Web Client with a different vCenter Single Sign-On instance

During installation or upgrade, the vSphere Web Client is registered with the Lookup Service for a vCenter Single Sign-On instance. If the Single Sign-On instance fails or changes, you might need to register the vSphere Web Client with a different vCenter Single Sign-On Lookup Service.

If the vCenter Single Sign-On server fails or is corrupted, you can install a new Single Sign-On instance and register the vSphere Web Client to the new Single Sign-On instance. Alternatively, you can install a new vSphere Web Client and register it to the new Single Sign-On instance. For more information, see the vSphere Installation and Setup documentation.

If you repoint vCenter Server and the vCenter Inventory Service from the failed Single Sign-On instance to a different, existing Single Sign-On instance, you can use the vSphere Web Client that is already registered with that Single Sign-On instance.

To register the vSphere Web Client with a different vCenter Single Sign-On Lookup Service:

1. Open a command prompt.
2. Change directory to:
   
   C:\Program Files\VMware\Infrastructure\vSphereWebClient\scripts
   
   Note: If you installed the vSphere Web Client in a location other than the default C:\Program Files\, adjust the path.
3. Run the client-repoint.bat command to register the vSphere Web Client with a different vCenter Single Sign-On and Lookup Service:
   
   client-repoint.bat lookup_service_url "single_sign_on_admin_user" "single_sign_on_admin_password"
   
   Use this example as a model:
   
   client-repoint.bat https://machinename.corp.com:7444/lookupservice/sdk "admin@System-Domain" "SSO_pw1!"
   
   In this example, 7444 is the default HTTPS port number for vCenter Single Sign-On. If you use a custom port, replace the port number in the example with the port number you use. The quotation marks are required to escape special characters in the Single Sign-On user name and password.

The vSphere Web Client is now registered with the vCenter Single Sign-On and Lookup Service.

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2033620

Unlocking and resetting the vCenter Single Sign On (SSO) administrator password (2034608)

Symptoms

• You are unable to log in to the vSphere Web Client using your SSO administrator credentials
• Logging in to the vSphere Web Client using your SSO administrator credentials fails 
• The password has been incorrectly entered three times (by default)
• You see the error:
  
  User account is locked. Please contact your administrator.

Cause

For security purposes, the administrator account is automatically locked out if there are too many failed login attempts. By default, vCenter SSO allows for three failed login attempts before an account is locked out.

Resolution

To resolve this issue, you must unlock/reset the administrator account. To reset the password, you must know the original password.

 

To unlock/reset the administrator account, use one of these methods:

• Wait for 15 minutes. By default, the account lockout policy is set to unlock after 15 minutes. For more information on account lockout policies for vCenter SSO, see Configuring and troubleshooting vCenter Single Sign On password and lockout policies for accounts (2033823).
  
• Unlock the account using another session that is still logged into the SSO server or using another user account with administrator privileges. 
  
  To unlock an account using another session or using another user account with administrator privileges:

1. Click Home.
2. Click Administration.
3. Click SSO Users and Groups.
4. Right-click the affected user account, such as admin, and click Unlock.
   

• In emergency situations or if the default policies have been changed, you can also reset the password to unlock the account.
  
  To reset the SSO administrator password on a Windows server:
  
  Note: Resetting the password will also unlock the administrator account.

1. Login as an administrator to the vCenter SSO server.
2. Click Start > Run, type cmd, and click OK. The Command Prompt window opens.
3. Navigate to the directory SSOInstallDirectory\utils. By default, the installation directory is C:\Program Files\VMware\Infrastructure\SSOServer\utils.
4. Run this command:
   
   rsautil reset-admin-password
5. Enter the master password when prompted.
   
   Note: This is the password selected for the SSO administrator during the SSO installation. If you have changed your SSO administrator password later, the master password is still the original one chosen.
   
6. Enter the SSO administrator name for which you want to reset the password. For example, admin.
7. Enter the new password for the user and then confirm it a second time.
   
   You should see the message Password reset successfully.

To reset the SSO administrator password on the vCenter Server Appliance:

1. Log in as root to the vCenter server Appliance. 
2. From the command line, navigate to /usr/lib/vmware-sso/utils directory. 
3. Run this command:
   
   ./rsautil reset-admin-password
4. Enter the master password when prompted.
   
   Note: By default, this is the root password.
   
5. Enter the SSO administrator name for which you want to reset the password. For example, admin.
6. Enter the new password for the user and then confirm it a second time.
   
   You should see the message Password reset successfully.

Source:-
 http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2034608