我想要做什么？
我们有几个 SCCM 客户端，大部分是面向公众的网站，运行在 Windows Server 2008 R2 的 IIS 7.5 上，由一个名为XYmon。我们最近注意到这些服务器在提前约一小时安装每月 Windows 更新后重新启动。SCCM 客户端操作和监控系统本身存在一定程度的延迟，但 XYmon 在 19:20-19:30 左右与这些机器失去连接，而其余受监控的机器似乎在约一小时后（20:20-20:30 左右）重新启动。
我预计应用的维护窗口从 20:00 开始，到 22:00 结束，并且每周四重复一次。
我正在尝试弄清楚为什么这些机器提前一个小时安装更新。我知道多个维护时段是“联合”或合并的，所以我怀疑还有另一个维护时段也适用于这些客户端。
这些机器也位于非域加入的 DMZ 中，所以我也不会排除任何时区/时钟偏差问题。
为了实现这一目标我做了什么尝试？
我认为时区/时钟偏差问题最有可能，但两台机器都处于正确的时区，时间同步，并设法适当地处理 3 月 8 日发生的夏令时变化。
我的下一个假设是，我们有一个错误或旧的维护窗口，它应用于这些机器所在的集合。这对我来说似乎不太可能，因为还有另一台机器应该所有相同的收藏都会在 20:00 左右的正确时间重新启动。
让我们确保当监控系统指示时客户端确实正在重新启动！
如果我检查客户端，systeminfo则显示启动时间为 19:22。事件日志似乎与此相关：
Log Name: System
Source: USER32
Date: 3/12/2015 7:21:02 PM
Event ID: 1074
Task Category: None
Level: Information
Keywords: Classic
User: SYSTEM
Computer: HOST09
Description:
The process C:\Windows\CCM\CcmExec.exe (HOST09) has initiated the restart of computer HOST09 on behalf of user NT AUTHORITY\SYSTEM for the following reason: No title for this reason could be found
Reason Code: 0x80020001
Shutdown Type: restart
Comment: Your computer will restart at 03/12/2015 07:21:02 PM to complete the installation of applications and software updates.
它是否因为 SCCM 的 Windows 更新而重新启动？
如果我深入研究，UpdatesHandler.log答案是一个肯定的“是”：
Initiating updates scan for checking applicability. UpdatesHandler 3/12/2015 7:00:00 PM 6472 (0x1948)
Successfully initiated scan. UpdatesHandler 3/12/2015 7:00:00 PM 6472 (0x1948)
Updates scan completion received, result = 0x0. UpdatesHandler 3/12/2015 7:00:00 PM 8396 (0x20CC)
Initiating updates scan for checking applicability. UpdatesHandler 3/12/2015 7:00:02 PM 10160 (0x27B0)
Method (Apply) called from SDM. UpdatesHandler 3/12/2015 7:00:02 PM 8888 (0x22B8)
Starting job with id = {7DD179F1-1B94-4ADB-A5F1-08E9A000709F} UpdatesHandler 3/12/2015 7:00:02 PM 8888 (0x22B8)
Successfully initiated scan. UpdatesHandler 3/12/2015 7:00:02 PM 10160 (0x27B0)
Updates scan completion received, result = 0x0. UpdatesHandler 3/12/2015 7:00:02 PM 8396 (0x20CC)
Initiating Scan. Forced = (0) UpdatesHandler 3/12/2015 7:00:02 PM 8888 (0x22B8)
Successfully initiated scan for job ({7DD179F1-1B94-4ADB-A5F1-08E9A000709F}). UpdatesHandler 3/12/2015 7:00:02 PM 8888 (0x22B8)
Scan completion received for job ({7DD179F1-1B94-4ADB-A5F1-08E9A000709F}). UpdatesHandler 3/12/2015 7:00:02 PM 8396 (0x20CC)
Evaluating status of the updates for the job ({7DD179F1-1B94-4ADB-A5F1-08E9A000709F}). UpdatesHandler 3/12/2015 7:00:02 PM 8396 (0x20CC)
Initiating download for the job ({7DD179F1-1B94-4ADB-A5F1-08E9A000709F}). UpdatesHandler 3/12/2015 7:00:02 PM 8396 (0x20CC)
Bundle update (038c4fc9-664f-45e5-b838-f7263ffc4512) is requesting download from child updates for action (INSTALL) UpdatesHandler 3/12/2015 7:00:02 PM 8396 (0x20CC)
'ServiceWindowManager.log' 显示维护窗口于 19:00 应用：
Active Service Windows List has 1 windows ServiceWindowManager 3/12/2015 7:28:13 PM 2404 (0x0964)
Service Window with ID = {F51051BF-90E8-4ED7-BA06-F74F9E74A098} having Starttime=03/12/15 19:00:00 ServiceWindowManager 3/12/2015 7:28:13 PM 2404 (0x0964)
Duration is 0 days, 08 hours, 00 mins, 00 secs ServiceWindowManager 3/12/2015 7:28:13 PM 2404 (0x0964)
好的...维护窗口是从哪里来的？
一点点 SQL 应该可以向我展示应用于特定 SCCM 客户端的所有维护窗口：
select
v_FullCollectionMembership.Name as Computername ,v_Collection.Name as CollectionName,
v_ServiceWindow.Description as "Next Maintanance Window"
from v_ServiceWindow
inner join v_FullCollectionMembership on (v_FullCollectionMembership.CollectionID = v_ServiceWindow.CollectionID)
inner join v_Collection on (v_Collection.CollectionID = v_FullCollectionMembership.CollectionID)
order by Computername
我得到以下结果：
Computername CollectionName Next Maintanance Window
HOST09 Default Maintenance Window Occurs on 9/15/2013 1:00 AM
HOST09 Weekly Maintenance Window - Thursday Occurs every 1 weeks on Thursday effective 11/1/2013 8:00 PM
需要解释一下：我们所有的 SCCM 客户端都属于一个集合，该集合被分配了一个默认维护窗口，该窗口只发生一次并且是过去的。这可以防止集合成员身份更改和不合时宜的客户端策略请求导致推迟操作的客户端立即执行这些操作。但是，由于维护窗口是“联合的”，因此每周维护窗口应该在 20:00 适用。
我凭直觉转储了该客户所在的所有集合，然后去检查他们是否已分配维护窗口：
SELECT dbo.v_Collection.Name
FROM dbo.v_FullCollectionMembership INNER JOIN dbo.v_Collection ON dbo.v_FullCollectionMembership.CollectionID = dbo.v_Collection.CollectionID
WHERE (LOWER(dbo.v_FullCollectionMembership.Name) = LOWER('HOST09'))
长话短说，他们没有。
您期望得到什么样的结果？
我真的希望看到一个应用了维护窗口的集合，该维护窗口从 19:00 开始，除非我的 SQL 不好而我错过了它，否则我猜这不是这里发生的事情。
提前一小时的事实也让我倾向于认为这可能是时区或时钟偏差的问题，但这似乎也是可以预料到的。
我仍然认为我的两个假设都是合理的，并且没有被驳斥，但我不知道如何收集更多信息来对它们做出判断。关于我应该如何进行故障排除，有什么想法吗？
我还需要考虑其他什么吗？还有哪些因素可能导致这种情况？
编辑：
我查看了软件更新组中本月的软件更新，截止日期为 2015 年 3 月 10 日 20:53但对于软件更新安装和系统重启，维护窗口之外执行的活动的截止时间行为均被禁用。
至于盒子上的当前时间，它确实看起来不错，但我只是在控制面板中检查日期和时间：
答案1
与大多数系统中心配置管理器一样，我确信事情现在这个样子有完全合理的理由，但作为一名低级技术人员，我也很确定我永远不会理解为什么。
我使用 Policy Spy 进行了检查System Center 2012 R2 配置管理器工具包并再次验证，是的，我得到了我期望找到的两个维护窗口，只是它F51051BF比应该开始的时间早了一个小时：
如果我将该列表与所有可用的维护窗口关联起来，我会找到以下 ServiceWindowID：精确的我期望看到的维护窗口（虽然屏幕截图中将其截断）F51051BF确实从 20:00 开始：
SELECT * FROM v_ServiceWindow
ORDER BY ServiceWindowID
如果一台机器有相同的维护窗口，并且工作正常（即维护窗口从 20:00 开始），那么情况会怎样呢：
Biggest Active Service Window has ID = {F51051BF-90E8-4ED7-BA06-F74F9E74A098} having Starttime=3/5/2015 7:00:00 PM ServiceWindowManager 3/5/2015 10:00:00 PM 68400 (0x10B30)
等一下，WUT？那行来自另一个客户端的 ServiceWindowManager.log，它肯定认为 19:00 是开始的合适时间。我检查了其他几个。猜猜怎么着。没有一个提到F51051BF-90E8-4ED7-BA06-F74F9E74A098从 20:00 开始......但如果我查看数据库中列出的内容以及配置管理器控制台中列出的内容，周四夜间维护窗口从 20:00 开始。
天哪！这不是神秘的维护窗口！这是蒙面维护窗口！
看起来，无论出于什么原因，F51051BF它都配置为在 20:00 开始。配置管理器控制台报告了这一点，数据库也是如此但如果我看几个客户，有些客户在 19:00 去，有些客户在 20:00 去。
两个 WAG（胡乱猜测）：1) 我们从之前实施的 ConfigMgr 2007 站点保留了旧的机器策略。或者 2) 维护窗口策略在某个时间点从 19:00 更改为 20:00，并且不是每台机器都收到了消息。随便吧。我不知道我在这里做什么。
解决
我创建了一个新的维护窗口来替换它F51051BF，并将其分配给适当的集合。我等了一两个小时，等着客户完成他们的政策提取，你猜怎么着：
Service Window with ID = {D047CD9F-25E4-4EDC-95E3-44E971E234FA} having Starttime=3/19/2015 8:00:00 PM ServiceWindowManager 3/16/2015 12:13:41 PM 15500 (0x3C8C)
谜团解开了？其实不然。问题解决了？或多或少……有点吓人吧？
答案2
这开始是一条评论，但现在是这样的：
揭示隐藏的维护窗口
你可能正在追逐红鲱鱼由于维护窗口隐藏，我不确定。现在，我们先假装您知道。
广告截止日期
仔细检查软件更新广告，确保没有截止日期外部您的维护窗口，因为在这种情况下更新可能会在窗口之外安装。截止日期可能是，19:00可以这么说吗？我会先检查一下。
https://technet.microsoft.com/en-us/library/gg682168.aspx https://technet.microsoft.com/en-us/library/hh508762.aspx
此外，如果您部署不同的包并将其标记为仅在维护窗口内部署，这将有助于缩小范围。
现在是几奌？
让我们回到你的话题上。日志表明可以事实上是维护窗口。服务器位于哪个时区？设置了哪个时区，服务器上显示的时间是什么？请记住，DST 刚刚发生，您的机器可能还没有收到向前跳转的备忘录。