einige Benutzer können keine Mails senden, bzw. tauchen diese ohne Fehlermeldung nicht im Ausgang auf

  • Ich habe hier ein sehr merkwürdiges Phänomen

    Ein einzelner David Nutzer kann von keinem seiner Endgeräte mehr Mails senden, egal ob von einem seiner Rechner, oder von seinem per EAS angebundenen iPhone.
    Die Mails verschwinden einfach im Nirvana und sind anschließend unauffindbar.
    Heute morgen um 09:23 hat er die letzte Mail erfolgreich versenden können und vor rund 30 Minuten hat er mich auf das Problem angesprochen.

    Änderungen an seinem Benutzeraccount habe ich in letzter Zeit keine vorgenommen. Änderungen am David Server ebenfalls seit Tagen keine mehr.

    Wenn ich eine Mail in seinem Namen mit @@own benutzername@@ versende wird die ordnungsgemäß versandt und taucht auch ordnungsgemäß in seinem Ausgang auf.

    Den David Server habe ich bereits einmal neu gestartet, das hatte allerdings keine Auswirkungen.

    Hat jemand eine Idee wo ich noch nach gucken könnte?

    Nachtrag:
    Ich habe mal getestet ob der Nutzer ein Dokument über neu Dokument in seinem Ausgang erzeugen kann. das geht ebenfalls nicht, eine bestehende Mail oder ein bestehendes Dokument kann er allerdings in seinen Ausgang kopieren.
    Als Admin kann ich auch Dokumente in seinem Ausgang anlegen.

    Sein Ausgangsarchiv scheint mir also auch nicht beschädigt zu sein. aber mir geht echt die Phantasie aus wo ich noch nach gucken sollte...

    Einmal editiert, zuletzt von riawie (13. Februar 2023 um 13:03)

  • hmm, jetzt meldet sich ein zweiter Nutzer mit dem gleichen Problem und gibt an das dieses seit etwa 12:30 besteht, wobei er heute vorher noch keine Mails verschickt hat.
    Es scheint also das Problem besteht doch nicht nur isoliert bei einem Nutzer :(

    Viele andere Nutzer sind allerdings während dessen fleissig und erfolgreich am eMails verschicken...

  • Merkwürdig - aber ich würde mal folgendes überprüfen:

    Im David Admin solltest Du im Ausgangsbuch feststellen können, in welchem Verzeichnis die versendete Mail liegt. Diese suchst Du im David Client heraus, klickst mit der rechten Maustaste drauf, Eigenschaften - Parameter - Erweitert - Kommunikation

    Dort solltest Du ziemlich genau sehen können, was mit der Mail passiert ist.

    So profane Lösungen wie eine Regel: "Wenn Mail, dann löschen" hattest Du sicherlich schon überprüft... :)

  • wordplex die Nachrichten der betroffenen Nutzer verschwinden leider kommentarlos im Nirvana und kommen nirgends an.
    Sprich es gibt auf dem Server keinerlei Spuren dieser Nachrichten.
    Auch die David Clients zeigen dabei keinerlei Fehlermeldung an.
    Regeln gibt es dazu auch keine die sowas erklären könnten, wobei die aber eh erst greifen würden wenn denn irgendwas davon je auf dem Server verarbeitet werden würde.

  • Inzwischen habe ich eine ganze Reihe an betroffenen Nutzeraccounts identifiziert wo das Problem auch weiterhin besteht.

    Während dessen können aber sehr viele andere Nutzer wieterhin fleissig Mails verschicken.

    Es spielt dabei auch keine Rolle auf welchem Rechner der jeweilige Nutzeraccount genutzt wird.
    Ich habe einen Rechner von dem auch ich jetzt alle Accounts durchteste und mich dazu mit den Jeweiligen Accounts am David Server anmelde. Der Rechner und auch der dortige Windows Nutzer ist also immer der gleiche, nur der David Client wird mit unterschiedlichen David Benutzern am David Server angemeldet. Damit lassen sich die Probleme der Nutzer an ihren jeweiligen Rechnern ebenso reproduzieren, wie sich auch das Versenden von Mails der nicht betroffenen Nutzer dort reproduzieren lässt.
    Die Ursache muss also irgendwo am jeweilgen David Benutzer, dessen Archiv oder irgendwas anderem auf dem David Server hängen.

  • Also dass die Ursache bei einem Benutzer bzw. dessen Archiv liegt, glaube ich weniger, denn das hieße ja, dass derselbe Fehler plötzlich mehrfach auftritt. Das ist wenig wahrscheinlich.

    Ich würde mal ganz anderes testen: überprüfe die Platte bzw. das Volume, auf dem David liegt, mal mit chkdsk. Nicht dass die Platte ein "Loch" hat und dort das Nirwana zu suchen ist.

  • wordplex Nicht bei einem einzelnen Nutzer und dessen Archiv, sondern wenn dann bei den betroffenen Nutzern und deren Ausgangsarchiven. Wobei mir natürlich auch nicht klar ist wie das bei so vielen Nutzern aufgetreten sein soll.

    Die Platte und auch das Filesystem darauf sind übrigens in Ordnung.

    Die Nutzer müssen irgendwas gemeinsam haben was andere - nicht betroffene - Nutzer nicht haben, ich kann aber bislang nichts entdecken, außer das es eben bei vielen auftritt und bei vielen anderen nicht.

  • wordplex nein, die Mails kommen zu keiner Zeit im Transit an.
    Ich habe das jetzt aber tatsächlich auch noch mal mit gestopptem Postman getestet, das ändert allerdings nichts. Es sind keine Spuren dieser Mails zu sehen.
    Weder bei Mails nach extern - nur da hat der Postman überhaupt etwas mit zu tun - noch bei internen Mails (wobei ich mich frage ob die überhaupt je im Transit landen würden)

    Die Mails verschwinden nach dem klick auf senden schlicht sang und klanglos.

    Im Explorer kann man auch sehen das dabei im out Archiv des jeweiligen Benutzers keine Datei erzeugt oder geändert wird.
    Das liegt aber augenscheinlich nicht an mangelnden schreibrechten für den Client, denn er kann ja Mails, Dokumente, oder was auch immer, aus anderen Ordnern dort hinein kopieren und die erscheinen dann auch korrekt als Datei im Archiv und haben dann auch eine Änderung der archive.dat zur Folge.

  • Na ich bin mal gespannt was Tobit dazu einfällt, eine Support Anfrage läuft.

    Bei den betroffenen Nutzern kann man wie sich inzwischen herausgestellt hat auch keine Dokumente in ihren Archiven anlegen (Steuerung + Umschalt + D) und dabei ist es egal ob sie das selbst versuchen, oder ein nicht betroffener Nutzer der bei ihnen Schreibrechte hat.
    eMails, Dokumente oder Dateien von wo anders kann man aber problemlos in die Archive ziehen, kopieren oder schieben und zwar sowohl die betroffenen Nutzer selbst als auch andere Nutzer welche dort schreibrechte haben.

    Schon sehr merkwürdig das ganze :o
    Vor allem weil es hier in den letzten Tagen keinerlei Konfiguartions oder Software Änderungen gab.

  • hmm, seltsam

    Seit 20:41 werden plötzlich alle Mails, die den Tag über spurlos verschwunden sind, vom David Server abgearbeitet und intern zugestellt oder extern versendet.

    Es wurde allerdings bereits seit 1 1/2 Stunden nichts mehr auf dem Server gemacht um das Problem aufzuklären, keine Dienste gestoppt oder gestartet und auch sonst nichts.
    Auch laufen um diese Uhrzeit keinerlei automatische Jobs auf dem Server.
    Auch die Windows Ereignis Anzeige liefert nichts was da als Trigger dienen könnte.

    Da die Clients allerdings auch alle lange Feierabend haben müssen die ganzen verschollenen Mails wohl heute über Tag doch alle irgendwo auf dem David Server gelandet sein, auch wenn ich sie dort nirgends entdecken konnte...?

  • Tobits Vorschlag dazu war:

    Im Verzeichnis david\apps\faxware\out\api nachgucken ob dort Dateien vorhanden sind.
    Wenn ja, verschieben und testen ob sich wieder Mails verschicken lassen.

    Ich nehme an dann wären die gestern verschollenen Nachrichten endgültig weg gewesen?
    Ich habe gestern allerdings auch immer nur im Bereich apps\postman geguckt, nicht im Bereich aps\faxware, so das ich keine Ahnung habe ob und wie voll der Bereich apps\faxware gestern war.

    Sollte sowas noch mal vorkommen werde ich da halt gucken.
    Einstweilen habe ich Tobit mal geschildert das und wie es sich gestern Abend plötzlich ohne weiteres zutun aufgelöst hat und gefragt ob man eine Idee habe wie sich noch nach der Ursache suchen lassen könnte. Mal sehen ob es noch eine Möglichkeit gibt hinter die Ursache zu kommen.
    Ansonsten bleibt nur abwarten und Tee trinken ;)

  • riawie 2. März 2023 um 17:20

    Hat den Titel des Themas von „einzelner Benutzer kann keine Mails mehr senden“ zu „einige Benutzer können keine Mails senden, bzw. tauchen diese ohne Fehlermeldung nicht im Ausgang auf“ geändert.
  • Das Thema hat heute eine Fortsetzung bekommen und konnte dabei nun durch genaue Beobachtung auch aufgeklärt werden.

    Ursache für das Problem war ein Nutzer welcher in einem seiner Eingangs-Ablagearchive mit etwa 7500 Einträgen die Idee hatte etwa 4500 Nachrichten welche dort als ungelesen standen als gelesen zu markieren.
    Da wir Message Tracking intern aktiv haben hat sein Client dann dem David Server brav für jede - von einem internen Absender stammende - dieser Mails mitgeteilt das sie gelesen wurde, was dazu führte das in einer der 4 Warteschlangen welche der David Server meiner Beobachtung nach verwaltet dann erst mal Stau war, denn rund 3500 der Nachrichten kamen von internen Absendern und der David Server musste nun für jede dieser Gelesen Benachrichtigungen nachschauen ob der Absender seine Kopie noch irgendwo herumliegen hat und bei dieser den Status im Message Tracking nachtragen.
    Ich weiß nicht ob es an der Größe unseres Systems bzw. der darin gespeicherten Mails liegt, oder ob es normal ist, aber eine Beobachtung des Ordners in welchem die Warteschlange liegt hat gezeigt das der Server rund 3 Sekunden pro Benachrichtigung brauchte um sie abzuarbeiten. Im Ergebnis wart er also heute nicht ganz 3 Stunden damit beschäftigt diese Benachrichtigungen abzuarbeiten und hat anschließend genau wie es eigentlich gedacht ist auch die von unseren Nutzern versandten eMails ausgeliefert welche nach der Benachrichtigungsorgie bei ihm eingeliefert wurden.

    Es ist keine Mail verloren gegangen und alle Mails wurden ausgeliefert.
    3/4 unserer Nutzer konnten wie schon beim ersten mal während dessen ganz normal weiter Mails versenden und empfangen.
    Unschön ist dabei zum einen das dieses Wust so langsam abgearbeitet wurde, ca 1/4 unserer Nutzer während dessen darauf warten musste das ihre zwischenzeitlich versandten bzw. beim David Server eingelieferten eMails auch tatsächlich versandt wurden und zum anderen das der David Server augenscheinlich alle Nutzer fix jeweils einer von 4 möglichen Warteschlangen zuweist statt das abhängig von deren aktuellem Füllstand zu tun.
    Weiterhin ist unschön das alle dann irgendwann abgearbeiteten Mails dann so behandelt wurden als seien sie erst zu dem Zeitpunkt versandt worden zu dem sie dann aus der Warteschlange verarbeitet wurden, statt zu dem Zeitpunkt wo sie ursprünglich vom Client in die Warteschlange eingeliefert wurden.

  • Interessantes Phänomen, danke für die Info. Und schön, dass es sich aufklären ließ. An solche Sachen denkt man ja in der Regel nur, wenn man schon einmal davon gehört hat, daher finde ich diese Praxisberichte immer sehr nützlich.

    Generell empfinde ich David leider als nicht sonderlich großzügig mit Rückmeldungen darüber, was er gerade so treibt. Kann man auch z. B. bei größeren Verschiebe-Aktionen im Client sehen oder beim Sortieren von Ein- oder Ausgangsbuch im David Admin. "...reagiert nicht" sagt Windows, und irgendwann kommt das Programm dann doch zurück. Hätte man schöner lösen können, aber gut - man gewöhnt sich dran. Wenn man's denn weiß. ;)

  • Ihr könnt dem David Server für die Zukunft aber auch ein bisschen auf die Sprünge helfen. In der David.ini sind einige Parameter die zu Netware Zeiten relativ hoch angesetzt waren um die damalige Hardware nicht zu überfordern. Da kann man m.E. heute die Werte deutlich niedriger ansetzen.

    So sieht das Ganze bei mir aus:

    TLDControlDelay = 20

    ; Default is 2000 (milliseconds)

    ; Time between scans in the directories of the Transport Layer Drivers

    MainTLDControlDelay = 20

    ; Default is 2000 (milliseconds)

    ; Time before starting scanning of Transport Layer Drivers

    GetFirstFreeTLDDelay = 10

    ; Default is 1000 (milliseconds)

    ; Time before getting the first free Transport Layer Driver

    JOBFreeDelay = 15

    ; Default is 1500 (milliseconds)

    ; Time between next reading when Job-File-Entry is free

    ;JOBDelay = 10

    ; Default is 10 (milliseconds)

    ; Time between next reading when Job-File-Entry is used

    ScanDelay = 50

    ; Default is 500 (milliseconds)

    ; Time between checking the services of David

    ; (e.g. FileScan, Import, Queue)

    QueueScanDelay = 20

    ; Default is 2000 (milliseconds)

    ; Time between polling tries of David queues


    Vielleicht muss man sich auch an die eigenen Werte mal "rantasten". Nach jeder Änderung den ServiceLayer neu starten nicht vergessen.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!