Avoid Windows Server server time synchronization issues

Has your Windows Server ever stopped working, even when you think everything is configured correctly? If you have encountered this situation, the problem may be related to the server clock. Although it may seem like a minor issue, the flaws in the server clock can threaten your entire operating system.

Some problems that may occur when the server clock is out of sync include:

- Network Authentication Failure

- Communication Problems with System Center Data Protection Manager (SCDPM) Agents < Br>

- Exchange Server, ActiveSync, and Outlook Web Access (OWA) are not available

In many cases, server time synchronization issues are derived from the Kerberos protocol, which has a security feature specifically for viewing Kerberos tickets. Timestamps, this is mainly to protect them from being reused. If the time on a ticket is now more than five minutes now, the ticket will be rejected. Therefore, if the clock is not synchronized within five minutes, Kerberos will start to fail.

Generally speaking, time synchronization does not cause problems. For example, when Windows is running in an Active Directory (AD) environment, all computer clocks in the domain are automatically synchronized with the domain controller. However, clock synchronization can become an issue in environments where domain members and workgroup members are mixed or multiple active forests exist.

For a more specific example, all production servers in my own network are virtualized. For this reason, there are no domain members in my virtualization host server, and all domain controllers are virtual machines. Since the virtual machine does not start at all, it is impossible for the host server to communicate with the domain controller. As a result, I chose to make the host operating system a member of the workgroup.

In addition, all of my virtualization hosts are running Hyper-V on Windows Server 2008 R2. Some of these servers run Windows 2008 R2 virtual machines, and other clusters still run Windows Server 2003. virtual machine. However, although the guest running Windows 2008 R2 seems to be in sync with the clock of the host server, the machine running Windows 2003 may not be able to synchronize with the rest of the network.

So how do you solve this problem? The solution will vary depending on whether the computer is a domain member or not. But no matter what the situation, you need to specify a server as a source of time. It can be a server on your network or you can synchronize with the National Institute of Standards and Technology (NIST) atomic clock.

In a workgroup environment, you can chain your machine to a time source by opening the Command Prompt window and typing the following command:

W32tm /config /syncfromflags:manual /manualpeerlist: W32tm /config /update

In this example, you can replace the fully qualified domain name (FQDN) with the server IP address you want to keep in sync with. You can specify multiple time sources by isolating each address that has a space.

In a domain environment, it is better to use Group Policy settings to specify a time source. 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 available for you to use, including:

- Configure Windows NTP Client - Allows you to synchronize your computer clock with an external time source.

- Enable Windows NTP Client - Allows the computer to synchronize the clock with other Windows servers.

- Enable Windows NTP Server - Allows the server to provide time synchronization to Windows NTP clients.

Note that if you plan to synchronize with an external time source, such as NIST, you cannot enable the Windows NTP Client or the Windows NTP Server. When using an external time source, you may want to open some firewall ports. The Windows server uses UDP port 123 for the time protocol, which should be turned on by default. But if you want to use NIST, you also need to open TCP port 13, TCP port 37 and UDP port 37.

As you can see, it is important to keep the synchronization between Windows Server clocks. Although the clock is usually automatically synchronized, it is necessary to be prepared to face the need to manually synchronize the clock.