Hi Gabriele! The server should use the OS time and timezone settings, so you should not need to set anything manually. I'm going to do some testing on this scenario and I'll let you know what I find out.

I ran through this under our last dev build and the current release build (to match your testing) but was not able to replicate in the what I believe is the same configuration. Below you'll see the results of the powershell command Get-TimeZone, and the NTP query you ran as well:

The offset on the NTP results looks to be about the same as well, but I don't see this chronic warning you are getting. On that note, I believe Windows uses just the one timezone for CET now and just offsets for daylight savings time. Can you check the Get-TimeZone command results and post here too? Per this list below you are in the W. Europe Standard Time default timezone in Windows:

I had no issues testing under that timezone either. Perhaps we have a locale issue in Windows as well - I can test that next.

Per Microsoft indication, we are in W. Europe Standard Time , maybe not exactly the strictly same of CET:

Strange: the alarm has now stopped appearing...

I don't know...

I'll let you know if it happens again...

Interesting, I wonder if the NTP results were temporarily askew and resolved themselves at some point. Do you see any NTP related errors or warnings in the Event Viewer in Windows?

Currently seeing the same thing right after we log in.... Build 8504.

It started appearing today.

I recommend checking your system time against a valid NTP server from Microsoft, as well as your timezone and other settings. We were not able to reproduce this issue here, and have had no tickets submitted on this.

Kyle, remember when you where working on another ticket for me you brought the 15 second notification to my attention. After re-syncing with the timeserver I still got the message. I had to reboot the server to make it go away. The question to ask is why we never got this message prior to the upgrade to build 8495. 

I am getting this constantly now. Its syncing towards 0.dk.pool.ntp.org and no issues there.

This is frustrating... to say the least.

this could be related to the MAPI issues since when I sync the time and restart outlook, then messages are not stuck in outbox.

I created a task in task scheduler to run every minute syncing the clock on the server.

cmd.exe w32tm /resync /rediscover

And it hasnt given an error message since.

We stopped using the Windows time service a while back, always had issues with it and servers being out 20-30 seconds. Switched to using the Meinberg NTP client with one of their LANTIME rackmount servers and all servers have been extremely accurate for ~10 years.

8504 is throwing the error despite clocks in perfect sync.(at least here).

It hasn't happened to me since the first initial alarms...

It stopped after I synced the server to POOL.NTP.ORG and then restarted the server

Does this issue present itself in the latest build 8510?

Havent had any alarms yet. But running background sync via task scheduler every minute....to avoid it.

Brian, do you mind disabling your workaround to verify fix?

Yup. I'll report back

HAvent seen it since upgrade to 8510. I will keep an eye out for it though since I believe some of the MAPI functionality is relying on a stable NTP function.

8531 just updated getting the error again.