Windows time service sync to external ntp servers only if they coincide

I recently had a problem which I've never seen occur before. One evening around 2030 one of the DC's changed its clock back an hour. This server syncs to two addresses in pool.ntp.org. Nobody was present when this occured and the event logs clearly show time-service syncing against a public ip.

I can only assume that we hit a server which was incorrecly configured because, after the chaos the following morning caused by the building management systems having the wrong time, I simply resynced the ntp server and it immediately corrected its clock.

I normally have ntp configured to use two different ntp servers so I assume that the client only connects to the first one which responds and just assumes that it will supply the correct time.

so, my question:

Is there any way to configure the windows time service so that it will only correct its clock after consulting two different ntp servers and they both coincide as to the correct time? I'm running Win2019

Edit: I hadn't known it was possible to do historical querying on ntp results(thanks Paul Gear). Querying for the two IP's I had configured s shows the cause of my problem:

1623189765,"2021-06-08 22:02:45",-0.003809235,1,13.2,,,0,
1623188607,"2021-06-08 21:43:27",6.1543e-05,1,12.8,6,"Newark, NJ, US",0,
1623188607,"2021-06-08 21:43:27",6.1543e-05,1,12.8,,,0,
1623187438,"2021-06-08 21:23:58",0.011513196,1,12.4,6,"Newark, NJ, US",0,

The middle line there indicates a huge variation from the server I was using.

Not to disagree too much with John Mahowald, but snce Windows 2016 at least, Windows Time Service has been much improved, including a full NTP service. They also have a document explaining how to configure Windows for high accuracy. I don't think there's any need to run a separate non-Windows NTP server unless you have extremely high precision requirements (in which case, you'd probably use PTP instead - there's even support for that in Windows 2019).

So most likely, you have just run up against an inaccurate pool server. This happens from time to time, and the pool is very good at removing these servers quickly. If you have a record of the IP address of the server it was syncing to, you can look up its history at https://www.ntppool.org/scores/<IP_ADDRESS>.

I think it's probable that because the system in question was still responding, it was selected because you have too few peers configured (see also the following section in RFC8633 about having a diversity of reference clocks), and Windows Time Service didn't need to re-query the pool for a new IP because the original server was still responding.

So the most important thing you can do to prevent this from reoccurring is, as John said, add more time sources. More sources from the pool is fine, and if you want something outside the pool which has pretty stable IPs and offers a reasonably accurate service, try time.apple.com, which appears to be a Geo-DNS pool of globally-distributed stratum 1 servers.