Has your Windows Server stopped working even when you thought everything was configured correctly? If so, the problem...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
may have been related to the server clock. And while it may seem minor, a deficient server clock can threaten your entire operating system.
Some of the problems that can occur when server clocks fall out of sync include:
- Network authentication failure
- Communication issues with System Center Data Protection Manager agents
- Exchange Server, ActiveSync and Outlook Web Access (OWA) unavailability
In many cases, server time sync issues stem from the Kerberos protocol, which has a security feature that looks at the time stamp on Kerberos tickets in an effort to prevent them from being reused. A ticket is rejected if it is more than five minutes old. Therefore, if the clocks fall out of sync by more than five minutes, Kerberos will begin to break down.
Normally, time synchronization doesn’t pose a problem. For instance, when Windows is operating in an Active Directory (AD) environment, all of the computer clocks in the domain are automatically synchronized with a domain controller. However, clock synchronization can become an issue in environments where there is a mixture of domain members and workgroup members, or multiple Active Directory forests exist.
To give you a more concrete example, all of the production servers in my own network are virtualized. Because of this, none of my virtualization host servers are domain members and all of the domain controllers are virtual machines (VMs). This eliminates a situation in which a host server can’t communicate with domain controllers because the VMs have not yet been started. As such, I chose to make the host operating systems members of a workgroup.
Additionally, all of my virtualization hosts run Hyper-V on top of Windows Server 2008 R2. Some of these servers host VMs that are running Windows 2008 R2, while others host VMs that are still running Windows Server 2003. But although the Windows 2008 R2 guest machines seem to stay in sync with the host server’s clock, the Windows 2003 machines have a tendency to fall out of sync with the rest of the network.
So how do you fix this problem? Well, the solution varies depending on whether or not the computer is a domain member. In either case, however, you will need to designate a server as a time source. This can be a server on your network or you can synchronize the time from the National Institute of Standards and Technology (NIST) atomic clock.
In a workgroup environment you can link the machine to a time source by opening a Command Prompt window and entering the following commands:
W32tm /config /syncfromflags:manual /manualpeerlist: <time source> W32tm /config /update
In this example, you would replace <time source> with the fully qualified domain name (FQDN) or the IP address of the server that you want to sync with. You can specify multiple time sources by separating each one with a space.
In domain environments you are better off using Group Policy settings to specify a time source. The clock-related Group Policy settings can be found in the Group Policy Editor at: Computer Settings | Administrative Templates | System | Windows Time Service.
There are three different group policy settings that you can use, including:
Configure Windows NTP Client -- allows you to sync your computer clocks with an external time source.
Enable Windows NTP Client -- allows computers to synchronize their clocks with other Windows servers.
Enable Windows NTP Server -- allows the server to provide time synchronization to Windows NTP clients.
Note that if you are going to synchronize with an external time source, such as NIST, you should not enable the Windows NTP Client or the Windows NTP Server. You may also have to open some firewall ports when using an external time source. Windows servers use UDP port 123 for the time protocol, which should be open by default. If you want to use NIST, however, you will also have to open TCP port 13, TCP port 37 and UDP port 37.
As you can see, it is extremely important to keep Windows Server clocks synchronized with each other. Although clocks usually synchronize automatically, it’s essential to be prepared for situations where you may have to force clock sync manually.
ABOUT THE AUTHOR:
Brien Posey is a seven time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.