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. DATEV-Server-Komponenten inkl. LIMA-, Komm.Server auf dem bisherigen DATEV-Fileserver deinstallieren. Dann DATEV-Daten ggf. mit NTFS-Permissions (ABER OHNE CONFIGDB) kopieren. Leeren CONFIGDB-Ordner am Ziel neu anlegen. Ggf. Freigabe- und NTFS-Berechtigungen prüfen/ anpassen. WINDVSW1-Freigabe alt entfernen. 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. Dann funktioniert nach ggf. zusätzlicher Datenpfadanpassung der Arbeitsplatz am Fileserver inkl. Benutzer- und Rechteverwaltung und auch die DFÜ. 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.
... Mehr anzeigen