Neben den Whitepapern und den Anleitungen im PDF-Format gibt es das Handbuch zum MDaemon-Server auch online zum lesen. Das hat durchaus seine Vorteile, denn nicht selten ist auf einem Server kein PDF-Reader installiert:
MDaemon Messaging Server V13.0
Soll die E-Mail-Domäne sich über mehrere Standorte erstrecken, so stehen dafür zwei Möglichkeiten zur Auswahl:
Ersteres benötigt je nach Anzahl der Anwender einen oder mehr Server und eine gute Anbindung an das Internet. Bei vielen Anwender und E-Mails mit (großen) Anhängen kann das schnell unangenehm werden.
Alternativ kann der Einsatz einer verteilten E-Mail-Domäne durchaus sinnvoll sein. Bei Microsoft Exchange Server nennt sich das Shared Namespace oder auch Shared Address Space. Bei MDaemon wird das mittels Domänen-Verteilung und Minger gelöst.
Am einfachsten lässt sich das anhand eines Beispiel verdeutlichen:
Es wird auf allen MDaemon-Servern an allen Standorten die gleiche E-Mail-Domäne, z.B. “firma.tld”, konfiguriert.
Auf Server A, der sich an Standort A befindet, werden die Benutzer angelegt, die an diesem Standort tätig sind. Auf Server B, der sich an Standort B befindet, werden die Benutzer angelegt, die wiederum an diesem Standort tätig sind.
Kommt nun eine E-Mail an Standort A an, die für einen Benutzer in Standort B bestimmt ist, wird über das Minger-Protokoll bei Server B nachgefragt, ob er diesen Empfänger kennt. Falls ja, wird die E-Mail entsprechend weitergeleitet. Umgekehrt verhält es sich genauso.
Die MDaemon-Server müssen sich untereinander erreichen können. Typischerweise wird das im Rahmen einer Standort-Vernetzung über VPN realisiert. Wichtig sind die Ports 25 (TCP, SMTP) und 4069 (UDP, Minger), ggf. auch 53 (TCP/UDP, DNS), falls sich die Server nicht direkt über IP-Adressen ansprechen.
Mindestens ein MDaemon-Server muss aus dem Internet mittels SMTP erreichbar und als MX-Eintrag im DNS der öffentlichen Domäne eingetragen sein. Andernfalls können von extern keine E-Mails zugestellt werden.
Anmerkung: Es besteht zwar bei MDaemon die Möglichkeit, externe Postfächer, z.B. beim Provider, mittels POP3 abzurufen. Typischerweise wird bei dem hier beschriebenen Szenario allerdings auf eine professionelle E-Mail-Anbindung gesetzt. In wie weit MultiPop oder DomainPop anwendbar sind, wurde im Rahmen dieses Beitrags nicht getestet.
Auf allen beteiligten MDaemon-Servern muss Minger konfiguriert werden:
Auf allen beteiligten MDaemon-Servern muss die Domänen-Verteilung konfiguriert werden:
Gerne wird bei der Firewall-Konfiguration übersehen, das Minger den Port 4069 und UDP verwendet.
In den Verbindungsprotokollen zu SMTP finden sich mitunter auch Angaben zu Minger:
(FAQ) MDaemon 11.x: How can I configure multiple MDaemon servers to share the same domain?
Mit SecurityPlus steht für den MDaemon Messaging Server Pro ein AntiVirus-Add-on zur Verfügung, das auf Basis von Kaspersky arbeitet. Auf der Homepage des Herstellers ist zwar nur von SMTP die Rede, allerdings funktioniert es auch wenn man keine direkte SMTP-Zustellung der E-Mails aus dem Internet hat, sondern Diese per Multi- oder DomainPop abruft.
Per Standard wird der Postmaster, das ist in der Regel der erste Benutzer der in MDaemon angelegt wurde, über Virenvorfälle, wie man im Screenshot erkennen kann, informiert.
Prinzipiell gibt es zwei Möglichkeiten, die sich allerdings etwas in den verfügbaren Optionen unterscheiden. Zum einen kann man direkt aus der jeweiligen Warteschlange heraus eine Nachricht mit der rechten Maustaste anklicken und über das Kontextmenü verschiedene Aufgaben wahrnehmen, wie z.B. den Absender auf die Weiße Liste (Whitelist) zu setzen oder eine Nachricht zu löschen. Mehr Optionen wenn es um das Verschieben von Nachrichten geht bietet allerdings der “Warteschlangen- und Statistik-Manager” an. Diesen findet man im Menü “Warteschlangen”.
Wählt man dort eine Warteschlange und eine Nachricht aus und klickt Diese mit der rechten Maustaste an, so kann man unter dem Menüpunkt “Verschieben” nicht nur weitere Warteschlangen auswählen, sondern z.B. auch Postfächer. So lassen sich False Positives direkt aus der Quarantäne an den zuständigen Benutzer verschieben.
Der MDaemon Messaging Server Pro Server bietet mehrere E-Mail-Filter an. Per Standard sind das der Spam- und Attachment-Filter. Ist das Add-on SecurityPlus installiert steht zusätzlich noch eine Antivirus-Lösung zur Verfügung.
Möchte man nun z.B. bestimmte Absender oder Anhänge zulassen, so muss das an den entsprechenden Stellen konfiguriert werden.
Alternativ kann man, sofern entsprechende E-Mails in den Warteschlangen vorhanden sind, von dort aus Absender in die Listen eintragen.
In Zeiten von vollen E-Mail-Postfächern und E-Mail-Archivierung kann es Sinn machen, automatisch nach einem bestimmten Zeitraum alte Nachrichten löschen zu lassen.
Zum einen sorgt das für mehr Übersicht, zum anderen entlastet das den E-Mail-Server als auch die Datensicherung. Archiviert man seine E-Mails beispielsweise mit Mailstore oder einer Securepoint UMA, so stehen die Nachrichten nach wie vor zur Verfügung. Sogar innerhalb des E-Mail-Programs, sofern man die Archive z.B. via IMAP oder die jeweiligen Add-ons integriert hat.
Auch der MDaemon Messaging Server bietet die Möglichkeit, automatisch alte E-Mails löschen zu lassen. Konfiguriert wird dies unter
"Einstellungen - Standard-Domäne & Server" - "Bereinigen"
Man stellt den gewünschten Intervall ein und klickt auf die Schaltflächen “Übernehmen” und “OK”.
Zu beachten gilt, das dabei nicht die Zeitangabe innerhalb einer E-Mail, sondern der Datei im Dateisystem verwendet wird. Ein Beispiel aus der Praxis:
Nach einer Kunden-Migration Anfang Januar wurden E-Mails von einem altem E-Mail-System zu MDaemon umgezogen. Folglich erhalten die E-Mail-Dateien, wir erinnern uns, MDaemon speichert die Nachrichten im *.msg-Format direkt auf der Festplatte, den Zeitstempel von dem Moment, als Sie im Dateisystem erstellt wurden.
Also selbst wenn eine E-Mail z.B. aus dem Jahr 2010 stammt und wie im Praxis-Beispiel erst Anfang 2013 in MDaemon gespeichert wird, greift das automatische Löschen erst z.B. nach 30 Tagen, also Ende Januar 2013 bzw. Anfang Februar 2013.
Im konkreten Fall machte dies gut 5 GB aus.
Eigentlich wollte ich diesen Beitrag mit einem Satz a la “Es wird wieder Zeit für einen Äpfel- und Birnen-Vergleich” beginnen und das tue ich gewissermaßen hiermit ja auch.
Ich habe die Tage mal die Installationszeiten von Microsoft’s Exchange Server 2013 und Alt-N’s MDaemon Messaging Server Pro mitgeschrieben.
Wieso das Ganze ein Äpfel/Birnen-Vergleich ist, liegt schlicht darin, das zwar beide Lösungen Groupware-Funktionen bieten, der Exchange Server mitunter eher für (ganz) große Umgebungen geeignet ist. MDaemon stellt hingegen eine Exchange-Alternative dar.
In der Vergangenheit habe ich ja schon mal darüber geschrieben, wie schnell ein MDaemon Server aktualisiert ist. Selbst eine Migration ist sehr einfach. Da kann kein Exchange mithalten.
Beide Produkte wurden auf einem Windows Server 2012, der im übrigen den aktuellen Patch-Stand aufweist, installiert. Zuvor wurden Setups der Kern-Produkte, Erweiterungen (ActiveSync und Outlook Connector bei MDaemon) und Komponenten (Office Filter, etc. die der Exchange benötigt) heruntergeladen.
Für den MDaemon Messaging Server Pro ohne Erweiterungen wurden folgende Zeiten ermittelt:
Ca. 3 Minuten ohne Bestellen eines Trial Keys. Ca. 5 Minuten mit Bestellen eines Trial Keys.
Kommen noch die Erweiterungen dazu, braucht man gut doppelt so lange. Folglich ca. 6 und 10 Minuten.
Beim Exchange Server 2013 sieht die Sache etwas anders aus. So müssen im Vorfeld drei zusätzliche Komponenten, verschiedene Rollen und Features installiert werden und dann nach ca. drei Neustarts und mehrere Runden Microsoft/Windows Updates durchlaufen werden.
Ca. 45 Minuten insgesamt für die Vorbereitung. Ca. 1 Stunde für das eigentliche Exchange Server 2013 Setup.
Die Zeiten wurden nur im Groben ermittelt. Weitergehende Konfiguration wurde nicht mit einbezogen und kommt folglich noch obendrauf. Die Zeiten können in Sachen Hardware und Performance, als auch durch die Internetanbindung variieren.
Kurz und knapp zum Abschluss: Ziemlich großer Unterschied!
Ein etwas seltsames Problem hat sich die Tage bei einem Kunden gezeigt:
Als Groupware-Server kommt Alt-N’s MDaemon Messaging Server Pro mit Outlook Connector und Microsoft Outlook 2010 zum Einsatz.
Neben dem gemeinsamen, öffentlichen Adressbuch werden zusätzlich öffentliche Kalender für die Termin-Vergabe in Besprechungsräumen verwendet.
Bei manchen Arbeitsplätzen wurden diese öffentlichen Kalender nicht mehr innerhalb von Outlook aktualisiert. Im WorldClient lief allerdings alles wie bisher.
Das Problem ist damit auf Outlook oder den Outlook Connector beschränkt. Welche Komponente genau, konnte bislang nicht geklärt werden.
Ein Aufräumen der Outlook Connector-Datenbank als auch ein Deaktivieren der Outlook-Addons oder des Virenscanners brachte keine Änderung.
Erst das Erstellen eines neuen öffentlichen Kalenders und das Einhängen in Outlook startete die Aktualisierung wieder.
Der Hersteller-Support wurde über dieses Problem informiert, konnte aber bislang keine Erklärung oder Lösung dafür finden. Ob unsere Lösung auf die Dauer das Problem löst, wird sich zeigen. Bislang ist es auch das erste und einzige Mal, das uns diese Phänomen begegnet ist.
Sperriger Titel, trifft den Nagel aber zwischen die Augen (hehe).
Bei einem Kunden mussten ca. 2200 E-Mails die via MailStore Server in ein Postfach auf einem MDaemon Server exportiert wurden, verschoben werden. Damit der Kunde in Ruhe weiterarbeiten kann, habe ich das Ganze auf dem Server durchgeführt.
Der Export von MailStore zu MDaemon war soweit kein Problem. Damit die E-Mails im Postfach aus dem “MailStore-Export”-Ordner in den eigentlichen Ordner platziert werden, sollten Diese schlicht verschoben werden. Wie bereits erwähnt, sollte der Kunde möglichst nicht gestört werden. Da sonst kein Outlook mit entsprechendem Connector zur Verfügung stand, wurde kurzerhand der WorldClient, also das MDaemon Web-Interface aufgerufen.
Dort hat man ebenfalls die Möglichkeit, E-Mails zu markieren und zu Verschieben. Im Gegensatz zu Outlook kann man leider nicht alle Nachrichten auf einmal als Liste anzeigen lassen. Das wären demnach dann 45 Seiten gewesen, auf denen man alles markieren und verschieben hätte müssen.
Damit es schneller geht, wurde kurzerhand die Einstellung, das statt der standardmäßigen 50 eben 500 (entspricht der maximal Einstellung) Nachrichten angezeigt werden vorgenommen. Somit waren es nur noch fünf Seiten die zu markieren und verschieben sind.
Aber denkste, alle Nachrichten markiert, “Kopieren/Verschieben” aus dem Kontextmenü aufgerufen, Ziel-Ordner ausgewählt und auf die Schaltfläche “Verschieben” geklickt. Peng! Man wird abgemeldet.
Ok nicht lange rumgefackelt, kurzerhand die Anzeige auf 250 Nachrichten eingestellt und schon läuft’s. So waren es dann sieben oder acht Seiten, die noch zu markieren und verschieben waren.
Lange Rede, kurzer Sinn: Das Exportieren von MailStore zu MDaemon hat ca. 15 Minuten gedauert, das Verschieben trotz des Umstands nochmal ca. 15 Minuten. Alles gut.
Per Standard versendet und empfängt Outlook alle 30 Minuten neue Nachrichten. In Verbindung mit dem Outlook Connector und einem MDaemon Messaging Server Pro ist das nicht viel anders, nur das durch die Voreinstellung des Outlook Connectors nur der Posteingang auf neue Nachrichten überprüft wird.
Das kann in Verbindung mit öffentlichen und freigegebenen Kalendern (oder anderen Ordnern) bei der Vergabe von Terminen oder dem Verschieben von Nachrichten zum Problem werden. Dabei ist Problem im organisatorischen Sinne zu verstehen.
Am Beispiel von Terminen könnte es sich um Einträge für Außendienstler handeln oder um Reservierungen für einen Besprechungsraum. Werden solche Termine von mehr als einer Person vorgenommen, kann es schnell zum Konflikt kommen, wenn noch freie Zeiten angezeigt werden, die eigentlich bereits belegt sind.
Ein Stück weit betrifft das auch den Fehler Windows: Öffentlicher Kalender von MDaemon wird unter Outlook nicht mehr aktualisiert.
Abhilfe schafft das Ändern zweier Einstellungen, einmal in Outlook und einmal im Outlook Connector.
Zunächst ändert man das Intervall, in dem Outlook auf neue Nachrichten prüft. Am Beispiel von Outlook 2010 sieht das wie folgt aus:
Welche Ordner nun in diesem Intervall auf Änderungen überprüft werden, wird im Outlook Connector pro Benutzer konfiguriert.
Bei einem Kunden sollten aus einem bislang gemeinsam genutzten Postfach und der dort angelegten Kalender die Termine nun auf die persönlichen Postfächer der Mitarbeiter verschoben werden. Da der Weg über Outlook allerdings in Sachen Performance recht langwierig sein kann, wurde auf einen Trick zurückgegriffen.
Einer der Vorteile (meiner Meinung nach) beim MDaemon Messaging Server liegt darin, das alle Einstellungen und Daten als Dateien gespeichert werden. Das vereinfacht nicht nur die Datensicherung, sondern eröffnet wie in diesem Fall auch das einfache Verschieben von Daten zwischen den Postfächern.
Bei diesem Fall mussten nur die *.msg Dateien aus dem Ordner
LW:\MDaemon\Users\DOMAIN.TLD\POSTFACHNAME\Kalender.IMAP
(ggf. auch “Kalender von …” genannt, falls weitere Kalender angelegt wurden) in den entsprechenden Ordner des anderen Benutzers kopiert bzw. verschoben werden.
Wichtiger Hinweis: Ich habe diesen Trick bislang nur einmal angewendet und es scheint als habe es funktioniert. Ob allerdings evtl. irgendwelche negativen Auswirkungen auftreten könnten und ob ggf. die *.mrk-Dateien, die ich nicht mitkopiert habe, benötigt werden, kann ich im Moment nicht sagen.
Immer mehr Anbieter verschlüsseln ihre E-Mail-Kommunikation und lassen unverschlüsselte Zugriffe nicht mehr zu. Ruft man von einem MDaemon-Server solche Postfächer mittels POP3 ab, so ist je nach Anbieter nur eine kleine Änderung notwendig, damit verschlüsselt kommuniziert wird.
Ein Kunde kann aufgrund seiner Internet-Anbindung (dynamische IP-Adresse) keine direkte SMTP-Zustellung realisieren. Seine E-Mail-Adressen samt Postfächer liegen bei 1&1. Seit geraumer Zeit weist der Anbieter mit einer E-Mail auf die kommende Änderung hin:
Eine Auflistung der E-Mail-Server findet sich zudem hier.
In diesem Fall musste nur ein Haken gesetzt werden:
Im Protokoll kann man anhand folgender Zeilen erkennen, das StartTLS verwendet wird:
Wed 2014-01-22 17:07:41: --> STLS
Wed 2014-01-22 17:07:41: Wed 2014-01-22 17:07:41: SSL negotiation successful (TLS 1.0, 2048 bit key exchange, 128 bit AES encryption)
Oder wenn TLS/SSL verwendet wird, sehen die entsprechenden Einträge so aus:
Mon 2014-01-27 15:18:44: * Connection established (192.168.0.2:50732 -> 46.30.211.93:995)
Mon 2014-01-27 15:18:44: Waiting for protocol to start...
Mon 2014-01-27 15:18:44: SSL negotiation successful (TLS 1.0, 2048 bit key exchange, 128 bit AES encryption)
Hinweis: Verwendet man eine UTM, so kann Diese evtl. nicht mehr filternd (AntiVirus/AntiSpam) in die Kommuninkation eingreifen!
EBERTLANG – Blog: Wichtig für MDaemon: T-Online & Co. stellen auf SSL um
Mit dem Aktivieren einer Option im MDaemon Messaging Server werden automatisch als Spam-markierte E-Mails in den Junk-E-Mail-Ordner verschoben. Ein manuelles Anlegen von Regeln oder Filtern ist nicht notwendig.
Diese Option bewirkt, das in jedem Benutzerkonto unter “IMAP-Filter” eine entsprechende Regel konfiguriert wird.
Der MDaemon Messaging Server stellt in Verbindung mit ActiveSync die Möglichkeit, nicht nur die Daten des eigenen Benutzerkontos mit dem Smartphone zu synchronisieren, sondern auch die von öffentlichen und freigegebenen Ordnern.
Leider kann letzteres einen negativen Nebeneffekt haben. Im konkreten Fall sind Kalender freigegeben und Diese wurden ebenfalls auf die angebundenen Smartphones synchronisiert. Das führte wiederum dazu, das man im Kalender auf dem Smartphone nicht nur die eigenen sondern auch die Termine der Anderen hatte.
Abhilfe schafft das Deaktivieren des Einbeziehens von freigegebenen Ordnern unter “Einstellungen – Verwaltung für mobile Endgeräte… – ActiveSync – Optionen”:
Der Beobachtung nach wirkte die Einstellung nahezu sofort auf einem Apple iPhone 5 mit aktuellen iOS und die unerwünschten Termine verschwanden aus dem Kalender. Bei einem ebenfalls vorhandenen BlackBerry Z10 mit gleichfalls aktuellem Softwarestand blieben die Termine bestehen. Erst ein Löschen und erneutes Anlegen des ActiveSync-Kontos auf dem Gerät löste diesen Umstand.
Rechzeitig zum Support-Ende von Windows Server 2003 (inkl. Small Business Server 2003) und Exchange Server 2003 stellt EBERTLANG das PDF MDMigrator Guide – von Exchange zu MDaemon in wenigen Schritten für den MDaemon Messaging Server bereit.
Auf 11 Seiten wird Schritt-für-Schritt erklärt, welche Voraussetzungen notwendig sind, welche Vorbereitungen getroffen werden müssen und wie die eigentliche Migration abläuft um von einem Exchange Server 2003, 2007 oder 2010 zu MDaemon zu wechseln.
Ein paar Screenshots des Migration Guides stammen von diesem Blog (siehe entsprechende Copyright- und Quellen-Angaben). EBERTLANG hat im Vorfeld freundlich um Erlaubnis gefragt, die ich gerne erteilt habe. An dieser Stelle möchte ich mich für die gute Zusammenarbeit gedanken.
Eine Möglichkeit der Migration hatte ich ebenfalls vor längerer Zeit im Rahmen dieses Blogs beschrieben:
Windows: Migration von Windows Small Business Server 2003 zu Alt-N MDaemon Messaging Server Pro
Wo möglich wundert man sich, das der MDaemon-Ordner insgesamt größer ist, als die reine Anzahl der PIM-Daten (Mails, Kontakte, Termine, …). Das kann an der Protokollierung liegen.
Die Größe der Protokolle ist unter anderem davon abhängig, wie viele Mails über den Server laufen. In der Voreinstellung wird jeden Tag das aktuelle Protokoll als ZIP-Archiv archiviert und ein neues Protokoll begonnen.
Entweder man löscht regelmässig ältere Datein unter
LW:\MDaemon\Logs\OldLogs
oder man konfiguriert ein automatisches Löschen unter
Einstellungen - Server-Einstellungen - Protokollierung - Wartung
Seit Version 17.0 unterstützt der MDaemon Messaging Server die automatische Einbindung von Let’s Encrypt-Zertifikaten. Im Rahmen eines Kundenprojekts hatte ich nun Gelegenheit, dieses zu Nutzen.
Damit Let’s Encrypt genutzt werden kann, müssen die Ports 80/tcp (http) und 443/tcp (https) in der Firewall am Internetzugang als auch in der Windows-Firewall des Systems, auf dem der MDaemon installiert ist, freigegeben sein.
Ferner muss eine Domäne im öffentlichen DNS registriert sein, die auf die IP-Adresse des Internetanschlusses verweist. Hat man keine feste öffentliche IP-Adresse können DDNS-Dienste verwendet werden. In diesem Fall wird spDYN (vormals SPDNS) verwendet.
Im MDaemon Messaging Server muss, ausgehend von der Voreinstellung, nichts angepasst werden. Auf Windows-Seite muss je nach Version und Ausgabe ggf. noch die PowerShell (min. Version 3.0) aktualisiert, die PowerShell-Ausführungsrichtlinie angepasst und ACMEsharp installiert werden. Siehe dazu
Let’s Encrypt Community – Windows 7 & MDaemon: error installing the certificate
Wichtig ist, das der SMTP-Hostname der Standard-Domäne (i.d.R. die erste Domäne) unter „Einstellungen – Domänen-Manager – <Domäne> – Hostname & IP – SMTP-Hostname“ der öffentliche Domäne, also hier der spDYN-Domäne, entspricht. Andernfalls bricht das Ausstellen des Zertifikats ab. Die Mail-Domäne ansich kann einen anderen Namen haben.
Sind die Voraussetzungen erfüllt, kann durch folgenden Befehl das Zertifikat ausgestellt werden:
powershell LW:\MDaemon\LetsEncrypt\LetsEncrypt.ps1
Dabei handelt es sich um die minimalste Angabe. Unter Umständen muss ein „-ExecutionPolicy Bypass“ nach „powershell“ eingefügt werden. Man kann zusätzlich noch alternative Domänen, sofern verwendet den IIS-SiteName und die Postmaster-Mail-Adresse angeben:
LetsEncrypt.ps1 -AlternateHostNames mail.domain.tld,wc.domain.tld -IISSiteName MeineSite -To "admin@domain.tld"
Z.B. kann mittels „AlternateHostNames“ noch die Subdomain für Autodiscover („autodiscover.domain.tld“) mit abgedeckt werden.
Lässt man „-to admin@domain.tld“ weg, wird automatisch „postmaster@<SMTP-Hostname>“ verwendet. In diesem Fall wäre das also die spDYN-Domäne: „postmaster@subdomain.spdns.de“.
Hinweis: Die TLD „.local“ kann sowohl als primäre als auch alternative Domäne nicht verwendet werden!
Das PowerShell-Skript führt die notwendige Schritte aus das Zertifikat zu bekommen, ändert die relevanten *.ini-Dateien des MDaemon ab (MDaemon.ini, WordClient.ini, WebAdmin.ini) und startet den MDaemon neu. Von daher sollte beachtet werden, wann man das Zertifikat ausstellt bzw. dieses erneuert wird, damit im laufenden Betrieb nicht (wenn auch nur kurz) die Verbindungen unterbrochen werden.
Die Zertifikate von Let’s Encrypt laufen alle 90 Tage ab, daher sollte man diese automatisch verlängern bzw. neu ausstellen lassen. Dazu muss lediglich der oben genannte Befehl erneut ausgeführt werden. In Form eines kleines Batch-Skriptes und der Windows-eigenen Aufgabenplannung kann das z.B. so aussehen:
@echo off powershell LW:\MDaemon\LetsEncrypt\LetsEncrypt.ps1 -To "admin@domain.tld"
Soweit ich weiß kann frühstens nach 60 Tagen erneuert werden. Zu oft sollte man nicht versuchen, das Zertifikat neu ausstellen zu lassen, da es sonst zu einer Sperre (Duplicate Certificate, etc.) kommen kann.
Unter „LW:\MDaemon\Logs“ erstellt das PowerShell-Skript eine Datei mit dem Namen „LetsEncrypt.log“.
Die Meldungen sowohl bei der Ausgabe des Skripts als auch im Log sind gut verständlich. So lässt sich im Problemfall relativ leicht rauslesen, woran es hakt.
Zumindest für das erste Ausstellen wird Port 80/tcp (http) benötigt. Wie es dann beim Renewal aussieht, kann ich aktuell noch nicht sagen. Beim Kunden wurde nach dem Ausstellen des Zertifikats die Umleitung von „HTTP mit Umleitung nach HTTPS“ unter „Einstellungen – Web- & IM-Dienste…“ konfiguriert, da man denn WorldClient nicht unverschlüsselt stehen lassen wollte.
Ich werden dann in 90 Tagen berichten und diesen Beitrag aktualisieren.
Um es Nutzern einfacher zu machen, Exchange- bzw. ActiveSync-Konten auf ihren Smartphone’s oder Tablets einzurichten, bietet es sich an AutoDiscover (aka AutoErmittlung) zu verwenden. Dadurch werden Anhand des Domänenanteils der E-Mail-Adresse automatisch der Mailserver ermittelt und SSL aktiviert. Der MDaemon Messaging Server zusammen mit der ActiveSync-Erweiterung bietet dazu fast alles nötige an.
Unterhalb der Haupt- bzw. Maildomäne eine Subdomain „autodiscover.domain.tld“ anlegen. Entweder per A- (bei fester öffentlicher IP-Adresse) oder CNAME-Eintrag (z.B. bei DDNS) auf den MDaemon-Server zeigen.
Am Beispiel von 1&1 zusammen mit einer DDNS-Domain bei spDYN sieht dies z.B. so aus:
Bis Änderungen im DNS greifen, können durchaus einige Stunden vergehen.
Am Beispiel vom bei MDaemon mitgelieferten Let’s Encrypt-PowerShell-Skript könnte dies so aussehen:
LetsEncrypt.ps1 -AlternateHostNames autodiscover.domain.tld -To "admin@domain.tld"
Die Angabe der Mail-Domäne ist nicht notwendig, da das Skript den SMTP-Hostname automatisch verwendet.
Ein einfacher erster Test kann darin bestehen, via Browser folgende URL aufzurufen:
https://autodiscover.domain.tld/AutoDiscover/AutoDiscover.xml
Funktioniert die DNS-Auflösung, laufen die Dienste usw. erhält man eine Antwort in folgender Art:
Um den Erfolg oder Misserfolg von Zugriffen zu erkennen, kann man die Protokolle unter „Plugins – AutoDiscover, ActiveSync und Dynamischer Filter“ konsultieren. Bei zu vielen Fehlerversuchen kann es passieren, das man auf die Blacklist vom „Dynamschen Filter“ gelangt.
MDaemon – Online Hilfer – ActiveSync für MDaemon (Automatische Provisionierung durch ActiveSync Autodiscover)
MDaemon – Knowledge Base – How to setup the ActiveSync AutoDiscovery Service
MSDN – Erstellen von DNS-Einträgen bei 1&1
EBERTLANG – Blog – Feature-Lexikon: Konfiguration von „AutoDiscover“ für MDaemon
Apple – Exchange ActiveSync auf dem iPhone, iPad oder iPod touch einrichten
Bei Android kann die Einrichtung je nach Version, App und Hersteller variieren.
Outlook ab Version 2013 kann ebenfalls via ActiveSync angebunden werden.
Möchte man MDaemon und ActiveSync zunächst nur testen, genügt der Download des Setups und das Anfordern einer Testlizenz.
Diese Testlizenz gilt allerdings nur für den MDaemon Messaging Server ansich. Für ActiveSync muss eine Testlizenz separat angefordert werden. Im Gegensatz zur vorangegangenen Testlizenz muss dazu nicht eine E-Mail-Adresse angegeben werden.
An dieser Stelle lauert eine kleine Falle:
Das Aktivieren der Test-Lizenz für ActiveSync klappt nur, wenn man folgenden Weg geht:
Einstellungen – Verwaltung für mobile Endgeräte – Testlizenzschlüssel anfordern
Versucht man es über
Server – ActiveSync: aktiviert – Rechtsklick „Informationen ActiveSync“
und dort Testlizenzschlüssel anfordern funktioniert es nicht. Der Dialog ist identisch, aber bei letztgenannten Weg passiert schlichtweg nichts, nachdem man die Anforderung bestätigt hat.
Manchmal hat man Glück im Unglück: Während der Migration eines Windows SBS 2008 zu Windows Server 2016 Standard mit MDaemon Messaging Server starb die Securepoint UTM bei einem Kunden.
In Folge des Ausfalls klappte zunächst nicht die Zustellung bzw. der Abruf von Mails, da die UTM als Mail-Relay (SMTP-Versand als Smarthost) und Mail-Connector (Abruf von POP3-Konten) fungierte. Da die eigentliche Mail-Server-Migration schon durch war, d.h. der Exchange Server 2007 war bereits weg, dafür lief ein MDaemon Messaging Server, war das kein größeres Problem. Es wurde fix der Smarthost und MultiPop im MDaemon konfiguriert und schon liefen die Mails mit einem „Otto-Normal-Firewall-Router“ als Leihgerät zur defekten UTM wieder.
Mit Exchange hätte zwar der Versand per SMTP funktioniert, aber ein Abruf von POP3-Konten beim Provider ging mit den Bordmitteln des SBS schon lange nicht mehr und ein vom vorigen IT-Service verwendeter POPcon lief ebenfalls seit einiger Zeit nicht mehr.
Der Vollständigkeit halber sei erwähnt, das eine direkte SMTP-Anbindung beim Kunden bislang nicht möglich war (soll in Zukunft kommen). Die zusätzliche Sicherheit durch die Filter der UTM fehlt zwar aktuell, da aber Panda Adaptive Defense 360 zum Einsatz kommt, ist das (imho) zu verschmerzen.
Die UTM wird wieder, da noch nicht so alt, Instandgesetzt und wird dann wieder eingebunden.
Wer servergespeicherte Profile zusammen mit Outlook und MDaemon’s Outlook Connector einsetzt, sollte bei großen Postfächern den Cache auf eine Netzwerkfreigabe legen.
Hintergrund ist, das die Datei „LocalCache.db“ und der dazugehörige Ordner „Attachments“ recht umfangreich ausfallen kann, wenn man z.B. ein Postfach mit mehreren tausend Nachrichten oder eine umfangreiche öffentliche Ordner-Struktur hat.
Damit nicht bei jedem Arbeitsplatzwechsel der Cache zum und vom Server synchronisiert werden muss, bietet es sich an, diesen auf eine Netzwerkfreigabe zu legen. So bleibt das eigentliche Benutzerprofil schlank, An-/Abmelden bleibt damit zügig.
Der Pfad kann in den Eigenschaften des Outlook Connectors des jeweiligen Outlooks unter „Verschiedene Einstellungen – Einstellungen zum lokalen Cache – Benutzerdefinierter Speichertort“ geändert werden. Daraufhin beginnt ein neuer Abgleich.
Nebenbei bemerkt: Ein Ändern der Pfade in der „config.xml“ funktioniert nicht, da diese vom Outlook Connector überschrieben werden.
