Neu Fehlermeldung "Es wurde im SQL-Server kein Backuppfad hinterlegt" => kein Schemaupdate möglich

[ThomasVoelker]

Das ist eine Referenz von https://forum.jtl-software.de/threa...hinterlegt-kein-schemaupdate-moeglich.211067/ - da kann ich leider nicht aktualisieren.

Beim Upgrade auf Version 1.9.x trat wieder dasselbe Problem auf. Folgende Umgebung:

• SQL Server im Netzwerk auf Windows Server Core (wahrscheinlich unerheblich)
• weitere Datenbanken und Benutzer auf SQL-Server vorhanden
• Benutzer JTL ist DBO der JTL-Datenbanken, hat aber im System keine zusätzlichen Rechte

Das Schemaupdate konnte schließlich durchgeführt werden, nachdem der Benutzer auf dem Server der SysAdmin-Rolle hinzugefügt wurde.

 

[John]

Das scheitert regelmäßig, wenn man auf einem Windows Client ein Update der DB machen will, die DB selbst aber auf den Server läuft.
Du startest mit dem Versuch des Updates das JTL Wawi DB Tool im Benutzerkontext des lokalen Users, versuchst dann aber das automatisches Backup auf dem Server abzulegen, wo dem User aber Schreibrecht nach typischerweise
C:\Program Files\Microsoft SQL Server\MSSQLxx.JTLWAWI\MSSQL\Backup fehlen.

Starte die Wawi DB Updates nur über eine Wawi Instanz auf dem Server, auf dem auch die DB läuft.
Alles andere macht Probleme und ist von JTL weder berücksichtigt, noch freigegeben. Es kann also auch mal ein Backup daneben gehen und das will man nicht wirklich...

 

[recent.digital]

Das Backup kann auch gerne mal testweise wieder eingespielt werden, damit hat man ein Stück mehr Sicherheit.

 

[John]

Jo. Aber bitte auf einem anderen System.

 

[ThomasVoelker]

Das scheitert regelmäßig, wenn man auf einem Windows Client ein Update der DB machen will, die DB selbst aber auf den Server läuft.
Du startest mit dem Versuch des Updates das JTL Wawi DB Tool im Benutzerkontext des lokalen Users, versuchst dann aber das automatisches Backup auf dem Server abzulegen, wo dem User aber Schreibrecht nach typischerweise
C:\Program Files\Microsoft SQL Server\MSSQLxx.JTLWAWI\MSSQL\Backup fehlen.

Starte die Wawi DB Updates nur über eine Wawi Instanz auf dem Server, auf dem auch die DB läuft.
Alles andere macht Probleme und ist von JTL weder berücksichtigt, noch freigegeben. Es kann also auch mal ein Backup daneben gehen und das will man nicht wirklich...

Nein.

Der Server ist eine Core-Installation, da läuft die WAWI sowieso nicht. Sicherungen auf dem Server mit TSQL werden im Sicherheitskontext des Dienstbenutzers durchgeführt - der hat Berechtigungen im Verzeichnis. Mit TSQL ausgelöste Sicherungen auf den Pfad funktionieren auch. Davon abgesehen: das Zwangsbackup hatte ich abgeschaltet. Die lokale Wawi-instanz wird zwar im Sicherheitskontext des angemeldeten Benutzers ausgeführt, dieser wird allerdings nur bei Anmeldung am Server mit SSPI an diesen weitergereicht - und das läßt sich mit der Wawi garnicht konfigurieren, sondern die verwendet immer einen SQL-Server-Benutzer. Aber auch mit SSPI erfolgt der Sicherheitstoken nur zur Authentifizierung und es findet keine impersonization statt. Dementsprechend spielen auch die Berechtigungen des Endbenutzers keine Rolle beim Zugriff auf den Pfad auf dem Server. (Fun-Fact: hatte das Update als Domänenadmin gestartet und der hat auf dem Server Schreibrechte in dem Verzeichnis und über Netz grätscht da auch die UAC nciht rein, die lokal die Adminrechte entfernt)

Den Thread habe ich aufgemacht, um den Post zu finden, wenn ich das nächste Mal nach der Fehlermeldung google und nicht nur meinen alten Thread. Ich hatte einfach keine Lust, wieder einen Server mit Desktopumgebung aufzusetzen, die DB dorthin zu schieben, zu aktualisieren und das ganze wieder zurückzuschieben, deswegen habe ich das diesmal an den Support eskaliert, der mir gesagt hat, für Core würde kein weiterführender Support geleistet, aber trotzdem gute Hinweise gegeben hat, die mich schlußendlich zur Lösung führten, daß der in Wawi verwendete DB-Benutzer für das Schemaupdate erweiterte Rechte benötigt, die Sysadmin hat, dbo aber nicht.

Und weshalb das im Bug-Forum ist: ich halte das für einen Bug im Updater. Da wird der Code ne Exception wenn Berechtigungen fehlen und daraufhin kommt die Fehlermeldung. Die Fehlermeldung paßt hier aber nicht zu der Exception und das ist - lt. Support - ein Fehler von untergeordneter Relevanz.

 

[mh1]

(...)Die Fehlermeldung paßt hier aber nicht zu der Exception und das ist - lt. Support - ein Fehler von untergeordneter Relevanz.

Wow

 

[John]

...kommt drauf an, in welchen Kreisen.
Bei eComData und Co intern bestimmt ein Thema. Hier im Forum und beim normalen Nutzer eher nicht.

Ganz ehrlich: Ich bin bei der Erklärung auch ausgestiegen.
Für mich gilt weiterhin praxisrelevant: Updates nur auf der Wawi, die auf dem Server läuft.

 

[ThomasVoelker]

...kommt drauf an, in welchen Kreisen.
Bei eComData und Co intern bestimmt ein Thema. Hier im Forum und beim normalen Nutzer eher nicht.

Ganz ehrlich: Ich bin bei der Erklärung auch ausgestiegen.
Für mich gilt weiterhin praxisrelevant: Updates nur auf der Wawi, die auf dem Server läuft.

Eben. Ist für mindestens 95% der JTL-Netzer so nicht relevant und daher als Fehler von untergeordneter Bedeutung - würde ich an Stelle von JTL genauso einschätzen. Und da jetzt klar ist, daß es sich um eine Berechtigungssache am Server handelt, es also einen Workaround gibt (der wenn's hochkommt eine Minute dauert), falls doch mal jemand betroffen ist, ist die Behebung noch weniger notwendig.

 

[mh1]

Und da jetzt klar ist, daß es sich um eine Berechtigungssache am Server handelt, es also einen Workaround gibt (der wenn's hochkommt eine Minute dauert), falls doch mal jemand betroffen ist, ist die Behebung noch weniger notwendig.

Wenn man den JTL Datenbankbenutzer wie von JTL dokumentiert in die processadmin Rolle aufnimmt gehts auch.
Zumindest hatten wir hier bislang keine Meldung bzgl. fehlender Berechtigungen (möglich, dass es in aktuellen Wawi Versionen anders ist).

ALTER SERVER ROLE [processadmin] ADD MEMBER [JTL-Datenbankbenutzer]