Beiträge von nordtech

Zitat von NSchuder

Im Postman ist eingetragen, dass er die Zugangsdaten vom Grabbing Server nehmen soll

Stell das mal testweise um auf z. B. "SMTP (AUTH=LOGIN)". Bei Benutzername und Kennwort nimmst du ein passendes Konto, z. B. info@{euredomain}. Auf diese Weise versendet ihr per Smarthost, das ist bei kleineren Umgebungen eine gängige Methode, und die meisten Provider unterstützen dieses Verfahren (ein authentifizierter User aus der gleichen Domäne und/oder dem gleichen Hosting-Paket bringt Mails mit abweichendem Absender auf den Weg).

Ich meinte eher, ob evtl. nur bestimmte OS-Plattformen betroffen sind - kann diese Frage aber gleich wieder zurückziehen, da bei uns nun auch mehrere andere Systeme mit 2019 oder auch Windows 10 Ärger machen. Bei vielen kleineren Installationen haben die User das bisher lediglich nicht bemerkt.

"Fein raus" sind momentan offenbar nur die Unternehmen, die noch einen Server 2012R2 am Laufen haben...

Habt ihr bei diesem Problem eine Regelmäßigkeit erkennen können? Ich wundere mich nämlich gerade, dass es bei nur einem einzigen unserer Kunden aufgetreten ist, bei allen anderen nicht. Obwohl die Systemkonstellationen stets ziemlich ähnlich sind.

Konkret betroffen war ein System mit Server 2016 Standard. Mehrere andere 2016er aber blieben ruhig, bei Kunden mit 2019 (zum Glück, nicht dass ich mich beschweren würde) war auch nichts.

Zitat von NSchuder

Können wir nun einfach die Datensicherung vom Ordner \David inkl. Unterordner zurück ziehen und anschließend evtl. mit einem Tool die Servernamen migrieren? Falls ja, wo bekommen wir dieses Tool?

Ja. Ihr könnt im Prinzip gemäß dieses Artikels vorgehen. Das Tool zum Anpassen der Indexdateien liegt in \david\util\windows\arcutil

Es seit darauf hingewiesen, dass es bei einem manuellen Umzug mit Änderung des Servernamens etliche Haken und Ösen gibt - da du aber von lediglich drei Benutzern schreibst, wäre es einen Versuch wert. Die alte Installation bzw. deren Daten bleiben ja quasi als "Backup" unverändert, falls doch etwas schief geht.

Oh Mann, ich hab's ja gewusst, es ist nur eine blöde Kleinigkeit. Danke, QWERTZ, dein Hinweis hat mich weiter gebracht, obwohl ich schon mehrfach ins Log geschaut hatte und die Anzeige nicht deuten konnte (die Zeile "SMTP Listener Active" erschien einfach nicht).

Lösung: In den Eigenschaften des Ports stand der Betriebsmodus auf "Nur senden". Hand aufs Hirn.

Moin zusammen, ich stehe hier vor einem Problem, bei dem ich FAST davon ausgehe, dass es eine Kleinigkeit ist. Aber momentan habe ich einen Knoten im Hirn.

Gegeben ist eine kleine (2 User) ganz frische David-Installation (neustes Rollout) auf einem Windows 10 Pro. Empfang via POP3, Versenden per Provider, klappt im Prinzip alles. Nun wollte ich lediglich noch das RAID-System so konfigurieren, dass es im Fehlerfall eine Mail intern via David an die User schickt. Und scheitere damit, denn auf Port 25 "hebt niemand ab".

Natürlich habe ich die Firewall geprüft, da sind sowohl die postman.exe als auch der Port 25 explizit im aktuellen Netzwerkprofil ausgenommen. Aber: Wenn ich per "netstat -ano" schaue, welche Ports belegt sind, fehlt da nicht nur die 25, sondern die PID der postman.exe taucht überhaupt nicht auf... Also scheint der Dienst keinerlei Ports intern zu öffnen - hä? Auch wenn ich den Port in der postman.ini testweise auf 1025 ändere, passiert nichts.

Die Konfiguration des Postman ist, nach allem was ich sehen kann, Standard. SMTP-Hostname ist die Kundendomäne (dort die lokale IP eintragen ändert aber auch nichts). DNS-Server ist korrekt, und darüber hinaus habe ich lediglich im Reiter "Provider" die Daten eingestellt, um externe Mails auf den Weg zu bringen. Ebenfalls keine Auswirkungen zu haben scheint die Funktion "Weiterleiten" - selbst wenn ich die testweise ohne Einschränkungen aktiviere, lauscht der Postman nicht.

Hat jemand eine Idee? Bei allen anderen Kunden klappt das problemlos, und ich bekomme z. B. per "telnet 127.0.0.1 25" sofort eine Antwort. Einziger Unterschied scheint mir im Moment, dass dies der einzige Win10-PC ist, den ich als "Server" am Start habe. Aber das sollte doch eigentlich passen, oder?

Ja, das ist glaube ich normal. Autoreply funktioniert ja bei beliebigen Ziel-Archiven, daher ist der Ausgang nicht immer eindeutig einem User zuzuordnen.

Leg doch einfach eine Regel im Ausgang des David System Users an: Wenn Absender = {useradresse}, dann verschiebe Original in {User-Ausgang}. Mache ich z. B. auch, wenn etwa aus einer Fibu/Warenwirtschaft über Postman-Weiterleitungen Mails versandt werden.

Zitat von dr_dee

Kann man da Prioritäten zuweisen

Nein, das ist so nicht vorgesehen und "by design". Auf diese Weise soll sichergestellt werden, dass z. B. eine Regel, die die betreffende Nachricht verschiebt, nicht andere Regeln daran hindert, ebenfalls gezogen zu werden. Die Sortierung ist dabei unerheblich und nur optisch relevant.

Das war vor einiger Zeit mal Thema hier, und wenn ich es korrekt erinnere, wollte Tobit die "Anregung aufnehmen", dass eine verbindliche Reihenfolge eingeführt wird - aber soweit ich es weiß, ist das bislang nicht passiert.

Welche Serveradresse ist auf dem iPhone hinterlegt? Ggf. grätscht euer Router im internen Netz dazwischen, wenn er merkt, dass die externe Adresse sich auf ihn selbst bezieht. In diesem Fall kannst du den Hostnamen im lokalen DNS manuell hinterlegen und an die korrekte Stelle (Port 443 David-Server) leiten.

Und nur zur Klärung: Nutzt ihr wirklich die (alte und nicht mehr gepflegte) APP oder ist David als ActiveSync-Konto eingebunden?

Dass Einträge in obigem Szenario verschwinden, habe ich allerdings noch nicht beobachtet - sofern der Server nicht korrekt angesprochen werden kann, sollten die Daten auf dem Endgerät einfach verbleiben.

Ich denke, da sollten wir erst einmal abwarten. Aus der Ankündigung "ergänzt die bestehenden nativen Clients und Standard-Schnittstellen von david3" kann ich jedenfalls nicht ersehen, dass irgendwer plant, den Zugang via EAS abzuschaffen.

Und was Outlook angeht: In meinen Ohren klingt die Sache eher nach einem (endlich!) grundsanierten Web-Access, so wie es ihn bei Exchange ja auch gibt - also komplett online, im Browser. Für die Bahnreise hingegen besteht doch bereits jetzt die Möglichkeit, ein aktuelles Outlook/Windows Mail über EAS anzubinden. Das wird vielleicht nicht offiziell von Tobit unterstützt, funktioniert aber nach meiner Erfahrung ziemlich gut.

Ich kann's mir zwar logisch auch noch nicht ganz erklären, aber ziemlich genau am 13.11. habe ich mit einem Kunden telefoniert, der mit seinem Outlook 2010 unter WinXP (!) nicht mehr an seine Strato-Mails kam. Senden klappte, nur Empfang via IMAP oder POP nicht. Ein testweise installierter Thunderbird auf dem XP-Rechner funktionierte. Ein frisch auf Windows 10 eingerichtetes Outlook 2010 funktionierte ebenfalls! Aber auf seinem ollen XP haben wir es partout nicht wieder zum Laufen bekommen. Sieht also tatsächlich so aus, als hätte der OS-Unterbau irgendeinen Einfluss - keine Ahnung, wie und warum.

Andererseits betreibt ein anderer Kunde einen aktuellen David.3 unter Server 2008R2, da gibt es keine Probleme. Alles bisserl seltsam.

Moin! Mal eine Frage an die DNS-Spezis: Ich habe einen kleinen Kunden, der an einem Telekom-DSL mit Fritz!Box hängt. Standard-Tarif, also keine feste externe IPv4. Der möchte mit seinem David den ActiveSync-Zugriff nutzen und dies via Let's-Encrypt-Zertifikat abwickeln.

Der Domain-Provider ist 1&1, da gibt es leider keinen dynamischen Host wie bei Strato. Also habe ich eine Subdomain david.{kundendomain} angelegt, dort alle DNS-Einträge entfernt und nur einen CNAME-Eintrag mit Verweis auf den dyndns.org-Hostnamen des Kunden gelegt, der über die Fritz!Box aktuell gehalten wird. Im Prinzip klappt das auch alles.

Problem: An der Box ist IPv6 aktiv, und dyndns.org übergibt somit für den dynamischen Host einen AAAA-Record. Im Zuge dessen ist Let's Encrypt beleidigt, weil dieser natürlich für den dyndns-Host passt, aber nicht zu der Subdomain, für die das Zertifikat erstellt werden soll. Daher klappt das Anfordern jenes Zertifikats nicht.

Spontan beholfen habe ich mir damit, IPv6 an der Fritz!Box komplett zu deaktivieren, somit wird offenbar auch kein AAAA-Record mehr übergeben, und das Ausstellen des Zertifikats klappt. Aber sonderlich elegant scheint mir das nicht. Bei dyndns konnte ich keine Möglichkeit entdecken, AAAA bzw. IPv6 zu deaktivieren, in den dyndns-Einstellungen der Fritz!Box ebenfalls nicht.

Hat jemand von euch eine Idee, wie man das handhaben könnte? Notfalls ginge ja eine Strato-Domain, die man nur für den Mail-Austausch nutzt und dabei die Strato-eigene dyndns-Lösung hernimmt. Fallen euch Alternativen ein?

Ist die Domäne im David-Admin korrekt konfiguriert? Rechtsklick "System" -> Konfigurieren... und dort im passenden Feld den Domain-Namen eintragen. Soweit ich weiß, ist diese Stelle die relevante für die Entscheidung, ob Mails extern bzw. via Provider versandt werden oder intern.

Wenn das TLDs sind, muss dann der Filter nicht *.*@icu und *.* BeSt lauten (also ohne weiteres .* am Ende)?

Zitat von r0bert81

Das mit dem verzögrten NLA-Dienst-Start habe ich auch gelesen und probiert jedoch keine Besserung. Hat das ganze evtl. damit zu tun das ich keinen Gateway eingetragen habe?

Nach meiner Erfahrung hängt das nicht am Gateway, sondern am DNS-Server. Bei kleinen Installationen ist der DC ja selbst Chef des DNS, daher kommt es dort gerne zu Zeitüberschreitungen, wenn man das System neu startet. Offizielle Microsoft-Lesart ist: In einem korrekt eingerichteten Domänen-Netz gibt es eh immer mindestens 2 DCs (incl. DNS-Rolle und 2nd DNS auf den jeweils anderen), daher stellt sich das Problem nicht. Ich hab' den Effekt allerding auch schon auf Server Essentials beobachtet, und da darf afaik ja ganz offiziell ein Server einziger DC sein. Von daher ein bisschen seltsam.

Ich behelfe mir inzwischen mit einem Powershell-Script, dass den NlaSvc nach einer Minute Systemlaufzeit neu startet. Powershell und Parameter -Force aus dem Grunde, weil im Zuge dessen auch der Netzwerklistendienst neu gestartet werden muss, was mit einem einfachen NET STOP/NET START nicht funktioniert.

Also, in der Aufgabenplanung einen Task erstellen mit Trigger "Systemstart" und 1 Min. Verzögerung, dann in den Eigenschaften Folgendes:

Programm:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Parameter:
-command "Restart-Service NlaSvc -Force"

Ist nicht schön/elegant, aber tut.

Die Benutzer stecken AFAIK in \David\Code\david.usr, Drucker in der david.drk

Zitat von Genesis

Servus, wie hast du das denn gemacht?

Wenn ich die oben angegeben Cipher hinterlege, klappt's bei mir. Wichtig ist natürlich ein gültiges Zertifikat (bei mir via eingebautem Let's-Encrypt-Automatismus) und Haken raus bei TLS 1.1 sowie Haken rein bei "Zertifikatskette übermitteln".

Welche dieser Schritte die Forward Secrecy betrifft, kann ich allerdings leider nicht sagen, habe mich auch darüber gewundert, dass diese Meldung im Zuge dessen verschwindet. Vielleicht kann das ein Krypto-Auskenner beantworten.

Hier im Forum kam mal der Tipp, im David-Admin unter TLS-Verschlüsselung auf "Benutzerdefiniert" zu stellen und dann manuell bei den verwendeten Ciphers folgendes einzutragen:

ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384

Im gleichen Dialog hab' ich TLS 1.1 abgewählt. Ferner in den Eigenschaften der Webbox die Übermittlung der Zertifikatskette eingeschaltet, anschließend ist ein Neustart des Webbox-Dienstes nötig.

Mit dieser Konfiguration bekomme ich wie erwähnt eine "A"-Einstufung, von daher ist dann Webbox-Seitig vermutlich alles getan, was getan werden kann.

Wie gesagt, Rückmeldung vom Kunden gab's bisher keine, daher ohne Gewähr, ob das im konkreten Fall wirklich hilft. Ich wollte nur im Vorfeld ausschließen, dass die Webbox noch mit veralteten Ciphern kommuniziert.

Dieses Problem ist an mich auch gerade herangetragen worden. Ich habe die Webbox des Kunden nun so weit optimiert, dass auf ssllabs.com ein "A"-Rating angezeigt wird, bisher war z. B. noch TLS 1.1 aktiviert. Es kam allerdings bislang keine Rückmeldung, ob das Problem dadurch beseitigt wurde.

Mit Office365 scheint es ebenfalls Probleme zu geben. Lt. des verlinkten Threads hilft es wohl, die Updates der GMail-App zu deinstallieren, zumindest als Workaround.

Wenn die Postfächer technisch "sauber" sind kannst du bei der überschaubaren Anzahl (10 Benutzer) auch durchaus versuchen, den Outlook-Import im David-Client zu nutzen. Ob dahinter ein Exchange liegt, ist dem Tool egal. Allerdings sollte die lokale Daten-Datei konsistent sein, das Import-Tool ist da sehr zickig anspruchsvoll. Am besten auch alle Caches etc. in Outlook abschalten.

Meine Kunden lassen sich meistens darauf ein, dass man eine Zeitlang beide Systeme parallel laufen lässt, du kannst dann nach und nach für die User den Import durchführen, während die schon produktiv im David arbeiten. 30 GB sehe ich dabei nicht als kritisch an, zumal du schreibst, es gibt große Dateianhänge - da hat man also vermutlich mit verhältnismäßig wenigen Einträgen zu tun.