Posts by nordtech

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):

• Apps -> Standard-Apps -> E-Mail = Outlook
• Apps -> Standard-Apps -> Standardeinstellungen per App: Outlook hat alles
• DVSMAPI.EXE mit Parameter -U ausgeführt, um die David-MAPI zu deinstallieren -> David sagt "MAPI ist nicht installiert".
• Reparaturinstallation von O365, um Zuordnungen wiederherzustellen -> kein Effekt
• HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail "Standard" steht auf Outlook
• HKEY_LOCAL_MACHINE\Software\Classes\mailto steht auf Outlook
• David-Client deinstalliert -> klappt! Neunstallation benutzerdefiniert, "David als Standard-Mailclient" deaktiviert -> nach Installation wieder das gleiche Problem

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: mailboxDone

Hat 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:

• Bau dir eine Subdomain wie david.meinedomain.invalid (oder nimm deine unbenutzte Domain)
• Konfiguriere den AA-Eintrag der (Sub)Domain auf eure feste IP - mit AAAA (IPv6) habe ich das bislang nicht zum Laufen bekommen, sondern nur ganz "klassisch" mit IPv4. Bei der Verwendung von Let's Encrypt ggf. AAAA unkonfiguriert lassen, sonst schaut LE da bevorzugt und ist sauer, wenn der Server über IPv6 nicht erreicht werden kann.
• Router: Portfreigabe für Port 443 und 80 auf den David-Server, ggf. auch Firewall am Server beachten (wie gesagt, Port 80 kann entfallen, wenn Zertifikat selbst gekauft).
• Dienst Webbox starten und auf automatischen Start stellen.
• Webbox -> Konfiguration -> Domain eure (Sub-)Domain david.meinedomain.invalid eintragen

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.

Moin zusammen,

ein Kunde plant den Einsatz eines cloudbasierten Archivierungs-Systems. Das generiert E-Mails, an die PDFs abgehängt sind. Wunsch des Kunden ist, dass diese Anhänge vollautomatisch ausgedruckt werden - wohlgemerkt, die Anhänge, nicht die E-Mail.

Spontan habe ich dieses Tool gefunden: https://www.karley.eu/anhangexporter/ - damit kann man wohl automatisch die Anhänge in ein Verzeichnis speichern lassen. Die von dort aus per Script automatisch zu drucken wäre der nächste Schritt, dafür lässt sich aber garantiert eine Lösung finden. Das in einem älteren Thread erwähnte Tool von itacom scheint leider nicht mehr verkauft zu werden?

Frage: Standet ihr ggf. schon einmal vor einer ähnlichen Aufgabe und habt das vielleicht schneller/einfacher/eleganter gelöst?

Genau richtig, was du beschreibst. Im Postman das Sende-Konto (Smarthost) anpassen, im Grabbing Server die POP-Postfächer. Wenn sich die Domain nicht ändert, war's das dann im Grunde schon. Prüfe am besten auch, ob "Auszuwertendes Adressfeld" in den Grabbing-Server-Konten noch stimmt. Das heißt oft "X-Original-To", manche Provider benennen es aber auch anders, kannst du im Header einer Mail sehen, die über den neuen Provider zugestellt wird. Wenn ihr dort statt dessen mit "Zieladresse" arbeitet, sind keine Änderungen nötig.

Ich mache die Umstellung meistens zum Abend hin oder auch am Wochenende, wenn generell wenig Mailverkehr herrscht. Du kannst die POP3-Konten im Grabbing Server einfach parallel laufen lassen, also nicht umstellen, sondern neue hinzufügen. Die alten bleiben aktiv, bis eine Fehlermeldung aufläuft. Dann kannst du sie rauswerfen.

Sofern die Umstellung gerade mitten im Gange ist und jemand eine Mail schickt, bekommt der halt evtl. einen Bounce - nach meiner Erfahrung ist DNS heutzutage aber erheblich flinker als noch vor einigen Jahren, es dauert oft nur noch Minuten, bis sich die Änderungen durchgesprochen haben. Den MX würde ich daher nicht umbiegen, kann man aber natürlich machen.

Ergänzungsfrage: Wird auf den David-Server von extern zugegriffen? Dann denke auch daran, dass da ggf. eine Subdomain existiert, über die Clients den Server aus dem WAN finden. Die muss natürlich ebenfalls beim neuen Provider angelegt werden.