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
