Export (0) Print
Expand All

7 Appendix B: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs:

  • Windows 2000 operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product 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 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 an index into a message table stored as a resource in a DLL, as defined in [MS-GLOS], 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 an index into a message table stored as a resource in the DLL that implements the time provider, as defined in [MS-GLOS], Message Identifier.

<8> Section 2.2.5: Windows clients ignore this field. Windows servers set it to the correct value.

<9> Section 2.2.7: Windows 2000 does not implement the W32Time clock discipline algorithm. Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012, W32Time implements the

<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 RPCendpoint 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 Windows client implementation in Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 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 supported in Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. 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, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2, 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, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2, 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, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 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, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2, 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. Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 give precedence to the least significant bit set.

<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.

W32Time supports the ulFlags parameter in the following Windows versions: Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. When mutually exclusive values are set in the ulFlags parameter, as specified in section 3.2.5.1, W32Time gives precedence to the flag whose bit is least significant.

<38> Section 3.2.5.2: In Windows 2000, W32Time always sets the DS_TIMESERV_FLAG bit. In Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2, 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. In Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. 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.

<40> Section 3.2.5.3: The following versions of Windows set this value to zero and ignore it on receipt: Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2.

<41> Section 3.2.5.3: In the following versions of Windows, W32Time implements two NTP time providers based on NTP, as specified in [RFC1305]: Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. 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.

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

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

<44> 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".

<45> Section 3.2.5.5: The RPC method W32TimeQueryProviderConfiguration is not supported in Windows 2000 or Windows XP.

<46> Section 3.2.5.5: Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 set this value to zero and ignore it on receipt.

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

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

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

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

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

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

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

<54> 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.

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

<56> 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].

 
Show:
© 2014 Microsoft