Migration von Depots in Version 15
Hallo zusammen,
wir führen in unserer Organisation gerade eine Migration von Version 8 auf Version 15 durch. Ihre FAQs zu dem Thema waren bisher sehr hilfreich! Großes Lob an dieser Stelle, die Dokumentationen sind super.
Wir hatten ein Testszenario durchgespielt um den Server 15 zu testen und die neuen Funktionen einzurichten. Dazu ist zu sagen: Der neue Server (Windows Server 2019 64Gb) ist ein separates System vom alten Server. Die initiale Migration hat auch reibungslos funktioniert. Der Stand der Depots war natürlich nun veraltet, da wir das ältere System aktiv im Einsatz haben. Es wurden in der Zwischenzeit noch einige Benutzeraccounts bereinigt und Depots bearbeitet.
Der nächste Test war nun die aktuellen Versionen der (.psw8) Depots zu migrieren. Hintergrund war: Zum Migrationszeitpunkt wäre es sehr viel einfacher und schneller nur die Depots und Benutzerdaten zu migrieren, anstatt den gesamten Server neu zu installieren und einzurichten. Der Test schlug fehl. Die Depots waren weiterhin in .psw8 Format.
Folgende Variationen wurden probiert:
1. Nur psw8-Depots in den Depot-Ordner des neuen Servers schieben
2. config-Datei plus Depots an die vorgegebenen Stellen schieben (Migration "light" ohne Neuinstallation des Password Depot Server 15)
3. Löschen aller User und Depots in der Server Applikation (Abgesehen vom Admin-Account), dann wie Punkt 2.
In allen Testversuchen war der Dienst des Servers angehalten und später neu gestartet worden.
Schließlich endeten die Versuche leider damit, dass der Password Depot Server neu installiert werden musste. Auch die Neuinstallationen liefen nicht ohne Tücken ab. Manchmal erlaubt der Server eine Migration von Depots die im designierten Ordner auf D:\ liegen, manchmal wollte der Server die Migration der Depots garnicht oder nur aus dem \DB\ Ordner machen und die Depots mussten bei angehaltenem Dienst an die richtige Stelle nach D:\ kopiert werden.
Alles sehr kurios.
Fragen:
1. Kann man einfach die Depots nachträglich migrieren nachdem man die Konfiguration des neuen Servers vorgenommen hat? (betrifft natürlich nur die "neuen" Funktionen, die Konfiguration vom alten Server wird ja soweit aus der config-Datei übernommen)
2. Was machen wir falsch? Mir scheint als hätten sich Fehler eingeschlichen die man zum Migrationszeitpunkt vermeiden kann.
Sorry, das war ein langer Text!
Vielen Dank schonmal für die Antwort!
Liebe Grüße
Comments
Guten Tag Frau Rottscheidt!
Zunächst einmal vielen Dank für Ihr Feedback zu unserer Dokumentation. Wir freuen uns sehr, wenn Ihnen diese weiterhelfen kann.
Gerne gehen wir auf Ihre Fragen ein, haben diesbezüglich aber noch ein paar Rückfragen, da wir das Problem anhand Ihrer Beschreibung leider nicht genau nachvollziehen konnten.
1. Wenn Sie schreiben, dass die Migration initial reibungslos funktioniert hat, wie genau sind Sie dabei vorgegangen? Haben Sie sich an unsere Migrationsanleitung gehalten? Was genau haben Sie dabei migriert?
2. Wenn Sie schreiben, dass der Stand der Depots veraltet ist, was genau meinen Sie damit? Wenn Sie Datenbanken von einer älteren Version in eine neuere übernehmen, dann werden diese genau mit dem Stand übernommen, mit dem Sie in der Vorgängerversion liefen. Neue Funktionen etc. werden hier nicht automatisch eingefügt.
3. Normalerweise konvertiert Password Depot Enterprise Server während der Migration ältere Datenbanken im *.psw8-Format etc. automatisch in das aktuelle und universelle Datenbankformat *.pswe. Sollte dies nicht erfolgen, so müssten Sie dies über einen Workaround eventuell manuell tun. Allerdings verstehen wir leider nicht ganz, warum Sie die Datenbanken erstmal weiterhin im Datenbankformat *.psw8 verwenden, anpassen und dann erst abschließend korrekt migrieren möchten? Dieser Vorgang wird so von uns nicht empfohlen bzw. getestet.
4. Grundsätzlich umfasst die Migration des Enterprise Servers auf eine neue Hauptversion (zusammengefasst) folgende Schritte:
a) Installieren des Enterprise Servers in der neuen Version (zwingend erforderlich).
b) Einrichten des gleichen Administrator-Kennworts wie in der Vorgängerversion.
c) Dienste beenden (sowohl des alten als auch des neuen Servers bzw. die Dienste beider Hauptversionen).
d) Kopieren aller Datenbanken.
e) Kopieren der cfg-Datei für die Übernahme der Benutzer & Einstellungen.
f) Starten des neuen Servers bzw. Server-Dienstes.
g) Bei Bedarf eine AD-Synchronisation, sofern der SSO-Login verwendet wird.
5. Ein Löschen der alten bzw. bisherigen Benutzer bis auf den Super-Admin (der auch nicht gelöscht werden kann) ist dabei grundsätzlich nicht erforderlich. Damit machen Sie sich im Grunde auch nur mehr Mühe, da bei Neu-Installation des Enterprise Servers ohnehin die Default-Einstellungen verwendet werden und keine Benutzer angelegt sind. Somit könnten Sie diese dann auf dem neuen Server gleich ganz neu anlegen, ohne dabei die cfg-Datei überhaupt zu kopieren.
6. Grundsätzlich können Sie die Verzeichnisse zum Abspeichern von Datenbanken und Sicherungsdateien in Password Depot Enterprise Server auch ändern - dann ist bei der Migration zu beachten, dass die Dateien (Datenbanken und cfg-Datei) in die entsprechenden Verzeichnisse kopiert werden. Wir empfehlen Ihnen, hierfür grundsätzlich lokale Netzwerke zu verwenden und sicherzustellen, dass der SYSTEM Account Vollzugriff auf diese Verzeichnisse hat.
7. Die Migration des Enterprise Servers ist grundsätzlich ein manueller Vorgang. Was meinen Sie damit, dass die Datenbanken an die richtige Stelle kopiert werden mussten?
8. Mit "Depots" meinen Sie die Datenbanken, korrekt? Diese können Sie auch nach dem Setzen neuer Einstellungen migrieren. Bei sehr großen Versionssprüngen, wie es bei Ihnen der Fall ist, gibt es natürlich zwischen den beiden Hauptversionen sehr viele Unterschiede. Daher ist gegebenenfalls, gerade was die Rechteverwaltung etc. betrifft, im Nachhinein noch einiges abzuändern bzw. anders einzustellen, was leider nicht automatisiert erfolgen kann, sondern manuell erledigt werden muss.
9. Was genau während der Migration nun schief gelaufen ist, können wir Ihnen mit den bisherigen Informationen leider nicht sagen. Bei der Migration des Enterprise Servers empfehlen wir Ihnen, sich stets streng an die Schritte unserer Anleitung zu halten. Eventuell hängt das Problem mit dem Gesamtvorgang zusammen, da Sie die Migration, sofern wir das korrekt verstanden haben, in zwei verschiedenen Schritten mit jeweils unterschiedlichen Änderungen durchgeführt haben.
Helfen Ihnen diese Angaben weiter?
Hallo Frau Andritsos,
vielen Dank für Ihre schnelle Antwort!
Im Grunde versuche ich nur heraus zu bekommen, ob Datenbanken auch nachträglich migriert werden können, nachdem die Funktionen des Servers eingestellt wurden.
Ich versuche einmal die Situation so genau wie möglich darzustellen und entschuldige mich an dieser Stelle schon mal für den furchtbar langen Text der folgen wird.
Anmerkung zu Punk 8.: Sie haben natürlich völlig Recht, mit „Depots“ meine ich „Datenbanken“. Das hatte sich ein wenig eingebrannt, da wir die Version 8 nun schon so lange nutzen. Entschuldigung, falls das zu Verwirrungen geführt hat!
Ist-Zustand:
Aktuell haben wir einen alten (virtualisierten) Server im Einsatz auf dem der Password Depot Server 8 läuft. Dieser soll in nächster Zeit abgeschaltet werden. Nun haben wir einen neuen virtuellen Windows 2019 Server bekommen, auf dem der Password Depot 15 Server laufen soll.
Der Password Depot Server 8 ist natürlich ein "lebendes" Produktivsystem. Er wird jeden Tag von mehreren Hundert Usern benutzt. Also wurde entschieden, den Password Depot Server 15 auf dem neuen Windows Server erst einmal zu testen, damit zum letztendlichen Migrationszeitpunkt alles reibungslos laufen kann. Die Migration selbst soll im besten Fall nicht länger als einige Stunden dauern, damit der Betrieb nicht stehen bleibt.
Es lief folgendermaßen ab:
Die neue virtuelle Maschine war zu diesem Zeitpunkt noch „jungfräulich“, d.h. gerade frisch von unserer Serverbereitstellung ausgerollt.
-Password Depot Server 15 wurde als Systemdienst installiert (Version 15.2.1)
-Im Server Manager 15 wurde ein Speicherort für die Datenbanken und Backups festgelegt (entsprechende Verzeichnisse auf D:\)
-Danach wurde die Migrationsanleitung befolgt wie sie in Ihren FAQs steht.
-Änderung des Passwortes vom Admin Account
-Server 15 Dienst anhalten
-Kopie der pwd_srv.cfg vom alten Server nach \Password Depot Server 15\Data auf dem neuen System (pdserver.ini wurde NICHT vom alten auf das neue System kopiert, da die gewünschten Verzeichnisse bereits eingestellt waren)
-Kopie der Datenbanken vom alten System nach D:\PasswordDepot15_Dateien auf dem neuen Server
-Start des Password Depot 15 Server Dienstes
Nachdem der Dienst gestartet war, konnte man im Ordner sehen, wie alle Dateien vom .psw8-Format in das .pswe-Format wechselten. Das war ein Indikator für mich, dass es funktioniert hatte.
Danach folgend noch einige Einstellungen und Tests von den Kollegen und mir (u.a. LDAP-Synchronisationen, Client-Sicherheitsrichtlinen, etc.) Es schien alles soweit zu funktionieren.
In der Zwischenzeit lief der Betrieb auf dem Produktivsystem natürlich weiter. Dann kam von den Kollegen die Frage auf, ob man denn auch eine Migration „nur von den Depots/Datenbanken“ durchführen kann, um eine Neuinstallation des ganzen Server-Gebildes zu vermeiden.
Gesagt, getan.
-Server 15 Dienst angehalten
-.pswe-Datenbanken aus Ordner gelöscht
-Kopie der aktuellen pwd_srv.cfg und .psw8-Datenbanken vom alten Server auf den neuen, wieder in die vorgesehenen Verzeichnisse
-Server 15 Dienst gestartet
Dieses Mal blieb die Konvertierung der Dateien von .psw8 in .pswe aus. Im Server Manger sah man, dass die Datenbanken nach wie vor im .pswe-Format angezeigt wurden. Wenn man versucht hat auf eine der Datenbanken zu klicken kam eine Fehlermeldung, der Pfad der Datei könne nicht gefunden werden (völlig klar, ich hatte diese Dateien ja gelöscht).
Was daran natürlich eigenartig war, ist die Tatsache, dass ich die Konfigurations-Datei geändert habe und im Manager trotzdem noch die Anzeige bekam wie sie mit der „ursprünglichen“ .cfg ausgegeben wurden.
Neustarts des Dienstes und der ganzen virtuellen Maschine brachten keine Änderung.
Es wurde noch ein paar Mal probiert die Datenbanken und .cfg zu kopieren bei denen es bereits einmal funktioniert hatte, leider ohne Erfolg. Danach bin ich noch einmal hingegangen und habe beim Server Manager die Benutzer bis auf den admin und alle Datenbanken gelöscht (im Server Manager, nicht im Verzeichnis selber), in der Hoffnung, es würde dann mit der neuen .cfg und Dateien-Kombination wieder funktionieren. Leider blieb auch das ohne Erfolg.
Schließlich habe ich den Password Depot Server 15 neu installiert.
Ich habe den Server bisher mehrfach neu installiert, da sich das Programm nicht mehr so verhält wie es bei der ersten Installation der Fall war. Es hat einige Versuchte gebraucht bis ich einen Weg gefunden habe wie sich die Datenbanken überhaupt noch migrieren lassen.
Auch nach kompletter Deinstallation (Löschen von allen Ordnern die nach der Deinstallation übriggeblieben waren und Löschung der Registry Einträge) lassen sich die Datenbanken nur aus dem \DB\ Ordner migrieren und müssen anschließend händisch an den gewünschten Ort kopiert werden.
Ich hoffe diese Ausführungen helfen bei der Fehleranalyse.
Liebe Grüße
Guten Tag Frau Rottscheid,
vielen Dank für Ihre ausführliche Rückmeldung und die zusätzlichen Informationen!
Wir konnten Ihr Anliegen nun besser verstehen und möchten versuchen, darauf nochmal detailliert einzugehen.
1. Grundsätzlich ist es so, dass Sie die Datenbanken und auch die cfg-Datei zu jeder Zeit kopieren oder migrieren können - dabei spielt es keine Rolle, ob vorher bereits mal eine Migration stattgefunden hat oder nicht, sondern indem Sie die aktualisierten Datenbanken von der Vorgängerversion auf das neue System kopieren, werden die dort existierenden Datenbanken grundsätzlich überschrieben.
2. Da Sie allerdings einen etwas größeren Versionssprung vornehmen und es hier auch einen Wechsel beim Datenbankformat gab, kann sich der gesamte Prozess etwas schwieriger gestalten.
3. Anhand Ihrer ersten Beschreibung lief die Migration anfangs auch korrekt ab. Wenn Sie sehen konnten, dass Password Depot Enterprise Server eigenständig und automatisch beim Kopieren der Datenbanken das Datenbankformat von *.psw8 zu *.pswe konvertiert hat, dann ist hier alles richtig verlaufen und die Datenbanken wurden korrekt übernommen. Im Prinzip haben Sie dann in einem ersten Schritt die Migration korrekt vollzogen und abgeschlossen.
4. Natürlich ist es nun so, dass gerade bei vielen Benutzern der gesamte Migrationsprozess (und bis alle Benutzer die Version gewechselt haben) etwas dauern kann und man eine Zeit lang auch noch mit dem alten System bzw. parallel mit beiden Systemen arbeiten muss. Dies ist grundsätzlich so erstmal möglich.
5. Bitte beachten Sie, dass die pwd_srv.cfg-Datei nur Ihre Benutzer und Einstellungen enthält und mit den eigentlichen Datenbanken so erstmal nichts zu tun hat. Das heißt also, wenn Sie nach Kopieren der cfg-Datei in Password Depot 8 keine Änderungen mehr ausgeführt haben was die Einstellungen und Benutzer betrifft, so macht es im Grunde keinen Sinn, die cfg-Datei "nochmal" zu migrieren, denn diese Einstellungen wurden ja alle bereits bei der ersten Migration korrekt übernommen.
6. Anhand Ihrer Beschreibung ist beim zweiten Kopiervorgang bzw. bei der zweiten "Migration" der Vorgang nicht korrekt abgelaufen. Bitte beachten Sie, dass dabei immer die Server-Dienste BEIDER Hauptversionen (in Ihrem Fall also sowohl der Server-Dienst der Version 8 als auch der neuen Version 15) gestoppt sein müssen, bevor der Migrationsvorgang bzw. das Kopieren der Dateien gestartet werden kann. Wenn der Server-Dienst der Version 8 hier lief und nur der Dienst der neuen Version 15 gestoppt war, dann hängt das Problem vermutlich damit zusammen. Die Migration kann nur korrekt erfolgen, wenn die Dienste beider Hauptversionen gestoppt sind. Können Sie dies bitte einmal überprüfen? Ihre Fehlerbeschreibung spricht auch hierfür.
7. Grundsätzlich ist es nicht erforderlich, dass Sie bereits getätigte Einstellungen auf dem neuen System nochmal komplett löschen, um dann die Migration erneut durchzuführen.
8. Wenn Sie sagen, dass sich das System nach mehrfacher Neu-Installation nicht mehr so verhalten hat wie am Anfang, was genau meinen Sie damit? Gab es Fehler während der Installation oder welche Fehler konnten Sie hierbei beobachten?
9. Gerne möchten wir Ihnen außerdem anbieten, über folgenden Link eine TeamViewer-Sitzung bei uns zu buchen:
https://www.password-depot.de/support/premium-support.htm
Diese sind für Sie kostenlos und wir könnten dann auch nochmal gemeinsam auf das Problem schauen.
Helfen Ihnen diese Angaben weiter?
Hallo Frau Andritsos,
danke für Ihre ausführlichen Erklärungen!
Es war in der Tat so, dass ich den 8er Server nicht angehalten hatte um die Migrationen durchzuführen. Die Dateien wurden direkt aus den Verzeichnissen des laufenden Servers kopiert.
Ich habe in der Zwischenzeit noch einmal eine Migration mit Hilfe Ihrer Hinweise ausprobiert. Leider hat das nicht funktioniert.
Der Server 8 wurde kurzzeitig angehalten um die Dateien (.cfg und Datenbanken) zu kopieren und auf dem anderen Server eine Migration durchzuführen.
Anhand der Hinweise aus 5. und 6. Hatte ich zunächst einfach die psw8-Dateien in den Datenbank-Ordner kopiert (die vorhandenen .pswe-Datenbanken wurden vorher an eine andere Stelle kopiert, sodass der Ordner leer war), um zu sehen ob der Server eine erneute Migration der Datenbanken durchführt. Das war leider nicht der Fall. Im Servermanager wurden die Datenbanken noch angezeigt, als seien die .pswe-Dateien noch vorhanden. Auch nach einigen Stunden wurden die Datenbanken nicht in das neue Dateiformat migriert.
Danach habe ich noch einmal eine „komplette“ Migration (.cfg und Datenbanken) ausprobiert, leider ebenfalls ohne Erfolg.
Ich werde nun eine Support-Sitzung buchen um dem Problem besser auf den Grund gehen zu können.
Vielen lieben Dank für Ihre Hilfe! Ihre Hinweise waren sehr hilfreich für das Verständnis und die Fehleranalyse.
Liebe Grüße
Hallo Frau Rottscheidt,
vielen Dank für Ihre Rückmeldung!
Es tut uns leid, zu hören, dass die weiteren Schritte das Problem bisher nicht lösen konnten. Gerne können Sie eine TeamViewer-Sitzung buchen, damit wir so die Fehlerquelle besser eingrenzen bzw. ermitteln können.
Please sign in to leave a comment.