none
大型アップデートの保留状態を検出できないか RRS feed

  • 質問

  • 皆様お世話になります。

    WSUSからバージョン1903が配信されていますが、アップデートがインストールされた後、シャットダウンまたはサインアウトのメニューが、

    ・シャットダウン

    ・更新して再起動

    のようになり、「更新してシャットダウン」が表示されません。

    これが仕様なのか不具合なのか、あるいはうちの環境固有の事象かは分かりませんが、更新のタイミングを選べるのは歓迎です。(退社時に更新してシャットダウンしても、翌朝20分待たされるのは厳しいので、昼休憩に再起動で更新できるのがとても有難い)


    とはいえ、エンドユーザーが意識して「更新して再起動」を選ばなければ更新されないので、アップデートがインストール済で更新が保留されている状態をPowershell等でシステム的に検出する方法があればご教示頂けますと幸いです。(Powershellに限定しません)


    現バージョンは1803と1809、Windows10 Pro 64bit です。


    よろしくお願いします。

    2020年1月23日 19:49

回答

  • 私は大型アップデート(機能更新プログラム)の保留状態(再起動要求待ち)の判別に以下のレジストリ値で判別を行っています。

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Orchestrator

    FlightPendingCommit

    機能更新プログラムがダウンロード、インストールされて再起動要求待ちになるとこの値が1になります。

    毎月のWindowsUpdate(品質更新プログラム)の再起動要求待ちではこのレジストリの値は1にはなりません。

    多分大丈夫とは思いますが、ただ実際にWSUSを使用しての確認は行ったことがございませんのでダメでしたらごめんなさい。

    ちなみにVer1903→Ver1909の場合は大型アップデートではないようですのでこの場合もFlightPendingCommitの値は1にはなりません。


    • 編集済み Savior13 2020年1月28日 6:02
    • 回答としてマーク M14Cluster 2020年1月29日 3:44
    2020年1月28日 4:25

すべての返信

  • チャブーンです。

    この件ですが、「更新プログラムのリブート待ち状態」は、イベントログの[Setup]にある「Servicing ID 4」イベントで記録されます。このイベントが記録された際に、通知や表示のためのプログラム(スクリプト)を実行するよう、「このイベントにタスクを設定」すればいいように思います。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2020年1月24日 2:23
  • 新たな再起動待ちについては、チャブーンさんが書かれている方法が有効だと思われます。

    今現在の状態を調べる場合は、有志の方が作成している以下のスクリプトを利用する事が考えられます。
    https://github.com/bcwilhite/PendingReboot/blob/master/README.md

    2020年1月24日 2:51
  • チャブーン様、Lapivy様、コメントありがとうございます。

    自宅のPCのイベントログを見たところ、確かに「Servicing ID 4」が再起動の保留を示していることを確認できました。しかし、前回の大型アップデート以前のログは消されているようでした。このため、バージョン1903→1909で試してみたところ、「更新してシャットダウン」「更新して再起動」が表示される状態でも「Servicing ID 4」イベントはありませんでした。ID 1 はあるので、これが使えるかもしれません。

    しかし、イベントログならPowershellのGet-EventLogで取得できると思ったら、Setupログは取れないのですね。
    Powershellには拘りませんが、自動化は今回の質問の必要条件です。きちんと書かなくて済みません。

    部内のPCに対し、任意のプログラムを実行する仕組みは仕込んであり、どのPCが「更新して再起動」を待っている状態か、忙しいユーザの手間を取らせないようにバックグラウンドで集計したいと考えています。

    その点、Test-PendingRebootは有り難く、確かに再起動の保留は検出できますが、大型アップデート(今回はバージョン1903へ)のみ区別できるでしょうか?

    バージョン1803(1809)のままの「更新して~」は除外したいです。

    恐れ入りますが、よろしくお願いします。

    2020年1月25日 2:34
  • なるほど、どの更新プログラムが再起動待ちかまで判別したい (Windows 10 1903 へアップグレードする機能更新プログラムの再起動待ちを判別したい) のですね。

     

    あくまで参考ですが、以下のスレッドにあるスクリプトを使えば、WSUSサーバー上で再起動待ちになっているPCと、どの更新プログラムが再起動待ちとなっているかが判別できるでしょう。ただし、WSUSサーバーにPCから報告されてきたレポートを元に出力しており、実際のPCの状態をリアルタイムに出力している訳では無いので、その点は注意して下さい。

     

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/cb5284b3-23dd-4b44-9180-3f2a11a15fc2/wsus-script-for-pending-reboot-possible-addition-how?forum=winserverwsus

    2020年1月26日 16:00
  • Lapivy様、コメントありがとうございます。

    スクリプトはWSUSサーバー上で実行するものですよね?

    そこが問題で、私の立場は末端部門の管理者でWSUSは触れず申し訳ありません。

    また、会社のPCで、先週から「更新して再起動」が出ていたPCのイベントログを見てみましたが、11月28日の再起動後、Setupログに Servicing のイベントが一つもありませんでした。そしてまた、何の再起動待ちか確認すると、WSUSから配信していないバージョン1809でした。この事象は2台目ですが、あるべきイベントが無いところからWindows Updateサービスに異常があるということですね。

    どうするべきか改めて考えます。

    ありがとうございました。

    2020年1月26日 23:25
  • チャブーンです。

    本件、(質問者さんの中で)解決済みならよいのですが。Setupログは「Get-Winevent」で取得できます。Get-EventLogはWindows NT/2000/2003時代のものしか取れないので、注意してください。条件抽出については、Xpathで書いてもいいですしFilterHashTableを使ってもいいです。したに一例があります。

    https://devblogs.microsoft.com/scripting/use-powershell-to-review-the-setup-event-log/


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2020年1月27日 10:46
  • 何か事情があるのかもしれませんが、個人的な意見としては WSUS サーバーの管理者としても更新プログラムの配信・適用は無関係では無いでしょうし、協力を依頼すればいいのではなかろうと思います。

     

    それと、PowerShell などの自動化できる手段では無いので微妙と思い書きませんでしたが、一応 ReportingEvents.log を確認すればどの更新プログラムにより再起動待ちか分かるでしょう。

     

    ReportingEvents.log の見方

    https://docs.microsoft.com/ja-jp/archive/blogs/jpwsus/rpev

    2020年1月27日 14:20
  • チャブーン様、コメントありがとうございます。

    ご指摘済みません。大変勉強になります。

    明朝、Get-WinEventにて情報収集してみます。

    2020年1月27日 14:49
  • 私は大型アップデート(機能更新プログラム)の保留状態(再起動要求待ち)の判別に以下のレジストリ値で判別を行っています。

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Orchestrator

    FlightPendingCommit

    機能更新プログラムがダウンロード、インストールされて再起動要求待ちになるとこの値が1になります。

    毎月のWindowsUpdate(品質更新プログラム)の再起動要求待ちではこのレジストリの値は1にはなりません。

    多分大丈夫とは思いますが、ただ実際にWSUSを使用しての確認は行ったことがございませんのでダメでしたらごめんなさい。

    ちなみにVer1903→Ver1909の場合は大型アップデートではないようですのでこの場合もFlightPendingCommitの値は1にはなりません。


    • 編集済み Savior13 2020年1月28日 6:02
    • 回答としてマーク M14Cluster 2020年1月29日 3:44
    2020年1月28日 4:25
  • Savior13様、コメントありがとうございます。

    レジストリの方も見てみたいと思います。

    イベントの方は、「更新して再起動」となっているPCをもう1台見つけたので、イベントビュアーで確認してみると、システムでは12月中旬のバージョン1903がダウンロード・インストールされているようですが、Setupの方には12月初旬以降のイベントが無い状態でした。

    2020年1月28日 13:14
  • レジストリ

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Orchestrator
    の FlightPendingCommit

    で無事検出できました。

    Savior13様のコメントを回答としてマークさせて頂きますが、このレジストリが正しく機能しているかの裏付けとしてイベントログ(WindowsUpdateClient)も確認しております。

    チャブーン様、Lapivy様も貴重な情報ありがとうございました。

    2020年1月29日 3:44
  • M14Cluster様

    WSUSでも無事検出できたようで安心しました。

    なお、私はVer1511(TH2)の最初の機能更新の頃からこのレジストリを使用して判別を行っております。
    このレジストリは機能更新が完了すれば値が0に戻りますし、何らかの原因で機能更新に失敗した場合も0に戻ります。

    機能更新に失敗した場合は再度、機能更新プログラムのダウンロード、インストールが行われ
    再度再起動要求待ち状態になれば再び値が1になります。
    2020年1月29日 8:28