Gleich Vorweg möchte ich erwähnen, das die im Titel genannten “Fehler” nichts direkt mit dem MDaemon Email Server zu tun haben. Die jeweiligen Ursachen liegen an den zwei unterschiedlichen Servern, da diese nach heutigem Maßstab nicht mehr die Schnellsten sind und beispielsweise noch mit Festplatten (statt SSDs) arbeiten.

Ironischerweise hatte ich die letzten Tage gleich zwei Fälle, bei denen der MDaemon-Dienst nicht erfolgreich automatisch gestartet ist. Beides sind Windows Server 2012 R2, also nach heutigem Stand (März 2021) schon ein paar Tage alt und auf beiden Laufen noch so Dienste wie z.B. Lexware (Datenbank) und mehr.

Bei dem einen Server startet regelmässig der MDaemon-Dienst nicht mehr, nachdem das Let’s Encrypt-Zertifikat verlängert wurde. Laut Ereignisprotokoll antwortet der Dienst nicht in der vorgegebenen Zeit. Abhilfe schafft hier ein kleines Skript, das nachschaut ob der Dienst läuft und wenn nicht, diesen dann startet:

@echo off

rem In das Arbeitsverzeichnis wechseln

 cd "C:\Scripts\MDaemon"

rem Aeltestes Protokoll entfernen, voriges Protokoll umbenennen

 del /q MDaemon-prev.log
 ren MDaemon.log MDaemon-prev.log

rem Pruefen, ob der MDaemon-Dienst ausgefuehrt wird.
rem Falls dieser nicht laeuft dann den Dienst starten.

 sc query "MDaemon" | find "STATE : 4 RUNNING"

 if %errorlevel% gtr 0 (
  echo %date% - %time% - Der MDaemon-Dienst wird nicht ausgefuehrt. Der Dienst wird gestartet: >> MDaemon.log
  net start "MDaemon" >> MDaemon.log 2>&1
  net start "MDaemon Remote Administration Server"
  Tools\smtpsend.exe -f -t<Empfänger> -h127.0.0.1 -sMDaemon-Dienst -iMDaemon.log -lu<Anmeldename> -lp<Kennwort>
 ) else (
  echo %date% - %time% - Der MDaemon-Dienst wird ausgefuehrt. >> MDaemon.log
  REM Tools\smtpsend.exe -f -t<Empfänger> -h127.0.0.1 -sMDaemon-Dienst -iMDaemon.log -lu<Anmeldename> -lp<Kennwort>
 )

Wie man sieht, wird zudem ein Protokoll und ggf. eine E-Mail versendet. Dieses Skript via Aufgabe ausgeführt zu einem Zeitpunkt, an dem der Email Server definitiv laufen sollte (beispielswiese in der Nacht außerhalb von Backup-, Let’s Encrypt-, Update- oder anderen Zeitfenstern) stellt den Dienst bei Bedarf wieder her. Natürlich kann man auch mit einem Monitoring seiner Wahl den Dienst-Status überwachen und reagieren lassen.

Bei Nummer Zwei startet der MDaemon-Dienst beispielsweise nach Windows Updates oder der automatischen Aktualisierung des MDaemon an sich (mit anschl. Windows-Neustart) nicht erfolgreich. Auch hier kommt es zu einem Timeout in der Dienste-Verwaltung.

Abmildern kann man dies mit einer Änderung der Dienst-Konfiguration:

  • Die Eigenschaften des MDaemon-Dienstes bearbeiten.
  • Den “Starttyp” von “Automatisch” auf “Automatisch (Verzögerter Start) ändern.
  • Optional: Auf der Registerkarte “Wiederherstellung” bei “Erster Fehler” “Dienst neu starten” auswählen.

Zudem kann man das obige Skript ebenfalls hierfür verwenden, um sozusagen eine weitere Maßnahme zur automatischen Fehlerbehebung zu etablieren.

Der Vollständigkeit halber: Selbstredend könnte man die Timeouts in Windows ändern, das gilt dann allerdings für alle Dienste und ob man das wirklich möchte ist etwas anderes.

Update 05.05.2021

Kleine Änderung im Skript, da der Befehl

net start | find /i "MDaemon"

zu ungenau ist und neben dem “Hauptdienst” auch die beiden weiteren MDaemon-Dienste

MDaemon Remote Administration Server
MDaemon XMPP Server

findet und so im Fehlerfall sozusagen übersieht, das der eigentliche “MDaemon”-Dienst nicht gestartet ist. Daher den Befehl durch

net start | findstr /i /x "MDaemon"

ersetzt, da “findstr” mit “/i” und “/x” nach dem exakten Suchbegriff schaut.

Update 06.05.2021

Und nochmal eine Änderung, leider an der gleichen Stelle. Leider hat sich gezeigt, das “findstr /x” doch keinen Treffer landet, ein Versuch mit “/l” half ebenfalls nicht. Daher nun der Wechsel zu

sc query "MDaemon" | find "STATE : 4 RUNNING"