7 Appendix B: Product Behavior

  • Article

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.

Windows Client

  • Windows 2000 Professional operating system

  • Windows XP operating system

  • Windows Vista operating system

  • Windows 7 operating system

  • Windows 8 operating system

  • Windows 8.1 operating system

  • Windows 10 operating system

  • Windows 11 operating system

Windows Server

  • Windows 2000 Server operating system

  • Windows Server 2003 operating system

  • Windows Server 2008 operating system

  • Windows Server 2008 R2 operating system

  • Windows Server 2012 operating system

  • Windows Server 2012 R2 operating system

  • Windows Server 2016 operating system

  • Windows Server operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 operating system

  • Windows Server 2025 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.3: The Windows Time service (W32Time) implements the server end of the W32Time Remote Protocol. For more information on W32Time, see [WTSREF].

<2> Section 1.7: Windows RPC returns RPC_S_PROCNUM_OUT_OF_RANGE to notify the client that an RPC method is out of range, as specified in [MS-ERREF].

<3> Section 2.1: Windows 2000 operating system supports only the unauthenticated RPC interface.

<4> Section 2.2.3: This field can take on any Windows error code value, as specified in [MS-ERREF].

<5> Section 2.2.3: The ulErrorMsgId value is used as a message identifier.

<6> Section 2.2.4: This field can take on any Windows error code value, as specified in [MS-ERREF].

<7> Section 2.2.4:  The ulErrorMsgId value is used as a message identifier.

<8> Section 2.2.5: Windows implementations of the protocol client ignore this field. Windows implementations of the protocol server set it to the correct value.

<9> Section 2.2.7: Windows 2000 does not implement the W32Time clock discipline algorithm. The clock discipline algorithm uses a phase lock loop (PLL) method to adjust the local clock's time difference and clock rate as phase correction and frequency correction, and it uses a state machine to model the different states of the time adjustment. W32Time supports all the values specified in the possible value table. For more information on clock state machines, see [NTP-TR9733i] and [NTP-TR9733].

<10> Section 2.2.11: The NtpClient time provider's configuration of W32Time is not implemented in Windows 2000. For more information on W32Time, see [WTSREF].

<11> Section 2.2.12: The NtpServer time provider's configuration of W32Time is not implemented in Windows 2000.

<12> Section 2.2.14: The basic configuration of W32Time is not implemented in Windows 2000.

<13> Section 2.2.15: The advanced configuration of W32Time is not implemented in Windows 2000.

<14> Section 2.2.16: The default configuration of W32Time is not implemented in Windows 2000.

<15> Section 3.1.3: Windows clients create a separate binding handle for every method invocation. The Windows 2000 client supports only RPC binding via unauthenticated RPC, and only attempts to communicate with the unauthenticated well-known endpoint (see section 2.1). The clients in Windows XP and Windows Server 2003 attempt an RPC binding to the authenticated RPC endpoint first. If the authenticated RPC is unavailable (as specified in [MS-RPCE] section 3.3.2), these clients perform an RPC binding to unauthenticated RPC for backward compatibility with the W32Time implementation when connecting to W32Time on Windows 2000.

Clients determine whether an authenticated RPC binding is available upon method invocation. The Windows implementation creates the binding handle, verifies the security capability of the remote server, and then invokes the method. If the method call fails with RPC_S_SERVER_UNAVAILABLE or RPC_S_UNKNOWN_IF (as specified in [MS-ERREF]), the client attempts to reestablish a binding to the unauthenticated well-known endpoint and retries the method invocation.

<16> Section 3.1.3: For authenticated RPC, the client implementation in Windows XP and later and in Windows Server 2003 and later invokes the rpc__mgmt_inq_princ_name method of the Remote Management Interface, as specified in [C706], and more specifically in the Remote Management Interface Appendix (as specified in [C706] and augmented in [MS-RPCE]) to retrieve the princ_name for the Simple and Protected GSS-API Negotiation (as specified in [MS-SPNG]) authentication service. This invocation is done prior to each W32Time Remote Protocol method call. If this invocation succeeds, authentication with the remote peer is deemed to be possible, and the RPC runtime is configured to use the SPNEGO security provider (with the RPC_C_AUTHN_GSS_NEGOTIATE and RPC_C_AUTHN_LEVEL_PKT_PRIVACY flags), and the retrieved princ_name for the subsequent RPC method calls to the server. If this invocation fails, the Windows client implementation makes all the RPC method calls without authentication.

W32Time Remote Protocol clients in Windows 2000 do not attempt to negotiate authentication.

<17> Section 3.1.4.1: In Windows releases prior to Windows XP, all applications and implementations available as part of Windows set the ulFlags parameter to zero.

<18> Section 3.1.4.1: In the default configuration of a non–domain-joined Windows NTP client, the W32TimeSync method results in the higher-layer–triggered use of NTP (as described in [RFC1305]). This occurs because a non–domain-joined Windows NTP client is configured to use NTP by default. For more information on NTP, see [RFC1305].

<19> Section 3.1.4.1: In the default configuration of a domain-joined Windows NTP client, the W32TimeSync method results in the higher-layer–triggered use of NTP with authentication extensions (as described in [MS-SNTP]). This occurs because a domain-joined Windows NTP client is configured to use NTP Authentication Extensions by default, as outlined in [MS-SNTP] section 1.6. For more information on the Windows implementation of NTP with authentication extensions, see [MS-SNTP].

<20> Section 3.1.4.3: All applications and implementations available as part of Windows set the ulFlags parameter to zero.

<21> Section 3.1.4.8: The RPC method W32TimeLog is not supported in Windows 2000, Windows XP, and Windows Server 2003. The Windows implementation sets up the logging configuration before invoking this method.

<22> Section 3.1.5: The Windows implementation ignores errors and passes them back to the invoker. The Windows implementation does not check returned values and does not notify the invoker of invalid values. This protocol requests that the RPC engine perform a strict network data representation (NDR) data consistency check at target level 5.0, as specified in [MS-RPCE] section 3.1.1.5.3.

<23> Section 3.2.1.1: The string syntax is a list of comma-delimited numbers. Valid numbers are from 0 to 300. Numbers can also be represented as a range, such as "0–300". The Windows implementation uses this string to indicate the points of execution in its implementation that it is logging locally. [MSFT-WTSFLE] shows the associated registry key for the storage of the string in the Windows implementation. It also shows what category of information is logged for a subset of the numbers in the string. This subset was published for the administration of the Windows implementation.

<24> Section 3.2.1.1: The Windows clock rate depends on the computer hardware and Windows releases. There are two common values: 100 ticks per second, where each tick is 10 milliseconds, and 64 ticks per second, where each tick is 15.625 milliseconds.

<25> Section 3.2.1.2: This field can take on any Windows error code value, as specified in [MS-ERREF].

<26> Section 3.2.1.2.1: For more information on domain time source discovery, see [MS-SNTP] and [WTSREF].

<27> Section 3.2.1.3: Windows does not cap ulResolveAttempts and instead wraps it around to 0.

<28> Section 3.2.1.3: This field can take on any Windows error code value, as specified in [MS-ERREF].

<29> Section 3.2.1.3: In Windows XP and later and in Windows Server 2003 and later, the time provider in W32Time defines the following message identifiers indicating possible time synchronization failure reasons. The failure reasons correspond to message errors, as specified in [RFC1305] section 3.4.4, "Packet Procedure".

Value

Meaning

0x0000005C

The peer is unreachable.

0x0000005E

The time sample was rejected because duplicate time stamps were received from this peer.

0x0000005F

The time sample was rejected because the message was received out of order.

0x00000060

The time sample was rejected because the peer is not synchronized or because reachability was lost in one or both directions. This value might also indicate that the peer incorrectly sent an NTP request instead of an NTP response.

0x00000061

The time sample was rejected because the round-trip delay was too large, as specified in [RFC1305] section 3.4.4, test 4 of the "Packet Procedure."

0x00000062

The time sample was rejected because the packet was not authenticated.

0x00000063

The time sample was rejected because the peer is not synchronized, or it has been too long since the peer's last synchronization, as specified in [RFC1305], section 3.4.4, test 6 of the "Packet Procedure".

0x00000064

The time sample was rejected because the peer stratum is less than the host stratum, as specified in [RFC1305] section 3.4.4, test 7 of the "Packet Procedure".

0x00000065

The time sample was rejected because the packet contains unreasonable root delay or root dispersion values, as specified in [RFC1305] section 3.4.4, test 8 of the "Packet Procedure".

<30> Section 3.2.1.3: In Windows XP and later and in Windows Server 2003 and later, the time provider in the W32Time defines the following message identifiers indicating possible authentication mechanisms.

Value

Meaning

0x0000005A

NoAuth: NTP without authentication extension

0x0000005B

NtDigest: NTP with authentication extension

<31> Section 3.2.1.3: This element is transparently passed through to the invoking application. Windows takes no explicit action on it.

<32> Section 3.2.3: W32Time in Windows 2000 supports only unauthenticated RPC over SMB and thus listens only on the well-known endpoint \\PIPE\W32TIME. W32Time in Windows XP and later and in Windows Server 2003 and later supports only authenticated RPC over SMB and thus listens only on \\PIPE\W32TIME_ALT. W32Time in Windows XP and Windows Server 2003 does not register any specific authentication mechanism but rather passes RPC_C_AUTHN_GSS_NEGOTIATE to RPC and allows RPC to negotiate security on behalf of the client and server, as specified in [MS-RPCE].

<33> Section 3.2.5: This protocol requires the RPC runtime to perform a strict NDR data consistency check at target level 5.0, as specified in [MS-RPCE] section 3.1.1.5.3.

For authenticated RPC in Windows XP and later and in Windows Server 2003 and later, W32Time performs an additional privilege check for all the methods in the RPC interface. W32Time checks the client's privileges to determine whether the client possesses the privilege to change system time. If the service is unable to perform this check, or if the client does not possess the required privilege, the RPC method fails. By default, members of the built-in Administrators group possess the privilege to change the system time. For details on RPC security callback, see [MS-RPCE].

<34> Section 3.2.5.1: Windows blocks the call by using a local RPC named event.

<35> Section 3.2.5.1: W32Time servers running Windows 2000 ignore this field.

<36> Section 3.2.5.1: If TimeSyncFlag_ReturnResult is not set, this method returns zero on success or any Windows error code value on failure, as specified in [MS-ERREF].

<37> Section 3.2.5.1: W32Time in Windows 2000 ignores the ulFlags parameter. The semantics of the invocation of W32TimeSync in Windows 2000 is that of the TimeSyncFlag_HardResync flag. This version does not support TimeSyncFlag_ReturnResult and always returns zero for this method.

<38> Section 3.2.5.2: In Windows 2000, W32Time always sets the DS_TIMESERV_FLAG bit. In Windows XP and later and in Windows Server 2003 and later, W32Time sets the DS_TIMESERV_FLAG bit only if it allows clients to synchronize with it using NTP, as specified in [RFC1305].

<39> Section 3.2.5.3: The RPC method W32TimeQueryProviderStatus is not supported in Windows 2000.

<40> Section 3.2.5.3: In Windows XP and later and in Windows Server 2003 and later, W32Time implements two NTP time providers based on NTP, as specified in [RFC1305]. The well-known time provider names that can be passed as the pwszProvider parameter are NtpClient and NtpServer. For more information on W32Time, see [WTSREF]. Windows has not implemented a hardware time provider.

<41> Section 3.2.5.3: This field can take on any Windows error code value, as specified in [MS-ERREF].

<42> Section 3.2.5.4: This field can take any Windows error code value, as specified in [MS-ERREF].

<43> Section 3.2.5.4: The RPC method W32TimeQuerySource is not supported in Windows 2000, Windows XP, and Windows Server 2003. If the time service synchronizes with a time source, the time source name is either an FQDN or an IP address. If the time service does not synchronize with a time source, the name of the time source is set to "Local CMOS Clock".

<44> Section 3.2.5.5: The RPC method W32TimeQueryProviderConfiguration is not supported in Windows 2000, Windows XP, or Windows Server 2003.

<45> Section 3.2.5.5: Time providers that W32Time supports are described in section 3.2.5.3.

<46> Section 3.2.5.5: This field can take on any Windows error code value, as specified in [MS-ERREF].

<47> Section 3.2.5.6: The RPC method W32TimeQueryConfiguration is not supported in Windows 2000 or Windows XP.

<48> Section 3.2.5.6: This field can take on any Windows error code value, as specified in [MS-ERREF].

<49> Section 3.2.5.7: The RPC method W32TimeQueryStatus is not supported in Windows 2000 or Windows XP.

<50> Section 3.2.5.7: This field can take on any Windows error code value, as specified in [MS-ERREF].

<51> Section 3.2.5.8: The RPC method W32TimeLog is not supported in Windows 2000 or Windows XP.

<52> Section 3.2.5.8: W32Time performs logging by writing to a text file stored locally on the machine. Logging is done in a circular fashion, meaning that the logging wraps to the top of the file when it reaches the limit. The size, location, and specific entries to log are configured through the registry.

<53> Section 3.2.5.8: This field can take on any Windows error code value, as specified in [MS-ERREF].

<54> Section 3.2.5.8: W32Time updates its logging behavior based on the logging configuration in the Windows registry. For more information on W32Time, see [WTSREF].