In einem aktuellen Kundenprojekt durfte ich eine Neuinstallation des Veeam Recovery Orchestrator (VRO) durchführen.
Die Installation selbst verlief zunächst völlig unauffällig – allerdings auf einem deutschsprachigen Windows Server Betriebssystem, was sich später noch als entscheidender Faktor herausstellen sollte.
Direkt nach der Installation wurde im Onboarding‑Wizard die lokale Administratorengruppe für den Zugriff auf das VRO-System berechtigt. So weit, so gut. Dachten wir! Das Ergebnis: Kein Benutzer, der Mitglied der lokalen Administratoren-Gruppe war, konnte sich anschließend am VRO-System anmelden.
Fehlermeldung: Access denied for the user „User-within-local-Administrators-Group“: the provided credentials are invalid or the user has insufficient privileges.
Damit waren wir direkt nach der Installation ausgesperrt.
Troubleshooting: Blick hinter die Kulissen
Nach kurzer Analyse war klar: Über die Web-UI kommen wir an dieser Stelle nicht weiter. Wir haben uns somit kurzerhand dazu entschlossen, einen gezielten Blick in die SQL‑Datenbank von VRO zu werfen.
Wichtiger Hinweis ⚠️
Achtung! Direkte Änderungen an der VRO‑Datenbank sollten immer mit äußerster Vorsicht durchgeführt werden! Ich möchte ganz klar betonen, dass dies kein offiziell dokumentierter oder supporteter Ansatz ist, sondern eine Troubleshooting‑Maßnahme auf eigene Verantwortung.
- es handelt sich hier um keinen offiziell supporteten Lösungsweg
- ein Backup der Datenbank vor jeder Änderung absolut Pflicht
- Nur durchführen, wenn klar ist, was geändert wird
- Im Zweifel immer: Veeam Support kontaktieren
In diesem speziellen Fall war es jedoch der schnellste und effektivste Weg, um das System wieder produktiv nutzbar zu machen.
Da es sich um ein frisches System handelte, galt die Devise – from Scratch zu beginnen dauert länger, wir können nicht mehr kaputt machen, als das wir das System nicht mehr verwenden können 😊
Analyse und Modifikation auf Datenbank-Ebene
In der VRO‑Datenbank haben wir geprüft, welche Benutzer bzw. Gruppen intern als berechtigt hinterlegt sind. Dabei fiel auf, dass die lokale Administratorengruppe zwar korrekt in den Tabellen gelistet war, aber aus irgendwelchen Gründen nicht korrekt aufgelöst bzw. interpretiert wurde.
Wir haben daraufhin die vorhandenen Einträge in der entsprechenden Tabelle VeeamAA.Account ausgelesen und um einen expliziten Benutzer ergänzt, in diesem Beispiel mit dem User veeam-administrator.
Via whoami /user in der PowerShell kann die entsprechende SID des Benutzer ausgelesen werden.
Und via New-Guid erzeugt uns das Systeme einen neuen Globally Unique Identifier.
Zurück im SQL Management Studio in der Tabelle VeeamAA.Account wurde im Edit Mode der User veeam-administrator mit seiner entsprechenden SID hinterlegt und der eben erzeugten Guid. Als Type muss für einen User eine 1 eingetragen werden (Ich konnte das kurzfristig in meinem Lab auslesen).
Danach folgten die Klassiker: Neustart der SQL und VRO‑Dienste, besser noch, direkt ein Neustart des gesamten VRO-Systems…
Anschließend folgte ein erneuter Login‑Versuch: Der Zugriff auf die Web UI war somit wieder möglich – Mission accomplished.
Bonus: Direktes Feedback aus dem VRO‑Produktmanagement
Da mir dieses Verhalten keine Ruhe gelassen hat, war ich kurzerhand so dreist, mich direkt via Tams-Chat bei Alec King (Vice President Product Management bei Veeam für den Recovery Orchestrator) zu melden – während wir schon mit dem SQL Management Studio beschäftigt waren. Zu meiner Verteidigung: Ich hatte immer wieder mal Kontakt zu Ihm bzgl. diversen Orchestrator Topics.
Mein Ziel war das Verhalten zu schildern bzw. ggfs. die Info zu erhalten, ob dies so bereits bekannt/adressiert ist. Aber auch, ob es die Möglichkeit gibt, das System kurzfristig (ohne erneute Installation, die beim VRO schon mal gut mehr als eine Stunde dauern kann) auf Auslieferungszustand zurückzusetzen.
Alec hatte zu Beginn so kurzfristig keine Möglichkeit gesehen, uns zu entsperren, daher hatten wir uns an der o.g. SQL-Thematik beholfen.
Später im Verlauf unseres Chats musste ich schmunzeln, als ich mitteilen konnte, der Zugriff ist wieder gegeben:
Alec:
So you just hacked the database and changed the entry to a specific user??Ich:
Yes.Alec:
You get the crown. 👑…
Alec: OK, let me dig into the German OS issue then, and get back to you. Hope your customer is OK that they have a workaround now
Ich: yes, we can proceed protecting the world by VRO 😄
Alec hat mir ein paar Stunden später noch einen Befehl gesendet, der kurzerhand die Datenbank in den Auslieferungszustand versetzen kann:
C:\Program Files\Veeam\Orchestrator\Server> .\Veeam.AA.Server.exe --create-databaseAlec: that will reset everything and you should be able to log in (as the setup user). However any other config will be DESTROYED, it will wipe the server!
So use with care and have fun 😅
Und abschließend die Info: Ein Bugfix ist bereits in der Entwicklung 😉