English
Chinese (Simplified)
French
German
Italian
Japanese
Russian
Spanish
Vietnamese
Server 2025 version 26100.2894 enrolled as Active Directory Controller and Mdaemon 24.5.2 services issue.
-
I apologize for the long post- but wanted to give as much detail as I could. I can provide as much clarification or other information as you may need. I can also continue testing with the test server I mention below as needed.
Server 2025 version 26100.2894 enrolled as Active Directory Controller and Mdaemon 24.5.2 services issue. (also tested with Mdaemon 25.0.0.d beta)
If Mdaemon 24.5.2 or newer (have tested with the 25.0.0.d beta and seeing the identical issue) is installed and set to run as an auto-starting system service on a Server 2025 Active Directory Domain controller and that Server 2025 is upgraded to release 26100.2894 (be that via KB5050009 or via the 26100.2894 install media) you will experience an issue where the Mdaemon applications fail to load at boot. Once the server is restarted (be it after Mdaemon is installed or the server is configured as an Active Directory Controller) the Mdaemon service will start and appear to be running but only the “Mdaemon for Windows” mdaemon.exe will be running in Task Manager (none of the other associated executables such as CFEngine, ClamAV, etc will run). If you try to open the Mdaemon GUI it will hang on “Installing plug-in (ClstrSvc)” and, eventually, display an error dialog for ‘Cluster Service (64bit) for Mdaemon Messaging Server’ stating ‘Configuration Session failed to open Service control event index 0 for plugin ClstrSvc.dll. This will negatively affect your ability to control this service within this configuration session. 0x80070002: The system cannot find the file specified’.
In addition, there will be other applications and services that fail to start. Such as Windows Defender and, if installed, Avast Business Antivirus. For Windows Defender it will state ‘Threat service has stopped. Restart it now’ but it will not start. The Windows Installer service will also fail to function and will prevent you from installing/uninstalling applications that rely on it. In addition, system backup applications that utilize VSS will fail to function. Strangely (and frustratingly) there will be no errors logged in the Event Viewer.
Again, this ONLY occurs under the following circumstances: The system is running Server 2025 release 26100.2894 or newer, it is configured as an Active Directory domain controller, and Mdaemon 24.5.2 or newer (not sure about any older versions as I didn’t test that) is installed and configured to run as an auto-start system service.
If the Server 2025 is demoted from being an Active Directory domain controller (even if all the Active Directory rolls and associated rolls remain installed) this issue will not occur. Or, if Server 2025 is an earlier release, even if it is an Active Directory domain controller, the issue will not occur. If the Mdaemon system service is disabled then the issue will not occur.
I have found a work around to this. If the Mdaemon system service is set to Automatic (Delayed) then this issue will not occur. This appears to give the Server 2025 services (I am assuming Active Directory or maybe security related) time to start fully and then Mdaemon is able to start and run properly.
For context, I found this issue when one of our Server 2025 boxes received the KB5050009 update. This server has been running Mdaemon for a very long time and has also been an Active Directory domain controller. There were no issues at all until KB5050009 self installed AND the server was later rebooted (the reboot happed 5-6 days after KB5050009 was initially installed). When the server restarted we noticed that no email was flowing and that Mdaemon was not running. Initially I thought it was a conflict between the mentioned ClstrSvc.dll and Avast (as that had been an issue not too long ago). But this turns out to not be the issue as the trouble occurs even if Avast is not installed and the Windows Defender service has been removed. I then began arduous troubleshooting to try and isolate the issue. Going so far as to take a spare server and do a full clean install of Server 2025 26100.2894 with Mdaemon and spending about a week trying different scenarios until I was able to track down the exact circumstances for what causes all of this to occur.
-
Wow, thank you so much for your efforts to identify the issue. I thought that we had already changed the MDaemon service to use Automatic (Delayed Start) as the startup type, but I just checked and it does not appear that we made the change.
I'll request to change the startup type for future versions.
-
Thanks Aaron,
There is still something going on though. I just tried promoting one of our production Server 2025 boxes back to being an AD domain controller. This server also runs Mdaemon 24.5.2. I first set the Mdaemon service to a delayed start thinking that was going to work (as it did work on the test server I rolled out as mentioned in my first post). However, even with Mdaemon set to a delayed start, most Windows services (including Mdaemon, VSS, Windows Installer, Windows Defender Security, etc) fail to load after a reboot. This only happens when the server is active as an AD domain controller and is updated to the most current release of Server 2025 with KB5050009. Prior to KB5050009 this same server was working perfectly as both an AD domain controller as well as with Mdaemon (and with the Mdaemon service set to a standard automatic startup).
So something has changed with this new version of Server 2025. I'm guessing something do with Active Directory security (but that's purely a guess on my part). I'm hoping you guys can dig in to it deeper as I'm concerned that the delayed startup work-around isn't going to always work (as I'm seeing with this production server).
-
Based on what you've shared, it sounds like something that Microsoft will need to assist with. Have you opened a ticket with Microsoft support?
-
I haven't reached out to Microsoft. I can do so but I don't know how seriously they will look at it as it only seems to be an issue with Mdaemon (so far at least). I'll respond back if I hear anything from them after submitting it. Just very strange that the issue only appears when the server is also an Active Directory domain controller. I know Mdaemon can integrate with Active Directory. We aren't using that integration but is that integration active in any way even if it's not being utilized? I'm wondering if there are updated AD connection policies/security that Mdaemon isn't working with properly?
