Beiträge von wlconsult

    Ich habe hier eine Kundeninstallation, bei der das Drag & Drop seit dem Update auf die 329/330 auf keinem Arbeitsplatz mehr funktioniert. Egal ob eine Nachricht lokal (auf das Desktop) oder in ein Netzwerklaufwerk gezogen werden soll, es werden immer nur Dateien mit den Header und Betreffdateien erzeugt, aber keine Inhalte mit kopiert. Ein Problem mit der Namensauflösung kann ich ausschließen, das funktioniert da einwandfrei.

    Ich habe dazu jetzt einen Case bei TOBIT aufgemacht.

    riawie wo Du recht hast, hast Du Recht :), man kann das Blau hier bei mir praktisch nicht erkennen. Ich musste ganz schön an den Monitoreinstellungen drehen, um den Unterschied zwischen dem dunklen Blau und dem Schwarz erkennen zu können.

    Allerdings ist das bei den mit der Rundesendefunktion versendeten Emails offenbar nicht so: Diese haben im Ausgang alle einen scharzen Betreff. Hier war TOBIT offenbar nicht ganz konsequent in der Umsetzung.

    Das muss dem Anwender gar nicht bewusst sein. Wenn er nämlich die Rundsendefunktion von DAVID ganz bestimmungsgemäß verwendet (also @@RND und dann Dateiname mit den Empfängern), um z.B. regelmässige Infos an alle seine Kunden zu verschicken, dann passiert exakt das o.A.:

    Hier werden die Empfänger beim Versand aus der Rundsendedatei extrahiert und vermeintlich eine eigene Email pro Empfänger erzeugt. Zumindest erweckt der DAVID den Anschein, denn im Ausgangsarchive finden sich nach dem Versand einzelne Nachrichten mit korrektem Empfänger in der An:-Spalte.

    DAVID versendet in diesem Fall aber nicht X einzelne Emails, sondern es wird so wie von Riawie beschrieben beim Versand per Smarthost eine Email an den Provider übergeben und entsprechend viele Einzelempfänger per Envelope dazu:

    "...

    (1) 235 2.5.0 Authentication successful. / Authentifizierung erfolgreich.

    (1) MAIL FROM:<xyz@t-online.de>

    (1) 250 2.1.0 Sender accepted. / Absender akzeptiert.

    (1) RCPT TO:<abc@muster-1.de>

    (1) 250 2.1.5 Recipient accepted. / Empfaenger akzeptiert.

    (1) RCPT TO:<def@muster-2.de>

    (1) 250 2.1.5 Recipient accepted. / Empfaenger akzeptiert.

    (1) RCPT TO:<ghi@muster-3.de>

    (1) 250 2.1.5 Recipient accepted. / Empfaenger akzeptiert.

    ..."

    Dadurch, dass die Nachricht nur einmal übergeben wird, kann in so einem Fall das An-Feld der Email natürlich nie den tatsächlichen Empfänger der einzelnen Email enthalten (den müsste ja dann der Provider dorthinein kopieren).

    Wenn der User vor dem Absenden der Rundsendung nicht z.B. seine eigene Emailadresse in das AN:-Feld geschrieben hat, dann bleibt das AN:-Feld bei all diesen Emails in so einem Fall leer und diese Emails werden dann von United Internet abgelehnt.

    Abhilfe in dem Fall nur: Auch bei bewussten Rundsendungen immer eine (eigene) Emailadresse ins AN:-Feld schreiben, dann klappts auch mit United Internet. Den DAVID für diese Fälle speziell auf Direktversand (also nicht Smarthost/Provider) umzukonfigurieren, funktioniert auch, weil der DAVID dann in dem Fall selbst Einzelemails verschickt. Das ist aber relativ viel Aufwand und bei kleineren Installationen, die sonst mit einen zwischengeschalteten Provider und per Smarthost versenden, meist auch gar nicht einfach mal so nebenbei möglich. Da holt man sich eher noch zusätzliche Probleme ins Haus.

    Viele Grüße

    Werner

    Es kann gut sein, dass der Provider (1&1) die Emails inhaltlich (wegen Links oder der Anhänge) nicht akzeptiert. In dem Fall wird die Kommunikation vom Providerserver abgebrochen und der Absender sieht dann im David-Client nur die o.a. Fehlermeldung, hat aber keinen weiteren Hinweis auf die eigentliche Fehlerursache.

    Genauer sehen kann man das im David.Administrator. Geh dort mal auf den Postman, mach einen Rechtsklick drauf und öffne dann den "Status Monitor" - "Communication". Versuche dann noch einmal, eine der abgelehnten Emails zu versenden. Im Status Monitor kannst Du dann i.d.R. bei einer Ablehnung durch den Providerserver den Grund schon im Klartext lesen. Werden dort nur wenig oder gar keine Ausgaben gemacht, musst Du u.U. in die Konfiguration des Postman gehen, dort den Reiter "Erweitert" anklicken und dann die "Monitor Informationen" auf mindestens "Normal" stellen. Dann die Konfiguration mit "OK" speichern und den Postman-Dienst neu starten. Dann noch mal den Monitor aufrufen und die Email erneut verschicken.

    Viele Grüße

    Werner

    Beim RT1202 kann nach einigen Jahren das eingebaute Netzteil schlapp machen. Das muss nicht schlagartig gehen, sondern erzeugt durch schlappe Kondensatoren erst einmal mehr Ripple. Dadurch hängt sich der Bintec nicht gleich komplett auf. Es scheint vielmehr so zu sein, dass das Signalprozessor-Board, das den Faxteil abdeckt, damit mehr Probleme hat. Bei einem meiner Kunden war das letztes Jahr auch so: Gerät ca. 5 Jahre alt, immer öfter mal Aus-/Einschalten notwendig, letztendlich Netzteil getauscht und seitdem läuft läuft der Laden wieder ohne Probleme.

    Das Netzteil ist ein einfaches Schaltnetzteil mit 12V Output, könnte also theoretisch auch durch etwas Eigenes (auch Externes) ersetzt werden. Bintec repariert diese Geräte immer noch für eine Pauschale. Ist auf jeden Fall eine saubere Alternative zum Selbermachen. Allerdings ist das Gerät dann natürlich einige Tage unterwegs.

    Man kann die Reparatur auch mit Vorabtausch machen lassen, dann wird das Ganze aber schnell teuer.

    Eine endgültige Löschung auf Dateiebene findet während der nächtlichen automatischen Bereinigung statt. Den Zeitpunkt kann man im david.Administrator einstellen: "System" - "Konfigurieren" - "Bereinigung".

    Man kann die Bereinigung natürlich auch manuell über den Administrator starten (Rechtsklick auf "System" - "Status Monitor" - "Datenbereinigung" - "Jetzt starten"). Das sollte man aber nicht machen, während alle User munter Emails bearbeiten, denn u.U. gibt es dann Datenverluste. Die Bereinigung löscht Dateien und ändert dabei auch die Inhalte der "ARCHIVE.DIR" und "ARCHIVE.DAT"-Dateien der betroffenen Verzeichnisse und wenn da gleichzeitig ein User vom Client aus etwas macht, dann gibt das u.U. Chaos.

    Hi,

    please check the settings of your POSTMAN-TLD in DAVID administrator. The settings should look like this:

    If "Email-Rundsendung" ist unchecked, DAVID will send the whole job to the provider and probably your provider is not separating the individual jobs from each other. The result will be one email to all recipients, where everybody can see all other recipients.

    Putting the receiver in BCC as nordtech suggested is probably not what you want, although it would work. You want individual emails with the correct receiver in the To:-field, I suppose.

    Bei der Datenmenge kann ich Dir auch nur die Methode von riawie empfehlen, wenn Du einigermassen schnell wieder an einen laufenden DAVID mit kompletten Datenbestand kommen willst.

    Nachteil ist allerdings, dass Du damit auf dem neuen Server 2019 zuerst einmal eine alte SQL-Datenbank hast. Hier im Forum gibt es aber auch gute Anleitungen zum nachträglichen Migrieren der SQL-Datenbank auf die neuste mit DAVID gelieferte Version.

    Wenn Dein neuer Server exakt so wie der alte heissen kann und auch dieselbe IP-Adresse bekommt, dann klappt das mit dem Kopieren der DAVID-Installation sehr gut. Bedenke in jedem Fall, dass Du auch mit Robocopy stundenlang kopieren wirst, weil Du bei 1.3 TB Datenbestand u.U. hunderttausende von kleinen und kleinsten Dateien bewegst. Ein Wochenende ist dabei schnell rum und Euer Emailsystem ist die ganze Zeit offline. Wenn Euer Provider oder ein SMTP-Proxy in der Zeit aber die neuen Emails zwischenspeichert, dann ist das OK, so lange Du Deine Chefs davon überzeugen kannst, dass es eben einmal längere Zeit kein Email gibt.

    Entscheidend ist, ob die Gegenstelle den Ruf auch annimmt und Du dort sehen kannst, dass wirklich eine Art Training/Kommunikation stattfindet. Wenn das Training fehlschlägt, muss es auch auf der Gegenseite eine Fehlermeldung geben.

    Das Piep-Piep-Piep kommt auch dann aus dem Modemlautsprecher, wenn die Gegenstelle überhaupt nicht antwortet. Das ist das CNG-Signal mit 0.5s Träger/3s Pause. Mit dem zeigt das Modem/Fax der Gegenstelle an, dass eine Faxübertragung ansteht. Damit kann auf der Gegenstelle eine Faxweiche z.B. von Telefon auf Fax umschalten. Erst wenn das Fax dann auf der Gegenseite wirklich "abhebt", findet eine bidrektionale Kommunikation und dann auch ein Training statt. Vorher ist das nur eine einseitige Sache ohne jede Aussage darüber, ob überhaupt eine Verbindung zu Stande kommt.

    An Deiner Stelle würde ich nicht zu viel an der Initialisierung des Modems herumspielen. Du warst weiter oben schon mal so weit, dass es gewählt hat. Wenn Du die Übertragungsgeschwindigkeit von vorne herein auf 14.400 oder 9600 Baud reduzieren möchtest, geht das im INIT-String in der TLD.INI.

    Wichtig ist aber: Erreichst Du überhaupt jemanden oder kann man das Modem anrufen/antwortet es? Durch das Ausschalten der Trägersignalerkennung wählt das Modem jetzt einfach und versucht sein Glück. Es kann aber sein, dass einfach das Kabel des Modems defekt oder der Eingangsübertrager des Modem hinüber ist. Das Modem merkt das in dem Fall nicht.

    Hast Du denn einen Träger, wenn Du ein analoges Telefon an den Cisco-Port hängst und einfach abhebst (also "Wählton" vorhanden)? Wenn der Cisco sich tot stellt und auf das Modem wartet,, dann warten beide aufeinander. Musst Du etwas vorwählen um eine "Leitung" zu bekommen? Ist das im Faxport eingestellt?

    Im o.a. INIT-String steht z.B. &C1, d.h. das Modem wartet auf einen Wählton. Wenn es den nicht gibt, dann musst Du hier z.B. &C0 eintragen (=Überspringen der Trägererkennung).

    Und es kann natürlich sein, dass Dein Modem eingangsseitig defekt ist ...

    Also das Thema "Modem" ist bei mir schon lange her, deswegen alles weitere ohne Gewähr :):

    Ich würde zuerst im DAVID-Admin in den Eigenschaften des Ports die Monitor-Informationen auf mindestens "Normal" oder höher setzen, den Port dann neu starten und dann im Status-Monitor schauen, ob beim Start der Kommunikation mit dem Modem alles klappt, das Modem korrekt initialisiert wird und es keine Fehlermeldungen gibt. Nur dann kann man davon ausgehen, dass der DAVID überhaupt korrekt mit der Hardware reden kann.

    Dann muss man an der TLD.INI-Datei des Ports noch ein paar Dinge manuell verändern. Ich habe da mal von TOBIT für ein US Robotics 56k USB-Modem folgende Parameter erhalten, mit denen es dann sofort geklappt hat:

    Änderungen an der TLD.INI des Modemports:

    - Als INIT-String verwenden: ATE0&F&D2&C1&H1X1S7=55

    - Den Parameter ADDAUTOEOP=TRUE setzen

    Danach den Port neu starten

    Es kann natürlich sein, dass der o.a. INIT-String nur für die USB-Variante gilt, aber das glaube ich nicht. Einfach mal probieren, man kann da ja nichts verlieren.

    Ansonsten: Falls Eure Tel.-Anlage auch einen internen ISDN-Port zur Verfügung stellen kann, dann nimm eine PrimuX-USB von Gerdes. Das ist aktuelle Hardware, Software Support bis rauf zu Server 2019, Anschluss über USB und damit keine Probleme mit COM-Ports o.ä. Und funktioniert sofort Out-of-the-Box.

    Vermutlich schickt Eure Firewall (192.168.1.2) die Emails per SMTP an den DAVID weiter und der empfängt sie über den POSTMAN. In dem Fall solltest Du zwei Dinge machen:

    1. In der POSTMAN.INI-Datei im Verzeichnis \DAVID\APPS\POSTMAN\CODE den Parameter EHLOWITHDOMAIN aktivieren und auf TRUE setzen.

    2. In der Konfiguration des POSTMAN auf dem ersten Tab unter "Generell" bei "SMTP Host Name" eure Email-Domain eintragen, also z.B. "musterdomain.de".

    Danach den Postman-Dienst neu starten.

    Das kann man halt nicht vergleichen: Beim reinen Kopieren (so wie im Tipp von Riawie) werden wirklich nur die Dateien von A nach B bewegt. Das entspricht Deinem 80000-Dateien Test und geht schnell.

    Wenn Du statt dessen aus der Strongbox wiederherstellst, dann holt der Service-Layer eine Email aus der gepackten Datei, entpackt die Email im Speicher, schreibt 2+X - Dateien (das X sind die Anhänge) in das Zielverzeichnis, dann erweitert er die ARCHIVE.DAT-Datei um einen 430 Byte großen Eintrag (430 Byte an eine bestehende Datei anfügen, das mögen alle SSD's :) ohne Overprovisioning). Wenn man beim neu installierten DAVID nichts im Eingang hat und dann mit der Strongbox 30000 Dateien hinzufügt, dann schreibt die SSD an dieser Stelle 30000 mal in die ARCHIVE.DAT-Datei und hängt jedesmal 430 Byte dran. Beim reinen Kopieren dagegen wird nur einmal eine ca. 12,9 MByte große Datei geschrieben.

    Dann läuft noch die Volltextsuche über Deine neu hinzugefügte Einzelemail drüber und erst danach kommt die nächste Email aus dem Image dran. Das Ganze läuft dann auf Deiner 8-Kern Maschine größtenteils auch nur auf einem Kern (weil das alles der Service-Layer als Dienst alleine macht) und schon gar nicht mit Volllast, weil der Dienst gar nicht 100 % Leistung vom System bekommt.

    Die 16h sind zwar krass, aber erklärbar.

    Welche Suche geht langsam? Die Volltextsuche über F3 oder der Quickfinder? Beide arbeiten komplett unterschiedlich, die Ursachen für träges/zähes Verhalten können demnach auch komplett verschieden sein.

    Hauptprobleme bei einem langsamen Quickfinder:

    - Zuviele Emails "flach" im Ordner, ab 2000 kann es sehr träge werden

    - Kommentarspalten und Anzeige für lange Betreffs sind aktiviert, das bremst noch mal gewaltig

    lycra

    Alle PRO-Versionen haben von Haus aus einen COM-Port mit dabei. Dieser wird bei der Neuinstallation mit installiert, aber nicht aktiviert. Genauso ist auch immer der Hybrid-Port mit dabei. Wenn man die Ports deinstalliert (im Admin entfernt), dann tauchen sie in der Liste nicht mehr auf, können aber jederzeit wieder hinzu gefügt werden.

    Die akt. DAVID Small Business hat nur zwei User und keinen Port, kann aber nachträglich um Ports und User erweitert werden. Und die alten BASIC-Pakete hatten keinen Port und konnten auch nicht nachträglich erweitert werden.