我有一个有两个DC的Active Directory域。 森林/域中的第一个DC是Server 2012，第二个是2008 R2。 第一个DC保存PDC模拟器angular色。
我偶尔会收到来自Time-Service源的警告，事件ID 50：
The time service detected a time difference of greater than %1 milliseconds for %2 seconds. The time difference might be caused by synchronization with low-accuracy time sources or by suboptimal network conditions. The time service is no longer synchronized and cannot provide the time to other clients or update the system clock. When a valid time stamp is received from a time service provider, the time service will correct itself.
在域中的时间同步configuration与第二个DC使用/syncfromflags:DOMHIER标志进行同步。 第一个DC被configuration为使用来自由诸如ntp2d.mcc.ac.uk的许多基于英国的层2服务器组成的对等列表的/syncfromflags:MANUAL /reliable:YES来同步时间。
我很困惑，为什么我收到这个事件的警告。 这意味着我的PDC模拟器无法与一个可靠的外部时间源同步时间，并且它引用900秒的时间差> 5秒。 值得一提的是，我曾经在ntp.org使用过英国的游泳池，但是我会经常收到警告。 由于更新了一些英国学术时间服务器，似乎更可靠。
能有更多经验的人可以对此有所了解 – 也许这纯粹是短暂的？ 我应该忽视警告吗？ 我的configuration是否正常？
编辑 ：
我应该补充一点，DC是虚拟的，并且安装在两个独立的VMware ESXi / vSphere物理主机上。
因为： c:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe timesync status返回Disabled禁用，所以我也可以确认，根据MDMarra的评论和最佳实践，VMware时间同步被禁用。
编辑2
一些奇怪的新问题出现了。 我注意到了一种模式。 最初，事件ID 50警告将在每天下午12:30左右发生。 这是有趣的，因为我们的veeam备份发生在中午12点。
由于我在这里讨论了这些变化，现在我收到一个事件ID 51而不是50.新的警告说：
The time sample received from peer server.ac.uk differs from the local time by -40 seconds
（或大约40秒）。 这已经发生了两天了。 现在我更加困惑了。 显然时间不会更新，直到我手动干预。
这个问题似乎与虚拟化和veeam有关。 当veeam正在备份PDCe时，可能会发生一些事情。 有什么build议么？
更新和总结
msemack下面的资源（接受的答案）提供了足够的信息来正确configuration域中的时间服务。 这应该是任何未来的人都希望validation他们的configuration的第一个端口。
通过调整VMware时间同步设置，我已经解决了最后的“40秒跳转”问题（没有更多的警告），如以下的veeam知识库文章所述： http : //www.veeam.com/kb1202
在任何情况下，如果将来的读者使用ESXi（不pipe是否为veeam），这里的资源都是关于时间同步主题的极好信息来源，而msemack的答案是非常宝贵的。
这是我推荐的Windows域时间同步configuration，从几个Microsoft TechNet文章和博客文章拼凑在一起。
如果您的服务器是虚拟化的， 请不要使用任何VMware工具的时间同步function。 只要让Windows时间服务（W32time）完成它的工作。 VMware甚至这样说。 我认为Hyper-V也是如此。 此外，如果您的VM工具和 Windows时间服务都尝试pipe理系统时钟，那么最终会出现“拔河”的情况，您的时钟将不断跳转，从而不准确。
您的主域控制器模拟器应手动configuration为与多个外部NTP服务器同步（四是一个好的数字）。 使用多个NTP源提供冗余，并在一台服务器开始发送不良时间数据（ 之前已经发生 ）的情况下用作完整性检查。 Active Directory假定您的PDCe是您的networking的中央授权时间源。 您域中的其他所有内容都应该从PDCe（包括其他域控制器）进行同步。
我build议你的PDCe是一个物理服务器（如果可能的话）。 其他每台服务器都可以是一台虚拟机 我觉得PDCe是一个物理服务器更舒服，原因有二：
3A。 物理服务器不太容易出现时间漂移。 VM时间漂移是一个有据可查的现象。 虚拟化服务器每天可以看到其时钟漂移几分钟。 时间源不是一个好的select！ （请注意，即使在物理服务器上，实时时钟仍然会每天漂移大约2秒，而无需外部源，这就是为什么您需要NTP。）
3B。 我知道冷启动后，物理服务器的date/时间将会正确启动。 几年前，在服务器机房完全closures的情况下，我遇到了一种情况：虚拟机的时间设置为UTC，而不是当地时区。 我认为他们从ESX主机（使用UTC）中抽出时间，并没有适当调整时区。 由于服务无法启动，导致各种各样的乐趣。 必须手动纠正时间，并重新启动每个人。
如果您的PDCe当前是虚拟机，并且您具有可用的物理域控制器，则将angular色转移过来相对比较容易 。
Microsoft（和其他）build议您使用Stratum 2或Stratum 3 NTP服务器作为您的PDCe的时间源。
虽然存在公共的Stratum 1服务器，但是它们的数量有限，而且它们的负载过重了很多。 使用Stratum 1服务器作为时间源，当你不需要它的时候会让你变成一个混蛋。 （是的，有些人真的需要Stratum 1，你可能不是其中的一员，如果你真的想使用Stratum 1来源，那么买一个你的本地networking的GPS时钟。）
所有的外部NTP源应该在同一层。 假设你有一个Stratum 2来源和几个Stratum 3来源。 Windows时间服务将有利于Stratum 2源。 您的PDCe将成为Stratum 3服务器。 w32time会忽略Stratum 3服务器（因为它们不如你的PDCe）。 Windows不会让您的服务器降级到更高/更差的层次，而无需人工干预（例如，重新启动时间服务）。 所以，如果你的Stratum 2资源脱机，你将会陷入无法退后的境地。
由于Windows时间服务对时间源的Stratum很挑剔，我不build议使用pool.ntp.org （至less不要用于PDCe）。 无法保证从服务器获得的服务器层次。
相反，我build议你从ntp.org列表中select4台Stratum 2服务器。 尝试挑选与您身体接近的人（networking延迟损害NTP）。 validation服务器是否仍然有效（此列表随时间而改变）。 注意微软的默认time.windows.com是臭名昭着的问题。 我不会相信我的域名。
如果您之前一直在使用Windows时间服务，或者从其他人那里inheritance了此networking，则在开始重新configuration之前将w32time重置为默认设置可能是一个好主意。 在您的域控制器上运行以下命令，从PDCe开始。
net stop w32time w32tm /unregister <-- If you get an Access Denied message, reboot. w32tm /register net start w32time
我build议您在运行这些命令后重新启动服务器1-2次，并确保Windows时间服务存在，设置为自动，然后启动。 我看过/ unregister命令在下面的重新启动之前没有生效的情况。 那么当你在做Windows补丁之后重新启动时，你会感到惊讶，并且w32time服务突然失效了！
要在您的PDCe上configurationWindows时间服务，我build议您创build一个使用WMIfilter为DomainRole = 5的PDCe特定的GPO，并将所有NTP客户端设置放在此处。 否则，您可以使用w32tm命令，或手动设置registry。 在这里看到所有三种方法的例子。
将PDCeconfiguration为使用NTP而不是NT5DS（Windows时间服务configuration中的Type = NTP）。 否则，PDCe将尝试与自己同步，这将不会工作得很好。
在Windows时间服务configuration（在GPO，registry或w32tm）中inputNTP服务器列表，请确保您以此格式input服务器列表： server1.whatever.com,0x9 server2.otherplace.com,0x9 server3.another.com,0x9 。 每个服务器末尾的0x9标志指示使用SpecialPollInterval（0x1）中指定的轮询间隔，并且时间同步是仅客户端，而不是双向同步（0x8）。
configurationPDCe NTP客户端时，请检查SpecialPollInterval的值。 如果您的PDCe是物理盒子，请将其设置为3600秒（每小时一次）。 如果你的PDCe是一个虚拟机，select一些更积极的东西，比如每15分钟，以对抗VM时间漂移。
一般来说，你不需要搞乱AnnounceFlags 。 默认值10对所有域控制器（PDCe或其他）都有效。 如果合适的话，它会自动发布时间源。
我build议所有域控制器（PDCe和其他）都启用NTP服务器。 我会为域控制器创build一个GPO并在那里启用它。 如果您不想使用组策略，可以在HKLM \ SYSTEM \ CCS \ Services \ W32Time \ TimeProviders \ NtpServer \ Enabled = 0x1registry中执行此操作。
确保MaxPosPhaseCorrection和MaxNegPhaseCorrection在所有的域控制器上设置为一个合理的值！ 这将保护您的域名，以防您的外部NTP源中的一个在杂草中消失，并广播一个极不准确的时间戳（ 已经发生 ）。 如果您是Win2008或更高版本，默认情况下这些限制应该设置为48小时，但是Win2003将这些限制设置为无限制。 您可以在前面提到的域控制器GPO中进行设置，也可以直接在registry中进行设置（HKLM \ SYSTEM \ CCS \ Services \ W32Time \ Config）。
对于域控制器，我也build议你设置EventLogFlags = 0x3。 这可以让您更深入地了解随时间推移的同步进度。 请注意，有两个EventLogFlags值要设置。 一个是在HKLM \ SYSTEM \ CCS \ Services \ W32Time \ Config下（对于所有的域控制器）。 另一个是在HKLM \ SYSTEM \ CCS \ Services \ W32Time \ TimeProviders \ NtpClient下（仅与PDCe相关）。 两者都可以通过组策略进行pipe理。 我将它们都设置为0x3。 （请注意，我发现TechNet和组策略描述之间对此设置的描述有些不一致。）
除了一台PDCe之外，域上的其他每台Windows机器都应设置为使用NT5DS Domain Hierarchy进行时间同步。 这包括所有其他域控制器，任何其他服务器和工作站。 NT5DS是join域的计算机的默认设置，所以你不需要搞砸它。
请注意，我在域中唯一与时间相关的设置是（1）带有WMIfilter的PDCe NTP客户端GPO和（2）启用NTP服务器的域控制器GPO，设置最大相位校正值和EventLogFlags。 所有组策略时间设置都可以在“计算机configuration\pipe理模板\系统\ Windows时间服务”下find。 我没有任何显式的configuration在registry中或w32tm命令。 我build议使用组策略这个东西，所以它超越了实际的服务器。 如果将来添加新的域控制器，或者replace您的PDCe，则所有内容都将“正常工作”。 否则，你必须记得手动configuration新的服务器。
关于上述configuration的一些附加说明：
虽然有可能绕过域的层次结构，并明确地configuration您的客户端同步到某个服务器，但我有这运气不好。 我build议你在NT5DS上只保留除PDCe以外的所有内容，并让时间服务按照Microsoft的要求工作。
请记住，Windows时间服务适用于您的系统时钟的小型次要定期更正。 假设你的服务器的时钟已经正确设置，w32time将保持这种方式。 如果你的服务器与你的外部NTP源很不一致，那么它几乎会“放弃”。 如果您遵循了上述build议，则应该保持与外部时间源的同步。 但是，如果您的虚拟机环境的时间漂移非常糟糕（VM主机过载，常量快照），则可能仍然不同步。 如果是这样，有几个设置“尖峰检测”，你可以调整。 这可能是一个在你的环境中的另一个问题的创可贴。 在深入研究设置之前，确保已经实施了上述所有build议！
应用configuration更改并检查一切：
如果您使用组策略来configuration时间服务，则更改应尽快传播到所有域控制器。 您可以在每个域控制器上运行gpupdate /force命令（从PDCe开始）立即执行。
如果您决定不使用组策略并使用w32tm手动configuration时间服务，或者通过编辑registry，请确保在每个受影响的服务器上运行w32tm /config /update ，然后重新启动服务（从PDCe开始）。 否则你的设置将不会生效！
接下来，在PDCe上运行w32tm /resync /rediscover 。 等待几分钟，然后查看事件查看器中的问题。 从注销/注册时间服务可能会有一些错误/警告消息，但之后，一切都应该是黄金。 您应该看到有关从NTP服务器获取有效时间数据的消息。 一旦你确定PDCe是好的，进入其他域控制器并运行相同的命令。
一旦时间服务在所有数据中心同步，您可以做一个w32tm /monitor 。 确保列出了域控制器，并且它们的RefID和Stratum看起来正确。 如果您使用的是Stratum 2服务器，则您的PDCe应该是Stratum 3.您也可以运行w32tm /query /status /verbose （仅限Win2008或更高版本）并观察上次更新的时间。 确保它按预期更新。
一旦您的域控制器按顺序运行，在一些工作站和成员服务器上运行w32tm /resync /rediscover 。 检查事件查看器中的错误。 如果你对其他工作站上的时间服务感到困惑，那么你也可能需要在它们上运行w32tm注销/注册命令。
跟进：
为了完整起见，您应该确保所有非Windows NTP客户端（路由器，交换机，打印服务器等）都指向您的域控制器作为时间源。 我build议为ntp.yourdomain.com设置一个指向yourdomain.com的CNAME DNS条目。 这样，您不必在所有设备上明确列出域控制器名称或IP地址，这将在将来添加/退出服务器时提供帮助。 您的非Windows NTP客户端将使用循环DNS中出现的任何域控制器。 （请注意，只有在您的所有域控制器上启用了NTP服务器，这才起作用。）
另外，在您的DHCP服务器上，确保范围选项42被configuration为指向您的域控制器。 任何支持选项42的DHCPconfiguration设备都将自动与域控制器同步时间。
我的信息来源：
事件发生时，您可能想要查看w32tmdebugging日志中显示的内容。
要启用debugging日志logging：
w32tm /debug /enable /file:C:\Windows\Debug\w32tm.log /size:50000000 /entries:0-300
关于你的configuration是否健全，如果你的DC没有长时间作为时间服务器广告，那将是一个问题。 您可以通过以下命令来检查您的DC是否正在广告宣传：
nltest /dsgetdc:domain.com
它应该有TIMESERV标志。
您可以使用以下命令查看有关时间服务的详细信息：
w32tm /query /status /verbose
示例输出：
Leap Indicator: 0(no warning) Stratum: 2 (secondary reference - syncd by (S)NTP) Precision: -6 (15.625ms per tick) Root Delay: 0.0312500s Root Dispersion: 0.0314141s ReferenceId: 0x81060F1E (source IP: 129.6.15.30) Last Successful Sync Time: 3/25/2014 11:55:30 AM Source: time-c.nist.gov Poll Interval: 7 (128s) Phase Offset: 0.0000667s ClockRate: 0.0156001s State Machine: 2 (Sync) Time Source Flags: 0 (None) Server Role: 64 (Time Service) Last Sync Error: 0 (The command completed successfully.) Time since Last Good Sync Time: 97.2535519s
状态机应该是“同步”，服务器angular色应该是“时间服务”。 如果源不是对等列表中的外部NTP服务器，那将是一个问题。 已知不良的源条目要注意“自由运行系统时钟”或“本地CMOS时钟”。