Troubleshooting Windows Time Service: Settings Not Saving on Windows Server?

Updated: 06 Jul, 2025 • 0 • min read

Table of Contents

This article outlines a specific problem where the settings configured for the Windows Time service (W32Time) are not retained in the system registry after performing an in-place operating system upgrade to Windows Server 2016 or Windows 10 Version 1607. This can lead to significant time synchronization issues within a network, particularly in Active Directory domains.

When an in-place upgrade is conducted using certain operating system paths, the Windows Time service configuration does not persist through the upgrade process. Instead, the service reverts to its default configuration, which is typically set up for a workgroup server or workstation environment. This default state is not suitable for domain environments, especially for critical roles like Domain Controllers.

The following table illustrates the specific upgrade paths known to be affected by this issue:

Upgrade From	Upgrade To
Windows Server 2012 or Windows Server 2012 R2	Windows Server 2016
Windows 7, Windows 8, or Windows 8.1	Windows 10 Version 1607

Windows Time Service Issue

Symptoms¶

Following the completion of an in-place upgrade on the affected operating system paths, several roles relying on the Windows Time service may experience configuration loss and synchronization problems. The W32Time service will lose its previously configured settings, such as external time sources or hierarchical synchronization methods.

Affected Roles¶

Different server and client roles within a network infrastructure rely on accurate time synchronization for various critical functions. When the Windows Time service configuration is lost or reset, these roles are directly impacted. Understanding the specific effects on each role is crucial for diagnosing and addressing the problem effectively.

Domain Controllers¶

Domain Controllers (DCs) play a pivotal role in maintaining time synchronization within an Active Directory domain. The DC holding the Primary Domain Controller (PDC) emulator Flexible Single Master Operations (FSMO) role is the designated authoritative time server for the entire domain. This PDC emulator is typically configured to synchronize its time with a highly accurate external time source, such as a reliable NTP server on the internet or a dedicated hardware time source. All other DCs in the domain are configured to synchronize their time with the PDC emulator, forming a synchronization hierarchy.

After an affected in-place upgrade, the PDC emulator DC loses its configuration to sync with the external time source. It also ceases to advertise itself as a time server to other domain members and DCs. This break in the synchronization chain prevents other DCs from syncing with the PDC emulator using the domain hierarchy. Consequently, these other DCs may also stop advertising themselves as time servers and will lose their configured sync partners, potentially leading to time drift across the domain.

You might observe a warning message in the DCDIAG output indicating that a DC is not advertising its time service capability. This warning is a direct indicator that the DC is not functioning correctly as a time source for the domain hierarchy.

Warning: <DCNAME> is not advertising as a time server

Furthermore, the affected DCs may fail to respond to Network Time Protocol (NTP) client requests. You can verify this behavior by using the w32tm.exe /stripchart tool, which attempts to track time synchronization with a specified time server. An unsuccessful attempt will result in error messages indicating that the time server is unreachable or not responding as expected.

c:>w32tm /stripchart /computer: <DCName>
Tracking <DCName> [10.1.1.100:123].
The current time is 10/28/2016 9:00:00 AM.
09:00:00 error: 0x800705B4: The operation timed out

This lack of response confirms that the Windows Time service on the DC is either not running correctly or is not configured to serve time, disrupting the time synchronization for the entire domain.

Domain Members¶

Domain member servers and workstations that undergo the affected in-place upgrade also lose their domain time synchronization configuration. By default, domain-joined machines are configured to synchronize their time using the Active Directory domain hierarchy, typically pointing to their authenticating domain controller.

However, after the upgrade, these member computers revert to their default workgroup time synchronization settings. This default configuration instructs the Windows Time service to synchronize with the time.windows.com website. This change bypasses the domain’s established time hierarchy and can lead to inconsistencies. While syncing with an external source is generally acceptable for individual workstations, it is problematic for domain servers and can potentially cause time drift between domain members and domain controllers, which is critical for Kerberos authentication.

Kerberos authentication, heavily used in Active Directory, requires that the time difference between the client and the server is within a small, predefined tolerance (typically 5 minutes). If domain members sync with an external source and DCs sync via the domain hierarchy (even if functional), minor discrepancies can accumulate, leading to authentication failures, login problems, and issues with group policy processing or resource access.

Authoritative Time Server¶

Windows computers that were manually configured to act as an authoritative NTP server for other devices (even outside a domain context) also lose their custom configuration after the in-place upgrade. This could include servers providing time to network devices, other servers, or clients that are not domain-joined.

When these authoritative time servers revert to default settings, they stop serving time to their configured clients. Devices relying on these servers for synchronization will either fail to synchronize or fall back to their own default configurations, which might be time.windows.com or no synchronization at all. This can lead to time drift across the network segments that were previously relying on this server as their primary time source.

Similar to DCs, you can use the w32tm.exe /stripchart tool to test the availability of these manually configured authoritative time servers. If the server is affected by the upgrade issue, the tool will likely report timeout errors or other failures, indicating it is not responding to NTP requests.

c:>w32tm /stripchart /computer:<myAuthoritativeTimeServer>
Tracking <myAuthoritativeTimeServer> [10.1.1.100:123].
The current time is <DateTime>.
<DateTime> error: 0x800705B4: The operation timed out

The loss of configuration on these various roles highlights the widespread impact of this upgrade issue on network time synchronization. Accurate and consistent time is fundamental for logging, security auditing, distributed applications, and overall network stability.

Cause¶

The root cause of this issue lies within the in-place upgrade process for the specific operating system versions mentioned. During the upgrade from Windows Server 2012/2012 R2 to Windows Server 2016, or from Windows ⅞/8.1 to Windows 10 Version 1607, the registry values associated with the Windows Time service (W32Time) are not correctly preserved.

The Windows Time service stores its configuration settings primarily under the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\. This key contains subkeys and values defining parameters like the time source (NTP server, domain hierarchy), polling intervals, logging settings, and the enabled time providers.

When the upgrade occurs, these specific registry keys and values are reset or replaced with the default settings appropriate for a clean installation on a workgroup member server or a standalone computer. This effectively overwrites any custom configurations that were previously in place, leading to the symptoms described, regardless of whether the computer was a domain controller, a domain member configured as an authoritative source, or a standard domain member. The service state and startup type might remain configured (e.g., Automatic), but its operational parameters are lost, causing it to function in the default, usually unsuitable, mode for its actual role in the network.

Workaround¶

Several methods can be employed to address the issue of Windows Time service settings not being preserved after an in-place upgrade. These workarounds involve restoring or reconfiguring the W32Time service to function correctly based on its intended role within the network.

Note: On Domain Controllers and domain-joined computers, the Netlogon service must be running before the W32time service can successfully start and operate in domain-specific modes (like NT5DS). After the upgrade, ensure that the Netlogon service is started before attempting any of the following workarounds.

To restore proper Windows Time service functionality, choose one of the following methods:

Method 1¶

This method involves manually backing up the Windows Time service configuration registry key before performing the in-place upgrade and then restoring it after the upgrade is complete. This approach preserves the exact configuration that was in place prior to the upgrade, including any custom settings.

Before the Upgrade:

Open the Run dialog box by pressing the Windows logo key‌+R.
Type regedit and press Enter to open the Registry Editor.
Navigate to and select the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\
With the W32Time key selected, go to the File menu and select Export.
In the Export Registry File dialog box, choose a safe location to save the backup file (e.g., a network share, external drive, or a different partition that won’t be affected by the upgrade). Provide a meaningful name for the file, such as W32Time_Backup_PreUpgrade.reg.
Ensure “Export range” is set to “Selected branch” and click Save.
For documentation and validation, save the current W32Time configuration to a text file. Open an elevated Command Prompt (Run as administrator) and run the following commands:
```
Net start w32time
w32tm /query /configuration /verbose > PreUpgradeW32timeConfiguration.txt
```
This command starts the service (if stopped) and exports its detailed configuration, which can be useful for comparison later. Save this text file in the same safe location as the registry backup.

After successfully backing up the configuration, you can proceed with the in-place upgrade to Windows Server 2016 or Windows 10 Version 1607.

After the Upgrade:

Once the upgrade is complete and you have logged into the upgraded operating system:

Open the Run dialog box by pressing the Windows logo key‌+R.
Type regedit and press Enter to open the Registry Editor.
In Registry Editor, go to the File menu and select Import.
In the Import Registry File dialog box, browse to the location where you saved the backup file (W32Time_Backup_PreUpgrade.reg), select the file, and click Open. Confirm any prompts about adding information to the registry.
Close Registry Editor.
Some specific triggers for the W32Time service might be deprecated or need removal after the upgrade. Run the following command at an elevated command prompt to remove a known deprecated trigger:
```
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TriggerInfo\1 /f
```
This command forcefully deletes the specified registry key, which can prevent issues with service startup or behavior post-import.
7. Restart the W32Time service to load the newly imported configuration settings. Open an elevated Command Prompt and run:
```
net stop w32time

net start w32time
```
These commands stop the service and then start it again, forcing it to read the configuration from the registry, which now contains your pre-upgrade settings.

Method 2¶

If you did not back up the configuration beforehand or prefer to reset the service to its default settings based on the current operating system and role (e.g., set a DC back to NT5DS mode), you can reregister the w32tm.exe executable. This process reinstalls the Windows Time service and restores its default parameters appropriate for the detected role of the machine.

Note: This procedure does not restore any manual customizations you might have made to the W32Time configuration (e.g., specific external NTP servers for a PDC emulator, or specific poll intervals). It resets the configuration to the Windows default state for a machine of that role (standalone, domain member, or domain controller).

To reregister w32tm.exe, open an elevated Command Prompt and execute the following sequence of commands:

net stop w32time

w32tm.exe /unregister

w32tm.exe /register

net start w32time

net stop w32time: This stops the currently running Windows Time service.
w32tm.exe /unregister: This command unregisters the Windows Time service executable, essentially removing its service entry from the system.
w32tm.exe /register: This command registers the w32tm.exe executable again, creating a new service entry and populating the W32Time registry keys with default values based on the current operating system version and whether the machine is domain-joined. For a DC, this will typically set it back to NT5DS mode, synchronizing with the domain hierarchy or its configured source.
net start w32time: This command starts the newly registered Windows Time service, applying the default configuration.

After running these commands, the W32Time service should be running with default settings. For a DC, this usually means it will attempt to find its time source via the domain hierarchy (typically the PDC emulator) or fallback mechanisms. If it’s the PDC emulator, you may still need to manually configure an external time source using w32tm /config commands.

Method 3¶

This method is more advanced and involves extracting the W32Time registry configuration from the Windows.old folder, which contains the files from the previous operating system installation, and then importing it into the current system while in the Windows Recovery Environment. This method is useful if Method 1 was not performed before the upgrade but the upgrade created a Windows.old folder.

Important: This procedure is complex and should only be attempted by experienced users comfortable with registry manipulation in a recovery environment. Incorrect steps could lead to system instability.

Export the registry key from the Windows.old folder:
a. Open the Windows Run dialog box (Windows logo key‌+R).
b. Type regedit and press Enter.
c. In Registry Editor, select HKEY_LOCAL_MACHINE.
d. Go to the File menu and click Load Hive….
e. Browse to the location of the old system hive file, typically located at C:\Windows.old\Windows\System32\Config\System. Select this file and click Open.
f. In the Load Hive dialog box, you will be asked to provide a name for the hive. Type Offline and click OK. This loads the System hive from the Windows.old folder under the HKEY_LOCAL_MACHINE\Offline key.
g. Expand HKEY_LOCAL_MACHINE\Offline.
h. Navigate to and select the following registry subkey within the loaded hive: ControlSet001\Services\W32Time\ (The exact ControlSet number might vary, but ControlSet001 or ControlSet002 are common; choose the one that looks most recent or corresponds to the default boot configuration).
i. With the W32Time key selected under HKEY_LOCAL_MACHINE\Offline, go to the File menu and select Export.
j. In the Export Registry File dialog box, choose a location on a local drive (ensure it’s accessible after restarting into recovery mode, like the root of C: or a dedicated recovery partition if available) and type a file name (e.g., W32Time_Old.reg). Click Save.
k. Navigate back to HKEY_LOCAL_MACHINE\Offline.
l. With the Offline hive selected, go to the File menu and click Unload Hive…. Confirm by clicking Yes in the confirmation dialog box. This unloads the System hive from Windows.old.
m. Exit Registry Editor.
Restart the computer in Recovery mode:
a. Select Start > Settings > Update & Security > Recovery.
b. Under the Advanced startup section on the right-hand pane, click Restart now.
c. The computer will restart into the Windows Recovery Environment. From the options presented, select Troubleshoot, and then select Command Prompt.
d. You may be prompted to select a local administrator user account and enter its password to continue to the command prompt.

Note: This step restarts the computer into a minimal environment where you can access a command prompt, necessary for manipulating system files or the registry of the main Windows installation when it’s offline.
Import the saved registry key from step 1:
a. At the Command Prompt window that opens in the Recovery Environment, type regedit and press Enter to open Registry Editor.
b. In this instance of Registry Editor, select HKEY_LOCAL_MACHINE.
c. Go to the File menu and click Load Hive….
d. Browse to the location of the current system hive file, which is typically C:\Windows\System32\Config\System. Select this file and click Open. Note: The drive letter for your main Windows installation might be different in the recovery environment (e.g., D:). You may need to use dir command to find the correct drive letter.
e. In the Load Hive dialog box, type Offline (or any temporary name) and click OK. This loads the current system hive.
f. Expand HKEY_LOCAL_MACHINE\Offline.
g. Navigate to and select the following registry subkey within this loaded hive: ControlSet001\Services\W32Time\ (Again, verify the correct ControlSet number).
h. Go to the File menu and click Import.
i. In the Import Registry File dialog box, browse to the location where you saved the W32Time_Old.reg file from step 1 (e.g., C:\W32Time_Old.reg). Select the file and click Open. Confirm any prompts. This imports the old W32Time configuration into the current system hive.
j. Navigate back to HKEY_LOCAL_MACHINE\Offline.
k. With the Offline hive selected, go to the File menu and click Unload Hive…. Confirm by clicking Yes.
l. Close Registry Editor.
m. At the Command Prompt, type exit and press Enter.
n. Continue the process to exit the Recovery Environment and restart the computer in Normal mode (e.g., select “Continue to Windows”).

After the computer restarts into normal mode, the W32Time service should be configured with the settings from the previous installation. You may still need to restart the W32Time service (using net stop w32time and net start w32time) and potentially remove the deprecated trigger mentioned in Method 1 if issues persist.

Verify the Workaround Results¶

After applying one of the workarounds, it is important to verify that the Windows Time service is now configured correctly and functioning as expected for its role.

For Domain Controllers: Run DCDiag.exe on the DCs. Check the output to ensure that they are now advertising as a time server, resolving the warning seen previously.
For DCs and Authoritative NTP Servers: Verify that the affected servers are responding correctly to NTP client requests. Use the w32tm.exe /stripchart tool from another computer that should be synchronizing with this server. A successful test will show time synchronization data with timestamps and offsets, rather than errors.
```
c:\>w32tm /stripchart /computer:<myTimeServer>
Tracking <myTimeServer> [10.1.1.100:123].
The current time is <DateTime>.
<DateTime> d:+00.0013494s o:-00.0891868s [ * ]
```
The [ * ] or similar indicators show successful synchronization attempts.
3. For Advanced Verification: Query the detailed configuration of the W32Time service using w32tm /query /configuration /verbose. Compare this output to the configuration you expected or, if you used Method 1, compare it to the PreUpgradeW32timeConfiguration.txt file you saved. This allows you to confirm that the service is using the correct time source (e.g., NT5DS for a domain member/DC, or a specific NTP server), appropriate polling intervals, and enabled providers.
```
c:\> w32tm /query /configuration /verbose > PostUpgradeW32timeConfiguration.txt
```
Analyze the generated text file to ensure settings like NtpServer, Type, AnnounceFlags, and other relevant parameters match your requirements.

By performing these verification steps, you can confirm that the chosen workaround has successfully resolved the time synchronization issues caused by the in-place upgrade. Maintaining accurate and synchronized time is vital for the health and security of your Windows environment.

Have you encountered this issue after upgrading Windows Server or Windows 10? Which workaround did you use, and was it effective? Share your experience in the comments below!

Computacionvinchi