Beiträge

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

Veröffentlicht am

ESXi Config export error

Hin und wieder ist es notwendig, die Konfiguration eines ESXi Hosts zu exportieren. Zum Beispiel dann, wenn das Flashmedium getauscht werden muss. Das ist eine Standardprozedur, die in der Regel keine Probleme bereitet. Beim Versuch, die Konfiguration eines ESXi 5.0.0 Hosts zu sichern, der ein von IBM angepasstes Image hatte, scheiterte der Export und ich erhielt die Fehlermeldung:

Restore failed: A general system error occured: Internal error

Zunächst ist verwunderlich, daß hier „Restore faild“ steht, denn ich wollte die Konfiguration sichern. Der Rest der Fehlermeldung ist so vielsagend wie die „Allgemeine Schutzverletzung im Modul XYZ“, die wir als der PC Steinzeit noch kennen. 😉 „ESXi Config export error“ weiterlesen

Veröffentlicht am

SSO Identity hinzufügen und entfernen mit CLI

William Lam von virtuallyGhetto beschreibt in einem interessanten Artikel, wie man Single-Sign-on (SSO) Identitätsquellen per Commandline Interface (CLI) hinzufügt oder entfernt.

Wichtigstes Werkzeug ist das Tool rsautil, welches im unten gezeigten Verzeichnis zu finden ist.

..\Program Files\VMware\Infrastructure\SSOServer\utils

Hilfe erhält man mit dem Befehl:

rsautil manage-identity-sources

Für eine Domäne mydomain.com und einem Domaincontroller dc1.mydomain.com lautet der Befehl:

rsautil manage-identity-sources -a create -u admin -p <ssopassword> -r ldap://dc1.mydomain.com --ldap-port 3268 -d mydomain.com -l mydomain --principal-base-dn DC=mydomain,DC=com --group-base-dn DC=mydomain,DC=com -f "" -L administrator@mydomain.com

 Links

Veröffentlicht am

Troubleshooting: LUN nach crash verloren

Nach einem heftigen LAN Ausfall war ein ESX Cluster in einem nicht administrierbaren Zustand und musste neu gestartet werden. Einige der VMs blieben jedoch unerreichbar. Bei näherer Betrachtung konnte man sehen, daß eine Storage LUN nicht mehr vorhanden war.

Die Umgebung

  • VMware vSphere 5.1 U1
  • Storage: Datacore SANsymphony-V 9 mit Frontend, Backend und Mirror über Fibrechannel

„Troubleshooting: LUN nach crash verloren“ weiterlesen