Beiträge von wlconsult

Meine letzte Migration war von einem Server 2008 (kein R2, also 32 bit, Rollout 256) auf einen aktuellen Server 2019 Std. mit DAVID.V3-310 , komplett mit neuer Domäne und entsprechend neuen/anderen Usern und z.T. 14 Jahre alten Emails. Das kann man dann nicht mehr so machen, wie es Riawie beschrieben hat (seine Methode funktioniert unter den o.a. Umständen aber sehr gut).

Es gibt da viele Ansätze, die alle schon einmal hier im Forum angesprochen wurden. Ich möchte hier aber mal eine Lanze für die DAVID-Migration-Services brechen, die jeder TOBIT Reseller haben sollte/müsste. Das Tool ist zwar als unzuverlässig verschrien, es funktioniert aber auch bei mehreren hundert Gigabyte großen Datenbeständen sehr gut, wenn man ein paar Dinge berücksichtigt und entsprechende Vorarbeiten durchführt:

- Alte Archives mit archivierten Ablagen sollte man so gut es geht zusammenfassen/packen (spart unglaublich Zeit bei der Migration, da nicht hunderttausende kleiner Dateien, sondern wenige gigabyte-große Files von A nach B kopiert werden müssen). Das gilt übrigens für jede Migration, ganz gleich nach welcher Methode.

- Nach dem Packen sollte man prüfen, ob in den entsprechenden Verzeichnissen nicht noch irgendwelche "Dateileichen" liegen (ausser dem eigentlichen *.PCK-File und den ARCHIVE.*-Dateien). Den Schrott sollte man löschen.

- In der DAVID.INI sollte man frühzeitig einen Eintrag "MSGMAILNAMES=", gefolgt von der eigenen Emailadresse machen. Man bekommt dann nach jeder nächtlichen Bereinigung eine Email mit angehängtem Report. Diesen Report sollte man auf Fehler prüfen und diese Fehler beseitigen, bevor man migriert. Meist handelt es sich um nicht mehr vorhandene Unterverzeichnisse in irgendwelchen Archiven. Am besten legt man die fehlenden Verzeichnisse auf Dateiebene einfach wieder mit dem Namen an, der im Report als fehlerhaft gemeldet wird. Sie erscheinen dann auch sofort wieder im Infocenter, wenn man auf das jeweilige Archive geht. Dort kann man das Verzeichnis dann auch wieder sofort löschen, dabei wird die ARCHIVE.DIR automatisch korrigiert. In nächsten Bereinigungsreport ist der Fehler dann meist nicht mehr vorhanden. So lange Fehler im Report sind, sollte man das Migration-Tool nicht verwenden.

- Wenn noch Ordnerstrukturen von alten Mitarbeitern unter "Benutzer" zu finden sind, die vielleicht gar nicht mehr als aktive User im aktuellen DAVID vorhanden sind, sollte man sich überlegen, ob man deren Emails an dieser Stelle noch braucht. Falls nicht, dann kann man diese Ordner ja per Strongbox sichern und dann im Produktivsystem vor der Migration löschen. Wenn man die Emails noch im Produktivsystem braucht, dann legt man am besten einen neuen allgemeinen Ordner im Infocenter an (z.B. "Alte Emails"), dahinein dann Unterordner für die alten User oder einfach nur "Eingang" und "Ausgang" und dann kopiert man die Nachrichten dort hin. Hauptsache, die Daten sind nicht unter "Benutzer" zu finden, denn die Daten dort werden nur dann migriert, wenn auch ein aktiver Benutzer im Altsystem zugeordnet ist. Auf den Datenschutz gehe ich hier nicht ein - jeder Admin muss wissen, wie er mit Emails ausgeschiedener Mitarbeiter umgehen muss/soll.

- Wenn im Grabbing-Server noch Einträge für POP3-Abholung sind, die sich im DvAdmin nicht löschen lassen, weil sie z.B. bei einem früheren User angelegt wurden, der User aber zwischenzeitlich gelöscht ist, dann sollte man diese im Info-Center unter SERVER\System\David\Grabbing Server löschen und den Grabbing-Server neu starten. Solche Altlasten können die Migration zum Absturz bringen, weil der dazu passende User nicht gefunden wird.

Überhaupt sollte man im Produktivsystem alle Unstimmigkeiten vor der Migration beseitigen. Das gehört aber prinzipiell bei DAVID mit zur Systempflege und alles was hier aufgeführt ist, sollte unabhängig von einer fälligen Migration immer wieder geprüft und erledigt werden. Ihr habt mit Eurem DAVID dann auf Dauer wesentlich weniger Kopfschmerzen.

Ist der Quellserver auf diese Art überprüft/vorbereitet, noch ein kurzer Blick auf den Zielserver: Hier muss man den DAVID einmal grundinstallieren. Es reicht prinzipiell, die Grundlizenz einzurichten und man kann dazu einfach die vorhandene Lizenz nehmen. Hauptsache ist, dass der DAVID dort erst mal mit seinen Diensten und der SQL-Datenbank läuft. Alle übrigen Einrichtungen kann man sich sparen. Die übrigen User- oder Portlizenzen werden bei der Migration automatisch mit übernommen.

Dann kann es ans Migrieren gehen. Die letzte Checkliste schaut hier wie folgt aus:

- Quell- und Zielserver sollten im selben Netzwerk/Subnetz sein

- Quell- und Zielserver sollten sich gegenseitig "sehen" können, d.h. DNS sollte einwandfrei funktionieren. Mit Kommunikation über IP-Adressen solltet Ihr gar nicht erst anfangen.

- Firewall und Virenscanner sollten auf beiden Servern für die Migration deaktiviert werden

- Wer ganz sichergehen will: Man sollte schauen, ob man auf das DAVID-Verzeichnis des Quellservers vom Zielserver aus per Laufwerksmapping rankommt und dort Dateien lesen kann.

Das Migration-Tool wird dann auf dem Zielserver (dem neuen Server) gestartet. Der Rest ist benutzergeführt. Wenn die Migration startet, kann man sich zurücklehnen und zuschauen. I.d.R läuft das Ding einfach durch, danach werden auf dem Zielserver die Dienste gestartet und das war's. Es gibt am Ende der Migration einen Bericht, den man eingehend überprüfen sollte. Sind Fehler aufgeführt, dann muss man diese einzeln abarbeiten und ggfs. korrigieren. Meist handelt es sich dabei aber um Unregelmässigkeiten im Datenbestand des alten Servers, die den normalen Betrieb bisher nicht gestört haben und die auf dem neuen Server jetzt nicht mehr vorhanden sind.

Natürlich muss man dann noch ein paar Dinge anpassen (Firewall-Eintragungen, Portforwardings, ...). Evtl. muss auch der Port für den Webaccess/EAS angepasst werden, denn alle diese Dinge werden durch die Migration-Services komplett 1:1 übernommen. Die SQL-Datenbank läuft nach der Migration aber bereits (bei einem neuen DAVID V3 ist es dann der SQL 2017) und die Volltextsuche und der Chat gehen sofort und die alten Daten sind auch da.

Sollten die Migration Services während der Migration abstürzen und man die Ursache nicht schnell finden können, dann ist es immer möglich, den DAVID auf dem alten Server einfach durch Neustarten der Dienste sofort wieder in Betrieb zu nehmen. Durch die Migration werden dort keinerlei Daten verändert. Bei einem Absturz gibt die Auswertung des bis dahin geschriebenen Log-Files meist wertvolle Hinweise auf die Ursache (wenn das Tool nicht aus Speichermangel o.ä. abgestürzt ist).

Noch ein Wort zur Geschwindigkeit der Migration: Mit Robocopy geht das Kopieren natürlich schneller, dafür läuft der Server mit den Migration Services hinterher sofort und es muss nur noch wenig angepasst werden. Bei umfangreichen Servern (mehrere hundert Gigabyte) kann es natürlich auch mal 24h oder länger dauern, bis der Server wieder läuft. Ganz grob kann man von ca. 2,5h für 100 GByte DAVID-Datenbestand ausgehen. Das hängt aber entscheidend von der Geschwindigkeit des alten und des neuen Servers und deren Festplattensystemen ab.

Wenn der Server nicht so lange Offline sein kann, dann muss man sich aber etwas anderes überlegen. Evtl. ist es dann günstiger, den neuen Server komplett manuell einzurichten und die Daten der User dann im Produktivbetrieb aus Strongbox-Images des alten Servers zuzuspielen. Das wird von den Usern meist akzeptiert.

Einen Königsweg für die DAVID-Migration gibt es nicht. Je nach Situation, Umfang des Servers, ... gibt es verschiedene Wege, die hier ans Ziel führen. In jedem Fall muss man aufgrund der Datenstruktur von DAVID alleine für den Datentransfer vom alten Server einiges an Zeit einplanen.

Du meldest Dich unter https://de.tspn.tobit.software im Partner-Network an und kannst dann alles bestellen/kaufen, was Dein Herz (oder das Deiner Kunden) begehrt. Dort hast Du auch Zugang zu allen Kundendaten, Lizenzdokumenten, ...

Das hört sich für mich nach Performance-Problem an. Bitte zuerst am Server prüfen: Der Server sollte nicht stark ausgelastet sein, er sollte genügend Plattenplatz haben und die SQL-Express-DB sollte nicht an der 10 GByte Grenze sein. Ausserdem sollten, falls ein Virenscanner auf dem Server läuft, die ARCHIVE.DIR und die ARCHIVE.DAT-Dateien dort als Ausnahmen definiert sein und vom Scanner nicht angetastet werden (ein Teil der Suche für lange Betreffs und Kommentare läuft genau über diese Dateien, aber auch jede Änderung in einem Archive bewirkt immer auch eine Änderung dieser Dateien).

Wenn die o.a. Punkte auf dem Server erfüllt sind, dann solltest Du Dir mal die Ein-Ausgänge der User anschauen und prüfen, ob da nicht vielleicht 10.000 und mehr Emails flach in den Ordnern liegen. Auf Dateiebene des Servers kommen da schnell mal 20.000 - 30.000 Dateien in einem Windows-Ordner zusammen und dann kann es beim DAVID ätzend mit den Reaktionszeiten werden. Email-Ein- und Ausgänge, die mehr als 2000-3000 Emails haben, sollten mit Unterordern versehen werden und alte Emails sollten da hinein verschoben werden. Das geht über die Archivierungsfunktion in DAVID sogar automatisch, so fern man eine nach Jahr/Monat geordnete Struktur brauchen kann.

Dann würde ich schauen, ob die Probleme immer noch vorhanden sind. Falls ja, dann würde ich mir einen Client-Rechner exemplarisch herausnehmen und dort in den Ein-/Ausgängen erstens die Kommentarspalte ausblenden und dann in der Ansicht die Unterstützung für lange Betreffs abschalten.

Wenn die Fehler dann schlagartig weg sind, braucht Ihr definitv einen schnelleren Server mit deutlich schnelleren Platten. Ansonsten mal den Virenscanner lokal auf dem Client für weitere Tests deaktivieren. Wenn das hilft, dann müsst Ihr den DAVID mit allen seinen Teilen als Ausnahme im Virenscanner anlegen.

Falls Ihr Kaspersky Endpoint-Security o.ä. verwendet: Deaktivieren reicht hier für einen Test nicht, wenn der DAVID-Client oder Teile davon unter "Basisschutz" - "Firewall" - "Regeln für Programme" in einer der eingeschränkten Gruppen ist. Dann müsst Ihr den DAVID in die Gruppe "unbeschränkt" verschieben, weil der DAVID über "ungewöhnliche" Ports und Protokolle mit dem Server redet und das wird immer vom Scanner untersucht (und damit gebremst).

Viel Erfolg!

Werner

Bei "Fehler in der Kommunikation": Schau Dir im DvAdmin mal im Monitor des Postman die Kommunikation beim Versenden einer derart weiter geleiteten Email an. Du musst vielleicht den Level der Monitorinformationen höher einstellen, um die geamte Kommunikation mit zu bekommen. U.U. sagt Dir der SMTP-Server Deines Providers im Monitor dann direkt im Klartext, was ihm nicht gefällt.

Beim Weiterleiten von Nachrichten per Regel lässt der DAVID die ursprünglichen Absender/Empfänger unverändert. Es kann sein, dass der SMTP-Server Deines Providers solche Emails nicht annimmt, weil der Absender in der weiter geleiteten email nicht zu Deinem Konto oder Deiner Email-Domain passt. Für den Provider bist Du dann ein Spammer .

Auf der Empfängerseite findet natürlich auch eine Überprüfung statt: Wenn das dort abgelehnt wird (spricht viel dafür, weil Deine Weitelrteitungen ja z.T. funktionieren), dann kommen die Emails halt mit einem Fehlercode zurück. Und wenn Dein DAVID direkt als MX eingetragen ist, gilt das selbe, nur dass die Ablehnung wegen Spam-Verdacht dann direkt vom Empfangsserver kommt (also von den Eingangservern von MAC.COM/ME.COM.

VIele Grüße

Werner

Dafür gibt es keine Variable und auch sonst keinen Trick. Das Signieren ist ja gerade ein Schutz vor Veränderungen an einer Email und geht alleine vom Absender aus. Die Email wird beim Abschicken "eingepackt", die Attachments kommen dran und die Signatur ist dann sozusagen das Siegel drum herum. Erst danach geht es in den Versand, wobei es keine Rolle spielt, ob die Empfänger interne oder externe Adressen sind. Bei mehreren Empfängern erhält jeder seine Kopie mit der Signatur und alle diese Kopien sind i.d.R. nicht mehr veränderbar.

Ausnahmen gibt es nicht, es sei denn, das Signieren wird nicht durch den Email-Client, sondern z.B. durch ein Verschlüsselungsgateway gemacht, das zwischen DAVID-Server und Internet/Provider sitzt. Hier kann man empfängerabhängige Policies für das Signieren/Verschlüsseln definieren. Dann würde nur die ausgehende Email signiert, die interne Kopie bliebe unsigniert. So ein Gateway kann bei eingehenden Emails auch Signaturen entfernen, damit man auch bei signierten "Fremdemails" alle Möglichkeiten offen hat.

Ihr werdet leider Euren Workflow ändern müssen und ggfs. die Email einmal unsigniert intern und dann noch einmal signiert zum Kunden schicken müssen. Es gibt dafür im DAVID keine Regel oder sonstigen Trick, um das mit Bordmitteln zu automatisieren.

Gehe im Client auf "Optionen", "Einstellungen", "Ansicht" und mache dann den Haken raus bei "Minimieren des Ticker-/Navigator-Bereichs". Abspeichern mit "OK" - das sollte es gewesen sein.

Vermutlich verteilst Du in Deinen Regeln nach "Empfänger ist gleich ....". Benutze statt dessen "Verteilkennung ist gleich ..." und die betreffende Emailadresse. Dann sollte das auch funktionieren, wenn die Empfängeradresse im CC: oder BCC: steht.

Hallo zusammen,

wir haben einen Kunden, der einen Bintec RT1202 als generellen Router/Firewall und zusätzlich zusammen mit DAVID als Anrufbeantworter und Faxgateway einsetzt. Der RT1202 hängt dabei an einem internen S0-Port der Telefonanlage, Anbindung an den DAVID erfolgt mit Remote-CAPI von BINTEC. Das hat jetzt ein paar Jahre einwandfrei funktioniert.

Vor ca. zwei bis drei Wochen konnte der Bintec plötzlich nichts mehr auf den S0-Ports empfangen (eingehende Anrufe wurden nicht mehr beantwortet, keine B-Kanal Aktivität mehr bei eingehenden Anrufen - also nicht der Timeout-Error bei bestimmten Firmware-Releases). Im Status-Monitors des betreffenden TLDs gabs im DAVID bei eingehenden Anrufen auch keinerlei Aktivität. Das Versenden von Faxen war aber noch fehlerfrei möglich. Seit gestern ist jetzt auch die Versandmöglichkeit weg gebrochen. Im Status-Monitor erscheint beim Sendeversuch die Meldung "CONNECT_CONF (0x2002) Illegal Controller/PLCI/NCCI".

TLD's wurden bereits mehrfach entfernt und neu angelegt, als Remote-CAPI haben wir auf dem DAVID-Server 1.1.5 und 1.1.8 probiert, bei beiden das selbe Verhalten: Die CAPI-Konfiguration erkennt den Router und sagt, dass alle Controller bereit sind, alle Tests verlaufen positiv. Nur der DAVID kann nichts mehr versenden (Illegal Controller) und einen Anruf bekommt er nicht mit, da der Bintec sich in dem Fall "tot" stellt.

Vermutlich ist das DSP-Board im Bintec gestorben, das Gerät ist mit 6 jahren auch schon gut alt. EIne Reparatur über Bintec wäre möglich, kostet aber natürlich relativ viel und vor allen Dingen mehr als eine neue be.IP Plus.

Jetzt die Frage: Hat jemand von Euch eine be.IP Plus schon einmal in dieser Konfiguration zusammen mit DAVID eingesetzt und kann bestätigen, dass sowohl Voice als auch Fax damit gehen? Können die ISDN-Ports der be.IP Plus als externe ISDN-Ports konfiguriert und dann über Remote-CAPI vom DAVID aus angesprochen werden, um damit Faxe (nicht über SIP, sondern über ISDN) zu versenden? Funktioniert dann auch die Unterscheidung Voice/Data für die Anrufbeantworter-Funktion über den DAVID noch?

Vielen Dank schon im Voraus für Eure Erfahrungen/Tipps!

Aufgrund Eurer speziellen Konstellation (Server in Singapur, Hong Kong, ...) gehe ich nicht davon aus, dass der Großteil Eurer Rechner den Client mit Offline-Datenbestand nutzt, sondern als reiner Client (wie in einem "normalen" Büro) eingerichtet ist. In diesem Fall gibt es keinen lokalen Datenbestand, in dem etwas gesucht wird, sondern die Suche erfolgt immer online auf dem Server. Gleiches gilt auch für den mobilen Client, wenn er online ist. Hier wird auch nicht lokal, sondern immer auf dem Server gesucht.

Der Quickfinder benutzt dazu nicht die SQL-Datenbank, sondern "wühlt" direkt in den ARCHIVE.DAT-Dateien des betreffenden Ordners und den Emaildateien selbst herum. Das ist an sich schon relativ langsam, weil es hier keinerlei Indizierung gibt. Es ist aber mit Einführung der langen Betreffs und der Kommentare noch langsamer geworden, weil diese Feldinhalte nicht in der ARCHIVE.DAT enthalten sind, sondern nur z.B. in den Emaildateien zu finden sind oder separat abgespeichert werden. Wenn der Client lange Betreffs nutzen soll oder die Kommentare eingeblendet sind, dann führt das zu einer Verfielfachung des Datenverkehrs zwischen Client und Server und der Client muß viel mehr unstrukturierten Text durchsuchen. In großen Archiven kannst Du deshalb den Quickfinder auf einem Client mit schlechter Anbindung und aktivierten langen Betreffs und/oder Kommentaren fast vergessen. Die SQL-Suche dagegen läuft immer auf dem Server und ist deswegen schneller. Hier gibt es allerdings ein paar Einschränkungen gegenüber der Quicksearch (z.B. die von Microsoft für die Textsuche auf dem SQL-Server festgelegten Stopwords, die eine Suche nach Einzelbuchstaben oder oft vorkommenden Begriffen wegen zu vieler möglicher Treffer verhindern). Das ist aber ein Thema für sich.

Wird das TIC dagegen als mobiler Client mit Offline-Nutzung installiert, werden die Daten vom Server auf die lokale Platte des Client repliziert und können da offline genutzt werden. Im Offline-Modus sucht das TIC dann auch wirklich lokal auf der Platte. Und da das sehr viel schneller geht, bekommt man da auch das Ergebnis flotter angezeigt. Die lokalen Daten werden aber nur dann genutzt, wenn der Client wirklich offline ist.

Was den Zugriff auf Archive bei schlechter Anbindung übrigens ebenfalls noch deutlich beschleunigt ist das Ausschalten der Vorschau. Hier müssen dann nur die Kopfzeilen der Emails übertragen werden, nicht jedoch Inhalte.

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.