本文提供事件 142 的解决方法：时间服务已停止将广告作为时间源。
适用于： Windows Server（所有支持的版本）原始 KB 数： 2468336
症状
Microsoft-Windows-Time-Service 事件 142 记录了下表中列出的四个错误字符串之一（小于 event_<hex 错误> 字符串：
日志名称: 系统 来源：Microsoft-Windows-Time-Service 日期： <日期><时间> 事件 ID：142 任务类别：无 级别: 警告 关键字: 用户：本地服务 计算机：<主机名>。<>域名。<顶级域> 描述：
| 错误状态 | 错误字符串 |
|---|---|
| event_0x0038 | 由于本地计算机不是Active Directory 域控制器，因此时间服务已停止作为时间源播发。 |
| event_0x0039 | 由于没有提供程序正在运行，因此时间服务已停止将广告作为时间源播发。 |
| event_0x003A | 由于没有提供程序正在运行，因此时间服务已停止将广告作为时间源播发。 |
| event_0x003B | 时间服务已停止将广告作为良好的时间来源。 |
| 本地时钟未同步 |
事件 Xml： <事件 xmlns=“
https://schemas.microsoft.com/win/2004/08/events/event”> <系统> <提供程序名称=“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</计算机> <安全 UserID=“<SID>” /> </系统> <EventData Name=“TMP_EVENT_STOP_ADVERTISING”> </EventData> </事件>
原因
| 错误字符串 | 原因 |
|---|---|
| 由于本地计算机不是Active Directory 域控制器，因此时间服务已停止作为时间源播发。 | 本地计算机不再托管 DC 角色，或者本地计算机存在配置问题。 |
| 由于没有提供程序正在运行，因此时间服务已停止将广告作为时间源播发。 | NTP 客户端服务已停止或未响应 |
| 由于没有提供程序正在运行，因此时间服务已停止将广告作为时间源播发。 | 本地计算机上的时间已与对等计算机失去同步 |
| 时间服务已停止将广告作为良好的时间来源。 | 本地 DC 无法找到时间服务器 |
解决方案
由 Microsoft-Windows-Time-Service 事件 142 记录的主要错误字符串是第三个示例：
“时间服务已停止将广告作为时间源，因为没有提供程序正在运行。
- 在 Technet 的“事件 ID 142 - 时间服务广告”中执行行动计划
- 验证林根 PDC 是否处于联机状态，并且当前根域 PDC 是否已正确配置为将时间与外部时间源同步，并且 （2.） 能够可靠地从该源获取时间。
- 验证服务启动值和服务状态：自动 + 正在运行
- 验证 DC 日志记录 142 事件是否可以使用 发现时间服务器
DCLocator
nltest /dsgetdc：<dns 域> /timeserv /force nltest /dsgetdc：<dns 域> /gtimeserv /force <- 如果在环境中配置 gtimesrv
- 验证与对等时间服务器的端口和协议连接
w32tm /query /source
-
通过查找以下事件来检查到期时间协议的使用：
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 更新时钟时记录在物理计算机中 -
其他根本原因
在林根 PDC 上，AnnounceFlags = 10。 此设置可以显式设置或在注册表中或在组策略中定义。
如果计算机日志记录Microsoft-Windows-Time-Service 事件 142 是驻留在 Hyper-V 主机上的虚拟化来宾计算机，请在 Hyper-V 主机上禁用 VMICTimeSync。
详细信息
实际客户体验 从 （已加入\\workstation1域） 到fabrikam.com不受信任的\\DC1域中的 RDP 登录contoso.com失败，并出现以下错误：
标题栏文本：远程桌面连接
对话框消息文本：远程桌面无法验证远程计算机的标识，因为计算机与远程计算机之间存在时间或日期差异。 确保计算机的时钟设置为正确的时间，然后重试连接。 如果问题再次发生，请联系网络管理员或远程计算机的所有者
该 contoso.com 域包含两个虚拟化 DC， \\DC1并 \\DC2 在同一 W2K8 R2 Hyper-V 主机上运行。 Hyper-V 主计算机是\\DC1``\\DC2域中的成员服务器fabrikam.com，即与 RDCP 客户端\\workstation1相同的域。
系统时间 \\workstation1 报告为与系统时间相 \\DC1隔的秒数。 域上的 \\DC2.contoso.com 系统时间从当前时间和存在的 \\DC1时间报告为 45 分钟。
有关如何排查错误的详细信息，请参阅 连接到远程计算机时“远程桌面无法验证远程计算机的标识”。
查看 SYSTEM 事件日志以查找 Kerberos 和时间相关错误，其中显示了以下事件。
Microsoft-Windows-Time-Service 事件 142 已 \\DC2.contoso.com登录。 如果 142 错误无法从对等服务器查找时间服务器或同步，则主要原因是错误。
日志名称: 系统 来源：Microsoft-Windows-Time-Service 日期： <日期><时间> 事件 ID：142 任务类别：无 级别: 警告 关键字: 用户：本地服务 计算机:
DC2.contoso.com描述： 由于本地时钟未同步，时间服务已停止将广告作为时间源播发。 事件 Xml： <事件 xmlns=“https://schemas.microsoft.com/win/2004/08/events/event”> <系统> <提供程序名称=“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</计算机> <安全 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 任务类别：无 级别：信息 关键字: 用户：本地服务 计算机:
dc1.contoso.com描述： 时间服务现在正在将系统时间与时间源 VM IC 时间同步提供程序同步。 事件 Xml： <事件 xmlns=“https://schemas.microsoft.com/win/2004/08/events/event” <系统> <提供程序名称=“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 时间同步提供程序 </事件数据> </事件>
控制台上 \\DC2.contoso.com 记录的 Microsoft-WIndows-Time-Service 事件 37 表示 \\DC2 也从中采购 NTP 时间 \\DC1.contoso.com
日志名称: 系统 来源：Microsoft-Windows-Time-Service 日期： <日期><时间> 事件 ID：37 任务类别：无 级别：信息 关键字: 用户：本地服务 计算机:
DC2.contoso.com描述： 时间提供程序 NtpClient 当前从 （ntp.d|[：：]：123-jwesth-t1.jwesth.nttest.microsoft.com[2001：4898：1b：4：6dd6：3c5c：699d：38cd]：123）接收有效时间数据>。 事件 Xml： <事件 xmlns=“https://schemas.microsoft.com/win/2004/08/events/event”> <系统> <提供程序名称=“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”> <数据名称=“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 任务类别：无 级别：信息 关键字：时间 用户：本地服务 计算机： <主机名>。<DNS 域>。<顶级域> 描述： 系统时间已更改为<格式为“like”2010-08-26T20：40：07.210000000Z ><的新时间，格式为“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） 中的 contoso.com 身份验证 DC 拒绝对 RDP 客户端登录请求进行身份验证，因为客户端的时间与服务器的时间不匹配。 客户端或服务器或两者都可以具有非同步时钟。
此案的时间差异因多个因素而加剧
-
RDP 客户端和 KDC/RDP 服务器存在于两个不同的林中，每个林使用不同的时间溯源配置
-
RDC 客户端使用的 KDC 和 RDP 服务器都是虚拟化域控制器，这些域控制器需要额外的配置更改来准确源时间，然后是物理硬件上运行的 DC。
-
虚拟主机是与 Hyper-V 主机不同的域中加入域的成员服务器
虚拟主机计算机上的时间准确性非常重要，因为 VM 来宾计算机最初在 OS 启动时从虚拟主机派生时间。
和 | 的两个负因素
\\DC1DC2 是成员计算机默认轮询时间的频率低于域控制器。 其次，Hyper-V 主计算机已加入到与 DC 来宾不同的域，并且受不同的时间源配置的约束最后，VMICTimeSync 用于
\\DC2源时间，不建议用于托管 DC 角色计算机的虚拟化计算机。 -
域中的
contoso.com林根 PDC 未配置为来自外部时间源的源时间
在这种情况下，在域（contoso.comVMICTimeSync）中使用ntp多个时间提供程序被视为导致 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 值之间进行乒乓球。 当一个林中的虚拟化 DC 来宾由另一个林中的虚拟主机计算机托管，甚至工作组计算机托管时，这种情况可能存在，其中每个计算机使用不同的时间源/时间配置，两者之间的时间样本不同。
Hyper-V 团队建议不要禁用 VMICTimeSync，因为它可在使用保存状态时针对时间同步问题提供保护。 此处的关键问题不是使用 VMICTimeSync，而是一个事实，即如果你运行的是域控制器，则需要从远程服务器获取准确的时间。 为此，可以配置虚拟机中的远程时间源，或者使 VMICTimeSync 已启用，并将主机配置为使用可靠的时间源。
通过设置禁用 VMICTimeSync 的虚拟机（并且没有外部时间源），域控制器将使用本地时间，这是始终保证在虚拟机中出错的一件事。
Microsoft Windows 时间团队的建议，以更正此环境包括：
- 使用 NTP 服务器配置林根 PDC。
- 将林根域中的 GTIMEServer 配置为备份
- 如果使用虚拟化，请禁用 VMICTimeSync（正在评估它）
- 使用外部时间服务器配置 Hyper-V 主机
- 使用与域控制器相同的轮询间隔配置 Hyper-V 主机
- 在 Hyper-V 主机上启用时间回滚保护。
有用的命令 （来源：卡洛斯·真巴·萨利纳斯）
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 中运行域控制器在 Active Directory 林中配置 Windows 时间服务 - 具有应变计划的分步作