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.
Bugs
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.
Update November 7, 2021 – Strange 1:00am Report, Still Failing
This year, one 2012 R2 Essentials and two 2016 Essentials machines tried to send reports at 1:00am (the exact time that Daylight Savings Time ended) and again at 6:00am. The dashboards say that both reports failed to send, but I received the 1:00am reports. Restarting the Windows Server Essentials Management service again.
Update November 7, 2024 – Ten Year Later, Missing Service
Ten years after I first blogged about this, and weeks before I decommission my last 2016 Essentials machine, the issue continues. This time, though, a new twist: the Windows Server Essentials Management Service is missing from the list in services.msc:
Fortunately I can still see and control the service from the command line with the net start / net stop commands, which did get the email working again:
There is a StackOverflow post that discusses how permissions can cause a service not to appear in the services list. Checking the current permissions of the WSE Management service:
sc sdshow WseMgmtSvc
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
Let’s compare that to the permissions of the WSE Health Service:
sc sdshow WseHealthSvc
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
The permissions are identical, so there must be some other reason that the WSE Management service is not appearing in the services.msc list.
Considering that this server will be decommissioned soon, I’m not going to pursue this further.
Thanks so much, I had the same issue and wasn’t sure what was happening. I thought it was my SMTP settings and restarted the SMTP server many times. Finally restarting the Windows Server Essentials Management service fixed. it.
Worked fine, thanks!
Mark,
Thanks for posting this. Rather sad that two years later the bugs still exists, but at least your entry gave me some clue as to where to look for a solution. Without you sharing your experience I would have wasted a lot more time trying to figure out what was going on. Chapeau!
Cheers, Steve
Thanks Mark. We noticed this issue on a couple of our Essentials servers that this week and never made the connection that Daylight saving hours occurred last weekend. Great info share, thanks again.
Thanks Mark. I noticed this issue on one of my Essentials servers this week and never made the connection about Daylight saving having anything to do with this. Great share, thanks again!
Pingback: Server Essentials 2012 & 2016 Can’t Email Health Reports | techspeeder
Bug still alive! November 2017!
Les, thanks for the reminder. Guess I should just put this in the calendar. One positive note: my new Server 2016 with the Essentials role did _not_ stop sending health reports. However, 2012R2 Essentials machines still break at the time change.
No, thank *you* for the reminder, Mark!. I’d completely forgotten about this, until today. I only have one 2016 with essentials role, and it was affected (as were all older versions). I don’t know why yours wasn’t ;-). Unless it lives in Saskatchewan, that is ;-).
These servers balk at 25 hour days ;-).
Yup, still does it. What a joke.
Still an issue March 2018!
My 2012R2 Essentials machines are still sending reports. Mind you, I’ve kept them at .NET 4.5.2, as described here: https://www.mcbsys.com/blog/2018/02/essentials-2012-r2-dashboard-fails-with-net-4-6-and-4-7/. But I don’t think I’ve ever had a problem in the spring, when the clocks move forward. It’s in the fall, when they move back, that I see this issue.
Hmm..I will have to look. Our server started failing over the weekend, I will head this up more in the AM.
Nov 2019!. Restart the service.
Just checking in ;-).
Yep, I’m now putting this in my calendar. Next switch : Nov. 3, 2019.
Just been very grateful for this bit of knowledge.
All our client servers have failed, 2012 Essentials, 2016 Essentials and also any standard servers running the Essentials experience.
Wh has this not been addressed by Microsoft in the last 5 years?
This will work from the command prompt (run as administrator) for the task:-
net stop ServiceProviderRegistry && net start ServiceProviderRegistry && net start WseNtfSvc && net start WseMgmtSvc && net start WseMediaSvc && net start WseHealthSvc
First time this has been an issue for me in several years of WSE. I had two machines affected of about 6 I manage – 1 WSE 2012R2, one my own WSE 2016 VM. They both had the spurious attempt to send logs at 1AM day of DST change, and then were unable to send. I rebooted mine and also cleared the C:\ProgramData\Microsoft\Windows Server\Data\settingsproviderdata\HEALTHREPORT directory per another post by Susan Bradley. On the WSE 2012R2 machine I just restarted the email and management services. I had to reconfigure email reports after that, but both machines are now sending reports correctly.
November 2020 – WSE 2016, no health reports!. Restart service :-).
As much as the IT landscape changes (esp. MS), some things stay the same :-).
November 2021 – WSE 2016. same problem, Restart service, it works.
7 years still not fix…
I have the Cannot Send Email issue on my WSEE 2016 and have restarted the Management Service dozens of times. The Error: SMTP server cannot perform the operation. Verify the settings for the SMTP server, then try again. Mailbox is unavailable. The server response was 5.1.0 Authentication failed.
No settings have changed and the Management Service is running. No settings have changed; just the end of daylight savings. How do I verify the SMTP settings beyond the dialog box of userid and password and the two boxes checked (SSL/TLS and Authentication)?
@Kurt, I wonder if you’re (coincidentally) hitting some restrictions on SMTP authentication protocols. I don’t think WSE supports modern authentication (where it pops up a little browser window to let you sign in). So if you’re using Gmail, you’d have to turn on “Allow Less Secure Apps” (https://myaccount.google.com/lesssecureapps). Or if you have 2FA enabled on the email account, you may need to set up and use an app password. You might be able to test it independently by manually setting up the account in Outlook or another email program. Another option I have used sometimes is to set up an SMTP relay service, then send through that. I wrote that up in 2014; don’t know if it’s still accurate: https://www.mcbsys.com/blog/2014/10/smtp-smarthost-to-office-365-and-gmail/.
After reviewing the manual steps, i got lucky and found this that does it all in seconds – I ran the powershell script found here:
https://www.hass.de/content/setup-microsoft-windows-or-iis-ssl-perfect-forward-secrecy-and-tls-12
run the test from here, before and after:
https://www.ssllabs.com/ssltest/
Hope it works for you.
@Les, are you saying the SSL level affects the ability to send emails? I’ve been upgrading TLS on servers (and clients) for security reasons. I found the Nartac GUI to be helpful as well (https://www.nartac.com/Products/IISCrypto/Download). Seems like I had to briefly disable the upgrade to renew my remotewebaccess.com certificate…
When it’s the time change issue, you see this: Error: The Windows Server Essentials Management Service is not running. But I was getting this one: Error: Cannot reach the SMTP server. Authentication failed because the remote party has closed the transport stream.
I just assumed, because I was sending health reports through smtp.office365.com, that it was a TLS issue. I upped the .net version, and then ran the script to configure TLS. Whether it was coincidence or not, that did solve the problem of the authentication failed error that was present for 4 days running.
Other than than, I dunno. I’m retired so not paying much attention these days, unless something stops working. I only see one server now, my own ;-/.
The authentication error might in fact be a code issue with the essentials application that is sending the email, not using tls 1.2. If that’s the case, come january (I believe) then the health reports will no longer be able to be sent directly to a 365 account natively. We’ll know soon enough ;-). The chances of MS updating the code are zero, so I’ve heard.
I have had the Management Service restart issue ever since WS 2016 Essentials was installed. I’m not a “power user” and typically don’t mess with settings. The Health Report “Cannot send email” errors have always been fixed by restarting the Management Service; up until this last time change on 11-7 when I received the authentication error stated in my original post. I have always used my primary “@comcast.net” email address as the sending account. However, I fixed this issue by using a secondary address (under the primary account) “@comcast.net” email address and changing the userid and password to use that account. The health report email, so far, appears to send without error. This change makes no sense to me as the SMTP authentication should be the same for all Comcast email. Or, rhetorically, is the secondary account verified differently?
@Kurt, maybe the primary Comcast account has 2FA (like it sends a text or email back to confirm login) but the secondary ones do not?
@Mark, 2FA was the issue. I checked my Comcast primary account and 2FA was “on”. I turned it off and now the primary account works as the sending account. Not sure why the time change broke the authentication. I guess Comcast no longer sees Windows Server 2016 Essentials Experience as a recognized app as it does not (and never will) support 2FA.
@Kurt, good to know. If you have the option, I’d leave 2FA enabled on your primary account and use a secondary account for basic SMTP. That makes it less likely that the primary will get hacked and if the secondary is hacked, you can use the primary to reset it.