IT

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).

 

Tobias Langner

Tobias Langner

Ich arbeite seit mehreren Jahren als Software-Release-Manager, zuvor als IT-Administrator, bin ausgebildeter Fachinformatiker für Systemintegration und Studium-"Pausierer" an der FernUni Hagen. Achtung: Für die Richtigkeit der zur Verfügung gestellten Informationen, Skripte, etc. übernehme ich keine Gewähr. Deren Nutzung geschieht ausdrücklich auf eigene Gefahr!

Alle Beiträge ansehen von Tobias Langner →

4 Gedanken zu “DATEV-Datenbank: Rechte für Datenbankdateien zerschossen und nichts geht mehr

  1. Tach Tobias,

     

    kleine Info von Fachinformatiker (auch wenn mein IHK Abschluss schon lange her ist) zu Fachinformatiker:

    Der virtual Account wird nicht direkt durch DATEV gesetzt. Dies passiert ganz normal beim Setup des SQL Servers und wie die Instanz benannt wird. Infos hierzu findet man auch unter https://docs.microsoft.com/de-de/sql/database-engine/configure-windows/configure-windows-service-accounts-and-permissions?view=sql-server-ver15

    In der Regel steuert man die SQL Server Dienste auch nicht über 3rd Party Tools wie den DATEV SQL Manager, sondern sollte den SQL Srv Configuration Manager und das SQL Server Management Studio nehmen. Ist zumindest die 1. Wahl bei einem SQL Server Admin.

    In der Regel kopiert man auch im SQL Server Umfeld die DB Dateien nicht, wenn es von einer Maschine A auf eine Maschine B geht, sondern überlässt dies ein paar Backup Restore Prozessen.

    Vorteil bei einem nativen Restore ist auch, dass die „neu geschriebenen“ DB Dateien die richtigen Berechtigungen für die DB Engine erhalten.

     

    Viele Grüße und nicht von den Usern ärgern lassen

    Dirk

    1. Hallo Dirk,

      danke für den Hinweis. Ich habe das mal korrigert 😉

      Die eigentliche Migration wurde auch nicht von mir durchgeführt, sondern von einem Service-Unternehmen. Naja, ging wohl daneben.
      Wenn ich mich recht entsinne, dürfte auf dem Server aber gar kein Management Studio drauf sein, da der SQL-Server nur von der DATEV-Software genutzt und verwaltet wird und nicht wirklich als MS SQL-Server zur Verfügung steht. Kann mich aber auch irren.

      Schönen Sonntag noch.

      mfg
      Tobias

  2. Vor Kurzem hatte ich ein großes Problem mit dem Drucksystem in DATEV nach einer Datenbankmigration. Als jemand mit Grundkenntnissen in IT fühlte ich mich zunächst überfordert. Der Support war keine große Hilfe, da die Wartezeiten lang und die Kosten hoch waren. Deshalb entschied ich mich, das Problem selbst in Angriff zu nehmen. Ich recherchierte online und stieß auf Informationen über das virtuelle Konto „MSSQL$DATEV_DBENGINE“, das für den Zugriff auf die Datenbankdateien wichtig ist. Mir wurde klar, dass dieses Konto in meinen Sicherheitseinstellungen fehlte. Nach einigen Versuchen und Anpassungen gelang es mir, das Problem zu beheben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert