SCCM：Zoinks...神秘维护窗口

Question

我想做什么？

我们有一些 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 很糟糕并且我错过了它，否则我想这不是这里发生的事情。

提前一小时的事实也让我认为这可能是时区或时钟偏差的问题，但这看起来也是意料之中的。

我仍然认为我的两个假设都不错，没有被反驳，但我不知道如何收集更多信息来确定它们。关于我应该如何进行故障排除的任何想法？

还有什么我应该考虑的吗？还有哪些事情会导致这种情况？

编辑：

我查看了本月软件更新的软件更新组，截止日期设置为 03/10/15 20:53，但对于软件更新安装和系统重启，在维护窗口外执行的活动的截止日期行为都被禁用.

至于盒子上的当前时间，看起来确实不错，但我只是在控制面板中检查日期和时间：

Answer 1

与系统中心配置管理器的大多数事物一样，我确信事物之所以如此，有一个完全合乎逻辑的原因，但作为一名低级技术人员，我也确信我永远不会理解为什么。

我使用System Center 2012 R2 Configuration Manager Toolkit中的策略间谍进行了检查，并再次验证了这一点，是的，我得到了我期望找到的两个维护窗口，只不过比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)

谜团已揭开？并不真地。问题解决了？或多或少……很恐怖吧？