在主域虚拟机上正确配置时间服务器

非常好 👍，你的输出信息非常有价值。 我们来仔细分析下目前状态，基本可以确定问题点在哪里。 

 

 🔍 一、当前状态分析 

 

 

 

 项目 

 状态 

 说明 

 

 

 

 

 nltest /dsgetdc 

 ✅ 正常 

 已成功解析到域控制器 S-DNS1.shuncom.local (192.168.0.5) ，域通信没问题 

 

 

 w32tm /query /status 

 ❌ 异常 

 Leap 指示符: 3(未同步) 、 层次: 0 (未指定) 、 源: Local CMOS Clock ，说明此机器未能与 DC 同步 

 

 

 w32tm /query /configuration 

 ✅ 正常 

 Type 为 NT5DS （域层级同步），表示配置是正确的 

 

 

 w32tm /query /peers 

 ⚠️ 异常 

 对等源显示 S-DNS1.shuncom.local ，但层次是 0 (未指定) ，说明虽然发现了 DC，但 DC 没有对外提供时间服务或未响应 NTP 

 

 

 

 👉 也就是说： 

 

 问题出在 DC（S-DNS1）的时间服务未正确提供，导致客户端无法获得可用时间数据。 

 

 

 🧭 二、请在域控制器（S-DNS1）上执行以下命令检查 

 1️⃣ 查看 DC 时间服务状态 

 w32tm /query /status

 

 正常应显示： 

 Leap Indicator: 0(no warning)

Stratum: 2

Source: Local CMOS Clock

 

 如果 Stratum: 0 或 未同步 ，说明 DC 自身时间服务异常。 

 

 2️⃣ 查看 DC 时间服务配置 

 w32tm /query /configuration

 

 看一下是否包含： 

 Type: NTP

NtpServer: time.windows.com,0x8

AnnounceFlags: 5

 

 如果没有，说明 DC 未配置为可靠时间源。 

 

 🛠 三、修复 DC 时间服务（PDC 角色上执行） 

 

 以下命令只在 PDC 域控制器 上执行（你从 nltest 输出看到 Flags 里包含 PDC ，说明 S-DNS1 就是 PDC）。 

 

 1️⃣ 设置外部时间源（例如微软时间服务器）： 

 w32tm /config /manualpeerlist:"time.windows.com,0x8" /syncfromflags:manual /reliable:yes /update

 

 2️⃣ 重启时间服务： 

 net stop w32time

net start w32time

 

 3️⃣ 重新同步一次： 

 w32tm /resync /force

 

 4️⃣ 检查状态： 

 w32tm /query /status

 

 应看到： 

 Source: time.windows.com,0x8

Stratum: 2

 

 

 🧩 四、在客户端再次执行 

 在你的客户端（ 7000 ）主机上执行： 

 net stop w32time

net start w32time

w32tm /config /syncfromflags:domhier /update

w32tm /resync /force

 

 检查结果： 

 w32tm /query /source

 

 ✅ 理想输出： 

 S-DNS1.shuncom.local

 

 

 ✅ 五、可选验证 

 最后可测试： 

 w32tm /stripchart /computer:S-DNS1.shuncom.local /dataonly /samples:5

 

 若出现带时间偏移值的连续行，说明 NTP 同步通道已恢复。 

 

 如果你愿意，把 S-DNS1 上执行的以下两条命令输出 发给我： 

 w32tm /query /status

w32tm /query /configuration

 

 我可以直接帮你确认 DC 是否已经成为“可靠时间源”。 

 

 非常好，这个输出说明问题的关键点已经非常清晰了。 你的域控制器 S-DNS1 当前的时间来源是： 

 Source: VM IC Time Synchronization Provider

 

 也就是 虚拟化平台（Hyper-V 或 VMware）提供的时间同步源 ，而 不是外部 NTP 服务器或域层级时间服务 。 这会导致以下问题👇： 

 

 ⚠️ 问题说明 

 

 

 DC 的 Leap 指示符: 3(未同步) 表示：虽然它声称是主时钟（Stratum 1），但实际上它自己都没同步。 

 

 

 “VM IC Time Synchronization Provider” 是虚拟机工具自动注入的时间源（VMware Tools / Hyper-V Integration Services）。 域内其他主机（如你的 7000 客户机）从该 DC 获取时间时，会被拒绝或无法获得“可用的时间数据”。 

 

 

 换句话说： 

 

 DC 当前只是从虚拟机宿主机获取时间，而非一个“可靠的 NTP 服务端”。 

 

 

 ✅ 解决方案（让 S-DNS1 成为域内可靠时间源） 

 步骤 1：在 S-DNS1 上设置外部时间源 

 以管理员身份运行 PowerShell： 

 w32tm /config /manualpeerlist:"time.windows.com,0x8 cn.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update

 

 这条命令含义： 

 

 

 manualpeerlist : 设置多个外部 NTP 源。 

 

 

 syncfromflags:manual : 强制从外部手动源同步。 

 

 

 reliable:yes : 声明本机是域内“可靠时间源”（PDC 的必备角色）。 

 

 

 

 步骤 2：禁用虚拟机时间同步（在 Hyper-V 或 VMware 上） 

 

 因为虚拟化层的时间同步会“覆盖” w32time。 

 

 VMware 环境下： 

 在 VMware vSphere 中编辑虚拟机设置，取消勾选： 

 

 “Synchronize guest time with host” 

 

 或者在命令行中执行： 

 vmware-toolbox-cmd timesync disable

 

 Hyper-V 环境下： 

 取消集成服务里的 “Time synchronization” 勾选。 

 

 步骤 3：重启时间服务并立即同步 

 net stop w32time

net start w32time

w32tm /resync /force

 

 然后检查： 

 w32tm /query /status

 

 期望输出： 

 Leap 指示符: 0(no warning)

层次: 2

源: time.windows.com,0x8

 

 

 步骤 4：客户端（如“7000”）重新同步 

 net stop w32time

net start w32time

w32tm /config /syncfromflags:domhier /update

w32tm /resync /force

 

 然后： 

 w32tm /query /source

 

 应返回： 

 S-DNS1.shuncom.local

 

 

 🔎 验证测试 

 客户端上运行： 

 w32tm /stripchart /computer:S-DNS1.shuncom.local /dataonly /samples:5

 

 如果出现类似输出： 

 12:34:56, +00.0012345s

12:34:57, +00.0009876s

...

 

 表示时间同步链路已恢复正常。 

 

 是否方便告诉我你的域控制器是在 VMware 还是 Hyper-V 环境中？ 我可以针对该平台提供具体的“禁用虚拟机时间同步”的操作步骤。 

 非常好！🎉 现在域控制器（S-DNS1）已经完全恢复成一个 健康、权威的时间源 。从输出可以确认一切工作正常： 

 

 ✅ 关键信息分析 

 Leap 指示符: 0(无警告) → 正常同步状态

层次: 3 (次引用 - 与(S)NTP 同步) → 已从外部 NTP 获取时间

源: cn.pool.ntp.org,0x8 → 当前时间来源为中国 NTP 池

 

 说明： 

 

 

 DC 不再依赖 “VM IC Time Synchronization Provider”； 

 

 

 已成功与外部网络时间源同步； 

 

 

 将作为域内 权威时间源（reliable time source） 向下游域成员提供时间。 

 

 

 

 🧭 下一步：客户端重新同步 

 在你的客户端（ 7000 ）主机上执行以下命令： 

 net stop w32time

net start w32time

w32tm /config /syncfromflags:domhier /update

w32tm /resync /force

 

 然后查看结果： 

 w32tm /query /source

w32tm /query /status

 

 正常情况下你会看到类似： 

 Source: S-DNS1.shuncom.local

Leap 指示符: 0(无警告)

层次: 4 (次引用 - 与域控制器同步)

 

 这时整个域的时间层级链路如下： 

 Internet NTP (time.windows.com / cn.pool.ntp.org)

 ↓

PDC S-DNS1 (Stratum 3, Reliable Time Source)

 ↓

域成员（如 7000 主机）(Stratum 4)

 

 

 🔧 可选验证命令 

 确认客户端确实能和 DC 通信： 

 w32tm /stripchart /computer:S-DNS1.shuncom.local /dataonly /samples:5

 

 输出示例（正常）： 

 12:45:01, +00.0001234s

12:45:02, +00.0002345s

...

 

 

 ✅ 到此为止，你的域控与客户端时间同步体系已经修复完成。 是否需要我帮你再提供一份 “Windows 域时间同步架构与常见故障修复指南” （可以保存为 Word 或 PDF）？这份文档可用于今后类似场景快速排障。 

 非常好，你的排查已经进行到最后一步。现在情况非常明确： 

 

 🔍 当前状态总结 

 

 

 域控 S-DNS1 → ✅ 已正常同步外部 NTP（ cn.pool.ntp.org ），工作正常； 

 

 

 客户端 7000 → ❌ 仍然未从域控获得时间数据，显示： 

 此计算机没有重新同步，因为没有可用的时间数据。

Source: Local CMOS Clock

 

 

 

 这表明客户端虽然配置为从域层级（ domhier ）同步，但实际上并没有真正与域控制器的时间服务建立通信。 

 

 🧭 一、确认客户端确实“在域中”且能联系域控 

 请先执行： 

 nltest /sc_query:shuncom.local

 

 

 

 如果返回： 

 The command completed successfully

 

 表示安全通道正常。 

 

 

 如果返回错误（如 1355 或 1786），则是 安全通道中断 ，必须先修复（重新加入域或重建信任）。 

 

 

 

 ⚠️ 时间同步依赖 Netlogon 安全通道。如果域信任断开，即使 DNS 和 ping 都正常，也不会同步时间。 

 

 

 🧩 二、检查 w32time 的同步类型 

 执行： 

 reg query HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters /v Type

 

 输出应为： 

 Type REG_SZ NT5DS

 

 如果不是 NT5DS （例如是 NTP 或空），请修正为域模式： 

 w32tm /config /syncfromflags:domhier /update

 

 然后重启时间服务： 

 net stop w32time

net start w32time

 

 

 🧱 三、确保客户端能通过 UDP/123 与域控通信 

 测试： 

 w32tm /stripchart /computer:S-DNS1.shuncom.local /dataonly /samples:5

 

 

 

 ✅ 如果看到时间偏移输出（连续几行时间差值），说明网络通信没问题； 

 

 

 ❌ 如果全部超时（timeout），说明 UDP 123 被防火墙或安全软件拦截 。 

 

 

 请确保以下端口开放： 

 

 

 出站 UDP 123（客户端 → DC） 

 

 

 入站 UDP 123（DC → 客户端） 

 

 

 

 🔧 四、强制手动指定 NTP 源测试（验证能否通） 

 先在客户端直接与 DC 做一次手动同步测试： 

 w32tm /config /manualpeerlist:"S-DNS1.shuncom.local,0x8" /syncfromflags:manual /update

w32tm /resync /force

 

 如果成功，会显示： 

 正在重新同步此计算机...

命令已成功完成。

 

 再执行： 

 w32tm /query /source

 

 应变为： 

 S-DNS1.shuncom.local,0x8

 

 👉 如果这一步成功，则说明问题只在“域层级自动选择”（NT5DS）上，可以再切回 domhier 模式继续用。 

 

 ⚙️ 五、（如仍失败）重置时间服务组件 

 net stop w32time

w32tm /unregister

w32tm /register

net start w32time

w32tm /config /syncfromflags:domhier /update

w32tm /resync /force

 

 然后再看： 

 w32tm /query /source

 

 

 ✅ 正常完成后的预期 

 当一切恢复时，你将看到： 

 w32tm /query /source

S-DNS1.shuncom.local

w32tm /query /status

Leap 指示符: 0(无警告)

层次: 4 (次引用)

上次成功同步时间: <当前时间>

 

 

 请先发给我这条命令的输出： 

 nltest /sc_query:shuncom.local

 

 我可以马上告诉你是否是 安全通道问题 （这种情况在“时间无法同步但 DNS 正常”时非常常见）。 

 非常好，你的诊断信息非常完整 👍。从结果看出： 虽然 Win11 客户机 已经成功与域控 S-DNS1.shuncom.local 建立同步源 ，但时间仍有较大误差（ 相差约 75 秒以上 ）。这说明同步服务逻辑通了，但 时间未真正对齐 。 

 

 🔍 一、确认问题核心 

 从以下输出判断： 

 w32tm /query /status

层次: 4 (次引用 - 与(S)NTP 同步)

上次成功同步时间: 2025-10-16 12:14:04

源: S-DNS1.shuncom.local

 

 说明： 

 

 

 域控可达，协议正常（UDP 123 可通） 。 

 

 

 但 /stripchart 显示： 

 +81s → +75s

 

 表示客户端时间比域控 快 75~80 秒 ，且时间差在逐渐变化 → 表示同步过程 未立即校正本地时间 。 

 

 

 

 ⚙️ 二、原因分析 

 Windows 客户端默认使用以下机制： 

 

 

 若时间差 < 128 秒 → 只进行“平滑调整（slew）”，不会立刻跳变。 

 

 

 若时间差 > 128 秒 → 直接重置时间（step）。 

 

 

 但在你的场景里（75 秒误差），虽然小于 128 秒，但系统仍未“平滑”追上，可能是由于： 

 

 

 客户端 Windows Time 服务未设置为自动立即步进调整 ； 

 

 

 系统时钟漂移太快 （如主板 CMOS、虚拟机时间漂移）； 

 

 

 时间同步策略被组策略覆盖 ； 

 

 

 NTP 响应延迟或丢包 （根延迟和分散值较大， 145s 表示误差累积高）。 

 

 

 

 🧭 三、推荐修复步骤 

 ✅ 1. 确认域控时间准确 

 在 S-DNS1 域控上执行： 

 w32tm /query /source

w32tm /query /status

 

 确保： 

 

 

 域控同步源为外部 NTP（如 cn.pool.ntp.org 或 time.windows.com ） 

 

 

 状态为已同步 ( 层次: 3 或更低) 

 

 

 如未同步，请修复主域控时间源： 

 w32tm /config /manualpeerlist:"time.windows.com,0x8 cn.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update

net stop w32time && net start w32time

w32tm /resync /force

 

 

 ✅ 2. 在客户端（Win11）强制立即校正时间 

 执行以下命令彻底清理缓存并重置同步： 

 net stop w32time

w32tm /unregister

w32tm /register

net start w32time

w32tm /config /manualpeerlist:"S-DNS1.shuncom.local,0x8" /syncfromflags:manual /update

w32tm /resync /nowait

 

 若仍存在 75s 误差，可强制 step 调整： 

 w32tm /resync /rediscover /force

 

 或者： 

 w32tm /config /update

net stop w32time && net start w32time

 

 

 ✅ 3. 修改注册表（启用强制时间跳变） 

 若客户端仍缓慢同步，可强制允许直接校正时间（step）： 

 reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config /v MaxPosPhaseCorrection /t REG_DWORD /d 3600 /f

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config /v MaxNegPhaseCorrection /t REG_DWORD /d 3600 /f

net stop w32time && net start w32time

w32tm /resync /force

 

 这允许系统在误差 ±3600 秒内直接跳变修正时间。 

 

 ✅ 4. 验证结果 

 再次检查同步状态： 

 w32tm /query /status

w32tm /stripchart /computer:S-DNS1.shuncom.local /dataonly /samples:5

 

 你应看到： 

 +0.05s ~ +0.10s

 

 即可视为同步成功。 

 

 📘 四、建议长期策略 

 

 

 确保域控（PDC Emulator 角色）同步外部权威 NTP； 

 

 

 其他域控、成员服务器、客户端使用 NT5DS （即 domhier）模式； 

 

 

 确认防火墙开放 UDP 123； 

 

 

 若为虚拟机，建议 关闭宿主机自动同步时间 （由域控统一管理）。 

 

 

 

 是否希望我帮你写一份完整的 域控+客户端 NTP 同步修复脚本（PowerShell 版） ？ 可直接在两边运行，一键同步时间并验证结果。