Artikel-Schlagworte: „vCenter“

Bei einem AD-integrierten vCenter kann man bekanntlich sehr schön vSphere-Privilegien auf Basis vorhandener AD-Benutzer vergeben – außer man bekommt gerade folgende Fehlermeldung vom vSphere Client gemeldet.

A general system error occurred: error accessing directory. Error stack: Call “UserDirectory.RetrieveUserGroups” for object “UserDirectory” on vCenter Server “VCENTER” failed

Dann nämlich kann der vCenter Dienst nicht mit seinem AD kommunizieren und Abhilfe muss her (vpxd.log sagt: “Vmomi.Fault.SystemError: A general system error occurred: error accessing directory” zu dem Problem).

Eine Frage von Service Accounts

In der VMware KB findet sich zur Fehlermeldung etwas zu Timeouts (nicht zielführend) und laut Support sollte das Umstellen auf einen Service-Account aus der Domäne helfen. Das stimmt prinzipiell, ganz so weit greifen muss man jedoch nicht – denn wahrscheinlich trat das Problem bis vor Kurzem noch nicht auf und einen dedizierten Domänen-Account hatte man auch noch keinen in Verwendung … aber ein vCenter 4.1 Upgrade wurde kürzlich durchgeführt.

Klingt bekannt? Falls ja, dann mal einen Blick in die Anmelde-Daten werfen, welche für vCenter und vCenter Web Service verwendet werden. Stehen diese auf “.\Administrator” sind die Kommunikations-Schwierigkeiten erklärt, denn der lokale Administrator hat keine Rechte aufs AD zuzugreifen. Hier schafft bereits das Korrigieren auf den “Local System Account” Abhilfe.

Nachdem die letzte halbe Stunde mit Grübeln vergangen ist, fällt es mir eben wie Schuppen von den Augen. Wovon ist die Rede? Migration eines vCenter von einem englischen W2K3 System auf ein deutsches W2K8 System. Danach konnten sich einige Admins noch anmelden, andere – und auch der lokale Administrator – jedoch nicht. Was war passiert?

Relativ simpel: Die vCenter Datenbank und damit auch die Berechtigungen aus VPX_ACCESS wurden übernommen. Damit kannte vCenter zwar wie gehabt die englische Gruppe ‘Administrators’ mit vollen Privilegien … die jedoch mit den deutschen ‘Administratoren’ auf dem neuen System relativ wenig zu tun hatte. Und ebendiese standen somit plötzlich ausgesperrt da. Nicht so weit her mit der Völkerverständigung, was?

Aus Englisch mach Deutsch

Zur Abhilfe in solch einem Fall also die deutsche Gruppe “Administratoren” mit Berechtigungen im vCenter ausstatten oder aber gleich nach vCenter Best Practices handeln und eine dedizierte Gruppe anlegen – mit der sich so ein Problem erst gar nicht ergibt. Im konkreten Fall gab es ein paar individuell mit Rechten ausgestattete Admins, die noch zugreifen und die Berechtigungen nachziehen konnten. Alternativ hätte auch manuelles Anpassen des Gruppennamens in VPX_ACCESS geholfen.

Typisches Szenario: vCenter 4.0 ist auf einem 32-Bit System installiert und das anstehende Upgrade auf 4.1 benötigt ein 64-Bit System, auf welches migriert werden muss. Fährt man dabei eine MS SQL Express 2005 Datenbank als Unterbau, kann man das Data Migration Tool nutzen, um die Migration durchzuführen. Außer man stolpert dabei über folgenden (wohl bekannten) Fehler.

[INFO] [INFO] Msg 8114, Level 16, State 1, Server VCENTER\SQLEXP_VIM, Line 1 Error converting data type bigint to int. Msg 3013, Level 16, State 1, Server VCENTER\SQLEXP_VIM, Line 1 RESTORE FILELIST is terminating abnormally.
[ERROR] Error: vCenter Server DB backup failed
[ERROR] Exiting…

Der genaue Verursacher ist unbekannt, das soll jedoch nicht stören, denn immerhin gibt es einen recht einfachen Workaround. Diesen Beitrag weiterlesen »