Most people reporting this error are running the AnyWhere Access on Essentials 2016, or possibly 2012, for the first time. However, I have run into this twice in the past few months, rerunning the wizard to renew the public access SSL certificate on older Essentials 2016 servers. Perhaps this is caused by a recent update. Many report waiting a while resolves the issue, but I have not found this to be true.
100% credit for the solution goes to JVH Consulting https://jvhconsulting.com/2022/01/02/2016-essentials-anywhere-access-setup-fails/
JVH advise you need to add 2 registry entries to each of 4 registry keys. NOTE: if you are not familiar with doing so, editing the registry incorrectly can destroy your server. As always, back up the registry before starting.
JVH suggest a reboot may be necessary, but I found simply restarting the Essentials Console was sufficient.
A built in feature of Server Essentials, till 2019, is the ability of the server to send a daily “Health Report”. This contains information about the last backup, storage, services and more. I always configure this on all Essentials servers and set to send at 7:00 am for my review later. On 4 of the Essentials servers I manage it seems on the morning of the Daylight Savings change, at 1:00 am it tried to send a report for some reason, failed, and has failed the 7:00 am report ever since.
Though the error shows the problem is the “Windows Server Essentials Management Service” is not running, checking the Services management console shows it is. Simply restarting the service resolves the problem. You can right click on the last report and choose “send e-mail” to verify.
It seems Server Essentials and possibly others will often show in the daily report a DFSR Event ID: 2147485861 error. There is also a corresponding Warning Event logged in the DFS Replication log (sub-folder of Applications and Services Logs) of the event viewer with Source DFSR and Event ID 2013, followed by an Event ID 2212. This is most often caused by a dirty shutdown.
There are numerous articles on the Internet explaining how to resolve this, but I was told they were not clear to some readers. So, hopefully to clarify:
Firstly open Regedit and locate the key below, and verify it is set to 1. If not change it to 1. (Note: you should always backup the registry before making any changes)
Then in the error message within the report locate the command as highlighted in the image above, but cut and past it from your server report as it will have the correct volume GUID. Make sure it is all one line. You may want to use Notepad to reassemble if broken in the report. You need to use an elevated command prompt to run this.
If you run the command with the wrong GUID it will display; “No Instance(s) Available”.
If successful your command window should look similar to this:
This should resolve the problem, but it may return at some point in the future. The Windows Server 2012 Essentials Build document (wiki article) suggests to prevent this in the future, after running the command successfully, change the aforementioned registry key from 1 to 0. Doing so enables DFS Replication automatic recovery.
I have had a few questions regarding a message “Office 365 authentication did not succeed” suddenly appearing both in the daily reports and the Alert Viewer of Server Essentials. The alert viewer suggests changing the admin account (or refresh it) in the Office 365 tab of the Essentials Dashboard, however doing so fails with a message stating you are using the wrong account or password.
In most cases if you log into the Office 365 site using the domain’s admin e-mail account you will find the password has expired and you are asked to update it. Do so and return to the Dashboard entering the new password which should now allow it to validate and eliminate the error.