我们有一些SCCM客户端,大多是公开面对在Windows Server 2008 R2的IIS 7.5上运行的网站,由一个名为XYmon的系统监控.我们最近注意到这些服务器在提前一小时安装他们的每月Windows更新后重新启动. SCCM客户端操作和监控系统中存在一定的延迟,但XYmon在19：20-19：30左右失去与这些机器的连接,而其余受监控的机器似乎在大约20小时后重启一小时： 20-20：30.

我希望应用的维护窗口从20:00开始,到22:00结束,每周四再次出现.

我试图弄清楚为什么这些机器提前一小时安装他们的更新.我知道多个维护Windows是“联合”或合并的,因此我怀疑还有另一个维护窗口也适用于这些客户端.

这些机器也在非域加入的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客户端的所有维护Windows：

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应用.

在预感中,我转储了此客户端所在的所有集合,然后检查它们是否为其分配了维护Windows：

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开始看到一个应用了维护窗口的Collection,除非我的sql很糟糕,我错过了,我想这不是这里发生的事情.

它提前一小时的事实真的让我觉得它可能是时区或时钟偏差的问题,但看起来也是如此.

我仍然认为我的假设都不错,并没有被驳斥,但我不知道如何收集更多信息来确定它们.关于如何进行故障排除的任何想法？

还有什么我应该考虑的吗？还有什么可能导致这种情况？

编辑：

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

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