Beiträge von Ruegen

Versuchen kannst Du es. Aber bitte erst nach sorgfältiger Datensicherung.
Ist nur ein Client betroffen oder alle?

Es tritt noch ein Schönheitsfehler namens SQL Error 80004005 nach 15 Minunten Betriebszeit auf. Die SQL-Suche funktioniert trotzdem.

Die KI schlägt dazu folgenden Lösungsweg vor:
Der SQL Error 80004005 ist ein allgemeiner Verbindungskonflikt („Unbekannter Fehler / Zugriff verweigert“).

Dass der Fehler erst nach exakt 15 Minuten auftritt, liefert den entscheidenden Hinweis: [1]

Zu diesem Zeitpunkt greift das automatische Energie- oder Standby-Management des SQL Server Express, oder die Integrität des neu aufgebauten Suchindexes bricht ab. Da die Suche anfangs lief, sind die Zugriffsrechte korrekt, aber die Verbindung wird nach Inaktivität getrennt. [1]

Gehen Sie die folgenden drei Lösungsschritte durch, um den Fehler dauerhaft zu beheben:

1. Das „Auto-Close“-Feature im SQL Server deaktivieren (Hauptursache)

Der SQL Server Express hat eine Standardeinstellung namens AUTO_CLOSE. Wenn 15 Minuten lang keine Suchanfrage erfolgt, fährt der SQL Server die Datenbank im Hintergrund herunter, um RAM zu sparen. Tobit David verliert die Verbindung und meldet den Fehler 80004005.

1. Starten Sie das SQL Server Management Studio (SSMS).
2. Verbinden Sie sich mit Ihrer Instanz (z. B. .\DAVID).
3. Klicken Sie im linken Objekt-Explorer auf das Pluszeichen bei Datenbanken.
4. Machen Sie einen Rechtsklick auf die David-Suchdatenbank (meistens David_Search oder ähnlich benannt) und wählen Sie Eigenschaften.
5. Wechseln Sie links auf die Seite Optionen.
6. Suchen Sie in der Liste den Punkt Automatisch schließen (AUTO_CLOSE).
7. Stellen Sie diesen Wert unbedingt von True auf False.
8. Klicken Sie auf OK. [1]

Wiederholen Sie dies zur Sicherheit auch für die Systemdatenbank model.

2. Die Volltextdatenbank in David zurücksetzen

Durch die Neuinstallation des SQL-Servers passen die alten Index-Tabellen oft nicht mehr zum neuen Dienst, was nach einigen Minuten Laufzeit zu Abbruchen führt. [1]

1. Öffnen Sie den David.Administrator (dvadmin.exe).
2. Navigieren Sie im linken Baum zu System -> Datenbanken.
3. Machen Sie einen Rechtsklick auf die Volltextdatenbank und wählen Sie Zurücksetzen.
4. Starten Sie anschließend die Windows-Dienste SQL Server (DAVID) und David Service Layer einmal neu.
5. David baut den Index nun im Hintergrund sauber und fehlerfrei neu auf. [1]

3. Energiesparmodus der Netzwerkkarte / SSD prüfen

Falls die SQL-Instanz über die IP-Adresse oder ein virtuelles Netzwerkinterface angesprochen wird, trennt Windows nach 15 Minuten Inaktivität manchmal die Verbindung:

1. Öffnen Sie den Windows-Geräte-Manager.
2. Machen Sie einen Rechtsklick auf Ihre Netzwerkkarte -> Eigenschaften.
3. Prüfen Sie den Reiter Energieverwaltung.
4. Deaktivieren Sie die Option: „Computer kann das Gerät ausschalten, um Energie zu sparen“.

Probieren Sie als Erstes das Abschalten von AUTO_CLOSE im SSMS. Bitte lassen Sie mich wissen:

• Konnten Sie die Option AUTO_CLOSE in der David-Datenbank finden und auf False umstellen?
• Tritt der Fehler nach dem anschließenden Dienste-Neustart weiterhin auf?

Der Fehler trat bei zwei Kunden mit identischer Hardware und identischen Betriebssystem auf
(Windows 11 Pro, alle Update aktuell)

Ich habe heute Morgen den SQL-Server Express 2017 noch einmal installiert und vorher bzw. während der Installation drei Fehlerquellen gefunden und behoben.

1. Die Formatierung der David Partition D: war 4K statt 64 k Blockgröße.
   Mit der kleinen Blockgröße haben SQL-Server gemäß Web-Veröffentlichungen manchmal Probleme.
   Lösung: David Dienste gestoppt, alle Daten der Partition auf andere Disk kopiert.
   D: NTFS formatiert mit 64K Blockgröße
   Daten inkl. David-Verzeichnis wiederhergestellt.
2. "Grant Perform Volume Maintenance Task"
   Sollte aktiviert sein, andernfalls Perfomance Probleme
3. Der SQL Server-Browser-Dienst muss mit installiert und automatisch gestartet sein

Dabei ist die zu kleine Blockgröße wohl die wichtigste Einflussgröße, denn der Fehler trat auch bei Verwendung der normalen Installationsroutine von David auf. CoPilot hatte diese Fehlerursache angezeigt ohne eine brauchbare Lösung vorzuschlagen außer Neuinstallation des Betriebssystems. Glücklicherweise hatte ich David auf einer separaten Partition installiert.

Hardware ist ein Wortmann PC Mini 6000 6.1 mit vorinstalliertem Windows 11 Pro.
... "Öfter mal was neues". Dieses SQL Problem hatte ich so in den letzten 16 Jahren noch nicht erlebt.

Vielen Dank an Euch für die Hilfe.

Ja, ist erfolgt.

Das Windows Ereignisprotokoll zeigt nach Neuinstallation des SQL-Servers folgenden Fehler:

"Fehlerhafter Anwendungsname: sqlservr.exe, Version: 2017.140.1000.169, Zeitstempel: 0x599d0bc0
Fehlerhafter Modulname: ntdll.dll, Version: 10.0.26100.8972, Zeitstempel: 0x59a29eb0
Ausnahmecode: 0xc0000005" ...

Hat dafür jemand eine Lösung?

Beides probiert - sowohl System als auch lokalen User mit Admin Rechten.

Trotz Neuinstallation startet der SQL Server Dienst nicht. "Kann den Dienst nicht starten -
Fehlercode 1067. Der Prozess wurde unerwatet beendet.".
Hat dazu jemand eine Idee?

Hatte schon des SQL Server deinstalliert und neu installiert - identisches Verhalten.
Windows 11 Pro, akuelles David.iso verwendet.

Gemäß Antwort auf eine KI-Anfrage ist die Html-Bearbeitung von Vorlagen und Textbausteinen im aktuellen Rollout nur noch den Adminstratoren zugänglich. Das war beim früheren David-Client nicht so, da gab es den Menüpunkt "Quelltext anzeigen". Und der Quelltext konnte bearbeitet im HTML-Format auch wieder in die aktuelle Vorlage integriert werden.
Gemäß KI-Antwort (Copilot) von heute Morgen soll es ab dem aktuellen Rollout einen Team-Administrator geben. Aber den habe ich noch nicht gefunden. ... Ergo: KI-Antworten sind oft sehr mit Vorsicht zu genießen.

Statt dessen funktioniert aber der von Wizzard gezeigte Weg gan zeinfach, auch für die von Tobit erstellten Textbausteine.
(Vorsicht, bei Textbausteinen und Vorlagen vor dem Ändern unbedingt eine Sicherungskopie erstellen).

P.S.: Bin seit gestern Nachmittag sehr knapp an Zeit, weil ich überraschend zu Entstörungs-Aufträgen weit fahren muss (oder besser gesagt: fahren darf). Bin daher wahrscheinlich erst nächste Woche (ab 9.2.26) wieder im Forum aktiv.

Interessant finde ich die ab Rollout 523 neue Möglichkeit, Benutzer temporär zu deaktivieren:

Kopie des Eintrags im aktuellen Tech Briefing:

Zitat

Temporäres Deaktivieren von TeamDavid Benutzern

[Blockierte Grafik: https://tsimg.cloud/77892-10814/rAIpgKt3pS2P1pm.jpeg]

Mitarbeiter, die für einen begrenzten Zeitraum ausfallen, lassen sich in der TeamDavid Benutzerkonfiguration sehr einfach temporär deaktivieren und bei ihrer Rückkehr wieder aktivieren, ohne die betreffenden Benutzerkonten dafür löschen zu müssen. Dazu steht im Kontextmenü eingerichteter Benutzer die Option »Benutzerlizenz deaktivieren« zur Verfügung.

Auf diese Weise deaktivierte Benutzer belegen keine TeamDavid Benutzerlizenz mehr und werden bei der Berechnung von sitecare und Backline Services wie Virus Protection etc. nicht berücksichtigt, verursachen also auch keine laufenden Kosten. In der Benutzerkonfiguration bleiben sie weiter eingetragen, sind dort jedoch als »Nicht lizenziert« gekennzeichnet. Sie können TeamDavid noch in eingeschränkter Weise nutzen, haben aber nicht mehr die Möglichkeit, Nachrichten zu erstellen oder zu versenden. Im Kontextmenü solcher nicht lizenzierten Benutzer ermöglicht die Funktion »Benutzerlizenz aktivieren«, das Ganze bei Bedarf ebenso einfach wieder rückgängig zu machen.

Danke für die Info. Ich sehe mir das am Donnerstag mal in Ruhe an.

Die Push up Sicherung in der Cloud ist überflüssig, wenn die StrongBox-Sicherung auf ein ausreichend geschütztes Medium erfolgt und zusätzlich etwa 1 x im Monat eine Auslagerungssicherung erfolgt.

Auslagerungssicherung bedeutet zum Beispiel, vorübergehend eine ausreichend große USB-Disk extern am David-Server anzuschließen und die letzte StrongBox-Datei darauf zu kopieren. Anschließend wird diese USB-Disk sauber vom David-Server getrennt und an einen anderen Ort - möglichst außerhalb des Betriebs - gebracht. Dieser Vorgang sollte mindestens 1 x im Monat erfolgen.

Nota bene: Verbleibt die Auslagerungssicherung im Betrieb, dann kann im Fall eines Brandes, eines gravierenden Wasserschadens oder bei Diebstahl der EDV-Hardware auch diese Sicherung mitunter nicht mehr genutzt werden. Sie sollte also zumindest nach dem Kopieren in einen anderen "Brandabschnitt" gebracht werden.

Digitales Signaturen machen Sinn für die wichtigsten eMail-Adressen. Sie schaffen erstens mehr Vertrauen beim Empfänger der eMails. Zweitens werden digital signierte eMails seltener beim Empfänger in den Spam-Ordner verschoben. Es ist daher leicht ersichtlich, dass digitale Signaturen für die ausgehenden Mails eines Webshop-Betreibers praktisch unverzichtbar sind.

Mit DMARC, SPF und DKIM habe ich mich bis heute noch nicht bewusst befasst. Bis jetzt genügte mit der Message Identifikation Service von David.

Folgende Reihenfolge empfehle ich für einen Serverumzug:
1) Beenden der Dienste Grabbing Server und Postman
2) Sicherung des aktuellen Stands von David via Strongbox
3) Ausführen des Programms David-Migration
4) Falls diese abbricht: Prüfen, ob die eMail-Konten bei Grabbing Server und Postman schon wiederhergestellt sind.
Falls nein, wiederholen des Migrationsprogramms mit Einstellung "nur Mailkonten wiederherstellen".
5) Mounten der gesicherten Strongbox-Datei und Nachtrag fehlender User-Archive
6) Prüfen der Zugriffsrechte

Ist das Zeitfenster für die Migration sehr knapp, dann kann man von der Standardeinstellung für die Migration abweichen und zum Beispiel nur die Mailkonten migrieren und dann die Benutzerarchive später per Strongbox nachtragen.

Nachteil eines Serverumzugs rein "via Strongbox" ist, dass manchmal die bereits eingetragenen Wiedervorlagen der User nicht mehr einwandfrei funktionieren. Auch die Regeln sollten überprüft werden. Denn wenn User manuell angelegt werden, dann stimmen auf dem Zielserver die eingetragenen Benutzer-IDs nur dann genau mit dem Quellserver überein, wenn die User haargenau in der gleichen Reihenfolge wie auf dem Quellserver angelegt werden. Hatte aber beispielweise auf dem Quellserver User 5 die ID 10014000 und hat nun auf dem Zielserver die ID 10004020, dann passt eine Regel nicht mehr, die Eingänge von User 1 auf User 5 verschiebt.

Denn David interessiert sich bei den Regeln nicht für die Namen (Eingang von "Müller" auf ein Unterverzeichnis von "Schmitz") von Archiven und Unterverzeichnissen. Statt dessen werden die Benutzer-IDs ausgewertet.

Zeitbedarf für eine vollständige Migration:
Dieser variiert sehr stark je nach Geschwindigkeit der CPUs, Speichermedien und Netzwerkkarten.
Als Anhaltswert kann knapp eine Stunde pro 30 GB angenommen werden. Bei 10 GB/s LAN-Karten geht es deutlich schneller.

Die nötigen Zeiten sowohl für eine David-Migration als auch für Strongbox-Sichern oder -Wiederherstellung lassen sich verkürzen:
Dazu ist es lediglich nötig, als Vorbereitung bei allen Eingängen und Ausgängen die automatische Ablage nach Jahren (!) zu aktivieren. Die Voreinstellung "Nach 3 Monaten" hat sich als praktisch erwiesen. Dann die Datenbereinigung ein oder zweimal durchlaufen lassen. Das kann im laufenden Betrieb geschehen.
Der Effekt ist, dass nun mitunter mehr als tausendfach weniger Dateien beim Serverumzug bewegt werden müssen und auch die Gesamtgröße der Daten merklich kleiner ist. Das beschleunigt StrongBox-Vorgänge und David-Migration deutlich.
Auch die Gesamtsicherung des Mailservers, zum Beispiel mit Acronis, geht danach schneller.

Eigentlich ist das beschriebene Verhalten schon seit längerem so, auch in der Client-Version vor David.
Nur im ganz alten David-Client waren die Vorlagen anders gestaltet.

Es ist mit HTML normalerweise möglich, diese Vorlagen individuell anzupassen oder eigene, einfacher strukturierte Vorlagen zu generieren.
Hab's früher öfter gemacht, muss mich aber morgen früh noch mal darin einlesen und das bei Team ausprobieren.
Melde mich, sobald ich ein brauchbares Ergebnis habe.

Hallo JS,
werden die Vorlagen und Textbausteine von Tobit verwendet oder eigene?

Hallo AdminDV,
am einfachsten geht das, wenn Du für Ein- und Ausgänge die automatische Ablage nach Jahren aktivierst.
Denn dann siehst Du die Jahrgänge, die älter als 10 Jahre sind und kannst diese löschen.

Eine Beschränkung der Postfachgröße macht wenig Sinn. Denn sobald die Schranke erreicht wird werden neue eMails an dieses Postfach nicht mehr akzeptiert. Das aber kann nicht die Lösung sein.

Manchmal ist der Posteingang auf einen IMAP-Server gelegt. Auch das ist nicht ratsam, weil es viel zu große Benutzerarchive erzeugt und dadruch David stark verlangsamt.

Zitat von ATH-David

...

Wie bekommt man die Daten am besten migriert? Einfach den David Ordner kopieren und alles ersetzen möchte ich jetzt erstmal nicht, da ich nicht weiß welche DLL's und ähnliches sich dann in die Quere kommen wegen Alt/Neu. Ich habe von dem Migrationstool gelesen, finde aber nur Erwähnungen, keine Pfadangaben oder Downloadlinks dazu. Wäre das hier hilfreich?

...

Grüße

Hallo ATH-David, bei einer Migration könnten wir helfen. Dazu wird ein spezielles Tool verwendet, das nur an Tobit-Partner geliefert wird (eine Migration-Lizenz mit zugehörigen kleinen Programm). Das Migration-Tool legt die Windows-User auf dem neuen Server an sowie deren Benutzerarchive im David einschließlich aller Regeln und Verteilvorgaben. Im gleichen Durchlauf werden die Postfächer im Grabbing-Server und im Postman identisch zum Ursprungsserver eingerichtet.
Wenn die Datenquelle nicht beschädigt ist dann macht diese sogenannte David-Migration weniger Arbeit als alle anderen Varianten.

Das geht am besten "häppchenweise": User für User nacheinander wiederherstellen. Dann die Verzeichnisse unter Gruppen, falls vorhanden und die Adressen. Es kann auch bei alten Installationen nicht schaden mal nachzusehen, ob sich unter Eingang und Ausgang Kopien anderer User-Archive befinden. Das passierte früher gelegentlich. Die benötigen unnötig Zeit beim Wiederherstellen.

Eine pcvisit Fernwartung wird nicht installiert. Es wird nur während der Fernwartung eine kleine Datei vorübergehend im Arbeitsspeicher ausgeführt. Nach Ende der Fernwartung löscht sich der Eintrag vor selbst aus dem Arbeitsspeicher.
Ist auch das bei Ihnen unzulässig? --

Ist in dem eMail-Konto des betroffenen Benutzers vielleicht eine Zieladresse angegeben?

Vorsicht bei Weg 2:
David ist ein Filesystem. Das bedeutet, dass zu jedem Eintrag ein Pfadbezug mit Namen des aktuellen David-Servers existiert.
Nach Kopieren eines David-Archivs auf einen neuen Server muss dieser Server exakt den gleichen Namen haben wir der alte Server.
Damit beide im LAN existieren können muss ergo der alte Server umbenannt werden. Vorher einfach die David-Dienste beenden.
Andernfalls gibt es sehr zeitraubende Nacharbeiten.

Was ohne Migration geht, ist der Import via Strongbox gesicherten Daten auf einen neuen Server.
Aber dabei müssen die Postman-Einträge neu gesetzt werden.

User 10000000\ ist der User Template, also der vordefinierte Default-User.
War das beabsichtigt? Oder ist das nur ein fei gewähltes Beispiel?

Ursache könnte ein Rechte-Problem sein.
Es wird erfahrungsgemäß am schnellsten zu lösen sein, wenn ich mir den Status per Fernwartung ansehen kann.