In the U.S., daylight savings time ended on November 2 at 2:00am. Which means that at 2:00am, it was suddenly 1:00am. At that moment, Essentials lost its ability to send email.
I maintain multiple Server 2012 R2 Essentials machines. (See notes below re. 2016 Essentials as well.) Each one emails its health report at 6am. On all three, on the Health Report tab, at 11/2 1:00am, I see the message:
Status: Cannot send email.
Error: The Windows Server
Essentials Management service is not running.
That message repeats on November 2 and 3 at 6am, i.e. at the times when the reports should have been sent.
When I right-click on a report and choose Email the Health Report, it shows “Emailing report…” but never finishes. If I stop and restart the dashboard, it is back to “Cannot send email.”
Reviewing my email history, I see that I did receive the 1:00am emails, even though the dashboard says “Cannot send email.” However I did not receive the subsequent 6am emails.
Workaround: Restart the Service
The Windows Server Essentials Management service is running and I doubt that it stopped. I decided to try restarting the Windows Server Essentials Management service. After that, when I sent a Health Report email from the dashboard, it went out immediately.
It seems there are a couple bugs here:
- The Essentials sever tries to send an unscheduled health report at the end of Daylight Savings Time.
- The Essentials sever cannot send email after the end of Daylight Savings Time.
Fortunately the workaround is simple: restart the Windows Server Essentials Management service.
Update November 8, 2016
As several have reported in the comments below, this issue continues two years later. In the US, on November 6, 2:00am became 1:00am. Essentials tried and failed to email a Health Report at 1:00am, and has failed at 6:00am every day since then. The reason given is still, “The Windows Server Essentials Management service is not running,” even though it is. After restarting the Windows Server Essentials Management service just now, I was able to manually email this morning’s report.
Update November 3, 2019 – Affects Some But Not All 2016 Essentials
So this is interesting. Two Essentials 2016 installations were failing to send email and needed the Essentials Management Service restarted. These two machines use an unauthenticated SMTP server running on the same LAN for email relaying.
A third Essentials 2016 installation, only a couple weeks old, did send the email without a service restart. This server sends directly through smtp.gmail.com.
I’m curious if anyone else sees this pattern? Local SMTP vs. remote, authenticated SMTP?
Update November 2, 2020 – All Machines Affected Again
This year, one 2012 R2 Essentials and three 2016 Essentials machines all failed to send reports after Daylight Savings Time ended on November 1. The SMTP server didn’t matter. Restarting the Windows Server Essentials Management service got the emails working again.