Hallo liebe Community,
Ich bin gerade damit beschäftigt die Virtualisierungs-Infrastrukur meiner Firma umzustellen und bin damit fast fertig, wenn da nicht der Datev-Server wäre. Der ist in der Vergangenheit immer etwas heikel gewesen. Daher wollte ich einmal nachfragen bevor ich etwas dummes mache.
Wir nutzen einen Windows 2016 Server der die gesamte Datev-Infrastruktur inkl. Datenbank und RZ-Kommunikation enthält, derzeit noch auf VMware.
Mein bevorzugter Umgang mit dem Problem wäre die VM einfach herunterzufahren, in das neue Format um zuschreiben und auf dem neuen Hypervisor in Betrieb nehmen. Allerdings befürchte ich das mir Datev dies übelnehmen könnte. Ich weiß z.B. ein Domain-Controller sollte besser nicht auf diese weise umgezogen werden, da hier Probleme mit der Synchronisierung und Integrität entstehen. Ist das bei Datev ebenfalls so?
Vorab schon mal vielen Dank
Gelöst! Gehe zu Lösung.
Hi,
@A_Seidler schrieb: Ist das bei Datev ebenfalls so?
Probleme könnten bei dem SQL (Microsoft-SQL) und dem DATEV-Lizenzmanager entstehen.
Sichere Variante:
- Deinstallation der DATEV-Serverkomponenten (dürfte nicht allzulang dauern)
- Migration durchführen
- DATEV-Serverkomponenten wieder installieren
Den kurzen Weg könnten Sie auch beschreiten, wenn Sie eine Datensicherung haben, mit dem Sie den ursprünglichen Stand schnell wieder herstellen können (SnapShot der kompletten virtuellen Maschine). Dabei würde ich zumindest die SQL-Datenbanken stoppen (Dienst beenden und für die Dauer auf [Deaktiviert] setzten). Dann sind die DB's zumindest mal in einem konsistenten Zustand.
Den Lizenzmanager könnte man im WorstCase von DATEV auch wieder zurücksetzen lassen, bei einer Servermigration wären zumindest Argumente vorhanden.
Beste Grüße
Christian Ockenfels
Hallo Herr Ockenfels,
vielen Dank für Ihre schnelle Antwort.
@chrisocki schrieb:Sichere Variante:
- Deinstallation der DATEV-Serverkomponenten (dürfte nicht allzulang dauern)
- Migration durchführen
- DATEV-Serverkomponenten wieder installieren
Leider fehlt mir beim Thema Datev die Expertise um das so durchzuführen. In der Vergangenheit haben wir immer externe Dienstleister für größere Eingriffe herangezogen. Da hier recht viel Zeit für die Migration nötig ist, (daher auch außerhalb der Geschäftszeiten) ist das dieses mal leider nicht so einfach was das Timing betrifft, ansonsten würde ich wohl wieder diesen Weg wählen.
Nach Ihrer Beschreibung scheint aber grundsätzlich nichts dagegen zu sprechen mal den Versuch zu wagen, die entsprechenden Sicherheitsmaßnahmen vorausgesetzt.
Der Punkt mit der SQL Datenbank irritiert mich allerdings etwas. Also grundsätzlich ist es eigentlich recht logisch um keine Inkonsistenzen zu erzeugen. Allerdings habe ich denn ohne die Möglichkeit den Rest von Datev auf Fehler zu prüfen? (nach der Migration) Ich würde mir vorstellen das ohne sofort diverse Fehler gemeldet werden, die von anderweitig gelagerten Probleme für mich als Datev-Leien kaum unterscheidbar sind.
Beste Grüße
Alexander Seidler
Hi,
@A_Seidler schrieb: Der Punkt mit der SQL Datenbank irritiert mich allerdings etwas. Also grundsätzlich ist es eigentlich recht logisch um keine Inkonsistenzen zu erzeugen. Allerdings habe ich denn ohne die Möglichkeit den Rest von Datev auf Fehler zu prüfen? (nach der Migration) Ich würde mir vorstellen das ohne sofort diverse Fehler gemeldet werden, die von anderweitig gelagerten Probleme für mich als Datev-Leien kaum unterscheidbar sind.
Wichtig bei einer solchen Migration ist:
- Beibehaltung des Servernamen (NetBIOS-Name)
- Beibehaltung der IP-Adresse (da wird der MS-SQL nervös)
- Beibehaltung des Freigabenamens (im Prinzip muss die komplette URL beibehalten werden)
Um die SQL-Datenbanken in jedem Fall sicher zu migrieren, würde ich den SQL-Dienst stoppen, dann sind die Datenbankdateien eben nicht mehr im Zugriff bzw. geöffnet.
Darüber hinaus können Sie auch den Dienst des DATEV-Lizenzmanagers stoppen, sofern dieser als Dienst eingerichtet ist (ich gehe mal davon aus).
Nach der Migration müssen zum einem die Dienste problemlos wieder anlaufen können. Zudem können Sie am Server im "DATEV SQL-Manager" schon prüfen ob die Datenbanken weiterhin angehängt sind. Dort können Sie auch Verbindungstests zum SQL-Dienst auslösen.
Zudem können Sie auf dem Server auch das Servicetool aufrufen und im Prüfprofil die Anwendungen mit anhaken. Im Ergebnis sehen Sie dann, ob zumindest alle Dateien (Programme) richtig mit migriert wurden.
Den "DATEV SQL-Manager" können Sie zudem auch auf einem DATEV-Client aufrufen und hier ebenfalls die Verbindungstests ausführen.
Auf dem Server als auch auf einem DATEV-Client können Sie über [Ausführen] auch "dstest" aufrufen und dort einen Funktionstest starten.
Finaler Test ist dann der Aufruf von DATEV-Anwendungen.
Beste Grüße
Christian Ockenfels
Hi,
@chrisocki schrieb:Wichtig bei einer solchen Migration ist:
- Beibehaltung des Servernamen (NetBIOS-Name)
- Beibehaltung der IP-Adresse (da wird der MS-SQL nervös)
- Beibehaltung des Freigabenamens (im Prinzip muss die komplette URL beibehalten werden)
Um die SQL-Datenbanken in jedem Fall sicher zu migrieren, würde ich den SQL-Dienst stoppen, dann sind die Datenbankdateien eben nicht mehr im Zugriff bzw. geöffnet.
An der Server-Konfiguration plane ich nichts zu ändern. Wenn das die größten Probleme sind bin ich schon mal beruhigt, da hier alles beim alten bleiben wird.
Bezüglich der SQL-Datenbank sollte ich vielleicht noch anmerken das die ebenfalls auf dem Datev-Server läuft. Der Server wird für die Migration heruntergefahren. Wenn Sie allerdings sagen das Datev zumindest rudimentär anlaufen kann auch ohne Datenbank und Lizenz-Manager, dann werde ich das zur Sicherheit lieber so versuchen.
Ich hatte vor allem die Sorge das es ein Grundsätzliches Problem mit dieser Methode gibt. Ich werde die Migration voraussichtlich dieses Wochenende durchführen und danach mal einen kurzen Bericht einstellen.
Schon mal vielen lieben Dank für die Beratung.
Beste Grüße
Alexander Seidler