我们有一些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,但是对于软件更新安装和系统重新启动,将禁用在维护窗口外执行的活动的截止日期行为.
至于盒子上的当前时间,就像它确实看起来不错,但我只是在控制面板中检查日期和时间：
我使用System Center 2012 R2 Configuration Manager Toolkit 中的策略间谍检查并再次验证,是的,我得到了我期望找到的两个维护Windows,除了F51051BF提前一小时开始：
如果我将该列表与所有可用的维护Windows相关联,我会找到我希望看到的确切维护窗口的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是适当的开始时间.我检查了一些其他人.你猜怎么着.从20:00开始没有提到F51051BF-90E8-4ED7-BA06-F74F9E74A098 …但如果我查看数据库中列出的内容并且在配置管理器控制台中查看周四.夜间维护窗口列为从20:00开始.
Zoinks！这不是一个神秘的维护窗口！这是一个蒙面维护窗口！
看起来无论出于何种原因,F51051BF配置为在20:00开始. Configuration Manager控制台会报告数据库以及数据库,但如果我查看少数客户端,则会报告19:00,其他客户端报及20:00.
两个WAG(狂野屁股猜测)：1)我们在之前实施的ConfigMgr 2007站点中有旧机器策略.或者2)维护窗口策略在某个时刻从19:00更改为20:00,并非每台机器都获得了新闻.随你.我不知道我在这做什么.
解析度
我创建了一个新的维护窗口来替换F51051BF并将其分配给相应的Collection.我等了一两个小时让客户做他们的政策拉动并猜测：
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)
谜团已揭开？并不是的.问题解决了？或多或少……诡异多哈？
