Bei derartigen Problemen hilft es oft schon, die Datei "ActiveSync.db" unter \\DAVID\ARCHIVE\USER\xxxxxxxx\ zu löschen. Vor allen Dingen dann, wenn die EAS-Verbindung zum Mobiltelefon schon lange besteht und dann noch das EAS für das Outlook dazukommt.
Viele Grüße
Werner
Die Strongbox ist m.E. nicht mit dem Mailstore-Server zu vergleichen und in dem hier besprochenen Szenario sowieso nicht für den User einsetzbar.
Schon in einem reinen DAVID-Umfeld (also ohne Outlook als Client) habe ich hier einige Kunden, die Emails lieber im Mailstore-Server suchen und auch viel schneller finden, als wenn sie das über die Suchfunktion beim DAVID machen (und wir reden hier noch von der Suche nach Emails im Produktivsystem, nicht in einem Archiv). Das Hauptproblem beim DAVID ist nämlich, dass die Suche an die Volltextsuche des MS-SQL-Servers gebunden ist. Diese führt oftmals bei kurzen Suchbegriffen (z.B. Teilen von Aktenzeichen o.ä.) zu keinem Treffer. Es gibt auch eine MS-SQL-interne Buzzword-Liste, nach denen einfach nicht gesucht werden kann. Auch hier liefert der DAVID ohne jeden weiteren Kommentar einfach kein Ergebnis. Mailstore kennt diese Probleme nicht. Ausserdem verschlagwortet er auch Anhänge und sucht auch darin. DAVID kann hier also in keiner Weise mithalten.
Mit Strongboxen als Archiv geht die Produktivität beim Suchen dann schnell gegen Null. Zum einen ist der Zugriff auf die Strongbox-Archive (vor allen Dingen wenn sie größer sind) relativ langsam, zum anderen geht die Volltext-Suche hier überhaupt nicht. Du hast nur die klassische Suche des DAVID-Clients zur Verfügung.
Wenn man dann Outlook als Clientersatz für das DAVID-Infocenter nutzen möchte/muss, gibt es damit dann sowieso keinen Zugriff auf Strongbox-Files.
Bei Deinem letzten Punkt hast Du meine volle Zustimmung: TOBIT sollte dringend etwas an den System-Schnittstellen machen und damit für mehr Interoperabilität zu anderen Programmen sorgen.
Wir setzen bei ein paar Kunden Outlook 2013/2016 und 2019 als Emailclient alternativ zum Infocenter ein. Gut funktioniert das nur per Activesync-Anbindung (nicht IMAP oder POP), weil nur dann auch Kalender und Adressen einwandfrei funktionieren. Dafür ist ein "offizielles" SSL-Zertifikat auf Port 443 am Server eigentlich obligatorisch. Outlook 365 funktioniert nicht, weil hier das EAS-Protokoll fehlt.
Gruppenordner kann man so anbinden, wie Caddo das oben schon gesagt hat. Mehrere Absender-Adressen sind nur möglich, wenn man diese dem User über die Mehrfacheinbindung der entsprechenden Postfächer zur Verfügung stellt. Dann hat man auch Zugriff auf die unterschiedlichen Kalender, was andernfalls nicht geht. Die übrigen Gruppenfunktionalitäten von DAVID werden praktisch nicht unterstützt, es gibt auch keine servergestützten Vorlagen.
Größere Probleme gibt es in Verbindung mit Add-Ins. So kann das Mailstore-Addin z.B. keine Emails online in ein Activesync-Postfach wiederherstellen, da kommt eine Fehlermeldung. Beim Add-In einer bei unseren Kunden häufig im Einsatz befindlichen Branchensoftware gibt es ebenfalls Probleme mit dem Versand von formatierten Emails. Die Email wird hier komplett aufgebaut, allerdings kommt beim Drücken des Send-Buttons dann die Meldung "Die Aktion, die Sie ausführen möchten, wird von ActiveSync leider nicht unterstützt". Einen Workaround haben wir noch nicht finden können, Support vom Software-Anbieter geht hier leider gegen Null.
Ich kann in jedem Fall nur empfehlen, speziell die Anbindung an Branchensoftware und die gewünschte Zusatzsoftware für Outlook (die ist ja meist die Ursache für die Frage nach Outlook) ausgiebig zu testen und dem Kunden vorher nichts zu versprechen.
Öffne auf dem betreffenden Client eine Email im Eingang per Doppelklick, gehe dann über den "Menu"-Button oben links und "Datei" - "Seite einrichten" in die Seiteneinrichtung für den Ausdruck.
Vermutlich ist bei dem Client der folgende Haken gesetzt:
Wenn der Haken ganz oben gesetzt ist, dann übernimmt der Client die Seiten-Einrichtung aus dem Internet-Explorer. Mach dann ganz oben den Haken raus und entferne dann den Haken bei "An Seitengröße anpassen". Speichere dann mit "OK".
Danach sollten die Emails in korrkter Größe gedruckt werden. Es kann aber sein, dass dann je nach Formatierung der Ursprungsmail nicht mehr alles in der Breite auf ein Blatt passt und am rechten Rand Teile der Nachricht abgeschnitten werden.
Dieses Problem tritt vor allen Dingen dann auf, wenn Emails mehrfach hin- und hergeschickt werden und die Original-Mails immer wieder zitiert und damit weiter nach rechts eingerückt werden. Der Client versucht (wenn der o.a. Haken gesetzt ist), die Nachricht immer komplett zu drucken und muss, damit auch die längste Zeile noch aufs Papier passt, die Schrift immer weiter verkleinern.
Wenn das ERP-Programm Emails nur über die MAPI-Schnittstelle an den Standard-Emailclient von Windows weitergeben kann, wirst Du im Mailbody nur den reinen Text, nicht aber Auszeichnungen wie Fett, Kursiv, ... Einrückungen oder Grafiken übergeben können, weil die Schnittstelle das einfach nicht bietet/hat.
Outlook ist hier wieder einmal eine Ausnahme, aber es geht eben auch nur dort und sonst mit keinem anderen mir bekannten Email-Client.
Wenn das direkte Versenden aus dem ERP-Programm per SMTP und dem DAVID-Server als SMTP-Relay keine Option ist (so wie oben schon von BlackShadow vorgeschlagen) und der Aufwand für die Nutzung des DAVID-Import-Service zu groß ist (Vorschlag von orumpf), dann bleibt dem Kunden nur die Anbindung von Outlook ab Version 2013 an den DAVID per EAS. Dann läuft Outlook auf dem Arbeitsplatz als Client und die MAPI-Übergabe funktioniert wie gewünscht.
Der Funktionsumfang dieser Anbindung ist dann aber gegenüber dem normalen DAVID-Client ziemlich eingeschränkt, insbesondere was Gruppenfunktionalitäten anbelangt.
Ja, das Thema ist schon seit letzter Woche bei TOBIT gemeldet und die werden sich das - Originalton - "mal ansehen". Wir haben uns auch jeweils immer dann, wenn wir neue Erkenntnisse hatten, mit diesen Zusatzinfos dort gemeldet. Bis jetzt waren die Rückmeldungen aber sehr spärlich.
Hallo zusammen,
wir mussten das jetzt beim Kunden selbst nachstellen, weil dieser mit den div. Tests überfordert war. Das Problem reduziert sich im Prinzip auf die Darstellung von Terminen im per EAS angebundenen Outlook 2013-2019.
Benutzt der Kunde Outlook per EAS und nimmt dort eine Termineinladung von Teams an, wird der entsprechende Kalendereintrag korrekt gesetzt. Mit dem DAVID-Client kann man diese Termine öffnen und dann den Link zum Teams-Meeting anklicken: Im Vorschaufenster per einfachem Klick auf den Hyperlink, im geöffneten Editorfenster mit Strg + Doppelklick auf den Link. Danke an der Stelle noch einmal riawie für seine Tipps und Tests.
Im Outlook werden diese Termin aber immer als Nur-Text geöffnet und angezeigt. Das bedeutet, dass man dort keine Links hat und so der Termineinladung nicht mehr folgen kann. Das scheint auch auf einigen Android-Mail-Apps so zu sein, wenn diese über EAS angebunden sind. Dort steht dann auch nur Text und die Hyperlinks werden nicht angezeigt. Offenbar missinterpretieren beide Plattformen den HTML-Code aus dem DAVID-Kalender und zeigen den Termin dann nicht korrekt an.
Als Workaroud haben wir jetzt erst mal zusätzlich den DAVID-Client installiert, damit man an den betroffenen Arbeitsplätzen die Termine öffnen und den Links folgen kann.
Hallo riawie, ja das haben wir probiert, funktioniert aber leider nicht.
Im Infocenter geht die Kombi Strg + Mausklick bei geöffnetem Termin schon, allerdings nur dann, wenn man Chromium zum Darstellen nutzt. Sonst geht im Infocenter nur der o.a. Workaround über den Klick in der Vorschau.
Es muss sich an den Termineinladungen seitens Teams etwas geändert haben, denn ich habe dieses Verhalten gerade an einer sehr alten DAVID-Installation (Rollout 268 ohne Sitecare) exakt so reproduzieren können. Auch da kann man Teams-Links bei geöffnetem Termin nicht mehr anklicken, wohl aber in der Vorschau.
Es ist also kein Problem mit einem bestimmten neueren Rollout, sondern offensichtlich etwas,dass Microsoft bei den Links geändert hat und mit dem DAVID nicht richtig klar kommt (vermutlich schon beim Annehmen der Einladung und der Umwandlung in einen Kalendereintrag). Auch auf per EAS am DAVID angebundenen Mobiltelefonen kann man z.B. bei Zoom-Terminen den Termin öffnen, dort den Hyperlink sehen und ihm per Klick/Tipp folgen, bei Zoom-Terminen geht das nicht. Dort ist z.B. unter Android überhaupt kein Link mehr im Text der Einladung zu sehen.
Ich habe das jetzt mit exakter Beschreibung an TOBIT weitergegeben. Vielleicht gibt es dazu ja ein Feedback.
Ich hole diesen alten Thread noch einmal raus, denn wir haben bei einem Kunden genau das o.a. Problem. Allerdings nutzt der Kunde auf einigen Rechnern ausschließlich Outlook 2019 per EAS als Client am DAVID. Dort kann man die Links zu Teams-Einladungen im Kalender auch nicht anklicken, hat aber auch keinen Vorschaumodus, so wie das im Infocenter als Workaround geht.
Ich muss im Outlook den Kalendereintrag per Doppelklick öffnen und kann dann den Link zur Einladung nicht mehr anklicken. Man sieht zwar an der Textmarkierung, dass hier ein Hyperlink vorhanden ist, dieser ist aber leider "tot". Bei Einladungen zu z.B. Skype oder Zoom gibt es hingegen keine Probleme.
Die URL steht natürlich im HTML-Code des Kalendereintrags drin und kann dort rauskopiert werden, aber das kann man natürlich z.B. dem Chef so nicht vermitteln.
Hat jemand noch eine Idee dazu (das Infocenter als Alternative zu Outlook ist an den betroffenen Arbeitsplätzen ausdrücklich keine Lösung 
).
Kurzes Update: TOBIT hat mir für den betroffenen Kunden ein spezielles Hotfix zum Testen zur Verfügung gestellt. Damit ist das Problem auf allen Arbeitsplätzen gelöst, das Erzeugen von EML-Dateien per Drag & Drop oder mit "Speichern unter" funktioniert damit wieder zuverlässig. Der Client ist dort jetzt wieder 330, allerdings mit Release 8547. Wer Bedarf hat, der soll sich bitte über das Intercom mit TOBIT in Verbindung setzen und nach dem Hotfix "hfv128nt.exe" fragen.
Diese Korrektur wird dann vermutlich in das nächste Rollout einfliessen.
Ich habe von TOBIT mittlerweile die Bestätigung für o.a. Verhalten bekommen. Wird kein Domänenuser oder ein lokal auf dem DAVID-Server authentifizierter User, sondern "nur" ein lokaler User für die Verbindung zum DAVID-Server verwendet, dann fehlen diesem seit Rollout 330 die Berechtigungen für den Export.
Das Problem ist erkannt (TOBIT kann es nachstellen) und soll einen Fix im nächsten Rollout dafür geben.
So lange kann man entweder den Client auf 328 zurücksetzen oder wie oben beschrieben die Workgroup-User auch lokal am DAVID-Server als einfache Benutzer anlegen.
Das mit dem Zusammenkopieren habe ich im ersten Anlauf auch versucht , bin aber dann auf die einfachere Lösung gekommen. Mit der Methode vermeidet man zumindest im Moment das Rollback auf dem Server. Selbst mit Rollback hätte man die Clients manuell rücksetzen müssen. Wäre also insgesamt noch mehr Arbeit gewesen.
Bin gespannt, wann TOBIT mit einem Tipp rüberkommt!
Ich hatte den auch nicht separat heruntergeladen. Falls Du noch das Rollout 328.exe hast, dann starte das noch einmal per Doppelklick auf dem Server. Der Installer packt dann alles in ein temporäres Verzeichnis aus (C:\Users\%USERDIR%\Appdata\Local\Temp\PackageX).
Wenn Du die Installation nach dem Auspacken einfach stehen lässt und nicht weiter machst, wird am laufenden System nichts verändert. Du kannst Dir dann im Hintergrund den "DAVID-CLIENT.EXE" aus dem Temp-Verzeichnis herausholen und damit die Arbeitsstationen wieder zurücksetzen. Du musst aber vorher dort den Client 330 deinstallieren.
Nachdem Du den Installer herauskopiert hast, kannst Du die offene Installation einfach mit "Abbrechen" beenden. Am Server im DvAdmin vorher natürlich das automatische Clientupdate deaktivieren, sonst ist der Erfolg nur von kurzer Dauer. Der Client 328 läuft einwandfrei auf dem Server 330.
Bitte melde das Problem auch bei TOBIT. Ich habe da nach mehr als 24h nur eine Nachfrage zur Verwendung der Chromium-Engine erhalten, mehr nicht. Bis jetzt also keine zweckdienlichen Hinweise auf ein mögliches Abstellen des Problems.
Wir haben jetzt bei dem betroffenen Kunden die automatischen Updates überall ausgesetzt und den Client 328 manuell auf den Arbeitsplätzuen installiert. Damit klappt der EML-Export wieder (sowohl D&D, als auch "Speichern unter"). Das ist zwar eine Notlösung, funktioniert aber für den Moment.
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.
Jetzt hast Du mich neugierig gemacht: Wo ist bei Dir der Betreff andersfarbig dargestellt? Der Betreff ändert bei den Installationen, die ich kenne, nur in Abhängigkeit der Dringlichkeit der Nachricht die Farbe.
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.
