DavidServer Migration von Win2008R2 zu 2016

  • Ich hab das erst vor einer Weile gemacht.
    Ich verbinde solche Aktionen auch jeweils gleich mit Hardware- Aufrüstung oder Wechsel.
    In jedem Fall bewahre ich die alte Installation in Form der Datenträger auf und installiere das Betreibssystem vollständig neu.
    Dabei installiere ich das neue System so, das der David Server wieder alles beim alten vorfindet, Servername und IP-Adresse bleiben also gleich, ebenso bleibt der Installationsort des David Servers gleich.
    Den David Server installiere ich erst einmal mit genau der gleichen Version wie sie auf dem alten Server zuletzt lief neu und beende anschließend alle seine Dienste + den SQL Server Dienst.
    Anschließend kopiere ich das gesamte David Installationsverzeichnis von den alten Platten über die neue Installation.
    Manche machen das genau anders herum, allerdings hat es bei uns so immer funktioniert und entsprechend bleibe ich dabei.
    Am ende hab ich meinen David Server mit all seinen Daten wieder genau so am laufen wie er das vorher getan hat, nur auf der neuen Windows Server Version und gegebenenfalls auf neuer Hardware sowie generell auf neunen Datenträgern.

    Bei dieser Vorgehensweise würde sich auch Dein Problem mit der inzwischen zu kleinen Partition für die Archive lösen wenn Du die eben vor bzw. bei der Neuinstallation des Server ausreichend vergrößerst, so das nach dem kopieren der Daten wieder genug freier Platz vorhanden ist.

  • Meine letzte Migration war von einem Server 2008 (kein R2, also 32 bit, Rollout 256) auf einen aktuellen Server 2019 Std. mit DAVID.V3-310 , komplett mit neuer Domäne und entsprechend neuen/anderen Usern und z.T. 14 Jahre alten Emails. Das kann man dann nicht mehr so machen, wie es Riawie beschrieben hat (seine Methode funktioniert unter den o.a. Umständen aber sehr gut).


    Es gibt da viele Ansätze, die alle schon einmal hier im Forum angesprochen wurden. Ich möchte hier aber mal eine Lanze für die DAVID-Migration-Services brechen, die jeder TOBIT Reseller haben sollte/müsste. Das Tool ist zwar als unzuverlässig verschrien, es funktioniert aber auch bei mehreren hundert Gigabyte großen Datenbeständen sehr gut, wenn man ein paar Dinge berücksichtigt und entsprechende Vorarbeiten durchführt:


    - Alte Archives mit archivierten Ablagen sollte man so gut es geht zusammenfassen/packen (spart unglaublich Zeit bei der Migration, da nicht hunderttausende kleiner Dateien, sondern wenige gigabyte-große Files von A nach B kopiert werden müssen). Das gilt übrigens für jede Migration, ganz gleich nach welcher Methode.


    - Nach dem Packen sollte man prüfen, ob in den entsprechenden Verzeichnissen nicht noch irgendwelche "Dateileichen" liegen (ausser dem eigentlichen *.PCK-File und den ARCHIVE.*-Dateien). Den Schrott sollte man löschen.


    - In der DAVID.INI sollte man frühzeitig einen Eintrag "MSGMAILNAMES=", gefolgt von der eigenen Emailadresse machen. Man bekommt dann nach jeder nächtlichen Bereinigung eine Email mit angehängtem Report. Diesen Report sollte man auf Fehler prüfen und diese Fehler beseitigen, bevor man migriert. Meist handelt es sich um nicht mehr vorhandene Unterverzeichnisse in irgendwelchen Archiven. Am besten legt man die fehlenden Verzeichnisse auf Dateiebene einfach wieder mit dem Namen an, der im Report als fehlerhaft gemeldet wird. Sie erscheinen dann auch sofort wieder im Infocenter, wenn man auf das jeweilige Archive geht. Dort kann man das Verzeichnis dann auch wieder sofort löschen, dabei wird die ARCHIVE.DIR automatisch korrigiert. In nächsten Bereinigungsreport ist der Fehler dann meist nicht mehr vorhanden. So lange Fehler im Report sind, sollte man das Migration-Tool nicht verwenden.


    - Wenn noch Ordnerstrukturen von alten Mitarbeitern unter "Benutzer" zu finden sind, die vielleicht gar nicht mehr als aktive User im aktuellen DAVID vorhanden sind, sollte man sich überlegen, ob man deren Emails an dieser Stelle noch braucht. Falls nicht, dann kann man diese Ordner ja per Strongbox sichern und dann im Produktivsystem vor der Migration löschen. Wenn man die Emails noch im Produktivsystem braucht, dann legt man am besten einen neuen allgemeinen Ordner im Infocenter an (z.B. "Alte Emails"), dahinein dann Unterordner für die alten User oder einfach nur "Eingang" und "Ausgang" und dann kopiert man die Nachrichten dort hin. Hauptsache, die Daten sind nicht unter "Benutzer" zu finden, denn die Daten dort werden nur dann migriert, wenn auch ein aktiver Benutzer im Altsystem zugeordnet ist. Auf den Datenschutz gehe ich hier nicht ein - jeder Admin muss wissen, wie er mit Emails ausgeschiedener Mitarbeiter umgehen muss/soll.


    - Wenn im Grabbing-Server noch Einträge für POP3-Abholung sind, die sich im DvAdmin nicht löschen lassen, weil sie z.B. bei einem früheren User angelegt wurden, der User aber zwischenzeitlich gelöscht ist, dann sollte man diese im Info-Center unter SERVER\System\David\Grabbing Server löschen und den Grabbing-Server neu starten. Solche Altlasten können die Migration zum Absturz bringen, weil der dazu passende User nicht gefunden wird.


    Überhaupt sollte man im Produktivsystem alle Unstimmigkeiten vor der Migration beseitigen. Das gehört aber prinzipiell bei DAVID mit zur Systempflege und alles was hier aufgeführt ist, sollte unabhängig von einer fälligen Migration immer wieder geprüft und erledigt werden. Ihr habt mit Eurem DAVID dann auf Dauer wesentlich weniger Kopfschmerzen.


    Ist der Quellserver auf diese Art überprüft/vorbereitet, noch ein kurzer Blick auf den Zielserver: Hier muss man den DAVID einmal grundinstallieren. Es reicht prinzipiell, die Grundlizenz einzurichten und man kann dazu einfach die vorhandene Lizenz nehmen. Hauptsache ist, dass der DAVID dort erst mal mit seinen Diensten und der SQL-Datenbank läuft. Alle übrigen Einrichtungen kann man sich sparen. Die übrigen User- oder Portlizenzen werden bei der Migration automatisch mit übernommen.


    Dann kann es ans Migrieren gehen. Die letzte Checkliste schaut hier wie folgt aus:

    - Quell- und Zielserver sollten im selben Netzwerk/Subnetz sein

    - Quell- und Zielserver sollten sich gegenseitig "sehen" können, d.h. DNS sollte einwandfrei funktionieren. Mit Kommunikation über IP-Adressen solltet Ihr gar nicht erst anfangen.

    - Firewall und Virenscanner sollten auf beiden Servern für die Migration deaktiviert werden

    - Wer ganz sichergehen will: Man sollte schauen, ob man auf das DAVID-Verzeichnis des Quellservers vom Zielserver aus per Laufwerksmapping rankommt und dort Dateien lesen kann.


    Das Migration-Tool wird dann auf dem Zielserver (dem neuen Server) gestartet. Der Rest ist benutzergeführt. Wenn die Migration startet, kann man sich zurücklehnen und zuschauen. I.d.R läuft das Ding einfach durch, danach werden auf dem Zielserver die Dienste gestartet und das war's. Es gibt am Ende der Migration einen Bericht, den man eingehend überprüfen sollte. Sind Fehler aufgeführt, dann muss man diese einzeln abarbeiten und ggfs. korrigieren. Meist handelt es sich dabei aber um Unregelmässigkeiten im Datenbestand des alten Servers, die den normalen Betrieb bisher nicht gestört haben und die auf dem neuen Server jetzt nicht mehr vorhanden sind.


    Natürlich muss man dann noch ein paar Dinge anpassen (Firewall-Eintragungen, Portforwardings, ...). Evtl. muss auch der Port für den Webaccess/EAS angepasst werden, denn alle diese Dinge werden durch die Migration-Services komplett 1:1 übernommen. Die SQL-Datenbank läuft nach der Migration aber bereits (bei einem neuen DAVID V3 ist es dann der SQL 2017) und die Volltextsuche und der Chat gehen sofort und die alten Daten sind auch da.


    Sollten die Migration Services während der Migration abstürzen und man die Ursache nicht schnell finden können, dann ist es immer möglich, den DAVID auf dem alten Server einfach durch Neustarten der Dienste sofort wieder in Betrieb zu nehmen. Durch die Migration werden dort keinerlei Daten verändert. Bei einem Absturz gibt die Auswertung des bis dahin geschriebenen Log-Files meist wertvolle Hinweise auf die Ursache (wenn das Tool nicht aus Speichermangel o.ä. abgestürzt ist).


    Noch ein Wort zur Geschwindigkeit der Migration: Mit Robocopy geht das Kopieren natürlich schneller, dafür läuft der Server mit den Migration Services hinterher sofort und es muss nur noch wenig angepasst werden. Bei umfangreichen Servern (mehrere hundert Gigabyte) kann es natürlich auch mal 24h oder länger dauern, bis der Server wieder läuft. Ganz grob kann man von ca. 2,5h für 100 GByte DAVID-Datenbestand ausgehen. Das hängt aber entscheidend von der Geschwindigkeit des alten und des neuen Servers und deren Festplattensystemen ab.


    Wenn der Server nicht so lange Offline sein kann, dann muss man sich aber etwas anderes überlegen. Evtl. ist es dann günstiger, den neuen Server komplett manuell einzurichten und die Daten der User dann im Produktivbetrieb aus Strongbox-Images des alten Servers zuzuspielen. Das wird von den Usern meist akzeptiert.


    Einen Königsweg für die DAVID-Migration gibt es nicht. Je nach Situation, Umfang des Servers, ... gibt es verschiedene Wege, die hier ans Ziel führen. In jedem Fall muss man aufgrund der Datenstruktur von DAVID alleine für den Datentransfer vom alten Server einiges an Zeit einplanen.

  • Da ich auch gerade das Vergnügen mit dem Umstieg von 2008 zu 2019 hatte:


    Ich habe es über die Sicherung/Rücksicherung per Strongbox gelöst (auf dem alten Server war auch die aktuellste David-Version installiert), so dass ich den neuen Server bereits komplett vorinstallieren konnte. Bei einer überschaubaren Anzahl von Benutzern halte ich das für den schnellsten Weg.

    Vorteil war, dass ich mich nicht um die "Leichen" auf dem bestehenden David kümmern, sondern tatsächlich nur die aktiven Benutzer umziehen musste. Und da auf dem Server auch noch die Steuerung für eine CNC-Stanze lief, konnte ich die Ausfallzeit beim Umbau auf deutlich unter eine Stunde drücken. Hat den Kunden gefreut. ;)

  • Hab das vor 2 Monaten auch gemacht.

    2008 alte Hardware auf 2019 neuste Hardware.


    0) Sitecare aktivieren und die alte David 11 auf dem 2008 auf die neuste Version gebracht.


    1) Alles via Robocopy auf den neuen Server spiegeln. Kann sehr lange dauern, je nach Datenmenge.
    *hat den Vorteil, dass die Leute in Vorbereitung auf den Umzug weiterarbeiten können.

    Am Tag des Umzugs

    3) David Dienste beenden nochmal robocopy, um die Änderungen auszugleichen.
    (dauert dann nur ein paar Minuten)

    4) Alten Server vom Netz nehmen / Lan Kabel - falls was schiefgeht, ist er wieder erreichbar.

    5) Neuen Server selbe IP / selben Namen wie dem Alten geben.
    User in Windows exakt so anlegen wie bei dem alten Server

    6) Jetzt erst neuste Version von David installieren aber nix großartig konfigurieren


    7) Dienste beenden und mit dem kopierten Verzeichnis das gerade Installierte David überschreiben. Evt. Rechte anpassen.


    8) Weiterarbeiten ;-)


    *evt. müssen noch kleine Anpassungen mit dem SQL oder den Rechten gemacht werden.

    Und wie immer, alle Angaben ohne Gewähr :-)

  • Hallo,


    auch ich hab letztes Wochenende eine Migration von Server 2012R2 auf Server 2019 durchgeführt. Datenmenge ca. 350GB bei ca. 20 Usern. Ich hab das Migrationstool verwendet. Donnerstag Abend gestartet, am Freitag morgen ca. 9 Uhr war der Datentransfer erledigt. Dann waren noch ein paar Nacharbeiten nötig (Clients anpassen, Portweiterleitungen anpassen, etc.). Ansonsten läuft wieder alles wie zuvor.



    Grüße

    ag1