我想知道是否有人可以推荐一种更好的方式来configuration一组Windows Server 2008 R2服务器的域时间同步，而不是我目前configuration的。 我有三个域控制器，都是Hyper-V guest虚拟机。 对于所有这些DC，集成服务的主机时间同步function被禁用。 DC被configuration为授权时间服务器，FSMO DC1服务器使用公共nist-a和nist-b服务器作为其时间源。 DC2，DC3以及此环境中的所有其他服务器（主机和来宾）都是该域的成员，并查看DC1的时间。 对于所有剩余的客人（即不是DC），启用集成服务的时间同步function。 这篇文章的原因是，我偶尔看到下一段中的消息，我想让我所有的服务器（包括主机和客户机）都尽可能的精确：
时间服务检测到900秒的时间差大于5000毫秒。 时差可能是由低精度时间源的同步或者不理想的networking条件造成的。 时间服务不再同步，不能将时间提供给其他客户端或更新系统时钟。 从时间服务提供商接收到有效的时间戳时，时间服务将自行更正。
如果某人与虚拟化DC有类似的设置，并且已经在域中的所有服务器上实现了高度准确的时间同步，那么您的意见是值得赞赏的。
谢谢。
在虚拟化域环境中保持时间最可靠的方法是保持您的PDC物理，增加所有虚拟DC和域成员上的同步频率和漂移容限，并禁用所有相关虚拟机的主机 – 访客时间同步。
这是对这个问题的一个伪解释（从我看这个已经很长时间了）：
当一台机器（工作站，服务器，VM）启动时，它从RTC（主板/ BIOS中由电池供电的时钟芯片）读取时间，并计算每个CPU时钟的持续时间。 然后，操作系统计算自初始读取以来发生的时钟滴答的数量 ，并将该时间与从引导时获取的原始时间读数相加。 这给你当前的时间。
问题是，主机混淆了虚拟机发生的真实时钟周期。 当主机上实际发生500个时钟周期时，虚拟机可能会看到100个时钟周期。 所以这种计算时间的方法出现了问题，时间在虚拟机上发生了重大的变化。
通过在vSphere和Hyper-V上安装的vm tools / enhancements软件包，主机 – 客户机时间同步可以解决这个问题，但这并不是完美的（在某些设置中，如果虚拟机实时向后移动，如果虚拟机实时超前，不要跳转虚拟机）。
时钟周期在多核设置（定时计数器基本上在每个内核上模拟）以及可以在运行中改变时钟速度的设置（我不知道如何保持这一点）上进行计数的方式进一步复杂化了这一点。 考虑到虚拟机可以在一个内核上执行一个时钟周期，然后在下一个周期内跳转到另一个CPU上的不同内核，这会变得非常糟糕。
所以回到原点：默认情况下，域名时间从PDC开始，然后逐渐下降到其他数据中心，然后从那里到成员服务器和工作站。 因此，如果您确保您的PDC是真正可靠的时间源（通过保持其物理），并禁用所有其他域成员上的主机 – 客户机同步，则您将确保一个稳定和相对准确的时间基础结构。
请注意，将PDC作为物理服务器运行，然后在该服务器上启用Hyper-V并添加一些guest虚拟机可能不是一个合适的解决方法，因为我相信当启用Hyper-V时，“基本”操作系统实际上变成了虚拟化操作系统（无声）。 因此，将一台物理服务器保存为PDC，并保持Hyper-V不变。
有趣的一面是：微软官方对Windows时间同步的立场，即使使用自Windows XP / 2003以来内置在Windows中的兼容NTP服务，也是15秒。 在实践中，你可以把它降到100毫秒以下，但他们所支持的只是在15秒内同步。 有意义的是，大多数MS环境中唯一对时间敏感的关键组件是Kerberos，默认情况下，只要在5分钟的容差范围内，就可以愉快地运行。
是啊。 除了实际上也是物理域控制器的服务器之外，不要closures同步。
我有相同的设置，我已经确保服务时间的机器是一个物理域控制器 – 小盒子。 所有虚拟DC都是从hyper-v时间同步的。
真正的危险是主机和客户端之间的反馈回路，这样循环就会中断。
这不是高度准确顺便说一句 – Windows永远不会。 它只会同步到非常不准确的程度。 我有另一台机器收集财务数据，并同步到MS到外部主机（平均每小时歪斜：根据统计37毫秒）;）这是准确的。