starte ich die sl.exe als admin, so wird sie scheinbar schnell wieder beendet - zumindest finde ich sie im Task-Manager danach nicht.
Im MS SSMS sehe ich erwartungskonform auch keine Datenbanken (bzw nur die system databases master, model, msdb, tempdb)
Danke für die Mühe, das mit der Größe kann blanker Zufall sein.
Der Nutzer, den ich im david Client verwende, ist wohl der David-Administrator:
Auf dem Server-System (Windows 10, aber auf dem System läuft eben die david-Server testinstanz) ist er Administrator (Allerdings UAC aktiv). Im david.Administrator hat der zugeordnete david-Nutzer unter "Rechte" alles aktiviert.
Das serverseitig gemountete Image ist für den David Administrator ebenso freigegeben wie für alle Nutzer. Interessant ist: Offenbar meint "alle Benutzer" eigentlich "alle anderen Benutzer", denn wähle ich nur dies, sieht der verwendete Nutzer die gemountete Strongbox nicht.
Das habe ich bereits gemacht, im Wesentlichen basierend auf http://m-vena.de/files/Dokument…_2008R2_528.pdf
allerdings wurde weder wie dort beschrieben die Datenbank automatisch umbenannt (mir erschließt sich auch gar nicht, wie das der Anleitung nach passieren soll) noch behebt dies den 'arc'-Fehler.
olise wie starte ich den Service Layer als Administrator? Indem ich die Einstellung in den Windows_diensten anpasse, indem ich die .exe (welche?) händisch als Administrator ausführe, oder wie macht man das korrekt?
Mein Anliegen ist es, Mailbestände in nicht-Tobit-Format zu exportieren (MailDir, eml o.ä.), da einzusetzende Werkzeuge zu Analysezwecken die Tobit-Formate (stbox, Mailverzeichnis) nachvollziehbarer Weise wegen der geringen Verbreitung nicht unterstützen.
Danke @riawe, das hatte ich schon verstanden - das etwas nicht der Fokus bzw. primäre Zielsetzung ist muss aber nicht heißen, dass nicht ein cleverer Mensch hier dennoch eine Lösung kennt 
Beim Test mit mehreren Strongboxen unterschiedlicher Größe musste ich feststellen, dass die kleineren (wenige 100GB) problemlos serverseitig gemeountet (und im Client eingesehen) werden können, die größeren (> 900GB) allerdings werden (bei serverseitigem mount) im Client unvollständig angezeigt, insbesondere fehlt der Pfad "Benutzer" an offenbar allen Tagen bzw in allen Sicherungsständen. Mounte ich dieselbe Strongbox clientseitig, so ist dieser Pfad in der Anzeige jeweils da. Nun ist ein Restore bei bisherigen Test etwa 2-3mal schneller gewesen, wenn er direkt auf dem Server passiert, statt auf dem Client (was nachvollziehbar ist, da der Overhead der Client <-> Server Kommunikation eingespart wird). Hat jemand eine Idee, wie ich bei serverseitigem mount vollständig zugreifen kann? Oder liegt es am Ende gar an der Kapazitätsgrenze des bisher eingesetzten MSSQL Express 2017 von 10GB? Soweit ich das bisher verstanden habe ist die MSSQL-Datenbank ausschließlich der Suchindex und sollte an dieser Stelle keine Auswirkungen haben, oder?
Danke.
MSSQL 2017 Express hatte seine 10GB Grenze für den index erreicht. Ein Upgrade auf MSSQL2019 Standard hat die vorhandene Datenbank offenbar weiterhin im "Express"-Zustand belassen. Jetzt scheitere ich daran, die Datenbank neu anzulegen.
david3 meldet "invalid object name 'arc'" - soweit, so klar: Er will auf etwas, wohl eine Tabelle, zugreifen, das nicht existiert. Allerdings habe ich die Datenbank schon unter Status Monitor -> Volltextindex zurückgesetzt und auch das löst das Problem nicht.
Naja, der david-Client sieht die serverseitig gemounteten Strongboxsicherungen genauso wie Postfächer, dass das über IMAP nicht geht, finde ich nicht so selbstverständlich, wie du es beschreibst.
Das heißt es bleibt einem nicht anderes übrig, als jeden Backup-Stand einzeln wiederherzustellen und dann über IMAP freizugeben? Kein sehr schöner Workflow. Vielleicht hat ja doch noch wer eine bessere Idee.
Nachdem ich den Server neu aufgesetzt habe, ist mein zuvor hier beschriebenes IMAP-Problem gelöst. Nun teste ich StringBox-Backups und frage mich, ob und wenn wie ich auf diese über IMAP zugreifen kann. Im David-Client kann der Nutzer Remote Access für StrongBox-Pfade nicht setzen, weder von lokal gemounteten Strongboxen noch von serverseitig gemounteten, obwohl dem Nutzer unter "Rechte" alle Haken gesetzt worden sind.
