Gelöst: Serverumzug 2012R2->2022 - DATEV-Community

Steran · ‎08.11.2023

Liebe Community!

Wir sind etwas spät dran mit dem Umzug unseres Datev von einem 2012R2 auf 2022, wollen diese jetzt aber endlich in Angriff nehmen.

Wir verwenden keine Terminalserver sondern haben die Software in Client/Server manier installiert.

Ein inPlace Upgrade werden wir nicht durchführen - da nicht empfehlenswert. Der 2022er ist bereits installiert und hängt im Netzwerk.

Wir würden uns an folgender Dokumentation orientiert:

https://apps.datev.de/help-center/documents/1011814

Hier wird dann ja auf die grundlegende Serverinstallation als Voraussetzung verlinkt.

Dabei sind uns 2 Schritte noch nicht ganz klar:

auf dem alten 2012R2 haben wir noch nicht die neueste Datev Version, da sich diese ja nicht mehr installieren lässt. Wie ist in diesem Fall vorzugehen bzw. was ist am praktikabelsten?
Müssen wir am neuen Server erstmal noch die alte Datev Version installieren, oder kann gleich die neueste verwendet werden?
Wenn wir die Neuste Version installieren werden die Clients in diesem Zuge wahrscheinlich auch gleich geupdated, oder? Somit hätten wir keinen Fallback mehr, wenn bei der Installation was schief geht, da auf den Clients ja die neue Version ist, auf den alten Server noch die alte.
Wie kommen die Daten in den neuen Server?
Der Umzugsassitent migriert ja nur die Datenpfade auf den neuen Servernamen, wenn ich das richtig gelesen habe?

Danke für Eure Tipps!

metalposaunist · ‎09.11.2023

@Steran schrieb:
Müssen wir am neuen Server erstmal noch die alte Datev Version installieren, oder kann gleich die neueste verwendet werden?

Es kann gleich die aktuellste Version installiert werden, wenn die Differenz nicht zu groß ist, sodass nach der Installation der neusten Version die SQL Skripte zur Anpassung der SQL-Datenbanken vor die Wand fahren, weil Zwischenversionen fehlen. Ist hier schon vorgekommen. Das muss man vorher prüfen, wie groß die Versionsdifferenz ist.

DATEV sagt offiziell (ich meine seit 2J), dass das Jahreswechsel-Update Voraussetzung für die neue DVD im August ist. Ob man der Aussage zu 100% vertraut - bin mir da unsicher und am besten ist es, wenn man DATEV im Rhythmus von 4W dauerhaft auf Stand hält.

@Steran schrieb:
Wenn wir die Neuste Version installieren werden die Clients in diesem Zuge wahrscheinlich auch gleich geupdated, oder?

Das kann man trennen und nur den DATEV SQL-Server damit installieren. Läuft der einwandfrei durch, muss man alle Clients dann nachziehen, damit DATEV wieder läuft, weil die Clients dann andere SQL-Datenbanken erwarten als am Server vorhanden.

@Steran schrieb:
Wie kommen die Daten in den neuen Server?

Wir haben dazu von 2014 bis 2017 bei der DO-net GmbH ein robocopy Skript genutzt, dass den WINDVSW1 Ordner 1:1 inkl. NTFS-Berechtigungen von A nach B kopiert und am Ende auch protokolliert: alles einwandfrei. Bei sehr großen Kanzleien kann das schon mal sehr lange dauern, je nach dem wie groß das Verzeichnis ist und wie die Server verbunden sind und welche Storage-Technologie als Basis zum Einsatz kommt. Bis 2017 waren das oftmals SAS 15k Festplatten. Heute ist's wohl eher SSD mit entsprechender Power. 2019 beim Systemhaus Cramer erzielten wir mit SSDs ca. 2GBs - das rockte schon sehr 😎.

Viel Erfolg 🍀!

#EmpoweringPeopleInTechnology – Daniel Bohle
www.metalposaunist.de

glasi · ‎09.11.2023

Wir haben Anfang Oktober von 2012 auf 2022 umgestellt (File-, Terminalserver). Zuerst hat unser EDV Betreuer auf Server2019 upgedated und dann auf 2022. (von Freitag auf Samstags in einem Rutsch) Danach habe ich Samstags die Datev Updates gemacht, lief alles ohne Probleme.

agmü · ‎09.11.2023

Ich ziehe den Server nach diesem Dokument um

Server umziehen ohne Server-Anpassungs-Assistent - DATEV Hilfe-Center

Andreas G. Müller
wir leben in spannenden Zeiten

d_z_ · ‎09.11.2023

@glasi

Direkt als Inplace Update? Ich bin bei einem 2016 FS am überlegen...

glasi · ‎09.11.2023

Ja hat unser EDV Betreuer gemacht. Hat er vorher getestet (sind ja virtuelle Maschinen)

Steran · ‎09.11.2023

Danke für Eure Antworten!

Ein inPlace Upgrade habe ich jetzt mal außer Betracht gezogen, da sich auf dem bisherigen Server schon ein bisschen Müll u.a. alte SQL Server Versionen aus vorherigen Datev Versionen angesammelt haben.

Wäre aber wahrscheinlich das einfachste 🙂

Installiert ist Datev Version 16 - d.h. die Migration der Daten auf 17. sollten kein Problem sein.

Hier habe ich aber doch noch ein Verständnisproblem:

Da sich der Servername ändern wird, werde ich die Version mit dem Serverumzugsassistenten verwenden.
Ich installiere also im ersten Schritt den neuen Server -> bereits erledigt.
Installiere dort die Datev Plattform Version 17
Kopiere dann die Daten vom alten Server (Datev-Freigabe inkl. NTFS Berechtigungen) auf die Datev-Freigabe des neuen Servers.

Ist das korrekt?
Wenn ja, wie kommt es dann zur Datenmigration? Passiert das automatisch beim Start des ersten Clients, oder muss ich das manuell anstoßen?

Ich kenne es aus den Updateinstallationen immer so, dass zuerst der Server aktualisiert wird, dann die Clients und innerhalb der Updateroutine wird am Ende automatisch der SQL Server angepasst...

metalposaunist · ‎09.11.2023

@Steran schrieb:
Ist das korrekt?

Nein. Unbedingt vor der DATEV Plattforminstallation das WINDVSW1 Laufwerk 1:1 kopieren und am neuen Server entsprechend der Vorgaben freigeben und als L: am Server mappen. Nur so erkennt DATEV, dass man nicht bei 0 starten, sondern vorhandene SQL Datenbanken übernehmen will.

Andernfalls installierst Du DATEV frisch mit 0 Inhalt und DATEV legt, weil keine SQL Datenbanken erkannt werden, frische, leere, neue Datenbanken kann und dann hat man den Salat, weil man dann die Datenbanken nicht mal eben so austauschen kann.

@Steran schrieb:
Passiert das automatisch beim Start des ersten Clients, oder muss ich das manuell anstoßen?

Die SQL Datenbanken können nur dort angepasst / aktualisiert werden, wo auch alle Programme installiert sind. Installierst Du einen reinen DATEV-SQL-Server ohne Programme, kannst Du am Server auch keine SQL Datenbank für z.B. Rechnungswesen oder Lohn anpassen. Das müsste dann an einem Client mit allen DATEV Programmen stattfinden.

Deshalb - rein aus Zeitgründen - bin ich der Meinung, dass man auch den SQL-Server mit allen Programmen ausstattet, weil man dann bei einem DATEV Update dort anfängt und wenn die Programme dort aktuell sind, man die SQL Datenanpassung am Server starten kann, während gleichzeitig alle Clients mit den aktuellen Programmen versorgt werden, sodass man im besten Falle mit der Anpassung der SQL Datenbanken fertig ist, wenn auch die Clients fertig sind, sodass wieder gearbeitet werden kann. Andernfalls müsste man immer auf 1 Client warten, bis dort alle Programme aktuell sind und kann danach erst mit der Datenanpassung starten.

Im DATEV und PARTNERasp inkl. Citrix und Golden Images kann man das allerdings technisch wieder anders machen. Das kommt ganz drauf an, was man technisch im Einsatz hat.

Da bei mir nie die netzweite Aktualisierung sauber durchlief, habe ich schnell DATEV einzeln auf den Servern nach meinem Ermessen aktualisiert. Ab und zu wartet die DATEV Routine auch auf irgendwelche Server - keine Lust zu. Aber das läuft wohl bei anderen Installationen besser.

#EmpoweringPeopleInTechnology – Daniel Bohle
www.metalposaunist.de

Steran · ‎16.11.2023

Eine Rückfrage ergibt sich mir vorab doch noch 🙂

Der Server ist nun vorbereitet, ich stoppe nun am Quellserver den SQL-Server und kopiere dann WINDVSW1 vom alten auf den neuen Server.

Dann installiere ich ich via Datev Basis Installer die aktuellste Version.

Anschließend würde ich noch den Lizenz-Manager-Server gemäß folgender Anleitung umziehen:

https://apps.datev.de/help-center/documents/1012341

Hier muss ich Daten von - in meinem Fall C:\DATEV\DATEN\LIMASERV) (lt. Aneleitung %DATEVDP%\DATEN\LIMASERV) - alt nach neu kopieren.

Sollte ich das ggf. auch noch vor der Datev Basis Installation machen?

Ist dieses eine Verzeichnis ausreichend, oder muss ich für eine saubere Datenübernahme vom alten Server ggf. das vollständige C:\datev-verzeichnis mitnehmen?

Muss ich bzgl. Nuko was beachten?

Gibt es für dieses Vorgehen eigentlich auch ein Infodoc?

metalposaunist · ‎16.11.2023

@Steran schrieb:
Sollte ich das ggf. auch noch vor der Datev Basis Installation machen?

Jap. Dann wird der Lizenzmanager gleich bei der Installation seiner selbst durch DATEV wieder grün, wenn man ihn kurz stoppt und wieder startet. Das ist dann schon mal viel wert.

@Steran schrieb:
Ist dieses eine Verzeichnis ausreichend, oder muss ich für eine saubere Datenübernahme vom alten Server ggf. das vollständige C:\datev-verzeichnis mitnehmen?

Das Verzeichnis ist ausreichend. Alle Produktivdaten liegen im Laufwerk L: / WINDVSW1 Verzeichnis.

@Steran schrieb:
Muss ich bzgl. Nuko was beachten?

Immer vor dem Umzug ein aktuelles Nuko Notprogramm frisch erstellen, damit man sich im Zweifel nicht selbst aussperrt. In einer Domäne sollte das nicht passieren, weil DOMÄNE/Administrator gleich bleibt aber man weiß ja nie, was passieren kann. Besser vorsorgen.

@Steran schrieb:
Gibt es für dieses Vorgehen eigentlich auch ein Infodoc?

Hm? Welches?

#EmpoweringPeopleInTechnology – Daniel Bohle
www.metalposaunist.de

martinkolberg · ‎17.11.2023

Domänencontroller?
Emails?

Hier Umzug folgendermaßen durchgeführt:

- Neuen Server ins Netz gebracht

- SQL- alt gestoppt
- Verzeichnisse rüber kopiert
- Server alt Freigebe gecancelt und SQL deaktiviert
- Server neu Freigeben, Datensicherung eingerichtet.
- Server neu installiert (neuer Name, neue IP- Adresse)
- Server Umzugsassistent nach Anleitung

- Clienten Mappings neu, Umzugsassistent

-> Alles läuft, wie gewohnt, nur viel schneller.

- viel später: USB- Dongle vom Server alt durch SWM Mini auf Neu Server ersetzt

To Do: (Altserver benötigt nur ca 50 Watt Strom)

- Domäne mit Homeverzeichnissen, usw. umziehen

- Exchange- Server umziehen

LS4B · ‎17.11.2023

Ich machs immer immer nach Doku: Serverumzug ohne Assistent. Wurde ja schon alles geschrieben. Nochmals in "kurz".

=> SQL-Stop und Lima-Stop alte Kiste

=> Datensicherung alte Maschine (am besten Image), dann hat man wenigstens alles zur Hand.

=> Lizenzpool und Nuko-Not nicht vergessen

=> Alte Maschine ausschalten, sollten sich alter DC und neuer DC im Netz einmal sehen => möchte ich nicht

=> Neue Kiste nach Vorgabe (Domäne, DATEVUSER, DATEVUO, Freigaben blah blah fertig machen

=> Rechte auf WINDVSW1 mittels Datev-Tool (diese kleine Datei)

=> Daten aus Image zurück in das Verzeichnis

=> Installation am Server, Ob nun Server mit/oder Arbeitsplatz soll jeder selber wissen. Ich machs inzwischen auch mit Arbeitsplatz und Programmen (früher nicht aber hab ich meine Meinung auch zu geändert) - dann hab ich zentral schon mal alles "fertig".

Lima gucken, bei Lizenzfehler einfach mal gucken in welches Verzeichnis "er" denn die Dateien nun haben möchte und entsprechend zurück kopieren. Nuko Not- einmal laufen lassen.

RZ-Assistent laufen lassen und wenn was nicht klappt erstmal "CDBTool" und "EODBConfig" anschauen.

Server Fertig...

PCs: raus/rein aus/in der Domäne DATEV runter/rauf, find ich "frisch gemacht" schöner. Ab 4-5 Leute mach ich eh WTS-Lösung - einfach weniger Arbeit auch für die Zukunft.

So in der Kürze...

windmann.it

Steran · ‎17.11.2023

Soo, jetzt habe ich mit dem Umzug begonnen - und wohl leider einen Fehler gemacht (Servername ändert sich - das war geplant):

Ich habe alle Dateien vom alten Server kopiert, leider auch ConfigDB 😕

Habe auf dem neuen Server die Plattform installiert (inkl. Kommunikationsserver) - zu Beginn der Installation habe ich den CCS vom alten Servernamen auf den neuen geändert (war das ggf. falsch?); das hat soweit auch geklappt, allerdings habe ich nach der Grundinstallation (Framework, SQL Server usw. usf.) beim RZ Abruf Verzeichnisfehler erhalten und konnte nicht weitermachen (ich vermute weil die unveränderte ConfigDB vom alten Server vorhanden war).

Ich dachte mir nun, das könnte an der noch fehlenden Serverumzugsassistentenausführung liegen.

Hier habe ich im Dokument dann gemerkt, dass ich das ConfigDB Verzeichnis NICHT auf den neuen Server hätte kopieren sollen.

Nun habe ich mit DVSERVERCHANGE vom alten Server die Konfiguration in eine Datei exportiert und am Client (User: Domainadmin) den Umzug durchgeführt. Das lief beim Ersten mal auf Fehler, weil das ConfigDB Verzeichnis nicht gefunden wurde (ich hatte es gelöscht, aber nicht neu angelegt).

Verzeichnis angelegt und DVSERVERCHANGE nochmal durchgeführt. Lief ca. 15 Minuten (u.a. DB Tabellenmigrationen usw.); nur leider ist nach erfolgreicher Durchführung das ConfigDB Verzeichnis auf dem Server immer noch leer; was dazu führt, dass ich u.a. beim Starten des Installationsmanagers oder Einstellungen vom Lizenzmanagerserver den Fehler #NK00105 (Konfigurationsdaten der Nuko konnten nicht ermittelt werden...) erhalte.

Lt. Infodok und meiner Vermutung liegt dies daran, dass mein ConfigDB Verzeichnis leer ist!?

Habt ihr eine Idee wie ich nun vorgehen könnte?

Das alte ConfigDB Verzeichnis, und auch den Server habe ich natürlich noch (HyperV).

Kann ich die alten Daten manuell rüberkopieren und anpassen?

EDIT:

Nach einem Serverneustart war das CONFIGDB Verzeichnis nun mit Daten befüllt 🙂

Oben genannte Vorgeschichte lasse ich aber mal stehen, evtl. hilft es bei der Fehlersuche.

Allerdings bekomme ich immer noch die folgenden Fehlermeldungen:

Beim Klick auf Lizenz-Manager-Einstellungen:

Oder beim RZ Abruf:

Die Plattforminstallation habe ich nochmal "drüberlaufen" lassen; endet dann mit o.g. Fehler beim RZ Abruf...

Da ich ein Rechteproblem vermute, habe ich die Berechtigungen (WINDVSW1) nochmal geprüft; scheinen identisch mit denen vom alten Server zu sein. Administrator bei Freigabe und Sicherheit jeweils Vollzugriff;

die Gruppe der Datevuser hat jedoch zu meiner Überraschung nur "Ordnerinhalt anzeigen" & "Spezielle Berechtigungen" - ist aber wie erwähnt identisch mit dem alten Server.

Ich mache für heute Schluss - evtl. habt ihr eine Idee was ich morgen ausprobieren könnte.

Lg

Steran

martinkolberg · ‎18.11.2023

Ich habe alle Dateien vom alten Server kopiert, leider auch ConfigDB 😕

EDIT:
Nach einem Serverneustart war das CONFIGDB Verzeichnis nun mit Daten befüllt 🙂
Oben genannte Vorgeschichte lasse ich aber mal stehen, evtl. hilft es bei der Fehlersuche.

Allerdings bekomme ich immer noch die folgenden Fehlermeldungen:
Beim Klick auf Lizenz-Manager-Einstellungen:
Ich mache für heute Schluss - evtl. habt ihr eine Idee was ich morgen ausprobieren könnte.

Machen Sie eine 360° Wende:

180° und zurück auf LOS
Nochmals 180° und beginnen Sie komplett neu. diesmal mit der korrekten leeren Config.SYS, wie in der Anleitung.

Lizenz Manager bitte separat behandeln.

Besser Server mit der jetzt gemachten Erfahrung nochmals neu aufsetzen, als mit einem Fehler im System in der Zukunft Ärger zu haben.

Sprichwort. besser ein Ende mit Schrecken, als ein Schrecken ohne Ende.

Steran · ‎18.11.2023

Vielen Dank - das hatte ich befürchtet; werde ich machen.

Was ist die richtige Antwort auf die Frage nach dem CCS zu Beginn der Installation? Alter Server oder neue Server?

Den Lizenzmanager installiere ich dann erstmal nicht mit?

janm · ‎18.11.2023

@Steran schrieb:

Was ist die richtige Antwort auf die Frage nach dem CCS zu Beginn der Installation? Alter Server oder neue Server?

AFAIK ist das egal bzw. würde ich das einfach unberührt lassen, da der CCS im Rahmen des Anpassungsassitenten (2.2.9 Punkt 9 aus der Anleitung oben) geändert wird.

Den Lizenzmanager installiere ich dann erstmal nicht mit?

Sollte eigentlich egal sein bzw. das kleinste / kein Problem sein.

Zur Gesamtsituation: Ich würde hier auch noch einmal neu anfangen.

Wenn möglich, den neuen Server einmal komplett entsorgen und mit einem frisch installierten OS anfangen.

Ansonsten alles deinstallieren und im Anschluss das Nacharbeitentool aus DATEV-Software deinstallieren - DATEV Hilfe-Center. (Hier kann es aber passieren, dass die Benutzer- und Rechteverwaltung sich "manipuliert" (fühlt) und der DATEV Support gebraucht wird! Wenn bei der neuen Installation ein BRV Nottool erstellt wurde, das vorsichtshalber mal behalten und ebenfalls ein Nottool der "Altinstallation" haben.)

Steran · ‎18.11.2023

So, zweiter Versuch sieht schon mal viel besser aus - vielen Dank!

Da ich nicht nochmal in ein Reihenfolgenproblem laufen möchte:

Auf dem Server ist jetzt Datev 17 vollständig installiert und angepasst.

Auf den Clients ist noch Datev 16 vorhanden.

Muss ich die jeweilgen Serveranpassungen an den Clients vor oder nach der netzweiten aktualisierung machen?

Ich vermute davor...konnte in der Doku hier aber keine Anhaltspunkte finden.

Ich frage deshalb weil mein Plan wie folgt ist:

Ich möchte nach wie vor einen Notfallplan haben, falls noch etwas schief geht, und deshalb erstmal einen unkritischen Client vollständig auf den neuen Server und neue Datevversion umstellen.

Wenn ich nun auf allen Clients vorab lokal noch den Serverumzug ausführen muss, verbaue ich mir ggf. den Fallback auf Version 16.

Wenn ich die netzweite Aktualisierung starte, dann werden alle Clients mitgezogen d.h. es könnte passieren, dass ich gar keine Möglichkeit mehr habe den Serverumzugsassistenten vor Start der netzweiten Aktualisierung zu starten.

martinkolberg · ‎18.11.2023

Aus dem Bauch heraus unbedingt vorher, damit die Pfade nicht verunfallen und die Clients den neuen Server kennen.
- Laufwerke mappen
- Server Anpassungs- Assistent (Wenn verunfallt wg. SQL- Version später nochmals durchführen)

- Update durchlaufen lassen.

unbedingt mit einem Test- Clienten das Spiel durchlaufen lassen, und den vorab sichern 😉

Was ist mit der Domäne? Bereits umgezogen oder bislang ignoriert?

Steran · ‎18.11.2023

Der Umzug ist vollbracht - ich mache 3 Kreuze 🙂

Danke nochmal für Eure schnelle Hilfe - auch bei doofen Fragen!

Für die Nachwelt folgende Infos:

Bei mir hat sich der Servername geändert, deshalb benötigte ich den Serverumzugsassitenten unter berücksichtigung der folgenden Anleitung:

https://apps.datev.de/help-center/documents/1011814

Der alte Server und die Clients hatten Datev Version 16; für die Installation am neuen Server habe ich gleich 17 verwendet.

Leider hatte ich das Dokument vorab nicht vollumfänglich durchgelesen, weil öfter Verzweigungen stattfinden und die Doku dann ziemlich mächtig wird. Zumindest o.g. Dokument sollte man sich aber vorab ganz durchlesen, ohne erstmal auf die Links zu verzweigen. Hilft für das Verständnis - für Admins die sich nur gelegentlich mit Datev beschäftigen.

Mein Fehler war, dass ich den Server lt. Link im Dokument vorbereitet hatte, und hier stand auch, dass man Datev gleich installieren sollte. Wie in vorherigen Beiträgen gepostet hatte ich die ConfigDB mitkopiert - das darf man nicht machen.

Da ich noch im Servervorbereitungsdokument bei der Datev Installation festhing, hatte ich auch die Installationslinks (Datev.Installation.Tools.Change.Extension.exe) nicht angepasst. Ich denke das war der Grund dafür, dass ich diese Fehlermeldungen erhalten hatte á la "Datenverzeichnis nicht vorhanden".

Dennoch würde ich auch nochmal ganz von vorne anfangen, wenn so ein Fehler passiert. Snapshots in einer virtualisierten Umgebung machen einem das Leben hier viel einfacher, wenn man sie gezielt einsetzt. 🙂

Nachdem der Server fertig war (wurde mit Kommunikationsserver installiert) und hier die Datev Anwendung fehlerfrei lief, habe ich mich an die Clients gemacht.

Erstmal den Unwichtigsten.
Hier als Admin angemeldet, den Serverumzugsassistenten nochmal gestartet und dann über den Installationsmanager direkt am Client den Arbeitsplatz aktualisiert. Dies musste ich zwar nach einem Neustart immer wieder selbst antriggern, was dazu führte, dass der UpdateMonitor am Ende selbst die Installation nochmal ein paar Mal gestartet hatte. Lief aber reibungslos durch.

Anschließend als lokaler User anmelden; nochmal den Umzugsassistenten starten (wenn das Laufwerk L korrekt gemappt ist, startet dieser auch sofort nach einer Bestätigung) und Datev lief anschließend.

Ach ja, nachdem ich beim 2. Versuch das ConfigDB Verzeichnis nicht kopiert hatte, wurde auch der CCS beim Starten der Installation nicht mit dem alten Server vorbelegt -> hier musste man nichts eingeben.

Datev habe ich wieder auf den DC installiert (sonst nichts drauf), weil es eine sehr kleine Umgebung ist, und auch die letzten 10 Jahre Datev auf dem DC absolut reibungslos lief. Da auch ein Exchange virtualisiert ist würde das eine weitere Lizenzierung notwendig machen, und ich bräuchte mehr Speicherplatz für die Backups.

Ich möchte aber nicht nochmal diese Diskussion eröffnen.

Den DomainController hatte ich vorab schon mit folgender, sehr guter Hilfestellung migriert:

https://www.youtube.com/watch?v=UOS7GuLs1fM

Viele Grüße,

Steran