Unless extremely accurate timekeeping is mission-critical for you there should be no discernible effect for your users, aside from their clocks changing by 2 minutes.
The possible exception is if they declare your NTP server to be "insane" as a result of the large change (which would require you to restart the NTP service on the affected systems to force them to sync the clock - though you can do this without an outage).
While you're fixing this here are a few other pointers:
You should configure your systems that look at external NTP sources to look at several (4-5) servers from the public NTP pool project -- preferably geographically appropriate ones.
Having more NTP servers allows the selection algorithm to ignore ones that break/go insane and keep your clock accurate.
In a configuration like yours I would point Core Router 1
and Core Router 2
at external clock sources (not each other).
This gives you two independently-synchronized clocks which should be within a few ms of each other, but if one of your routers goes insane it can't hurt the other one.
In a configuration like yours I would point the domain controllers at BOTH core routers (again to protect against one going down).
If you want to protect against a clock going insane you should add a third authoritative NTP server (or list one of your routers twice and hope it's not the one that loses its mind…)
This is what I ended up doing and what I assume is sound:
Hyper-V host (physical server) is set to synchronize against a selection of time servers and each Hyper-V guest is set to synchronize against the host alone. The changes below are differences from default.
Host setup
First stop the time service with:
net stop w32time
Registry changes (base HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\
):
w32time\Config\AnnounceFlags
= 10
w32time\Parameters\NtpServers
= 0.dk.pool.ntp.org,0x1 1.dk.pool.ntp.org,0x1 2.dk.pool.ntp.org,0x1 3.dk.pool.ntp.org,0x1
w32time\TimeProviders\NtpClient\SpecialPollInterval
= 900
(15 minutes)
w32time\TimeProviders\NtpServer\Enabled
= 1
Some use AnnounceFlags=5 but the correlation with a domain controller (which is not setup in this case) causes the ntp server to not announce itself (observation; not fact) hence AnnounceFlags is set to 10 (more on AnnounceFlags)
0x1 on the ntpservers = use special poll interval (instead of standard ntp poll intervals). (more on 0x1, 0x2, 0x4 and 0x8). Using SpecialPollInterval is not required, but it seems to be recommended (perhaps mostly for guests and not so much for hosts). If you decide not to use SpecialPollInterval, you have to limit MinPollInterval and MaxPollInterval instead. Their defaults are 10 (1024 seconds) and 15 (32768 seconds); I suggest 6 (64 seconds) and 10 (1024 seconds)) instead.
Make sure the time service is started when the server has network connection:
sc triggerinfo w32time start/networkon stop/networkoff
The default is to start (and stop) the time service with the domain controller (which is not present in this setup). Forgetting this step will stop your time server on every boot (shortly after it is started automatically). This problem was a difficult one to track.
And start the service again:
net start w32time
Now the host will poll one of the ntp time servers every 15 minutes and offer to be a ntp server for other clients. I have firewalled udp:123 to make sure only the guests are allowed in.
The server may take up to 15 minutes (SpecialPollInterval) until it announces its capabilities as a reliable time server to the world (guests). This means the guests may be free-running for 15-20 minutes after start of the service.
Guest setup
The guests drift (much) more than the host (also compared to each other) and require a relatively short poll interval. Due to this, using remote ntp servers is not ideal and as we have a reliable ntp server at hand (just configured), we are going to use this (and only this). The guests can all access the host using a virtual network.
Make sure the Hyper-V Time Integration service is installed and running. With this setup, it will be used when the virtual server is booted but also when resuming from save. It will not be used as a time source.
Stop the time service with:
net stop w32time
Make the necessary registry changes (base HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\
):
w32time\Config\AnnounceFlags
= 10
w32time\Parameters\NtpServers
= 192.168.0.100,0x9
w32time\TimeProviders\NtpClient\SpecialPollInterval
= 300
(5 minutes)
w32time\TimeProviders\NtpServer\Enabled
= 0
w32time\TimeProviders\VMICTimeProvider\Enabled
= 0
Make sure the time service is started when the server has network connection:
sc triggerinfo w32time start/networkon stop/networkoff
And start the service again:
net start w32time
Conclusion
With this setup, time should be in good control on both the host and the guests.
Best Answer
Have you configured the 2811 as an external time source for the DC?