MDaemon: Kein ActiveSync mehr seit der Windows Updates vom März’21?

Die Windows Update vom März 2021 sorgen weiter für Ungemach, zwar hauptsächlich in Sachen Drucker oder Druckvorschau, aber manchmal gibt es noch weitere “Kollateralschäden”.

Bei einem recht neuem Kunden der seine IT selbst verwaltet und seit langem den MDaemon Email Server auf einem Quasi-Server unter Windows 10 Pro verwendet streikte ActiveSync seit dem Patchday.

Ein näherer Blick zeigte, dass das Problem weit- und tiefergehender ist. Beim ersten Verbindungstest via Browser und URL (ganz gleich ob via Internet oder lokal) fiel zunächst auf, das auf die https-Anfrage sogar mit dem richtigen Let’s Encrypt-Zertifikat geantwortet wird, aber dann kam gleich ein “404 Not Found”.

Beide URLs, sprich die zum Webmail (aka WorldClient)

https://<fqdn>

und die zu ActiveSync

https://<fqdn>/Microsoft-Server-ActiveSync

zeigten diesen Fehler.

Die entsprechenden Teile im MDaemon, sprich Webmail und ActiveSync, sind aktiv. Seltsam. Also mit NirSoft’s CurrPorts mal die Port-Belegung angeschaut (“netstat -ano” geht natürlich auch, CurrPorts finde ich persönlich hübscher, zumal man die zugehörigen Prozesse gleich mit aufgelistet bekommt) und da sah man dann, das der Port 443/tcp mehrfach belegt ist.

Da gab es die gewollten Bindungen durch die “WorldClient.exe”, das ist der Webserver des MDaemon für Webmail und ActiveSync, aber auch Bindungen auf “SYSTEM” mit der PID “4”. Nach der Änderung von Port 443/tcp auf eine andere Nummer konnte der MDaemon-eigene Webserver wieder erreicht werden, die “SYSTEM-Bindung” blieb allerdings bestehen.

Der erste Gedanke meinerseits in solchen Situationen ist immer: Da läuft bestimmt ein IIS, also der Webserver von Microsoft. Ein Blick in die Dienste-Liste sorgte allerdings für Ernüchterung, da der “WWW-Publishingdienst” zwar installiert aber nicht gestartet und sogar deaktiviert ist.

Komisch ist zudem, das sozusagen ab Werk der IIS nicht einfach eine Bindung zu 443/tcp für https mit auch noch dem “richtigen” Zertifikat von selbst macht. Als vorläufigen Workaround wurde zunächst im Firewall-Router des Kunden die Port-Weiterleitung geändert, damit ActiveSync erstmal wieder läuft. Die Abklärung zu diesem Port-Konflikt sollte später erfolgen.

Bei einem weiteren Termin wurde dann zusammen mit dem Support von EBERTLANG danach geschaut. Der IIS ist zwar installiert, wird allerdings nur für FTP genutzt, wie bereits erwähnt ist der WWW-Dienst deaktiviert. Zur Sicherheit wurden dennoch die Bindungen überprüft, dort war allerdings nichts in Richtung 443 vorhanden.

Interessant wurde es dann in der Eingabeaufforderung: Nach Absetzen des Befehls

net stop http

und dem Bestätigen das abhängige Dienst beendet werden dürften kam soweit erstmal die Bestätigung der jeweiligen Dienste-Stops:

Die folgenden Dienste hängen vom Dienst HTTP-Dienst ab.
Das Beenden des Dienstes HTTP-Dienst beendet auch diese Dienste.

UPnP-Gerätehost
SSDP-Suche
Druckwarteschlange
Routing und RAS
Funktionssuche-Ressourcenveröffentlichung

Möchten Sie diesen Vorgang fortsetzen? (J/N) [N]: J
UPnP-Gerätehost wird beendet.
UPnP-Gerätehost wurde erfolgreich beendet.

SSDP-Suche wird beendet.
SSDP-Suche wurde erfolgreich beendet.

Druckwarteschlange wird beendet.
Druckwarteschlange wurde erfolgreich beendet.

Routing und RAS wird beendet..
Routing und RAS wurde erfolgreich beendet.

Funktionssuche-Ressourcenveröffentlichung wird beendet.
Funktionssuche-Ressourcenveröffentlichung wurde erfolgreich beendet.

Systemfehler 1051 aufgetreten.

Ein Stoppzeichen wurde an einen Dienst gesendet, von dem andere Dienste abhängen.

Denn Fehler am Ende ignorieren wir jetzt einfach mal. Anschließend wurde Dienst für Dienst wieder gestartet und dazwischen beobachtet, ob der Port 443 wieder irgendwie belegt ist. Kurzum: Der Übeltäter ist “Routing und RAS” (RRAS). Warum dieser den Port belegt konnten wir nicht klären. Da bislang nach der Beendigung dieses Dienstes keine Probleme auftraten haben wir ihn auf “Deaktiviert” gesetzt.

So ganz zufrieden bin ich mit dieser Lösung nicht, konnte allerdings bislang leider noch ermitteln was da genau passiert. Ganz unbekannt sind diverse Probleme in dieser Richtung wohl nicht:

superuser  Why is the ‘System’ process listening on port 443?

Vielleicht ergibt sich ja noch etwas. Jedenfalls danke ich an dieser Stelle dem Support von EBERTLANG für die tolle Unterstützung.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.