Beiträge von nordtech

    Der Ordnertyp bei "Anzeigen als" muss auf "Eingang" stehen (nicht auf "Vorgabe" o. ä., siehe Thread vor ein paar Tagen). Außerdem werden soweit ich weiss nur an den Archiven die Zahlen eingeblendet, die vom David Notifier überwacht werden. Unten rechts Rechtsklick auf das David-Symbol -> Konfiguration -> Reiter "Ordner", dort das betreffende Archiv hinzufügen.

    OK, hab's gerade mal mit O365 probiert, müsste ja identisch sein mit 2019 - in der Tat würgt einen der Assistent immer ab, obwohl man "Konto manuell einrichten" aktiviert. Mit falscher Domain geht's gar nicht erst weiter.

    Vielleicht hilft dir das hier: https://docs.microsoft.com/en-…2010/cc511507(v=office.14) - im Abschnitt "Using Autodiscover locally" ist beschrieben, dass man per Registry-Eingriff dem Client lokal eine XML-Datei unterjubeln kann.

    Über die Systemsteuerung zu gehen wird nichts bringen, da landet man spätestens bei "Konto hinzufügen" wieder bei dem selben dusseligen Assistenten.

    Ich hatte OL 2019 noch nicht in den Fingern, aber ein Versuch wäre es, absichtlich eine falsche Domain einzugeben (test@kunde.invalid), damit Autodiscover nichts findet. Oft kommt dann anschließend eine Oberfläche, in der man alles manuell eintragen kann. Da dann natürlich nicht vergessen, auch die Mailadresse wieder zu korrigieren. ;)


    Interessant fände ich es aber auch, Autodiscover korrekt zu konfigurieren. Praktisch bei Unternehmen, die oft neue Mitarbeiter haben, deren Schlaufones per EAS angebunden werden. Wenn der Mailversand über einen Provider läuft, scheint es dafür aber leider keine Lösung zu geben.

    Mit dem AV-Dienst für die Clients ("Desktop Protection for david") habe ich mich lange nicht beschäftigt, vor einigen Jahren war das "unter der Haube" ein zugekauftes McAfee. Allerdings vermissten wir stark eine Verwaltungsoberfläche, in der man weitere Einstellungen vornehmen kann. Außerdem ist die Lösung nicht unbedingt günstig, daher haben inzwischen alle Kunden eine separate Software am Laufen.

    Aktiv ist jedoch bei einigen (und bei uns hausintern auch) die serverseitige Prüfung ("Virus Protection"), die findet tatsächlich ab und zu was und sorgt dann dafür, dass die gefährlichen Anhänge gar nicht erst beim Empfänger ankommen. In Kombination mit einem anderen Scanner auf den Client-PCs hat man so eine gewisse Mehr-Sicherheit.

    Was wirklich sehr gut funktioniert, ist der David-eigene SPAM-Schutz ("Identification services") - jenen gibt es auch als Paket in Form der "David Premium Protection", worin u. a. SPAM-Schutz und serverseitiger Virenschutz enthalten sind. Je nach Anwendungsszenario ggf. preislich interessant.

    Ich würde auch erwägen, das einen Dienstleister machen zu lassen - das Hantieren mit archive.dat & Co. ist nicht immer ganz einfach, und man macht schnell was kaputt. Aber wenn du es selbst probieren möchtest: https://club.tobit.com/login/f…p?ArticleID=9957&lang=ger


    Alternativ mach eine Strongbox-Sicherung (ging das bei 10 schon?), dann geht's u. U. noch einfacher. Kommt auch ein bisschen auf die Datenmenge an.


    Willst du nicht nur die Archive, sondern auch Einstellungen und Konfiguration übernehmen, dann sei das Migrations-Tool von Tobit empfohlen. Das haben aber, wenn ich es korrekt weiß, nur autorisierte Fachhändler.

    Moin!


    Exchange lokal würde ich (für ein kleines Unternehmen) ebenfalls nicht anraten. Da gibt's heute bessere Varianten - entweder als gehostetete Lösung oder halt in Form von Office 365. Muss man aber auch mögen.


    Als "unausgereift" möchte ich David eigentlich nicht beschreiben. Es gibt einige Punkte, die anders sind als z. B. bei Exchange, dafür ist (imho) die Verwaltbarkeit aus Admin-Sicht ziemlich gut/simpel. Das Gemecker hier im Forum bezieht sich auch oft gar nicht so sehr auf das Produkt als vielmehr auf den Hersteller. Leider nicht immer ganz unbegründet.


    Unterm Strich läuft David aber recht unauffällig und störungsarm. Daher sind von meinen Kunden bislang nur sehr wenige umgestiegen. Die meisten haben statt dessen Sitecare abgeschlossen und halten die Software so auf aktuellem Stand. Kerio habe ich mir mal angesehen, aber der Leidensdruck ist nicht so groß, dass wir das als Alternative im Vertrieb konkret aufgenommen hätten.


    Übrigens:


    David Zehn kann ja sowieso nicht geupdated werden und alles neu gemacht werden


    ...stimmt so nicht. Die Archiv-Struktur hat sich seit langer Zeit nicht wesentlich geändert, die wird man (etwas Wissen vorausgsetzt) 1:1 übernehmen können. Eventuell ist sogar eine Migration mit dem von Tobit bereitgestellten Tool möglich, aber wenn du schreibst, dass es serverseitige Probleme bei der Mailverarbeitung gibt, ist es vielleicht auch nicht dumm, einmal einen sauberen Schnitt zu machen. Die User-Archive lassen sich aber auch manuell umkopieren.

    Viel hängt auch vom Anbieter ab. Ich hatte hier einen Kunden, der ebenfalls vom "Disconnect during fax transfer (remote abort)" geplagt war, interessanterweise nur bei ausgehenden Faxen. MAX9600 hatten wir ausprobiert, die Karte (diva.fx) war einwandfrei und hatte vor Allem vor der IP-Umstellung nie Probleme gemacht.

    Geholfen hat uns letztlich der lokale Elektriker mit gutem Draht zur Telekom: Der stimmte mit denen ab, in der Vemittlungsstelle (?) etwas umzukonfigurieren, und seitdem läuft das Faxen vollkommen problemlos. Ohne, dass wir am David-Server irgendwas geändert hätten.

    Ich weiß leider nicht mehr genau, worum es sich seinerzeit gedreht hat, aber Telekom-seitig gibt es entweder 2 Versionen von Hardware oder aber 2 Software-Konfigurationen, von denen eine gut und eine nicht so toll läuft. Vielleicht einfach mal da anfragen.

    Das ist glaube ich in der Form nicht vorgesehen. Behelf: Auf Dateisystem-Ebene liegen die konfigurierten Regeln in der archive.urt. Also: Erstelle für einen Benutzer (der ansonsten keine Verteilregeln hat) die passende Regel mit einem Textbaustein, der aus einem allgemein zugänglichen Archiv gezogen wird und kopiere anschließend die archive.urt aus seinem Eingang in alle anderen User-Eingänge. Aber Achtung: Das klappt nur, wenn auch die anderen Benutzer bisher KEINE eigenen Verteilregeln konfiguriert haben. Sonst überschreibst du mit diesem Vorgehen die bisherigen Regeln.

    Ist immer noch umständlich, aber besser als sich immer wieder durch den Regel-Assistenten zu klicken. Wer eine bessere/einfacherer Lösung für das Problem weiß: Daran wäre ich ebenfalls interessiert.

    Die ganze Zeit Shift halten muss aber nicht sein.

    • Nicht-leeren Ordner anklicken und löschen (bzw. das versuchen)
    • Evtl. Abfrage "wirklich löschen?" bestätigen
    • Fehlermeldung "kann nicht löschen, Ordner nicht leer" abwarten
    • Diesen Dialog mit Shift+Enter bestätigen (Shift + Maus geht sicherlich auch)
    • Ordner samt Inhalt ist weg

    Ist es möglich als Reseller im TPN zu sehen welche Kunden Sidecare haben?

    Im alten TPN unter https://tpn.tobit.com kannst du nach Anmeldung auf Kunden -> Kundenübersicht gehen. In der Spalte "Hinweis" ist "sitecare(TM)" eingetragen, wenn jener Kunde bislang kein Sitecare aktiviert hat.


    Darüber hinaus sind mir aber für Fachhändler keine Möglichkeiten zur Verwaltung bekannt. im neuen TSPN ( https://de.tspn.tobit.software ) fehlt die oben erwähnte Spalte. Da bleibt dann wirklich nur die Anmeldung mit der jeweiligen Site-ID.

    OK, jetzte... Ich kann das Verhalten nach dem Einfügen reproduzieren, nachdem CreateJobDebugFile = TRUE in der david.ini eingefügt wurde. Erstellt man dann eine neue Nachricht, ändert dort manuell den Absender und speichert anschließend über Datei - Erstellen - Persönliche Vorlage, so erhält man neben den normalen üblichen Verdächtigen (.0tx, .$00, .001) auch eine Debug-Datei .deb. Darin ist dann via @@FROM falsche@mailadresse.de@@ eingetragen.


    Ich glaube aber nicht, dass das alleine ein Bug ist - dass David in diesem Fall die abweichende Absenderadresse irgendwie in den Job einbauen muss, ist ja klar. Das zeigt sich in der dab-Datei, was erstmal nicht weiter schlimm wäre (die gibt es ja normalerweise nicht, bzw. wird da nichts rausgezogen, sondern sie protokolliert nur, was David so treibt und welche Befehle er verarbeitet).


    Relevant in diesem Zusammenhang: Bei mir taucht in obigem Versuch der @@-Befehl in der deb-Datei auf (was OK ist, ich habe den Absender ja umgestellt), aber in den anderen Dateien eben nicht! Dementsprechend findet sich bei mir auch in der Vorlage(!) keinerlei @@-Befehl.


    Nochmal ganz deutlich: Deine Aussage

    die Vorlage (*.deb-Datei) lässt sich hervorragend mit jedem Editor betrachten

    ist so nicht korret. Die *.deb-Datei ist NICHT die Vorlage, sondern ein Mittschnitt der Kommunikation im David, der durch den ini-Eintrag angelegt wurde. Damit, dass der Eintrag dort auftaucht, ist noch nicht geklärt, woher er gezogen wurde.


    Sofern der @@-Eintrag auch in Vorlagen (.001 plain text oder .0tx HTML) vorkommt, ist er da irgendwie anders herein geraten.

    Naja *89* Euro (elektronisch, die CD-Version braucht man bei einer exe-Größe von knapp 400 kb nicht wirklich), und das auch noch brutto... Ich denke, solche Kosten verschwimmen bei einer Server-Umrüstung in den Beträgen für die Dienstleistung locker. ;)


    In meinem konkreten Fall ist es dann auch noch so, dass die Kunden wie erwähnt eh alle eine eigene Version für die tägliche Datensicherung besitzen und natürlich ordnungsgemäß lizenziert haben. Von daher kein Problem.


    Ich möchte hier auch keine anderen Produkte aus dem Segment schlecht reden (außer vielleicht Acronis TI in der Server-Variante, das habe ich echt gefressen), natürlich gibt es eine Reihe von Tools, die ebenfalls gute Arbeit leisten. Mich persönlich hat Drive Snapshot seinerzeit nur ziemlich "geflasht" wegen seiner Winzigkeit und der Option, es überall komplett ohne Installation einsetzen zu können. Daher empfehle ich es immer gern weiter. Aber wie gesagt, es gibt viele andere Tool in der Richtung (viele davon kenne ich vermutlich gar nicht), und die haben selbstverständlich auch spezifische Vorteile und ihre Existenzberechtigung.

    Port 443 in der Firewall des Servers auch freigegeben? Und wird dein Zertifikat gezogen bzw. hast du eines erstellt ? Schau mal im David-Client unter Servername -> System -> David -> Ereignisse, ob die Webbox beim Neustart des Dienstes Meldungen auswirft. Wenn z. B. kein Zertifikat gefunden wird, bindet sich die Webbox auch nicht an Port 443 (https).

    schau Dir mal Drivesnapshot an (http://www.drivesnapshot.de)

    Dem möchte ich mich mal anschließen. Irgendwie scheint kaum jemand dieses Tool zu kennen, obwohl es vieles viel besser macht als die aufgeblähten Kollegen von Acronis & Co. Ich liebe DS und setze es bei fast allen Kunden und auch intern zur Datensicherung ein.


    (Ja ich weiß, klingt nach Werbung, ist aber verdient. DS spielt für mich in einer Liga mit z. B. den Tools von Sysinternals oder Nirsorft. Klein, fein, super-praktisch).

    Ich hatte das Thema auch schon mal, es ist in der Tat so, dass die Regeln nicht "von oben nach unten" abgearbeitet werden, sondern gewissermaßen gleichberechtigt nebeneinander stehen. Auch werden Nachrichten nicht sofort verschoben, wenn dies per Verteilregel angestoßen wird, sondern sie bleiben so lange im Quellverzeichnis liegen, bis alle (anderen) Regeln gegen die Nachricht ausgeführt wurden.


    Ich wollte seinerzeit etwas ähnliches wie CCNST durchführen: Eingehende Nachrichten anhand bestehender Kriterien in Unterordner verschieben und dann die übrig gebliebenen weiterleiten. Klappte aber nicht - es wurden statt dessen alle Nachrichten weitergleitet, auch die, die den Verschiebe-Kriterien entsprachen. Tobit erklärte mir dann, dass dies der oben geschilderten Arbeitsweise der Verteilregeln geschuldet ist.

    Ah, jetze. Nicht im Kontextmenü, sondern in Eigenschaften -> Optionen. Gut, das ist dann ja eine allgemeine Option generell für Archives - ich dachte schon, dass ich eine (neue) Funktion gezielt zum Ausblenden von Usern übersehen hätte.


    Aber dass man auf diese Weise auch User intern "unsichtbar" machen kann, wusste ich in der Tat noch nicht. Wieder was gelernt. :)