Wie schaut es denn in der Registry aus? Bei mir gibt es nur einen einzigen Verweis auf die Datei, und zwar unter
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\SharedDLLs]
Ist der Eintrag dort noch vorhanden?
Ansonsten auch mal wie von Genesis vorgeschlagen die Autostarts durchsuchen, ich nehme dafür immer gern autoruns zur Hand: - wenn du diese Liste nach "tobit" filterst ist schnell ersichtlich, ob da noch Reste feststecken.
Eigentlich müsste das so passen. Der entsprechende Drucker ist im David Administrator definiert?
Ich bin nicht ganz sicher, ob der Druck beim manuellen Schieben von Einträgen auch gezogen wird. Was passiert, wenn du die Nachrichten per Verteilregel oder Direktzuordnung in das Archiv legen lässt?
Es genügt, den in Frage kommenden Usern im David-administrator das Recht zu entziehen, selbst Regeln anlegen und verändern zu dürfen.
Dann klappt aber die vom TE geforderte Möglichkeit für die einzelnen User, noch Abwesenheits-Autoreplys einzurichten nicht mehr. Oder sehe ich das falsch? Mit dem neuen Abwesenheits-Assistenten habe ich offen gesagt noch nicht experimentiert, aber beim Kunden sah es so aus als würde auch der nur "normale" Regeln erstellen. Oder funktioniert der Assistent ggf. unabhängig vom User-Recht, Regeln anzulegen? Das wäre ja mal was.
Ich fände das auch sehr schön/nützlich, aber da alle Regeln in einer einzigen Datei im jeweiligen Archiv abgelegt werden wird das wohl nicht funktionieren. Gäb's für jede Regel eine separate Datei könnte man mit Rechtevergabe auf Dateisystem-Ebene operieren.
Wenn es sich nicht um ein Rechte-Problem handelt würde ich auf eine defekte archive.dat tippen. Das habe ich auch schon bei div. Kunden ohne erkennbare äußere Einwirkung beobachtet, und eine elegante/automatische Möglichkeit, diese Datei auf Konsistenz zu prüfen gibt es leider nach wie vor nicht.
Dir bleibt da nur der Weg über arcutil.exe (im Windows-Utilities-Verzeichnis deiner David-Installation). Damit wird die archive.dat neu erstellt und auch im Filesystem vorhandenen Daten ein Eintrag im Archive-System zugewiesen, sofern dieser bisher nicht existierte. Problem dabei: Die neuen Einträge werden von dem Tool nicht ausgewertet, sondern erhalten den Namen "Arcutil recover". Manuell nacharbeiten wirst du also in jedem Fall müssen. Das Verfahren klappt aber nur, wenn meine Vermutung auch zutrifft: Dann liegen die vermissten Einträge noch im Windows-Dateisystem, der Eintrag in der archive.dat zeigt aber auf einen anderen/falschen Namen. Sofern dem David die Daten auf Dateisystemebene "entrissen" wurden (z. B. manuell gelöscht oder durch einen Trojaner verschlüsselt und ähnliche Späße) läuft der Neuaufbau der Indexdatei archive.dat natürlich ins Leere.
Sofern derartige Ursachen ausgeschlossen sind: Mach vor der Durchführung ein Backup des Archivs oder mindestens der momentanen archive.dat. Dann lässt du arctuil auf jenes Archiv los und wählst zunächst "Von alter archive.dat wiederherstellen", so werden dir zumindest die noch korrekten Einträge nicht überschrieben. Und dann Daumen drücken.
Ich wollte von der iOS-Mail App weg. Kennst du eine Mail App die das auch noch beherscht? Ich habe noch Cloud-Mail und MyMail probiert aus dem APPStore.
Leider auch keine Verbindung...
Nein, eine andere App ist mir spontan nicht bekannt. Aber Boxer sieht ja in der Tat ganz interessant aus, das schaue ich mir ggf. auch mal an.
Ich verwende zur Verbindung VPN und reine private IP-Adressen. Damit können dann die Amis nix anfangen...
Das Programm verbindet sich aber (anders als z. B. die Mail-App von Apple) nicht direkt mit deinem David-Server, sondern überträgt deine Login-Daten an den Acompli-Server. Benutzername und Kennwort. Deren Server holt dann die Daten und leitet sie an die App weiter. Das meinte ich mit "datenschutztechnischen Bedenken". Wenn du nur über ein VPN verbunden bist kann das natürlich auch die Ursache dafür sein, dass es nicht klappt...
Ergänzung: Hab's grad nochmal probiert. Du musst natürlich, sofern kein Autodiscover konfiguriert ist, manuell in den erweiterten Einstellungen den Servernamen und den Benutzernamen ergänzen. Standardmäßig fragt das Programm nur nach E-Mail-Adresse und Kennwort.
Also: E-Mail = Mailadresse des Users. Passwort = Passwort, wie im David-Client unter Einstellungen -> Zugang hinterlegt. Beschreibung = (beliebig). Server = Adresse, unter der dein Server im WAN erreichbar ist. Domäne = leer lassen. Benutzername = Name, wie im David-Client unter Einstellungen -> Zugang hinterlegt.
So sollte es dann passen, wenn ActiveSync grundsätzlich funktioniert (Remote-Nutzungsrecht für den User, Portweiterleitungen im Router etc.)
Ich hatte das gleich nach dem Erscheinen der App mal ausprobiert, und es lief problemlos. Für den Dauerbetrieb war mir dann aber die "Umleitung" über amerikanische Server datenschutztechnisch etwas zu heikel.
Moin,
sorry falls das hier schon Thema war, ich habe auf die Schnelle nichts gefunden. Vielleicht aber interessant für den ein oder anderen Leser. 
Auf meinem Experimentier-PC läuft seit einiger Zeit die RTM-Version von Windows 10, und obwohl ich eigentlich kein großer Freund der Heirat von Desktop und Smartphone bin habe ich mal ein bisschen mit den eingebauten Apps experimentiert. Erstaunlicherweise verlief die Kontaktaufnahme zu meinem David-Server darüber in der Tat fast so reibungslos wie auf einem Smartphone: Mail-App aufrufen, neues Konto anlegen. Ganz unten "erweitertes Setup" wählen (sonst kommt nur die Abfrage nach einer Mailadresse und die App versucht die Serverdaten mittels Autodiscover zu finden - klappt nur, wenn letzteres auf dem Server bzw. für die Domain konfiguriert ist). "Exchange ActiveSync" wählen, dann Mailadresse, Kennwort, Benutzername, öffentliche Serveradresse und einen Namen vergeben. Das Feld "Domäne" habe ich leer gelassen.
Wenn man den Haken bei "Server erfordert eine verschlüsselte Verbindung" gesetzt lässt beschwert sich das System im nächsten Schritt natürlich, sofern man ein selbsterstelltes Zertifikat benutzt. Das kann aber per Klick einfach akzeptiert werden.
Tja, wie soll ich sagen, es funktioniert anschließend tatsächlich so simpel wie auf iPhone & Co. - der Kalender füllt sich, die Kontakte ebenso, und in der Mail-App kann man auswählen, wie lange zurückliegend synchronisiert werden soll. Unterordner werden allerdings nicht direkt eingeblendet, sondern verbergen sich hinter dem Punkt "Mehr".
Offen gesagt war ich sehr angenehm überrascht. Ein Windows mit Bordmitteln an David anbinden zu können hat durchaus seinen Reiz. Oder ging das mit Windows 8.x auch schon? Wenn ja, dann bitte ich den unangebrachten Enthusiasmus zu entschuldigen - die Versionen 8.x habe ich wie seinerzeit auch Vista komplett ignoriert. 
Das ist mir bisher so nicht untergekommen, aber schau sicherheitshalber mal in die Eigenschaften des Windows-Users ("Active Directory-Benutzer und -Computer" bzw. wenn keine Domäne vorhanden auf dem lokalen PC), was dort im Benutzerkonto bei "Anzeigename" eingetragen ist.
Mal ins Blaue geschossen: Sind für diesen User im David Administrator unter "Versand" besondere Einstellungen zu finden? Zum Beispiel eine Include-Datei, die @@warten enthält oder so etwas? Ist bei "Rechte" das Recht "Externe eMails versenden" aktiv? Wie wird E-Mail bei euch generell versandt, über einen Smarthost (Postman)? Oder gibt es bei jenem Benutzer im Reiter "eMail Konten" Einträge?
Wenn's daran nicht liegt: Was passiert, wenn der User sich testweise mal an einem anderen PC anmeldet? Oder eine E-Mail über den Webaccess abschickt?
Sofern deine David-Installation aktuell ist stellt ActiveSync in der Tat das Mittel der Wahl dar. Andere Varianten (IMAP o. ä.) würde ich dann gar nicht mehr ausprobieren.
Verwendet wird, sofern nicht die (nicht mehr weiter entwickelte) David-App zum Einsatz kommt, in der Regel der Standard Mail-Client des iOS. Oder halt eine alternative App deiner Wahl - das im App Store erhältlich "Outlook für iOS" zum Beispiel verbindet sich ebenfalls per ActiveSync zu einem David-Server und ist somit eine nette Variante, wenn man z. B. geschäftliche und private E-Mails komplett trennen möchte. Dennoch ist Outlook an dieser Stelle mit Vorsicht zu genießen, da die App nicht direkt mit deinem Server kommuniziert, sondern die Daten erst über einen Dritt-Server geleitet werden. NSA hört mit und so. Einfach und (relativ) sicher ist daher eher der Einsatz der eingebauten Mail-App von Apple.
Die Sache mit dem "Von außen erreichbar" habe ich nicht ganz verstanden. Das ist für den Remote-Zugriff IMMER Voraussetzung, auch wenn du die alte David-App benutzt. Der David-Server muss über eine öffentliche IPv4-Adresse im Internet erreichbar sein. Im Router brauchst du ein entsprechendes Port Forwarding; in der Regel sind das heute Port 80 und/oder 81 für den Webaccess per Browser, Port 443 für ActiveSync und Port 267, sofern du direkt per Windows-Client von draußen draufkommen möchtest. Für ActiveSync alleine brauchst du nur Port 443. Dazu muss in der Webbox die Verwendung von TLS freigegeben werden und ein selbst signiertes Zertifikat hinterlegt sein. Ob der Server eine dynamische oder eine feste Adresse hat ist hingegen wurscht - dafür gibt es Dienste wie dyndns oder auch die "Server Location Services" von Tobit. Die übersetzen einen definierten Namen auf deine gerade gültige öffentliche IP-Adresse.
Möchtest du den Server hingegen nach außen wirklich komplett "dicht" machen und es kommt auf dem iPhone nur darauf an, Mails zu empfangen (kein Abgleich von Kontakten, Kalendern etc.), dann gibt's noch die Variante, beim Provider ein separates (in der Regel nach außen nicht bekanntes) Mailkonto einzurichten, das nicht von David, sondern nur von diesem iPhone abgeholt wird (max.muster-iphone@kundendomain.invalid oder so). In David legst du dann im Eingang des Users eine Verteilregel an, die alle Nachrichten in Kopie auf das iPhone-Konto schickt.
Also, ActiveSync ist meine Empfehlung. Schau aber bitte zuerst mal im David Administrator, welche Version du hast. Läuft Sitecare, also das Aktualisierungs-Abo von Tobit? Gerade bei ActiveSync wird im David immer noch relativ viel gebastelt und verbesser.
Ich habe aus Bequemlichkeit meist auch das Migration-Tool verwendet, u. a. deshalb, weil mir in der Praxis immer mal wieder Fälle unterkamen, in denen ich einige der archive.dirs und archive.dats nicht sauber mit dem neuen Servernamen betankt bekam (Fehlermeldungen im Arcutil).
Was mich bis heute an den Migration Services nervt ist, dass die User quasi grundsätzlich eine neue User-ID erhalten. In diesem Zusammenhang gibt es oft Probleme: Die Ordnerüberwachung des Notifiers klappt nicht mehr oder überwacht die falschen Ordner (lässt sich durch Löschen der dic.cfg beheben, aber Vorsicht, darin sind auch noch andere Sachen gespeichert). Auch dass Regeln plötzlich ins Leere zeigten kam schon vor. Und last not least scheint die Desktop Protection nicht mit dem neuen Server klar zu kommen: Auf den Clients kann man zwar einen neuen Signatur-Server hinterlegen, der wird aber oft einfach nicht gezogen. Es hilft nur ein Entfernen und neu installieren des Virenscanners.
Gut, nun mögen einige von euch sagen: Wenn solche Probleme auftauchen, dann stimmt vielleicht mit der Archivstruktur was nicht... 
Das kann gut sein, aber es gibt ja leider auch seitens Tobit kein Tool, das einfach nur die Konsistenz der Indexdateien prüft und dem armen Admin mal sagt, wo was hakt. Von daher ist die Sache zumindest bei umfangreichen Installationen mühsam.
Bis heute begreife ich nicht, warum die Migration Services nicht die User-IDs einfach identisch übernehmen. Damit hätten sich viele Probleme in der Folge schon erledigt.
Und die Desktop Protection... Naja, das scheint bei Tobit eh so eine Art ungeliebtes Kind zu sein. Glücklicherweise habe ich meine Kunden bald alle auf andere Lösungen umgestellt - ein bisschen schade eigentlich, denn die Lösung "E-Mail, Virenschutz und Spam-Filter aus einer Hand" hatte durchaus Stil.
OK. Sorry für den Rant, aber ich muss Ende des Jahres meinen größten Kunden mit 65 Usern und fast 300 GB David-Archiv auf einen neuen Server umstellen, bei dem Gedanken wird mir schon ganz blümerant.
Bietet David hierzu anderen Programmen Schnittstellen, die dieses erlauben?
Neben oben genannter Variante gibt es die Möglichkeit, mit einem Filescan-Service zu arbeiten. Den Versand erledigst du dann per @@-Befehl in einer kleinen Steuerungsdatei.
Aber eine Verbindung innerhalb des LAN ist möglich über den Mail Access Dienst zu praktisch beliebigen Clients.
Diese können auch einen älteren Stand haben als Outlook 2013.
Hm. Auf der Produktseite steht: "david® mail exchange™ ist ein vollstängiger SMTP-Mail Server für bis zu 5.000 Anwender. Er läuft unter Windows Server 2003, Windows Server 2008 (R2), Windows Server 2012, Windows XP (SP3), Windows Vista, Windows 7 und Windows 8. Mind. 2,2 GB Festplattenkapazität und Microsoft.NET Framework (ab 2.0) erforderlich. Über POP3, IMAP4, CalDAV, CardDAV und Exchange ActiveSync können beliebige Clients auf allen Plattformen eingesetzt werden."
Das liest sich für mich so, als könne das Produkt ältere Outlook-Versionen auch nur mit POP/IMAP "versorgen", oder? Interessant fände ich ja nach wie vor eine "echte" Outlook-Anbindung an David, also nicht über EAS, sondern über die normalen "alten" Outlook-Kanäle (incl. Kalender/Kontakte). Aber das wird Tobit vermutlich nicht lizenziert haben... Schade, denn mit der Aussage "Wenn Sie möchten können Sie Outlook behalten" könnte man sicher noch den ein oder anderen Kunden ködern. 
Moin Moin,
wir haben bei einem einzigen Kunden ein seltsames Phänomen, zu dem mich eure Kommentare interessieren würden.
Gegeben ist eine aktuelle (site care) David-Installation, die über einen externen Mailprovider E-Mails austauscht. Versand via SMTP, Empfang mit einem Catchall-Sammel-POP3. Rennt soweit auch alles.
Nun gibt es sporadisch (!) das Problem, dass ein Benutzer eine E-Mail versendet, diese aber mit einem anderen (quasi "generischen") Absender beim Empfänger ankommt. Neben dem David-Client wird auch aus einer Warenwirtschaft versandt, dort arbeiten wir mit Job-Befehlen (@@), die in der Regel einen PDF-Anhang zum Empfänger bringen. Meist passiert's dabei, kann aber auch Zufall sein. Im Ausgangsprotokoll David steht dann ganz brav "Von: kollege123@kundendomain.de, An: kollege789@empfaengerdomain.de". Der Empfänger bekommt die Nachricht auch, aber wenn er in seinem Mailprogramm z. B. auf "Antworten" klickt ist als Empfänger plötzlich "postfach_xyz@server7.mailprovider.com" angegeben. Schaut man sich die Mail dann an stellt man fest, dass die Nachricht tatsächlich mit jenem Absender zugestellt wurde. "Server7.mailprovider.com" ist dabei der Server des Mail-Providers, der Vorbau "postfach_xyz" sagt uns nichts. Es sind nicht oder zumindest nicht exakt die Daten, die im Postman bei "Über Provider senden -> Parameter" hinterlegt sind. Dort steht als Server "server7.mailprovider.com", als Anmeldename (Konto) aber "kundenname@kundendomain.de". Jene kundendomain.de wird allerdings vom gleichen Provider gehostet wie auch das E-Mailsystem.
So. Wie gesagt passiert das Ganze nur sporadisch. Da im Ausgangsprotokoll ja die korrekte Adresse hinterlegt ist gehen wir eigentlich davon aus, dass David dem Mailprovider ein korrektes FROM:-Feld übergeben hat. Das Phänomen ist uns bislang auch nur bei diesem einen Kunden mit diesem relativ speziellen Provider untergekommen. Wir können das Problem auch nicht manuell reproduzieren, es geht 100 Mal gut, und dann geht's plötzlich schief (OK, oder aber den anderen Empfängern ist es bislang schlichtweg nicht aufgefallen - in David sieht ja sowohl im Client als auch im Ausgangsprotokoll alles normal aus).
Nach unserem bisherigen Kenntnisstand sind wir geneigt, dem Kunden zu sagen: Da macht dein Mailprovider irgendwas falsch. Der scheint das FROM: nicht immer sauber zu übernehmen und ergänzt oder überschriebt das Feld dann mit dem Namen seines Server-Postfachs. Was sagt ihr dazu? Hatte jemand schon dieses Problem? Gibt es (außer einem kompletten Protokoll-Mitschnitt des Postmans und viel Glück) noch einen Weg, dem Phänomen auf die Spur zu kommen?
Bin gespannt auf eure Meinungen, denn mir sind die Ideen ausgegangen.
Macht es einen Unterschied, wenn du den Assistenten zur Portkonfiguration nicht aus dem David Administrator heraus startest, sondern aus dem Startmenü bzw. über den Explorer? \David\Install\setup.exe - ist die Datei vorhanden und geht's ihr gut? Bei einem aktuellen Sitecare-David sollte die Datei ca. 2 MB groß sein. Prüf ggf. mal die digitale Signatur um herauszufinden, ob die Datei verändert wurde.
Hi
ich habe folgendes Problem:
Ich habe bei einem unserer Kunden Tobit auf die neuste Version gebracht und wollte Activesync aktivieren. Leider bringt er trotz korrekter Funktion sowohl in der Webbox als auch per Activesync die Fehlermeldung: "Authentifikation falsch".
Hm, das ist seltsam. Was passiert denn, wenn du dich per Webaccess auf den Server verbinden willst, werden dort die Zugangsdaten angenommen? Also im LAN direkt per Browser auf (per Port 80)? Wenn das klappt auch mal auf probieren. Mit welchem mobilen OS willst du den ActiveSync-Abgleich einrichten? Hast du ein Zertifikat erstellt und in der Webbox eingebunden? AS kann nicht (wie die alte App) unverschlüsselt kommunizieren, dort ist soweit ich weiß immer Port 443 bzw. SSL Pflicht. Ein selbst erstelltes Zertifikat muss (je nach Mobil-OS) "abgenickt" werden.
Ei schau, es ist ja alles viel einfacher als man denken mag. Auf tiefschwarz.com kann man sich auch mit den vorhandenen Zugangsdaten aus club.tobit.com anmelden! Also erst auf "Kein Facebook" klicken und dann im ersten Feld keine E-Mail-Adresse eintragen (Das ist wichtig! Bei mir wurde die bereits seit Langem registrierte Mailadresse dort zwar akzeptiert, allerdings mit einem mir unbekannten Kennwort - und "Kennwort vergessen" o. ä. gibt's an der Stelle ja nicht), sondern einfach den Benutzernamen aus club.tobit.com. Schwupps ist man drin. Das war ja einfach. Und wenn das eigene Clubkonto bereits mit einem Partneraccount verknüpft ist darf man dann auch endlich den Newsletter lesen.
Inzwischen steht das da auch alles ("Wenn Sie über einen Tobit.NET-Account verfügen, können Sie sich auch mit diesen Zugangsdaten anmelden" bzw. "E-Mail-Adresse oder Benutzername" - entweder ist das neu, oder ich hab's zuvor im Eifer des Gefechtes überlesen. Nunja. Was so ein paar Tage Osterurlaub doch ausmachen können. 
