Quantcast
Viewing all 179 articles
Browse latest View live

配信の最適化について #1 概要篇

みなさま、こんにちは。WSUS サポート チームです。

今秋にも Windows 10 Fall Creators Update のリリースが予定されておりますが、Windows 10 の展開も進み、更新プログラムやアップグレードの配信についてどうするか検討されているお客様も多いのではないでしょうか。Windows 10 においては、更新プログラムが累積型となり、サイズが大きくなっております。また、アップグレード用の更新プログラム (機能更新プログラムと呼びます)  も数 GB のファイル サイズとなりますので、WSUS クライアントと WSUS サーバー間のネットワーク帯域を逼迫させないためにどうすべきか議論にあがることもあるかと存じます。

WSUS 環境におけるネットワーク帯域制御については、こちらのブログ記事が役に立ちますが、この設定に加えて、そもそも WSUS サーバーからファイルをダウンロードする際のネットワーク トラフィックを抑えることができないかとお思いの事もあるかと思います。現時点において、ダウンロードする際のネットワーク トラフィックを抑える方法としては、次の 3 つがあります。

 

  1. 高速インストール ファイルを有効にする
  2. BranchCache を使用する
  3. 配信の最適化を使用する

 

1. と 2. については、Windows 10 リリース以前から存在する方法ですので、ご存じの方も多いのではないでしょうか。(Windows 10 1607 以降で BranchCache を利用する際の条件については、こちらのブログ記事が役立ちますので、ご参照ください。) 3. の配信の最適化については、Windows 10 から導入された機能であり、当サポート チームにも配信の最適化がどういう機能か教えて欲しいというお問い合わせを多くいただくようになりました。

そこで、今回は全 3 回にわたって、「配信の最適化」の機能について説明いたしますので、検討の際にお役立ていただけますと幸いです。第 1 回は「概要篇」です。第 2 回は「グループポリシー篇」、第 3 回は「効果測定篇」を予定しております。

 

概要

「配信の最適化」 (Delivery Optimization : DO) とは、Windows 10 から導入された P2P 型の配布方法です。Windows 10 のアップグレードや累積形式の更新プログラムを配信した際に、世界的なネットワーク負荷高騰が発生してしまうことを防ぐために実装された機能であり、ホーム ユーザーまたは 数十台規模のスモール ビジネス環境での利用を主に想定しています。本機能を利用すると、品質更新プログラムや機能更新プログラムのダウンロードをインターネットや WSUS だけでなく、ピアとなるクライアントのキャッシュから細かく分割されたファイル単位で分散してダウンロードします。また、Windows 10 1607 から更新プログラムをダウンロードする既定のコンポーネントは、BITS から DO に変わりました。この機能は WSUS 環境でも使用することができます。

(参考情報)

Windows Update の配信の最適化に関する FAQ

 

動作フロー

WSUS 環境における、配信の最適化の動作フローは次の通りです。重要なポイントとしては、WSUS 環境であっても、配信の最適化を使用してダウンロード ソースのピアとなるクライアント端末を探すために、インターネットへの接続が必要になる、ということです。この点が BranchCache と大きく異なります。

1. クライアント A は WSUS に更新プログラムのチェックを行います。
2. WSUS は、更新プログラムの情報をクライアント A に返します。
3. クライアント A は Delivery Optimization のクラウド サービスにダウンロード ソースを要求します。
4. Delivery Optimization のクラウド サービスは、ダウンロード ソースの候補としてクライアント B と C を返します。
5. クライアント A は、クライアント B と C から、分割された更新プログラムのファイルを要求します。
6. クライアント A の要求に対して、B、C が応答します。応答がない場合は、WSUS からファイルをダウンロードします。
7. クライアント A は、分割された更新プログラムのハッシュをチェックします。ハッシュが異なる分割ファイルは破棄します。
8. クライアント A は、インストール前にすべてのファイルのハッシュをチェックします。

 

ポート要件

配信の最適化を使用するためのポート要件は次の通りです。

・クライアント -> インターネット(HTTP  80、HTTPS 443)
・クライアント <-> クライアント (TCP 7680)
・クライアント <-> クライアント (UDP 3544) ※
※ NAT を超えた P2P を使用する場合。また、Teredo サービスを有効にする必要があります。

なお、クライアント -> インターネットにおいては、次の URL に対して、HTTP RANGE 要求を許可するようにプロキシを構成する必要があります。

  • *.download.windowsupdate.com
  • *.au.windowsupdate.com
  • *.tlu.dl.delivery.mp.microsoft.com

(参考情報)

Windows の更新のためのプロキシの要件

 

前提条件

配信の最適化を使用するためには、次の前提条件を満たす必要があります。

  1. ディスクの容量が 32 GB 以上であること。
  2. メモリが 4 GB 以上であること。
  3. ダウンロードする ファイルが 100 MB 以上であること。
  4. ダウンロードするファイル サイズの x2 以上の空きディスク領域があること。

なお、1. ~ 3. の前提条件については、Windows 10 1703 からグループ ポリシーを使用して設定変更可能です。

(参考情報)

Windows 10, Delivery Optimization, and WSUS: Take #2

 

ログ

配信の最適化に関するログは、%windir%\Logs\dosvc に ETL 形式で保存されますが、こちらは現在のところ、シンボルが公開されておりませんので、お客様ご自身でデコードして、解析いただくことはできません。また、パフォーマンス カウンターも用意されておりませんので、ピアからダウンロードしているかどうかを正確に確認する場合は、パケットを解析していただく必要があります。但し、ファイルがキャッシュされているかどうかであれば、次のフォルダーにファイルが存在するかどうかでご確認いただけますので、まずはこちらをご確認ください。

%windir%\SoftwareDistribution\DeliveryOptimization

当該フォルダー配下に実体となるファイルとメタデータである pieceshash ファイルが配置されます。

また、Windows 10 1703 からジョブを確認するための次の PowerShell コマンドが用意されました。

  • Get-DeliveryOptimizationStatus
  • Get-DeliveryOptimizationPerfSnap

こちらのコマンドの出力結果の詳細は第三回「効果測定篇」で説明する予定です。なお、Windows 10 1703 以前の Windows 10 でも、次のレジストリ値より、DO ジョブの確認可能です。こちらも参考までにお役立てください。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DeliveryOptimization\Jobs

 

「概要篇」は以上です。Windows 10 から実装された機能ですので、ビルド毎に新しい機能が搭載されている状況ではありますが、今後のご検討の際に是非ともお役立てください。次回は「グループポリシー篇」です。

 

(免責事項)
本情報の内容
 (添付文書、リンク先などを含むは、作成日時点でのものであり、予告なく変更される場合があります。

 


WSUS のレポートに表示される「状態」の項目の説明

みなさま、こんにちは。WSUS サポート チームです。

 

今回は WSUS サポート チームに、多くご質問いただく内容の 1 つである WSUS レポートに表示される「状態」の項目について説明いたします。WSUS のレポートからクライアントへの更新プログラムの配信可否を確認出来る、非常に便利かつ強力な機能です。

 

WSUS のレポートや管理コンソールに表示される「状態」情報には、以下 (A) (B) 2 種類の表記があります。

 

(A) 詳細表示

下記の詳細レポート画面に表示される内容です。個々の更新プログラム毎の具体的な状態を示します。

Image may be NSFW.
Clik here to view.

 

(B) サマリー表記

下記の4種類に集計(サマライズ)した表記です。表形式レポートのほか、管理コンソールの更新ビューの「状態」フィルターなどに表示されている情報です。

Image may be NSFW.
Clik here to view.

本表記にて全てのクライアントが「インストール済みまたは該当しない」に該当している場合には、配信が必要なクライアントには全て配信が完了出来ているものと判断できます。

※ ただし、通常のレポートや管理コンソール上での表記には、更新プログラムをインストール承認していない (配信対象としていない) クライアントもカウントの対象となっているため、ご注意ください。更新プログラムをインストール承認しているクライアントに限定して、レポートを表示する場合には、管理コンソール上の [レポート] メニューより [承認済み更新プログラムについての更新状態 (表形式)] [承認済み更新プログラムについてのコンピューターの状態 (表形式)] を利用します。

 

それぞれの「状態」について詳細を案内しますので、是非普段のご運用にご活用してください。

 

(A) 詳細表示

下記 (A-1) (A-7) 7 通りが存在し、それぞれ以下のクライアントの状態を示します。

 

(A-1) ダウンロード済み

クライアントに対して、その更新プログラムが適用可能であり、クライアントにダウンロードされているが、未インストールである。

 

(A-2) 失敗

クライアントで、その更新プログラムのインストールが失敗した。

 

(A-3) インストール済み

その更新プログラムがクライアントにインストールされた。

 

(A-4) 再起動の保留中

その更新プログラムのインストールはクライアントで実行された。しかし、クライアントを再起動するまで更新プログラムはインストール完了できない。

 

(A-5) 適用なし

実際に更新プログラムがインストール済みのケースを含め、以下のようなケースが含まれます

 

- システムが対象外

そもそも適用の前提条件を満たさない。OS やアプリケーションの種類、バージョンなどが対象外である。

 

- システム更新済み

システムが、その更新プログラム適用済みと同等か、それ以降の状態にあるとみなすことがでできる。このケースには、さらに次のケースが含まれます。

 

・インストール済み

該当の更新プログラムを 実際にインストール完了した経緯がある。

 

・より新しい更新がインストール済み

該当の更新プログラムのインストール経緯に関わらず、その更新プログラムの内容を含む

(置き換える) 後続の更新プログラムがインストール済みである。

 

(A-6) インストールされていません

クライアントに対して、その更新プログラムが適用可能であるが、

クライアントにダウンロードおよびインストールされていない。

 

(A-7) 状態の報告なし

クライアントにおいて、その更新プログラムの状態が不明である。

 

具体的には、以下のようなケースの場合に「状態の報告なし」との表示になります。

該当の更新プログラムのカタログ情報が WSUS サーバーへ着信して以降

 

- まだクライアントが一度も WSUS サーバーにアクセスしていない

- クライアントは WSUS サーバーにアクセスを行ったが、その検出結果 (レポート情報) WSUS サーバーへ一度も報告していない

- クライアントは WSUS サーバーにアクセスを行い、その検出結果 (レポート情報) WSUS サーバーへ報告したことがあるが、該当の更新プログラムが「拒否済み」になったことにより 該当情報が WSUS サーバー内で破棄された

 

 

(B) サマリー表記

上記 (A-1)(A-7) を、管理上の観点から 下記 (B-1)(B-4) の4種類に集計 (サマライズ) した表記です。表形式レポートのほか、管理コンソールの更新ビューの「状態」フィルターなどに表示されている情報です。

 

(B-1) 必要

-----------------------------------------------------------

(A-1) ダウンロード済み

(A-4) 再起動の保留中

(A-6) インストールされていません

 

(B-2) インストール済みまたは該当しない

-----------------------------------------------------------

(A-3) インストール済み

(A-5) 適用なし

 

(B-3) 失敗

-----------------------------------------------------------

(A-2) 失敗

 

(B-4) 状態の報告なし

-----------------------------------------------------------

(A-7) 状態の報告なし

 

 

~ 参考情報 ~

- Update Status Report Terminology for WSUS 3.0 SP2

http://technet.microsoft.com/en-us/library/dd939917(WS.10).aspx

 

WSUS での Windows 10 管理まとめ

こんにちは。WSUS サポート チームです。

Windows 10 がリリースされてから月日が立ち、WSUS Windows 10 を管理されるお客様も増えてきています。

このブログ記事では、そんなお客様に向けて Windows 10 の管理に関してこれまで公開してきたブログや公開情報を纏めて紹介します。これからも順次更新していきますので、乞うご期待ください!

 

Windows 10 のサポート モデル

LTSC 以外の Windows 10 を管理する場合には、WaaS のサポート モデルに沿って、必ず継続的にアップグレードをする必要があります。基本的な WaaS (Windows as a Service) の考え方は、下記の公開情報にて紹介しているので、ご参考としてください。

 

- サービスとしての Windows のクイック ガイド

https://docs.microsoft.com/ja-jp/windows/deployment/update/waas-quick-start

 

また、各 Windows 10 バージョンのサポート期間は下記にて紹介しています。

 

- Windows ライフサイクルのファクト シート

https://support.microsoft.com/ja-jp/help/13853/windows-lifecycle-fact-sheet

 

各バージョンや更新プログラムのリリース履歴については、下記の公開情報を用意しています。

 

- Windows 10 のリリース情報

https://technet.microsoft.com/ja-jp/windows/release-info.aspx

 

- Windows 10 の更新履歴

https://support.microsoft.com/ja-jp/help/4018124/windows-10-update-history

 

 

設計時のTips

 

WSUS サーバー側のTips

WSUS からアップグレードを配信するためには、事前に準備が必要です。詳細は下記ブログで紹介しています。

 

- WSUS サーバーからの Windows 10 のアップグレードの配信

https://blogs.technet.microsoft.com/jpwsus/2016/02/11/wsus-windows-10/

 

また、各 OS の WSUS の最新バージョンについては下記ブログで紹介しているため、基本的に最新バージョンを利用することをご検討ください。

 

- WSUS サーバーのバージョン番号について

https://blogs.technet.microsoft.com/jpwsus/2016/02/16/wsus-18/

 

アップグレードや更新プログラムの累積化に伴って Windows 10 では更新プログラムのサイズが大きくなっています。WSUS 利用時のネットワーク帯域制御方法については下記で紹介しています。

 

- WSUS 環境のネットワーク帯域制御について

https://blogs.technet.microsoft.com/jpwsus/2012/03/15/wsus-4/

 

- Windows 10 バージョン 1607 の環境にて BranchCache を利用する際の条件

https://blogs.technet.microsoft.com/jpwsus/2017/03/15/win10-1607-branchcache/

 

- 配信の最適化について #1 概要篇

https://blogs.technet.microsoft.com/jpwsus/2017/09/04/aboutdo_1/

 

Windows 10 を管理するためにオプションにて選択する製品については、下記にて紹介しています。

 

- WSUS で選択する Windows 10 の製品分類について

https://blogs.technet.microsoft.com/jpwsus/2016/09/23/wsus-windows-10-product/

 

- Windows 10 LTSB の 更新プログラムを WSUS で同期する際の注意事項について

https://blogs.technet.microsoft.com/jpwsus/2017/08/09/windows-10-ltsb/

 

クライアント側の Tips

クライアント側での自動更新の動作の制御については、下記ブログで紹介しています。

 

- Windows 10 の Windows Update の自動更新設定

https://blogs.technet.microsoft.com/jpwsus/2015/09/17/windows-10-windows-update/

 

また、以下のブログは Windows 10 向けのものではありませんが、グループ ポリシーの動作に変化はありませんので、ご参考としてください。

 

- WSUS クライアントのグループ ポリシー : その 1 – 基本編

https://blogs.technet.microsoft.com/jpwsus/2015/03/24/wsus-1/

 

- WSUS クライアントのグループ ポリシー : その 2 – Windows 8 / Windows Server 2012 以降編

https://blogs.technet.microsoft.com/jpwsus/2015/03/24/wsus-2-windows-8-windows-server-2012/

 

WSUS サーバーとクライアントの間にプロキシが存在する場合には、必ずネットワーク環境に合わせて適切にプロキシを構成する必要があります。下記の情報をご確認ください。

 

- プロキシ サーバー経由での Windows Update へのアクセスについて

https://blogs.technet.microsoft.com/jpwsus/2017/05/17/proxy-settings/

 

 

よくお問い合わせいただく既知の問題

よくお問い合わせをいただく既知の問題については、ブログを用意していますのでご参考としてください。

 

WSUS サーバー側の問題

 

- Windows 10 / Windows Server 2016 を管理している環境で WSUS サーバー の負荷が高騰する

https://blogs.technet.microsoft.com/jpwsus/2017/08/30/win10-high/

 

クライアント側の問題

 

- Windows 10 バージョン1607 で更新プログラム適用後の自動再起動が実施されない

https://blogs.technet.microsoft.com/jpwsus/2017/07/10/win10-reboot/

 

- Windows 10 機能更新プログラムインストール後の再起動について

https://blogs.technet.microsoft.com/jpwsus/2017/07/07/update-and-restart/

 

- Windows 10 の WSUS クライアントが Windows Update から更新プログラムを取得するようになってしまう事象について

https://blogs.technet.microsoft.com/jpwsus/2016/11/15/windows-10-1607-wufb/

 

- Windows 10 バージョン 1607 および Windows Server 2016 の環境で、更新プログラムのダウンロードが途中から進まなくなる問題について

https://blogs.technet.microsoft.com/jpwsus/2016/10/28/win10-stop-download/

 

- 「削除の承認」が Windows 10 / Windows Server 2016 のクライアントに反映されない事象について

https://blogs.technet.microsoft.com/jpwsus/2017/09/04/cant-delete-win10/

 

Windows 10 の機能更新プログラムの延期について

みなさま、こんにちは。WSUS サポート チームです。

今回は Windows 10 を新しいバージョンにアップグレードするための機能更新プログラムの延期方法について、ご案内します。

 

常に最新の機能更新プログラムを適用する運用であれば、特に考慮は不要ですが、社内で使用しているシステムが最新バージョンに対応していない等の理由で、なかなか常に最新の機能更新プログラムを行う運用は難しいという方も多くいらっしゃると思います。今回はそのような方に向けたブログとなります。

 

まず、機能更新プログラムの配信を制御する方法として、一般的に下記の 2 種類の方法がございます。

 

  1. WSUS や SCCM 等を利用して、配信する機能更新プログラムを制御する。
  2. Windows Update for Business のグループ ポリシーを利用して、機能更新プログラムの適用を延期する。

 

1」の方法で制御が出来る場合には、WSUS SCCM 等で配信を制御すれば問題ないため、このブログでは詳細な説明を割愛させていただきます。

WSUS SCCM をご利用の場合は、このブログで紹介している延期のグループ ポリシーを設定すると、こちらこちらの事象が発生しますので、ご注意下さい。

 

今回は「2」の方法で、WSUS SCCM 等を用いずに Windows Update for Business のグループ ポリシーで制御する方法をメインに紹介していきます。「とにかくサポート期間内に機能更新プログラムは適用したくない!」という方にとって、まず把握していただく必要がある情報は、「サポート期間」と「Windows Update サイト上で、CBB (Current Branch for Business)※ へリリースされた日」となるため、順を追って紹介していきます。

※ 既に Semi-Annual Channel に名称変更がアナウンスされていますが、設定上は Current Branch for Business という表記が残っているため、このブログでは便宜上、CBB (Current Branch for Business) の名称を利用します。特に Semi-Annual Channel に置き換えて読んでいただいても問題ありません。

 

「サポート期間」と「CBB への機能更新プログラムのリリース日」

これまでの OS と同様にサポート期間が過ぎたバージョンに対しては、セキュリティ更新プログラムがリリースされなくなってしまうため、各 Windows 10 のバージョンのサポート期間については、意識して運用していただく必要があります。サポート期間については、下記の公開情報で正式なご案内しているため、参照してください。

 

- Windows ライフサイクルのファクト シート

https://support.microsoft.com/ja-jp/help/13853/windows-lifecycle-fact-sheet

 

また、Windows Update for Business のグループ ポリシーにて延期設定を行う場合、延期の起点となるのは「延期対象の機能更新プログラムが Windows Update サイトに公開された日」となります。Windows 10 の各バージョンのリリース情報は下記の公開情報がございます。

 

- Windows 10 のリリース情報

https://technet.microsoft.com/ja-jp/windows/release-info.aspx

 

しかし、ここで注意が必要なのは、上記で公開されている日付と実際に Windows Update サイト上に CBB としてリリースされた日付に差がある点です。実際には下記の日付に Windows Update サイト上に公開されているため、CBB として設定する場合には、下記の日付を把握しておく必要があります。

 

- バージョン 1607 の CBB へのリリース日 : 2017/02/02

- バージョン 1703 の CBB へのリリース日:2017/07/27

 

それでは上記を踏まえて、実際に各バージョンでサポート期間内は、機能更新プログラムが着信しないようにする設定内容を例に紹介していきます。

 

Windows 10 バージョン 1511 の場合

Windows 10 バージョン 1511 を利用している場合には、下記のグループ ポリシーで機能更新プログラム延期の設定が出来ます。”有効” に設定すると CBB としてリリースされている機能更新プログラムが着信します。

 

[コンピューターの構成] - [管理用テンプレート] - [Windowsコンポーネント] - [Windows Update]

[アップグレードおよび更新を延期する] を “有効”、期間は “0 ~ 8” ヶ月で指定可

さらに “アップグレードおよび更新を一時停止する” を有効にすると 1 ヶ月間、機能更新を含む全ての更新プログラムの着信を延期可

 

例えば、実際にサポート期間内は機能更新プログラムを着信しないようにする場合には、下記のように設定をします。

Image may be NSFW.
Clik here to view.

 

Windows 10 バージョン 1607 の場合

Windows 10 バージョン 1607 を利用している場合には、下記のグループ ポリシーで機能更新プログラム延期の設定が出来ます。”有効” に設定し Current Branch for Business を選択することで、CBB としてリリースされている機能更新プログラムが着信します。

 

[コンピューターの構成] - [管理用テンプレート] - [Windowsコンポーネント] - [Windows Update] - [Windows Update の延期]

[機能更新プログラムをいつ受信するかを選択してください] を “有効”、 “Current Branch / Current Branch for Business”、期間は ”0 ~ 180” 日で指定可

さらに “機能更新プログラムの一時停止” を有効にすると60 日間、機能更新プログラムの着信を延期可

 

例えば、実際にサポート期間内は機能更新プログラムを着信しないようにする場合には、下記のように設定をします。

Image may be NSFW.
Clik here to view.

 

Windows 10 バージョン 1703 の場合

Windows 10 バージョン 1703 を利用している場合には、下記のグループ ポリシーで機能更新プログラム延期の設定が出来ます。”有効” に設定し Current Branch for Business を選択することで、CBB としてリリースされている機能更新プログラムが着信します。

 

[コンピューターの構成] - [管理用テンプレート] - [Windowsコンポーネント] - [Windows Update] - [Windows Update の延期]

[機能更新プログラムをいつ受信するかを選択してください] Current Branch / Current Branch for Business”、期間は ”0 ~ 365” 日で指定可

さらに機能更新プログラムの一時停止を開始する日付を指定することで、指定日より 35 日間延期が可能

 

例えば、実際にサポート期間内は機能更新プログラムを着信しないようにする場合には、下記のように設定をします。

Image may be NSFW.
Clik here to view.

 

また新しい機能更新プログラムがリリースされた場合には、随時更新しますので、ご期待ください。

 

- 参考情報 : Windows Update for Business の構成

https://docs.microsoft.com/ja-jp/windows/deployment/update/waas-configure-wufb

 

(免責事項)
本情報の内容 (添付文書、リンク先などを含むは、作成日時点でのものであり、予告なく変更される場合があります。

オフライン WSUS サーバーの構築方法

みなさま、こんにちは。WSUS サポート チームです。

 

オフライン環境でも更新プログラムの管理を WSUS から行ないたい!と、弊サポート チームによくお問い合わせをいただきます。オフライン環境でも、もちろん WSUS を利用することは可能なのですが、オフライン WSUS サーバーの構築には、ちょっとしたコツや注意点がいくつかあるので、今回のブログではオフライン WSUS サーバーの構築手順と合わせて、そのような点を紹介します。

 

是非これから構築を行われる方や、試しに構築してみたけど上手くいかないという方の一助となれば幸いです。

 

必要な構成

オフライン環境に WSUS を用意するためには、下記の 2 台の WSUS サーバーを用意する必要があります。

 

- インターネットと接続できるオンライン WSUS サーバー

- オフラインネットワーク内のオフライン WSUS サーバー

 

 

構築手順の概要

オフライン WSUS サーバーの構築時には、オンライン WSUS サーバーから下記の 2 つのデータを移行し、オフライン WSUS サーバーへインポートします。

 

- カタログのメタデータ (更新プログラムのリスト)

- WsusContent フォルダ (更新ファイル)

 

具体的には下記の順に作業を進めていきます。

 

  1. インターネットと接続できる WSUS サーバーにて、Microsoft Update サイトよりカタログ情報やコンテンツデータをダウンロードします。
    ※ この時に、必ずオフライン側で配信したい更新プログラムをオンラインの WSUS サーバーでインストール承認して、ダウンロードしておく必要があります。この時点で、オフラインで必要なファイルをダウンロードしていない場合、構築に必ず失敗します。
  1. wsusutil コマンドにてカタログ情報をインターネットと接続できる WSUS サーバーからエクスポートします。
  2. インターネットと接続できる WSUS サーバーからリムーバブルメディアに、エクスポートした情報と、コンテンツデータをコピーします。
  3. オフラインネットワーク内の WSUS サーバーへリムーバブルメディアから、エクスポートされた情報と、コンテンツデータをペーストします。
  4. オフラインネットワーク内の WSUS サーバーにて wsusutil コマンドにてインポートします。
  5. オフラインネットワーク内の WSUS サーバーにて対象の更新プログラムを承認し、配布します。

 

さらに詳細な手順は下記にご案内します。

 

 

構築手順の詳細

オンライン WSUS サーバー、オフライン WSUS サーバーで共通の手順

  1. 下記の公開情報の手順に従い、オンライン WSUS サーバーとオフライン WSUS サーバーをインストールします。
    - 手順 2: WSUS サーバーの役割をインストールする
    ※ WSUS に適用する更新プログラムはこちらのブログで紹介しています。オンライン WSUS サーバーとオフライン WSUS サーバーは更新プログラムの適用状況も含めて、バージョンは合わせる必要があるので、注意してください。

 

  1. 下記の手順に従い、オプション設定の変更を必要に応じて行います。
    - 手順 3: WSUS を構成する

    ※ オフライン環境の WSUS につきましては、下記の通りオプションを設定してください。オフラインの WSUS では、オンライン環境からエクスポートしたコンテンツや メタデータをインポートするため、同期処理を行わないように、設定をする必要があります。

           - [更新ファイルと更新言語] の [更新ファイル] タブおよび [言語の更新] タブの内容を、オンラインとオフライン WSUS サーバーにて相違のないように設定してください。

           - [更新元およびプロキシサーバー] の [更新元] を [Microsoft Update から同期する] に設定してください。

           - [同期スケジュール] を [手動で同期する] に設定してください。

 

オンライン WSUS サーバーでの実施手順

  1. Microsoft Update とオンライン WSUS サーバーを同期させ、メタデータを同期します。

 

  1. オンライン WSUS サーバーにて、オフライン WSUS サーバーにて配信する予定の更新プログラムを承認し、更新プログラム ファイルをダウンロードします。
    インストール承認後は、WSUS 管理コンソールの下記の箇所からダウンロードが完了したことを必ず確認してください。ダウンロードが完了していない状態で手順を進めると構築に失敗します。

Image may be NSFW.
Clik here to view.

  1. オンライン WSUS サーバーから更新プログラムのメタデータをエクスポートします。

        5.1 Microsoft Update と疎通できるオンライン WSUS サーバーにログインします。

        5.2 管理者権限にてコマンドプロンプトを起動し、以下のコマンドを実行します。

        ※ Windows Server 2012 R2 より前の環境では更新プログラムの適用を行っていないと、下記のコマンドの実行が出来ません。詳細につきましては、このブログをご参照ください。

 

        ) エクスポートするメタデータを export.cab として

            C:\Program Files\Update Services\Tools に作成する場合

 

                cd "C:\Program Files\Update Services\Tools"

                wsusutil.exe export export.xml.gz export.log


  1. オンライン WSUS サーバーから更新プログラム ファイルが保管されている WSUSContents フォルダおよび、上記の手順で出力した export.xml.gz USB ドライブや共有フォルダにコピーし、オフライン環境のWSUS サーバーへコピー出来るようにします。この時、WSUSContents フォルダについては、同じフォルダ構成にてコピーしてください。

 

オフライン WSUS サーバーでの実施手順

  1. オフライン WSUS サーバーにて WsusContent フォルダに関する以下のアクセス権限を設定/確認します。

        7.1 ドライブのルート (例:C:\ など) に、最低でも Users グループ または  Network Service アカウントに対して [読み取り] アクセス許可

        7.2 WSUSContent フォルダが作成されるルートフォルダ (: C:\WSUS など) に対し、最低でも Users グループならびに Network Service アカウントの両方に [読み取り] アクセス許可

 

  1. WSUSContents フォルダを、オフライン環境のWSUS サーバーへ同じフォルダ構成にてコピーします。この手順でコピーが完了してから、次の手順を実施しないと失敗いたしますので、ご注意ください。

 

  1. Microsoft Update と疎通できる WSUS サーバーからエクスポートした export.xml.gz ファイルを、オフライン環境 WSUS サーバーの任意の場所にコピーします。

 

  1. オフライン WSUS サーバーにてエクスポートされた更新プログラムのメタデータをインポートします。

        9.1. オフライン環境の WSUS サーバーにログインします。

        9.2. 管理者権限にてコマンドプロンプトを起動し、以下のコマンドを実行します。   
    ※ Windows Server 2012 R2 より前の環境では更新プログラムの適用を行っていないと、下記のコマンドの実行が出来ません。詳細につきましては、このブログをご参照ください。

 

        ) export.cab ファイルを C:\Program Files\Update Services\Tools にコピーした場合

 

                cd "C:\Program Files\Update Services\Tools"

                wsusutil.exe import import.xml.gz import.log

 

  1. オフライン WSUS サーバーにて、手順 4 にて承認した配信を行う更新プログラムの承認を実施し、WSUS クライアントへ配信を行います。
    ※ 手順 4 でインストール承認し、ダウンロードが完了していない更新プログラムは、オフライン WSUS サーバーでインストール承認することは出来ませんので、ご注意ください。

Windows 10 / Windows Server 2016 でも Windows Update の自動更新は止められます

みなさま、こんにちは。WSUS サポート チームです。

 

いきなり結論ですが Windows Server 2016 および Windows 10 でも Pro 以上のエディションであれば、下記のグループ ポリシーを利用することで Windows Update による自動更新は止めることが出来ます。このブログでも紹介している通り、「設定」画面から自動更新の設定が変更出来ないため、不安に思うかもしれませんが安心してください!

 

[コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Update]
[
自動更新を構成する] を ”無効”

 

私も 3 年以上 WSUS / Windows Update のサポートをしており、何度も「無効にしていたはずなのに動作してしまった」「実際に Windows Update は無効に出来ないのではないか?」「勝手に Windows Update が実行された」とのお問い合わせをいただきましたが、それは上記のグループ ポリシーが正常に動作していないわけではなく、すべてのケースにおいて別の要因でした。

 

今回は自動更新が意図せず動作してしまったように見えるパターンも合わせてご紹介しますので、同じような状況の場合は是非チェックしてみてください。

 

  • 手動で Windows Update を実行した
  • Windows Update による自動更新ではなく、その他の更新処理等が動作した
  • 自動更新の設定が意図せず変わった

 

手動で Windows Update を実行した

[自動更新を構成する] のグループ ポリシーでは、あくまでも Windows Update の自動実行を抑止するものです。このため、手動で「設定」画面から Windows Update を実施すると、自動更新を無効にしていても Windows Update を行えてしまいます。

 

「さすがにそんなこと知っているって」と思われる方も多いかと思いますが、Windows Server 2016 / Windows 10 では、以前の Windows OS と違い、適用可能な更新プログラムがあれば「設定」画面から「更新プログラムのチェック」をクリックすると、インストールまで行われてしまうため、このパターンのお問い合わせもよくいただきます。

 

ちなみに、Windows Server 2016 / Windows 10 バージョン 1607 以降の環境では、下記のグループ ポリシーを設定することで、「設定」画面から「更新プログラムのチェック」を押せなくなるため、そもそも手動でも実行させたくないんだけど…という方は、合わせて設定をご検討ください。

 

[コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Update]
[Windows Update
のすべての機能へのアクセスを削除する] を ”有効”

 

上記のグループ ポリシーを設定すると、下記のように「更新プログラムのチェック」も押せなくなります。

Image may be NSFW.
Clik here to view.

 

Windows Update による自動更新ではなく、その他の更新処理等が動作した

手動でも実行もしてないけど Windows Updateサービスが動作したり、通信等を見ていると Windows Update サイトへの接続が発生している…という場合には、このパターンに当てはまる可能性があります。Windows Update サービスや Windows Update サイトは、Windows Update による OS 等の更新プログラムの適用以外にも利用されているため、実際に自動更新が行われていなくても、サービスが動作したり、サイトへの接続が発生することはございます。

 

Windows Defender の定義ファイルの更新、ストア アプリの更新、ドライバーの更新等がありますが、これらもグループ ポリシーで無効にすることが出来るので、更新が不要であれば、止めてしまいましょう。

 

- Windows Defender による定義ファイルの更新を無効化
[
コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [Endpoint  Protection]
[Endpoint Protection
を無効にする] "有効"

 

- ストア アプリの自動更新を無効化
[
コンピューターの構成] [管理用テンプレート] [Windows コンポーネント] [ストア]
[
更新プログラムの自動ダウンロードおよび自動インストールをオフにする] "有効"

 

- Microsoft コンシューマー エクスペリエンスの無効化
[
コンピューターの構成] [管理用テンプレート] [Windows コンポーネント] [クラウド コンテンツ]
[Microsoft
コンシューマー エクスペリエンスを無効にする] を “有効”

 

- ドライバーの検索を無効化
[
コンピューターの構成] - [管理用テンプレート] - [システム] - [デバイスのインストール] -
[
デバイス ドライバーを検索する場所の順序を指定する] "有効" かつ
オプション [検索順序を選択する] にて、"Windows Update を検索しない" を指定

 

また、Windows Update に限らず、OS としてインターネット経由で弊社サイトへアクセスする動作はあります。インターネット接続が発生する動作の制御方法については、下記の公開情報にて紹介しておりますので、ご参考としてください。

 

- ご参考 : Windows オペレーティング システムのコンポーネントから Microsoft サービスへの接続の管理
https://docs.microsoft.com/ja-jp/windows/configuration/manage-connections-from-windows-operating-system-components-to-microsoft-services

 

あと、加えて注意が必要なのは Office の更新です。このブログでも紹介している通り、クイック実行版の Office は Windows Update / Microsoft Update と異なる仕組みで更新を管理しているので、更新させたくない場合には別途考慮が必要です。

 

自動更新の設定が意図せず変わった

さてこのパターンに当てはまる時が一番やっかいなパターンとなります。まず OS 標準の動作で自動更新の設定を変更して、勝手に有効化することは絶対にありません。このため、意図していないのに、自動更新の設定が変わってしまうということであれば、下記のようなパターンが考えられます。

 

- グループ ポリシーの適用が正しく行われていない
-
サードパーティ製のアプリケーション等が、勝手に設定を変えている

 

"gpupdate /force" を実行しても下記のレジストリ値に設定が反映されない、またタイミングによって反映されないことがある場合には、グループ ポリシーの適用が正しく行われていない可能性があるので、グループ ポリシーの観点でトラブル シューティングを行う必要があります。

 

- [自動更新を構成する] を ”無効” に設定されていることを示すレジストリ値
キー
: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
: NoAutoUpdate : 1 (Reg_DWORD)

 

ローカル グループ ポリシーで設定を行っている場合や、"gpupdate /force" を実施しても、しばらくすると設定が変わっている!?という場合には、何かのアプリケーションが勝手に設定を変えている可能性があります。よくあるのはセキュリティ系のアプリケーションですが、アンインストールして動作に変化が見られないか、切り分けを実施するのは、セキュリティ上ちょっと。。。と言う場合には、監査ログを利用した調査が有効です。

 

下記の手順で監査ログを仕掛けると、どのアプリケーションが対象のレジストリ値に変更を行ったか記録しておくことが出来るため、勝手に自動更新の設定変更をしているアプリケーションを特定出来る可能性があります。

 

- 監査ログの設定手順

  1. 事象発生コンピューターへ管理者権限を持つユーザーでログインし、 [スタート] メニューの [ファイル名を指定して実行] より[regedit] を起動します。

 

  1. 以下のキーを右クリックし、 [アクセス許可] を開きます。それぞれのキーに対して、順に実施します。

    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

 

  1. [セキュリティ] タブを開き、[詳細設定] を開きます。

 

  1. [監査] タブを開き、[追加] をクリックします。([続行] と表示される場合は、[続行]をクリック後に表示されます。)

 

  1. [プリンシパルの選択] にて、"Everyone" と入力しま す。

 

  1. [ユーザー または グループ の選択] 画面で、[OK] をクリックします。

 

  1. [監査エントリ] で、[すべて]  [このキーとサブキー]、[フルコントロール] にチェックを入れま す。

 

  1. [OK] で順に開いているウインドウを閉じます。

 

  1. コマンド プロンプトを管理者として起動します。

 

  1. 以下コマンドを実行します。(監査ポリシーについて設定を確認します。)

    auditpol /get /category:"オブジェクト アクセス"

    例: 監査ポリシーより設定していない場合以下のように表示されます。

    C:\Users\Administrator>auditpol /get /category:"オブジェクト アクセス"

    システム監査ポリシー
    カテゴリ/サブカテゴリ                               設定
    オブジェクト アクセス
    ファイル システム                               監査なし
    レジストリ                                   監査なし
    カーネル オブジェクト                             監査なし
    SAM                                     監査なし
    証明書サービス                                 監査なし
    生成されたアプリケーション                           監査なし
    ハンドル操作                                  監査なし
    ファイルの共有                                 監査なし
    フィルタリング プラットフォーム パケットのドロップ              監査なし
    フィルタリング プラットフォームの接続                     監査なし
    その他のオブジェクト アクセス イベント                    監査なし

 

  1. "レジストリ" を "成功および失敗" と設定を行います。

    ====
    auditpol /set /subcategory:"レジストリ" /success:enable
    auditpol /set /subcategory:"レジストリ" /failure:enable
    ====

 

  1. 再度以下コマンドを実行し、"レジストリ" が "成功および失敗" となっているか確認します。

    auditpol /get /category:"オブジェクト アクセス"

 

  1. レジストリ エディタ等で、「HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU」キー配下を開いた後、セキュリティのイベント ログに下記のよう出力されることを確認します。

    - 出力例 -
    下記のイベントでは、レジストリ エディタで、「HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU」キー配下へアクセスが行われたことが判ります。
    --------------------------------
    ログの名前:         Security
    ソース:           Microsoft-Windows-Security-Auditing
    日付:            2017/06/07 11:19:17
    イベント ID:       4663
    タスクのカテゴリ:      レジストリ
    レベル:           情報
    キーワード:         成功の監査
    ユーザー:          N/A
    コンピューター:       XXX
    説明:
    オブジェクトへのアクセスが試行されました。

    (中略)

    オブジェクト名:        \REGISTRY\MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
    ハンドル ID:        0x1b4

    プロセス情報:
    プロセス ID:        0x880
    プロセス名:        C:\Windows\regedit.exe
    --------------------------------

 

  1. 事象を再現した後に、再度セキュリティのイベント ログを確認します。

    - 出力例 -
    例えば、下記のイベントでは、XXX.exe がレジストリ値の設定変更を行っていることを特定出来ます。
    --------------------------------
    ログの名前:         Security
    ソース:           Microsoft-Windows-Security-Auditing
    日付:            2017/06/07 11:19:17
    イベント ID:       4657
    タスクのカテゴリ:      レジストリ
    レベル:           情報
    キーワード:         成功の監査
    ユーザー:          N/A
    コンピューター:       XXX
    説明:
    レジストリ値が変更されました。

    (中略)

    オブジェクト:
    オブジェクト名:        \REGISTRY\MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
    オブジェクト値名:     NoAutoUpdate
    ハンドル ID:          0x108
    操作の種類:           既存のレジストリの値が変更されました

    プロセス情報:
    プロセス ID:          0xa2c
    プロセス名:           C:\Program Files\XXXXX\XXXXX.exe
    --------------------------------

WSUS サーバーのダウンロード障害について – BITS と Range ヘッダー

(更新) 2017/9/12 補足情報を追記しました。

こんにちは。WSUS サポート チームです。

今回は WSUS サーバーが Microsoft Update サイトや上位の WSUS サーバーから更新プログラムのインストーラーをダウンロードする際に、よくあるトラブル事例と対処方法をご紹介します。
もし下記のような症状が出ている場合には、本ブログ記事が役立つと思います。

・いくつかの更新プログラムについてのみ、ダウンロードが失敗する
・ダウンロードが異常に遅い (例えば、月例のセキュリティ更新プログラムをダウンロードするのに数日かかる、など)
・アプリケーション イベントログに下記のようなエラーが記録されている

イベントの種類: エラー
イベント ソース: Windows Server Update Services
イベント カテゴリ: (2)
イベント ID: 364
日付: date
時刻: time
ユーザー: 該当なし
コンピューター: ServerName
説明:コンテンツ ファイルのダウンロードに失敗しました。原因:サーバーは必要な HTTP プロトコルをサポートしていません。バックグラウンド インテリジェント転送サービス (BITS) では、サーバーが Range プロトコル ヘッダーをサポートしている必要があります。

こういった場合、下記の技術情報でご紹介する対処方法をお試しください。

バックグラウンド インテリジェント転送サービスを使用してファイルをダウンロードしようとすると、次のエラー メッセージが表示される: "コンテンツ ファイル ダウンロードに失敗しました"
http://support.microsoft.com/kb/922330/ja

本ブログ記事ではトラブルの詳細、対処方法とその影響についてもう少し補足してご説明します。

トラブルの詳細について
====================
WSUS サーバーが更新プログラムのインストーラーをダウンロードする際には、"Background Intelligent Transfer Service" (BITS) サービスが利用されます。
BITS は帯域制御の機能を持ったファイル転送の仕組みで、バックグラウンド、フォアグラウンド、と 2 種類の転送モードを持ちます。

WSUS サーバーは既定の設定で、バックグラウンド モードを利用してダウンロードを行います。
この時、ダウンロード要求は HTTP/1.1 の Range ヘッダーを使って、インストーラーをいくつものブロックに分けて分割ダウンロードを行います。

しかし、プロキシやネットワーク機器の設定状況によっては、Range ヘッダーを利用した通信を拒否する、通信が遅くなる、といった事象が発生することがあります。
これが先に挙げた症状の、よくある発生要因です。

対処方法について
====================
技術情報 KB922330 でご紹介する対処方法は、下記の 2 通りです。

A. プロキシやネットワーク機器の設定を変更し、Range ヘッダーを利用した通信をサポートするように対処する
++++++++++++++++++++++++++
技術情報では具体的な製品名として SonicWALL を挙げておりますが、それ以外のネットワーク機器が影響することもありえます。
ただ、この対処方法はいくつものネットワーク機器を調べる必要があり、また設定を変更するとネットワーク全体に影響が及ぶため、ほとんど実施されることはありません。

B. WSUS の BITS をフォアグラウンド モードに変更する
++++++++++++++++++++++++++
BITS の設定をフォアグラウンド モードに変更すると、Range ヘッダーを利用した分割ダウンロードは行われず、インストーラー全体をまとめて 1 つのダウンロード要求で処理します。
技術情報の "方法 1:プロキシ サーバーが HTTP 1.1 の範囲要求をサポートしていない" を実施するのですが、具体的には下記の 2 ステップで設定を変更しています。

ステップ 1
WSUS が利用するデータベース "SUSDB" に対して、下記の SQL クエリを実行して設定値を変更する。

update tbConfigurationC set BitsDownloadPriorityForeground=1

ステップ 2
WSUS のサービス "Update Services" を再起動して、設定変更を反映させる。

もし設定を元に戻したい場合には、ステップ 1 で実行する SQL クエリを下記に変更して、"Update Services" を再起動します。

update tbConfigurationC set BitsDownloadPriorityForeground=0

WSUS が利用する既定のデータベース Windows Internal Database に対して GUI から SQL クエリを実行したい時には、下記のブログ記事をご参照ください。

WSUS データベースを簡単に操作するには
http://blogs.technet.com/b/jpwsus/archive/2012/03/08/how-to-manage-wid.aspx

BITS フォアグラウンド モードの影響について
====================
BITS を用いたファイル転送には帯域制御を設定可能ですが、BITS フォアグラウンド モードは帯域制御を行いません。
もし帯域制御をグループ ポリシー等で設定する環境では、注意が必要となります。
なお、WSUS が BITS を利用する際の設定のみが変更されるため、その他の場面で BITS が利用されるときの動作には影響ありません。

- 参考資料
タイトル: Background Intelligent Transfer Service
URL: http://msdn.microsoft.com/en-us/library/windows/desktop/bb968799.aspx

 

(補足情報)
Windows 10 の機能更新プログラムなど、2 GB を超えるファイルについては、WSUS の設定で BITS フォアグラウンド モードに変更したとしても、Range ヘッダーを使って分割ダウンロードが行われます。こちらは、BITS における想定された動作となりますので、機能更新プログラムのダウンロードを実施する場合は、お手数をおかけいたしますが、ネットワーク中継機器で Range ヘッダーを許可してくださいますようお願いいたします。

2017 年 10 月にリリースされた Windows 10 1607 / 1703 向け更新プログラム適用後に OS 起動不可になる問題について

皆さま、こんにちは。WSUS サポート チームです。
2017 年 10 月にリリースされた Windows 10 1607 / 1703 向け更新プログラム KB4041691 および KB4041676  適用後に OS 起動不可になる問題について、次の通りご案内いたします。

この度は弊社更新プログラムの問題により、ご迷惑をおかけいたしましたことを、深くお詫び申し上げます。

 

対象製品

WSUS / System Center Configuration Manager
Windows 10 1607 / 1703, Windows Server 2016

 

概要

WSUS または System Center Configuration Manager から配信された KB4041691 および KB4041676   の「累積更新プログラム」と「差分更新プログラム」が同時にインストールされたマシンにおいて、再起動後に OS が起動できない問題が発生する可能性があります。インターネットの Windows Update からのみ更新プログラムを取得しているマシンは本問題の影響を受けません。

 

原因

日本時間の 2017 年 10 月 11 日の午前 8 時まで、KB4041691 および KB4041676  の「累積更新プログラム」と「差分更新プログラム」を WSUS 向けに公開していたことによります。この期間に同期を行った WSUS サーバーにおいては「累積更新プログラム」と「差分更新プログラム」が配信可能となります。これら 2 つの更新プログラムを WSUS または System Center Configuration Manager から同時に配信した場合、本問題が発生します。

 

影響

KB4041691 および KB4041676   の「累積更新プログラム」と「差分更新プログラム」がインストールされている場合、再起動後に OS が起動できない問題が発生する可能性があります。更新プログラムがインストールされているかどうかは、「設定」->「更新とセキュリティ」->「Windows Update」画面の「更新の履歴」よりご確認いただけます。

Image may be NSFW.
Clik here to view.

 

対処方法

・WSUS 側の対処方法

WSUS 管理コンソールにて、KB4041691 および KB4041676   の「差分更新プログラム」を右クリックして、[拒否] をクリックします。なお、2017 年 10 月 11 日 (水曜日) の午前 9 時以降に WSUS が同期されている場合、既定の設定であれば自動的に「拒否済み」となります。以下の画面ショットのように「差分更新プログラム」が「拒否済み」の状態となっていれば、対処は完了しています。

Image may be NSFW.
Clik here to view.

・クライアント側の対処方法

KB4041691 および KB4041676  の「差分更新プログラム」がインストールされていなければ、特に対処を実施して頂く必要はありません。「差分更新プログラム」がインストールされた場合の対処方法につきましては、次の技術情報をご確認ください。

Windows デバイスは、10 月 10日のバージョンの KB4041676 または公開の問題が含まれている KB4041691 をインストールした後のブートに失敗する可能性があります。

「差分更新プログラム」がインストールされているが、再起動前の状態の場合は、「シナリオ 2」の対処方法を実施してください。再起動後に OS が起動できない状態の場合は、「シナリオ 3」の対処方法を実施してください。

(補足)
上記技術情報に記載の内容をわかりやすくまとめ直したものについて、次にご紹介いたします。

シナリオ 2. 「累積更新プログラム」と「差分更新プログラム」がインストールされているが、まだ再起動していない場合

コントロールパネルより、「累積更新プログラム」と「差分更新プログラム」の両方をアンインストールしてください。

Image may be NSFW.
Clik here to view.

シナリオ 3. 再起動し、起動できない状態になった場合

以下の手順でアンインストールを行います。

1. 何度か起動に失敗すると、青い自動修復画面が表示されますので、[詳細オプション] をクリックします。

2. [トラブルシューティング] – [詳細オプション] - [コマンド プロンプト] をクリックします。

3. コマンドプロンプトで以下のコマンドを実行し、Software ハイブをマウントします。
> reg load hklm\temp <OS ドライブ>\windows\system32\config\software
実行例: reg load hklm\temp C:\windows\system32\config\software

4. 以下のコマンドを実行し、レジストリ キーを削除します。
なお、環境によってはキーは存在しない場合がございますので、その際は次の手順に進んでください。
> reg delete “HKLM\temp\Microsoft\Windows\CurrentVersion\Component Based Servicing\SessionsPending” /v Exclusive
> reg unload HKLM\temp

5. 以下のコマンドを実行し、パッケージ情報を取得します。
> dism /Image:<OS ドライブ> /Get-Packages
例: Dism /Image:C:\ /Get-Packages

6. インストール済みのパッケージの一覧が表示されますので、状態が [保留中] となっているパッケージ ID を確認します。
出力例:
パッケージ ID : Package_for_RollupFix~31bf3856ad364e35~amd64~~15063.674.1.8
状態 : インストールの保留中
リリースの種類 : Security Update
インストール時刻 :

7. 手順 6 のパッケージ ID を使用して、以下のコマンドを実行し、削除します。
> Dism /Image:<OS ドライブ> /Remove-Package /PackageName:<パッケージ ID>
例: Dism /Image:C:\ /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~15063.674.1.8

8. 保留中のパッケージをすべて削除しましたら、コマンドプロンプトを終了し、[続行] をクリックして再起動します。


WSUS のクリーンアップ ウィザードについて

こんにちは。WSUS サポート チームです。

 

今回は WSUS のオプションより実行する、クリーンアップ ウィザードについて紹介いたします。クリーンアップ ウィザードは WSUS の運用を行う上で、メンテナンスの一環として必ず定期実行することをお勧めしているので、WSUS の運用を行われている方は、是非ご一読ください!

 

クリーンアップ ウィザードは、管理コンソールのオプションの下記の箇所から実行することができ、

Image may be NSFW.
Clik here to view.

 

実行しようとすると以下の 5 つの項目が選べます。

Image may be NSFW.
Clik here to view.
 

 

いずれの項目も、WSUS で保持されている更新プログラムのデータや、コンピューターの情報を整理・削除するための処理を実行するものとなりますが、実際に何が実行されるのか、なかなか分かりづらいですよね。

 

これを理解するためには、WSUS が保持する更新プログラムのデータの種類が、2 種類あることを事前に知っておく必要があります。具体的には下記の 2 種類です。

 

(a) WSUS データベース内のメタデータ

データベース内に保持される更新プログラムの情報です。WSUS 管理コンソール上に表示される下記のような更新プログラムの情報は、このメタデータの情報を元に表示しています。

Image may be NSFW.
Clik here to view.
 

 

(b) コンテンツ ファイル (更新プログラムのインストーラー本体)

WSUSContent フォルダ内に格納されている更新プログラムのインストーラー本体等のファイルです。これらのファイルは実際にクライアントにて更新プログラムがインストールされる際に利用されます。

WSUS 上では、WSUSContent フォルダ配下にコンテンツ ファイルが保存されています。

 Image may be NSFW.
Clik here to view.
 

 

以上を踏まえて、各項目の処理の詳細について説明していきます。

 

① 「不要な更新プログラムと更新プログラムのリビジョン」

「不要な更新プログラムと更新プログラムのリビジョン」はメタデータの削除を行う唯一の項目です。削除対象となる更新プログラムのメタデータが削除されます。

具体的には下記の 2 つの条件を「同時に」満たす場合に、該当する更新プログラムの情報がデータベースから削除されます。

 

条件:

- 期限切れの更新プログラム (弊社にて公開を停止した更新プログラム)

30日以上承認されていない更新プログラム

  (30日間以上、承認ステータスが変化していない更新プログラム

注意 : 「他の更新プログラムにバンドルされている更新プログラム」や「他の更新プログラムの前提条件となっている更新プログラム」は、削除の対象外となります。

 

上述のとおり「期限切れ (弊社にて公開を停止)」が設定されていない更新プログラムのレコードは、データベースからの削除対象とはなりません。

 

② 「サーバーにアクセスしていないコンピューター」

30日以上サーバーにアクセスしていないコンピュータの情報がデータベース上から削除されます。

 

③ 「不要な更新ファイル」

現時点で不要なコンテンツ ファイルを WSUSContent フォルダ内から削除します。

 

具体的には、「拒否済み」に設定されている更新プログラムのファイル、および、言語のオプションなどの設定変更の経緯により、現時点では不要と判断されるファイルが対象となります。本項目の詳細は下記ブログでも紹介しているので、コンテンツ ファイルの削減を行う場合には、ご参考としてください。

 

- WSUS で不要な更新プログラムのインストーラーを削除する

https://blogs.technet.microsoft.com/jpwsus/2015/08/13/wsus-17/

 

④ 「期限の切れた更新プログラム」

承認されない状態のまま期限切れとなった更新プログラムを「拒否済み」に設定します。この処理は、メタデータの更新であり、データベース内からメタデータの削除を実行するわけではありません。

 

⑤ 「置き換えられた更新プログラム」

下記の3つの条件を「同時に」満たす場合にのみ、該当する更新プログラムを「拒否済み」に設定します。この処理は、メタデータの更新であり、データベース内からメタデータの削除を実行するわけではありません。

 

条件:

30日間以上承認されていない更新プログラム

- 現在クライアントによって必要とされていない更新プログラム

- 承認された更新プログラムによって置き換えられる更新プログラム

 

 

参考情報 : 定期実行する場合の自動化の方法

クリーンアップ ウィザードを定期実行する場合は、スクリプトやコマンドをタスク スケジューラーより実行して自動化してしまうことも可能です。Windows Server 2012 以降の WSUS であれば、下記のコマンドレットが用意されているので、オプションを指定して実行することで、クリーンアップ ウィザードを Powershell から実行させることが可能です。


Invoke-WsusServerCleanup
https://docs.microsoft.com/ja-jp/powershell/module/wsus/invoke-wsusservercleanup


実行するクリーンアップ ウィザードの項目は、指定するオプションで制御することが可能です。下記ように各項目がオプションに対応しています。

 

<オプションの対応表>

・ 不要な更新プログラムおよび更新のリビジョン

        -CompressUpdates

        -CleanupObsoleteUpdates

 

・ サーバーにアクセスしていないコンピューター

        -CleanupObsoleteComputers

 

・ 不要な更新ファイル

        -CleanupUnneededContentFiles

 

・期限の切れた更新プログラム

        -DeclineExpiredUpdates

 

・ 置き換えられた更新

        -DeclineSupersededUpdates

 

例えば、不要な更新プログラムおよび更新のリビジョンを実行する場合は、下記のように指定して WSUS サーバー上で実行することで、クリーンアップを開始出来ます。

 

< 実行例 : 不要な更新プログラムおよび更新のリビジョンを実行する場合 >

Invoke-WsusServerCleanup -CompressUpdates -CleanupObsoleteUpdates

 

また、WSUS 3.0 SP2 以前の環境でも、クリーンアップ ウィザードは PowerShell スクリプトから実行出来ます。WSUS 3.0 SP2 以前の環境でクリーンアップ ウィザードを実行する PowerShell スクリプトは、下記を参考にしてください。

WSUS Clean - Powershell script
https://gallery.technet.microsoft.com/scriptcenter/WSUS-Clean-Powershell-102f8fc6

 

 

 

Windows 7 / Windows Server 2008 R2 以前の環境において、Microsoft Update 実行時に 0x80248015 エラーが発生する

皆さま、こんにちは。WSUS サポートチームです。

 

Windows 7 / Windows Server 2008 R2 以前の環境において、2017 12 4 (月曜日) より Microsoft Update 実行時に 0x80248015 エラーが発生する、というお問い合わせを多く頂いております。

 

本事象につきましては、弊社 Microsoft Update サイトに問題があったことに起因しており、2017 12 5 (火曜日) 午後 1 時に Microsoft Update サイト側の修正が完了いたしました。

 

この度は弊社 Microsoft Update サイトの問題により、ご迷惑をおかけいたしましたことを、深くお詫び申し上げます。

 

現時点では本問題は解消しているため、ご利用の端末側で対応を実施していただく必要はございません。しかし、一部の環境においては、依然として下記のエラー等が発生し続けるとの報告がございますため、本事象の詳細と現時点でエラーが発生し続ける環境での対処方法についてご案内いたします。

Image may be NSFW.
Clik here to view.

 

(事象)

2017 年 12 月 5 日 (火曜日) 以前において、次の 2 点 の条件を満たす環境で、0x80248015 エラーが発生して、Microsoft Update からの更新プログラムの取得に失敗します。

 

- Windows 7 / Windows Server 2008 R2 以前の環境

- Microsoft Update を有効にしており、インターネット上の Microsoft Update サイトより更新プログラムを取得している

WSUS 環境では発生いたしません

 

また、加えて下記の条件を満たす環境では、2017 12 5 (火曜日) 以降も上述のエラーが発生し続ける場合があります。

 

- 2017 年 12 月 4 日 (月曜日) 以前に開始された、更新プログラムのダウンロード ジョブが残存している

 

(原因)

弊社 Microsoft Update サイトに問題があったことに起因します。

 

(対処方法)

2017 年 12 月 5 日 (火曜日) 午後 1 時に Microsoft Update サイト側で対処を実施いたしましたため、現在は解決しております。

依然として上述のエラーが発生し続ける場合は、下記の対処方法を実施してください。

 

- Windows Update クライアントの情報をクリアにする手順

https://blogs.technet.microsoft.com/jpwsus/2014/12/02/windows-update-3/

※ 上記の手順は、こちらのバッチ ファイルでも実行可能です。ご利用の際は拡張子を「.bat」に変更し管理者権限でご実行ください。

 

 

不要な更新プログラムは「拒否済み」に設定しよう!

みなさま、こんにちは。WSUS サポート チームです。

今回は WSUS で設定出来る、更新プログラムの「拒否済み」の設定について、詳細を紹介いたします。

Image may be NSFW.
Clik here to view.

「そんなこと知ってどうするんだ…」と思われるかも知れませんが、WSUS はその性質上、過去にリリースされた更新プログラムの情報が、どんどん蓄積されてしまうシステムです。そのため、運用を行う上で、不要な更新プログラムを継続的に「拒否済み」に設定していき、不要な処理を実行させないようメンテナンスしていくことが非常に重要となります。本記事では、その詳細について説明していきます。

 

「拒否済み」とは?

「拒否済み」は、いわば「論理的な削除状態」です。具体的な他の承認状態との違いは、以下の通りとなります。

承認状態 クライアントへの配信 レポート情報の収集 設定の単位
インストール承認 配信される 収集される コンピューター グループ単位
未承認 (既定) 配信されない 収集される コンピューター グループ単位
削除の承認 配信されない

(アンインストールがされる)

収集される コンピューター グループ単位
拒否済み 配信されない 収集されない WSUS サーバー全体

 

「拒否済み」に設定すると、「未承認」状態と同じくクライアントへの配信は行われませんが、レポート情報の収集も行わなくなります。この点が他の承認状態との大きな違いです。逆に言うと更新プログラムを WSUS 上で「拒否済み」に設定しない限り、実はクライアントや WSUS サーバーでは、レポート情報を収集するための処理を実行し続けることになります。

ちなみに一度「拒否済み」に設定した更新プログラムでも、他の承認状態に任意のタイミングで変更し、再度配信等を実施することは可能ですので、その点はご安心ください。

 

「拒否済み」に設定すると何が嬉しいの?

更新プログラムを「拒否済み」に設定することの、具体的なメリット・デメリットは下記の通りとなります。

1 ~ 2 件の更新プログラムを「拒否済み」に設定したところで大きな効果が得られるわけではありませんが、WSUS は数千から数万件の更新プログラムを管理することが当たり前なので、塵も積もれば山となり、WSUS の負荷やディスク容量に大きな影響を与えてしまいます。

既に配信の必要がなく、レポート情報も収集する必要がない更新プログラムについては「拒否済み」に設定することにメリットしかありません。どんどん不要な更新プログラムは「拒否済み」に設定していきましょう。

 

メリット

  • クライアントや WSUS サーバーで「拒否済み」に設定した更新プログラムのレポート情報の収集が行われなくなるため、クライアントや WSUS サーバーの負荷が軽減される。
  • クリーンアップ ウィザードの「不要な更新ファイル」項目の削除対象となるため、WSUS サーバーのディスク容量の消費を削減出来る。

 

デメリット

  • レポート情報の収集が行われなくなるため、クライアントへ適用が行われているか、配信が必要であるか、WSUS 上のレポートから確認出来なくなる。
  • WSUS 全体での設定となるため、一部のコンピューター グループだけを「拒否済み」にすることは出来ない。

 

どうやって「拒否済み」に設定する更新プログラムを選べばいいの?

では、具体的にどうやって「拒否済み」に設定する更新プログラムを選んでいくか紹介していきます。一般的には下記の方法があります。

 

A. クリーンアップ ウィザードを実行する

B. 置き換えが行われた更新プログラムを「拒否済み」に設定する

C. 不要となった分類や製品の更新プログラムを「拒否済み」に設定する

 

Aについては、このブログで詳細を紹介しているので、こちらを参照してください。「期限の切れた更新プログラム」と「置き換えられた更新プログラム」が、更新プログラムを「拒否済み」に設定する項目となります。

B」「Cについては、本ブログで詳細な手順を紹介していきます。

 

B. 置き換えが行われた更新プログラムを「拒否済み」に設定する

更新プログラムの中には、より新しい置き換えが行われた更新プログラムがリリースされているものがあります。このような更新プログラムは、新しい方の更新プログラムが WSUS から配信されれば、古い方の更新プログラムを配信しなくても、クライアントとしては最新のセキュアな状態となります。

このため、「クライアントが最新の状態になれば問題ない」という方針で運用されている場合には、置き換えが行われた更新プログラムを「拒否済み」の設定対象とすることが可能です。

WSUS 管理コンソールでは、既に置き換えが行われた更新プログラムを管理コンソールから一括して判別が出来るので、下記の手順で置き換えが行われた更新プログラムを纏めて「拒否済み」に設定しましょう。

※ 注意 : 最新の更新プログラムを配信する方針 (数ヶ月遅れで更新プログラムを配信する等) でご運用されていない場合には、本手順を実施しないでください。本手順は最新の更新プログラムを配信する方針で運用している環境を前提としております。

 

- 手順

  1. WSUS サーバーで、[管理ツール] [Windows Server Update Services] を開きます。
  2. [すべての更新プログラム] で、下記のようにフィルタを選択し、[最新の情報に更新] を選択します。
    Image may be NSFW.
    Clik here to view.
  3. 中央画面の項目バー(タイトル、承認等が表示されているバー)を右クリックし、[優先] にチェックを入れます。
    Image may be NSFW.
    Clik here to view.
  4. [優先] の項目(ピラミッド型のアイコン) が表示されますので、当該項目をクリックして、ソートします。Image may be NSFW.
    Clik here to view.
    Image may be NSFW.
    Clik here to view.
    のアイコンを持つ更新プログラムは、既に新しい更新で置き換えが行われており、「拒否済み」対象と判断できます。※ 下記の 3 種類のアイコンがあります。アイコンの表示がない更新プログラムは、置き換え関係を持つ更新がないので承認する必要があります。
    Image may be NSFW.
    Clik here to view.
    :
    置き換え関係を持つ更新プログラムの中で、最新の更新プログラムです。承認する必要があります。
    Image may be NSFW.
    Clik here to view.
    :
    より新しい更新プログラムと、より古い更新プログラムの双方が存在する更新です。「拒否済み」に設定します。
    Image may be NSFW.
    Clik here to view.
    :
    置き換え関係を持つ更新プログラムの中で、最も古い更新プログラムです。「拒否済み」に設定します。
  5. Image may be NSFW.
    Clik here to view.
    Image may be NSFW.
    Clik here to view.
    のアイコンを持つ更新プログラムを選択し、[右クリック] - [拒否] をクリックすることで、「拒否済み」に設定します。
    Ctrl や Shift を押しながら、選択することで一括して「拒否済み」に設定することも可能です。

 

【補足 : スクリプトで「拒否済み」に変更する方法】
以下のリンクで、置き換えられら更新プログラムの承認ステータスを「拒否済み」に変更するスクリプトをご提供しております。ダウンロードいただいたファイルの名前を Decline-SupersededUpdates.ps1 に変更して WSUS 上でご利用ください。タスク スケジューラーから定期的に実行させることも可能です。

Download

 

(実行方法の例)

powershell.exe -Command C:\Temp\Decline-SupersededUpdates.ps1

 

(実行結果の例)

Connecting to WSUS server  on Port ... Connected.

Getting a list of all updates... Done

Parsing the list of updates... Done.

List of superseded updates: C:\Temp\SupersededUpdates.csv

 

Summary:

========

All Updates = 17829

Any except Declined = 4418

All Superseded Updates = 118

Superseded Updates (Intermediate) = 112

Superseded Updates (Last Level) = 6

 

SkipDecline flag is set to False. Continuing with declining updates

DeclineLastLevel is set to False. Declining all superseded updates.

Declined 118 updates.

Backed up list of superseded updates to C:\Temp\SupersededUpdatesBackup.csv

 

Done

 

C. 不要となった製品の更新プログラムを「拒否済み」に設定する

Windows XP Windows Server 2003 等、もう管理の必要のない OS や製品の更新プログラムが WSUS 上に同期されている状態であれば、それら「拒否済み」の設定対象としていただくことが可能でしょう。

この場合には、下記の手順で更新ビューの機能を用いて、その製品の更新プログラムだけを表示して「拒否済み」に設定すると便利です。

 

- 手順

  1. WSUS サーバーで、[管理ツール] [Windows Server Update Services] を開きます。
  2. 左ペインより [Update Services] - [<WSUS サーバー名>] - [更新プログラム] を右クリックし、[新しい更新ビュー] を選択します。
    Image may be NSFW.
    Clik here to view.
  3. ステップ 1 にて、[更新は特定の製品用です] にチェックを入れ、ステップ 2 [任意の製品] をクリックします。
    Image may be NSFW.
    Clik here to view.
  4. [すべての製品] のチェックを外し、「拒否済み」の設定を行いたい製品にチェックを入れ、[OK] をクリックします。
  5. ステップ 3 にて、任意の更新ビューの名前を入力し、[OK] をクリックします。
  6. 左ペインより [Update Services] - [<WSUS サーバー名>] - [更新プログラム] 配下に作成された更新ビューを選択し、中央ペインに対象製品用の更新プログラムのみが表示されていることを確認します。
  7. 対象製品用の不要な更新プログラムを選択して右クリックし、[拒否] を実行することで 「拒否済み」に設定します。

 

※ 注意 : 拒否済みの設定対象製品の更新プログラムについて

.Net Framework 用の更新プログラム等の中には、複数の OS に跨って提供されるものがあるため、製品別に「拒否済み」に設定される場合は、ご注意ください。

複数の製品に跨って提供されている更新プログラムを一覧で識別するような方法はありませんが、更新プログラムのタイトルや下記の箇所の情報から、複数の製品に跨って提供されている、更新プログラムではないか、確認が可能です。

 Image may be NSFW.
Clik here to view.

 

いかがだったでしょうか。「拒否済み」は WSUS を安定運用させるための強力な武器です。是非普段の運用の中に取り入れてみてください!

 

WSUS 上で KB4022730 のダウンロードに失敗する

皆さま、こんにちは。WSUS サポート チームです。

 

今回は WSUS サーバーにおいて、下記の 2 つの Windows 10 向けの更新プログラムのダウンロードに失敗する事象について、詳細と対処方法を紹介します。

 

・2017-06 x86 ベースシステム用 Windows10 Version 1703 セキュリティ更新プログラム (Adobe Flash Player 対応) (KB4022730)

・2017-06 x64 ベースシステム用 Windows10 Version 1703 セキュリティ更新プログラム (Adobe Flash Player 対応) (KB4022730)

 

詳細

対象の 2 つの更新プログラム ファイルに付与されているデジタル署名の証明書は期限が 2017 12 5 日までに指定されています。このため、2017 12 5 日以降に WSUS にてダウンロードを試みた場合、証明書の有効期限が切れていることを検知し、「File cert verification failure. 」エラーにてダウンロードに失敗します。

 

大変恐縮ながら、KB4022730 はより新しい更新プログラムにて置き換えられており、新しい更新プログラムを配信していただければ KB4022730 の配信が必要ないこと、また KB4022730 のダウンロードに失敗する事象が発生することで、その他の WSUS の動作に影響がないことから、対象の更新プログラムの証明書の有効期限が延長される予定はございません。

 

なお、本事象が発生した場合には、下記のようなエラーが WSUS サーバー上のイベント ログに出力されます。

 

----------------------------------

ログの名前:         Application

ソース:           Windows Server Update Services

日付:            2018/01/15 21:43:42

イベント ID:       364

タスクのカテゴリ:      2

レベル:           エラー

キーワード:         クラシック

ユーザー:          N/A

コンピューター:       WSUS12R2

説明:

コンテンツ ファイル ダウンロードに失敗しました。

理由: File cert verification failure.

ソース ファイル: /c/msdownload/update/software/secu/2017/06/windows10.0-kb4022730-x86_749a5a7af3ac36a1ff014171f2b21eb38fc224f4.cab

ターゲット ファイル: C:\WSUS\WsusContent\F4\749A5A7AF3AC36A1FF014171F2B21EB38FC224F4.cab

----------------------------------

 

また、下記の手順で、実際に対象の更新プログラムのダウンロードに失敗しているか確認することが可能です。

 

- 確認手順

1. WSUS 管理コンソールを起動し、[<WSUS サーバー名>] - [更新プログラム] - [すべての更新プログラム] の順に選択します。

2. 中央画面上部の表示フィルターを以下のように設定して、[最新の状態に更新] をクリックします。

承認:拒否された更新以外のすべて
状態:任意

3. タイトル、承認、等の項目が表示されている、中央画面の項目バーを右クリックし、[ファイルの状態] の項目を追加します。[ファイルの状態] の項目をクリックして、更新プログラム一覧をソートします。

Image may be NSFW.
Clik here to view.

4. [ファイルの状態] が赤バッテンのアイコン (ダウンロード失敗) になっている更新プログラムが、対象の 2 つの更新プログラムである場合には、本事象に該当しているものと判断出来ます。

Image may be NSFW.
Clik here to view.

 

対処方法

Adobe Flash Player 向けの KB4022730 は、既により新しい更新プログラムに置き換えられており、セキュリティの観点からはより新しい更新プログラムを配信していただければ、KB4022730 を配信する必要がありません。このため、下記の手順にて対象の更新プログラムを「拒否済み」に設定し、ダウンロードを停止した後に、新しい更新プログラムを承認していただくことが対処方法となります。

 

- 手順

1. WSUS 管理コンソールを起動し、[<WSUS サーバー名>] - [更新プログラム] - [すべての更新プログラム] の順に選択します。

2. 右ペインの [検索...] をクリックします。

3. 検索ボックスに KB4022730 と入力して、[検索] をクリックします。

4. 検索結果に KB4022730 に一致する更新プログラムが表示されますので、今回対象の下記の更新プログラムを見つけます。

 

2017-06 x86 ベース システム用 Windows10 Version 1703 セキュリティ更新プログラム (Adobe Flash Player 対応) (KB4022730)

2017-06 x64 ベース システム用 Windows10 Version 1703 セキュリティ更新プログラム (Adobe Flash Player 対応) (KB4022730)

 

5. 問題の更新プログラムを右クリックして、[拒否] をクリックします。

6. ダイアログが表示されますので、[はい] をクリックして、画面を閉じます。

7. 検索ボックスに、KB4022730 よりも新しい Adobe Flash Player 向けの更新プログラムの KB 番号を入力して、[検索] をクリックします。

※ より新しい Adobe Flash Player 向けの更新プログラムは、下記の Microsoft Update カタログ上で確認出来ます。

http://www.catalog.update.microsoft.com/Search.aspx?q=Adobe+Flash+Player+Windows+10+1703

8. 検索結果に一致する更新プログラムが表示されますので、配信対象の更新プログラムを見つけます。

9. 対象の更新プログラムを右クリックして、[承認] をクリックし、配信が必要なグループに対し、更新プログラムの配信を開始します。

 

WSUS クライアントのグループ ポリシー : その 3 – Windows 10 基本編

こんにちは。WSUS サポートチームです。

今回は、Windows 10 WSUS クライアントとして管理する場合のオススメのグループ ポリシーの設定や設定時の注意点を、下記のシナリオ毎に紹介します。Windows 10 の導入を検討されている方や既に導入されている方は是非ご一読ください!

 

A. 更新プログラムを WSUS サーバーのみから取得するようにしたい場合

B. 更新プログラムの自動適用は WSUS サーバーから行なうが、外部へ端末を持ち出した際等に手動で Windows Update / Microsoft Update サイトより更新プログラムの取得を行えるようにしたい場合

 

A. 更新プログラムを WSUS サーバーのみから取得するようにしたい場合

Windows 10 のクライアントにて、WSUS サーバーからのみ更新プログラムを取得させたい場合には、下記の 3 種類のグループ ポリシーを有効に設定してください。

 

1. [コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [イントラネットの Microsoft 更新サービスの場所を指定する]

2. [コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [自動更新を構成する]

3-1. [コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [インターネット上の Windows Update に接続しない]

もしくは

3-2. [コンピューターの構成] -> [管理用テンプレート] -> [システム] -> [インターネット通信の管理] -> [インターネット通信の設定]
-> [Windows Update のすべての機能へのアクセスをオフにする]

 

また、Window 10 バージョン 1607 の環境では、上記の設定に加え、下記の設定を有効にすることをご検討ください。

 

4. デュアル スキャン対策のため KB4025334  (OS Build 14393.1532) 以降の更新プログラムを適用後

4-1. [コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [Windows Update に対するスキャンを発生させる更新遅延ポリシーを許可しない]

および

4-2. [コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update] -> [Windows Update   延期]
    -> [機能更新プログラムをいつ受信するかを選択してください]
※ ブランチ準備レベルや延期日数については任意の値で構いません。

 

1、2 のグループ ポリシーについては、こちらの記事で詳細を紹介しているため、本記事では 3、4 について詳細を紹介していきます。

 

< 3. [インターネット上の Windows Update に接続しない] もしくは [Windows Update のすべての機能へのアクセスをオフにする] >

このいずれかのグループ ポリシー設定しないと、設定画面上にてユーザーが以下の [オンラインで Microsoft Update から更新プログラムを確認します。] ボタンを押した場合には、WSUS サーバーではなく Windows Update / Microsoft Update サイトより更新プログラムを取得してしまいます。このため、WSUS サーバーのみから更新プログラムを取得させたい場合には、必ずいずれかの設定をしていただく必要があります。

Image may be NSFW.
Clik here to view.

また、[インターネット上の Windows Update に接続しない] を有効にした場合は、ストアアプリのインストールや更新ができません。ストアアプリのインストールや更新を許可したい場合は、[Windows Update のすべての機能へのアクセスをオフにする] の方を有効にしてください。

 

< 4. デュアル スキャン対策の設定 >

Windows 10 バージョン 1607 の環境においては、上記の 3 種類の設定を行っても、ユーザーが下記のチェックボックスにチェックを入れた場合には、WSUS からではなく Windows Update / Microsoft Update サイトより更新プログラムを取得してしまいます。これはこの記事で詳細を紹介している通り、下記のチェックを有効化することで、Windows Update for Business が有効化され、デュアル スキャンが発生するためです。

Image may be NSFW.
Clik here to view.

上述の 4 の設定を行うことで、上記のチェック ボックスがグレー アウトするため、ユーザー操作によってデュアル スキャンが動作することを防ぐことが出来ます。

なお、Windows 10 バージョン 1703 以降の環境では、この記事の「補足3:UIの表示について」で紹介している通り、1 の設定を行うと上記の設定に対応する項目は非表示となるため、本設定をしていただく必要はありません

 

B. 更新プログラムの自動適用は WSUS サーバーから行なうが、外部へ端末を持ち出した際等に手動で Windows Update / Microsoft Updateサイトより更新プログラムの取得を行えるようにしたい場合

基本的には WSUS サーバーから更新プログラムの自動配信が行われるようにしつつも、外部へ端末を持ち出したタイミング等で WSUS サーバーと通信が行えない環境では、ユーザー操作によって Windows Update / Microsoft Update サイトより更新プログラムを取得出来るようにしたいという場合には、以下の設定を行ないます。

 

1. [コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [イントラネットの Microsoft 更新サービスの場所を指定する]

2. [コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [自動更新を構成する]

3. デュアル スキャン対策のため Windows 10 1607 の場合、KB4025334  (OS Build 14393.1532) 以降の更新プログラム、Windows 10 1703 の場合、 KB4041676 (OS Build 15063.674) 以降の更新プログラムを適用後

3-1. [コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [Windows Update に対するスキャンを発生させる更新遅延ポリシーを許可しない]

および

3-2. [コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update] -> [Windows Update の  延期 / Windows Update for Business]
    -> [機能更新プログラムをいつ受信するかを選択してください / プレビュー ビルドや機能更新プログラムをいつ受信するか選択してください]

 

こちらについても 1、2 のグループ ポリシーについては、この記事で詳細を紹介しているため、本記事では 3 について詳細を紹介していきます。

 

< 3. デュアル スキャン対策の設定 >

本シナリオの場合、WSUS サーバーからだけではなく Windows Update / Microsoft Update サイトからも更新プログラムを受信するため、下記のグループ ポリシーの設定を検討していただく必要があります。Windows Update / Microsoft Update サイトでは常に最新の更新プログラムが配信されているため、下記の設定をしないと、WSUS 上で配信の制限を掛けている更新プログラムやアップグレードが、ユーザーが [オンラインで Microsoft Update から更新プログラムを確認します。] をクリックしたタイミングで配信されてしまうことがあります。

 

3-2. [コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update] -> [Windows Update   延期 / Windows Update for Business]
    -> [機能更新プログラムをいつ受信するかを選択してください / プレビュー ビルドや機能更新プログラムをいつ受信するか選択してください] ※ 本設定についてはこの記事でも詳細を紹介しております。

 

また、上記の設定に加え下記の設定を行わないと、この記事で詳細を紹介している通り、Windows Update for Business が有効化され、デュアル スキャンの動作が発生してしまいます。

 

3-1. [コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [Windows Update に対するスキャンを発生させる更新遅延ポリシーを許可しない]

 

上記の設定を全て行うことで、自動更新や下記の設定画面の [更新プログラムのチェック] を押したタイミングでは、WSUS 上で承認している更新プログラムが全て配信され、[オンラインで Microsoft Update から更新プログラムを確認します。] をクリックした場合には、3-2 で指定した延期日数やブランチの設定に合わせて機能更新プログラムの配信が行われます。

Image may be NSFW.
Clik here to view.

 

補足 : デュアル スキャンに関する注意事項

この記事で紹介している通り、下記の 3 つのグループ ポリシーは上述のデュアル スキャン対策と合わせて設定しないと、WSUS サーバーからではなく、Windows Update / Microsoft Update サイトから更新プログラムを取得する動作が発生してしまいますのでご注意ください。

 

[コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update] -> [Windows Update の延期]
-> [
機能更新プログラムをいつ受信するかを選択してください / プレビュー ビルドや機能更新プログラムをいつ受信するか選択してください]
-> [
品質更新プログラムをいつ受信するかを選択してください]

[コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
->  [Windows Update
からドライバーを除外する]

 

WSUS 上の Windows 10 の機能更新プログラムのタイトルについて

みなさま、こんにちは。WSUS サポート チームです。

 

WSUS 上では、機能更新プログラムは下記のように似たようなタイトルの機能更新プログラムが 2 つの表示されます。今回はこの 2 つのどちらを承認すべきか悩む方に向けたブログとなります。

 

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

 

上記の 2 つの機能更新プログラムの違いは、配信対象のクライアントのライセンスの違いとなります。上記の例では、ボリューム ライセンスを利用しているクライアントに対してはビジネス エディションを、それ以外のリテール ライセンス等を利用しているクライアントにはコンシューマー エディションを配信する必要があります。

 

このため、WSUS 配下にボリューム ライセンスを利用しているクライアントと、リテール ライセンスを利用しているクライアントが両方いる場合には、2 つの機能更新プログラム共に承認していただく必要があります。

 

また、機能更新プログラムのタイトルは、以下のようにバージョンによっても少し異なるため注意してください。

 

>> ボリューム ライセンスのクライアントを対象にした機能更新プログラムのタイトル例

Windows 10 (ビジネス エディション)、バージョン 1709ja-jp の機能更新プログラム

Windows 10 Enterprise、バージョン 1703ja-jp の機能更新プログラム

Windows 10 Enterprise、バージョン 1607ja-jp の機能更新プログラム

 

>> リテール ライセンス等のクライアントを対象にした機能更新プログラムのタイトル例

Windows 10 (コンシューマー エディション)、バージョン 1709ja-jp の機能更新プログラム

Windows 10 Enterprise、バージョン 1703ja-jp、製品版の機能更新プログラム

Windows 10 Enterprise、バージョン 1607ja-jpRetail の機能更新プログラム

 

WSUS での Windows 10 管理まとめ

こんにちは。WSUS サポート チームです。

Windows 10 がリリースされてから月日が立ち、WSUS Windows 10 を管理されるお客様も増えてきています。

このブログ記事では、そんなお客様に向けて Windows 10 の管理に関してこれまで公開してきたブログや公開情報を纏めて紹介します。これからも順次更新していきますので、乞うご期待ください!

 

Windows 10 のサポート モデル

LTSC 以外の Windows 10 を管理する場合には、WaaS のサポート モデルに沿って、必ず継続的にアップグレードをする必要があります。基本的な WaaS (Windows as a Service) の考え方は、下記の公開情報にて紹介しているので、ご参考としてください。

 

- サービスとしての Windows のクイック ガイド

https://docs.microsoft.com/ja-jp/windows/deployment/update/waas-quick-start

 

また、各 Windows 10 バージョンのサポート期間は下記にて紹介しています。

 

- Windows ライフサイクルのファクト シート

https://support.microsoft.com/ja-jp/help/13853/windows-lifecycle-fact-sheet

 

各バージョンや更新プログラムのリリース履歴については、下記の公開情報を用意しています。

 

- Windows 10 のリリース情報

https://technet.microsoft.com/ja-jp/windows/release-info.aspx

 

- Windows 10 の更新履歴

https://support.microsoft.com/ja-jp/help/4018124/windows-10-update-history

 

 

設計時のTips

 

WSUS サーバー側のTips

WSUS からアップグレードを配信するためには、事前に準備が必要です。詳細は下記ブログで紹介しています。

 

- WSUS サーバーからの Windows 10 のアップグレードの配信

https://blogs.technet.microsoft.com/jpwsus/2016/02/11/wsus-windows-10/

 

また、各 OS の WSUS の最新バージョンについては下記ブログで紹介しているため、基本的に最新バージョンを利用することをご検討ください。

 

- WSUS サーバーのバージョン番号について

https://blogs.technet.microsoft.com/jpwsus/2016/02/16/wsus-18/

 

アップグレードや更新プログラムの累積化に伴って Windows 10 では更新プログラムのサイズが大きくなっています。WSUS 利用時のネットワーク帯域制御方法については下記で紹介しています。

 

- WSUS 環境のネットワーク帯域制御について

https://blogs.technet.microsoft.com/jpwsus/2012/03/15/wsus-4/

 

- Windows 10 バージョン 1607 の環境にて BranchCache を利用する際の条件

https://blogs.technet.microsoft.com/jpwsus/2017/03/15/win10-1607-branchcache/

 

- 配信の最適化について #1 概要篇

https://blogs.technet.microsoft.com/jpwsus/2017/09/04/aboutdo_1/

 

Windows 10 を管理するためにオプションにて選択する製品等については、下記にて紹介しています。

 

- WSUS で選択する Windows 10 の製品分類について

https://blogs.technet.microsoft.com/jpwsus/2016/09/23/wsus-windows-10-product/

 

- Windows 10 LTSB の 更新プログラムを WSUS で同期する際の注意事項について

https://blogs.technet.microsoft.com/jpwsus/2017/08/09/windows-10-ltsb/

 

- WSUS 上の Windows 10 の機能更新プログラムのタイトルについて

https://blogs.technet.microsoft.com/jpwsus/2018/01/26/upg-title/

 

クライアント側の Tips

クライアント側での自動更新の動作の制御については、下記ブログで紹介しています。

 

- Windows 10 の Windows Update の自動更新設定

https://blogs.technet.microsoft.com/jpwsus/2015/09/17/windows-10-windows-update/

 

また、WSUS クライアントのグループ ポリシーの動作については、以下をご参考としてください。

 

- WSUS クライアントのグループ ポリシー : その 1 – 基本編

https://blogs.technet.microsoft.com/jpwsus/2015/03/24/wsus-1/

 

- WSUS クライアントのグループ ポリシー : その 2 – Windows 8 / Windows Server 2012 以降編

https://blogs.technet.microsoft.com/jpwsus/2015/03/24/wsus-2-windows-8-windows-server-2012/

 

- WSUS クライアントのグループ ポリシー : その 3 – Windows 10 基本編

https://blogs.technet.microsoft.com/jpwsus/2018/01/24/wsus-gp3/

 

WSUS サーバーとクライアントの間にプロキシが存在する場合には、必ずネットワーク環境に合わせて適切にプロキシを構成する必要があります。下記の情報をご確認ください。

 

- プロキシ サーバー経由での Windows Update へのアクセスについて

https://blogs.technet.microsoft.com/jpwsus/2017/05/17/proxy-settings/

 

 

よくお問い合わせいただく既知の問題

よくお問い合わせをいただく既知の問題については、ブログを用意していますのでご参考としてください。

 

WSUS サーバー側の問題

 

- Windows 10 / Windows Server 2016 を管理している環境で WSUS サーバー の負荷が高騰する

https://blogs.technet.microsoft.com/jpwsus/2017/08/30/win10-high/

 

- WSUS 上で KB4022730 のダウンロードに失敗する

https://blogs.technet.microsoft.com/jpwsus/2018/01/16/wsus-kb4022730/

 

クライアント側の問題

 

- Windows 10 バージョン1607 で更新プログラム適用後の自動再起動が実施されない

https://blogs.technet.microsoft.com/jpwsus/2017/07/10/win10-reboot/

 

- Windows 10 機能更新プログラムインストール後の再起動について

https://blogs.technet.microsoft.com/jpwsus/2017/07/07/update-and-restart/

 

- Windows 10 の WSUS クライアントが Windows Update から更新プログラムを取得するようになってしまう事象について

https://blogs.technet.microsoft.com/jpwsus/2016/11/15/windows-10-1607-wufb/

 

- Windows 10 バージョン 1607 および Windows Server 2016 の環境で、更新プログラムのダウンロードが途中から進まなくなる問題について

https://blogs.technet.microsoft.com/jpwsus/2016/10/28/win10-stop-download/

※ この事象については、こちらの公開情報でも紹介しております。

 

- 「削除の承認」が Windows 10 / Windows Server 2016 のクライアントに反映されない事象について

https://blogs.technet.microsoft.com/jpwsus/2017/09/04/cant-delete-win10/

 

- Windows 10 ベースのコンピューターが WSUS コンソールに表示されない場合がある

https://blogs.technet.microsoft.com/askcorejp/2017/04/21/windows-10-%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AE%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%BC%E3%81%8C-wsus-%E3%82%B3%E3%83%B3%E3%82%BD%E3%83%BC%E3%83%AB%E3%81%AB%E8%A1%A8%E7%A4%BA/

※ この事象については、こちらの公開情報でも紹介しております。

 


ReportingEvents.log の見方

みなさん、こんにちは。WSUS サポート チームです。

今日は Windows Update の処理の状況が記録される ReportingEvents.log の見方について紹介します。

このログ ファイル自体は以前の OS から存在していましたが、特に Windows 10 や Windows Server 2016 では Get-WindowsUpdateLog を実行しないと WindowsUpdate.log が参照出来なくなったので、検証の際やトラブル シューティングの際にリアルタイムにログを確認する場合には、こちらのログを利用することをオススメしております。

ReportingEvents.log は以下のフォルダにリアルタイムで TXT 形式で保存されます。
C:\Windows\SoftwareDistribution\ReportingEvents.log

 

Windows Update の処理の実行順序


ReportingEvents.log  を見るためには、Windows Update の処理の実行順序を理解しておく必要があります。Windows Update の処理は下記の順に実行され、ReportingEvents.log には、各処理の結果が出力されるため ReportingEvents.log  でどの処理まで進んでいるか、またどの処理で失敗しているのかが確認が可能です。

 

A. 更新プログラムの検出
⇒ 新たに適用が必要な更新プログラムがあるかどうかの確認処理

B. 更新プログラムのダウンロード
⇒ 「A」にて検出された更新プログラムのダウンロード処理

C. 更新プログラムのインストール
⇒ 「B」にてダウンロードされた更新プログラムのインストール処理

 

各処理が成功した場合の記録


Windows Update の各処理が成功した場合には、ReportingEvents.log に以下の通り記録され、処理が正常に進んでいることが確認出来ます。

 

A. 更新プログラムの検出 が成功した時の記録
AGENT_DETECTION_FINISHED
と記録されます。

{68D698EE-B4A7-4CA5-9D33-EFB2EDE6CD36}        2017-12-13 10:37:22:371+0900        1        147 [AGENT_DETECTION_FINISHED]        101        {00000000-0000-0000-0000-000000000000}        0        0        UpdateOrchestrator        Success        Software Synchronization        Windows Update Client successfully detected 3 updates.

 

B-1. 更新プログラムのダウンロードが開始された時の記録
AGENT_DOWNLOAD_STARTED と記録されます。

{1AF10086-220D-47E2-BA6B-7CDA8358E2C8}        2017-12-13 10:37:23:309+0900        1        167 [AGENT_DOWNLOAD_STARTED]        101        {89F1C905-9C84-4A67-9B90-17B5E30B0FCF}        201        0        UpdateOrchestrator        Success        Content Download        Download started.

 

B-2. 更新プログラムのダウンロードが成功した時の記録
AGENT_DOWNLOAD_SUCCEEDED
と記録されます。

{4C01117E-1FB6-404C-B32B-3EBE8A15A185}        2017-12-13 10:37:26:762+0900        1        162 [AGENT_DOWNLOAD_SUCCEEDED]        101        {89F1C905-9C84-4A67-9B90-17B5E30B0FCF}        201        0        UpdateOrchestrator        Success        Content Download        Download succeeded. 

 

C-1. 更新プログラムのインストールが開始された時の記録
AGENT_INSTALLING_STARTED
と記録されます。

{55010EE0-76AE-42B0-A212-89169299185E}        2017-12-13 10:43:11:392+0900        1        181 [AGENT_INSTALLING_STARTED]        101        {9A3FB4A5-968D-47D6-B87E-CD248FB9EEF7}        200        0        UpdateOrchestrator        Success        Content Install        Installation Started: Windows has started installing the following update: 2017-12 x64 ベース システム用 Windows Server 2016 の累積更新プログラム (KB4053579) 

 

C-2. 更新プログラムのインストール後に再起動待ち状態となった際の記録
AGENT_INSTALLING_PENDING
と記録されます。

{57866C44-0196-4EFB-A265-64B5F691B73F}        2017-12-13 10:59:40:657+0900        1        201 [AGENT_INSTALLING_PENDING]        101        {9A3FB4A5-968D-47D6-B87E-CD248FB9EEF7}        200        240005        UpdateOrchestrator        Success        Content Install        Installation pending. 

 

C-3. 更新プログラムのインストールが成功した時の記録
AGENT_INSTALLING_SUCCEEDED
と記録されます。

{E9D3C1A8-1EEF-4AD9-9FA8-19BFA0C1FD4F}        2017-12-13 17:39:11:176+0900        1        183 [AGENT_INSTALLING_SUCCEEDED]        101        {9A3FB4A5-968D-47D6-B87E-CD248FB9EEF7}        200        0        UpdateOrchestrator        Success        Content Install        Installation Successful: Windows successfully installed the following update: 2017-12 x64 ベース システム用 Windows Server 2016 の累積更新プログラム (KB4053579) 

 

各処理が失敗した場合の記録


これに対して Windows Update の各処理が失敗した場合には、下記の通り失敗した旨とエラー コードが出力されます。

 

A. 更新プログラムの検出が失敗した時の記録
AGENT_DETECTION_FAILED
の記録と共にエラー コードが記録されます。

{F6703CB6-0C82-4E7B-8C75-C25946AA03B0} 2018-01-17 20:13:28:509+0900  1      148 [AGENT_DETECTION_FAILED]      101    {00000000-0000-0000-0000-000000000000} 0      8024402c       UpdateOrchestrator    Failure Software Synchronization      Windows Update Client failed to detect with error 0x8024402c. 

 

B. 更新プログラムのダウンロードが失敗した時の記録
AGENT_DOWNLOAD_FAILED
の記録と共にエラー コードが記録されます。

{BC2328B6-6BE3-4C84-9F01-E177859503B6}        2017-12-12 19:30:38:444+0900        1        161 [AGENT_DOWNLOAD_FAILED]        101        {3FD93540-CD8C-4939-A71D-1C2BE7767D4D}        200        80246008        UpdateOrchestrator        Failure        Content Download        Error: Download failed. 

 

C. 更新プログラムのインストールが失敗した時の記録
AGENT_INSTALLING_FAILED
の記録と共にエラー コードが記録されます。

{2C3C39FA-FC0F-4F44-9049-D2AA53B27FFB}        2017-12-12 19:46:19:636+0900        1        182 [AGENT_INSTALLING_FAILED]        101        {BFC8A103-FD5F-4458-9935-231D9F79E2C1}        203        80242015        UpdateOrchestrator        Failure        Content Install        Installation Failure: Windows failed to install the following update with error 0x80242015: 2017-11 x64 ベース システム用 Windows Server 2016 の累積更新プログラム (KB4051033) 

 

また、Windows Update の実行時に出力される一般的なエラー コードは以下の公開情報にて紹介しているので、トラブル シューティングの際には参考としてください。

WSUS クリーンアップ ウィザードにてタイムアウトが発生する

みなさま、こんにちは。WSUS サポート チームです。

今日はよくお問い合わせいただく事象の 1 つである WSUS クリーンアップ ウィザードがタイムアウトで失敗してしまう事象について紹介いたします。

クリーンアップ ウィザードの詳細については、以下のブログで紹介しているので、クリーンアップ ウィザードの詳細について、まずは知りたいという方は以下を先にご覧ください。

WSUS のクリーンアップ ウィザードについて
https://blogs.technet.microsoft.com/jpwsus/2017/12/05/43/

 

事象の詳細


クリーンアップ ウィザードの 1 番上の項目「不要な更新プログラムと更新プログラムのリビジョン」は、クリーンアップの各項目の中でも、特に処理対象のデータ量が多くなりやすい項目です。弊社での実績上では、運用を開始してから数年経過した環境で初めて実行すると、数十時間 ~ 1 日を要することもあるような項目です。

このため、処理の途中でタイムアウトが発生してし、エラーで途中停止してまうことも、しばしばあります。

Image may be NSFW.
Clik here to view.

 

対処方法


定期的にクリーンアップ ウィザードを実行していただくのが、一番の対策とはなるのですが、もしこの事象陥ってしまった場合には、対処方法として、以下の 3 つがあります。

 

対処 1. WSUS データ ベースのインデックス再構成を実施する

対処 2. Powershell より処理を分割して実行する

対処 3. 繰り返しクリーンアップを実行する

 

対処 1. WSUS データ ベースのインデックス再構成を実施する


以下の記事で紹介しているインデックスの再構築を実施すると、WSUS の処理が効率化されるため、クリーンアップ ウィザードの処理をより効率的に進めることが出来るようになります。インデックスの再構成を定期的に実施していない環境では、まずインデックスの再構成を実施して事象に改善が見られないか確認をします。

WSUS DB インデックスの再構成の手順について
https://blogs.technet.microsoft.com/jpwsus/2014/03/05/wsus-db/

上記の手順を実施しても、まだ事象が改善されない場合には続けて以下の手順を実施します。

 

対処 2. Powershell より処理を分割して実行する


実はクリーンアップ ウィザードの 「不要な更新プログラムと更新プログラムのリビジョン」項目は、内部的には 2 つの処理を同時に実行しています。このため、Powershell から 2 つの処理を分けて実行することで、タイムアウトを回避出来ることがあります。

Windows Server 2012 以降の WSUS では、Powershell で以下の 2 つのコマンドを上から順に実行することで、2 つの処理を同時ではなく、それぞれ実行することが出来ます。

 

・ Windows Server 2012 以降の WSUS の場合

Invoke-WsusServerCleanup -CompressUpdates
Invoke-WsusServerCleanup -CleanupObsoleteUpdates

 

WSUS 3.0 SP2 の環境の場合には、少し行数が多くなってしまいますが、以下の 2 つのスクリプトで Powershell から処理を実行可能です。そのまま Powershell のコンソールに貼り付けて実行していただくことも可能です。

 

・ WSUS 3.0 SP2 の場合 : その 1

[System.Reflection.Assembly]::LoadWithPartialName('microsoft.updateservices.administration')

$wsus=new-object 'Microsoft.UpdateServices.Administration.AdminProxy'
$wsusrv=$wsus.GetUpdateServerInstance()

$cm=$Wsusrv.GetCleanupManager()
$cs=new-object 'Microsoft.UpdateServices.Administration.CleanupScope'

$cs.CompressUpdates = $True

$cm.PerformCleanup($cs)

 

・ WSUS 3.0 SP2 の場合 : その 2

[System.Reflection.Assembly]::LoadWithPartialName('microsoft.updateservices.administration')

$wsus=new-object 'Microsoft.UpdateServices.Administration.AdminProxy'
$wsusrv=$wsus.GetUpdateServerInstance()

$cm=$Wsusrv.GetCleanupManager()
$cs=new-object 'Microsoft.UpdateServices.Administration.CleanupScope'

$cs.CleanupObsoleteUpdates = $True

$cm.PerformCleanup($cs)

 

対処 3. 繰り返しクリーンアップを実行する


さて上記の 2 つの対処を実施して、それでも事象が改善されない場合には、あとは繰り返し実行するしかありません。「不要な更新プログラムと更新プログラムのリビジョン」は、開始した直後にエラーとなるような状況でなけば、途中まで処理は進んでいます。繰り返し何度も対処 2 の Powershell を実行することで、処理を完了させましょう。

一度「不要な更新プログラムと更新プログラムのリビジョン」を完了出来れば、あとは定期的に実行すれば、いちいちこれらの対処をする必要はなくなります。対処が完了したら、タスク スケジューラ等からクリーンアップを自動的に定期実行するようにしておくと、この事象が再発することを未然に防ぐことが出来るので是非検討ください。

 

Windows 10 / Windows Server 2016 の Windows Update 後の自動再起動の制御方法

みなさま、こんにちは。WSUS サポート チームです。

本日は Windows 10 および Windows Server 2016 での Windows Update 後の自動再起動の制御方法について、一般的なシナリオとシナリオに合わせた設定方法を紹介します。Windows Update 後に意図せず再起動されてしまったとのお問い合わせは、弊サポート チームでもよくお問い合わせいただく内容の一つですので、未然に事象発生を防ぐために、是非ご参考としてください。

また、Windows Update 後の自動再起動の制御については、以下の公開情報でも紹介しています。

 

前提事項


  • Windows 10 の既定の状態や、下記のグループ ポリシーを設定している環境では、更新プログラムの自動インストール後に再起動が自動で行われてしまう可能性があります。再起動されるタイミングを管理したい場合には、必ず他の設定と組み合わせて利用してください。
[コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [自動更新を構成する] を ”有効”、オプションにて [4 – 自動ダウンロードしインストール日時を指定] に指定
  • 上記のグループ ポリシーが "無効" に設定されている場合や、その他のオプションが指定されている場合でも、Windows 10 / Windows Server 2016 の環境では、設定画面より [更新プログラムのチェック] にも再起動が自動実行されるよう、スケジュールされてしまいます。手動で Windows Update を実行する場合には注意してください。

Image may be NSFW.
Clik here to view.

  • 下記のグループ ポリシーを設定すると、上記の [更新プログラムのチェック] をユーザーが押せないように出来るため、上記のボタンがクリックされ、再起動が自動的に行われることを防ぐためには、今回ご案内する他のグループ ポリシーと併せて、以下のグループ ポリシーを設定することをご検討ください。
[コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [Windows Update のすべての機能へのアクセスを削除する] を ”有効”

 

よくご要望いただくシナリオ


さてここからが本題です。よく Windows Update 後の自動再起動を抑止したいとのお問い合わせで、ご要望いただくシナリオは下記の 4 種類があります。詳細について紹介していきますので、運用に合わせた設定をすることをご検討ください。

 

  1. ユーザーが利用している限りは自動で再起動したくない
  2. 業務時間内には自動再起動をしたくない
  3. 更新プログラムをインストールした後に直ぐに自動再起動させたい
  4. 更新プログラムのインストールのタイミングと再起動を行うタイミングを別々にしたい

 

シナリオ 1 : ユーザーが利用している限りは自動で再起動したくない


一番よくお問い合わせいただくのが、このシナリオです。ユーザーが利用している状態で再起動をしたくない場合には、以下のグループ ポリシーを 2 つ共に設定いたします。この設定を行うとユーザーがログオンしている限りは、更新プログラムの適用後の自動再起動は実施されないので、意図せず利用中に再起動が発生することを防ぐことができます。

[コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [スケジュールされた自動更新のインストールで、ログオンしているユーザーがいる場合には自動的に再起動しない] を "有効"
-> [自動更新を構成する] を ”有効”、オプションにて [4 – 自動ダウンロードしインストール日時を指定] に指定

なお、[スケジュールされた自動更新のインストールで、ログオンしているユーザーがいる場合には自動的に再起動しない] の設定は、必ず [4 – 自動ダウンロードしインストール日時を指定] と合わせて設定をしないと効果がありませんので、注意が必要です。

 

シナリオ 2 : 業務時間内には自動再起動をしたくない


Windows 10 バージョン 1607 / Windows Server 2016 の環境では、アクティブ時間という設定が導入され、アクティブ時間として指定した時間には、自動再起動が行われないように設定が出来るようになりました。このため、下記のグループ ポリシーでアクティブ時間として業務時間を指定しておけば、業務時間中は再起動が行われないように設定することが出来ます。

[コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [アクティブ時間内の更新プログラムの自動再起動をオフにします] を "有効"、オプションにてアクティブ時間を指定

また、アクティブ時間の設定はグループ ポリシーでなく設定画面の以下の箇所から設定することも出来るので、上記のグループ ポリシーを敢えて設定せず、ユーザーが好きな時間をアクティブ時間として設定させることも可能です。

Image may be NSFW.
Clik here to view.

なお、Windows 10 バージョン 1607 / Windows Server 2016 の環境ではアクティブ時間は最大 12 時間、Windows 10 バージョン 1703 以降の環境ではアクティブ時間を最大 18 時間の範囲で指定可能です。

加えて Windows 10 バージョン 1703 以降の環境であれば、以下のグループ ポリシーでユーザーがアクティブ時間として指定可能な範囲をい制限することが出来ます。

[コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [自動再起動のアクティブ時間範囲を指定する] を "有効"、オプションにて最大範囲を 8 ~ 18 時間の範囲で指定

 

シナリオ 3 : 更新プログラムをインストールした後に直ぐに自動再起動させたい


サーバー OS や更新プログラムの適用を強制したい環境では、この設定が有効です。以下のグループ ポリシーを設定すると、更新プログラムの自動インストールの完了したら [スケジュールされた時刻に常に自動的に再起動する] で指定した時間の経過後に自動で再起動が行われます。このため、夜中の内の更新プログラムのインストールと再起動を完了させておきたいという場合には、この設定で要望を満たすことが出来ます。

[コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [スケジュールされた時刻に常に自動的に再起動する] を "有効"
-> [自動更新を構成する] を ”有効”、オプションにて [4 – 自動ダウンロードしインストール日時を指定] に指定

 

シナリオ 4 : 更新プログラムのインストールのタイミングと再起動を行うタイミングを別々にしたい


サーバー OS でよくお問い合わせいただくのは、このシナリオです。更新プログラムのインストールは自動で行ないたいけども、再起動は計画メンテナンスのタイミングで決まった時刻に再起動したいという要望の場合には、このシナリオに合致します。一見シナリオ 3 と似たように見えますが、シナリオ 3 では更新プログラムのインストール処理完了した後に再起動となるため、例えば「必ず決まった時刻に再起動をする」という要件は、シナリオ 3 の設定では満たすことが出来ません。

このシナリオの場合には、まずは以下のグループ ポリシーを設定します。下記の設定を行うことで、まず更新プログラムのダウンロードまでが自動的に行われるようになります。

[コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [自動更新を構成する] を ”有効”、オプションにて [3 – 自動ダウンロードとインストールを通知] に指定

上記の設定に加えて WUA (Windows Update Agent) API を利用した「ダウンロードが完了した更新プログラムのインストール処理を実行する」スクリプトをタスク スケジューラに設定し、更新プログラムの自動インストールを行うようにすることで、このシナリオの要望を満たすことが出来ます。本設定を行うと、あくまでも自動更新の機能では自動ダウンロードまでが制御対象となるため、インストール後の再起動は自動で行われないようにすることが出来ます。

また、「ダウンロードが完了した更新プログラムのインストール処理を実行する」スクリプトについては、こちらに用意してますので vbs 形式で、是非ご活用ください。

 

Windows 10 / Windows Server 2016 で イベント ID 7043 (UsoSvc) が発生する

みなさま、こんにちは。WSUS サポート チームです。

 

今回は Windows 10 / Windows Server 2016 の環境にて、更新プログラム適用後の再起動処理のタイミングで、UsoSvc (Update Orchestrator Service) に関連する以下のエラーがイベント ログに出力される事象について紹介いたします。

 

< 対象イベント ログ >

ログの名前:         System
ソース:           Service Control Manager
イベント ID:       7043
レベル:           エラー
説明:
Update Orchestrator Service for Windows Update サービスは、プレシャットダウン コントロールを受け取った後に正しくシャットダウンされませんでした。

赤字の箇所が、この事象に合致しているかの重要なポイントとなります。

 

結論から申し上げると上記の記録は、異常を指し示すものではございません。詳細について以下にご案内していきます。

 

事象の詳細


この事象は、更新プログラム適用後の再起動のタイミングでの UsoSvc のサービス停止処理に伴って発生します。

通常 SCM (Service Control Manger) がサービスの停止を要求した後に、停止対象のサービスは自身のサービスの状態を SCM へ一定間隔で通知する必要があります。

しかし、UsoSvc は動作上の問題があり、サービスの停止処理中に一定間隔の状態報告を SCM に対して行わない場合があることが確認出来ております。この結果として SCM はサービスの停止処理が正しく行われていないと判断し、イベント ID 7043 の出力後、UsoSvc が停止してしまいます。

 

対処方法


残念ながら現時点では問題に対する修正が行われておりませんが、このイベントが出力されることによって影響が発生することは想定されず、対処を実施していただく必要はありません。

恐れ入りますが、イベント ログの監視等を行われている場合には、この UsoSvc  に関するイベント ID 7043 を除外していただけますようお願いいたします。

 

 

WSUS メンテナンス ガイド

みなさま、こんにちは。WSUS サポート チームです。

本日は WSUS サーバーのメンテナンス方法について、纏めてご紹介をいたします。

WSUS は月々リリースされる更新プログラムを配信出来るよう、更新プログラムの情報をサーバー上に溜め込む必要があります。しかし、この製品の性質上、日々メンテナンスを実施しないと、データベースや情報が肥大化し、様々な障害や弊害が発生しやすくなってしまいます。

弊サポート部門へいただく様々なお問い合わせも、最終的にはこのいずれかの対処に行き着くことが、ほとんどですので是非 WSUS をこれから導入・構築される方々、また既に運用されている方々は、ご一読ください!

 

WSUS の各種メンテナンス


一般的な WSUS のメンテナンスとして、下記の 3 種類のメンテナンスは更新プログラムのリリースと合わせて、月 1 回程度実行していただくことをオススメしております。各メンテナンスについては、既に以下のブログで、それぞれ紹介していますので、WSUS をご利用いただいている方で、まだ読んだことがない方は一度内容をご覧ください。

 

1. WSUS DB インデックスの再構成の手順について
https://blogs.technet.microsoft.com/jpwsus/2014/03/05/wsus-db/
2.WSUS のクリーンアップ ウィザードについて
https://blogs.technet.microsoft.com/jpwsus/2017/12/05/43/
3.不要な更新プログラムは「拒否済み」に設定しよう!
https://blogs.technet.microsoft.com/jpwsus/2017/12/11/decline-is-yrfrnd/

 

また、これらのメンテナンスはいずれもコマンド ライン等から実行出来るため、タスク スケジューラと組み合わせて自動化することが可能です。今回は自動化の手順とそれに伴う注意事項も紹介しますので、運用の中に取り入れる上で参考としていただけると幸いです。

 

注意事項


以下にメンテナンスを実施いただく上での注意事項をご案内します。メンテナンスの自動化を行う前に、必ずご一読ください。

 

  • 初めてメンテナンスを実施する場合には、各メンテナンスが正常に動作することを一度必ずご確認ください。特に何年も運用しているような環境で、初めてメンテナンスを実施する場合には、処理が長時間 (数十時間 ~) に及ぶ可能性もあるので、覚悟してください。

 

  • 各メンテナンスと WSUS の同期は、なるべく同じ時刻に実行されないようにしてください。いずれのメンテナンスも WSUS の負荷が高くなる可能性があるため、各メンテナンスを同時に実行したり、メンテナンスと同期を同時に実行すると失敗することがあります。

 

  • 「3」のブログで紹介している置き換えが行われた更新プログラムを「拒否済み」に設定するスクリプトを利用して貰えると、新しい更新プログラムにて置き換えられている古い更新プログラムのみを、簡単に「拒否済み」に設定することが可能です。今回ご案内の手順でも、このスクリプトを利用します。
    ただし、最新の更新プログラムを常に配信するような運用をしていない場合 (リリース後 1 ヶ月遅れで配信したり、特定の更新を除外して配信しているような場合) には、配信対処の更新プログラムが「拒否済み」に設定されてしまうこともあるため、注意してください。

 

  • レプリカ構成の WSUS を利用している場合には、「2」のクリーンアップ ウィザードは上位のサーバーから実行する必要があるため、上位のサーバーから順番にメンテナンスが実行されるよう、スケジュールをしてください。

 

  • 階層構成の WSUS の場合でも「1」「2」のメンテナンスについては、上位下位双方の WSUS にて実施してください。なお。レプリカ構成の WSUS の場合には、「3」の「拒否済み」の設定については、上位の WSUS サーバーだけで実施すれば問題ありません。

 

メンテナンスの自動化


それでは各メンテナンスを自動化する方法について、それぞれ紹介していきます。

 

SUSDB のインデックス再構築をタスク スケジューラから自動実行させる

  1. こちらより、インデックスの SUSDB のインデックス再構築を行うスクリプトを入手し、WSUS サーバー上に保存します。(SUSDBMaint.sql 等)
  2. スタート メニューより、タスク スケジューラを立ち上げます。
  3. [基本タスクの作成] を選択し、任意の名前を付けます。
    Image may be NSFW.
    Clik here to view.

  4.  インデックスの再構築を実施するスケジュールを指定します。以下の例では、毎月第一日曜日の AM 2:00 に実行するよう指定しています。
    Image may be NSFW.
    Clik here to view.
  5. [プログラムの開始] を選択して、以下のような指定を行ないます。以下の指定では -i オプションで手順 1 で保存したスクリプトのパスを指定し、-o にてスクリプトの実行ログの出力パスを指定しています。
    - Windows Server 2012 以降の WSUS で WID を利用している場合の指定例
    "C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.exe" -S \\.\pipe\Microsoft##WID\tsql\query -i C:\WSUS\SUSDBMaint.sql -o c:\WSUS\reindexout.txt

    - WSUS 3.0 SP2 で WID を利用している場合の指定例

    "C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.exe" -S \\.\pipe\mssql$microsoft##ssee\sql\query -i C:\WSUS\SUSDBMaint.sql -o c:\WSUS\reindexout.txt

    ※ SQL Server を利用している場合には -S にて SQL Server のインスタンス名を指定します。
    Image may be NSFW.
    Clik here to view.

  6. 以下のような警告が出力されますが [はい] を選択して、そのままタスクの作成を完了させます。
    Image may be NSFW.
    Clik here to view.

  7. 作成したタスクを右クリックして [プロパティ] を選択し、以下の 2 つの設定を行って [OK] をクリックします。
    Image may be NSFW.
    Clik here to view.
  8. 試しに作成したタスクを右クリックして [実行する] を選択して実行してみましょう。ログを確認してエラー等が出力されておらず、最後の方に "Statistics for all tables have been updated" または "全テーブルの統計が更新されました" いなければ、問題なくタスクの登録が出来ています。

 

クリーンアップ ウィザードをタスク スケジューラから自動実行させる

  1. インデックスの再構築の自動化の手順と同様にタスク スケジューラを起動し、基本タスクの作成を行ない、クリーンアップ ウィザードを実行するスケジュールを指定 (上述の手順 2 ~ 4) します。
    ※ インデックスの再構築とはスケジュールが被らないよう、インデックス再構築の実行開始の数時間後や別の日等を指定します。
  2. [プログラムの開始] を選択して、実行したいクリーンアップの項目に合わせて、以下のような指定を行ないます。
    - Windows Server 2012 以降の WSUS で WID を利用しており、全ての項目を実行する場合の指定例
    Powershell -Command "Invoke-WsusServerCleanup -CompressUpdates -CleanupObsoleteUpdates -CleanupObsoleteComputers -CleanupUnneededContentFiles -DeclineExpiredUpdates -DeclineSupersededUpdates" > C:\WSUS\wsusClean.txt

    ※ オプションとクリーンアップの各項目の対応については、こちらのブログの参考情報を参照してください、
    - WSUS 3.0 SP2 の場合の指定例
    WSUS 3.0 SP2 では、Invoke-WsusServerCleanup は利用できないため、こちらのスクリプトを保存して実行します。出力ファイルのパスについては、スクリプト内の「$outFilePath = '.\wsusClean.txt'」の箇所を編集します。

    Powershell -ExecutionPolicy Unrestricted -File "C:\WSUS\WSUS_Clean.ps1"
  3. インデックスの再構築の自動化の手順と同様にタスクの作成を完了 (上述の手順 6 ~ 7) させます。
  4. 試しに作成したタスクを右クリックして [実行する] を選択して実行してみましょう。出力ファイルに以下のようにエラー等が出力されていなければ、正常に登録されています。
    出来ています。
    削除された古い更新プログラム:0
    拒否された期限切れの更新プログラム: 0
    削除された古い更新プログラム:87
    圧縮された更新プログラム:0
    削除された古いコンピューター:0
    解放されたディスク領域:0

 

不要な更新プログラムの「拒否済み」設定をタスク スケジューラから自動実行させる

  1. こちらより、置き換えられた更新プログラムを「拒否済み」に設定するスクリプトを入手し、WSUS サーバー上に保存します。(Decline-SupersededUpdates.ps1 等)
  2. インデックスの再構築の時と同様にタスク スケジューラを起動し、基本タスクの作成を行ない、不要な更新プログラムの「拒否済み」設定を実行するスケジュールを指定 (上述の手順 2 ~ 4) します。
    ※ こちらもインデックスの再構築やクリーンアップ ウィザードとはスケジュールが被らないよう、他のメンテナンスの実行開始の数時間後や別の日等を指定します。
  3. [プログラムの開始] を選択して、以下のようにスクリプトを指定します。本指定については、WSUS 3.0 SP2 でも Windows Server 2012 以降の WSUS 環境でも同様となりますが、利用しているポート番号によって -Port 以降の指定を変更する必要があるので、ご注意ください。WSUS 3.0 SP2 では既定で 80、Windows Server 2012 以降の WSUS 環境は既定で 8530 となります。
    powershell -ExecutionPolicy Unrestricted -Command "C:\WSUS\Decline-SupersededUpdates.ps1 -UpdateServer localhost -Port 8530"
  4. インデックスの再構築の自動化の手順と同様にタスクの作成を完了 (上述の手順 6 ~ 7) させます。
  5. 試しに作成したタスクを右クリックして [実行する] を選択して実行してみましょう。出力ファイル SupersededUpdates.csv や SupersededUpdatesBackup.csv が出力されていれば、正常に登録されています。

 

Viewing all 179 articles
Browse latest View live