Ach Mist, lesen hilft!
SELF signed... Da ist mir kein Weg bekannt, von Haus aus unterstützt iOS in aktuellen Versionen nur "offizielle" Zertifikate - manuellen Import habe ich noch nicht gemacht. Der Königsweg ist aber eh: Entweder im Rahmen von Sitecare ein echtes Zertifikat über Let's Encrypt erstellen lassen ODER eines für schmales Geld kaufen. Kostet bei globessl und ähnlichen Kandidaten rund 10 Euro im Jahr.
Mag sein, dass ich dich komplett falsch verstehe, aber: Auf dem iPhone muss da nichts installiert werden.
Das iPhone kommt auf eurer David-Domain an, schaut nach, ob das übergebene Zertifikat gültig ist und zum Hostnamen passt, und ist dann glücklich. Das gilt für den Webaccess (Browser) genau so wie für die ActiveSync-Einrichtung.
Das wbcert.pem liegt warm und trocken auf eurem David-Server und sollte diesen lediglich in Form einer Datensicherung verlassen. 
Nein, nicht den Freigabebereich erweitern - du musst sicherstellen, dass der externe Port 80 (der MUSS für Let's Encrypt 80 sein) beim David ankommt. Wenn du vorher den IIS gesehen hast, ging extern 80 auf intern 80 und extern 81 auf intern 81, das nützt dir nichts.
Mach ein Forwarding von extern 80 auf intern 81, dann kannst du auch den IIS wieder einschalten.
Sobald Port 80 läuft (du musst von extern bei Aufruf eurer Seite mit http:// die Anmeldung von David bekommen, also Abfrage Username/Kennwort), trägst du bei der Zertifikatsanforderung eure korrekte Subdomain ein (david.deinedomain.invalid) - Zertifikate können nur für Hostnamen ausgestellt werden, nicht für IP-Adressen. Und der David muss über david.deinedomain.invalid:80 erreichbar sein. CNAME bitte wieder rauslöschen, den brauchst du bei einer festen IP nicht.
Nach Zertifikats-Bezug sollte die Webbox sich bei Neustart des Dienstes auch korrekt an Port 443 binden - gut möglich aber, dass da ebenfalls der IIS draufsitzt. Bekommst du eine Antwort, wenn du lokal https://127.0.0.1 aufrufst? Dann muss der Port noch "freigeräumt" werden. Sobald das Ganze durch ist, würde ich in der Webbox übrigens die Option "Port 80 nur für Let's Encrypt benutzen" anhaken, denn unverschlüsselte Verbindungen will man heute eh nicht mehr haben...
Viel Erfolg!
Bevor du ein Let's-Encrypt-Zertifikat anfordern kannst, muss deine Webbox auf Port 80 (von extern) korrekt antworten. "Falsches Modul" bedeutet, dass sich da ein anderes Programm vorgedrängelt hat, daher ist die Webbox lokal automatisch auf Port 81 ausgewichen. Ggf. ein anderer Webserver (IIS?) oder ein Systemdienst? Prüf mal mit "netstat -ano", welche PID sich den Port 80 geschnappt hat. Oft ist das "4", dann bezieht sich das auf was Windows-eigenes.
Am einfachsten ist im Router ein Port Forwarding von extern 80 auf intern 81 und Umstellen der Webbox fest auf Port 81 (in der webbox.ini).
Danke, werde ich bei nächster Gelegenheit mal probieren. Der Kunde hat den David-Client an den betroffenen Stationen nun aber schon deinstalliert. 
Moin zusammen,
wir haben (erstmalig!) bei einem Kunden auf 2 PCs das hier besprochene Phänomen beobachtet. Man will ein Dokument per Mail versenden, z. B. via Rechtsklick -> senden an -> E-Mail-Empfänger, und es öffnet sich David statt Outlook. David ist dort aber nur noch für Faxe zuständig, es soll eigentlich Outlook zum Zuge kommen.
Wir haben folgende Ecken kontrolliert (Windows 10 64bit):
Hat noch jemand eine Idee? Wir kennen es meistens nur anders herum, dass Outlook sich dauernd vordrängelt. Aber auf diesen PCs scheint David dominant zu sein. Bin für jeden Tipp dankbar.
Na, OK, es war schon die Ecke, die wir vermutet hatten. Nach Hinterlegung von "X-Envelope-To" in "Auszuwertendes Adressfeld" klappt es nun wie gewünscht.
Interessant: Eine Mail heute früh vom Kunden, die auch an eine weitere Adresse per CC ging, landete bei uns als Kopie im "Unverteilt". Das ist ja durchaus ein zu erwartendes Verhalten, wenn eingehende Mails an mehrere Adressaten gehen und David nicht weiß, wohin damit. Aber wie erwähnt: Bislang war "Auszuwertendes Adressfeld" bei uns leer, und es gab dennoch keine Dopplungen.
Warum David nun neuerdings 2 Mails aus einer macht, die an genau einen Adressaten ging, erschließt sich mir jedenfalls nicht wirklich. Aber immerhin vermutlich in der Praxis eher selten - bei den meisten Installationen düfte ja "Auszuwertendes Adressfeld" oder "Zieladresse" befüllt sein.
Moin,
reproduzierbar seit Installation des Rollouts 336 kommen Mail bei uns doppelt rein. Wir dachten zunächst, das wäre eine defekte .mldb im Grabbing Server, haben daher per Webaccess das Postfach geleert und die mldb gelöscht, aber neue Mails werden im David dennoch schlicht doppelt angezeigt. Zwei separate Einträge für dieselbe Nachricht (auch schon im Eingangsprotokoll im David-Admin).
Ist das bei euch auch so? Im Grabbing Server wurde ja was verändert bzgl. der Auswertung des Original-To-Headers. Der ist bei uns allerdings gar nicht konfiguriert.
David bedient sich an einem Catchall-Postfach bei Strato und lässt die Nachrichten dort 14 Tage lang liegen. Lief bisher problemlos.
Wenn ich das Log richtig deute, passiert das alles schon direkt im Grabbing Server:
:1: +OK User logged in, proceed. (196)
:1: STAT
:1: +OK 1 5160
:1: Open Messagelist file (\\server\david\apps\dvgrab\code\I008D347.mldb)
:1: LIST
:1: +OK 1 messages, listing follows:
:1: UIDL 1
:1: +OK 1 ea15f362f6b4c391b17a6d3c8238e494
:1: UIDL
:1: +OK 1 messages, listing follows:
:1: RETR 1
:1: +OK Message follows:
Open \\server\david\apps\dvgrab\in\88C9A98B
:1: QUIT
Open \\server\david\tld\port\extra\88C9A9AA.001
Open \\server\david\tld\port\extra\88C9A9AB.001
Open \\server\david\tld\port\extra\88C9A9AB.0tx
WriteMySR: filename=\\server\david\tld\port\extra\88C9A9AB, from=xxxxx.xxxxx@gmx.de, to=
WriteMySR: FName=\\server\david\tld\port\extra\88C9A9AB.rx Handle=808
WriteMySR: filename=\\server\david\tld\port\extra\88C9A9AA, from=xxxxx.xxxxx@gmx.de, to=
WriteMySR: FName=\\server\david\tld\port\extra\88C9A9AA.rx Handle=808
Conversion finished
:1: +OK Closing connection
:1: mailboxDoneHat das System da nicht schon aus einer Nachricht 2 Einträge generiert? 88C9A9AA und 88C9A9AB?
Leider keine Änderung bzgl. der zusammengeknautschten Favoriten-Icons.
Moin zusammen,
heute früh kam bei mir wieder die Meldung "Eine wichtige Komponente des david Client (WebView2) wurde aktualisiert..." Den damit verbundenen Neustart haben meine Einstellungen dieses Mal zum Glück überlebt.
Parallel Hilferuf eines Kunden: Auf dem Terminal Server lässt sich David zwar starten, dann kommt aber eine Fehlermeldung, dass Microsoft Edge (!) in einem bestimmten Verzeichnis keine Rechte habe. Im Client wurden daher keine Einträge angezeigt, Mails ließen sich nicht öffnen.
Lösung: In \users\username\appdata\roaming\tobit\ den Ordner WebView2 umbenennen und den Client neu starten. Gesucht wurde der Pfad \users\username\appdata\roaming\tobit\WebView2\{wildes Sonderzeichen}. Den gab's nicht. Etwas seltsam fand ich, dass der Client anschließend den Ordner WebView nicht neu angelegt hat... Aber laufen tut's.
Nur so flugs zur Info, falls jemand das gleiche Problem hat.
Das ist ja (soweit ich das mit meinen bescheidenen Kenntnissen beurteilen kann) eine JAVA-Bibliothek, betroffen sind wohl in erster Linie (aber natürlich nicht nur) Apache-Systeme. Insofern gehe ich davon aus, dass die Webbox nicht betroffen ist. Was unter der Haube alles im Smart Client steckt, weiß ich allerdings nicht.
Ich persönlich bin bei solchen Meldungen auch immer unsicher, zumal natürlich Kunden-Anfragen eintrudeln. Wie schon neulich bei den Exchange-Lücken.
Schön wär's, wenn Tobit dazu auf der Webseite ein kurzes Statement abgäbe. Wan wird ja noch träumen dürfen...
ag1 Beschreib bitte mal, ob das Phänomen generell auftritt oder nur bei Teams-Einladungen. Wenn letzteres, dann siehe was riawie geschrieben hat.
ABER: Ich hab' hier intern gerade festgestellt, dass ich auf unserem ollen 2012R2-Server (kein TS) das Problem nachvollziehen kann. Und zwar mit JEDEM Link, nicht nur bei Teams-Einladungen. Klickt man mit rechts auf einen Link, passiert einfach gar nix. Kein Kontextmenü, nichts. Mache ich das bei der gleichen Mail auf einem PC-Client, kommt brav das Kontextmenü incl. "Verknüpfung kopieren". Auf einem Testsystem mit Server 2019 war wiederum alles anders, da ging das auch.
Meine Vorschreiber haben davon unabhängig natürlich Recht: Teams ist ohnehin ein ganz eigenes Thema. Böse Zungen behaupten, Microsoft macht mal wieder alles anders/komisch, aber vermutlich sind die Nachrichten lediglich "Optimiert für Outlook[tm]". Oder so. Wir haben das Thema bei einem Kunden (etwas hemdsärmlig, wie auch von wlconsult angeregt) so gelöst, dass auf den Notebooks, mit denen der Kunde sich zum Terminal Server verbindet, ebenfalls der David-Client läuft. Da die Geräte nicht in der Domäne sind, per Direkt-Anmeldung, die VPN-Verbindung steht ja ohnehin. Der David-Client ist diesbezüglich zum Glück ziemlich gutmütig/flexibel und Lizenzprobleme gibt's auch keine.
Da wird wohl nur ein Blick in die Ereignisprotokolle helfen. Irgendwelche Abhänigkeiten noch nicht erfüllt? Versucht Windows, die Dienste zu starten, ehe DNS & Co. korrekt laufen? Was ist das denn für ein System - Member-Server in einer Domäne?
Wenn die Ursache nicht klar wird, würde ich einfach ein Script basteln und darin per NET START die Dienste manuell ankurbeln. Das dann per Aufgabenplanung 3 Minuten nach dem Booten anstoßen - so wird dir zumindest der Teil des manuellen Eingriffs abgenommen. Nicht schön, aber Windows Server ist halt manchmal launisch.
Konkret diesen Fall hatte ich persönlich übrigens noch nicht, aber beim letzten Reboot unseres eigenen David-Servers lief anschließend der SQL-Server nicht. Das haben wir damals gedanklich abgehakt, weil es eine ziemlich alte Kiste ist (mit Server 2012R2), alle David-eigenen Dienste waren gestartet.
Wenn's mit ActiveSync laufen soll, brauchst du die WebAPI nicht, nur die Webbox mit Port 443. Sowie Port 80 für den Bezug des Let's-Encrypt-Zertifikats. Ein selbst erstelltes Zertifikat wird von den meisten modernen Smartphones hier nicht mehr akzeptiert, du musst also entweder über LE automatisch beziehen (ist im Sitecare mit drin) oder ein Zertifikat zukaufen und manuell einspielen. Wenn du selbst kaufst, kann der Port 80 geschlossen bleiben.
Also:
In dieser Konfiguration solltest du per Webbrowser schon auf https://david.meinedomain.invalid draufkommen und einen Login-Prompt erhalten, wohl mit Zertifikats-Warnung. Wenn ja, sind damit prinzipiell die Voraussetzungen für den Exchange-Zugang erfüllt. Je nach Router musst du das ggf. "von außen" machen, also nicht aus dem zu erreichenden LAN, weil einige Modelle kein Hairpin NAT beherrschen. Mit z. B. einer Fritz!Box klappt das, mit Lancoms auch, mit manchen Telekom-Geräten nicht.
Im David-Client aktivierst du nun unter Einstellungen -> Zugang den Remotezugriff. Der User muss dazu das entsprechende Recht haben (zu vergeben im David-Admin).
Auf dem Smartphone hangelst du dich durch den Assi für ein neues Exchange-Konto, gehst aber so schnell wie möglich auf "manuell konfigurieren", da einige Dinge nicht automatisch erkannt werden. Mailadresse ist klar, Kennwort wie im David-Client vergeben. Beim Server mischt sich ggf. euer Provider ein, das überschreibst du mit david.meinedomain.invalid. Der Anmeldename ist wie im David-Client vergeben.
Anschließend konnte man früher[tm] die Warnung bzgl. eines selbst signierten Zertifikats wegklicken, wie gesagt, das geht bei den meisten aktuellen Systemen nicht mehr. Wenn also mit dem Zertifikat etwas nicht stimmt, hakt's dort. Mit LE ist das im David-Admin simpel: Abschnitt "TLS-Verschlüsselung" anklicken, "Neues Zertifikat anfordern", fertig.
Bei der Gelegenheit gleich im Admin Rechtsklick auf "TLS-Verschlüsselung" und die Kompatibilität auf "Modern" umstellen. TLS 1.0 und 1.1 braucht heute (fast) niemand mehr.
Gut, ich bin offenbar doch geistig verwirrt. Die Symbole in eine Zeile zu quetschen, gelingt auf dem zweiten PC ebenfalls. Dass das möglich ist, habe ich wohl irgendwann verpasst. Mein gedanklicher Stand war, dass "Neu, Bild und Formulare" immer in einer separaten Zeile stehen und da (unnötig) Platz verbraten.
Die Update-Meldung kam auf dem zweiten PC nicht. Kann aber sein, dass dies nicht explizit angezeigt wurde, sondern sich durch ohnehin erfolgten Neustart einfach so aktualisierte. Dagegen, dass die Rendering Engine unter der Haube immer mal wieder Updates unabhängig von Tobit erhält, ist ja im Prinzip nichts einzuwenden. Wobei es spannend werden könnte, wenn jemand kein Sitecare hat und die Installation viele Jahre laufen lässt.
Bleibt halt die Sache mit den zurückgesetzten Einstellungen und die neue Ansicht. Ich hoffe mal, das lag tatsächlich an der speziellen Konstellation mit Remote-Client. Am lokalen PC, der immer direkt am Server hängt, gab's keinerlei Probleme. Wenn bei allen (oder auch nur einigen) Kunden die eingestellten Vorlagen rausflögen, wäre das ein ziemlicher Support-GAU. Auf dem Notebook war nahezu alles verstellt, was man sich vorstellen kann: Von "Scrollbalken automatisch ausblenden", über eben die Vorlagen und Schriftarten bis hin zu den "klassichen Formatierungsoptionen" im Editor. Lediglich die Grundansicht (Vorschau unter den Nachrichten, Hintergrund grau) blieb unangetastet.
Also gut. Haken wir mal ab unter "IT-Schluckauf". Oder wie Fefe immer sagt: Softwareproblem. Kannste nix machen.
Nein, der Kunde hängt an einem ziemlich schmalen DSL, feste IP ist nicht vorhanden. Außerdem möchte ich da derzeit nicht so gern an Grundsätzlichem herumschrauben - der Versand erfolgt zum Beispiel über T-Online, während die Postfächer bei IONOS liegen. Da scheint einiges historisch gewachsen zu sein, das ich geistig noch nicht ganz durchdrungen habe.
Ja, ulkig. Ich kann das Phänomen auf meinem zweiten PC (ebenfalls Win10) nicht reproduzieren. Was habe ich denn da wohl bekommen? Ein Client-Update war's auch nicht, nur eine darunterliegende Komponente (ich MEINE "webkit", kann aber auch was anderes/ähnliches gewesen sein). Nach Neustart sind nun die abgrundeten Ecken weg, aber die schmale Symbolleiste ("Neu", "Bild", "Formulare" und der ganze Rest in einer Zeile) blieb:
Das ist eigentlich ganz charmant - bisschen mehr Platz auf dem Schirm. 
Ich sehe es doch richtig, dass das bislang nicht ging, oder? Also alle Symbole in einer Zeile? Oder habe ich jetzt einen Knoten im Hirn?
OK, danke für eure Antworten. Wir haben das jetzt komplett unabhängig von David gelöst, mit "Automatic EMail Manager" - der kann alles, was der Kunde wünscht, läuft als Dienst einfach vor sich hin unterstützt für das separate Postfach sogar IMAP-Push. Das ist natürlich angenehmer, als wenn der Kunde im schlimmsten Fall eine Minute vorm Drucker steht und wartet, dass der Grabbing Server die Mails abgeholt hat.
Direkt zum Drucker senden klappte leider nur holprig. Daher sein Wunsch nach einer serverbasierten Lösung.
Moin,
bei mir hat sich eben der David-Client gemeldet, dass ein Webkit-Update verfügbar sei und im Zuge dessen einen Neustart gemacht. Nun ist oben die Symbolleiste deutlich schmaler (angenehm), die Ecken sind abgerundet(?), aber es hat gleichzeitig sämtliche Einstellungen zerwürfelt: Vorlagen nicht mehr zugewiesen, Standard-Schrift weg, Animationen usw. wieder aktiv... Ich arbeite allerdings gerade Remote (nicht per VPN/RDP, sondern mit David-Direktzugriff) , könnte also evtl. auch damit zusammen hängen.
Auf dem Server ist davon nichts zu sehen, nur auf meinem Win10-Client. Habt ihr das auch bekommen? Und falls ja, sind bei euch die Einstellungen erhalten geblieben? Wenn nicht, befürchte ich nämlich demnächst einen Kunden-Ansturm... 
So, mal kurz Rückmeldung - wie's denn ab und zu so ist: Am Ende steht man wieder ganz am Anfang.
Wir haben letztlich herausgefunden, dass es vermutlich doch an der Sophos hängt. Aber anders, als zunächst vermutet. Ein lokal testweise installierter Thunderbird lief nämlich ebenfalls in Fehler, wenn POP über Port 995 (SSL) abgeholt wurde. Auf Port 110 (TLS/STARTTLS) funktioniert es sauber. Da Port 110 ja früher für die unverschlüsselte Kommunikation zuständig war, ist meine Vermutung, dass dafür eine passende Firewall-Regel besteht? Warum über Port 995 ab und zu trotzdem Mails geholt werden konnten, erschließt sich mir hingegen noch nicht ganz. Irgendeine Art von Timeout?
Auffällig war, dass Thunderbird beim Port 110 wegen eines Zertifkatsfehlers gemeckert hat. Durchaus nachvollziehbar, denn kontaktiert hat er pop.1und1.de, aber das Zertifikat kam vom Sophos-UTM, musste man also einmal manuell "abnicken". David scheint sich daran nicht zu stören.
Fest steht nun zumindest, dass David unschuldig ist, beim DNS klappt alles, der Grabbing Server ist gesund, es liegen auch keine temporären Dateien mehr in der Gegend. Insofern hätte ein Update auf die neuste Version einen Haufen Geld gekostet, das Problem aber nicht beseitigt. Was, wie angedeutet, von Anfang an mein Verdacht war. BlackShadow Magst du mir vielleicht doch deine Screenshots schicken? Ich darf leider weiterhin nicht selbst in die Konfiguration rein, aber vielleicht kann ich so ja die Kollegen dezent in die richtige Richtung schubsen.