Schlagwort: SSO

Veröffentlicht am

vSphere SSO 5.5: Passwort Ablauf

Dass die Kennwörter für SSO Benutzer ein Ablaufdatum haben, hattew ich bereits in einem früheren Artikel berichtet. Man konnte das Problem elegant umgehen indem man die Standard Ablaufzeit (365 Tage) auf Null setzte (= unbegrent).

Bug oder Feature?

Ich versuchte, diese Einstellung auf einem frisch aktualisierten vCenter Server (5.5.0a) und bekam bei jedem Versuch eine Fehlermeldung ohne Information. „vSphere SSO 5.5: Passwort Ablauf“ weiterlesen

Veröffentlicht am

vCenter 5.5 Upgrade

Das Upgrade oder Update von vCenter auf Version 5.1 war mit einigen Problemen verbunden. Ich berichtete dazu in älteren Beiträgen (vgl. Links).

Auch das Upgrade auf die neueste Version 5.5 ist nicht ganz unproblematisch.

Testumgebung

  • vCenter 5.1 (1235232) installiert
  • Windows Server 2012 Standard, Build 9200
  • Alle Dienste (SSO, vCenter, DB) auf einem System
  • self signed Certificate (default)

Simple Install mit 1603 Fehler

Fehlerquelle 1 – Zertifikat

Bei selbstsignierten Zertifikaten, die sich nicht auf eine offizielle Stammzertifizierungsstelle zurückführen lassen, erscheint im Setup diese Warnung.upgrade55-01
Es ist wichtig das Zertifikat auf Gültigkeit (Ablaufdatum) und den korrekten Hostnamen von vCenter zu überprüfen. am einfachsten geht dies mit einem Browser.

https://FQDN:7444/lookupservice/sdk

upgrade55-02Die Warnung ist in Ordnung, da das Zertifikat selbst signiert ist. Daher das Laden fortsetzen.

upgrade55-03Die Details sieht man, indem man auf “Zertifikate anzeigen” klickt. Es müssen zwei Dinge sichergestellt sein:

  1. Das Zertifikat ist nicht abgelaufen
  2. Es muss für den vollqualifizierten Namen (FQDN) des vCenter ausgestellt sein. Z.B. vc.mydomain.com

Registry

Der im Zertifikat hinterlegte FQDN muss ebenfalls in der Registry zu finden sein.

HKEY_LOCAL_MACHINE\Software\VMware, Inc.\VMware Infrastructure\SSOServer\

Im Key FqdnIp muss der vollständige Hostname hinterlegt sein. Im dargestellten Fall war der Key leer und damit die Ursache für ein gescheitertes Setup.

upgrade55-04Hier den FQDN des vCenter eintragen. Sollte hier eine IP Adresse registriert sein, so ist das lauf vmware KB auch eine mögliche Fehlerquelle. Was auch immer im Zertifikat steht, muss auch hier stehen!

upgrade55-05

 

  • Der Hostname lautet VC
  • Der FQDN lautet vc.mydomain.com
  • Die IP-Adresse lautet 192.168.1.35
  • Die Maschine gehört zu MYDOMAIN. Das Installationsprogramm verwendet den vorhandenen FQDN- IP-Wert aus der Registrierung: vc.mydomain.com

 Fehlerquelle 2 – Überbleibsel nach erfolglosem Upgradeversuch

Hatte man zuvor schon einen vergeblichen Upgradeversuch gestartet, so bleiben oft Verzeichnisse mit Updatedateien übrig. Für ein erfolgreiches Upgrade muss der gesamte CIS Ordner entfernt werden.

%ProgramData%\Vmware\CIS

Upgrade

Nach Bereinigung der Fehlerquellen 1 und 2 steht einem erfolgreichen Upgrade nichts mehr im Wege.

Links

Veröffentlicht am

VMware SSO Upgrade Error 1603

Tricky update

Der Updatevorgang von vCenter bietet einige Fallen. Insbesondere bei nicht-englischen Windows Versionen müssen besondere Vorbereitungen getroffen werden.

  • Single Signon (SSO) darf nicht über die GUI installiert werden. Ich berichtete darüber in einem früheren Beitrag: “vCenter Update Sequenz“
  • Die zum vCenter gehörenden Dienste müssen installiert und aktiv sein. So scheiterte eine Installation, weil die Komponenete “profile driven storage” nicht richtig installiert war.
  • Es gibt Probleme beim Update, wenn die Setupdateien als ISO in vCenter eingebunden werden. Die Setupdateien müssen entpackt, und in ein lokales Verzeichznis des vCenter kopiert werden.

Fehlerhaftes Rollback

Passiert eine Störung während der SSO Installation, so erscheint ein Fehler 1603 im Setup-Log und der Installer macht ein Rollback. In meinem Fall wurde der erste Upgradeversuch (5.1 -> 5.1 U1b) von einem ISO gestartet und scheiterte. Danach liess sich der vCenter Dienst und der Single-Signon Dienst nicht mehr starten. Erneute Updateversuche mit enpackten Setupdateien von lokalen Verzeichnissen scheiterten ebenfalls. Auch Reboot brachte keine Besserung. Nach intensiver Untersuchung der Setup-Logdatei und Recherche im Internet fand ich einen Blogartikel von Andrew Bruce (softwareAB) und einen VMware Artikel (KB2052738), die zur Lösung führten.

Während des Upgrades stoppt der Installer den SSO Dienst und verändert die  Namen einiger SSO Verzeichnisse auf vCenter, indem er einen 8-stelligen Hexcode an das Verzeichnis anhängt (Beispiel: \lib -> \lib.51a36cb4). Dies wird beim Rollback jedoch nicht wieder entfernt, so daß der SSO Dienst danach seine Programmverzeichnisse nicht mehr finden kann und daher nicht startet. Ohne SSO, kann auch der vCenter Dienst nicht starten und man endet in einer Sackgasse.

Rename to Default

Man kann das Problem lösen, indem man die Verzeichnisse wieder umbenennt und den Hexcode am Ordnernamen entfernt. VMware hat unter KB2052738 alle Verzeichnisse aufgelistet, die beim Setup verändert werden.

C:\Program Files\VMware\Infrastructure\SSOServer\lib
C:\Program Files\VMware\Infrastructure\SSOServer\thirdparty-license
C:\Program Files\VMware\Infrastructure\SSOServer\utils\lib
C:\Program Files\VMware\Infrastructure\SSOServer\utils\jars
C:\Program Files\VMware\Infrastructure\SSOServer\utils\bin\windows-x86
C:\Program Files\VMware\Infrastructure\SSOServer\utils\bin\windows-x86_64
C:\Program Files\VMware\Infrastructure\SSOServer\webapps\ims\WEB-INF\lib
C:\Program Files\VMware\Infrastructure\SSOServer\webapps\sso-adminserver\WEB-INF\lib

Entfernt man bei all diesen Verzeichnissen die Endung .aabbccdd (für einen zufälligen Hexcode), so lassen sich die Dienste wieder starten und das Update erneut (erfolgreich) durchführen.

Patrick von NerdThinking hat hierfür ein Powershell Script geschrieben. Ich habe dieses jedoch nicht getestet und bevorzuge in solchen Fällen die manuelle Ausführung. Benutzung auf eigenes Risiko!

Links