DATEV-Datenbank: Rechte für Datenbankdateien zerschossen und nichts geht mehr

Eigentlich sah alles gut aus, aber auf der Zielgeraden einer DATEV-Migration auf einen Server 2019 ging es dann doch noch ziemlich bergab. Auf eines kann man sich in so einer Situation defintiv nicht verlassen: Den (kostenpflichtigen) Eil-Support von DATEV. Diesen kratzt es nicht wenn das System Stunden lang still steht und das dann auch noch für stolze 25 € pro Anruf. Da hilft nur eins: Selber fixen! Dieser Artikel hilft grundsätzlich dabei, falls man in DATEV Probleme bzgl. fehlender Rechte auf Datenbankdateien bei einer Migration des „windvsw1“ auf einen neuen DATEV-Server hat.

Problem

Eigentlich funktionierte in DATEV nach der Migration alles, bis auf den Druck in allen möglichen Programmen.

Hierbei kam dann meistens die Fehlermeldung mit der Nummer #REB22056 oder mit der Nummer #PS00010:

Es trat ein Problem beim Anlegen eines Dokuments mit dem PrintService auf.

oder:

Die Layout-Datenbank konnte nicht geöffnet werden.

…

Es ist ein Fehler in der Verbindung mit dem Conserve Service aufgetreten.

Erste Ansätze und Problemverlauf

Entsprechend dem Dokument unter https://www.datev.de/dnlexom/client/app/index.html#/document/1046281 habe ich mich im DATEV-Daten-Ordner auf die Suche nach komprimierten Dateien/Ordnern gemacht. Die Suche blieb allerdings erfolglos.

Nachdem ich noch verschiedene andere Sachen ausprobiert habe und bei diesem Dokument landete, wurde noch ausprobiert Crystal Reports neu zu installieren, da dieses innerhalb von DATEV für den Druck gentuzt wird. Aber auch das kann man sich schenken.

Laut einem Ratschlag habe ich dann noch „SMB1.0“ installiert, sowohl auf dem Datenbank- wie auch dem Terminalserver, und neu gestartet. Aber auch das brachte nichts. Da dies das Problem aber auch nur verschoben hat, weiß ich nicht ob das wirklich nötig ist.

Die Fehlermeldung hat sich dann zwar geändert, aber der Druck ging dann immer noch nicht. Es wurde immer ein Fehler mit der Layout-Datenbank bzw. mit den Rechten betreffend dieser gemeldet.

Ein Blick in den „DATEV SQL Manager“ offenbarte dann, dass es ein Problem mit der Verbindung zu der entsprechenden Datenbank gab:

Die Rechte auf den Ordner „windvsw1“ wurden nochmal „korrigiert“ und an alle Unterordner durchgereicht, sodass alle DATEV-Benutzer defintiv ausreichende Berechtigungen auf diesen Ordner als Netzlaufwerk bekommen. Dies war rückwirkend betrachtet dann wohl keine gute Idee, aber dazu im nächsten Punkt mehr.

Danach sollte über den „DATEV SQL Manager“ der SQL-Server neu gestartet werden. Stattdessen wurden versehentlich alle Datenbanken ausgehangen, aber der Vorgang noch abgebrochen und nach einem Neustart des Servers waren diese fast alle rot, was aber gar nicht am versehentlichen Aushängen lag:

Lösung und Ursache

Irgendwann kam ich auf die Idee, auf einer vom Netzwerk getrennten Kopie des virtuellen Servers, dann nochmal genauer mit den Rechten der betroffenen Ordner und Dateien rumzuspielen. Ein paar Datenbanken waren nämlich trotz allem fehlerfrei verbunden und ließen sich auch erfolgreich prüfen. Deshalb habe ich mir die Sicherheitseinstellungen dieser Datenbank-Dateien nochmal genauer angesehen und mit denen der nicht mehr funktionsfähigen Dateien verglichen und dabei einen wichtigen Unterschied festgestellt: Es gibt den Benutzer MSSQL$DATEV_DBENGINE bei den noch laufenden Datenbanken, bei den anderen nicht:

Der MS SQL-Server nutzt hier für den Zugriff auf die Datenbankdateien nämlich einen „virtuellen Account“. Das Ätzende daran ist, dass man diesen über die Sicherheitseinstellungen des Ordners nicht manuell hinzufügen kann und bei der Einrichtung des Daten-Ordners auch gar nicht auf dem Schirm hat. Denn diesen Benutzer gibt es ja nicht wirklich, zumindest steht er nicht in der Benutzerverwaltung und man kann ihn nicht selber zu den berechtigten Benutzern für den Ordnerzugriff hinzufügen. Man findet diesen aber in der Diensteverwaltung bei den SQL-Diensten:

Der Klassiker beim Migrieren des Ordners war dann wohl, dass beim Kopieren der Dateien bzw. des Ordners, anscheinend recht willkürlich, bei der ursprünglich einzigen nicht laufenden Datenbank dieser Benutzer keine Rechte hatte. Durch das Überschreiben der Nutzerrechte beim Versuch den Fehler los zu werden, wurde dieser dann auch bei den meisten anderen Datenbanken entfernt. Komischerweise auch wieder nicht bei allen… Sonst hätte ich den gar nicht mehr bei einer Datenbank-Datei finden können.

Da man den selber ja nun gar nicht hinzufügen kann, hilft es nur entsprechend einer weiteren Anleitung von DATEV vorzugehen, die man unter https://www.datev.de/dnlexom/client/app/index.html#/document/1001827 findet und die Rechte mit Hilfe eines speziellen Tools von DATEV namens „vatool“ neu zu setzen. Dort wird die Problematik mit den virtuellen Accounts und dem Vererben der Ordnerrechte auch beschrieben. Ich vermute VA steht in diesem Zusammenhang für „virtual accounts“.

Nachdem man das Tool heruntergeladen und entpackt hat, startet es und man muss nur den Pfad zum DATEV-Datenverzeichnis angeben und auf Start klicken. Danach werden die Rechte für alle Datenbanken korrekt gesetzt. In diesem Fall waren das recht viele, denn wenn das Setzen nötig war zeigt das Tool unter „VA Rights“ ein „done“:

Wenn man dann den SQL-Server in dem „DATEV SQL Manager“ herunterfährt und dann wieder startet, dann sind die Datenbanken vermutlich immer noch rot markiert, aber durch ein mehrfaches Anklicken wurden diese jeweils wieder grün und man konnte die Verbindung zu diesen über den Punkt im Kontextmenü erfolgreich testen.

Einige Datenbanken ließen sich aber trotzdem immer noch nicht erfolgreich testen.

Letztendlich half dann nur noch eins: Den kompletten Server einfach mal durchstarten, damit diese Datenbankdateien mal kurz nicht im Zugriff von Windows oder was auch immer sind.

Danach lief es zum Glück wieder!

Fazit

Bei einer DATEV-Migration sollte man vermutlich einfach grundsätzlich das erwähnte „vatool“ nutzen um die Rechte auf den Daten-Ordner bzw. die darin liegenden Datenbank-Dateien richtig zu setzen. Das spart Zeit und Nerven (und Geld für einen unbrauchbaren DATEV-Support).