这是 Windows AD PowerShell 学习记录的第九节，主要整理 AD 的时间层级、PDC Emulator 的外部时间源配置、w32tm 常用命令，以及 Kerberos 时间偏差的排查方法。

2026 年 9 月 22 日，本节通过 VMware Tools 在 QYNET-CORE01 上进行了只读实机核验。结果确认它是林根域 PDC Emulator，但当前没有配置外部 NTP，实际时间源为 Local CMOS Clock；QYNET-CORE02 在 w32tm /monitor 中没有响应。

文中标注“实机输出”的内容来自本次 VM。配置外部 NTP、重启服务、强制同步和恢复域层级等会改变状态的命令只作教学展示，本次均未执行。

九、时间同步#

9.1 为什么 AD 对时间如此敏感#

Kerberos 使用时间戳抵御重放攻击，因此参与认证的客户端、KDC 和目标服务必须保持时间接近。默认域策略中，“计算机时钟同步的最大容差”通常为 5 分钟；超过有效策略允许的偏差时，Kerberos 认证可能被拒绝。

⚠️ “5 分钟”是默认策略值，不是写死在所有环境中的常量。 管理员可以通过域策略修改它，因此排障时应检查实际生效策略；但不建议通过放宽容差长期掩盖时间源故障。

时间异常可能表现为：

域用户突然无法登录或访问共享。
Kerberos 出现 KRB_AP_ERR_SKEW。
klist get 申请服务票据失败。
GPO、计划任务、证书验证或安全日志时间异常。
多台服务器的事件顺序无法对应，增加复制和认证排障难度。

检查当前 Kerberos 时间容差策略：

1
secedit /export /cfg "$env:TEMP\secpol.cfg" | Out-Null
2

3
Select-String `
4
    -Path "$env:TEMP\secpol.cfg" `
5
    -Pattern "MaxClockSkew"
6

7
C:\Users\qianyue\AppData\Local\Temp\secpol.cfg:42:MaxClockSkew = 5

也可以生成组策略结果报告，确认设置来自哪个 GPO：

1
gpresult /scope computer /h "$env:TEMP\gpresult-time.html"
2

3
INFO: The computer policy report was saved to C:\Users\qianyue\AppData\Local\Temp\gpresult-time.html

策略路径为：

1
计算机配置
2
└─ Windows 设置
3
   └─ 安全设置
4
      └─ 账户策略
5
         └─ Kerberos 策略
6
            └─ 计算机时钟同步的最大容差

9.2 域内时间同步层级#

Active Directory 默认使用域层级同步时间，而不是让每台计算机都直接访问公网 NTP。

1
可靠的外部 NTP / 内部硬件时钟
2
                ↓
3
林根域 PDC Emulator
4
                ↓
5
各子域 PDC Emulator / 其他域控制器
6
                ↓
7
成员服务器与客户端

更准确地说：

林根域的 PDC Emulator 位于整个林默认时间层级的顶端，应同步到可靠的外部或组织内部权威时间源。
子域 PDC Emulator 沿父域层级寻找时间源，不应各自随意配置公网 NTP。
其他 DC 按域层级选择合适的 DC 作为时间源。
成员服务器和客户端通常从其认证 DC 或域层级中的 DC 同步。
工作组计算机没有 AD 时间层级，需要单独配置时间源。

域成员常见的同步类型为 NT5DS，表示从 AD 域层级获取时间；手工指定 NTP 时通常为 NTP。

💡 只在林根域 PDC Emulator 上配置外部时间源。 如果 FSMO 角色发生正常转移或强制夺取，应及时检查新 PDC 的时间配置，避免旧 PDC 仍对外授时，而新 PDC 退回本地硬件时钟。

PDC Emulator 与 FSMO 的查询方法见第四篇：域控与 FSMO。

9.3 先确认林根域 PDC Emulator#

当前域的 PDC Emulator，以下为实机输出：

1
Get-ADDomain |
2
    Select-Object DNSRoot,PDCEmulator
3

4
DNSRoot PDCEmulator
5
------- -----------
6
qy.net  QYNET-CORE01.qy.net

同时确认当前域是否为林根域：

1
$domain = Get-ADDomain
2
$forest = Get-ADForest
3

4
[pscustomobject]@{
5
    CurrentDomain = $domain.DNSRoot
6
    ForestRoot    = $forest.RootDomain
7
    PDCEmulator   = $domain.PDCEmulator
8
    IsForestRoot  = $domain.DNSRoot -eq $forest.RootDomain
9
}
10

11
CurrentDomain : qy.net
12
ForestRoot    : qy.net
13
PDCEmulator   : QYNET-CORE01.qy.net
14
IsForestRoot  : True

只有 IsForestRoot 为 True，并且目标服务器正是该域的 PDCEmulator 时，才属于默认应配置外部时间源的服务器。

在本机确认是否持有 PDC Emulator：

1
$pdc = (Get-ADDomain).PDCEmulator
2
$localFqdn = "{0}.{1}" -f $env:COMPUTERNAME,(Get-ADDomain).DNSRoot
3

4
[pscustomobject]@{
5
    LocalComputer = $localFqdn
6
    PDCEmulator   = $pdc
7
    IsPDC         = $localFqdn -ieq $pdc
8
}
9

10
LocalComputer : QYNET-CORE01.qy.net
11
PDCEmulator   : QYNET-CORE01.qy.net
12
IsPDC         : True

9.4 查询当前时间源与同步状态#

查看当前时间源，实机结果为本地硬件时钟：

1
w32tm /query /source
2

3
Local CMOS Clock

QYNET-CORE01 是林根域 PDC Emulator，此结果说明它尚未配置有效的外部时间源。成员机或非 PDC 域控通常应沿域层级显示某台 DC，例如下面的教学示例：

1
w32tm /query /source
2

3
QYNET-CORE01.qy.net

以下输出需要重点警惕：

输出	常见含义
`Local CMOS Clock`	当前使用本机硬件时钟，域成员或林根 PDC 通常需要继续检查
`Free-running System Clock`	没有有效同步源，系统时钟自行运行
`VM IC Time Synchronization Provider`	正从虚拟化宿主机同步，需要确认是否符合 DC 的时间设计
DC 的 FQDN	正沿域层级同步，成员机和非根 PDC 通常正常
外部 NTP 名称	林根域 PDC 上通常正常；普通域成员上应核对是否误配

查看详细状态：

1
w32tm /query /status
2

3
Leap 指示符: 0(无警告)
4
层次: 1 (主引用 - 与无线电时钟同步)
5
精度: -6 (每刻度 15.625ms)
6
根延迟: 0.0000000s
7
根分散: 10.0000000s
8
引用 ID: 0x4C4F434C (源名称: "LOCL")
9
上次成功同步时间: 2026/9/22 15:10:25
10
源: Local CMOS Clock
11
轮询间隔: 6 (64s)

这里的 Stratum: 1 不代表已经连接高精度外部时钟；ReferenceId 为 LOCL，再次证明当前使用的是本地时钟。

常用字段：

字段	含义	排查重点
`Leap Indicator`	时间源告警状态	`3` 通常表示未同步
`Stratum`	当前时间源层级	数值异常或为 0 时继续核查
`Last Successful Sync Time`	最近成功同步时间	是否长时间没有更新
`Source`	当前实际时间源	是否符合域时间设计
`Poll Interval`	轮询间隔	是否与策略和预期一致

w32tm /query /source 显示的是当前实际选择的源，/query /configuration 显示的是配置。两者都要看：配置了某个 NTP，不代表它当前一定同步成功。

9.5 查询完整配置与对等时间源#

1
w32tm /query /configuration
2

3
[配置]
4

5
EventLogFlags: 2 (本地)
6
AnnounceFlags: 10 (本地)
7
TimeJumpAuditOffset: 28800 (本地)
8
MinPollInterval: 6 (本地)
9
MaxPollInterval: 10 (本地)
10
MaxNegPhaseCorrection: 172800 (本地)
11
MaxPosPhaseCorrection: 172800 (本地)
12
MaxAllowedPhaseOffset: 300 (本地)
13

14
[TimeProviders]
15

16
NtpClient (本地)
17
DllName: C:\Windows\system32\w32time.dll (本地)
18
Enabled: 1 (本地)
19
InputProvider: 1 (本地)
20
SpecialPollInterval: 3600 (本地)
21
Type: NT5DS (本地)
22

23
NtpServer (本地)
24
DllName: C:\Windows\system32\w32time.dll (本地)
25
Enabled: 1 (本地)
26
InputProvider: 0 (本地)
27

28
VMICTimeProvider (本地)
29
DllName: C:\Windows\System32\vmictimeprovider.dll (本地)
30
Enabled: 1 (本地)
31
InputProvider: 1 (本地)

实机配置中的 Type: NT5DS 表示它仍尝试沿域层级找时间源。然而它本身就是林根域 PDC，域层级上方没有其他服务器，因此最终使用 Local CMOS Clock。

关注配置值右侧的来源；不同系统语言会显示为 (Local) / (Policy) 或 (本地) / (策略)：

(Local) / (本地)：来自本地配置。
(Policy) / (策略)：来自组策略，手工修改后可能再次被 GPO 覆盖。

查看已配置的时间对等点及状态：

1
w32tm /query /peers
2

3
#对等数: 1
4

5
对等:
6
状态: 挂起
7
剩余时间: 792.4958760s
8
模式: 0 (保留)
9
层次: 0 (未指定)
10
对等机轮询间隔: 0 (未指定)
11
主机轮询间隔: 0 (未指定)

这里虽然显示“对等数 1”，却没有对等服务器名称，状态也是“挂起”，不能据此认为已配置可用 NTP。

0x8 表示以 NTP Client 模式向目标发起请求，适合大多数外部 NTP 服务。

常见标志可以组合：

标志	含义
`0x1`	使用 `SpecialPollInterval` 指定的特殊轮询间隔
`0x2`	只作为备用时间源
`0x4`	Symmetric Active 模式
`0x8`	Client 模式

例如 0x9 等于 0x8 + 0x1，表示 Client 模式并使用特殊轮询间隔。

9.6 测量时间偏差#

使用 stripchart 连续比较本机与目标时间源。本次实机无法解析 ntp.aliyun.com：

1
w32tm /stripchart /computer:ntp.aliyun.com /samples:5 /dataonly
2

3
发生下列错误: 这是在主机名解析时通常出现的暂时错误，
4
它意味着本地服务器没有从权威服务器上收到响应。 (0x80072AFA)

结合前面的配置查询，可以确认当前没有外部 NTP；而这次失败还说明，在正式配置前必须先处理外部 DNS 解析，或改用组织内部可解析的权威时间源。

正值或负值表示两台计算机时钟的相对偏差方向，重点关注绝对值是否持续增大或接近策略容差。

比较客户端与域控：

1
w32tm /stripchart /computer:QYNET-CORE01.qy.net /samples:5 /dataonly
2

3
正在跟踪 QYNET-CORE01.qy.net [[fe80::dd1b:2adc:aa3b:ad0c%4]:123]。
4
正在收集 5 示例。
5
当前时间是 2026/9/22 15:12:27。
6
15:12:27, +00.0000259s
7
15:12:29, +00.0002162s
8
15:12:31, +00.0002297s
9
15:12:33, +00.0000817s
10
15:12:35, +00.0000961s

这是 PDC 与自身的比较，只能证明本机 NTP 服务能够响应，不能证明它已经同步到外部权威源。

检查域内所有 DC：

1
w32tm /monitor /domain:qy.net
2

3
QYNET-CORE01.qy.net *** PDC *** [[fe80::dd1b:2adc:aa3b:ad0c%4]:123]:
4
    ICMP: 0ms 延迟
5
    NTP: +0.0000000s 偏移起点 QYNET-CORE01.qy.net
6
        RefID: 'LOCL' [0x4C434F4C]
7
        层次: 1
8
QYNET-CORE02.qy.net [192.168.254.11:123]:
9
    ICMP: 错误 IP_REQ_TIMED_OUT - 没有响应 1000ms
10
    NTP: 错误 ERROR_TIMEOUT - 1000ms 内服务器没有响应

实机结果记录了两个现象：QYNET-CORE01 的 RefID 是 LOCL，与尚未配置外部 NTP 的现状一致；QYNET-CORE02 的 ICMP 和 NTP 均超时。后者应在 CORE02 开机并可达时，再判断是否需要检查 W32Time 服务、防火墙和 UDP 123。

/monitor 不会自动以颜色标出故障，需要管理员自己检查错误文字、偏差、Stratum 和 RefID。

9.7 触发重新同步#

以下命令会触发时间同步，本次仅保留操作格式，没有在 VM 上执行：

标准的立即重新同步命令：

1
w32tm /resync
2

3
Sending resync command to local computer
4
The command completed successfully.

如果怀疑网络或时间源发现缓存异常，可以重新发现时间源后再同步：

1
w32tm /resync /rediscover
2

3
Sending resync command to local computer
4
The command completed successfully.

⚠️ w32tm /resync /force 不是 Windows w32tm 文档中的标准语法。 常用有效参数包括 /nowait、/rediscover 和 /soft。想重新发现域时间源时使用 /rediscover，不要把其他工具的 force 参数套到 w32tm 上。

“命令成功”只表示 W32Time 接受并完成了同步请求，仍应再次验证：

1
w32tm /query /source
2
w32tm /query /status

常见失败：

1
w32tm /resync /rediscover
2

3
Sending resync command to local computer
4
The computer did not resync because no time data was available.

此时反复执行 /resync 没有意义，应检查：

DNS 是否能解析时间源。
UDP 123 是否可达。
Windows Time 服务是否正在运行。
Type、NtpServer 和组策略配置是否正确。
时间源本身是否响应 NTP。
当前偏差是否超过允许自动修正的范围。

9.8 在林根域 PDC 配置外部 NTP#

本节是后续配置方案，本次没有执行。当前实机仍使用 Local CMOS Clock。

先确认角色和原配置，并记录变更前状态：

1
Get-ADDomain | Select-Object DNSRoot,PDCEmulator
2
w32tm /query /source
3
w32tm /query /configuration
4
w32tm /query /peers

确认当前服务器是林根域 PDC Emulator 后，以管理员身份执行：

1
w32tm /config `
2
    /syncfromflags:manual `
3
    /manualpeerlist:"ntp.aliyun.com,0x8" `
4
    /reliable:yes `
5
    /update
6

7
The command completed successfully.
8

9
Restart-Service W32Time
10

11
w32tm /resync /rediscover
12

13
Sending resync command to local computer
14
The command completed successfully.

/reliable:yes 将本机标记为域内可靠时间源，只应在承担该职责的服务器上使用。公网 NTP 数据本身通常不经过 AD 身份验证；生产环境应依据组织安全要求选择内部权威时钟、硬件源或可信的多个上游。

为避免单点依赖，可以配置多个经过验证的时间源：

1
w32tm /config `
2
    /syncfromflags:manual `
3
    /manualpeerlist:"ntp1.example.net,0x8 ntp2.example.net,0x8" `
4
    /reliable:yes `
5
    /update
6

7
Restart-Service W32Time
8
w32tm /resync /rediscover

上面的 example.net 仅表示格式，不能直接作为生产时间源。应替换为组织批准且可从 PDC 访问的服务器。

配置完成后的预期验证格式如下；这不是当前 VM 的实机结果：

1
w32tm /query /source
2

3
ntp.aliyun.com,0x8
4

5
w32tm /query /peers
6

7
#Peers: 1
8
Peer: ntp.aliyun.com,0x8
9
State: Active
10

11
w32tm /query /status
12

13
Leap Indicator: 0(no warning)
14
Last Successful Sync Time: 9/22/2026 14:31:02
15
Source: ntp.aliyun.com,0x8

为什么不使用 `net stop w32time && net start w32time`#

&& 是传统 CMD 和 PowerShell 7 支持的条件连接符，但 Windows Server 2016 默认的 Windows PowerShell 5.1 不支持该语法。笔记中的命令应能直接在 Windows PowerShell 5.1 执行：

1
Restart-Service W32Time

如果在 CMD 中执行，也可以分两行：

1
net stop w32time
2
net start w32time

9.9 让普通域成员恢复域层级同步#

以下为恢复配置示例，本次没有在任何 DC 或成员机上执行：

如果成员机或非林根 PDC 曾被手工配置为公网 NTP，应恢复 NT5DS 域层级：

1
w32tm /config `
2
    /syncfromflags:domhier `
3
    /reliable:no `
4
    /update
5

6
The command completed successfully.
7

8
Restart-Service W32Time
9

10
w32tm /resync /rediscover
11

12
Sending resync command to local computer
13
The command completed successfully.

验证配置与当前源：

1
w32tm /query /configuration | Select-String "Type:"
2

3
Type: NT5DS (Local)
4

5
w32tm /query /source
6

7
QYNET-CORE01.qy.net

如果输出仍显示原来的公网 NTP，应检查是否有 GPO 持续下发配置：

1
w32tm /query /configuration | Select-String "Type:|NtpServer:"
2

3
Type: NTP (Policy)
4
NtpServer: ntp.example.net,0x8 (Policy)

出现 (Policy) 时，应修改对应 GPO，而不是反复修改本地设置。

9.10 检查 Windows Time 服务与事件日志#

1
Get-Service W32Time
2

3
Status   Name               DisplayName
4
------   ----               -----------
5
Running  W32Time            Windows Time

以上为 QYNET-CORE01 的实机结果，服务启动类型为 Automatic。

如果服务停止：

1
Start-Service W32Time
2

3
Get-Service W32Time
4

5
Status   Name               DisplayName
6
------   ----               -----------
7
Running  W32Time            Windows Time

查看最近 24 小时的 Time-Service 警告和错误：

1
$startTime = (Get-Date).AddDays(-1)
2

3
Get-WinEvent -FilterHashtable @{
4
    LogName      = "System"
5
    ProviderName = "Microsoft-Windows-Time-Service"
6
    StartTime    = $startTime
7
} |
8
    Where-Object LevelDisplayName -In "Warning","Error" |
9
    Select-Object TimeCreated,Id,LevelDisplayName,Message
10

11
TimeCreated          Id LevelDisplayName Message
12
-----------          -- ---------------- -------
13
2026/9/22 15:10:34  12 Warning          时间提供程序 NtpClient: 此机器配置为用域层级确定它的时间源，
14
                                        但它已经是在林的根目录域的 AD PDC 仿真，因此在域层级
15
                                        没有机器在它上面以用作时间源……

这是实机日志。相同的 Event ID 12 在 9 月 20 日、21 日和 22 日均有记录，说明这不是一次性启动抖动，而是当前持续存在的“林根域 PDC 尚未配置外部上游”状态。

实机还记录了时间服务开始播发的信息事件：

1
Get-WinEvent -FilterHashtable @{
2
    LogName      = "System"
3
    ProviderName = "Microsoft-Windows-Time-Service"
4
    StartTime    = $startTime
5
} |
6
    Select-Object -First 20 TimeCreated,Id,LevelDisplayName,Message
7

8
TimeCreated          Id LevelDisplayName Message
9
-----------          -- ---------------- -------
10
2026/9/22 15:10:25 143 Information      时间服务已开始作为良好的时间源播发。
11
2026/9/22 15:10:25 139 Information      时间服务已开始作为时间源播发。

“正在播发时间”不等于“已经同步外部权威时间”。当前 PDC 正把自己的本地 CMOS 时间作为域内来源发布，因此必须把事件日志与 /query /source、RefID 一起判断。

事件 ID 在不同版本和场景中含义可能不同，应结合完整消息、当前配置与状态判断，不要只凭编号下结论。

9.11 网络与虚拟化注意事项#

本节为排障说明，没有修改 VM 的虚拟化时间集成设置或防火墙。

Windows Time 使用 NTP，通常需要 UDP 123。Test-NetConnection -Port 测试的是 TCP，不能用下面这种命令证明 NTP 可用：

1
# 这只能测试 TCP 123，不等于 NTP 的 UDP 123
2
Test-NetConnection ntp.aliyun.com -Port 123

更直接的应用层验证是观察：

1
w32tm /stripchart /computer:ntp.aliyun.com /samples:5 /dataonly
2
w32tm /query /peers
3
w32tm /resync

如果这些命令没有时间数据，再检查主机防火墙、出口 ACL、NAT 和上游 NTP 服务。

虚拟化 DC 还要防止宿主机时间与 AD 时间层级相互竞争：

1
w32tm /query /source
2

3
VM IC Time Synchronization Provider

若 DC 长期显示虚拟化时间提供程序，应核对 Hyper-V、VMware 或其他平台的来宾时间同步策略。尤其是林根域 PDC，应按设计从权威上游获取时间，避免宿主机错误时间传播到整个域。调整虚拟化集成服务前，应确认平台版本、备份恢复机制和厂商建议。

9.12 三个典型故障案例#

除特别注明外，以下是教学案例，不代表此次 VM 的实际状态。

案例一：所有域用户突然出现认证失败#

先比较客户端与 DC：

1
Get-Date
2

3
Tuesday, September 22, 2026 3:08:42 PM
4

5
w32tm /stripchart /computer:QYNET-CORE01.qy.net /samples:3 /dataonly
6

7
Tracking QYNET-CORE01.qy.net [10.0.0.10:123].
8
15:08:43, +00:07:12.4210874s
9
15:08:45, +00:07:12.4209221s
10
15:08:47, +00:07:12.4211058s

偏差已超过默认五分钟容差，应先查客户端与 DC 的时间源。如果多台设备同时异常，继续向上检查 PDC 与其外部源，而不是逐台重置用户密码。

1
w32tm /query /source
2
w32tm /query /status
3

4
$pdc = (Get-ADDomain).PDCEmulator
5
Invoke-Command -ComputerName $pdc -ScriptBlock {
6
    w32tm /query /source
7
    w32tm /query /status
8
}

案例二：成员机总是改回错误的公网 NTP#

1
w32tm /query /configuration | Select-String "Type:|NtpServer:"
2

3
Type: NTP (Policy)
4
NtpServer: old-ntp.example.net,0x8 (Policy)

(Policy) 说明设置由组策略控制。应使用 gpresult 找到来源 GPO，并在策略中修复；本地执行 /config /syncfromflags:domhier 只会暂时改变状态或直接被策略覆盖。

案例三：迁移 PDC 后新 PDC 使用本地硬件时钟#

1
Get-ADDomain | Select-Object PDCEmulator
2

3
PDCEmulator
4
-----------
5
QYNET-CORE02.qy.net
6

7
Invoke-Command -ComputerName QYNET-CORE02 -ScriptBlock {
8
    w32tm /query /source
9
}
10

11
Local CMOS Clock

FSMO 角色已经迁移，但新 PDC 没有可靠上游。应在新 PDC 上配置经过批准的时间源并验证，再把旧 PDC 恢复为域层级同步，避免形成两个“权威”源。

9.13 推荐排查顺序#

Get-Date：确认肉眼可见的日期、时区和时间是否异常。
Get-ADDomain / Get-ADForest：确认林根域与当前 PDC Emulator。
w32tm /query /source：确认当前实际时间源。
w32tm /query /status：确认最近成功同步时间和状态。
w32tm /query /configuration：区分本地配置与组策略。
w32tm /query /peers：确认配置的上游是否 Active。
w32tm /stripchart：测量与 DC 或上游源的实际偏差。
w32tm /monitor /domain:<域>：比较所有 DC 的偏差和 RefID。
检查 W32Time 服务、System 日志、DNS 与 UDP 123。
修复根因后使用 w32tm /resync /rediscover，再重复查询验证。
如果修改了林根 PDC 配置，再从非 PDC DC 和普通客户端逐层验证。

域时间排障应沿着“客户端 → 本域 DC → 域 PDC → 父域 → 林根域 PDC → 权威上游”逐层追踪。只有林根域 PDC 应默认直接配置外部时间源。

9.14 常用命令速查#

命令	作用
`w32tm /query /source`	查看当前实际时间源
`w32tm /query /status`	查看当前同步状态
`w32tm /query /configuration`	查看完整配置及配置来源
`w32tm /query /peers`	查看手工配置的时间对等点
`w32tm /stripchart /computer:<目标>`	连续测量与目标的时间偏差
`w32tm /monitor /domain:<域>`	查看域内 DC 的时间状态
`w32tm /resync`	请求立即重新同步
`w32tm /resync /rediscover`	重新发现时间源并同步
`w32tm /config /syncfromflags:domhier /update`	恢复 AD 域层级同步
`Restart-Service W32Time`	在 PowerShell 中重启 Windows Time 服务

参考资料#

上一篇：Windows AD PowerShell（八）：Kerberos 与票据

下一篇：Windows AD PowerShell（十）：事件日志

音乐

音乐

九、时间同步#

9.1 为什么 AD 对时间如此敏感#

9.2 域内时间同步层级#

9.3 先确认林根域 PDC Emulator#

9.4 查询当前时间源与同步状态#

9.5 查询完整配置与对等时间源#

9.6 测量时间偏差#

9.7 触发重新同步#

9.8 在林根域 PDC 配置外部 NTP#

为什么不使用 `net stop w32time && net start w32time`#

9.9 让普通域成员恢复域层级同步#

9.10 检查 Windows Time 服务与事件日志#

9.11 网络与虚拟化注意事项#

9.12 三个典型故障案例#

案例一：所有域用户突然出现认证失败#

案例二：成员机总是改回错误的公网 NTP#

案例三：迁移 PDC 后新 PDC 使用本地硬件时钟#

9.13 推荐排查顺序#

9.14 常用命令速查#

参考资料#

支持与分享

音乐

文章目录

音乐

音乐

Windows AD PowerShell（九）：时间同步

九、时间同步#

9.1 为什么 AD 对时间如此敏感#

9.2 域内时间同步层级#

9.3 先确认林根域 PDC Emulator#

9.4 查询当前时间源与同步状态#

9.5 查询完整配置与对等时间源#

9.6 测量时间偏差#

9.7 触发重新同步#

9.8 在林根域 PDC 配置外部 NTP#

为什么不使用 net stop w32time && net start w32time#

9.9 让普通域成员恢复域层级同步#

9.10 检查 Windows Time 服务与事件日志#

9.11 网络与虚拟化注意事项#

9.12 三个典型故障案例#

案例一：所有域用户突然出现认证失败#

案例二：成员机总是改回错误的公网 NTP#

案例三：迁移 PDC 后新 PDC 使用本地硬件时钟#

9.13 推荐排查顺序#

9.14 常用命令速查#

参考资料#

支持与分享

音乐

文章目录

为什么不使用 `net stop w32time && net start w32time`#