Neue Installationsvoraussetzungsprüfung bringt rote Lampe mit Stillstand am DATEV-ConfigDB-Server

[#1]

Hallo Community,

unsere Installationsvoraussetzungsprüfung vor Beginn eines Updates prüft seit dem 16.12.24 folgende Bedingungen am Datenbank-Server und bricht bei "True" die Installation ab:

• System ist ein Server Betriebssystem
• System hat den PC-Info Use 0 Wert. Das bedeutet auf diesem System soll ein ConfigDB Server gestartet werden.
• In der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Datev.Framework.RemoteServiceModel.EnablerService
  ist ein Group Eintrag mit dem Wert DATEV vorhanden.

Warum haben wir diese Prüfung eingebaut?

Im Service sind nach der Installation der DATEV-Programme V 18.0 viele Fälle mit folgenden Fehlerbildern aufgetreten:

• Nach dem Start des Servers konnte dieser nicht mehr erreicht werden.
• Während der Netzweiten Aktualisierung wurden Programme nicht installiert, weil die Datenpfade vom Datenbank-Server nicht mehr erreichbar waren.
• Der Aufruf vom DATEV Arbeitsplatz brachte Fehlermeldungen in Verbindung mit der Benutzer- und Rechteverwaltung
• usw.

Um erst gar keine Fehlersituation zu erzeugen, haben wir uns für die Prüfung und den Abbruch entschieden.

Als Ursache konnte eine alte Loadorder Konfiguration ermittelt werden.

Seit den DATEV-Programmen Version 14.0 (2020) wird bei Neu-Installationen am Datenbank-Server keine Loadorder mehr eingerichtet, aber Altsysteme und Systeme die durch Im-Place upgrade die Altkonfiguration übernommen haben, sind potentiell von dem Problem betroffen.

Durch eine Änderung in den DATEV Framework-Diensten kommt es zu Problemen in Verbindung mit dieser alten Konfiguration.

Die fehlerbereinigte DATEV Framework wird zu den DATEV-Programmen 19.0 ausgeliefert und im Moment schon pilotiert. 

Damit Ihre Datenbank-Server beim Jahreswechsel nicht mit einer roten Lampe stehen bleiben, führen Sie unbedingt im Vorfeld das Hilfecenter-Dokument, welches auch in der roten Lampe verlinkt wäre, aus:

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

Betroffen sind alle Datenbank-Server, die vor den DATEV-Programmen Version 14.0 (2020) erstmalig eingerichtet  wurden, also vorrangig WINDWS Server 2016.

Mit freundlichen Grüßen

Susanne Folkendt

Datev eG

[#2]

---

@Susanne_Folkendt  schrieb:

Betroffen sind alle Datenbank-Server, die vor den DATEV-Programmen Version 14.0 (2020) erstmalig eingerichtet  wurden, also vorrangig WINDWS Server 2016.

---

Vier Jahre nachdem das Problem korrigiert wurde in der Weihnachtszeit so einen Change durchziehen ist irgendwie echt unglücklich. Das hätte man nicht irgendwann früher dieses Jahr oder auch nächstes Jahr nach der "Frozen Zone" machen können?!

[#3]

Hallo janm, hallo Community,

es ist unbestreitbar, dass die Situation nicht ideal ist.

Wie so oft wäre es hilfreich, wenn man im Voraus wüsste, was man im Nachhinein weiß.

Im Jahr 2020 haben wir beschlossen, die Loadorder auf Server-Systemen nur bei Neuinstallationen nicht mehr anzuwenden und die Bestandsysteme unverändert zu lassen. Diese Entscheidung hat sich 4 Jahre als richtig erwiesen, da die Problemfälle, die 2020 auftraten, deutlich zurückgegangen sind und die laufenden Systeme nicht beeinträchtigt wurden.

Nun zu dem, was wir im Nachhinein wissen:

Mit der Version 18.0 war eine Konfigurationsänderung bezüglich des Starts der Dienste notwendig. Die Beteiligten haben dies nicht als problematisch eingestuft, jedoch traten, wie im ersten Beitrag beschrieben, verschiedene Probleme bei Kunden auf.

Erst Ende Oktober, Anfang November konnten wir die Ursache der Probleme eindeutig identifizieren.

Mit der Version 19.0 wird diese Konfiguration am Server entfernt. Dies ist nicht früher möglich, da wir keine Testmöglichkeiten für grundlegende Änderungen haben. Solche Änderungen werden nur zur "August"-Programmversion vorgenommen und pilotiert.

Die einzige Möglichkeit, die uns bleibt, ist die Einführung einer Installationsvoraussetzungsprüfung. Diese Prüfung haben wir online bereitgestellt. Der Vorteil einer solchen Prüfung ist, dass wir bei einem Fehler die Prüfung sofort entfernen oder anpassen können. Derzeit sehen wir die Ergebnisse der Prüfung bzw. der ausgeführten Skripte.

Momentan können wir definitiv sagen, dass unser Vorgehen Nutzen stiftet. Einige potenzielle Problemfälle wurden bereits aufgedeckt und behoben.

In diesem Sinne wünsche ich Ihnen besinnliche Weihnachten.

[#4]

Moin @Michael_Crome ,

vielleicht wundert es nur mich, dass wir hier im "Voraus" grob vier Jahre hatten und im "Nachhinein" das ganze in der letzten vollen Arbeitswoche vorm Jahreswechsel scharf geschaltet wird bzw. das hier drei/dreieinhalb/vier Arbeitstage vor Heiligabend bekannt gegeben wird.

Das Thema kam an anderer Stelle hier in der Community bereits Ende November auf, wo wir dann letztlich vorgestern vor diese Tatsache gesetzt wurden. Eine Rückfrage Ende November, ob wir das Dokument (1008965) pauschal überall ausrollen sollen blieb unbeantwortet.

Es wäre halt toll, wenn man als Solution Partner / PARTNERasp Partner bzw. eigentlich generell frühzeitig über solche Ideen informiert wird. Das wurde ja vermutlich nicht am 13. oder 14. auf einer Weihnachtsfeier zu später Stunde beschlossen und direkt am Montag umgesetzt...

(Vor dem Hintergrund, dass das online geschaltet wird, verstehe ich erst recht nicht, warum nicht der SR-Day im Januar genommen wird.)

Danke, Gruß und entspannte Weihnachten

Jan

[#5]

---

@Susanne_Folkendt schrieb:
[...]
Die fehlerbereinigte DATEV Framework wird zu den DATEV-Programmen 19.0 ausgeliefert und im Moment schon pilotiert. 
[...]

---

wow !  ... jetzt schon pilotiert ?! 😎

Aus Erfahrung weiß ich, dass rote Ampeln beim Versuch, eine Neue Datev-Version netzweit zu installieren, augenblicklich zu erhöhtem Puls und höherem Blutdruck führen.

Zum Glück habe ich persönlich mit solchen OnPremises-Aktionen aktuell nichts mehr zu tun, aber man muss darauf vertrauen können, dass der zuständige Techniker weiß, wie er auf solche Effekte korrekt reagieren kann.

Die Lösung des Problems (die 'Umschaltung der Ampel auf grün')  wirkt in diesem Fall ziemlich einfach, aber ich habe auch schon erlebt, dass das Betriebssystem abgekündigt war und upgegraded werden musste 

Solche Aktionen können die Termin-, Urlaubs- und/oder Familienplanung heftig durcheinander bringen 

[#6]

Frohes neues Jahr zusammen!

Nachdem uns gestern eine Vielzahl an Installationen mit diesem "Problem" stehengeblieben sind und ich somit auf diesen Beitrag gestoßen bin, stellt sich mir an dieser Stelle hauptsächlich eine Frage:

Wenn die Problemstellung sowie auch die Problemlösung klar sind. (Das Löschen eines Registry-Keys) Warum muss dann händisch vor der Installation (Wenn man denn Bescheid gewusst hätte) oder während der Installation händisch ein bereits fertiges Skript ausgeführt werden, was sich darum kümmert? Im Anschluss lässt sich noch nicht einmal die Installation fortsetzen, sondern diese muss neu angestoßen werden, da die Voraussetzungsprüfung ja fehlgeschlagen ist...

Wäre es nicht einfacher gewesen den Admin nicht damit zu belämmern sondern einfach den RegKey zu Löschen wenn dieser vorhanden ist und die Installation fortzusetzen, oder übersehe ich etwas? Mehr gibt das Dokument 1008965 als manuelle Abhilfe auch nicht an...

Mit freundlichen Grüßen

Thomas

[#7]

Guten Morgen,

heißt das, dass der Registry-Eintrag auf jeden Fall gelöscht werden muss, wenn er denn vorhanden ist?

Und das am besten vor der Installation der Jahreswechselversionen?

Oder nur wenn der Fehler auftaucht?

[#8]

Guten Abend,

das wäre auch meine Frage. Der besagte Registry Key ist bei uns noch auf dem File-Server (Server 2016) vorhanden. Bisher hatte ich nie Probleme mit der Arbeitsplatz-Aktualisierung am File-Server. 

In der Regel aktualisiere ich immer als erstes den File-Server. Danach lasse ich eine netzweite Aktualisierung laufen. 

Morgen Vormittag werden die Service-Releases vom 30.12 installiert.
Sollte der Eintrag vorab einfach gelöscht werden, bevor man die Installation morgen startet?

Gruß

[#9]

Solange der Eintrag vorhanden ist, wird die Installation bei der Überprüfung der Installationsvoraussetzungen aussteigen. Es bietet sich somit an, die Anpassung im Vorfeld auf einem der beiden im Dokument NK00105 mit Grund Cached: Bei der Verbindung mit dem Server über DFL-Hosting - DATEV Hilfe-Center genannten Wege durchzuführen.

[#10]

Wenn der Eintrag da ist, erspart das vorherige Löschen folgenden Installations-Stopp:

[#11]

Hallo Community,

um vorbereitet zu sein, können Sie am Fileserver den Registry Eintrag löschen, oder bequemer das Skript, enthalten im Dokument www.datev.de/hilfe/1008965, am Fileserver ausführen. Das Skript löscht den Eintrag, wenn er vorhanden ist.

Danach bleibt die Installationsvoraussetzungsprüfung nicht stehen.

[#12]

Das Update ist am Wochenende ohne Fehler durchgelaufen. Den Key habe ich vorher auf unserem File-Server bzw. Config-DB Server gelöscht. 

Gruß und Danke für den Hinweis.