Beiträge von wlconsult

Probiere folgendes: Schalte in den Optionen unter Einstellungen - Ansicht - Einstragsliste die Unterstützung für lange Betreffs aus. Du kannst dann zwar keine langen Betreffs mehr anzeigen und auch nicht mehr komplett darin suchen, die Suche reagiert dann aber wieder sehr viel schneller (speziell beim mobilen Client). Und dann solltest Du überall die Kommentarspalte in der Ansicht Deiner Ordner ausblenden, denn das beschleunigt den Zugriff auf die Archive ebenfalls deutlich. Danach kannst Du auch bei knapper Bandbreite oder langsamen Server i.d.R. normal mit Deinem mobilen Infocenter arbeiten.

Die Darstellung und Suche in Feldern, die langen Text erlauben, ist im DAVID-Client bei mobiler Nutzung ätzend langsam. Wenn man die Suche verwendet und die o.a. Felder/Funktionen aktiviert sind, dann sollte man in jedem Fall warten, bis das Suchergebnis angezeigt wird, bevor man irgend etwas anderes anklickt. Sonst hängt der Client mit blauem Kreisel und man kann ihn nur noch mit dem Taskmanager abschiessen.

TOBIT müsste hier dringend etwas tun, kann das aber vermutlich prinzipbedingt nicht. Die Suche in großen SQL-Binärfeldern dauert einfach lange, weil hier nichts indiziert werden kann und beim Darstellen dieser Felder in der Ansicht (Kommentarfeld) wird offenbar immer die gesamte Datenmenge vorab zwischen Server und Client bewegt und das dauert bei mobiler Nutzung ebenfalls sehr viel länger, als wenn man das Ganze im Büro mit z.B. Gigabit-Netzwerkanbindung macht.

Es könnte auch eine Inkompatibilität zwischen der Grafikkarte bzw. den Treibern für die Karte des Servers und dem Framework, das TOBIT für die Umsetzung des User-Interfaces seiner Programme verwendet, sein.

Einfacher Test: Deinstalliere die Grafikkartentreiber und lass den Rechner testweise mit Standard-VGA Einstellungen laufen. Wenn die Checkboxen dann da sind und alles andere auch lesbar ist, dann weißt Du zumindest, woran es liegt. Eine Lösung wird es dann dafür aber nicht geben, es ei denn, es gibt andere Treiber für die Graka Deines Rechners.

Falls Du per RDP auf Deinen Server zugreift und das Problem dabei hast: Ich hatte mal ein Problem mit der Grafikdarstellung von DAVID im Remote-Desktop. Da war es dann ein Treiberproblem mit dem lokalen Rechner, der für die RDP-Sitzung verwendet wurde. Da waren in der RDP-Sitzung im Navigator die Ordner nur noch schattenhaft oder gar nicht mehr zu sehen und der Mauszeiger verursachte überall im TIC Störungen. Betroffen war in dem Fall nur der DAVID, sonst nichts. Hier hat temporär aber immer ein Neustart beider beteiligten Rechner geholfen. Wir haben dann den Rechner getauscht, der für die RDP-Sitzung verwendet wurde, seit dem ist Ruhe.

Das geht leider nicht, weil die Outlooks vom MAC m.W. nicht Exchange Active Sync for Mobile Devices "sprechen", sondern nur das reine Exchange Protokoll. Das aber unterstützt der DAVID nicht. Outlook 2013, 2016 und 2019 für WIndows (nicht die Office 365 Mietversionen !!) können auch die mobile Version von EAS und deshalb klappt das da auch mit dem DAVID-Server.

Du kannst das Outlook auf dem MAC also nur per IMAP/POP an den DAVID anbinden und hast dann auch keine Unterstützung für Adressen, Kalender und andere Funktionen, wie z.B. Aufgaben, ...

Als Alternative bleibt Dir nur der MAC-Client von TOBIT, der aber nicht den vollen Funktionsumfang des DAVID Client für Windows hat.

Wenn Du Remote-Access für das jeweilige Postfach frei gibst und den Mailaccess-Server entsprechend konfigurierst, kannst Du die Postfächer nacheinander in einen Mailstore-Server überführen. Das geht auch für einzelne Archive, für die man vorher natürlich einen Email-Alias einrichten muss und für die auch der Remote-Access freigegeben sein muss. Der Mailstore-Server legt dann für jede Email-Adresse ein eigenes Archiv an und bildet darin auch eine evtl. vorhandene Unterverzeichnisstruktur ab.

Ich habe auf diese Art und Weise schon den kompletten Emailbestand einer ausscheidenden Abteilung eines Kunden zuerst in den Mailstore-Server archiviert und anschliessend von dort in einen neuen Exchange-Server migriert. Hat ohne Probleme geklappt. Man kann dafür auch die kostenlose 30 Tage Testversion des Mailstore-Servers benutzen, dann entstehen nicht einmal zusätzliche Kosten.

Etwas problematisch wird es bei reinen Dokumenten, die man z.B. in ein Archiv gezogen hat oder z.B. bei Fax, Voice, SMS: Diese werden per IMAP an den Mailstore weiter gegeben, dort erscheint allerdings als Nachrichtentext z.B.

"MailStore kann diese E-Mail nicht darstellen. Bitte klicken Sie auf E-Mail-Befehle -> Öffnen in..., um diese in einem E-Mail-Programm Ihrer Wahl zu öffnen."

Faxe hängen in dem Fall als GIF-Datei an der Nachricht. Im Header in Mailstore sieht man aber immer noch den Absender und seine Faxnummer. Mit reinen Dokumentenablagen (PDF, ...) in DAVID habe ich in Bezug auf die Archivierung mit Mailstore noch keine Erfahrungen sammeln können.

Wie gesagt: Die kostenlose 30 Tage Testversion von Mailstore macht einen Test sehr einfach. Du kannst alles ausprobieren und das Ergebnis prüfen. Wenn die Daten erst mal im Mailstore sind, kannst Du sie von dort aus praktisch in jedem Format exportieren oder direkt z.B. in Exchange-Postfächer überführen.

Gar nicht mit Mailstore gehen: Kalender, Adressen, To-Do, Wiedervorlagen, Aufgaben.

Unterliegt Ihr da nicht einem Denkfehler? Die Windows Index-Suche sucht wie Stylistics schon angemerkt hat, auf Dateiebene. Wenn Ihr da einen Suchbegriff aus einer Email angebt, die im DAVID-Archive-System liegt, bekommt Ihr im besten Fall einen kryptischen Dateinamen, wie z.B.

D:\DAVID\ARCHIVE\USER\10004000\IN\Ia3b1004.001

Wem oder was nützt das? Ihr wisst dann zwar, dass es eine Datei gibt, aber nicht (zumindest nicht im Klartext) wo sie liegt, wann sie reingekommen ist und z.B. welche Dateien noch dazu gehören. Die Volltextsuche von DAVID dagegen liefert als Ergebnis Nachrichten mit Datum und Uhrzeit zurück.

Beide Suchmethoden haben nichts gemein und verwenden auch nicht dieselbe Datenbasis. Es wird also hinsichtlich der Suchergebnisse nichts schneller oder besser, wenn man die Windows Index-Suche zusätzlich für das DAVID-Verzeichnis aktiivert. Das geht ausserdem nur, wenn man entweder sowieso direkt auf dem DAVID-Server als User arbeitet, das DAVID-Verzeichnis seines Servers als lokales Laufwerk gemappt hat oder die mobile Version des Infocenters auf dem Rechner hat, zusammen mit einer lokalen Kopie seiner DAVID-Daten.

Ich habe das bei einem Kunden so gelöst, dass ich den Mitarbeitern, die keine eigene Emailadresse haben, jeweils eine nur intern vorhandene Adresse als Hauptadresse und die info@... als Zweitadresse gegeben habe:

User mit Emailadresse: max.mustermann@domain.de (Hauptadresse)

User ohne Emailadresse:lisa.mustermann@domain.local (Hauptadresse) und info@domain.de als Zweitadresse für Versand

Untereinander kann dann jeder jedem Emails schreiben und ist auch eindeutig identifizierbar (sowohl im internen Adressbuch, als auch z.B. beim Verteilen, ...)

Den externen Versand habe ich genauso wie bei Dir mit @@-Befehlen in den Vorlagen erledigt. So ist sichergestellt, dass User ohne eigene Adresse immer mit der richtigen Adresse, nämlich der info@domain.de verschicken.

Um zu verhindern, dass trotzdem Emails mit einer nur intern vorhandenen Adresse nach draussen gehen (es gibt immer Spezialisten, die die Steuerbefehle löschen, sich selbst Vorlagen und Textbausteine ohne die passenden Befehle machen oder schlicht vergessen, auf die info@domain.de umzustellen) habe ich verschiedene Sende-Methoden definiert:

Wenn Absender = *@domain.de ist, dann Versand über den Smart-Host des Providers

Wenn Absender = *@domain.local, dann denselben Eintrag, nur mit irgendeinem SMTP-Server eines Großproviders und mit falschen Zugangsdaten

Emails mit *@domain.local als Absender kommen dadurch sofort mit der Fehlermeldung "Ungültiger Absender" zum jeweiligen User zurück.

Das funktioniert so allerdings nur, wenn Ihr über den Smarthost des Providers versendet, nicht wenn der DAVID direkt der MX ist. Diese Lösung ist zwar nicht ganz "sauber", aber praxistauglich und stabil. Und die User merken sofort selbst, wenn sie etwas verbockt haben

Das ist die Standardeinstellung und so völlig OK. Wenn Du aber auch mit außereuropäischen Email-Empfängern arbeitest (z.B. Russland, ...), dann solltest Du den Zeichensatz auf UTF-8 umstellen.

Wir haben hier im Laufe der Zeit die Erfahrung gemacht, dass es am Besten ist, mit einer komplett leeren Vorlage zu starten und dann die HTML-Vorlage für z.B. eine Signatur damit zu erstellen.

Ich mache das so:

- Neue Nachricht erstellen

- Umschalten auf "Format - Nur Text" (das löscht alle evtl. vorhandenen HTML-Leichen)

- Zurückschalten auf "Format - HTML"

- Jetzt zuerst den gewünschten Grundzeichensatz und die Schriftgröße einstellen (Diese sollte sich mit den EInstellungen in den "Optionen" - "Einstellungen" - "Editor" decken)

- Jetzt Signatur gestalten (das Einschalten der klassischen Formatierungsoptionen ist dafür sehr hilfreich)

- Betreff eingeben und dann "Datei" - "Erstellen" - ...

Wenn es irgendwie geht, dann weder den Text, noch eine evtl. vorhandene Grafik fertig gestaltet aus anderen Programmen (schon gar nicht aus Word) einkopieren. Damit schleppt man sich viele HTML-Tags in die Vorlage, die im DAVID-Editor zu zum Teil verrückten Ergebnissen führen können. Wenn einkopiert wird, dann nur reines HTML (aus z.B. Notepad++). Darauf achten, dass man alle Tags mit kopiert.

Text nur in den Größen 8/10/12/14/18/24 und 36 verwenden. Damit kann DAVID umgehen. Werte kleiner als 8 oder Zwischenwerte wie z.B. 11 Punkt werden nicht richtig dargestellt und führen beim Anzeigen von zurückkommenden Antworten zu Chaos.

Grafiken immer aus einer gespeicherten Datei per "Einfügen" - "Grafik" in die Vorlage einfügen, nicht mit Drag & Drop oder Copy/Paste arbeiten. Als Alternative kann man kleine Grafiken auch Base64-codiert direkt in die HTML-Vorlage einbauen. Man bekommt dann keine Probleme mit einem plötzlich verschwundenen Firmenlogo, wenn eine Email mehrfach hin- und hergeht.

Das o.a. Vorgehen hat bis jetzt immer zu reproduzierbaren Ergebnissen geführt und viele Probleme beseitigt. Es gibt aber Email-Systeme wie z.B. Lotus Notes, die sich mit DAVID nicht wirklich vertragen. Hier gibt es bei Antwort-Emails immer wieder veränderte Zeichensätze und Sprünge in der Schriftgröße, die sich durch nichts erklären oder nachvollziehen lassen.

Hier noch ein Nachtrag: Ich komme gerade von einem Kunden mit aktuellem DAVID. Die haben sich auch über elend langsamens, springendes Scrollen und eine unzuverlässige Suchfunktion mit dem Quickfinder beschwert.

In dem Fall war es das Ausblenden der Kommentarspalte in der Eintragsliste , das die alte Geschwindigkeit sofort wieder hergestellt hat.

Der Kunde hat die Kommentarfunktion erst seit ca. zwei Monaten in Benutzung und mit zunehmender Anzahl an Einträgen wurde das Ganze immer schlimmer. Allerdings hat das Problem zunächst niemand mit den Kommentaren in Verbindung gebracht. Der Kunde hat nämlich relativ viele Emails (einige Tausend pro Verzeichnis) und einen zugegebener maßen langsamen Server,

Offenbar ist der Quickfinder aber nur dann schnell, wenn er keine langen Textfelder (Kommentare oder lange Betreffs) durchsuchen muss. Ist der Server dann noch langsam, kann das auch dazu führen, dass das Infocenter nicht mehr reagiert.

Bei dem Kunden wird jetzt der Server gegen etwas aktuelles mit SSDs getauscht. Das sollte das Problem zumindest in dem vorliegenden Fall nachhaltig lösen.

Wenn Du in Deiner Vorlage neben @@VON info@...@@ noch eine zweite Zeile mit @@ANGEZEIGTERNAME Mustermann GmbH@@ einfügst, dann sollte das funktionieren.

Ich habe hier ebenfalls mehrere Installationen mit Sitecare, wo die Suchgeschwindigkeit über den Quickfinder z.T. unterirdisch ist (es kann in großen Archives auch mal eine halbe Minute dauern, bis etwas gefunden wird). Klickt der ungeduldige User in der Zwischenzeit im Client woanders hin, kann es sein, dass der Client abstürzt. Auch das Scollen in großen Archives läuft ruckartig und zeitverzögert.

Wenn man den Haken rausmacht bei "Optionen" - "Einstellungen" - "Ansicht" - "Eintragsliste" - "Anzeige des Betreffs erweitern", dann läuft alles wieder flüssig. Allerdings natürlich auf Kosten der Anzeige- und Suchfunktion für lange Betreffs.

Ich hoffe auch, dass TOBIT das bald korrigert.

Die letzte Client-Version, die unter Windows XP, Server 2003 oder Server 2008 (ohne R2) installiert werden kann und läuft, ist die Version aus dem Rollout 276 vom November 2017.

Dieser Client (276) läuft aber problemlos auch mit der aktuellsten Version von DAVID (298). Einschränkungen gibt es ggfs. bei allen seitdem veröffentlichten neuen Features, wie z.B. langen Betreffs.

Man muss "Strg" und "Shift" zusammen drücken, während man die gewünschte Adresse in den Gruppenordner zieht. Dann legt DAVID eine Verknüpfung an.

Das Ablegen von markierten Emails mittels Drag & Drop in einen Dateiordner geht i.d.R. ganz gut. Es gibt aber ein paar Beschränkungen, die einem das Leben schwer machen können:

- Die Menge der in einem Durchgang transportierbaren Nachrichten hängt entscheidend von der Größe der einzelnen Nachrichten ab. Das Ganze geht ja incl. Attachments über die Zwischenablage und hier gibt es Größen-Beschränkungen (sei es vom Infocenter, sei es von der Zwischenablage selbst, ...). Das ist nirgendwo dokumentiert. Erfahrungswert: Wenn es in Richtung 200 markierter Emails geht, klappt es i.d.R. nicht mehr.

- Die bei diesem Vorgang erzeugten EML-Dateien erhalten als Dateinamen den Betreff der jeweiligen Email abzüglich von Sonderzeichen, die im Dateinamen nicht erlaubt sind und automatisch weg gelassen werden. Wenn dabei allerdings eine Mail mit einem besonders langen Betreff die Grenze für die max. Länge des Dateipfades unter Windows sprengt, bricht der Vorgang hier immer ab. Da kann man nichts machen, ausser diese Datei einzeln als EML abspeichern und dabei den Namen kürzen.

- Wenn man große Archives nur in mehreren Schritten in einen externen Dateiordner exportieren kann/muß, dann kommt es ab dem 2. oder 3. Export häufig zu Problemen wegen Namensgleichheit der erzeugten Dateien im Zielverzeichnis. Grund sind hier i.d.R. Emails, die aus einer Quelle stammen und alle denselben Betreff haben (aber unterschiedliches Datum und unterschiedlichen Text, ...). Der Export ist zwar so schlau, in einem Durchgang Namensgleichheit zu vermeiden (die Emails erhalten dann am Ende des Namens fortlauende Nummern zur Unterscheidung), das klappt aber bei einem zweiten unabhängigen Export ins selbe Verzeichnis nicht mehr. Statt dessen kommt eine Explorer-Meldung wegen Namensgleichheit. Wenn man hier dann abbrichtt, ist man i.d.R. erledigt, denn das Infocenter sagt einem nicht, wo der Export abgebrochen hat.

Zusammenfassung: Man kann es so machen, aber nur bei kleinen Archiven mit wenig Einträgen (ca. 100). Ansonsten ist das Ganze auf diesem Weg eine Sisyphusarbeit.

Ich habe hier in einer Installation auch noch einen "Server" auf Basis Windows XP laufen. Hier hat das Update auf Rollout 297 (automatisch) keinerlei Probleme verursacht. Der DV-Admin startet nach dem Rollout einwandfrei, keine Störungen.

Allerdings hat der Server das Rollout 296 direkt übersprungen, weil er die Rollouts automatisch immer erst am Samstag früh installiert. 297 war also schneller verfügbar, als er 296 installieren konnte Vielleicht hat TOBIT hier ja schnell reagiert und das Rollout 297 entsprechend angepasst.

Ich muss das Thema noch mal rausholen:

Kann mir jemand bestätigen, dass auch mit dem letzten Rollout (294, 295 kommt erst) der Betreff bei Übertragung per IMAP oder per EAS nach dem 96. Zeichen abgeschnitten wird, obwohl lange Betreffs unter Ansicht - Eintragsliste aktiviert sind?

Hintergrund: Ich habe einen Kunden, der die meisten Arbeitsplätze mittlerweile mit Outlook 2016 über EAS am DAVID hängen hat. Und da werden die Betreffs nach wie vor alle abgeschnitten. Im Infocenter hingegen werden längere Betreffs angezeigt. Das kann ich aber wegen der benötigten Outlook-Plugins seiner Branchenlösung nicht nutzen.

Ja, das ist leider bei DAVID so: Wenn man eine AUTOREPLY-Regel erstellt, dann kommt die automatische Antwort immer von der ersten Adresse, die im TO:-Feld der Originalnachricht steht. Ich empfehle meinen Kunden deswegen, beim Erstellen der Autoreply-Regel immer auch die eigene Email-Adresse bei "Absender ersetzen" ein zu tragen.

Allerdings sollte man sich überlegen, ob das schon reicht. Unter Umständen erzeugt man damit Antwort-Emails mit dem eigenen Absender, wo man besser keine geschickt hätte (z.B. wenn man im BCC: gestanden hat). Evtl. sollte man das noch zusätzlich kombinieren mit der Bedingung "Verteilkennung ist gleich" und dann die eigene Email-Adresse angeben. Oder man gibt an, dass die Regel nur dann zieht, wenn es sich nicht um einen bestimmten Absender handelt.

Man muß also ein bisschen Hirnschmalz investieren, um diese Eigenheit von DAVID in den Griff zu bekommen .

Das kann ich bestätigen: Hier bei mir gibt es einen Kunden, der extra wegen Problemen mit der Suchfunktion bei seinen Windows-10 Maschinen von seiner älteren DAVID-Version auf die aktuelle Version geupdated hat. Ich habe ihm das Update auch noch mit dem Hinweis empfohlen, dass damit jetzt auch endlich längere Betreffs möglich wären, weil er in der Vergangenheit schon mehrfach moniert hat, dass Betreffs bei Emails, die mehrfach hin- und hergehen, irgendwann abgeschnitten werden.

Jetzt musste er feststellen, dass die Volltextsuche in den langen Betreffs öfter gar nichts findet. Das betrifft auch nur die Volltextsuche, die Filtersuche hat offenbar keine Probleme damit.

Die Ausrede, dass ein in den Augen des Anwenders vorhandener Programmfehler keine zugesicherte Eigenschaft ist, habe ich vom Support auch schon mehrfach gehört. Das ist in meinen Augen eine juristische Spitzfindigkeit: TOBIT vermeidet damit jede Art von Anspruch seitens der Kunden. Insbesondere vermeidet man so von Kunden, die kein Sitecare haben, im Falle von Programmfehlern jeden Anspruch auf Nachbesserung oder Wandlung. Installieren und in Betrieb nehmen lässt sich DAVID ja immer. Alles was nicht funktioniert ist dann halt keine zugesichete Eigenschaft - Ein Schelm der böses dabei denkt !

Und es funktioniert m.W. gar nicht, falls Du Dein EAS auf einem anderem Port als 443 (z.B. auf 8443 o.ä.) abwickelst, weil man beim Windows Mobile Phone keinen Port mit angeben kann bzw. Windows Mobile Phone einen anderen Port als 443 einfach ignoriert.

Das Problem kenne ich in abgewandelter Form auch von einem Kunden: In einem Fall bekommt ein DAVID-User regelmässig Termineinladungen zu Telefonkonferenzen von Seiten einer Gruppe von Outlook-Usern. Manche der Einladenden schreiben die Einwahldaten für die Telefon-Konferenz in ihrem Outlook in den Kommentar und schicken diesen Termin dann als Einladung an die anderen Teilnehmer weiter.

Der DAVID-User muss dann jedes Mal nachfragen, wie denn die Einwahldaten für die nächste Telco sind, denn der DAVID ignoriert offenbar die Kommentare beim Annehmen der Einladung. Die anderen eingeladenen Outlook-User haben da offenbar keine Probleme damit.