Super, das hat geklappt. Vielen Dank! ![]()
Beiträge von nordtech
-
-
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.
-
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... -
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:
Externer Inhalt www.youtube.comInhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt. -
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!

-
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.
-
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: 8bitEs 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: base64UklGRsSuAABXQVZFZm10IBAAAAAGAAEAQB8AAEAfAAABAAgAZGF0YaCuAABUVFRUVFRVVVVV
VVVVVVXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dVU1dVUVFRUVFRVVVVV
VVVVVVXV1dXV1dXV1dXV1dXV1VTVVFVVVVVV1dXVVVVV1dXV1dXV1dXV1dVU1dXVVFRU1dXV
1dXV1dXV1dXVVFRUVFRUVVVVVVVVVVVV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dVU
VFRUVFRVVVVVVVVVVVXV1dXV1dXV1dXV1dXV1dXV1dXV1dXVVFRUVFRUVVVVVVVVVVVV1dXV
[usw.] -
Klick im Eingangsbuch im David Administrator den Eintrag mal mit rechts an, dann kannst du in den Eigenschaften sehen, wo im Archivsystem er "gelandet" ist. Wenn er an der Stelle nicht auftaucht, wäre der nächste Schritt eine Prüfung von eventuell im Zielarchiv vorhandenen Verteilregeln. Schau auch mal auf Dateisystemebene nach, ob der Eintrag vorhanden ist. Wenn ja, gibt es ggf. ein Darstellungsproblem im David-Client (Filter?) oder es liegt eine defekte archive.dat vor.
-
Neeein, das Bild haben wir in den Eigenschaften schon auf rund 200x100 Pixel verkleinert
Schau mal das "aufgeblähte" Bild an, wenn es zurück kommt: Ist das total unscharf und pixelig? Wenn nein, dann liegt das Bild noch in Originalgröße vor. Es gibt natürlich die Möglichkeit, die Grafik in 3000x1500 Pixel an die Mail anzuhängen und dann per Editor einfach kleinzuziehen. Das verkleinert die Grafik aber nicht, sondern skaliert sie bloß. Oft gemachter Fehler, habe ich schon bei diversen Kunden gehabt, die Ihre Vorlagen selbst bauten. Auch manchmal auf Webseiten zu beobachten, wenn sich ein Bild verdächtig langsam aufbaut - schaut man dann mit Rechtsklick in die Eigenschaften, ist das angeblich 200x200 Pixel große Bild im Original plötzlich 5 MB groß.
Wenn im weiteren Mailverkehr dann irgendwo in den Zitatebenen der Skalierungs-Befehl "verrutscht", erscheint einem die Grafik in voller Pracht.
Also: Grafik in einem geeigneten Programm öffnen, das mit Pixelgrafiken umgehen kann (notfalls MS Paint), Größe ändern auf 200x100, Datei neu speichern und DIE dann in die Vorlage einbauen.
-
Ich denke mal, es geht hier eher um SMS-Versand. Ein Kunde von mir hat das neulich auch angefragt, allerdings hätte er gern eine Rückmeldung im David (!) darüber, ob der Empfänger die SMS erhalten hat - soweit ich das herausbekommen habe, ist das aber wohl nicht möglich. Oder weiß jemand mehr?
-
Nur mal so eingeworfen, als Bericht aus der Praxis (ausdrücklich NICHT als Empfehlung
: Wir haben einen Kunden, der die aktuelle David-Version incl. Sitecare noch auf einem 2003er-Server (x86) einsetzt. Die Installation ist dabei nicht winzig - knapp 70 User mit reichlich Daten. Es läuft soweit alles sauber und stabil. Ebenso läuft die aktuelle Version des David-Clients stabil unter WinXP sowie Terminal Server 2003. Bei letzterem funktioniert die unlängst eingeführte automatische Aktualisierung allerdings nicht.Ob auch eine Neuinstallation auf 2003 durchführbar ist, habe ich nicht ausprobiert. Wenn das Setup die Version des OS nicht abfragt und die Installation durchführt würde ich mal darauf tippen, dass es klappt. Potentiellen Ärger kann man sich mit einer nicht mehr unterstützten Systemumgebung natürlich trotzdem einhandeln, zum Beispiel im Bereich SQL-Server. In deinem (RobDust) Fall wäre das ja aber eh nur eine Übergangslösung, oder? Probier doch einfach mal aus, ob das Update bzw. die "Drüber-Installation" einer aktuellen Version läuft (Datensicherung nicht vergessen!).
Wenn sich die Server in der gleichen Domain befinden spricht aber auch nichts gegen den Einsatz der erwähnten "Migration Services". Der Umzug selbst ist eigentlich vergleichsweise trivial, nur das Umschieben der Daten dauert eben ein wenig.