事件 142:时间服务已停止作为时间源的广告

本文提供事件 142 的解决方法:时间服务已停止将广告作为时间源。

适用于: Windows Server 2012 R2
原始 KB 编号: 2468336

症状

Microsoft-Windows-Time-Service 事件 142 使用下表中列出的四个错误字符串之一进行记录, (event_<错误> 字符串:

日志名称:系统
资料来源:Microsoft-Windows-Time-Service
日期: <日期><时间>
事件 ID:142
任务类别:无
级别:警告
关键 字:
用户:LOCAL SERVICE
计算机: <主机名>。<域名>。<顶级域>
说明:

错误状态 错误字符串
event_0x0038 时间服务已停止作为时间源进行广告宣传,因为本地计算机不是Active Directory 域控制器。
event_0x0039 时间服务已停止将广告作为时间源,因为没有提供程序在运行。
event_0x003A 时间服务已停止将广告作为时间源,因为没有提供程序在运行。
event_0x003B 时间服务已停止将广告作为好时间源。
本地时钟未同步

事件 Xml:
<事件 xmlns=“https://schemas.microsoft.com/win/2004/08/events/event”>
<系统>
<Provider Name=“Microsoft-Windows-Time-Service” Guid=“{06EDCFEB-0FD0-4E53-ACCA-A6F8BBF81BCB}” />
<EventID>142</EventID>
<版本>0</版本>
<级别>3</级别>
<任务>0</任务>
<Opcode>0</Opcode>
<关键字>0x8000000000000000</关键字>
<TimeCreated SystemTime=“YYYY-MM-DDTHH:MM:SS。MSZ“ />
<EventRecordID>3965</EventRecordID>
<相关/>
<Execution ProcessID=“<PID>” ThreadID=“<TID>” />
<通道>系统</通道>
<计算机>DC1.contoso.com</计算机>
<Security UserID=“<SID>” />
</系统>
<EventData Name=“TMP_EVENT_STOP_ADVERTISING”>
</EventData>
</事件>

原因

错误字符串 原因
时间服务已停止作为时间源进行广告宣传,因为本地计算机不是Active Directory 域控制器。 本地计算机不再托管 DC 角色,或者本地计算机出现配置问题。
时间服务已停止将广告作为时间源,因为没有提供程序在运行。 NTP 客户端服务已停止或未响应
时间服务已停止将广告作为时间源,因为没有提供程序在运行。 本地计算机上的时间与对等计算机不同步
时间服务已停止将广告作为好时间源。 本地 DC 无法找到时间服务器

解决方案

Microsoft-Windows-Time-Service 事件 142 记录的主要错误字符串是第三个示例:

时间服务已停止作为时间源的广告,因为没有提供程序在运行。

  1. 在 Technet 的“事件 ID 142 - 时间服务广告”中执行行动计划

  2. 验证林根 PDC 是否处于联机状态,并且当前根域 PDC 均 (1.) 正确配置为与外部时间源同步时间, (2.) 能够可靠地从该源获取源时间。

  3. 验证服务启动值和服务状态:自动 + 正在运行

  4. 验证 DC 日志记录 142 事件是否可以使用 发现时间服务器 DCLocator

    nltest /dsgetdc:<dns domain> /timeserv /force
    nltest /dsgetdc:<dns 域> /gtimeserv /force <- 如果在环境中配置了 gtimesrv

  5. 验证与对等时间服务器的端口和协议连接

    w32tm /query /source

  6. 通过查找以下事件来检查决斗时间协议的使用情况:

    Microsoft-Windows-Time-Service 事件 35 请注意事件中的协议 + 源 DC
    Microsoft-Windows-Time-Service 事件 37 <请注意事件中的协议 + 源 DC
    Microsoft-Windows-Kernel-General 事件 1。 Microsoft-Windows-Kernel-General 事件 1 指示 VM 中的时间已更改。 每次 W32time 更新时钟时,都会记录此事件。 每次 Hyper-V 时间同步更新时钟时,都会记录 Microsoft-Windows-Kernel-General 事件 1。 此事件不特定于 VM,因为它在 w32time 更新时钟时也会记录在物理计算机中
  7. 其他根本原因

    林根 PDC 上的 AnnounceFlags = 10。 可以在注册表中显式设置或在组策略中定义此设置。

    如果记录 Microsoft-Windows-Time-Service 事件 142 的计算机是驻留在 Hyper-V 主机上的虚拟化来宾计算机,请在 Hyper-V 主机上禁用 VMICTimeSync。

更多信息

实际客户体验
\\workstation1 (加入域) 到fabrikam.com\\DC1不受信任contoso.com域的 RDP 登录失败,并出现以下错误:

标题栏文本:远程桌面连接

对话框消息文本:远程桌面无法验证远程计算机的身份,因为计算机与远程计算机之间存在时间或日期差异。 确保计算机的时钟设置为正确的时间,然后再次尝试连接。 如果问题再次发生,请与网络管理员或远程计算机的所有者联系

contoso.com 域包含两个虚拟化的 DC, \\DC1\\DC2 在同一个 W2K8 R2 Hyper-V 主机上运行。 Hyper-V 主机是\\DC1\\DC2域中fabrikam.com的成员服务器,即与 RDCP 客户端\\workstation1相同的域。

据报道,所开 \\workstation1 的系统时间与系统时间 \\DC1相差几秒钟。 据报道,域上的 \\DC2.contoso.com 系统时间与当前时间和存在 \\DC1时间的时间为 45 分钟。

查看用于查找 Kerberos 和时间相关错误的 SYSTEM 事件日志显示以下事件。

Microsoft-Windows-Time-Service 事件 142 已登录 \\DC2.contoso.com。 如果 142 错误是无法找到时间服务器或无法从对等服务器同步,则主要原因。

日志名称:系统
资料来源:Microsoft-Windows-Time-Service
日期: <日期><时间>
事件 ID:142
任务类别:无
级别:警告
关键 字:
用户:LOCAL SERVICE
计算机: DC2.contoso.com
说明:
时间服务已停止将广告作为时间源,因为本地时钟未同步。
事件 Xml:
<事件 xmlns=“https://schemas.microsoft.com/win/2004/08/events/event”>
<系统>
<Provider Name=“Microsoft-Windows-Time-Service” Guid=“{<GUID>}” />
<EventID>142</EventID>
<版本>0</版本>
<级别>3</级别>
<任务>0</任务>
<Opcode>0</Opcode>
<关键字>0x8000000000000000</关键字>
<TimeCreated SystemTime=“YYYY-MM-DDTHH:MM:SS。MSZ“ />
<EventRecordID>3965
<相关/>
<Execution ProcessID=“<PID>” ThreadID=“<TID>” />
<通道>系统</通道>
<计算机>DC1.contoso.com</计算机>
<Security UserID=“<SID>” />
</系统>
<EventData Name=“TMP_EVENT_STOP_ADVERTISING”>
</EventData>
</事件>

在控制台 \\DC1.contoso.com 上记录的 Microsoft-WIndows-Time-Service 事件 35 指示 PDC \\DC1 正在使用 VM IC 时间同步提供程序来同步时间。

日志名称:系统
资料来源:Microsoft-Windows-Time-Service
日期: <日期><时间>
事件 ID:35
任务类别:无
级别:信息
关键 字:
用户:LOCAL SERVICE
计算机: dc1.contoso.com
说明:
时间服务现在将系统时间与时间源 VM IC 时间同步提供程序同步。
事件 Xml:
<事件 xmlns=“https://schemas.microsoft.com/win/2004/08/events/event
<系统>
<Provider Name=“Microsoft-Windows-Time-Service” Guid=“{<GUID>}” />
<EventID>35</EventID>
<版本>0</版本>
<级别>4</级别>
<任务>0</任务>
<Opcode>0</Opcode>
<关键字>0x8000000000000000</关键字>
<TimeCreated SystemTime=“<DateTime>” />
<EventRecordID>2614</EventRecordID>
<相关/>
<Execution ProcessID=“1012” ThreadID=“2508” />
<通道>系统</通道>
<计算机>dc1.contoso.com</计算机>
<Security UserID=“<sid>” />
</系统>
<EventData Name=“TMP_EVENT_TIME_SOURCE_CHOSEN”>
<数据名称=“TimeSource”>VM IC 时间同步提供程序
</EventData>
</事件>

在控制台 \\DC2.contoso.com 上记录的 Microsoft-WIndows-Time-Service 事件 37 指示 \\DC2 还从中采购 NTP 时间 \\DC1.contoso.com

日志名称:系统
资料来源:Microsoft-Windows-Time-Service
日期: <日期><时间>
事件 ID:37
任务类别:无
级别:信息
关键 字:
用户:LOCAL SERVICE
计算机: DC2.contoso.com
说明:
时间提供程序 NtpClient 当前从 jwesth-t1.jwesth.nttest.microsoft.com (ntp.d|[::]:123->[2001:4898:1b:4:6dd6:3c5c:699d:38cd]:123) 接收有效时间数据。
事件 Xml:
<事件 xmlns=“https://schemas.microsoft.com/win/2004/08/events/event”>
<系统>
<Provider Name=“Microsoft-Windows-Time-Service” Guid=“{<GUID>}” />
<EventID>37
<版本>0
<级别>4
<任务>0
<Opcode>0
<关键字>0x8000000000000000</关键字>
<TimeCreated SystemTime=“<DateTime>” />
<EventRecordID>3972
<相关/>
<Execution ProcessID=“1012” ThreadID=“1596” />
<通道>系统</通道>
<计算机>DC2.contoso.com</计算机>
<Security UserID=“<sid>” />
</系统>
<EventData Name=“TMP_EVENT_TIME_SOURCE_REACHABLE”>
<Data Name=“TimeSource”>dc1.contoso.com (ntp.d|[::]:123->[2001:4898:1b:4:6dd6:3c5c:699d:38cd]:123)
</EventData>
</事件>

另一个事件 Microsoft-Windows-Kernel-General(在此特定情况下未记录)指示 Hyper-V 主机可能会更改 VM 来宾计算机上的时间。 下面显示了一个示例事件。

日志名称:系统
资料来源:Microsoft-Windows-Kernel-General
日期: <日期><时间>
事件 ID: 1
任务类别:无
级别:信息
关键字:时间
用户:LOCAL SERVICE
计算机: <主机名>。<DNS 域>。<顶级域>
说明:
系统时间已更改为<新时间,格式为“like”2010-08-26T20:40:07.2100000000Z ><,格式为“like”2010-08-26T20:40:07.210642400Z>。

Microsoft-Windows-Kernel-General 事件 1 指示 VM 中的时间已更改。 每次 W32time 更新时钟时,都会记录此事件。 每次 Hyper-V 时间同步更新时钟时,都会记录 Microsoft-Windows-Kernel-General 事件 1。 此事件并不特定于 VM,因为当 w32time 更新时钟时,它也会记录在物理计算机中。

问题摘要

RDP 客户端被认为依赖于可选取最佳身份验证机制的 SPNego,在本例中使用了 Kerberos 事件,尽管 fabrikam 和 contoso.com 林之间没有信任。 Kerberos 身份验证要求两台计算机的时钟相距小于 5 分钟,但不考虑时钟准确性。

RDP 登录失败是由域 (DC1 中的 DC contoso.com 身份验证引起的,) 拒绝对 RDP 客户端登录请求进行身份验证,因为客户端的时间与服务器的时间不匹配。 客户端或服务器或两者都可以有一个未同步的时钟。

本例中的时差因多种因素而加剧

  1. RDP 客户端和 KDC/RDP 服务器存在于两个不同的林中,每个林使用不同的时间源配置

  2. RDC 客户端使用的 KDC 和 RDP 服务器都是虚拟化的域控制器,需要进行其他配置更改,以准确获取源时间,然后再在物理硬件上运行的 DC。

  3. 虚拟主机是与 Hyper-V 主机不同的域中加入域的成员服务器

    虚拟主机计算机上的时间准确性很重要,因为 VM 来宾计算机最初在 OS 启动期间从虚拟主机派生时间。

    两个负面因素| \\DC1 DC2 是成员计算机的轮询时间默认低于域控制器。 其次,Hyper-V 主机已加入到与 DC 来宾不同的域,并受制于不同的时间源配置

    最后,VMICTimeSync 用于 \\DC2 源时间,不建议用于托管 DC 角色计算机的虚拟化计算机。

  4. 域中的 contoso.com 林根 PDC 未配置为从外部时间源源获取时间

在这种情况下,在域 (、VMICTimeSync) ntpcontoso.com使用多个时间提供程序被认为是导致 RDP 登录失败的不准确时间的根本原因。

对于如何在 AD 和 Hyper-V 团队中的主机和来宾计算机中配置时间,存在不同意见。 Ryan Sizemores 建议 2010.11.22 启用 VMIC,但请密切关注主计算机上时间的配置和准确性。 例如,“在现有域中部署 W2K8 和 W2K8 R2 DC”的“为 Windows Server 2008 和 Windows Server 2008 R2 配置 Windows 时间服务”部分建议使用“类似 DC 的”轮询间隔和最大*阶段更正设置来配置虚拟主机计算机, + 准确的时间服务器,类似于在林根 PDC 上执行的操作。

在虚拟主机和虚拟来宾环境中使用不同的时间提供程序和时间源可能会导致来宾计算机上的时间在从主机计算机传递的 VMIC 值之间进行 ping pong 的情况。 当一个林中的虚拟化 DC 来宾由另一个林中的虚拟主机计算机托管,甚至工作组计算机(其中每个都使用不同的时间源/时间配置,并且两者之间的时间示例不同)时,可能会存在此情况。

Hyper-V 团队建议不要禁用 VMICTimeSync,因为它可在使用保存状态时防止时间同步问题。 此处的关键问题不是使用 VMICTimeSync,而是如果运行域控制器, 需要从远程服务器获得准确的时间。 可以通过在虚拟机中配置远程时间源或启用 VMICTimeSync 并将主机配置为使用可靠的时间源来执行此操作。

通过设置禁用了 VMICTimeSync 且没有外部时间源的虚拟机,域控制器将使用本地时间,这一点始终保证在虚拟机中出错。

Microsoft Windows 时间团队针对更正此环境的建议包括:

  1. 使用 NTP 服务器配置林根 PDC。

  2. 在林根域中将 GTIMEServer 配置为备份

  3. 如果使用虚拟化,请禁用正在评估的 VMICTimeSync (

  4. 使用外部时间服务器配置 Hyper-V 主机

  5. 使用与域控制器相同的轮询间隔配置 Hyper-V 主机

  6. 在 Hyper-V 主机上启用时间回滚保护。

源 (有用的命令 :Carlos Trueba Salinas)

net stop vmictimesync
sc config vmictimesync start= disabled
reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider" /f
w32tm /config /manualpeerlist:ntdev-dc-05.ntdev.corp.microsoft.com /syncfromflags:MANUAL /update
net stop w32time & net start w32time
w32tm /query /source
w32tm /resync /force

事件 ID 142 - 时间服务广告
时间服务广告 - Technet
在林根域中的 PDC 模拟器上配置 Windows 时间服务
为 Windows Server 2008 和 Windows Server 2008 R2 配置 Windows 时间服务
在 Hyper-V 中运行域控制器
为 Windows Server 配置 Windows 时间服务 - Ace Fekay 的博客文章