-->

1. Open Settings by pressing Win + I on the keyboard. Go to Upgrade & recovery Windows Insider Program. Join the program, if you are not already in, and select the Release Preview channel which will be the only available channel for you. Now, press Win + R and type regedit, and hit the Enter key.
2. For a 32-bit application on a 64-bit operating system, you need to get the content of the registry key HKEYLOCALMACHINE SOFTWARE Wow6432Node Microsoft Windows CurrentVersion Uninstall. If an application was installed for the current user, then you can locate it using the following registry key HKCU Software Microsoft Windows CurrentVersion.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows 10

The Windows Time service (W32Time) synchronizes the date and time for all computers managed by Active Directory Domain Services (AD DS). This article covers the different tools and settings used to manage the Windows Time service.

By default, a computer that is joined to a domain synchronizes time through a domain hierarchy of time sources. However, if a computer has been manually configured to synchronize from a specific time source, perhaps because it was formerly not joined to a domain, you can reconfigure the computer to begin automatically sourcing its time from the domain hierarchy.

Most domain-joined computers have a time client type of NT5DS, which means that they synchronize time from the domain hierarchy. An exception to this is the domain controller, which functions as the primary domain controller (PDC) emulator operations master for the root forest domain. The PDC emulator operations master in turn is usually configured to synchronize time with an external time source.

Wmic csproduct get UUID. That UUID is the best way to ID a machine, it exists in Windows, Mac and many other platforms. It is 32 characters in length, a universally unique identifier. You can run the above wmic command to get it. But wait, that’s not always the case.

You can achieve down to one-millisecond time accuracy in your domain. For more information, see Support boundary for high-accuracy time and see Accurate Time for Windows Server 2016.

Caution

Don't use the Net time command to configure or set a computer's clock time when the Windows Time service is running.

Also, on older computers that run Windows XP or earlier, the Net time /querysntp command displays the name of a Network Time Protocol (NTP) server with which a computer is configured to synchronize, but that NTP server is used only when the computer's time client is configured as NTP or AllSync. This command has since been deprecated.

Network port

The Windows Time service follows the Network Time Protocol (NTP) specification, which requires the use of UDP port 123 for all time synchronization. Whenever the computer synchronizes its clock or provides time to another computer, it happens over UDP port 123. This port is exclusively reserved by the Windows Time service.

Note

If you have a computer with multiple network adapters (is multi-homed), you cannot enable the Windows Time service based on a network adapter.

Using W32tm.exe

You can use the command-line tool W32tm.exe to configure Windows Time service settings and to diagnose computer time problems. W32tm.exe is the preferred command-line tool for configuring, monitoring, and troubleshooting the Windows Time service. W32tm.exe is included with Windows XP and later and Windows Server 2003 and later.

Membership in the local Administrators group is required to run W32tm.exe locally, while membership in the Domain Admins group is required to run W32tm.exe remotely.

Run W32tm.exe

1. In the Windows search bar, enter cmd.
2. Right-click Command Prompt, then select Run as administrator.
3. At the command prompt, enter w32tm followed by the applicable parameter, as described below:

Set client to use two time servers

To set a client computer to point to two different time servers, one named ntpserver.contoso.com and another named clock.adatum.com, type the following command at the command prompt, and then press ENTER:

Set client to sync time automatically from a domain source

To configure a client computer that is currently synchronizing time using a manually-specified computer to synchronize time automatically from the AD domain hierarchy, run the following following:

Check client time configuration

To check a client configuration from a Windows-based client computer that has a host name of contosoW1, run the following command:

The output of this command displays a list of W32time configuration parameters that are set for the client.

Important

Windows Server 2016 has improved the time synchronization algorithms to align with RFC specifications. Therefore, if you want to set the local time client to point to multiple peers, we recommended that you prepare three or more different time servers.

If you have only two time servers, you should specify the NtpserverUseAsFallbackOnly flag (0x2)to de-prioritize one of them. For example, if you want to prioritize ntpserver.contoso.com over clock.adatum.com, run the following command.

Additionally, you can run the following command and read the value of NtpServer in the output:

Configure computer clock reset

In order for W32tm.exe to reset a computer clock, it first checks the offset (CurrentTimeOffset, also known as Phase Offset) between the current time and the computer clock time to determine whether the offset is less than the MaxAllowedPhaseOffset value.

• CurrentTimeOffset < MaxAllowedPhaseOffset: Adjust the computer clock gradually by using the clock rate.
• CurrentTimeOffset ≥ MaxAllowedPhaseOffset: Set the computer clock immediately.

Then, to adjust the computer clock by using the clock rate, W32tm.exe calculates a PhaseCorrection value. This algorithm varies depending on the version of Windows:

• Windows Server 2016 and later versions:

  PhaseCorrection_raw = |CurrentTimeOffset| ÷ (16 × PhaseCorrectRate × pollIntervalInSeconds)
  MaximumCorrection = |CurrentTimeOffset| ÷ (UpdateInterval × 1,000 × 10,000)
  PhaseCorrection = min(PhaseCorrection_raw, MaximumCorrection)

• Windows Server 2012 R2 and earlier versions:

  PhaseCorrection = |CurrentTimeOffset| ÷ (PhaseCorrectRate × UpdateInterval)

All versions of Windows use the same final equation to check PhaseCorrection:

PhaseCorrection ≤ SystemClockRate ÷ 2

Note

• These equations use PhaseCorrectRate, UpdateInterval, MaxAllowedPhaseOffset, and SystemClockRate measured in units of clock ticks. On Windows systems, 1 ms = 10,000 clock ticks.

• MaxAllowedPhaseOffset is configurable in the registry. However, the registry parameter is measured in seconds instead of clock ticks.

• To see the SystemClockRate and pollIntervalInSeconds values (measured in seconds), open a Command Prompt window and then run W32tm /query /status /verbose. This command produces output that resembles the following.
  The output presents the poll interval in both clock ticks and in seconds. The equations use the value measured in seconds (the value in parentheses).
  The output presents the clock rate in seconds. To see the SystemClockRate value in clock ticks, use the following formula:

  (value in seconds) × 1,000 × 10,000

  For example, if SystemClockRate is 0.0156250 seconds, the value that the equation uses is 156,250 clock ticks.For full descriptions of the configurable parameters and their default values, see Config entries later in this article.

The following examples show how to apply these calculations for Windows Server 2012 R2 and earlier versions.

Example: System clock rate off by four minutes

Your computer clock time is 11:05 and the actual current time is 11:09:

PhaseCorrectRate = 1

UpdateInterval = 30,000 clock ticks

SystemClockRate = 156,000 clock ticks

MaxAllowedPhaseOffset = 10 min = 600 seconds = 600 × 1,000 × 10,000 = 6,000,000,000 clock ticks

|CurrentTimeOffset| = 4 min = 4 × 60 × 1,000 × 10,000 = 2,400,000,000 clock ticks

Is CurrentTimeOffset ≤ MaxAllowedPhaseOffset?

2,400,000,000 ≤ 6,000,000,000: TRUE

AND does it satisfy the following equation?

(|CurrentTimeOffset| ÷ (PhaseCorrectRate × UpdateInterval) ≤ SystemClockRate ÷ 2)

Is 2,400,000,000 / (30,000 × 1) ≤ 156,000 ÷ 2

80,000 ≤ 78,000: FALSE

Therefore, W32tm.exe would set the clock back immediately.

Note

In this case, if you want to set the clock back slowly, you would also have to adjust the values of PhaseCorrectRate or UpdateInterval in the registry to make sure that the equation result is TRUE.

Example: System clock rate off by three minutes

Your computer clock time is 11:05 and the actual current time is 11:08:

PhaseCorrectRate = 1

UpdateInterval = 30,000 clock ticks

SystemClockRate = 156,000 clock ticks

MaxAllowedPhaseOffset = 10 min = 600 seconds = 600 × 1,000 × 10,000 = 6,000,000,000 clock ticks

|CurrentTimeOffset| = 3 mins = 3 × 60 × 1,000 × 10,000 = 1,800,000,000 clock ticks

Is CurrentTimeOffset ≤ MaxAllowedPhaseOffset?

1,800,000,000 ≤ 6,000,000,000: TRUE

AND does it satisfy the following equation?

(|CurrentTimeOffset| ÷ (PhaseCorrectRate × UpdateInterval) ≤ SystemClockRate ÷ 2)

Is 3 mins × (1,800,000,000) ÷ (30,000 × 1) ≤ 156,000 ÷ 2

Is 60,000 ≤ 78,000: TRUE

In this case, the clock will be set back slowly.

Using Local Group Policy Editor

The Windows Time service stores a number of configuration properties as registry entries. You can use Group Policy Objects (GPOs) in Local Group Policy Editor to configure most of this information. For example, you can use GPOs to configure a computer to be an NTPServer or NTPClient, configure the time synchronization mechanism, or configure a computer to be a reliable time source.

Note

Group Policy settings for the Windows Time service can be applied on Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2 domain controllers and can be applied to computers running Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2.

Windows stores the Windows Time service policy information in the Local Group Policy Editor under Computer ConfigurationAdministrative TemplatesSystemWindows Time Service. It stores configuration information that the policies define in the Windows registry, and then uses those registry entries to configure the registry entries specific to the Windows Time service. As a result, the values defined by Group Policy overwrite any pre-existing values in the Windows Time service section of the registry. Some of the preset GPO settings differ from the corresponding default Windows Time service registry entries.

For example, suppose you edit policy settings in the Time ProvidersConfigure Windows NTP Client policy. Windows loads these settings into the policy area of the registry under the following subkey:

HKLMSoftwarePoliciesMicrosoftW32timeTimeProvidersNtpClient

Then Windows uses the policy settings to configure the related Windows Time service registry entries under the following subkey:

HKLMSYSTEMCurrentControlSetServicesW32TimeTime ProvidersNTPClient

The following table lists the policies that you can configure for the Windows Time service, and the registry subkeys that those policies affect.

Note

When you remove a Group Policy setting, Windows removes the corresponding entry from the policy area of the registry.

¹Category path: Computer ConfigurationAdministrative TemplatesSystemWindows Time Service
² Subkey: HKLMSOFTWAREPoliciesMicrosoft
³ Subkey: HKLMSYSTEMCurrentControlSetServices

Windows registry reference

Warning

This information is provided as a reference for use in troubleshooting and validation. Windows registry keys are used by W32Time to store critical information. Don't change these values. Modifications to the registry are not validated by the registry editor or by Windows before they are applied. If the registry contains invalid values, Windows may experience unrecoverable errors.

The Windows Time service stores information in the registry at the HKLMSYSTEMCurrentControlSetServicesW32Time path under the following subkeys:

In the following tables, 'All versions' refers to Windows 7, Windows 8, Windows 10, Windows Server 2008 and Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019.

Note

Some of the parameters in the registry are measured in clock ticks and some are measured in seconds. To convert the time from clock ticks to seconds, use these conversion factors:

• 1 minute = 60 sec
• 1 sec = 1000 ms
• 1 ms = 10,000 clock ticks on a Windows system, as described at DateTime.Ticks Property.

For example, 5 minutes becomes 5 × 60 × 1000 × 10000 = 3,000,000,000 clock ticks.

Config entries

The Config subkey entries are located at HKLMSYSTEMCurrentControlSetServicesW32TimeConfig.

Parameters entries

The Parameters subkey entries are located at HKLMSYSTEMCurrentControlSetServicesW32TimeParameters.

NtpClient entries

The NtpClient subkey entries are located at HKLMSYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClient

NtpServer entries

The NtpClient subkey entries are located at HKLMSYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpServer.

Enhanced logging

The following registry entries are not a part of the W32Time default configuration but can be added to the registry to obtain enhanced logging capabilities. The information logged to the System Event log can be modified by changing values for the EventLogFlags setting in the Group Policy Object Editor. By default, the Windows Time service logs an event every time that it switches to a new time source.

In order to enable W32Time logging, add the following registry entries:

Group Policy Object settings

Group Policy settings are contained in the Global Configuration Settings and the Windows NTP Client Settings GPOs.

Global Configuration Settings

These are the global Group Policy settings and default values for the Windows Time service. These settings are contained in the Global Configuration Settings GPO in Local Policy Editor.

Windows NTP Client settings

These are the Windows NTP client settings and default values for the Windows Time service. These settings are contained in the Configure Windows NTP Client GPO in Local Group Policy Editor.

Get Windows Registry Value Powershell

Related information

See RFC 1305 - Network Time Protocol of the Internet Engineering Task Force (IETF).

Whenever you install software, updates or make configuration changes, it’s common for Windows to need a reboot. Many OS tasks sometimes force Windows to require a reboot. When a reboot is pending, Windows add some registry values to show that. In this blog post, you’re going to learn how to check for a pending reboot and how to build a PowerShell script to automate the task.

Windows Needs Rebooted

When you’re in on the console, you can notice a reboot is pending by some popup box or notification as shown below.

From that notification, you can restart Windows and be done with it. But, what if you can’t immediately reboot a machine when it needs to? What if you’ve just installed updates on a production server and that server can’t be rebooted right now?

The reboot must wait.

Time goes by and by then the reboot may be forgotten about altogether! By the time you realize, many servers or workstations need to be rebooted but which ones?

Pending Reboot Flags are in the Registry

A pending reboot is defined in many places. Scroll right to see the values and conditions. A Windows computer is pending a reboot if any of the conditions in this table are true.

If you have the Microsoft System Center Configuration Manager (SCCM) client installed, you may also see these methods in WMI.

Once you know each method to check for a pending reboot, there are many different ways to check registry values. You could open up regedit.exe and manually mouse through each registry key.

Manually checking via the registry works but we’re human. What if you forget to check one registry path or just forget which ones to check? There’s a much better way to do this. You can create a script or function to do this for you. In my case, I prefer PowerShell so that’s what I’ll use.

By using a PowerShell script, you can query one or all computers in our domain or manually provide the server names to see if they are pending a reboot. You can then make a decision to whether to reboot them then or make a list to reboot later. The choice is yours.

To use my PowerShell method, you’ll need to ensure PowerShell Remoting is set up and available on your servers.

Testing for a a Pending Reboot (The Easy Way)

If you don’t want to learn how to check these registry keys and build a tool like this in PowerShell, I’ve made it easy for you. Simply open up your PowerShell console and type Install-Script Test-PendingReboot. Install-Script will download my PowerShell script from the PowerShell Gallery to C:Program FilesWindowsPowerShellScripts. Then run the script as shown below.

You can provide as many servers as you want via the ComputerName parameter. The script will return True or False along with the server name.

This tool checks all of the registry keys in the above table for you.

If you’d like to add conditions I’ve missed or correct any mistakes I’ve made, feel free to issue a pull request on GitHub to fix it.

If you want to learn how to build a tool like this, read on!

Building a Pending Reboot PowerShell Tool

First, you’ll need to define all of the computers you’d like to test a reboot on. There are many different ways to do this but for this demonstration, I’ll define them manually via an array.

Now create a foreach loop to iterate over each of them.

Next, I recommend using PowerShell Remoting and checking each registry key and value condition inside of a single PSSession. Create a PSSession for every server.

Once you have a PSSession created, you’ll then need to run the checks.

Get Windows Registry Key C#

Since you’ll be running many different checks using the same code such as:

• Testing if a registry key exists
• Testing if a registry value exists
• Testing if a registry value is not null

I recommend creating simple functions for each of these checks. This allows you to call a function instead of duplicating code. The Test-PendingReboot script builds all of these helper functions into a single scriptblock as shown below.

Inside of that same scriptblock, define each condition referencing the helper functions you just created.

You can now create a foreach loop inside of your $serversforeach loop that reads each test executes each test.

When you run the code, the script returns an output like this:

You can create this output by ensuring the foreach loop returns a single object per server. You should know that if any of the registry values exist, then the server is pending a reboot. Knowing this, you then need to return True if any of the values exist and False if none of them exist.

Wrap all of this up into a script and it should look like this (with some minor additions like Credential).

You can now execute it like this:

Summary

Get My Windows Product Key From Registry

You should now have a quick way to test pending reboot across Windows servers. You can see that by using PowerShell, you can consolidate down many tedious steps into one script. This script allows you to quickly test for a pending reboot across many servers at once.

If you know of any other indications to check for a pending reboot, please let me know.

More from Adam The Automator & Friends