Solution 1:

The Network Time Protocol, or NTP, can be used to synchronize the time on a server with an authoritative source. Windows Servers, for example, will use one of the network domain controllers (the DC which holds the PDC emulator FSMO role for the domain [thanks Graeme]) to get time information. You can configure the domain controller to get information from some known source, such as time.windows.com.

Solution 2:

And to represent the Virtual Machine crowd...

If you're running virtual servers, time drift seems to be a common problem - and so there's usually a way (other than NTP) to keep the VM's in sync with their host.

In my case, I am using VMWare. I can turn this on from a linux Virtual Machine by using:

vmware-guestd --cmd "vmx.set_option synctime 0 1"

And from a Windows Virtual machine you can open the vmware-tools icon from the system tray, and select time synchronization between the virtual machine and the host OS

Solution 3:

VMwareTools SyncTime is not a good option for virtual machines on ESX! VMware itself has altered their recommendations for timekeeping in VM's to using NTP instead of vmware-tools if you experience problems.

I talked about this to an engineer from VMware at VMworld once and was told vmware-tools was never designed to do the job it is doing now. In the old days, lost interrupts was a big problem. Today much less. This is the reason why vmware-tools is able to correct your machine time if the machine is behind, but not when the machine is ahead. In fact, once the machine goes ahead of 'real' time, you're pretty much screwed if you use vmware-tools to do timekeeping.

Better still: when using ntp, the process that corrects your time actually wakes up less often compared to using vmware-tools. So for virtual machines ntp will provide less overhead instead of more.

Therefore, for Linux you should always use ntp in VMware virtual machines. Disable vmware-tools synctime completely.

For Windows VM's on Vmware, I'm less sure, but I think it is pretty much the same. Use the built-in time synchronization stuff in AD, which works better than VMware SyncTime. (Even though AD time synchronization sucks pretty bad by itself; it's sole reason for existence is to keep Windows boxen in sync with their domain controllers and Kerberos will still work as long as the clock difference is less than about 5 minutes, so there is much less need for accuracy.)

You can read about VMware time synchronization on Linux a bit more here