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.
Ende Januar habe ich das einem andernen Anfragenden unter diesem Link schon einmal beschrieben und das sollte das Problem lösen:
scanning to Tobit server for emails
Der Fragesteller wollte zwar wissen, wie er von seinem Kopierer aus eine Email an interne Empfänger senden kann, aber das ist im Prinzip dieselbe Ausgangssituation.
Mein o.a. Post war zwar auf Englisch, aber ich denke, dass Du damit klarkommst. Ansonsten bitte noch mal nachfragen.
Mach einen völlig neuen Ordner auf, und zwar am besten einfach im Infocenter mit einem Rechtsklick und dann "Neuer Ordner". Verschiebe alle Einträge aus Deinem alten Ordner dorthin. Der alte Ordner sollte danach leer sein.
Jetzt lösche Deine beiden Einträge für die alten Ordner. Es bleibt Dir überlassen, ob Du den neuen Ordner danach einfach umbenennst oder das ganze Spiel wieder zurück drehst.
Von ARCUTIL würde ich hier abraten, denn man kann damit sehr schnell sehr viel kaputt machen. Und den Trick mit den geschweiften Klammern im Namen wende ich nur in Notfällen an.
Please do the following: Start your DAVID.Administrator, go to "System" - "Configure" and put your domain into the field "Domain" on the first tab (fx. "disney.co.uk").
Then go to "Email" - "Postman" - "Configure" and put the same domain in the field "SMTP Host Name" on the first tab.
Next take a text-editor, go to the DAVID-directory on your server, open the folder \\DAVID\APPS\POSTMAN\Code and edit the file POSTMAN.INI. Look for the entry "EHLOWITHDOMAIN", remove the ";" in front of it and set the value to TRUE. The line should now look like "EHLOWITHDOMAIN=TRUE". If there is no such line in your file than add it.
Save the text file and restart service-layer and postman within the DAVID.Administrator. That should fix it.
Falls die Clients unter Windows 10 laufen, dann gibt es da speziell mit dem Creators-Update und älteren DAVID-Versionen einige Probleme. Hast Du schon einmal geschaut, ob auf dieser Seite ein passender Patch für die fraglichen Clients dabei ist:
https://david.tobit.software/Windows10FallCreatorsUpdate
Ausserdem hat Microsoft Ende im letzten Quartal 2017 einige Updates für die MSHTML.DLL des Internet Explorers herausgebracht (alle noch unterstützten Windows-Versionen). Da die älteren DAVID-Versionen sehr stark von der MS-HTML-Engine abhängig sind, kann es da auch zu Problemen bei der Darstellung von HTML-formatierten Emails kommen. Dafür hilft aber i.d.R. ein (auch einmaliger) Update auf die aktuelle DAVID-Version.
In Bezug auf weitere Anniversary-Upgrades bei Windows 10 wird auf Dauer aber nur Sitecare helfen.
Das hatte ich bei einem Kunden auch, der das Jahresendangebot für Upgrade/Sitecare angenommen hat. Ich gehe anhand Deines für die Gültigkeit von Sitecare genannten Datums davon aus, dass es bei Euch auch so ist.
Grund war (nach Auskunft eines Mitarbeiters von TOBIT), dass für die betreffende Site "SystemServices" in der Datenbank von TOBIT deaktiviert waren. Sitecare gehört da offensichttlich dazu und liefert in dem Fall die o.a. Meldung. Die Rollouts werden dann zwar herunter geladen, aber nicht automatisch installiert.
Der Kunde hat wissentlich nie die Deaktivierung eines Service bei TOBIT beantragt. Er hat über die Jahre hinweg aber auch keinerlei sonstige Services von TOBIT genutzt (weder Spam-Filter, noch Virenscanner, ...).
Es hat gereicht, das Problem an TOBIT über das Intercom zu melden und sie zu bitten, SystemServices wieder zu aktivieren. Danach lief Sitecare wie erwartet und die Fehlermeldungen waren weg.
Was soll dieser Scheiß? Das ist doch keine Update-Politik, das ist unausgegorenes Rumgepfusche. Unter dem Zwang, den eigenen großspurigen Aussagen zu "alle zwei Wochen ein Update" auch Taten folgen zu lassen, wird in letzter Zeit viel zu oft Mist in Ahaus gebaut.
Ständig unnötige Veränderungen der Benutzeroberfläche, weil man sonst offenbar keine neuen Ideen mehr hat (siehe z.B. Anzeige der markierten Emails). Einbau sinnloser Dinge, die gleich wieder in der Versenkung verschwinden (siehe Veränderungen an der Suchfunktion). Echte Fehler, die niemandem auffallen, weil man unter dem Druck des Updates offenbar keinerlei Tests mehr macht, ...
Mann oh Mann! Was ist das nur für ein Laden geworden?
Liesschen Müller freut sich vielleicht, wenn jede Woche was neues aus Ahaus kommt. Aber die Administratoren größerer Installationen finden es langsam zum Kotzen, die User sind verwirrt und die Chefs nicht amüsiert.
DAVID kann auch in der aktuellsten Version problemlos auf Windows XP, Server 2003 oder Server 2008 (ohne R2) installiert werden. Wie lange das aber noch so weitergeht, kann nur TOBIT beantworten.
Beim Infocenter war die letzte installierbare Version unter XP die aus dem Rollout 276. Neuere Infocenter lassen sich unter XP nicht mehr installieren und auch das automatische Update funktioniert dort nicht mehr. Mit dem Infocenter 276 läuft aber z.B. ein als DAVID-Server eingerichteter Windows XP Rechner auch mit Rollout 279 vollständig und ohne jedes Problem (auch EAS, Webbox, IMAP, ...).
Am sinnvollsten wäre gleich eine Weiterleitung der Emails vom eingehenden POP3-Postfach auf das entsprechende Postfach des Archivservers. Bei Strato, UDAG und 1und1 kann man das direkt in den Einstellungen des Postfachs einrichten (Email-Weiterleitung). Bei anderen Providern sicher auch, aber leider nicht bei allen.
Der DAVID kann dann trotzdem parallel per POP3 abholen und auch gleich immer alles löschen, weil diese Weiterleitung an den anderen Server sofort beim Eingang neuer Nachrichten auf dem Konto durchgeführt wird.
Am DAVID-Server kannst Du das m.E. nicht mit Regeln o.ä. machen, weil die Nachrichten dadurch immer verändert werden.
Wenn Dein Provider Email-Weiterleitung nicht unterstützt, dann kannst Du nur ein Emailarchiv, wie z.B. den Mailstore-Server einsetzen. Den kannst Du als Proxy-Server zwischen DAVID und Deinen Provider hängen und quasi alles "mitkopieren" lassen, was rein und rausgeht. Alternativ kann er auch per IMAP direkt an den DAVID-Userkonten andocken und diese auslesen. Da hat der User aber immer die Möglichkeit, Emails zu löschen, bevor der Archivserver sie gelesen hat.
Dein(e) Archiv(e) ist/sind dann aber immer erst einmal lokal auf einem internen Rechner. Du kannst von dort aber die archivierten Konten wieder per automatischem Export per IMAP auf einen externen Server hochladen. Ist zwar ein Umweg, funktioniert aber in der Praxis hervorragend.
Das ist schon immer so bei DAVID. Direkt von einem Bug kann man nicht sprechen, eher von einer Eigenheit des Programms (eine von vielen eben ). Es wird bei eingehenden Emails überall der Versandzeitpunkt eingetragen/angezeigt und nicht der Zeitpunkt, wann die Nachricht bei Deinem Provider oder Deinem DAVID-Server (wenn er als MX eingetragen ist) eingegangen ist.
Für Nachweiszwecke muss man beim DAVID also immer auf den SMTP-Header der Nachrichten zurückgreifen, denn da steht natürlich im Klartext, wann die Email abgeschickt, wann sie weiter geleitet und wann sie bei Deinem Server eingegangen ist. Outlook und Konsorten nehmen für die Anzeige immer diese Daten.
Wenn Du einen vorgeschalteten Provider hast, dann steht als letzter Zeitpunkt im Header natürlich immer der Zeitpunkt, zu dem die Nachricht beim Provider eingetroffen ist. Wann Dein Server sie dort abgeholt hat interessiert nicht, weil es im Zweifel ja Dein Problem ist, wenn eine Nachricht dort längere Zeit liegen bleibt, weil z.B. Dein Server Offline ist.
Basti hat damit zwar generell recht (das Dateisystem vom DAVID ist ein resourcenfressender Dinosaurier), das dürfte hier aber keine Rolle spielen. Du nutzt ja intern wie extern den Terminalserver und intern läuft es ja wohl zufriedenstellend.
Versuche, im per VPN genutzten Remote Desktop-Client die Farbtiefe in der Session von 32bit auf z.B. 24bit oder gar 16bit zu verringern. Das Grafikframework, das TOBIT beim Infocenter benutzt, ist leider nicht besonders windows-affin (siehe auch die vielen bescheuerten Fehler mit der Grafikdarstellung beim Infocenter unter Windows 10). Es könnte sein, dass sich der Terminalserver mit dem Infocenter im Vollbildmodus, wo ja keine Fensterrahmen oder Gestaltungselemente mehr von Windows zu sehen sind, extrem schwer tut, zumal TOBIT vermutlich nur noch auf Windows 10/Server 2016 hin optimiert.
Wenn Dein extern genutztes Gerät z.B. ein Notebook mit Full-HD-Display oder höher ist, dann bringt es auch etwas, statt des normalen MS-RDP-Clients den MS RDC-Manager zu verwenden, der das Bild selbständig skaliert. Die Session läuft dann nicht mit der nativen Auflösung des verwendeten Rechners, sondern mit einer kleineren Auflösung und vergrößerter Darstellung. Das könnte die Sache auch deutlich beschleunigen/verbessern.
Das stimmt so nicht. Wie in dem oben verlinkten Video mehrfach gesagt, kann man max. 18 Einträge in die Liste machen und diese dann im Kalender und in den Aufgaben von DAVID verwenden. Mehr gehen nicht. Standardmässig sind 10 Einträge vorhanden.
Natürlich kann man mehr Einträge in der TOBIT!.GER machen, diese werden aber im Infocenter ignoriert.
