Beiträge von wlconsult

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.

Da habe ich letztes Jahr schon mal in die Runde gefragt und dann ein eigenes Formular gemacht:

Eigene ATTACHMENTS.HTM erstellen

TOBIT hat damals übrigens mit langer Verzögerung und nach mehrmaligem Nachfragen mitgeteilt, dass es nur die drei in dem Thread genannten Variablen gibt.

Hi Tino,

das Problem hatte ich auch mal bei einem Kunden. Am DAVID kannst Du diesbezüglich nichts verstellen, das Timeout ist fest "verdrahtet". Wenn die Emails bei einem Provider sind, der auch einen Webmail-Zugang bietet (Strato, 1 & 1, UDAG, ...), dann kannst Du versuchen, die Emails über das Webinterface aus dem Eingang heraus in einen anderen Ordner im selben Postfach zu legen.

Beim POP3-Protokoll "sieht" der DAVID ja nur den Eingang und holt alles dort ab, andere Ordner interessieren ihn aber nicht. Auf diese Weise solltest Du den Eingang freischaufeln können. Probiere einfach aus, wieviele Emails Du drin lassen kannst, ohne dass der DAVID beim Abholen wieder in das Timeout läuft. Danach verschiebst Du im Webinterface die nächste Ladung zurück in den Eingang und immer so weiter, bis Du alles geschafft hast. Dauert zwar eine Weile, könnte aber funktionieren.

Wenn das nicht geht, dann würde ich mir eine kostenlose Testversion vom Mailstore-Server holen, diesen installieren und dann per POP3-Connector die Postfächer damit leeren. Du hast dann eine lokale Kopie der Emails aus den Postfächern und die Postfächer beim Provider sind leer. Danach kannst Du die Emails dann z.B. per IMAP stückchenweise wieder an Deinen Provider zurückgeben, wo sie dann der DAVID abholen kann. Theoretisch könntest Du sie auch gleich von Mailstore-Server direkt per IMAP dem DAVID über den Mailaccess-Server einspielen, dabei würden sie dann aber nicht über den Spamihalator laufen.

Auf die eine oder andere Art klappt das aber bestimmt.

Viele Grüße
Werner

Hi Joe,
dieses Problem haben wir auch bei einem unserer Kunden. Dort ist es Ende Dezember nach dem Einspielen des Rollout 259 aufgefallen, es ist aber offenbar schon wesentlich länger vorhanden. Der Kunde hatte vor Rollout 259 nur kein Sitecare.

Der Kunde hat eine große DAVID-Installation und bekommt 600-700 Emails am Tag (große Kanzlei). Es gibt einen zentralen Posteingang mit zwei Mitarbeitern, die die meisten dieser Emails auch für die Akten ausdrucken müssen. Wenn einer dieser Mitarbeiter die 50. Email ausdruckt (Anhänge zählen hier nicht, denn die werden per Doppelklick geöffnet und dann von der jeweiligen Software, also Word, Excel, Acrobat, ... gedruckt), druckt der DAVID-Client einfach nichts mehr aus, d.h. es wird auch nichts mehr in die Druckerwarteschlange gestellt.

Man muss den Client dann beenden. Dabei kommt dann meist die Meldung, dass es noch einen ausstehenden Druckauftrag gibt und ob trotzdem geschlossen werden soll. Wenn man aufJa" geht und anschliessend den Client wieder startet, kann man wieder 49 Emails drucken, danach beginnt das Spiel von vorne. Anmerkung: Ob es immer genau nach der 50. Email passiert, kann ich nicht absolut sagen, die Tests hat der Kunde gemacht. Es geht aber ziemlich genau in diese Richtung. Die Windows-Version des Arbeitsplatzes spielt keine Rolle.

Alle uebrigen Programme auf dem betreffenden Arbeitsplatz koennen in der ganzen Zeit normal weiter drucken, auch wenn der DAVID-Client den Druck schon eingestellt hat. Es liegt also nicht am Drucker/-treiber, an der Warteschlange oder am Spooler-Dienst.

Wir haben das Problem auch bei uns nachvollziehen können und es dann dem TOBIT-Support mitgeteilt. Es gab mehrere Postings hin- und her. Schliesslich konnte man es dort offenbar auch exakt reproduzieren. Nach Aussagen des Supports handelt es sich um ein Problem im Zusammenspiel zwischen dem Infocenter und der MSHTML.DLL. Diese gehört zum IE und wird von TOBIT für die Darstellung und den Druck der HTML-formatierten Emails mit benutzt. Die DLL quittiert beim wiederholten Aufruf durch das Infocenter irgendwann den Dienst und dann passiert einfach nichts mehr.

Lt. Aussagen des Supports von TOBIT wird "an einer umfangreichen Umstellung gearbeitet". Sie können aber nicht sagen, wie lange das dauert. Diese Information ist vom Februar diesen Jahres, seither gab es keine weiteren Infos und der Fehler ist auch nicht behoben.

Rollout 259 beinhaltet das Infocenter mit der internen Version 6684, momentan sind wir bei 6707. Mit dem Infocenter 5967 z.B. tritt das Problem nicht auf. Du kannst also nur versuchen, auf den problematischen Arbeitsplätzen ein älteres Infocenter z.B. vom Anfang 2016 oder noch früher zu installieren. Ansonsten heisst es warten auf TOBIT.

Viele Grüsse
Werner

Ja, das ist leider schon seit Jahren so: Mehr als 96 Zeichen gehen nicht - auch nicht per Trick. Einige meiner Kunden hätten da auch schon lange gerne mehr, zumal es in z.B. Outlook überhaupt keine Probleme damit gibt. Aber TOBIT ignoriert diesen Wunsch offensichtlich (vielleicht gibt's da ja auch einen technischen Grund dafür, den wir nicht kennen).

Und bevor jetzt jemand kommt und sagt: "Braucht man nicht": Im Zeitalter, wo viele Emails aus Dokumentenmanagement-Systemen kommen und Betreffs z.T. automatisch erzeugt werden, gibt es immer mehr Nachrichten, die solche langen Betreffs haben. Und wenn man die mit DAVID beantwortet, schneidet das System einfach alles nach 96 Zeichen ab. Das bedeutet, dass die Gegenseite die Email nicht mehr eindeutig identifizieren kann, weil da ein Teil des Betreffs fehlt. Das gilt natürlich auch für Suchfunktionen in z.B. Email-Archivsystemen, ...

Es wäre wirklich wichtig, dass TOBIT hier mal nachrüstet. Aber man ändert in Ahaus statt dessen lieber gerne die Farben oder das Layout des Infocenters und verkauft das als große Innovation.

Vermutlich ist bei Euch im DAVID-Administrator unter "System" - "Ports"
in den Eigenschaften des David-Postman unter "Dienste" der Punkt
"eMail-Rundsendung" deaktiviert. DAVID schickt dann wie in Eurem Fall
bei mehreren Empfängern einzelne Emails raus. Die Empfänger der
Nachricht können dann nicht sehen, wer diese Nachricht noch bekommen
hat.

Einfach den Haken setzen und den Postman neu starten. Danach sollte das funktionieren.

Gruß
Werner

Vermutlich ist bei Euch im DAVID-Administrator unter "System" - "Ports" in den Eigenschaften des David-Postman unter "Dienste" der Punkt "eMail-Rundsendung" deaktiviert. DAVID schickt dann wie in Eurem Fall bei mehreren Empfängern einzelne Emails raus. Die Empfänger der Nachricht können dann nicht sehen, wer diese Nachricht noch bekommen hat.

Einfach den Haken setzen und den Postman neu starten. Danach sollte das funktionieren.

Gruß
Werner

PS: Wenn Ihr natürlich öfter Rund-Emails an alle Eure Kunden schickt, bei denen Ihr einfach alle Empfänger in das TO:-Feld packt, dann solltet Ihr für diese Zwecke den Haken wieder tunlichst rausnehmen, denn sonst wissen alle Eure Kunden, mit wem Ihr sonst noch Geschäfte macht. Für diese Zwecke gibt es in DAVID sog. Rundsendedateien, die dann vom DAVID trotz des o.a. Hakens in einzelne Emails "aufgelöst" werden.

Im Prinzip ist das schon so, wie es Winkler oben beschrieben hat: Du erstellst mit TLSCERT.EXE ein CRT-Request. Aus der PEM-Datei des CRT-Request schneidest Du mit einem Editor den Abschnitt "-----BEGIN CERTIFICATE REQUEST----- ....... ----- END CERTIFICATE REQUEST----- raus und beantragst damit Dein Zertifikat bei einem Aussteller Deiner Wahl. Den Part mit dem PRIVATE KEY brauchst Du dafür nicht.

Wenn Du Dein Zertifikat hast, dann kopierst Du Dir mit einem Editor den Part "-----BEGIN CERTIFICATE----- ....... -----END CERTIFICATE -----" raus und setzt es in Dein ursprüngliches Certificate Request nach dem Part mit dem PRIVATE KEY ein. Den CERTIFICATE REQUEST-Teil löscht Du.

Das so gebastelte Zertifikat speicherst Du als "WBCERT.PEM" (nicht "WEBBOX.PEM" !) im Verzeichnis \DAVID\APPS\WEBBOX\CODE ab und startest die Webbox anschliessend neu. Wenn es vorher mit Deinem selbstsignierten Zertifikat funktioniert hat, dann sollte das auch sofort funktionieren. Dieses Zertifikat gilt dann für die Webbox, EAS und postlagernden Versand.

Es ist meiner Erfahrung nach nicht notwendig, das Root- und das Intermediate-Zertifikat da auch mit abzuspeichern. Wenn das Zertifikat z.B. von Commodo kommt, reicht die o.a. Vorgehensweise völlig aus. Wenn Du allerdings einen "exotischen" Herausgeber hast, kann es nicht schaden diese Infos zusätzlich mit rein zu packen.

Die Strongbox wäre um einiges besser nutzbar, wenn TOBIT es endlich einmal schaffen würde, User-Credentials für das Ziellaufwerk bei den Strongbox-Aufträgen zu hinterlegen. Sicherungen schlagen nämlich immer dann fehl, wenn das Sicherungsgerät z.B. nicht in der Domäne ist und eigene/andere User/Passwort-Kombis braucht, als die DAVID-Dienste auf dem Server.

Da kannst Du auf dem DAVID-Server unter Windows als Administrator z.B. ein wunderschön gemapptes Laufwerk auf dein NAS haben und alle Schreib-/Leseoperationen gehen alle; Du denkst, dass die Strongbox also auch kein Problem damit haben wird, aber: Auf das gemappte Laufwerk kann der Strongbox-Job nicht zugreifen (er läuft ja als Dienst zu einem Zeitpunkt, wo der User abgemeldet ist und damit auch keine Mappings bestehen) und auf den UNC-Pfad kann er nur zugreifen, wenn der DIenste-User und der Zugriffs-User des NAS absolut identisch sind.

Die Forderung von Dieter/force01 kann ich absolut nachvollziehen. Jedes vernünftige Datensicherungsprogramm kann das (Acronis True Image Server, Symantec Backup exec, ...), nur TOBIT bringt das nicht zustande. Ich habe das schon mehrfach bei TOBIT zur Sprache gebracht - die Antworten kann man sich leider schenken

Hi Joe,

wenn man eine Email im Ausgang doppelt anklickt (=öffnet) und dann druckt, wird schon immer eine andere Vorlage verwendet, als beim Ausdruck der Eingänge. Die verwendete Vorlage (die hat nur einen zweizeiligen Kopf und dann eine Trennlinie vor dem eigentlichen Mailtext) ist noch ein Relikt aus der DAVID-Steinzeit und wurde so schon in Mailware und dann in DAVID 5 verwendet. Diese Vorlage ist fest im Service-Layer verdrahtet und kann so weit ich weiß nicht geändert werden. Warum das immer noch so ist, weiß vermutlich nicht einmal TOBIT.

Wenn Du die zu druckende Ausgangsmail statt dessen im Ausgangsarchive mit der rechten Maustaste anklickst, dort auf "Drucken..." gehst und dann "Lokaler Drucker" auswählst und "OK" klickst, wird für den nachfolgenden Druckvorgang dieselbe Vorlage wie für Eingangs-Emails verwendet.

Die Vorlage für die Eingangsemails kannst Du beliebig gestalten. Ich habe vor einigen Tagen hier in einem anderen Thread schon einmal eine geänderte Vorlage zum Download zur Verfügung gestellt, bei der im Kopf der Email auch die CC:-Adressen und die Attachments ausgegeben werden:

Bei Ausdruck Anhänge immer auf Seite 2

Du kannst diese ja einfach mal ausprobieren.

Werner

So, jetzt bin ich es selbst noch einmal. Nachdem TOBIT es auch nach mehrmaliger Anfrage meinerseits nicht geschafft hat, meine Frage nach den Variablen für eine eigene Attachments.htm-Datei zu beantworten, gehe ich davon aus, dass es neben den o.a. drei Variablen schlichtweg keine weiteren gibt, die hier funktionieren.

Die anhängende Mustervorlage in deutsch/englisch ist im Prinzip die Vorlage, die TOBIT selbst fest in den Service-Layer eingebaut hat. Ich habe sie ein bisschen umgeschrieben und mich auf die drei verfügbaren Variablen beschränkt.

Editieren lässt sich die Datei sehr gut mit z.B. Notepad++ oder jedem anderen HTML-fähigen Editor. Ich kann nur raten, dafür nicht Word zu verwenden. In Zeile 6 des Quellcodes kann der eigene Firmenname eingetragen werden (<TITLE>Mein Firmenname</TITLE>). Dieser erscheint dann beim Empfänger oben auf dem Browsertab. Selbstverständlich kann jeder den verwendeten Text beliebig abändern oder um zusätzliche Sprachen erweitern. Das Ganze ist als Muster zur freien Verwendung gedacht.

Wo im System die fertige Vorlage abzulegen ist, steht in meinem vorherigen Post. Die Vorlage ist dann sofort aktiv, Ihr müsst also keinen der DAVID-Services neu starten.

Viel Spaß beim Ausprobieren
Werner

Die Tests dazu konnte ich bei einem großen Kunden erst letzte Woche machen und mittlerweile auch bei anderen Kunden mit/ohne Sitecare nachprüfen.

Das Problem ist schon an TOBIT weitergegeben, eine Antwort steht allerdings noch aus. Der Fehler besteht aber mindestens schon seit einem Jahr, denn so alt war die älteste DAVID-Version (ohne Sitecare), mit der ich das testen konnte.

Hallo zusammen,

das Problem kann ich bestätigen und es tritt schon seit Längerem auf (ist also nicht auf die aktuellste DAVID mit Sitecare beschränkt):

Kommt von extern eine Termin-/Besprechungsanfrage herein, die im AN-Feld mehrere Empfänger aufweist (Empfänger-Adressen aus unterschiedlichen Domänen), dann nimmt DAVID als Absender-Adresse für eine Antwort immer die erste Adresse aus dem AN-Feld, auch wenn die mit dem internen Empfänger oder der eigenen Domäne nichts zu tun hat. Als Ergebnis wird diese Email vom eigenen Provider abgelehnt, wenn eine Überprüfung der Absenderadresse stattfindet. Alternativ lehnt der Empfangsserver die Nachricht ab, weil Absender-Adresse und -Domäne nicht übereinstimmen.

Korrekt macht der DAVID das nur, wenn es nur einen (internen) Empfänger für die Besprechungsanfrage gibt, oder wenn per Zufall der interne Empfänger an erster Stelle im TO:-Feld steht.

Ein ziemlicher Bock meiner Meinung!

Du musst die Druckvorlage für Emails ändern. Diese befindet sich im Verzeichnis \DAVID\Clients\Windows und hat den Namen EMAIL.PRN. Ich habe meine eigene und die von allen Kunden schon vor einigen Jahren abgeändert, weil die Liste der Anhänge m.E. auch in den Kopf der Emails gehört und nicht an das Ende. Wenn eine Nachricht etliche Male hin und her geht, dann stehen die Anhänge mit der Originalvorlage schliesslich dort, wo kein Anwender sie mehr sucht.

Ich habe meine EMAIL.PRN hier mal angehängt. Probiere sie einfach mal aus.

Werner

Dem kann ich nur zustimmen. Bei größeren Netzwerkinstallationen legt bestimmt jeder Admin Wert darauf, dass sich die einzelnen Anwender bei Tobit anmelden und dann unkontrolliert irdendwelche Dinge auslösen können. Der Button sollte mindestens per Voreinstellung ausblendbar sein und zwar so, dass der User am Arbeitsplatz ihn auch nicht wieder einblenden kann.