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.
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
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
For Windows 2000: Tardis 2000. Works nicely, comes with a control panel. If you use this, be sure to turn off Windows Time Service.
For Windows 2003/2008: Already mentioned in other answers in this question. Alternatively, you can run Tardis 2000 on a 2k3 box, I don't know if it works on 2k8.
For any Windows workstation: run the following command at login: net time /domain:your-domain-here
For all NTP services:
Point your service at pool.ntp.org, although you'll want to at least narrow it down to the same continent. For example, US servers would use 0.us.pool.ntp.org, 1.us.pool.ntp.org, 2.us.pool.ntp.org, etc.
As many have answered, NTP is the way to go. Depending on your needs and requirements, there are several possible designs that you can use for syncing time.
Sync individual machines to public host i.e. pool.ntp.org
Designate a local master (with upstream NTP) and sync everything else to it
Local master with your own GPS hw attached (could be $$$)
If you have many machines, options 2 and 3 are a lot friendlier to the network. For more details, read about NTP and clock strata.
Additionally, I find that the Windows default interval for synchronization is too long (once a week) which leads to too much drift. You should check out the following if you want to set things to a shorter period (I use once a day).
A good NTP server, mainly. Set it up so that the clock hasn't drifted more than a few seconds since the last NTP sync and you shouldn't have any problems.
If your server is drifting more than a 30 seconds per day, you might want to look at better alternatives, but the clocks inside most computers are generally much better than 30 seconds per day, so one sync per day is usually fine.
BE AWARE that you might skip minutes if you set it up to synch periodically (ntpdate), and don't use the NTP daemon (ntpd) - if you are behind 3 seconds, and the NTP sync attempts an update at 10 minutes 58 seconds, it'll skip to 11 minutes 1 second, and depending on the scheduler you're using, it may not trigger the 11 minute tasks.
The NTP daemon runs in the background and fixes the time slowly so programs and processes notice time may be going slightly more quickly or slowly than usual, but it won't skip second.
A NTP server it is what's needed to keep time synchronized on your DC, yes. Read this article for instructions on how to synchronize your DC with an external source, and this knowledge base article on how to configure an authoritative time server with Windows 2003. You will need both to keep your domain time synchronized. Workstations joined to the domain, will automatically synchronize with the authoritative time server.
Use a common clock source for all your servers and make sure your time zones are setup correctly. A good Internet source is "time.windows.com". If you are using Windows, you can use "net time" and "w32tm" for time related commands.
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.
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:
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
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
Use NTP daemon.
NTP is your friend.
RHEL/CentOS:
Debian/Ubuntu:
Windows:
net time /domain:your-domain-hereFor all NTP services:
Point your service at pool.ntp.org, although you'll want to at least narrow it down to the same continent. For example, US servers would use 0.us.pool.ntp.org, 1.us.pool.ntp.org, 2.us.pool.ntp.org, etc.
As many have answered, NTP is the way to go. Depending on your needs and requirements, there are several possible designs that you can use for syncing time.
If you have many machines, options 2 and 3 are a lot friendlier to the network. For more details, read about NTP and clock strata.
Additionally, I find that the Windows default interval for synchronization is too long (once a week) which leads to too much drift. You should check out the following if you want to set things to a shorter period (I use once a day).
http://www.softpedia.com/get/System/System-Miscellaneous/Internet-Time-Update.shtml http://www.tweakxp.com/article36948.aspx
A good NTP server, mainly. Set it up so that the clock hasn't drifted more than a few seconds since the last NTP sync and you shouldn't have any problems.
If your server is drifting more than a 30 seconds per day, you might want to look at better alternatives, but the clocks inside most computers are generally much better than 30 seconds per day, so one sync per day is usually fine.
BE AWARE that you might skip minutes if you set it up to synch periodically (ntpdate), and don't use the NTP daemon (ntpd) - if you are behind 3 seconds, and the NTP sync attempts an update at 10 minutes 58 seconds, it'll skip to 11 minutes 1 second, and depending on the scheduler you're using, it may not trigger the 11 minute tasks.
The NTP daemon runs in the background and fixes the time slowly so programs and processes notice time may be going slightly more quickly or slowly than usual, but it won't skip second.
-Adam
A NTP server it is what's needed to keep time synchronized on your DC, yes. Read this article for instructions on how to synchronize your DC with an external source, and this knowledge base article on how to configure an authoritative time server with Windows 2003. You will need both to keep your domain time synchronized. Workstations joined to the domain, will automatically synchronize with the authoritative time server.
Use a common clock source for all your servers and make sure your time zones are setup correctly. A good Internet source is "time.windows.com". If you are using Windows, you can use "net time" and "w32tm" for time related commands.