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

今回は Windows 10 でログオン時にコマンド プロンプト画面が一瞬表示される事象についてご説明します。

Windows 10 にログオンした際に下記のようにコマンドプロンプトが画面が一瞬表示されたことはございませんでしょうか。この事象は [Schedule Retry Scan] というタスクが動作することにより表示されています。

※ コマンド プロンプト画面が表示されることによる動作影響はございません。
※ 本事象は Windows 10 バージョン 1709 では発生しないことを弊社環境で確認しております。

上記画面が表示される事象について下記の順に詳細をご説明します。

1. 発生原因について
2. 発生頻度について
3. 対処方法について

1. 発生原因について

前述したとおり [Schedule Retry Scan] というタスクが実行されることにより発生します。

ただし、 [Schedule Retry Scan] というタスクについては既定で存在するタスクではなく、自動更新による検出処理を実行している [Schedule Scan] というタスクがネットワーク等の問題により失敗した場合に登録されます。

[Microsoft] - [Windows] - [UpdateOrchestrator]

2. 発生頻度について

[Schedule Retry Scan] タスクはログオンのタイミングで実行されるため、この事象もログオンのタイミングで発生します。

3. 対処方法について

対処方法としては、ご状況に合わせて以下の対策を行います。

3-1) [Schedule Scan] が失敗しないように対応する

既定で 22 時間間隔で実行される自動更新の検出処理が失敗することにより本事象が発生しますので、Winhttp プロキシ設定等を適切に構成し、失敗する原因を取り除きます。

Winhttp プロキシ設定につきましては、このブログを参照してください。

3-2) 自動更新を止める

本事象が発生するとの報告では、WSUS や Windows Update に接続できないネットワーク構成となっており、本来 Windows Update を実行する想定ではない環境にて多く報告されております。

そのような場合には、バックグランドで動作する自動更新を無効化することで [Schedule Scan] による検出処理を実行しないように対応することも可能です。

・[コンピューターの構成] -> [管理用テンプレート] -> [Windows コンポーネント] -> [Windows Update]
-> [自動更新を構成する] を "無効" に設定します。

なお、既に [Schedule Retry Scan] タスクが一旦登録されてしまった環境では、上記の設定を行っても [Schedule Retry Scan] タスクを削除しないと [Schedule Retry Scan]  タスクが動作し、事象が発生してしまうためご注意ください。

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

Windows Server 2016 の環境にて、更新プログラム削除時に、Windows Update Client に関する以下のエラーがイベント ログに出力される事象について紹介いたします。

< 対象イベント ログ >

ソース: ESENT
イベントID: 640
レベル: 警告
ユーザー: N/A
メッセージ：
wuaueng.dll (960) SUS20ClientDataStore: フラッシュ マップ ファイル "C:\Windows\SoftwareDistribution\DataStore\DataStore.jfm" でのヘッダー ページの検証中にエラー -1919 が発生しました。フラッシュ マップ ファイルは無効になります。
詳細については、[SignDbHdrFromDb:Create time:00/00/1900 00:00:00.000 Rand:0 Computer:] [SignFmHdrFromDb:Create time:00/00/1900 00:00:00.000 Rand:0 Computer:] [SignDbHdrFromFm:Create time:03/16/2018 14:57:54.165 Rand:2602757889 Computer:] [SignFmHdrFromFm:Create time:03/16/2018 14:57:54.212 Rand:1467011330 Computer:] を参照してください

ソース: ESENT
イベントID: 636
レベル: 警告
ユーザー: N/A
メッセージ：
wuaueng.dll (960) SUS20ClientDataStore: フラッシュ マップ ファイル "C:\Windows\SoftwareDistribution\DataStore\DataStore.jfm" は削除されます。理由: ReadHdrFailed。

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

事象の詳細

Windows Update Client が起動する際には、常に以下のデータベースのバージョンを確認いたします。

C:\Windows\SoftwareDistribution\DataStore\DataStore.edb

その際に、データベースのバージョンと、想定されるバージョンが異なる場合に、必ずデータベースの再作成を行います。再作成の結果として、今回のエラーが発生いたします。
更新プログラムのアンインストール時等のシステム変更に伴い、Windows Update Client とデータベースのバージョンに差異が発生することを考慮して実装されている状況ではないため、当該警告メッセージが出力される状況となりますが、頻発しない場合には問題ないとご判断ください。

対処方法

残念ながら現時点では問題に対する修正が行われておりませんが、このイベントが出力されることによって影響が発生することは想定されず、対処を実施していただく必要はありません。
恐れ入りますが、イベント ログの監視等を行われている場合には、当該警告イベントを除外していただけますようお願いいたします。

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

本日は Windows Server 2016 の WSUS をご利用の場合に Microsoft Update カタログからの更新プログラムのインポート時に、以下のエラーが発生する事象についてご紹介をいたします。

※ 日本語では「この更新プログラムは Windows Server Update Services にインポートできません (理由: お使いのバージョンの WSUS と互換性がありません)」と表示されます。

このエラーは、Microsoft Update カタログ サイトの問題に起因して発生するものであり、今後修正を予定しております。お手数お掛けいたしますが、現時点では以下の対処方法にてエラーの回避が可能ですので、エラーが発生した場合には以下の手順の実施お願いいたします。

また、本問題については進展があり次第、このブログにて情報をお伝えして参ります。なお、以下の弊社開発部門のブログでも本問題を紹介しております。

対処方法

1. WSUS 管理コンソールを開き、左ペインにて WSUS サーバー名を選択して右クリックし「更新のインポート...」をクリックします。
2. Microsoft Update カタログ サイトが開きます。※ 初回アクセス時のみ、Microsoft Update カタログ アドオンのインストールが必要です。
3. カタログの互換性の問題を回避するため、URL の最後の部分を以下の通り「Protocol=」以降の指定を変更し、 URL をクリックしてカタログサイトを開きなおします。
   << 変更前 >>

   http://catalog.update.microsoft.com/v7/site/< 中略 >&Protocol=1.20

   << 変更後 >>

   http://catalog.update.microsoft.com/v7/site/< 中略 >&Protocol=1.8

4. インポートを行いたい更新プログラムのインポートを実施し、正常にインポートを出来ることを確認します。

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

今回は WSUS で配信出来る更新プログラムの各分類について紹介します。

WSUS では以下の分類の内、どれを配信するか選択することが出来ます。分類については、セキュリティの修正及び重要な修正を含めるために、「セキュリティ問題の修正プログラム」と「重要な更新」を選択することが一般的ですが、パッと見てどの分類にどんな更新プログラムが含まれているか、なかなかイメージが沸かない方も多いかと思います。このブログでは詳細を紹介するので、是非参考としてください！

また、WSUS では好きな分類を好きなように選択して配信することが出来ますが、安定した運用するために、ポイントがあります。まずはそのポイントについて紹介いたします。

ポイント : 特別な利用がない限り ”ドライバ” の分類は絶対に選択しない

“ドライバ” の分類は、リリースされている更新プログラムの数が群を抜いて多く、選択すると数万件の更新プログラムが同期され、WSUS のパフォーマンスに大きな影響を与えてしまいます。このため、特別な利用がない限り、”ドライバ” の分類は絶対に選択しないことをお勧めします。

 そもそも “ドライバ” の更新は、各ハードウェア ベンダーの申請に基づいて公開されるため、WSUS で分類を選択していても、各ベンダーのドライバが常に最新のバージョンに更新されるとは限りません。

 WSUS から配信が必要なドライバがある場合には、下記ブログにて紹介している「A. 特定の更新プログラムのみ WSUS へインポートしたい」にて個別にインポートし、配信を行ないましょう。

Feature Packs

< 概要の説明 >

新しく公開された機能で、製品の次期リリースに含まれるような内容となります。

< 対象の更新プログラムの例 >

- Microsoft Silverlight (KB3126036)

- Windows 7 用 Microsoft .NET Framework 4.5.2 (KB2901983)

Service Packs

< 概要の説明 >

これまでに作成されたすべてのホットフィックス、セキュリティ問題の修正プログラム、重要な更新、および更新をまとめたものと、製品の公開以後に内部で発見された不具合に対する修正が含まれます。

Service Pack には、一部のお客様から要望された設計上の変更や機能が含まれることもあります。

< 対象の更新プログラムの例 >

- Windows 7 Service Pack 1 (KB976932)

- Microsoft Office 2013 (KB2850036)  Service Pack 1

- Microsoft SQL Server 2012 Service Pack 3

Upgrades

< 概要の説明 >

Windows 10 の機能更新プログラム (Feature Update) となります。

本分類の更新プログラムを配信するためには、WSUS で事前に準備が必要となります。詳細については、下記ブログにて紹介しております。

<対象の更新プログラムの例>

- Windows 10 Pro N、バージョン1511、10586にアップグレード – en-us,Volume

セキュリティ問題の修正プログラム

< 概要の説明 >

セキュリティ上の脆弱性を修正するために、特定の製品に対して公開される修正プログラムです。「セキュリティのみの品質更新プログラム」や「セキュリティ マンスリー品質ロールアップ」も、この分類でリリースされております。

< 対象の更新プログラムの例 >

- Windows 8.1 用セキュリティ更新プログラム (KB3121212) / 特権の昇格に対処する Windows カーネル用のセキュリティ更新プログラム

- Windows 7 用セキュリティ更新プログラム (KB3121918) / リモートでのコード実行に対処する Microsoft Windows 用のセキュリティ更新プログラム

- Microsoft Silverlight のセキュリティ更新プログラム (KB3126036) / リモートでのコード実行に対処する Silverlight 用のセキュリティ更新プログラム

ツール

< 概要の説明 >

あるタスク、または一連のタスクの実現を支援する、ユーティリティまたは機能です。

< 対象の更新プログラムの例 >

- ネットワークの診断ツール (KB914440) 

ドライバ

< 概要の説明 >

ドライバーの更新となります。各ハードウェアベンダーにてWSUS に公開した更新が公開されております。

< 対象の更新プログラムの例 >

- HP driver update for HP LaserJet M1530 MFP Series PCL 6

ドライバーセット

< 概要の説明 >

特定のモデルのコンピューターのハードウェアをサポートするドライバー郡となります。

Windows Server 2016 以降の WSUS でのみ、本分類は表示・選択できます。

更新

< 概要の説明 >

重要性が低く、セキュリティに関連しない不具合を修正するために、特定のプログラムに対して公開される修正プログラムです。「マンスリー品質ロールアップのプレビュー」もこの分類にてリリースされております。

< 対象の更新プログラムの例 >

- Windows 7 用更新プログラム (KB2977759) / Windows 7 の RTM 版の互換性に関する更新プログラム

- Windows 8.1 用更新プログラム (KB2976978) / Windows 8.1 および Windows 8 の互換性更新プログラム

- Windows Server 2012 R2 用更新プログラム (KB3112148)  / 2015 年 12 月付、Windows オペレーティング システム用の累積的なタイム ゾーン更新プログラム

修正プログラム集

< 概要の説明 >

ホットフィックス、セキュリティ問題の修正プログラム、重要な更新、および更新を 1 つのパッケージにまとめ、展開したものです。修正プログラム集は通常、“セキュリティ”などの特定の分野、または “インターネット インフォメーション サービス (IIS)” などの製品のコンポーネントに対して用意されます。

< 対象の更新プログラムの例 >

- 悪意のあるソフトウェアの削除ツール - 2016 年 1 月 (KB890830)

- Windows 8.1 用更新プログラム (KB3025417) / Windows 8.1 で Windows 8 の Windows Defender のマルウェア対策用プラットフォームの更新

- Microsoft System Center 2012 R2 - Operations Manager Agent の更新プログラムのロールアップ 8 (KB3096382)

重要な更新

< 概要の説明 >

重要性が高く、セキュリティに関連しない不具合を修正するために、特定の問題に対して公開される修正プログラムです。

< 対象の更新プログラムの例 >

- Windows 8.1 用更新プログラム (KB3112336) / Windows 8.1 と Windows Server 2012 R2 の更新

- Windows 7 用更新プログラム (KB3112343) / Windows 7 および Windows Server 2008 R2 の Windows Update Agent

- Microsoft Office 2013 (KB3114498) の更新プログラム / 2016 年 1 月 12 日 Office 2013 の更新

定義更新プログラム

< 概要の説明 >

製品の定義データベースへの追加を含む、広範かつ頻繁にリリースされるソフトウェア更新プログラムです。

定義データベースは、悪意のあるコード、フィッシングWebサイト、ジャンク電子メールなど、特定の属性を含むオブジェクトを検出するために、頻繁に使用されます。

Windows Defender やOfficeをお使いの場合に設定することが多いものとなります。

< 対象の更新プログラムの例 >

- Microsoft Security Essentials の定義の更新 - KB2310138 (定義 1.213.3177.0)

- Microsoft Endpoint Protection の定義の更新 - KB2461484 (定義 1.213.3168.0)

- Microsoft Office 2010 (KB3114563) の定義の更新

参考情報 : WSUS 上の各分類と Windows Update 上の分類について

さて、分類関連の設定でよくご要望いただく内容として「Windows Update で配信されている内容と、全く同一の更新プログラムを WSUS から配りたい！」というお問い合わせをいただきます。結論から言ってしまうと、WSUS 向けに公開されている更新プログラムと、Windows Update 向けに公開されている更新プログラムは完全に一致するわけではないので、全く同一の状態とすることは出来ません。

これは WSUS はエンタープライズ / 企業向けの用途、Windows Update はコンシューマー / 一般ユーザー向けの用途を想定しているためです。(例えば Windows 10 への無償アップグレードの通知用の更新プログラムは WSUS 環境に着信しないように考慮が行われておりました。)

ただし、可能な限り、配信される更新プログラムを近づけることは可能です。Windows Update では、上述の WSUS の分類のように細かく分類されておらず、

下記のように「重要な更新プログラム」と「オプション / 推奨される更新プログラム」に分類されています。

- 重要な更新プログラム : 「重要な更新」、「セキュリティ問題の修正プログラム」、「定義更新プログラム」、「修正プログラム集」、「Service Packs」

- オプション / 推奨される更新プログラム : 「ツール」、「Feature Packs」、「更新」

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

今回は Windows Update に失敗した場合に、一般的にご確認いただきたいこと等についてご紹介します。

Windows Update に失敗した場合に、一般的にご確認いただきたい対処方法

「先月まで上手く適用出来ていたのに、なぜか今月は上手くできない！」といった場合等には、以下ブログの手順をご確認ください。ブログの中でも紹介している通り、まず実施いただきたい対処方法となります。

また、以下の公開情報では Windows Update に失敗した場合に実施いただきたい内容を、ウォークスルー ガイドで紹介しています。上記のブログで紹介している手順でも解消しない場合には、ウォークスルー ガイドに沿って対処をお試しください。

Windows Update になぜ失敗したのかを調査したい

「対処方法を色々と実行するのではなく、なぜ問題が発生したのか知りたい」という場合や「上記の対処方法は実施出来ないから、その他の対処方法を調査したい」という場合等は、ログから調査等を行う必要があります。

ログの調査の仕方については、以下のブログや公開情報にて紹介しているのでご参考としてください。もちろん弊サポート部門へお問い合わせいただくことも手法の 1 つとなります。

また、Windows 10 でのアップグレードに失敗する場合の調査の手法については以下の公開情報にて紹介しております。

しかし、多くの端末の管理を行われている場合には、Windows Update 失敗している端末に対して 1 台 1 台調査を行うと非常に多くのコストが掛かってしまいます。共通したエラーであれば 1 台の端末の調査で調査は完了しますが、最悪の場合、端末毎にエラーの状況が異なり、失敗しているそれぞれの端末で調査が必要となる可能性があります。そのため調査を行う前に、調査を進める価値があるのかも含め、慎重に検討をすすめる必要があります。

例えば、以下のような場合には、迷わず調査を行う必要があるものと考えられるでしょう。

• 共通したエラー コードが複数の環境で継続して発生している
• 事象が発生している環境が、ビジネス上重要なものであり対処が実施しづらい環境である
  (役員が利用している端末、業務上重要なサーバー上で問題が発生している等)

逆に上記のようなケースに当てはまらない場合には、まずは一般的にご確認いただきたい対処方法を、まずはお試しいただき、それでも解消しない場合には調査を進めるという運用も一つの手法となります。

また、よくお問い合わせいただく問題や対処方法については、本ブログでも随時紹介してまいりますため、是非ご参考としてください！

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

今回は Windows Update を実行する際のプロキシ設定について、2 回に渡ってご案内をいたします。第 1 回は「考え方篇」、第 2 回は「設定篇」となります。

プロキシの設定が正しく行われていないと、Windows Update が上手くいく環境もあれば、失敗する環境もある等、複雑な状況に陥りがちです。このような場合には、「なぜ上手くいく環境と失敗する環境があるのか？」「バージョン毎に微妙にエラーが異なるのはなぜか？」といった目の前に起きている事象に焦点を当てるよりも、まずは「そもそも正しくプロキシが参照出来るよう設定されているか？」といった観点で確認を進めていく必要があります。

クライアントの導入時に、ネットワーク環境に合わせて適切にプロキシ設定が行われていれば、特に改めて考慮する必要はないのですが、本記事では改めて順を追って説明していきます。

Windows Update するためにプロキシ設定は必要か？

これはよくお問い合わせいただく質問ですが、ご利用のネットワーク構成や運用に合わせて設定を考慮していただく必要があるため、弊社から一概に申し上げられる情報はありません。

「プロキシ設定が必要か判らない！」という場合は、まず自社内でネットワークの担当等に、Windows Update の通信がプロキシ サーバーを経由する必要があるのか確認をしてみましょう。

例えば、以下のようにクライアント - WSUS サーバー間の通信で、プロキシ サーバーを経由する必要がないネットワーク構成の場合には、WSUS サーバーに対する Windows Update を成功させるためにプロキシの設定をする必要はありません。

[ 例 1 ]

対して例えば以下のようなネットワーク構成の場合には、WSUS サーバーへの接続にプロキシ サーバーを経由する必要があるため、Windows Update を成功させるためには、プロキシ設定が必要となります。

[例 2]

ただし、例えば例 1 の構成でも、WSUS サーバー以外への通信は、プロキシ サーバーを経由させたい場合には、クライアントへプロキシの設定を行った上で WSUS サーバーへの通信はプロキシを経由しないように、バイパスの指定に WSUS サーバーの URL を加える必要があります。

このように、プロキシ設定は Windows Update の観点でだけでなく、ネットワーク環境に合わせて考慮が必要となります。

さて以上を踏まえて、ご利用の環境でプロキシを経由する通信が必要かどうか確認がとれたら、今度は具体的な設定方法について「設定篇」で紹介していますので、こちらをご参考としてください。

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

今回は第 1 回の「考え方篇」に引き続き、Windows Update 実行時のプロキシ設定の具体的な手法について、オススメの設定と注意点を紹介していきます。「Windows Update を実行するときにプロキシ設定って必要なの？」という方は、まずは「考え方篇」をご参照ください。

プロキシを利用する環境でのオススメの設定

プロキシを利用する環境の場合には、Windows Update の実行時にプロキシ設定が読み込まれるように設定を行っていただく必要があります。オススメの設定としては、以下の 2 種類があるため紹介をします。是非以下のいずれかの設定について、ご検討をください。

A. WPAD を利用した設定方法

WPAD (Web Proxy Auto-Discovery) はクライアントにプロキシの設定を自動配布するための方法として開発された技術であり、WPAD を利用すると DHCP サーバーもしくは DNS サーバーからプロキシの設定をクライアントに対して自動的に配布することが可能です。

Windows Update による通信でも WPAD は参照されるため、WPAD を利用することで各クライアントにて個別にプロキシの設定を行うことなく、プロキシ経由で通信を行うようすることが可能です。

WPAD の設定方法の詳細については、以下ブログで紹介しているため、ご参考としてください。

また、特にクライアント端末を外に持ち出すような環境では、静的にプロキシ設定をクライアントにしてしまうと、外部のネットワークに接続したタイミングで、意図せずプロキシ設定が読み込まれてしまう可能性があるため、WPAD の利用を是非ご検討ください。

B. IE および WinHTTP の両方に静的にプロキシ設定を行う方法

Windows Update の通信で確実にプロキシ設定を読み込ませるためには、IE (Internet Explorer) および WinHTTP のプロキシ設定の両方を実施していただく必要があります。このため静的にプロキシ設定を行う場合には IE のプロキシ設定と WinHTTP のプロキシ設定を両方共に実施していただくことをオススメしております。

IE のプロキシ設定については、以下ブログにて紹介しているため、ご参考としてください。静的にプロキシ サーバーのアドレス等を指定する場合には「2) プロキシ サーバー」の箇所の設定を行います。

また、WinHTTP のプロキシ設定については、以下のコマンドを管理者権限で実行することで設定が可能です。

<< WinHTTP のプロキシ設定をする場合 >>

netsh winttp set proxy proxy-server =<プロキシ サーバー> bypass-list=<バイパス リスト>

<< 上記コマンドの実行例 >>

netsh winhttp set proxy proxy-server="myProxyServer:8080" bypass-list="<local>;*.microsoft.com;*.foo.ne"

なお、以下のコマンドを実行することで IE のプロキシ設定を、そのまま WinHTTP のプロキシ設定へ反映することが可能です。

<< IE のプロキシ設定を WinHTTP のプロキシ設定へインポートする場合 >>

netsh winhttp import proxy source=ie

加えて以下のコマンドで現在の WinHTTP のプロキシ設定の確認やリセットが可能です。

<< 現在の WinHTTP のプロキシ設定を参照する場合 >>

netsh winhttp show proxy

<< WinHTTP のプロキシ設定をリセットする場合 >>

netsh winhttp reset proxy

プロキシを利用する上での注意点

プロキシ サーバーを利用している環境において、よく失敗するポイントや注意点について紹介をします。

静的にプロキシ設定を行う場合

上述の通り、静的にプロキシ設定を行う場合には、IE および WinHTTP のプロキシ設定を両方共にしていただくことをオススメしております。

Windows Update の通信では、どちらのプロキシ設定も参照される可能性があり、細かい使い分けについて以下のブログにて紹介をしております。

IE のプロキシ設定はユーザー単位で設定が保持され、WinHTTP のプロキシ設定は端末全体での設定となるため、基本的な考え方としてはユーザーが介する動作では、ユーザーの IE のプロキシ設定が参照され、システムがバックグラウンドで実行される通信については、WinHTTP のプロキシ設定が参照されます。

しかしながら、Windows Update による通信は、自動更新等のユーザーが意図しないところでバックグラウンドでの通信が発生することが多くあるため、確実に Windows Update の通信を成功させるためには、両方共に設定していただくことをオススメしております。

認証が必要なプロキシをご利用の場合

以下の公開情報でも紹介している通り、認証が必要なプロキシを介して Windows Update を実行すると、Windows Update の動作が不安定になることがあります。認証が必要なプロキシを利用している場合には、接続先の WSUS サーバーもしくは Windows Update / Microsoft Update サイトへの接続ついては、認証が不要なよう除外してください。

--- 該当箇所抜粋 ---

Windows Update または Microsoft Update の使用中に、以下のいずれかまたは複数の問題が発生する場合があります。

(中略)

統合プロキシ認証 (NTLM 認証) を使用して認証を行う Web プロキシ サーバーを経由して Windows Update サイトまたは Microsoft Update サイトに接続すると、これらの Web サイトが表示されないことがあります。

--- 該当箇所抜粋 ---

インターネット上の Windows Update / Microsoft Update サイトに対して Windows Update をする場合

インターネット上の Windows Update / Microsoft Update サイトに対して Windows Update をする場合には、以下のブログにて紹介している URL への通信が必要となります。

プロキシ サーバー等で接続先の URL によってブロック等を実行している場合には、上記のブログにて紹介している URL に対する通信を許可する必要があるので、ご注意ください。また、上述の通り、認証が必要なプロキシを利用している場合には、ブログ内で紹介している URL について認証が不要なようにしてください。

全 2 回に渡る投稿いかがでしたでしょうか。プロキシ設定が環境に合わせて正しく構成されていないと、ネットワーク系のエラー (0x80240030 / 0x80072efe / 0x80244022 / 0x80072efd / 0x80072ee2 / 0x80072ee7 / 0x8024402c 等) が発生したり、異常に Windows Update に時間を要したり、様々な事象が発生します。

プロキシ設定を正しく見直すことで、こういった問題の発生を未然に防ぐことが可能なので、是非ご参考としていただければ幸いです。

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

今回は Windows Server 2016 で以下のような Windows Error Reporting のメッセージが出力される事象について紹介します。

ログの名前: Application
ソース: Windows Error Reporting
日付: 2018/06/08 10:58:53
イベント ID: 1001
タスクのカテゴリ: なし
レベル: 情報
キーワード: クラシック
ユーザー: N/A
コンピューター: test
説明:
障害バケット 、種類 0
イベント名: WindowsUpdateFailure3
応答: 使用不可
Cab ID: 0

問題の署名:
P1: 10.0.14393.1914
P2: 8024402c
P3: 00000000-0000-0000-0000-000000000000
P4: Scan
P5: 0
P6: 0
P7: 8024500b
P8: TrustedInstaller FOD
P9: {9482F4B4-E343-43B6-B170-9A65BC822C77}
P10: 0

結論から言ってしまうと、情報レベルで出力される通り、特に実影響がなければ無視していただいても問題ありません。また、このイベントが出力されたからといって、Windows Update が失敗しているとも限りません。

このイベントが何の処理なのか特定するポイントは、上記の赤太字の箇所となります。運用上必要な処理が失敗している場合には、もちろんエラー コードから、個別に対応の検討が必要となります。

しかし、運用上もし不要な処理であれば、処理を停止してしまうことも可能ですので、今回はこのイベントの赤太字の箇所が、何の処理を示すのか紹介してまいります。

UpdatesOrchestartor / Windows Update の処理

上述の箇所に、UpdateOrchestartor と表示される場合には Windows Update の処理に失敗したことを示します。

もし、そもそも Windows Update が出来ないような環境の場合には、以下ブログにて紹介している方法で Windows Update の自動実行および、このイベントが出力されることを抑止出来ます。

TrustedInstaller FOD / 言語パックの情報の取得処理

過去の事例より、TrustedInstaller FOD と表示される場合には、LanguageFeaturesOnDemand というユーザーの言語に一致する言語パックの情報をバックグランドで取得するタスクが実行され、この処理が失敗した場合に記録されることが判っております。

 このタスクは、以下のパスに存在します。

このタスクは、ユーザーの言語に一致する言語パックの情報をバックグランドで取得するタスクであるため、言語パックなどの追加や変更を行うことがない環境であれば、停止していただいても影響はありません。

タスクを無効化する場合には、以下のコマンドを管理者権限で実行します。

SCHTASKS /Change /TN "Microsoft\Windows\LanguageComponentsInstaller\Installation" /DISABLE
SCHTASKS /Change /TN "Microsoft\Windows\LanguageComponentsInstaller\Uninstallation" /DISABLE

Device Driver Retrieval Client / ドライバーの更新処理

Device Driver Retrieval Client と表示されている場合には、ドライバーの取得処理です。

特にドライバーの取得や更新をする必要がない場合には、以下のグループ ポリシーを設定することで無効化が可能です。

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

CompatTelRunner.exe / アプリケーションの互換性に関するテレメトリ (統計情報) の収集する処理

CompatTelRunner.exe はタスク スケジューラーのタスクより定期的に起動して、アプリケーションの互換性に関するテレメトリ (統計情報) の収集を行うプロセスとなります。

CompatTelRunner.exe の動作を止める方法として、以下のパスに存在するタスク Microsoft Compatibility Appraiser と ProgramDataUpdater の
無効化をする方法がございます。

また、以下のコマンドを管理者権限で実行いただくことでも上記タスクを無効化することが可能です。

SCHTASKS /Change /TN "\Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser" /DISABLE 
SCHTASKS /Change /TN "\Microsoft\Windows\Application Experience\ProgramDataUpdater" /DISABLE

Windows Defender / Windows Defender による定義ファイルの更新処理

Windows Defender は、その名の通り Windows Defender による定義ファイルの更新処理を示します。

もし、サードパーティ製のアンチウイルス ソフトを利用していたり、Windows Defender の利用の必要がない場合には、以下のグループ ポリシーを設定し、Windows Defender を無効にすることで停止が可能です。

[コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [Endpoint Protection] –
[Endpoint Protection を無効にする] を "有効"

補足 : 各処理を停止した場合に、本イベントの出力を停止する方法について

上記の各処理を停止しても、Windows Error Reporting のキューにファイルが溜まっていると、過去に発生したイベントがイベント ログ上に出力され続けてしまいます。キューのファイルについては、以下のフォルダに保存されているため、手動で削除していただくことによって、過去に溜まったイベントを一掃し、イベントの出力を停止することが可能です。

イベントが気になる方は合わせて以下のフォルダ配下のファイル削除をご実施ください。

対象フォルダ : C:\ProgramData\Microsoft\Windows\WER\ReportQueue\

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

今回は「配信したい更新プログラムが WSUS 上に同期されてこない！」という場合に、実施すべき対応や一般的に考えられる要因について紹介をしてまいります。

対応方法

まずは WSUS 上に本当に更新プログラムが存在しないか、念のため検索して確認を行います。

WSUS 管理コンソール上の以下の箇所より、同期されている更新プログラムの検索が可能ですので、KB 番号やタイトル等から対象の更新プログラムが同期されていないか確認を行います。

もし検索結果に対象の更新プログラムが存在しない場合には、個別に Microsoft Update カタログから対象の更新プログラムをインポートする方法がオススメです。インポートの手順については、以下のブログにて紹介しているので、こちらをご参考にしてください。

考えられる要因

ではなぜこのような事が発生してしまうのでしょうか。よくあるパターンとして以下のような要因が考えられます。

• 「製品と分類」の設定にて、対象の更新プログラムの製品や分類が選択されていない
• 対象の更新プログラムが WSUS へ公開されていない
• 弊社サイトと WSUS の同期に失敗している

「製品と分類」の設定にて、対象の更新プログラムの製品や分類が選択されていない

対象の更新プログラムが、リリースされている製品や分類にチェックが入っていない場合には、WSUS 上に対象の更新プログラムは同期されてきません。対象の更新プログラムの製品や分類については、Microsoft Update カタログから確認が出来ます。

例えば、Microsoft Update カタログ上で検索して、以下のように表示される更新プログラムは、製品は「Windows 10 Anniversary Update and Later Servicing Drivers」、分類は「ドライバ」としてリリースされています。このため、以下の更新プログラムについてはオプションの「製品と分類」にて、この両方にチェックが入っていないと同期されてきません。

「製品と分類」の設定を変更し、今回必要な製品や分類にチェックを入れてしまう方法も対処の 1 つではあるのですが、必要な更新プログラム以外も同期されて来てしまうため、対処方法としてはあまりオススメできません。上述の通り、カタログからインポートする方法であれば、必要な更新プログラムだけを同期出来るため、こちらについて実施をご検討ください。

対象の更新プログラムが WSUS へ公開されていない

更新プログラムの中には、そもそも WSUS で自動的に承認・配信されないように、敢えて更新プログラムの開発したチームが WSUS へ直接公開していないものもあります。

こういった更新プログラムでも、Microsoft Update カタログ上に存在する更新プログラムであれば、インポートし WSUS から配信することが可能なので、上述の対応方法を実施いただけます。

弊社サイトと WSUS の同期に失敗している

弊社サイトと WSUS の同期に失敗している場合には、新しい更新プログラムについて WSUS 上に着信出来ません。

なぜ失敗しているかは個別にトラブル シューティングが必要ですが、WSUS 上でいつ同期が行われたか、また同期の結果については管理コンソール上の以下の箇所より確認が可能です。

みなさま、こんにちは。

日本マイクロソフト System Center Configuration Manager サポートの金です。

本日は、System Center Configuration Manager Current Branch (以下、SCCM CB) にて、Active Directory の組織単位 (以下、OU) に基づいて、デバイス コレクションを作成する方法をご紹介させていただきます。

前提条件

AD の OU に基づくコレクションの作成の際には、事前に、Active Directory システムの探索が実施されている必要があります。

SCCM の探索方法から、"Active Directory システムの探索" が正しく設定され、有効になっていることを確認してください。

手順

本手順では、以下の OU をサンプルとしておりますので、お客様の環境に応じて、設定内容を変更していただきますようお願いいたします。

contoso.local/TestClient/TestOU

1. SCCM プライマリ サイト サーバーにサインインし、[Configuration Manager コンソール] を開きます。

2. [資産とコンプライアンス] - [概要] - [デバイス コレクション] を右クリックし、[デバイス コレクションの作成] をクリックします。

3. [デバイス コレクションの作成ウィザード] が表示されますので、[全般] 画面で、"名前" に任意の名前を入力し、"限定コレクション" に、[すべてのシステム] を指定後、[次へ] をクリックします。

4. [メンバーシップの規則] で、[規則の追加] - [クエリ規則] を選択します。

5. [クエリ規則のプロパティ] 画面が表示されますので、[クエリ ステートメントの編集] をクリックします。

6. [クエリ ステートメントのプロパティ] 画面が表示されますので、[条件] タブを開きます。

7. [条件プロパティ] 画面で、"条件の種類" が、[単純な値] であることを確認し、[選択] をクリックします。

8. [属性の選択] の画面が表示されますので、以下のとおり選択し、[OK] をクリックします。
- 属性クラス : システム リソース
- 属性 : システム OU 名

9. [条件プロパティ] に戻りますので、"演算子" と "値" を、以下のように設定し、[OK] をクリックします。
- 演算子 : が次と類似
- 値(例) : contoso.local/TestClient/TestOU
値につきましては、お客様の環境に合わせて変更してください。
"ドメイン名/OU名(親)/OU名(子)" の形式となります。

10. [クエリ ステートメントのプロパティ] 画面に戻りますので、[OK] をクリックします。

11. [クエリ条件のプロパティ] 画面に戻りますので、[OK] をクリックします。

12. [デバイス コレクションの作成ウィザード] に戻りますので、[次へ] をクリックします。

13. [概要] の画面で、[次へ] をクリックします。

14. [完了] の画面で、[閉じる] をクリックします。

15. [Configuration Manager コンソール] - [資産とコンプライアンス] - [概要] - [デバイス コレクション] の画面にて、上記で作成したデバイス コレクションが表示されていることを確認し、アイコンに、砂時計のマークがなくなるまで待機します。

16. アイコンに、砂時計のマークがなくなりましたら、コレクションをダブルクリックし、指定した OU に所属しているデバイスが該当コレクションに入っていることを確認します。

以上となります。

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

今回は、Windows 10 の Windows Update 設定画面にある [更新プログラムのチェック] ボタンの無効化についてご紹介いたします。

Windows 10 において、手動で更新プログラムを取得したい場合、[設定] -> [更新とセキュリティ] -> [Windows Update] 画面を開き、[更新プログラムのチェック] ボタンをクリックすることで、即座に WSUS や Windows Update から更新プログラムを取得することができますが、社内の規定で「ユーザーが手動で更新プログラムの取得を行う操作を禁止したい」という運用をされたいというご要望もあるかと思います。

その場合は、次のグループ ポリシーを有効にすることで、[更新プログラムのチェック] ボタンをグレーアウトさせて、ボタンを無効化することができます。

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

(対応するレジストリ値)
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
SetDisableUXWUAccess (0 : 無効、1 : 有効)

また、ボタンがクリックできるように元の状態に戻す場合は当該ポリシーを「無効」にする必要がありますが、誠に恐縮ながら「無効」にしてもグレーアウトのまま反映されないという既知の不具合がございます。

この不具合につきましては、既に修正した更新プログラムがリリースされており、次のバージョンであれば「無効」にすることで、再びクリックできるようになります。

・Windows 10 1709 + KB4343893 以降の更新プログラム適用済み (16299.637～)

・Windows 10 1803 + KB4340917 以降の更新プログラム適用済み (17134.191～)

・Windows 10 1809

Windows 10 1607, 1703 など修正されていないバージョンの場合は、お手数をおかけいたしますが、当該グループ ポリシーを未構成にして、SetDisableUXWUAccess レジストリ値が削除されることで、ボタンがクリックできるようになります。

ご不便をおかけいたしますが、何卒ご理解賜りますようお願い申し上げます。

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

2018 年 9 月に WSUS と弊社 Microsoft Update サイト間において、一時的に同期が失敗する事象が発生しておりましたので、本記事にてご報告いたします。

本事象については、弊社 Microsoft Update サイトの更新に伴う問題があったことに起因しておりました。そのため、事象発生直後より、開発部門にて調査、対応を行い、根本要因を特定の上、9 月中に全ての問題について対策を実施いたしました。そのため、本問題は既に解消しており、現在は発生いたしません。

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

なお、現時点で本問題は解消しているため、WSUS 側で対応を実施していただく必要はございません。

また、今回の問題を受けて、既に弊社内にて弊社サイトの変更時のプロセスの見直しを行っております。
今後とも継続的改善を実施し、サービスの安定と充実を目指して更なる品質の向上に努めて参りますので、何とぞご理解賜りたくお願い申し上げます。

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

今回は WSUS 環境で稀に発生が報告されている、意図せず WsusService.exe が停止してしまう事象について紹介をします。この事象が発生した場合には、「%programfiles%\Update Services\LogFiles」フォルダ内に保存されている SoftwareDistribution.log もしくは SoftwareDistribution.log.old にサービスが停止したタイミングにて、以下の記録が行われます。

YYYY-MM-DD HH:MM:SS   UTC   Error  WsusService.3  ContentSyncAgent.ProcessSqlException  File RowId: de386af7-2fd1-44a6-86a8-ee4db3d571ec: ActualState: DownloadingFile; Event: FileDownloaded; SqlException.Number: 50000; SqlException.State: 1; Message: spFireStateMachineEventEx found invalid EventName: FileDownloaded, FROM State: FileReady, on StateMachineName: FileOnServerActualStateMachine
 spFireStateMachineEvent got failure from spFireStateMachineEventEx for StatemachineName: FileOnServerActualStateMachine, RowID: 6f65e2a6-ffe6-40fd-ba56-925b11ef100c, EventName: FileDownloaded
   場所 Microsoft.UpdateServices.ServerSync.ContentSyncAgent.ProcessSqlException(Int32& numRetry, Int32 sqlExceptionNumber, String errorMessage)
   場所 Microsoft.UpdateServices.ServerSync.ContentSyncAgent.ContentSyncSPFireStateMachineEvent(DataAccess da, Guid rowId, String actualState, String eventToFire)
   場所 Microsoft.UpdateServices.ServerSync.ContentSyncAgent.ProcessBITSNotificationQueue()
   場所 Microsoft.UpdateServices.ServerSync.ContentSyncAgent.WakeUpWorkerThreadProc()
   場所 System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   場所 System.Threading.ThreadHelper.ThreadStart()

※ このログ ファイルは UTC 時刻にて記録が行われます。

通常この事象が発生した場合でも、WsusService.exe はその直後に起動されるため、大きな影響を与えることはございません。詳細について以下にご案内していきます。

事象の詳細

この事象は、WSUS サーバーが弊社サイトや上位の WSUS より、複数の更新プログラムに紐づく同一のファイルの処理のダウンロードを行った際に、内部的に更新プログラムのダウンロードの遷移を管理している処理において、意図しない遷移が稀に発生し、WsusService.exe が強制終了されてしまう事象となります。

複数の更新プログラムにて、同一のファイルが参照されることは、更新プログラムのリリース形態として起こり得るものであるにも関わらず、WSUS の製品として、このような状況を想定した処理が行われていないために、本問題が発生することがあります。

残念ながら現時点では本問題について、発生が報告されている環境においても、発生頻度も低く (数ヶ月に一度等) 問題に対する修正は行われておりません。

対処方法

上述の通り、この事象が発生した場合でも WsusService.exe はその直後に起動されるため、大きな影響を与えることはなく、通常は対処を実施していただく必要はございません。

また、この事象は、複数の更新プログラムに紐づく同一のファイルの処理のダウンロードを行った際に発生するため、リリース形態上 Windows Defender や Endpoint Protection の定義更新ファイルの自動承認、ダウンロードをしている環境にて発生し易い傾向があります。運用上可能であれば、定義更新ファイルの自動承認を停止していただくことや、最新の定義ファイルのみがダウンロードされるよう手動での承認を実施していただくことも事象の回避策として有効となります。

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

今回は Windows 10 / Windows Server 2016 で Get-WindowsUpdateLog による WindowsUpdate.log の出力に失敗する場合に、確認していただきたい点について紹介をいたします。

Windows 10 / Windows Server 2016 ではリアルタイムに WindowsUpdate.log が出力されなくなっており、通常はこちらのブログで紹介している ReportingEvents.log を見ていただいておりますが、より詳しい情報の確認をする必要が出てくることが稀にあります。このような場合には Powershell にて Get-WindowsUpdateLog を実行し、デスクトップに出力される WindowsUpdate.log よりログを確認するのですが、本ログの出力に失敗することがあるため、本記事ではよくお問い合わせいただくパターンについて紹介をしていきます。

「SymSrv.dll が存在しないため検出できません」エラーが表示される

Get-WindowsUpdateLog の実行後に、以下のようなエラー メッセージが出力されてしまうことがあります。

< エラー メッセージ >

Copy-Item : パス 'C:\Program Files\Windows Defender\SymSrv.dll' が存在しないため検出できません。
発生場所 C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1:56 文字:5
+ Copy-Item -Path $SYMSRV_DLL_PATH -Destination $WORKDIR -Force -Er ...

このエラーが出力されるケースとして、事例上は以下の 2 つパターンがあります。

• x64 の環境で Powershell (x86) から Get-WindowsUpdateLog を実行した場合
• Windows Defender の機能をアンインストールしている場合

1 つ目のパターンに該当する場合には、x64 版の Powershell から Get-WindowsUpdateLog を実行すれば問題ありません。

2つ目のパターンに該当する場合には、もちろん Windows Defender の機能を再度インストールしても良いのですが、「WindowsUpdate.log のためだけにインストールを行うのはちょっと…」という場合には、以下の手順にて Debugging Tools for Windows 10 (WinDbg) より、SymSrv.dll を入手することで対処が可能です。なお、この不具合については Winodws 10 Version 1607 / 1703 および Windows Server 2016 で発生します。

Windows Defender の機能をアンインストールしている場合の対処方法

1. Debugging Tools for Windows 10 (WinDbg) をこちらのサイトから入手し、ウィザードに従ってインストールを行います。
   ※ ウィザードの中では [Debugging Tools for Windows 10] だけを選択すれば問題ありません。
   ※ インストールを行う環境は、エラーが発生している環境と別の環境でも大丈夫です。
2. インストール フォルダ (既定では C:\Program Files (x86)\Windows Kits\10\Debuggers) 配下より、対象のアーキテクチャのフォルダ配下の SymSrv.dll をコピーし入手します。
3. 事象発生環境にフォルダ「C:\ProgramFiles\Windows Defender」が存在しない場合は作成、入手した SymSrv.dll  をコピーします。

ログの内容が「No Format Information found」になってしまう

Get-WindowsUpdateLog の実行自体は成功するものの、ログの内容が以下のようになってしまうことがあります。

1601/01/01 09:00:00.0000000 788 1160 Unknown( 10): GUID=638e22b1-a858-3f40-8a43-af2c2ff651a4 (No Format Information found).
1601/01/01 09:00:00.0000000 788 1160 Unknown( 11): GUID=bce7cceb-de62-3b09-7f4f-c69b1344a134 (No Format Information found).
1601/01/01 09:00:00.0000000 788 1160 Unknown( 11): GUID=638e22b1-a858-3f40-8a43-af2c2ff651a4 (No Format Information found).

この問題が発生するケースについては、事例上以下の 3 つのパターンがありますが、いずれもログのデコードを行うためのシンボル ファイルの入手に失敗していることが原因となります。なお、このいずれのケースも Windows 10 Version 1709 以降の環境では発生しません。

• インターネット接続が行えない場合
• キャッシュに古いシンボルの情報が残っている場合
• シンボル サーバーの更新が完了していない場合

1 つ目と 2 つ目のパターンに該当する場合の対処方法について、以下に紹介をしていきます。大変残念ながら 3 つ目のパターンに該当する場合には、対処方法はなく弊社側のシンボル サーバーの更新反映を待っていただくしかありません。

インターネット接続が行えない場合の対処方法

Get-WindowsUpdateLog の初回実行時には、デコードを行うためのシンボル ファイルをダウンロードするために、インターネット接続が必要となります。インターネット接続を行った状態で、Get-WindowsUpdateLog を実行することも対処となり得ますが、オフライン環境の場合でも以下の手順を実施することで、少し手間が掛かりますが、デコードを行うことが可能です。

<手順>

1.  インターネットに接続できる同じ WUA のバージョンの OS 環境をご用意いただきます
   ※ WUA のバージョンは「C:\Windows\System32\wuaueng.dll」のファイル バージョンより判別出来ます。また、この公開情報で紹介している、同じ累積的な更新プログラムが適用されていれば、同じ WUA のバージョンとなります。
2. 1 の環境で Powershell より、オプションの指定なしで Get-WindowsUpdatelog を実行します。
3. ダウンロードされたシンボル ファイルが存在する「%temp%\windowsupdatelog」フォルダをコピーします。
4. インターネットに接続できない環境に 3 でコピーしたフォルダをコピーします。
5. 4 の環境で Powershell より、 「Get-WindowsUpdatelog -symbolserver <4 のコピー先フォルダ\symcache>」と入力します。
6. デスクトップに「WindowsUpdate.log」が生成されます。

キャッシュに古いシンボルの情報が残っている場合の対処方法

シンボルのファイルは「%temp%\windowsupdatelog」にキャッシュされるため、この中のファイルが古いままの場合には問題が発生することがあります。このフォルダは手動で削除出来るため、削除後に再度 Get-WindowsUpdateLog を実行することで問題を改善出来ます。

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

ちょっと期間が空いてしまいましたが、今回は第 1 回は「概要篇」に引き続き、配信の最適化のグループ ポリシーについて紹介をいたします。グループ ポリシーの一覧や各設定を行った場合の詳細については、以下の公開情報にて紹介していますので、今回はポイントを絞ってよくご利用いただくグループ ポリシーについて案内していきます。

ダウンロード モードの設定

配信の最適化の機能を利用する上で、一番重要なグループ ポリシーが以下のダウンロードの設定です。この設定で配信の最適化でピアとしてクライアントが選択される範囲を指定することが出来ます。

配信の最適化を有効に活用して、クライアント同士で P2P の通信を行いたい場合には、以下の 3 つの内いずれかを選択します。これらについては図も含めて後ほど詳細を紹介します。

• LAN (1 - 既定) : 同じパブリック IP アドレスを使用してインターネットに接続するクライアント同士
• グループ (2) : 同じドメインや同じ Active Directory サイトのクライアント同士、または同じグループ ID のクライアント同士
• インターネット (3) : インターネット上のクライアントも含めたクライアント同士

また、逆に P2P での通信を行いたくない場合には、以下の 3 つの内いずれかを選択します。いずれも P2P の通信は行いませんが、以下の表に示す通り、細かな動作の違いがあります。

※ 注意 : ダウンロード モードのグループ ポリシーを "無効" に設定しても、P2P の通信は無効に出来ません。"無効" の場合は、既定の設定が利用されます。

クラウド サービスの接続も含めて無効化する場合には、「簡易 (99)」もしくは「バイパス (100)」を選択しましょう。また、このブログでも紹介している通り BranchCache や、このブログの C として紹介している BITS の帯域制限等、以前の OS から利用出来た BITS に関連する機能を利用したい場合には、「バイパス」を選択していただく必要があるので注意が必要です。

さて、それではさらに LAN (1 - 既定)、グループ (2)、インターネット (3) を選択した場合の動作について詳しく説明していきます。

LAN (1 - 既定) を選択した場合の動作

LAN を選択した場合には、以下のように同じパブリック IP アドレスを使用してインターネットに接続するクライアント同士でピアリングが行われます。各拠点で利用しているパブリック IP アドレスが異なるようなネットワーク構成では、本設定が有効です。

逆に複数の拠点で、共通した 1 つのパブリック IP アドレスを利用しているようなネットワーク構成の場合には、本モードを選択すると拠点を跨いだ P2P の通信が発生してしまう可能性があるため、注意してください。

グループ (2) を選択した場合の動作

グループ (2) を選択した場合には、以下のように同じドメインや同じ Active Directory サイトのクライアント同士でピアリングが行われます。

また、グループを選択した場合には、以下のグループ ポリシーと組み合わせて設定をすることで、同一のグループ ID を設定したクライアント内でピアリングを行よう範囲をカスタマイズすることが出来ます。グループ ID と指定する ID は一意の GUID であれば、なんでも問題ありませんので、公開情報に記載の通り Powershell で [guid]::NewGuid() を実行し、ID を生成し設定してください。

- 補足 :同じサブネット内のクライアントでピアリングが行われるよう制限を掛けたい場合
バージョン 1803 のクライアントからは、同じサブネット内のクライアントでピアリングが行われるよう制限を掛けたい場合に、併せて以下のグループ ポリシーを設定することで、要望を実現することが可能となりましたので、こちらの設定についても併せてご検討ください。

インターネット (3) を選択した場合の動作

インターネット (3) を選択した場合には、インターネット越しのクライアントも含めてピアリングが行われる動作となります。インターネット経由でのピアリングも行われる可能性がある設定となり、一般的にエンタープライズ環境で利用していただくことはあまりありません。

エンタープライズの環境でよくご利用いただく設定

その他の設定も含め、配信の最適化による P2P を動作させるために、エンタープライズ環境でよくご利用いただく設定値について、参考としてご案内します。

なお、以前のブログでも紹介した通り、配信の最適化では端末同士のピアリングを Delivery Optimization のクラウド サービス上で行っており、これらの値を設定した場合でもダウンロードするファイルの 100% をピアからファイルを取ってくるような動作になりませんので、ご注意ください。

※ これらのポリシーはバージョン 1803 より利用できます。

「グループポリシー篇」は以上です。さて次回は実際の効果を測定する「効果測定篇」となります。お楽しみに！

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

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

今回は「概要篇」、「グループポリシー篇」に引き続き第 3 回は「効果測定篇」として、実際に配信の最適化でどの程度ピアからファイルを取得出来ているか、確認を行う手順について紹介をしていきます。

Windows 10 もバージョン アップが重ねられ、配信の最適化の機能も効果を確認することが出来る、以下の「アクティビティ モニター」の機能がバージョン 1709 から追加されています。

[スタート]  ボタン > [設定]  > [更新とセキュリティ]  > [詳細オプション] > [配信の最適化] > [アクティビティ モニター]

上記のアクティビティ モニターを利用することで、配信の最適化の効果もかなり簡単に確認が出来るようになったため、その手順について今回の記事では紹介していきます。

検証環境の構成および設定

今回の検証では、以下のシンプルな構成でバージョン 1803 のクライアントを 2 台用意し検証を行います。

実際の検証を行う場合には、本番環境に可能な限り近い構成で検証していただくことをオススメします。特にクライアントの台数は多いほど効果が得られ易いので、可能であれば多くのクライアント (例えば 10 台以上) を用意して検証をしてください。

また、今回は配信の最適化の機能について、効果を得られやすくするために、以下グループ ポリシーの設定を行います。これらのグループ ポリシーはいずれも「グループポリシー篇」で紹介しておりますので、詳細についてはそちらの記事をご参照ください。

• ダウンロード モード : "グループ (2)"
• グループ ID : 共通したグループ ID
• 最小ピア キャッシュ コンテンツ ファイル サイズ (MB) : 1 MB
• 最大キャッシュ時間 (秒) : 0 秒 (無制限)
• http からのバックグラウンド ダウンロードを延期 (秒) : 3600 秒
• http からのフォアグラウンド ダウンロードを延期 (秒) : 60 秒

検証手順

それでは実際の検証手順について紹介をしていきます。

事前準備

検証のために新しく OS をインストールした場合には、特に問題とはならないのですが、以前より環境を利用していた場合には、アクティビティ モニターのカウンターが一部カウント アップされてしまっていることがあります。

この場合には、各端末で以下のコマンドを管理者権限で実行し、Delivery Optimization サービスを一度停止した後に値を保持しているレジストリ キーを削除することで、カウンター値を全てクリアします。

net stop dosvc
reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DeliveryOptimization\Usage /f
net start dosvc

1 台目のクライアントでの Windows Update の実施

1 台目のクライアントで Windows Update を実施し、配信の最適化のキャッシュが保存されるようにします。

1. このブログの手順等に沿って、Windows Update を実行し、更新プログラムのダウンロードを完了させます。
   ※ 特にインストールまでしていただく必要はありません。
2. Powershell で以下のコマンドを実行し、"Status" が "Caching" となっており、キャッシュの準備が完了しているものが存在するか確認を行います。
   << 実行コマンド >>
   

   Get-DeliveryOptimizationStatus

   << 実行例 (キャッシュの準備が完了出来ている場合) >>
   

   Get-DeliveryOptimizationStatus
   
   FileId : 8b46fea9c0a4ca53a93248c279b86cbc678b0216
   FileSize : 21734025
   TotalBytesDownloaded : 21734025
   PercentPeerCaching : 0
   BytesFromPeers : 0
   BytesFromHttp : 21734025
   Status : Caching
   Priority : Background
   BytesFromLanPeers : 0
   BytesFromGroupPeers : 0
   BytesFromInternetPeers : 0
   BytesToLanPeers : 0
   BytesToGroupPeers : 0
   BytesToInternetPeers : 0
   DownloadDuration : 00:00:03.0780000
   HttpConnectionCount : 2
   LanConnectionCount : 0
   GroupConnectionCount : 0
   InternetConnectionCount : 0
   DownloadMode : 2
   SourceURL : http://7.au.download.windowsupdate.com/c/msdownload/update/software/updt/2018/10/windows10.0-
   kb4462930-x64_8b46fea9c0a4ca53a93248c279b86cbc678b0216.cab
   
   (以下略)

   ※ 注意 : キャッシュの準備が 1 つも出来ていない場合には、Delivery Optimization のクラウド サービスへ接続出来ていない可能があります。このブログで紹介しているポート要件が満たされているか、またこちらやこちらのブログで紹介している通り、プロキシの設定が正しく行われているか改めて確認してください。

3. 念のため、アクティビティ モニターを立ち上げて状況を確認します。1 台目のクライアントのために、通常は以下のように、ほとんどキャッシュからは取れていません。
   

2 台目以降のクライアントでの Windows Update の実行

続けて 2 台目以降のクライアントで、Windows Update を実行し、実際にキャッシュからどの程度情報を取ってこれるか確認を行います。

1. 2 台目以降のクライアントでも Windows Update を実行します。ただし、今回は "http からのバックグラウンド ダウンロードを延期 (秒)" の設定によって、キャッシュが利用される確率を上げるため、以下のコマンドを実行してバックグラウンドでダウンロード処理を開始させます。

   usoclient StartScan

2. Powershell で以下のコマンドを実行し、状況を確認します。"BytesFromPeers" がカウント アップされていれば、クライアント間での通信が行われているものと考えられます。
   << 実行コマンド >>
   

   Get-DeliveryOptimizationStatus

   << 実行例 (キャッシュからファイルのダウンロードが行われている場合) >>
   

   Get-DeliveryOptimizationStatus
   
   FileId : 1d4edb196dcd01bb090cceaa3e7633ea9e48d475
   FileSize : 132970352
   TotalBytesDownloaded : 132970352
   PercentPeerCaching : 100
   BytesFromPeers : 132970352
   BytesFromHttp : 0
   Status : Caching
   Priority : Background
   BytesFromLanPeers : 132970352
   BytesFromGroupPeers : 0
   BytesFromInternetPeers : 0
   BytesToLanPeers : 0
   BytesToGroupPeers : 0
   BytesToInternetPeers : 0
   DownloadDuration : 00:00:27.3590000
   HttpConnectionCount : 2
   LanConnectionCount : 1
   GroupConnectionCount : 0
   InternetConnectionCount : 0
   DownloadMode : 2
   SourceURL : http://11.au.download.windowsupdate.com/d/msdownload/update/software/defu/2018/10/am_base_1d4edb196dcd01bb090cceaa3e
   7633ea9e48d475.exe
   
   (以下略)

   ※ 注意 : キャッシュよりダウンロードが行われない場合には、公開情報に記載の通りこちらやこちらの点をご確認ください。

3. ダウンロードが完了したら、アクティビティ モニターを立ち上げ、キャシュからどの程度ファイルが取って来れたかを確認します。今回の検証では、かなりキャッシュから取って来易いよう設定したため、73.19 % をキャッシュから取ってこれていることが確認出来ます。
   ※ "http からのバックグラウンド ダウンロードを延期 (秒)" を利用している場合には、ダウンロードが完了するまでに長時間を要する可能性があるご留意ください。
   
   なお、以下の Powershell コマンドで同じ内容を出力することも可能なため、複数のクライアントで統計情報を収集する際にはお役立てください。
   << 実行コマンド >>
   

   Get-DeliveryOptimizationPerfSnapThisMonth

   << 実行例  >>
   

   Get-DeliveryOptimizationPerfSnapThisMonth
   
   MonthlyUploadLanBytes : 402,519,920
   MonthlyUploadInternetBytes : 0
   MonthlyDownloadHttpBytes : 155,175,324
   MonthlyDownloadLanBytes : 423,621,728
   MonthlyDownloadInternetBytes : 0
   MonthlyDownloadFgRateKbps : 0
   MonthlyDownloadBgRateKbps : 28,757
   MonthlyUploadLimitReached : No
   MonthStartDate : 11/1/2018
   

さてこれで配信の最適化に関する一連のシリーズは以上です。リリースされた当初は動きが分かりづらかったり、コントロールしにくい点が多かったかと思いますが、バージョンアップの度に機能が改善されていますので、今後の導入検討の参考となれば幸いです！

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

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

今回は Windows 10 バージョン 1703 以降の環境で、機能更新プログラムの配信時に以下のグループ ポリシーを設定しても、自動的にインストールまで進んでしまう問題について紹介します。問題の修正については、さらに開発部門から進展が得られた場合には、本ブログを更新する予定です。ご不便をおかけしますが、何卒ご了承賜りますようお願い申し上げます。

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

- 事象の概要

上記の設定を実施している場合でも、機能更新プログラムの配信時に Windows 10 バージョン 1703 以降の環境では、インストールまでが自動実行されてしまう問題が発生してしまいます。なお、この問題は月々リリースされている品質更新プログラムや、機能更新プログラム以外のその他の更新プログラムでは発生いたしません。

なお、本問題が発生した場合でも、再起動の時間はアクティブ時間によって制御されます。

- 対処方法

大変恐縮ながら、現時点で根本的な対処方法はありません。回避策として機能更新プログラムの配信時に以下のような設定を検討していただいております。

- 回避策 1 : 更新プログラムの検出処理までを自動実行させる

機能更新プログラムのインストール処理を、必ずユーザーが任意のタイミングで始められるようにしたい場合には、以下のグループ ポリシーを設定することで本問題を回避することが可能です。

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

ただし、この回避策を実施した場合には、ユーザーが Windows Update を開始したタイミングで、機能更新プログラムのダウンロードから行われる挙動となるため、ダウンロードに長時間を要する可能性があるような環境では注意が必要です。

- 回避策 2 : 更新プログラムのインストールまでを自動実行し、再起動を任意のタイミングで実施する

機能更新プログラムの適用時には、そのほとんどの処理が再起動時に実行されます。このため、以下の設定でインストールまでを自動実行し、再起動の処理をユーザーがログインしている場合には実行しないようにすることで、可能な限り、ユーザーの任意のタイミングで再起動および再起動に伴う、機能更新プログラムの適用処理を実施させることが可能です。

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

この回避策の場合、更新プログラムのダウンロード、インストールはバックグラウンドで自動実行することが可能です。ただし、ユーザーがログインしていない場合には、再起動が自動実行される恐れがあるため、必ずユーザー任意のタイミングで機能更新プログラムの適用を行いたい場合には注意が必要です。

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

WSUS の同期時に接続する URL については以下の公開情報の「2.1.1. Connection from the WSUS server to the Internet」の箇所にて紹介をしておりますが、今回接続先の URL の追加を行いましたため紹介をいたします。

- Step 2: Configure WSUS

https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus#BKM_ConfigurenetworkConnections

具体的には、WSUS サーバーが弊社サイトから更新プログラムをダウンロードする際に以下の URL を追加で利用するように変更を行いました。ご不便をおかけしますが、プロキシやファイア ウォールにて接続先の URL を制御している場合には、以下の URL に対する通信についても許可していただけますようお願い申し上げます。

[ 追加 URL ]

http://dl.delivery.mp.microsoft.com

https://dl.delivery.mp.microsoft.com

※1 上述の公開情報についても更新を行う予定です。

※2 本ブログの執筆時点 (2019 年 2 月 14 日) で本 URL がダウンロード時に用いられている更新プログラムは、Windows 10 Version 1709 向けの KB4486996 のみとなります。

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

こちらの公開情報でも紹介している通り、Microsoft ではセキュリティ保護のために SHA-1 から SHA-2 への移行を段階的に進めており、この一環として Windows Update や WSUS 等から配信される更新プログラムに付与されているコード証明書についても SHA-2 へ移行を行うことを予定しております。

具体的なタイムラインについては、以下の公開情報で最新の情報を随時紹介しております。特に WSUS 3.0 SP2 や Windows 7 SP1、Windows Server 2008 SP2、Windows Server 2008 R2 SP1 を利用しているお客様は、これからリリースされる SHA-2 の証明書のみが付与された更新プログラムを適用・配信するために、期限までに更新プログラムの適用が必要になります。

適用すべき更新プログラムや今後の移行スケジュールの情報は、次の公開情報に記載しております。ご一読いただき、期限までに更新プログラムを適用くださいますようお願いいたします。