Umzug mit kompletter Neuinstallation Probleme

[#1]

Liebe Community.

In der Kanzlei, die ich seit mehr als 20 Jahren betreue, habe ich schon einige Serverumzüge gemacht, die sind allerdings schon einige Zeit her. Seitdem neu sind das neue Datev Benutzer- und Rechtesystem und die Bereitstellung per DFÜ.

Am Wochenende wollte ich umziehen, aber leider mit Problemen.

Istzustand: Ein Hyper-V Host auf dem 2 VM laufen, in der einen der Datev-Server als DC/AD mit SQL/Fileserver, LiMa und Komm-Server. In der zweiten der WTS. Alles auf Windows Server 2012R2. Läuft seit Jahren ohne jeglichen Ärger. Mit aktueller 15er Version inkl. allen SRs.

Neu: Ein komplett neues Blech, also komplett neuer Hyper-V Host, wieder gleiche Struktur wie beim alten, aber alles mit Windows Server 2022. Somit auch mal ein komplettes Aufräumen der Systeme mit Neuinstallationen, auch Datev. Vorher das System komplett vorbereitet für den Umzug der Datev-Programme inkl. DNS und DHCP, das AD wird neu aufgesetzt.

Der Domainname bleibt gleich, aber Servernamen ändern sich.

Auf dem alten Server alles anhand des aktuellen Server Anpassungs Assistenten Dokument gemacht. Datenbanken gelöst, SAA ausgeführt, LiMa-Server Lizenzpool Verzeichnis kopiert, Datev-Ordner aus WINDSVW1 kopiert usw. Notprogramm erstellt wegen neuer AD.

Das alte System herunter gefahren. Am neuen System auf dem AD/DC mit der aktuellen Basisinstallationsdatei 15 die Plattform installiert inkl. LiMa und Komm-Server.

Am Ende kommt die Konfiguration des Komm-Servers und da begann das Problem. Beim Funktionstest kam "Der angemeldete Datev-Benutzer ist nicht mit einer Person im DATEV-Rechenzentrum verknüpft".

Somit keine Verbindung zum Rechenzentrum, somit kein Herunterladen der Rechte und der Software per DFÜ usw. Da ja nirgends ein Datev-Arbeitsplatz mit Datev Benutzerverwaltung vorhanden ist da Neuinstallation, kann ja auch nichts verknüpft werden.

Somit also nicht mit der Basisinstallation sondern mit der DVD-ISO 15 probiert. Damit komme ich auf dem WTS aber auch nicht weiter, nach der Plattforminstallation will auch diese Installation ja Daten aus dem Rechenzentrum herunterladen, oder auf Bereitstellungen von alten DVDs zugreifen, die ja im Moment nicht da sind.

Wie mache ich also in solch einem Fall einer kompletten Neuinstallation mit Servernamenänderung den Umzug korrekt? An welcher Stelle wende ich auf dem neuen System den SAA an? Nach den Dokumenten hörte es sich so an, erst die Installation auf dem SQL/Fileserver, dann auf dem WTS und danach den SAA. Aber das scheint so nicht zu gehen.

Weil das System eh vermurkst war habe ich dann auf dem WTS erst mal den SAA laufen lassen, Datev-Programme waren keine installiert (ein wenig irritiert war ich, dass dort an einer Stelle steht, man solle ihn an einem Rechner ausführen, wo die meisten Datev-Programme installiert sind). Dann die Installation angestoßen, so fand der WTS dann das Instman Verzeichnis auf dem Fileserver und hatte von dort dann ein paar Programme nach der Plattforminstallation installiert.

Durch vernünftige Backup-Strategie konnte ich den alten Server direkt wieder in Betrieb nehmen, so dass es zu keinen Ausfällen kommt.

Aber ich muss ja demnächst den nächsten Versuch machen. 🙂

Vielen Dank für Hilfe. Gruß Kai Klintworth

[#2]

@kklint,

herzlichen Glückwunsch! Sie sind der Gewinner der Umstellung und werden in der Hölle der Rechteverwaltung willkommen geheißen.

Es gibt im Hilfecenter das Dokument https://apps.datev.de/help-center/documents/1071587 hilft.

Da Sie die Benutzer im neuen AD angelegt haben führt der Titel ein wenig in die Irre. Das neue AD ist die neue Domain, auch wenn der Name gleich geblieben ist. Da würde nur die Migration vom alten 2012er etwas bringen. Das gewünschte "Ausmisten" würde dabei aber auf der Strecke bleiben.

[#3]

Bei einer Neuinstallation brauchts keinen SAA!

Nutzdaten vorweg an die passende Stelle kopieren, Neuinstallation machen fertig,

An der passenden Stelle (wenn die entsprechende Meldung kommt!!) das Nuko (BRV) Notprogramm von der ALTEN Anlage herüberkopiert aufrufen, fertig

Zum Schluss die "neuen" AD User in der BRV wieder verheiraten.

[#4]

@münster das Dokument hatte ich mit beachtet...

@siro hm, ok. Früher wurde ja auch immer ohne SAA umgezogen. 🙂 Aber irgendwie klappte ja die Installation auf dem WTS nicht, dann muss ich schauen, was da das Problem war. Irgendwie fehlten Installations-DVDs und deswegen wollte er die Installation nicht machen.

Und was ist mit diesem Punkt?

"Wenn der alte Server die für DATEV-Programme wichtige zentrale Datenpfad-Tabelle verwaltet hat (z.B. war er der einzige DATEV File-/SQL-Server im Netzwerk), den neuen Server mit dem Tool DpIdExplorer als zentralen Konfigurationsserver setzen und zentrale Datenpfad-Tabelle wiederherstellen (Anleitung: Dok.-Nr. 1080172)."

[#5]

Das  DATEV Hilfe-Center, Dok.-Nr. 1080071 Punkt 2.2.1 beschreibt den Umzug (inkl. cdbtool) aber komischerweise fehlt dort der Hinweis auf das Notprogramm.

[#6]

Da bleibt doch nur noch der CNAME Eintrag im DNS der auf den Host verweist.

Edit: Nicht zu vergessen die Anpassung der Profile im Komm-Server.

[#7]

Das klingt insgesamt, als wenn es einer machen sollte, der das in den letzten zwei, drei Jahren mehr als einmal gemacht hat? Ich wüsste z.B. nicht, warum man eine neue AD mit gleichem Domain-Namen neu erstellen sollte (oder wollte). Wofür dann einen neuen Einrichtungsaufwand für Benutzer, Gruppen, Kennworte, NTFS-Berechtigungen, Neuverknüpfungen von DATEV-Benutzern ... etc. pp? In einer vorhandenen AD versteckt sich möglicherweise noch mehr, z.B. sinnvolle (oder sinnlose) Gruppenrichtlinien, diverse Computerkonten (Computer oder weitere Server müssten mit weiteren Konsequenzen Neumitglied werden etc.) was dann alles unnötigen, aber zusätzlichen Zeitaufwand/ Nacharbeit (verlängert möglicherweise die Downtime) darstellt. 

Es geht leider die Mär um, ein altes AD sei irgendwie eine potenzielle Fehlerquelle und ein neues AD = sauber würde potenzielle Probleme ausschließen oder irgendetwas enorm beschleunigen. Nein. Das kann ich aus Erfahrung so nicht bestätigen. Eher noch dementieren. Natürlich sollte eine Quell-AD-Struktur in sich konsistent sein und bezüglich DNS-Konnektivität fehlerfrei. Das muss man aber auch bei einer neu erstellten AD prüfen und gewährleisten. 

Den SAA kann man benutzen, wenn man ihn dringend braucht (z.B. wenn man mehrere. vorhandene DATEV-Arbeitsplätze ohne Neuinstallation "retten" möchte, wenn es mehrere EODB-Datenpfade in einer Sozietät o.ä. gibt). Wenn man aber  Fileserver und WTS erneuert, muss man ohnehin ALLES neu installieren und Datenpfade u.U. mit dem CDBtool anpassen. Dbenötigt dann den SAA nicht. Da wäre die Anwendung des SAA eher eine zusätzliche Fehlerquelle und dann ein zusätzlicher Zeitfresser. 

Die Kunst ist ja immer, die Downtime für das DATEV-System und seine Benutzer in Grenzen von möglichst wenigen Stunden zu halten. D.h. so viel wie möglich vorbereiten, alle Vor- oder Nacharbeiten eben davor oder danach und für eine Zeit X beide Systeme nebeneinander, um Daten zum korrekten Zeitpunkt relativ schnell von alt nach neu kopieren zu können. Zwei verschiedene AD mit gleichem Domainnamen zur gleichen Zeit nebeneinander betreiben wäre schon schwierig. Für den Datentransfer wären eventuell gar Zwischenkopien nötig. Das verbraucht unnötig zusätzliche unproduktive Zeit und Platz.

Ein neuer Benutzer oder ein Admin oder Administrator ist eben erstmal kein DATEV-Benutzer und eventuelle Verknüpfungen müssten mit dem Nuko-Notprogramm verfügbar und dann händisch repariert werden. Ohne Funktion der DFÜ und ohne DATEV-Benutzer plus Berechtigungen wird der Umzug unschön und/oder nicht fertig oder länger dauern. 

Eigentlich ist das Dokument Server umziehen ohne Server-Anpassungs-Assistent relativ eindeutig. Natürlich kann das Dokument nicht alle sonstigen Umstände abbilden, die so ein Server-Umzug außerdem und auch unabhängig von DATEV hat. Aktuelle Umzugserfahrung und Grundkenntnissse und der hoffentlich bereinigten DATEV-Benutzer- und Rechteverwaltung und in Server-Migration von ADS, DC-Rollen, ggf. Exchange, Setup RDS-Services sollten vorhanden sein. 

Alter ADS-Master-DC = on, neuen Server zur Domain hinzufügen, eventuell AD-Schema auf gemeinsamen Mindeststandard anheben, Neuen DC zur vorhandenem ADS hinzufügen, AD-Masterrollen übertragen, am Ende alten DC-Master sauber herabstufen = einfacher Mitgliedserver, fertig. Bis hier sollten DATEV-Programme immer noch auf den bisherigen Servern laufen wie gehabt. Bis hier kann man auch noch manuell einen Lizenz- und DFUE-Abruf von Software ins Depot machen. Exchange- oder Postfachmigration ist noch ein extra Thema. Sonstige liebgewonnene Software kommt häufig noch hinzu.

RDS-Server mit allen nötigen Rollen, ggf. MS Office  - noch ohne DATEV-Installation - hinzufügen. Die Steuerung von Netzwerk-RDS-Profilen plus Folder Redirection (n.m.E. besser/ schneller als Remote Desktop Profile Disks) sollte man per neu erstellter Gruppenrichtlinien vorbereitet und getestet haben.

Dann beginnt die DATEV-Offline-Time.

1. DATEV-Server-Komponenten inkl. LIMA-, Komm.Server auf dem bisherigen DATEV-Fileserver deinstallieren.
2. Dann DATEV-Daten ggf. mit NTFS-Permissions (ABER OHNE CONFIGDB) kopieren.
3. Leeren CONFIGDB-Ordner am Ziel neu anlegen. Ggf. Freigabe- und NTFS-Berechtigungen prüfen/ anpassen. WINDVSW1-Freigabe alt entfernen. 
4. Dann DATEV-Server-Komponenten auf dem neuen Fileserver (ggf. inkl. LIMA-Umzug, Komm.Server, DATEV-Plattform mit Programmen) installieren. Es macht zu 99% Sinn, alle diese Funktionen auf einem Server zu vereinen und diese nicht verteilt zu betreiben. 
5. Dann funktioniert nach ggf. zusätzlicher Datenpfadanpassung der Arbeitsplatz am Fileserver inkl. Benutzer- und Rechteverwaltung und auch die DFÜ.
6. Dann kann man sich um den "WTS" kümmern. 

Ohne Anspruch auf Vollständigkeit. Im Zweifel schaue ich selbst auch ins Dokument. 

Bis 1. und nach 4. sollten Datenpfade, LIMA, Benutzer- und Rechteverwaltung, DFÜ konsistent sein oder wieder konsistent werden, Berechtigungen, Verknüpfungen wiederhergestellt werden und der DATEV-Arbeitsplatz inklusive Installations-Manager und RZ-Verbindung nach 5. wieder funktionieren. Wie ein "Admin-PC". Sonst kommt man bei 6. nicht sinnvoll weiter. Zum richtigen Zeitpunkt Lizenz-Manager-Server umziehen ... und Voraussetzungen zum Betrieb der DFÜ-Komponenten über die Netzschnittstelle ... beachten - DNS-Verweise komm-srv-1 auf den Komm-Server anpassen ist außerdem ein guter Hinweis. 

[#8]

@JoergZielke Ich habe mich vielleicht nicht richtig ausgedrückt, ich bin seit 30 Jahren in der IT und kümmere mich auch um Netzwerke. Somit, bis zu "Dann beginnt die DATEV-Offline-Time." oder eher Punkt 3 ist schon alles klar. Und auch kein Problem, denn die Systeme sind ja schon bis zu dem Punkt vorbereitet.

Es geht ja wie geschrieben um den Datev-Umzug.

VG

[#9]

Hallo @kklint ,

wenn die bereits aufgeführten Hilfestellungen nicht zum Erfolg führen, wenden Sie sich bitte an unsere Servicekollegen.

Dort ist dann ein direkter Blick auf Ihr System möglich und das macht die Problemlösung einfacher.

Viele Grüße

Mario Engel