SCCM：Zoinks…神秘維護視窗
我想做什麼？
我們有一些 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 ，但軟體更新安裝和系統重啟都禁用了在維護視窗之外執行的活動的截止時間行為.
至於盒子上的目前時間，看起來確實不錯，但我只是在控制面板中檢查日期和時間：
像系統中心配置管理器的大多數事情一樣，我確信事情之所以如此，有一個完全合乎邏輯的原因，但作為一個卑微的技術人員，我也確信我永遠不會明白為什麼。
我使用System Center 2012 R2 Configuration Manager Toolkit中的 Policy Spy 進行了檢查，並再次驗證了這一點，是的，我得到了我期望找到的兩個維護視窗，除了
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 開始。Configuration Manager 控制台報告了這一點，數據庫也報告了這一點，但如果我查看少數客戶端，一些客戶端會在 19:00 進行，而其他客戶端會在 20:00 進行。兩個 WAG（Wild Ass Guesses）：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)謎團已揭開？並不真地。問題解決了？或多或少……嚇人吧？
