いくつかのSCCMクライアント、ほとんどがWindows Server 2008 R2で実行されている公に面しているWebサイトIIS 7.5、 XYmon 。最近、これらのサーバーが毎月のWindows Updateをインストールした後、約1時間早く再起動していることに気付きました。SCCMクライアントアクションと監視システムには固有の遅延がありますが、 XYmonはこれらのマシンとの接続を19:20〜19:30頃に失いますが、残りの監視対象マシンは約1時間後の20:20〜20:30に再起動するようです。
適用する予定のメンテナンスウィンドウは20:00に始まり、22:00に終わり、毎週木曜日に繰り返し発生します。
これらのマシンが更新を1時間早くインストールする理由を理解しようとしています。複数のメンテナンスウィンドウが「結合」またはマージされていることを知っているので、これらのクライアントにも適用されている別のメンテナンスウィンドウがあると思います。
これらのマシンはドメインに参加していないDMZなので、タイムゾーンやクロックスキューの問題も除外しません。
私はタイムゾーン/クロックのずれの問題が最も可能性が高いと考えましたが、両方のマシンが正しいタイムゾーンにあり、時刻を同期し、3月8日に発生した夏時間の変更を適切に処理しました。
私の次の仮説は、これらのマシンが含まれるコレクションに適用されていた誤った、または古いメンテナンスウィンドウがあったことです。であるはずの別のマシンがあるため、これは私には少しありそうにありません20:00-ishの正しい時間に再起動するすべて同じコレクション。
監視システムが再起動したときにクライアントが実際に再起動していることを確認しましょう!
クライアントを確認すると、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 Updateが原因で再起動しましたか?
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)
OK ...メンテナンスウィンドウはどこから来たのですか?
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クライアントは、1回だけ発生する過去のデフォルトメンテナンスウィンドウが割り当てられたコレクションに属しています。これにより、コレクションのメンバーシップが変更されず、クライアントがタイムリーに変更されなくなりますアクションをすぐに実行しないようにしたクライアントからのポリシー要求。ただし、メンテナンスウィンドウは「結合」されているため、週次メンテナンスウィンドウは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が不良で見逃さない限り、ここでは何も起こっていないと思います。
また、1時間早いという事実は、タイムゾーンまたはクロックスキューの問題である可能性もあると考えさせられますが、それも予想されるようです。
私の仮説はどちらもまともであり、反駁されていないとまだ思いますが、それらについて判断するためにさらに情報を収集する方法がわかりません。トラブルシューティングを続行する方法に関するアイデアはありますか?
他に考慮すべきことはありますか?これを引き起こす原因は他にありますか?
今月のソフトウェアアップデートのソフトウェアアップデートグループを確認したところ、2015年10月3日の20:53に期限が設定されていますしかしソフトウェアアップデートのインストールとシステムの再起動の両方で、メンテナンスウィンドウが無効になります。
ボックスの現在の時刻については、実際には問題ないように見えますが、コントロールパネルで日付と時刻を確認しているだけです。
ほとんどのSystems Center Configuration Managerと同様に、物事が現状のままである理由には完全に論理的な理由があると確信していますが、技術者としては低いので、その理由を理解することはできません。
System Center 2012 R2 Configuration Manager Toolkit からPolicy Spyを使用してチェックし、再度確認しました。はい、F51051BF
が1時間早く開始することを除いて、予期していた2つのメンテナンスウィンドウが表示されます。それがすべきより:
そのリストを使用可能なすべてのメンテナンスウィンドウと関連付けると、exactのメンテナンスウィンドウの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)
ちょっと待って?その行は別のクライアントのServiceWindowManager.logからのものであり、19:00が開始するのに適切な時間であると確かに信じていました。他にもいくつかチェックしました。何だと思う。 20:00から始まるF51051BF-90E8-4ED7-BA06-F74F9E74A098
についての1つの言及ではありませんが、データベースとConfiguration Managerコンソールの「木」にリストされているものを見ると、夜間メンテナンスウィンドウは、20:00に開始すると表示されます。
何らかの理由でF51051BF
が20:00に開始するように構成されているようです。 Configuration Managerコンソールはそれを報告し、データベースbutも報告します。少数のクライアントを見ると、19:00に行くクライアントと20:00に行くクライアントがあります。
2つのWAG(Wild Ass Guesses):1)以前に実装されたConfigMgr 2007サイトから古いマシンポリシーがぶら下がっています。または2)メンテナンスウィンドウポリシーが19:00から20:00に変更され、すべてのマシンがニュースを受け取るわけではありません。なんでも。ここで何をしているのかわかりません。
F51051BF
を置き換える新しいメンテナンスウィンドウを作成し、適切なコレクションに割り当てました。クライアントがポリシーをプルして何を推測するのか私は1〜2時間待ちました。
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)
ミステリーは解決しましたか?あんまり。問題が解決しました?多かれ少なかれ...不気味なハァッ?
これはコメントとして始まりましたが、ここに行きます:
非表示のメンテナンスウィンドウで red herring を追跡している可能性がありますが、よくわかりません。とりあえず、あなたのふりをしよう。
ソフトウェア更新のアドバタイズを再確認し、メンテナンスウィンドウの外側の期限がないことを確認します。その場合、更新はおそらくウィンドウの外側にインストールされます。 。 1900時間になる可能性のある締め切りとは?最初に確認します。
https://technet.Microsoft.com/en-us/library/gg682168.aspxhttps://technet.Microsoft.com/en-us/library/hh508762.aspx
また、別のパッケージを展開し、それをメンテナンスウィンドウ内にのみ展開するようにマークすると、絞り込みに役立ちます。
赤いニシンに戻りましょう。ログは、それが実際にメンテナンスウィンドウであることを示します。サーバーはどのタイムゾーンにありますか?設定されているタイムゾーン、およびサーバー上で表示されている時刻は何ですか? DSTが発生したばかりであることを忘れないでください。お使いのマシンは、前に進むためのメモを持っていなかった可能性があります。