Beiträge von nordtech

Moin z'sammen,

bei einem Kunden habe ich auf seinen ausdrücklichen Wunsch hin David wie folgt konfiguriert: Es gibt einzelne User mit eigenen Konten in David, ABER es sollen alle ausgehenden Mails mit einer generischen Adresse das Haus verlassen, also im Format info@kundendomain.invalid. Gleichzeitig wünscht der Kunde, dass a) die info-Adresse als Default-Absender bei neu verfassten Nachrichten hinterlegt ist (die User also beim Schreiben einer neuen Mail nichts manuell umstellen müssen), dass b) aber eine manuelle Auswahl des individuellen Absenders (hans.schmidt@kundendomain.invalid) möglich bleibt.

Gelöst habe ich das so, dass die info@-Adresse jedem User als Hauptadresse zugewiesen ist und die eigene/individuelle als zusätzliche ein- und ausgehende Adresse. Was dazu führt, dass eingehende Mails auf der Info von David munter im Zufallsprinzip in die User-Eingänge geworfen werden. Macht aber nichts, in jedem persönlichen Eingang greift eine Regel, die Mails, die an die info... geschickt wurden, in ein Sammelarchiv umleitet. Das klappt auch.

Es gibt aber einen fiesen Sonderfall: Eingehende Besprechungsanfragen landen zwar ebenfalls im Sammelarchiv, nach dem Bestätigen taucht der Termin dann aber im Kalender jenes Users auf, an den die Besprechungsanfrage ursprünglich mal verteilt wurde. Und das kann, durch obige Konstellation, immer wieder ein anderer sein.

Fällt euch für dieses Szenario eine Lösung ein? Ich hatte überlegt, einen Dummy-User einzurichten, dem die info@-Adresse alleine gehört, dann weiß man zumindest immer, wo die Anfragen landen und kann sich die Termine dort in den eigenen Kalender ziehen. Um dann noch ohne manuelle Auswahl alle Mails ausgehend mit info@... zu verschicken, müsste ich allerdings eine include-Datei bauen, die den Absender überschreibt. Und damit entfällt dann die Option, bei Bedarf mit eigenem Absender versenden zu können.

Wer einen Tipp hat - gerne her damit. Momentan behilft sich der Kunde damit, dass er aus dem Ausgangsarchiv die bestätigte Besprechungsanfrage in seinen Kalender verschiebt, wo dann ein Termin daraus wird. Ist aber irgendwie nicht sehr elegant.

Doch, da klingelt was tief im Hintergrund. Ich hatte diese Meldung auch irgendwann einmal, und zwar im Zuge einer großen Systemumstellung mit Clonen des David-Servers. Da lag es an fehlerhaften Rechten: Prüf mal, ob Admins und SYSTEM auf alle David-Verzeichnisse zugreifen können und \David\apps\faxware\out\api für alle David-Benutzer beschreibbar ist. Letzteres scheint beim Clonen ab und zu verloren zu gehen, keine Ahnung warum. Und natürlich wäre es auch seltsam, wenn's bei euch der Fall wäre, ohne dass (abgesehen von der DHL-Geschichte) sonst nichts verändert wurde. Aber in meiner langen David-Karriere war das der einzige Anlass, zu dem "Die Nachricht konnte nicht versendet werden" auftrat.

Bringt das nichts, führe am besten erst einmal eine Bereinigung gemäß Knowledgebase Q-100.559 durch.

Sauber! RND reicht mir schon - die so generierte Zahl ist kommagetrennt, es kommt also ein Dateiname wie test0,3716439.eml dabei heraus. Passt.

Cossys' Frage ist auch interessant, das würde noch einen Doppelklick einsparen... Hat bei uns aber keine Priorität, immerhin ersparen wir dem Anwender das mühsame drag'n'drop, die Lösung im Nachrichteneditor ist also schon eine sehr praxisnahe.

Besten Dank noch einmal!

Hm, wobei: Eine Frage hab' ich doch noch. Der Export läuft derzeit von allen Plätzen in ein bestimmtes Verzeichnis, das dann vom Archivierungssystem gescannt und geleert wird. Somit ist es vermutlich in 99% der Fälle kein Problem, wenn der Dateiname bei allen Usern und Aktionen immer der gleiche ist, aber es KÖNNTE halt auch vorkommen, dass jemand die Datei "export.eml" überschreibt, bevor das Archivsystem sie weggefischt hat.

Daher schreibst du ja sehr richtig, dass es gut wäre, den Dateinamen mit weiteren Feldern zu ergänzen. Ich würde also gerne entweder eine Zufallszahl oder Datum/Zeit (sekundengenau) in den Dateinamen einbacken. Statt export.eml demnach export20170112103337.eml oder export28461876.eml oder so.

Gefunden habe ich aber nur Befehle für das Einbinden von weiteren Informationen aus der E-Mail, also z. B. oConverter.Convert FormatEML, "c:\test\test" & oItem.subject - was nach meinem Verständnis den Betreff mit in den Dateinamen packt.

Hast du zufällig die Syntax für eine Zufallszahl oder das Datum im Dateinamen parat? Mein Dank würde dir ewig nachschleichen.

Super, das hat geklappt. Vielen Dank!

Hallo alle,

bei einem Kunden stehe ich vor der Aufgabe, einzelne E-Mails (manuell) in ein Archivsystem zu übernehmen. Plugins gibt's natürlich nur für Outlook, daher muss es mit Tobit anders laufen.

Was funktioniert, ist eine Mail per drag'n'drop auf den Desktop zu ziehen, so eine .eml-Datei zu erstellen, und diese per Rechtsklick und "senden an..." ins Archivsystem zu übergeben. Das ist dem Kunden aber manuell zu umständlich, und nun sucht er nach einer vereinfachten Variante, am besten mittles eines simplen Rechtsklicks auf die Nachricht direkt im David und eine entsprechende Option.

Was mir mit Hausmitteln einfällt, ist eine Frickellösung per AutoIt: Mail im separaten Fenster öffnen, "Speichern unter..." -> *.eml, Datei speichern, Datei Rechtsklick, ans Arvchiv übergeben. Das klappt prinzipiell, nun müsste man nur noch den Aufruf des Scripts in das Kontextmenü der Nachrichtenliste im David-Client hineinbekommen. Ist das für Normalsterbliche möglich, oder muss man dazu eine eigene Lösung programmieren?

Hat alternativ jemand eine bessere Idee als oben beschrieben? So ganz glücklich bin ich mit der AutoIt-Variante nämlich nicht, da kann alles möglich schief gehen, wenn der Anwender während des Script-Ablaufs nicht "stillhält".

Ich habe ebenfalls noch einige Kunden mit alten Servern und XP-Clients. Aktuelles Rollout einspielen lief problemlos, Client-Installation auf 2003er Terminalserver ebenfalls. Von den XP-Clients habe ich keine negative Rückmeldung erhalten, gehe daher davon aus, dass die auch sauber updaten konnten.

Zitat von BlackShadow

Wenn der Download länger dauert, abbrechen, die Seite neu laden dann landet man auf einem anderen Download Server

Der Tipp war gut, danke! "download4" wäre vermutlich erst zu Weihnachten fertig geworden...

Zitat von David_1983

Also der Punkt "Verzeichnisse durchsuchen" bin ich mir noch nicht so sicher...ob ich den anhaken soll oder nicht.

Wie der gute Herr Füchter im Video sagt: Im Zweifelsfall bei "Verzeichnisse durchsuchen" den Haken rausnehmen!

Bei doppelten Ordner sollte in der Tat die archive.dir repariert werden. Aber nur diejenige des Verzeichnisses, in dem die falsch angezeigten Ordner liegen. Also:

SERVER
--Hauptordner 1
-----Ordner A
-----Ordner B
-----Ordner kaputt (zeigt z. B. auf das gleiche Dateisystem-Verzeichnis wie Ordner B)

Dann lässt du NUR im "Hauptordner 1" die archive.dir reparieren, in den Unterordnern tut das nicht Not. Bzw. gibt's da in diesem Beispiel gar keine.

Funktionen bei Arcutil kenne ich im Wesentlichen drei:

• archive.dir aufbauen/reparieren
• archive.dat aufbauen/reparieren
• Suchen und Ersetzen

Die ersten beiden sind nah verwandt. In der archive.dir ist die Verzeichnisstruktur eines Archives gespeichert. Wenn du z. B. den Fall hast, dass du ein Archive im Client aufklappst, und da erscheinen mehr (oder weniger) Ordner als auf Dateisystemebene, oder es gibt Archive, die auf einen gemeinsamen Pfad auf Dateisystem-Ebene zeigen, dann ist die Zuordnung defekt und muss repariert werden. Mit einem Haken bei "archive.dir herstellen" werden diese Zuordnungen neu aufgebaut. "Verzeichnisse durchsuchen" bezieht auch Unterverzeichnisse mit ein, denke ich.

In der archive.dat sind alle Einträge eines Archivs gelistet, auch hier kann es zu Unstimmigkeiten kommen. Kleines Problem dabei: Wenn du stumpf die archive.dat neu aufbauen lässt, können dabei mitunter Infomationen verloren gehen. Bei E-Mails hat man z. B. gerne mal eine Menge "ARCUTIL Recover"-Einträge, die plötzlich im Archiv liegen, aber der Betreff ist weg. Setzt du einen Haken bei "Von alter DAT herstellen", dann versucht das Tool, solche Informationen aus bestehenden DAT-Dateien zu retten. Auf diesem Wege werden nur die ehemals defekten Zuordnungen als "ARCUTIL Recover" markiert; jene Mails, die vorher korrekt indiziert waren, behalten ihre Eigenschaften.

Im Reiter "Suchen und Ersetzen" kannst du manuell Strings suchen und ersetzen lassen, das ist z. B. dann nützlich wenn man manuell Daten kopiert oder auch einen Serverumzug durchführt. In letzterem Fall lässt du den Text "ALTERSERVERNAME" einfach durch "NEUERSERVERNAME" ersetzen. Da David ein proprietäres Format verwendet, kommt man da mit anderen Tools nicht ran.

Die etwas archaische Methode von David, mit einzelnen Dateien zu arbeiten, hat an dieser Stelle den Vorteil, dass man leicht manuell Sicherheitskopien erstellen kann. Speichere einfach alles, was als Datei mit "archive" beginnt weg, und wenn bei Arcutil dann irgendwas schief geht, kannst du die Dateien einfach zurückschieben. Arbeiten sollte zu diesem Zeitpunkt natürlich niemand mit dem System, am besten den Dienst "Service Layer" in der Zeit anhalten.

Ein Video gibt's zu dem Thema auch, sehe ich gerade:

Zitat von nordtech

Disclaimer: Das ist eine Idee

OK, vermutlich ist es eine blöde. Ich hab' natürlich nicht bedacht, dass bei Adressen ja die Einträge teils direkt in der archive.dat, teils aber auch in den .0tx und .001-Dateien stehen. Arcutil kümmert sich aber afaik nur um *.dat und *.dir. Sofern das Ersetzen in der .dat also klappt, hast du anschließend evtl. ein inkonsistentes Archivsystem.

Also: Hör besser nicht auf mich!

Zitat von dreamar

Kann man die archive.dat bearbeiten und mit "suchen und ersetzen" die Adressen ändern?
Ich habe es mal versucht, aber wenn man dann speichert ist die Datei quasi zuerschossen.

Auf Binärebene geht das durchaus (also nicht mit Notepad & Co., sondern z. B. mit einem Hex-Editor). Habe ich testweise mal erfolgreich durchgeführt. Zu empfehlen ist dieses Vorgehen dennoch nicht: Nicht supportet, nicht vom Hersteller vorgesehen, Dateiformat afaik nicht öffentlich dokumentiert, und vor Allem könntest du die Datei auf eine Weise beschädigen, die auf den ersten Blick nicht erkanntbar ist -> zunächst funktioniert alles, aber nach einige Monaten kommen dann Folgefehler. Bei einem Produktivsystem daher: Nicht machen.

Was doch aber gehen müsste ist die "Suchen/Ersetzen"-Funktion in \David\Util\Windows\ARCUTIL\arcutil.exe - das Tool kennt das Dateiformat, und welcher String da durch welchen neuen Wert ersetzt wird, ist ihm glaube ich schnurz. Kopier die archive.dat einfach mal in ein eigens erstelltes Test-Archiv und lass über Arcutil in jenem Verzeichnis @alterkunde.xx durch @neuerkunde.xy ersetzen.

Disclaimer: Das ist eine Idee - ich hab' das selbst nicht ausprobiert. Alles ohne Gewähr! Testarchive verwenden! Sicherheitskopien nicht vergessen!

Lass mal die Datei archive.dir im Eingang prüfen bzw. mit ARCUTIL reparieren. Vorher sicherheitshalber Backup erstellen! ARCUTIL.EXE findest du im UTIL-Verzeichnis der David-Installation.

Schau mal im David Administrator: eMail -> Postman, hier Rechtsklick und "Konfigurieren...", dann Reiter "Weiterleiten".

Wenn die Option "Weiterleiten" aktiviert UND dein Server von außen erreichbar ist, dann nimmt David prinzipiell Nachrichten "von anderen" entgegen. In diesem Fall sollte KEIN Haken bei "Ohne Einschränkungen" gesetzt sein. Falls doch, raus damit.

Ist der Haken schon draußen, hat jemand vielleicht die Zugangsdaten erraten, die unter "Einschränkungen" -> "Parameter" definiert sind. Da empfiehlt es sich dann, ein neues komplexes Passwort zu vergeben.

Generell kommt es aber darauf an, wie der David überhaupt konfiguriert ist. Sofern Ihr beispielsweise über ein Provider-Konto per POP3/SMTP empfangt und sendet, müssen die entsprechenden Ports in Router/Firewall gar nicht weitergereicht werden, dann ist der Dvaid-Server nach außen hin quasi "unsichtbar".

Passt nicht so ganz zum Fehler, aber schau bitte sicherheitshalber auch mal nach, ob auf Dateisystem-Ebene im User-Verzeichnis ein Ordner "temp" existiert und dieser auch beschreibbar ist.

Jeder Ordner im David-Archivsystem entspricht einem Odner auf Ebene des Dateisystems. Für das was du vorhast, könnte man zum Beispiel wie folgt vorgehen:

• Du legst ein neues Archiv im David an (hierzu im Client die Navigator-Ansicht verwenden, Admin-Rechte brauchst du natürlich auch) und benennst dieses z. B. als "Gemeinsames Adressbuch".
• In den Eigenschaften des Archivs (Rechtsklick) stellst du nun bei "anzeigen als" den Wert "Adresse" ein.
• Nun geht's an die Rechte. Dazu wieder Rechtsklick, dann "erweiterte Eigenschaften", damit werden dir die Rechte auf Dateisystem-Ebene angezeigt. Die musst du nun so vergeben, dass alle Benutzer auf den Ordner zugreifen können. Sobald das gewährleistet ist, sehen sie ihn auch im David-Archivbaum.
• Damit die Benutzer sich nicht immer durch die Archivstruktur hangeln müssen, legst du ihnen am besten eine Verknüpfung auf das neue Archiv an, z. B. bei den Favoriten. Das geschieht lokal am Arbeitsplatz des jeweiligen Users.

Zitat von jens jensen

Ist das die Sache, dass lumnia windows phone keine selbst erstellten Zertifikate unterstützt?

Vermutlich. Bei iOS muss man eine entsprechende Nachfrage bestätigen, bei Android (je nach Version) ggf. vorher explizit auch selbsterstellte Zertifikate zulassen. Bei einem älteren Windows-Phone hatte ich mal exakt dieses Problem; eine Lösung konnten wir nicht finden. Außer natürlich, ein "echtes" beglaubigtes Zertifikat einzusetzen (schwierig, wenn der Kunde eine dynamische WAN-IP hat) oder auf Krücken wie den Webaccess via Browser zurückzugreifen.

barabas: Die Domain ist korrekt eingetragen, die Zustellung an sich funktioniert ja auch. Lediglich wird der Anhang in den Text "reingemischt".

caddo: Ja, hab' ich mir fast gedacht, wollte aber sicherheitshalber mal nachgefragt haben.

Danke an die Antworter; dann schicken wir einfach weiterhin über den Provider. Trotzdem komisch, das alles.

Hm. Hört sich eigentlich in der Tat nach einem Darstellungsproblem (Filter geprüft? Den kleinen Trichter in der Symbolleiste im David-Client?) bzw. einer defekten archive.dat an - zumal du die Mail ja über Direkteingabe des Dateinamens aufrufen kannst. Wenn das auch nach einem Tag noch klappt, hat sie sogar die nächtliche Bereinigung überlebt, und das heißt: Die Nachricht wohnt dort legitim, aber der Index (archive.dat) bekommt davon nichts mit.

Die archive.dat neu aufbauen bzw. reparieren kannst du prinzipiell mit der arcutil.exe im Util-Verzeichnis der David-Installation. Dabei kann aber so einiges schief gehen, ich pflichte daher Arno bei und empfehle, dass du dir hierfür einen David-erfahrenen Dienstleister suchst. Insbesondere, weil das Problem nach deiner Beschreibung ja offenbar in mehreren Eingangsarchiven auftritt, und da liegt dann der Verdacht nahe, dass irgendwas faul ist.

Wie schaut's denn zum Beispiel von Betriebssystemseite aus: Hast du mal ein chkdsk auf der David-Partition laufen lassen?

Hallo zusammen,

ein Kunde hat gerade eine Telefonanlage von Siemens bekommen, und deren integrierter AB soll aufgezeichnete Nachrichten per E-Mail versenden (mit angehängter WAV-Datei). Ich mache das hier im kleinen Büro mit meiner Fritzbox genauso, ist ja eigentlich kein Problem. Wenn wir aber für den Versand David intern nutzen wollen, dann kommt die Nachricht plötzlich mit diversen Header-Einträgen und (am schlimmsten) dem in base64 codierten WAV-Anhang im Mailbody an.

Kurios: Wenn wir die Anlage statt dessen so einstellen, dass sie über den Provider (hier: Strato) verschickt, dann sieht die Mail aus, wie sie soll. Die WAV-Datei erscheint ganz ordnungsgemäß als Anhang und kann direkt im David-Client abgespielt werden.

Großartige Konfiguration seitens der Anlage, was Codierung etc. angeht, gibt es nicht. Nur einen Haken zum "Anfügen der WAV-Datei".

Im Postman ist "Weiterleiten" aktiviert.

Habt ihr eine Idee, ob man diesbezüglich im David etwas drehen kann? Oder wo die Stelle ist, an der David offenbar nicht mehr korrekt zwischen Header/Anhang und Mailbody unterscheidet? Hat ggf. jemand die Konstellation Siemens+David mit diesem Feature am Laufen?

SMTP-Header usw. sind leer, da die Nachricht ja intern verarbeitet wurde. So sieht der Text aus, der als Mail im David ankommt (Kundenname unkenntlich gemacht):

X-DvISE-ForwardJob: Try count: 1, FirstTry: Wed, 16 Nov 2016 19:20:37 +0100
Received: from localhost [192.168.2.29] by [xxx].de with David.fx (xxxx.xxxxxxxxxxxxxxxxxxxx);
16 Nov 2016 18:20:36 UT
Date: Wed, 16 Nov 2016 19:19:22 +0000
From: 012345 <kundenname@[xxx].de>
To: kundenname@[xxx].de
Subject: Aufzeichnung empfangen =?iso-8859-1?Q?f=FC?=
=?iso-8859-1?Q?r?= Mailbox 25
Message-ID: <20161116192015.GA26722@ivm-4992>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Importance: Normal
User-Agent: Mutt/1.5.9i

--/9DWx/yDrRhgMJTb
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Es wurde eine Sprachnachricht f³r Mailbox 25 hinterlassen.

Die Sprachnachricht wurde von 012345 hinterlassen.

--
Diese Nachricht wurde automatisch generiert. Eine Antwort ist nicht m÷glich!

--/9DWx/yDrRhgMJTb
Content-Type: audio/x-wav
Content-Disposition: attachment; filename="15_05_20161116191922.wav"
Content-Transfer-Encoding: base64

UklGRsSuAABXQVZFZm10IBAAAAAGAAEAQB8AAEAfAAABAAgAZGF0YaCuAABUVFRUVFRVVVVV
VVVVVVXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dVU1dVUVFRUVFRVVVVV
VVVVVVXV1dXV1dXV1dXV1dXV1VTVVFVVVVVV1dXVVVVV1dXV1dXV1dXV1dVU1dXVVFRU1dXV
1dXV1dXV1dXVVFRUVFRUVVVVVVVVVVVV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dVU
VFRUVFRVVVVVVVVVVVXV1dXV1dXV1dXV1dXV1dXV1dXV1dXVVFRUVFRUVVVVVVVVVVVV1dXV
[usw.]