Server Umzug auf neue Hardware

[#1]

Hallo Zusammen,

Wir haben vor den Datev Fileserver auf eine neue
Hardwarebasis zu verschieben

Ich habe mich schon mit den entsprechenden Datev Dokumenten
intensiv beschäftigt, leider sind noch immer einige Unklarheiten vorhanden.So
wie ich es verstanden habe gibt es 3 Möglichkeiten des Serverumzuges, Mit oder
ohne SAA (Server Anpassungsassistent) und wenn ohne mit Neuinstallation des
Filservers und der Clientsysteme (sehr
aufwändig) oder lediglich die Datenverzeichnisse incl. der SQL DB´s vom alten
Fileserver auf den neue kopieren unter der Voraussetzung das alles gleichnamig
ist, danach Datev Serverkomponenten installieren..

Danach lediglich in der Rechteverwaltung die Datevuser mit
den „neuen“ Domänennutzern verknüpfen. Diese Variante klingt am leichtesten zu
bewerkstelligen, mir stellt sich aber die Frage ob es nicht Probleme mit sich
bringen kann wenn ich auf dem neuen Server ein neues AD (aber eben gleichnamig)
aufsetze, neue User und Gruppen anlege die zwar gleich heissen aber natürlich
nicht identisch sind (unterschiedliche SID´s.)

Hat jemand hiermit schon Erfahrung, gibt es Besonderheiten
welche zu beachten sind ? Zum Beispiel liegt unser Lizenz Server Manager und
der Komm Server auf einer der Arbeitsstationen.

Welche Variante wäre die günstigste um im Notfall wieder auf
den alten Server zurückswitchen zu können, und den Neuanlauf vielleicht um ein
Wochende verschieben zu können, in der Woche aber die Kanzlei weiterarbeiten
kann??

Meine letzte Frage, hat jemand Erfahrung mit Steuersoft, RA-
Micro und Datev auf derselben Servermaschine, empehlenswert oder ausser Datev
alles auf eine Virtualisierung packen…

Zu meinem Kenntnisstand, erfahrener Windows Admin, Datev
Clientsysteme schon umgezogen, Rechteverwaltung umgestellt, aber eben noch nie
einen Datev Serverumzug gemacht.

Ich würde mich wirklich über jeden Kommentar freuen…

[#2]

Also, wenn es eine AD gibt, würde ich diese auch behalten und dann eine Migration machen, wenn das AD auch umgezogen werden soll. Dann entfällt das lästige raus und rein und alte, neue Domäne. Migration machen und alles kann wie gehabt weiterlaufen.

Dann den DATEV FS aufsetzen (eigene VM, wenn möglich, kann ich empfehlen - ist man unabhängiger) und dann eines Abends die Anleitung mit SAA durchführen. Komplett Laufwerk L: bzw. die Freigabe via Robocopy auf den neuen FS übertragen, Freigabe am alten FS löschen, neue Freigabe mit entsprechenden Rechten setzen, an einem Client die neue Freigabe als L: mappen, SAA durchführen, DATEV FS neuinstallieren und dann können alle Clients nach Ausführung der SUT weiterarbeiten, als wenn nichts gewesen wäre.

So würde ich es machen. Ist für alle am bequemsten und ohne Ausfälle machbar.

[#3]

Zunächst einmal vielen Dank für die wertvollen Tipps und Hinweise zum Serverumzug.

Nur das ich alles richtig verstanden habe:

1. AD von altem System auf neues System migrieren (in unserem Fall von 2008R2 auf 2016 (hoffe die Migration ist möglich?!)

2. Datev Serverkomponenten auf neuer Hardware und migrierter Domäne installieren.

3.Serverumzug mit SAA durchführen incl. LW Freigaben, kopieren, rechte setzen, löschen der alten Freigabe für Client mit SAA Mappen.

4. Dann nochmals die FS Komponenten installieren ?

5.Alle Clients führen SUT aus

Ich hoffe ich habe jetzt die Richtige Vorgehensweise verstanden...?

[#4]

1. AD von altem System auf neues System migrieren (in unserem Fall von 2008R2 auf 2016 (hoffe die Migration ist möglich?!)

Das sollte möglich sein. Wenn, dann meckert Windows schon. Ggf. auf die Gesamtstrukturebene der Domäne achten und hochziehen.

2. Datev Serverkomponenten auf neuer Hardware und migrierter Domäne installieren.

Auf keinen Fall! Bitte unbedingt die Anleitung dazu von der DATEV inkl. SAA durchlesen. Die Schritte sind super genau beschrieben und exakt einzuhalten.

In Kurzform: Server 2016 in AD aufnehmen, zum AD machen, DATEV WINDVSW1 Freigabe von 2008 auf 2016 per Robocopy kopieren inkl. NTFS-Rechte, alte Freigabe löschen, neue Freigabe am 2016er setzen, Freigabe am DATEV Client mappen, SAA durchführen (Einträge in der CONFIGDB werden von alter DATEV FS auf neuen DATEV FS umgeschrieben) und erst dann am DATEV FS DATEV als Server inkl. ggf. Arbeitsplatz installieren.

Danach an allen anderen Clients die neue Freigabe mappen, SUT ausführen lassen (vor dem 1. DATEV Start!) und danach erst den DATEV Arbeitsplatz öffnen.

[#5]

Hallo nochmal,

Super erklärt, fühle mich jetzt mutig genug es umzusetzen, nochmals vielen Dank für die Unterstützung !!!!!!

Das der Lizenz Server Manager und der Kom Server auf einem der "alten" Clients verbleibt ist hoffentlich kein Problem, wir haben diesen immer als Administration PC verwendet. ?

[#6 · Accepted solution]

Das der Lizenz Server Manager und der Kom Server auf einem der "alten" Clients verbleibt ist hoffentlich kein Problem, wir haben diesen immer als Administration PC verwendet. ?

Ich meine nicht. Wichtig auch hier erst die SUT ausführen und dann DATEV starten.

Aber warum nicht LiMa und KOMM-SRV auf dem neuen 2016 mitlaufen lassen? Extra nur dafür einen PC 24/7 mit Strom zu versorgen, wo der Server sowieso 24/7 läuft?!

Auch hier einfach die Anleitung Schritt für Schritt exakt durcharbeiten.

Einen Administrator-PC hat es in meinen Kanzleien nie gegeben. Bei einem Update erst den neuen Server 2016 inkl. DATEV aktualisieren und dann einfach alle Clients. Je nach Menge ist eine Aktualisierung von Hand ggf. schneller.

Und wenn Sie am Server 2016 noch alle DATEV Programme installieren, können Sie dort schon die Datenanpassung anstoßen während die Clients sich noch alle aktualisieren.

Dann sind Server und Clients im besten Falle gleichzeitig fertig und mehr Zeit kann man sich nicht sparen.

[#7]

Super, genau so werde ich es umsetzen...und hoffen das alles klappt.

Echt selten daß ich in einem Forum so klare Hilfestellung bekommen habe, vielen Dank nochmal !

[#8]

Eine "schnell und dirty"- Lösung könnte darin bestehen nach Kauf des neuen Bleches zu versuchen dort die normale Datensicherung einzuspielen.

Mit ein wenig Glück (und dafür ist die Datensicherung ja da) läuft er an und könnte sofort den Produktivbetrieb gehen.

Schritt II: Auf diesem Gerät die "Migration" durchführen.

[#9]

> Lima & Kommserver mitlaufen lassen?

Lima OK und problemlos, aber benötigt der Kommserver nicht alle Anwendungen für die Nachbearbeitungen?

Bei der Installation des Kommservers auf einer normalen Arbeitsstation spart man sich eine komplette DATEV- Lizenz. Der Client sollte per Task: Shutdown & Bios- Autostart nachts zur Ruhe gelegt werden. Der Anwender spürt nichts von dem zusätzlichen Dienst.

[#10]

Durch die Lizenzierung des KommServers wird deshalb die Betriebsstättenbasis um 1 erhöht.

[#11]

Lima OK und problemlos, aber benötigt der Kommserver nicht alle Anwendungen für die Nachbearbeitungen?

Korrekt, und dann kann man auch gleich die Datenanpassung am Server starten, wie oben beschrieben. Gerade weil die Datenanpassung am leistungsstarken Server meist schneller als am Client geht.

Durch die Lizenzierung des KommServers wird deshalb die Betriebsstättenbasis um 1 erhöht.

Korrekt. Tut sich also nichts am Preis.

[#12]

Durch die Lizenzierung des KommServers wird deshalb die Betriebsstättenbasis um 1 erhöht.

Die Erhöhung bleibt auch, wenn der Kommserver auf einem normalem Arbeitslatz- PC läuft.
-> Man spart sich dadurch eine Lizenz, da damit der Server keine Lizenz benötigt.

Frage zu den Lizenzen:

Wie läuft ein Mischbetrieb mit WTS und Clients lizenztechnisch?

Planung:

Bei einem bestehenden Server- Client- System wird der Server neu aufgesetzt

-> alles OK., (Clients sind i5- Rechner mit SSD, 8 GB RAM und Office 2010)

Jetzt wird auf dem Server- Blech ein WTS bereitgestellt, auf den sich Mitarbeiter von ihrem bestehenden Client aus aufschalten können.

langfristige Zukunft: Wenn alle nur noch über den WTS arbeiten, soll DATEV von den Clients verbannt werden.

Office Lizenzen müssen wohl neu gekauft werden.

DATEV: Reichen die vorhandenen Lizenzen, oder zieht sich dann jeder Anwender zwei Lizenzen, wenn er lokal den DAP offen hält?

[#13]

DATEV: Reichen die vorhandenen Lizenzen, oder zieht sich dann jeder Anwender zwei Lizenzen, wenn er lokal den DAP offen hält?

DATEV zieht sich meiner Meinung nach erst eine Lizenz, wenn ein entsprechendes Programm (REWE, KSt, Lohn&Gehalt, ...) geöffnet wird. Wird es wieder geschlossen, wird die Lizenz wieder freigegeben.

D.h. der DATEV Arbeitsplatz kann dann überall zumindest gestartet werden, ohne, dass eine Lizenz "verbraucht" wird.

langfristige Zukunft: Wenn alle nur noch über den WTS arbeiten, soll DATEV von den Clients verbannt werden.

Wie lange möchten Sie das mitmachen? Bitte in jedem Monat bei den DATEV SR daran denken, dass die gesamte DATEV Umgebung auf gleichem Stand sein muss. D.h. auch die "lahmen" lokalen DATEV Installationen müssen dann inkl. WTS immer aktualisiert werden. Das macht deutlich mehr Aufwand als nur den WTS zu aktualisieren.

[#14]

Die Erhöhung bleibt auch, wenn der Kommserver auf einem normalem Arbeitslatz- PC läuft.

Das wäre aber nicht im Sinne des Erfinders! Man könnte dies auch als Lizenzverstoss ansehen.

Reichen die vorhandenen Lizenzen, oder zieht sich dann jeder Anwender zwei Lizenzen, wenn er lokal den DAP offen hält?

Wofür der lokale DAP?

[#15]

Hallo nochmal,

AD Migration von 2008R2 nach 2016 scheint kein Problem zu sein, jedoch ist meine Frage ob es für den anschliessenden SAA kein Problem ist das sich die Computernamen des alten und des neuen DC´s (Datev Fileserver unterschieden, mit hoher Wahrscheinlichkeit auch die IP Adresse, gleiche Namen oder IP in der Domäne sind ja nicht wirklich gut...passt der SAA das denn alles automatisch an ?

im Voraus vielen Dank....

[#16]

Ja, dafür ist der SAA schließlich gedacht / gemacht.

Theoretisch kann man auch Daten sichern -> temporären DC installieren -> alten DC demoten, entfernen und ggfs. aufräumen -> neuen DC mit gleichem Namen (und IP) installieren -> Daten einspielen.

[#17]

asmodi​: Wie jan schon schrieb: nichts anderes macht der SAA, als den alten Servernamen überall dort zu ändern, wo die DATEV ihn in der CONFIGDB und Registry geschrieben hat und ihn auf den neuen Namen zu ändern.

Die DATEV Programme schauen in der Registry und CONFIGDB nach, wo denn die Datenbank liegt und wo "alle" Anfragen hingehen. Steht da noch der alte Name drin, fährt DATEV gehen die Wand. Der Timeout dazu dauert auch gefühlt ewig.

Daher braucht man den SAA nicht, wenn man die CONFIGDB löscht und komplett neuschreiben lässt und auch die Arbeitsplätze neuinstalliert, sodass überall alles  was mit DATEV zu tun hat, nicht mehr existiert und beim Neuanlegen der korrekte DATEV-DB Name reingeschrieben wird.