Active Directory authentication fails when vCenter Single Sign-On 5.5 runs on Windows Server 2012 and the AD Domain Controller is also on Windows Server 2012 (2060901)

Symptoms

  • Users cannot authenticate with a vCenter Single Sign-On (SSO) 5.5 system that is installed on Windows Server 2012 when this system is joined to an Active Directory domain controller also running on Windows Server 2012.
  • Users receive this error message when trying to log in through the vSphere Web Client:

    Cannot Parse Group Information

  • This issue occurs only in environments where BOTH of these conditions apply:
    • vCenter SSO 5.5 is running on Windows Server 2012, and
    • vCenter SSO 5.5 joined an Active Directory Domain with a Domain Controller that is running on Windows Server 2012.
  • This article does not apply if:
    • The vCenter SSO 5.5 machine is running on Windows Server 2008 or Windows Server 2008 R2 joined to any supported Active Directory Domain version.
    • The vCenter SSO 5.5 machine is running on Windows Server 2012 and the Active Directory domain is running on Windows Server 2008 (and R2).
    • The vCenter SSO 5.5 machine is installed as the vCenter Server Appliance joined to any supported Active Directory Domain version.
    • You are running vCenter SSO versions earlier than 5.5.

Resolution

This issue is resolved in vCenter Server 5.5.0a, available at VMware Downloads. For more information, see the VMware vCenter Server 5.5.0a Release Notes.

To work around this issue on vSphere 5.5 GA (Build Number 1312298), replace the %WINDIR%\System32\idm.dll file on all systems running vCenter SSO 5.5 with the idm.dll file attached to this KB article.

Note: The attached idm.dll file is provided by VMware. It is tested and verified by VMware engineering. If you experience issues after replacing the dll file, contact VMware Technical Support.

To replace the idm.dll file on the Windows Server 2012 running SSO 5.5:

  1. Ensure that you are logged in as an administrator
  2. Stop the VMware Identity Management Service on the vCenter SSO server. For more information, see Stopping, starting, or restarting vCenter services (1003895).

    Note: This step also stops the VMware Secure Token Service.

  3. Back up the existing idm.dll by copying %WINDIR%\System32\idm.dll to %WINDIR%\System32\idm.dll.orig.
  4. Download the idm_patch09252013.zip attached to this article. It contains the replacement idm.dll.
  5. Run md5 checksum on the downloaded idm_patch09252013.zip. The md5 checksum should match the MD5 checksum in the note below.
  6. Decompress the zip file to a temporary location then copy the idm.dll to %WINDIR%\System32\.
  7. Confirm that you have both new (idm.dll) and old (idm.dll.orig) in the %WINDIR%\System32\ Directory.
  8. Start the VMware Secure Token Service on the vCenter SSO server. For more information, see Stopping, starting, or restarting vCenter services (1003895).x

    Note: This step also starts the VMware Identity Management Service.

After replacing the dll and restarting services, the initial AD login may take longer than normal to authenticate.
source : KB Vmware
vmware_vsphere

VMware vSphere web client – Error 1053: The service did not respond to the start or control request in a timely fashion

Was unable to start the VMware vSphere Web Client after upgrading from 5.1 to 5.5 (it’s same after restore a vcenter 5.5)

Noticed that the VMware Vsphere web client service wasn’t started.
Tried manually via Services.msc got the following error;
Windows could not start the VMware Vsphere web client service on local computer.
Error 1053: The service did not respond to the start or control request in a timely fashion.

Explanation

I realized that the folders in the new version installation had changed and for that reason paths should be changed also.

Resolution

Check your Registry value for hkey_local_machine\system\currentcontrolset\services\vspherewebclientsvc:

“C:\Program Files\VMware\Infrastructure\vSphereWebClient\server\bin\service\bin\wrapper.exe” -s “C:\Program Files\VMware\Infrastructure\vSphereWebClient\server\bin\service\conf\wrapper.conf” set.default.SERVER_HOME=C:\Program Files\VMware\Infrastructure\vSphereWebClient\server set.default.JMX_PORT=9875

Look at these value and confirm that the WRAPPER file is located and accessible on the path mentioned above.

Always backup your registry before making changes.

For me I had to change the port (see below) for it to work, for others I have seen it is due to the path being incorrect or inaccessible. (with quote because Program Files have a space in name)

“C:\Program Files\VMware\Infrastructure\vSphereWebClient\server\bin\service\bin\wrapper.exe” -s “C:\Program Files\VMware\Infrastructure\vSphereWebClient\server\bin\service\conf\wrapper.conf” set.default.SERVER_HOME= »C:\Program Files\VMware\Infrastructure\vSphereWebClient\server » set.default.JMX_PORT=9877

Restart the server.

source :https://payze.wordpress.com

 

vmware_vsphere