こんにちは。マイクロソフトの三原です。

今回は、インデックスの再構成の手順をご紹介いたします。

WSUS サーバー自身には、データベースのインデックスをメンテナンスする機能が含まれていません。
運用継続に伴ってデータベースのパフォーマンスが劣化する可能性があります。(※1)
このメンテナンス用スクリプトが公開されていますので、これを利用し定期的にインデックスの再構成を実施いただくことをお勧めします。

(※1) 例えばWSUS サーバーを運用するにあたり、定期的にクリーンアップ ウィザードを実施していただくことを推奨しておりますが、今まで、定期的にクリーンアップ ウィザードを実施していない場合は、クリーンアップ処理に数時間を要することもあります。
処理完了までの時間を少しでも削減するために、まずはインデックスの再構成を行ってください。

インデックスの再構成を行う手順は下記のとおりとなります。

＜作業概要＞
WSUS のデータベースである SUSDB に対して、下記ページに記載されている WSUS データベース メンテナンス用のスクリプトを実行します。スクリプトをコピーペーストする際の注意点をこちらの記事の最後に記載してございますので、ご一読ください。 (※2)

スクリプトは WSUS サーバー上で実行してください。WSUS サーバーを親子構成している場合は、親子両方の WSUS サーバー上で実行してください。

"Re-index the WSUS 3.0 Database"
<http://go.microsoft.com/fwlink/?LinkId=87027>

＜作業手順＞
ご利用いただいているデータベース製品にあわせて、以下のいずれかの作業を実施してください。

＜SQL Server (製品版) を使用している場合＞
1) SQL Server Management Studio を起動し、WSUS 用のデータベースが動作しているインスタンスに接続します。

2) SUSDB に対する新しいクエリ画面を開きます。

3) クエリ画面内に、上述の WSUS データベース メンテナンス用スクリプトをコピーペースト (※2) して、実行します。データベースの最適化が終了すると "Statistics for all tables have been updated" または "全テーブルの統計が更新されました" というメッセージが表示されます。


＜Windows Internal Database (WID) を使用している環境の場合＞
SQL Server Management Studio Express を下記よりダウンロード、インストールしてから、上述の SQL Server の場合と同じ要領で実行します。本ツールでは 製品版の SQL Server Management Studio とほぼ同等の GUI 操作ができます。

1) 下記 URL より SQL Server Management Studio Express をダウンロードし、WSUS サーバーにインストールします。

Microsoft SQL Server Management Studio Express
<http://www.microsoft.com/ja-jp/download/details.aspx?id=8961>
(.NET Framework 2.0, MSXML 6.0 のインストールが必要となります。もし未導入の場合にはページ内のリンクからインストールを行って下さい)

※ OS が Windows Server 2008, Windows Server 2008 R2 の場合は、こちらもお使いいただけます。
Microsoft SQL Server 2008 R2 RTM - Management Studio Express
<http://www.microsoft.com/ja-jp/download/details.aspx?id=22985>

2) SQL Server Management Studio Express を起動し、下記のパラメータを入力してデータベースへ [接続] を行います。

サーバーの種類 : データベース エンジン
サーバー名 : \\.\pipe\mssql$microsoft##ssee\sql\query
認証 : Windows 認証

3) 左ペインのデータベースのツリーから [SUSDB] を右クリックして[新しいクエリ] を選択します。

4) 右ペインのクエリ画面内に、上述の WSUS データベース メンテナンス用スクリプトをコピーペースト (※2) して、実行します。

データベースの最適化が終了すると "Statistics for all tables have been updated" または"全テーブルの統計が更新されました" というメッセージが表示されます。

※2 スクリプトをコピーペーストする場合は、スクリプト右上の "Copy Code" を押してコピーせず、スクリプト全体をマウスで選択し、コピーペーストしてください。


手順は以上です。

-補足
WSUS 3.0 SP2 操作ガイド (Operations Guide) では、少なくとも月次でこのメンテナンスの実施を推奨しております。下記ページをご参照ください。

"Appendix I: Database Maintenance"
<http://technet.microsoft.com/ja-jp/library/dd939795(v=ws.10).aspx>

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

本日は Windows Server 2012 上の WSUS 4.0 にてポート番号を 8530 から 80 に変更する方法をご紹介します。
WSUS 3.0 SP2 までは既定のポートは 80 番であり、インストール中に変更可能でしたが、Windows Server 2012 にて WSUS 4.0をインストールすると、既定のポートは 8530 番となりインストール中に変更することは出来ません。

運用環境上、既定の 8530 番から 80 番へ変更する必要がある場合には、この手順をご活用ください。

【 操作手順 】
1. WSUS サーバーにて [インターネット インフォメーション サービス(IIS) マネージャー] を起動します。
2. 左ペイン [サイト] に [Default Web Site] と [WSUS の管理] があることを確認します。

※ Point※
[Default Web Site] と [WSUS の管理] がある場合： ポート 8530 番が設定されています。
[Default Web Site] のみある場合： 既にポート 80 番が設定されています。

3. コマンドプロンプトを管理者権限で実行し、以下のコマンドを入力します。
"C:\Program Files\Update Services\Tools\wsusutil.exe" UseCustomWebSite false

4. 実行後「ポート番号の使用： 80」 と表示されることを確認します。


5.  [インターネット インフォメーション サービス(IIS) マネージャー] - [サイト] にて [Default Web Site] のみ表示されていることを確認します。



< 参考情報>
Step 3: Configure WSUS
http://technet.microsoft.com/en-us/library/hh852346.aspx

以上のとおり、ご案内いたします。

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

Windows Server 2012 にて、WSUS サーバーを構築中のお客様より、「 Windows Server 2012 で 役割と機能の追加ウィザードを利用し、WSUS サーバーをインストールした際、インストール後の初期構成タスクに失敗する。」 というお問い合わせをいただくことがあります。

以下の公開情報にて、WSUS サーバーのインストール方法について、3 点の回避策を公開しております。同様の事象が発生した場合には、トラブルの対処にお役立てください。

回避策1. PowerShell を利用した WSUS サーバーのサイレント インストールを実行する。
回避策2.構成ファイルを手動で編集する。
回避策3. WSUS 管理コンソールを起動して、初期構成タスクを完了する。

－ Windows Server 2012 で WSUS サーバーの役割をインストール後に、初期構成タスクに失敗する事があります
http://support.microsoft.com/kb/2882799/ja

※ 補足 ※
回避策 1では、PowerShell で WSUS サーバーのインストールを実行する前に、「役割と機能の追加ウィザード」 の 「構成設定ファイルエクスポート」 にて構成設定ファイルをエクスポートする必要があります。

以上のとおり、ご案内いたします。

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

今回は Windows Update の実行時に通信エラーが発生した際のトラブルシュート方法をご紹介します。

以下の公開情報にて、プロキシ サーバーを使用する環境にて Windows Update を実行すると通信エラー (0x80240030 / 0x80072efe / 0x80244022 / 0x80072EFD / 0x80072EE2) が発生する際の原因や対処方法を公開しております。Windows Update のトラブルシュートにお役立てください。

－ プロキシ サーバーを使用する環境にて Windows Update を実行すると通信エラーが発生する
http://support.microsoft.com/kb/2894304


通信エラーの原因:
1. Windows Update の通信がプロキシ サーバーを使用するように構成されていない
2. プロキシ サーバーが Windows Update に必要な通信を許可していない


対処方法:
原因 1 の対処方法
クライアントの環境に応じて、以下の公開情報をもとに、WinHTTP の構成や Internet Explorer のインターネット オプション構成を確認します。
－ Windows Update クライアントが Windows Update Web サイトへの接続に使用するプロキシ サーバーを決定するしくみ
http://support.microsoft.com/kb/900935/ja


原因 2 の対処方法
プロキシ サーバーにて Windows Update  / Microsoft Update サイトへの通信を許可します。許可リストにつきましては、以下の弊チームブログもご参照ください。
－ WSUS サーバーにおける Firewall の構成方法
http://blogs.technet.com/b/jpwsus/archive/2013/04/10/wsus-firewall.aspx


＊補足＊
なお、プロキシ サーバーを構成していない環境にて、通信エラーが発生する場合には、クライアントにて不要な WinHTTP 設定の有無や Internet Explorer のインターネット オプション構成について、正常なクライアントとの相違をご確認ください。


＊参考情報＊
ご参考までに、Windows Update 時に発生したエラーコードの説明を記載した公開情報をご案内いたします。
－ Additional Resources for Windows Server Update Services
http://technet.microsoft.com/en-us/library/cc720432(v=ws.10).aspx

以上のとおり、ご案内いたします。

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

2014 年 4 月 8 日に Windows 8.1 の操作性を向上した更新プログラムである Windows 8.1 Update (KB 2919355) を公開いたしました。

しかしながら、KB 2919355 のWSUS 経由での展開に関しましては、特定の WSUS 環境に起因した問題が確認されたため、現在のところ提供を延期しております。
現在可能な限り早く問題を解決し、すべてのサポートされる WSUS 構成で正常動作を確認できた後、リリースすることを予定しております。
なお、KB 2919355 は Microsoft Update カタログや MSDN より入手いただけますが、本問題を解決した更新プログラムがリリースされるまで、WSUS 環境においては KB 2919355 の展開を停止していただくことをお勧めしております。
ご不便をおかけしており誠に申し訳ございませんが、何卒ご理解賜りますようお願い申し上げます。

本問題の詳細につきましては、弊社 WSUS 開発チームが運用している以下の blog 記事にてご案内しております。

Windows 8.1 Update (KB 2919355) prevents interaction with WSUS 3.2 over SSL
http://blogs.technet.com/b/wsus/archive/2014/04/08/windows-8-1-update-prevents-interaction-with-wsus-3-2-over-ssl.aspx

問題に関する説明の日本語訳を以下に記載いたします。

問題の説明

以下の条件すべてに合致した場合、WSUS 3.0 SP2 に対するスキャン処理が失敗する事象が発生します。

  1. KB 2919355 を適用した Windows 8.1 PC であること。
  2. KB 2919355 を適用した Windows 8.1 PC の接続先が、以下のプラットフォームで動作する WSUS 3.0 SP2 サーバーであること。
     ・ Windows Server 2003 SP2
     ・ Windows Server 2003 R2 SP2
     ・ Windows Server 2008 SP2
     ・ Windows Server 2008 R2 SP1
  3. SSL を使用するように構成している HTTPS 環境の WSUS サーバーであること。
  4. WSUS サーバーで、TLS 1.2 が無効になっていること。

従いまして、TLS 1.2 を有効にしていない HTTPS 環境の WSUS 3.0 SP2 サーバーが接続先に設定された、KB 2919355 適用済みのWindows 8.1 PC にのみ影響を与える問題となります。
但し、HTTPS 環境の WSUS サーバーは、既定で TLS 1.2 が無効になっておりますので、ご注意いただく必要がございます。

回避策

Windows Server 2008 R2 の WSUS 3.0 SP2 環境の場合は、次のいずれかの手順を実施いただくことで、現象を回避することができます。

  ・TLS 1.2 を有効にする。 (※)
  ・WSUS における HTTPS の利用を無効にする。

Windows Server 2008 R2 以外の WSUS 3.0 SP2 環境の場合は、次の手順を実施いただくことで、現象を回避することができます。

  ・WSUS における HTTPS の利用を無効にする。

本問題を解決した更新プログラムがリリースされた後は、WSUS における HTTPS の利用を有効にします。

(※) Windows Server 2008 R2 において、TLS 1.2 を有効にする手順は、以下の技術情報の [詳細] – [SCHANNEL\Protocols サブキー] セクションをご参照ください。

特定の暗号化アルゴリズムおよび Schannel.dll のプロトコルの使用を制限する方法
http://support.microsoft.com/kb/245030

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

2014 年 4 月 16 日に Windows 8.1 Update (KB2919355) を WSUS に公開いたしました。
この更新プログラムは、既に Microsoft Update や MSDN で公開している KB2919355 の内容に加え、以下の KB でご案内している HTTPS 環境の WSUS 3.0 SP2 で発生する問題に対する修正も含まれております。

HTTPS を構成し、TLS 1.2 が有効でない場合は、WSUS 3.0 SP2 を Windows Update クライアントはスキャンしません。
http://support.microsoft.com/kb/2959977

WSUS で同期が完了すると、以下のように「Windows 8.1 Update (KB2919355)」が表示されます。
(64 bit 用は、「x64 ベース システム用 Windows 8.1 Update (KB2919355)」の表記となります。)

製品は「Windows 8.1」、更新プログラムの分類は「セキュリティ問題の修正プログラム」、重要度は「重大」となります。
サイズは、32 bit 用が約 430 MB、64 bit 用が約 890 MB と通常のセキュリティ更新プログラムと比較して、大きいものとなっておりますので、適用の際はご考慮くださいますようお願い申し上げます。

～ 参考情報 ～
米国の弊社 WSUS 開発チームの blog 記事においても、KB2919355 の WSUS への公開についてご案内しております。

Solution to KB2919355 preventing interaction with WSUS 3.2 over SSL
http://blogs.technet.com/b/wsus/archive/2014/04/16/solution-to-kb2919355-preventing-interaction-with-wsus-3-2-over-ssl.aspx

こんにちは。WSUS サポートの本田です。

2014/6/10 現在、WSUS より Internet Explorer 9 ～ 11 を配信できるようになっておりますが、最近 WSUS で Internet Explorer 9 や 10 を配信しているものの、Windows 7 クライアントで検出されないというお問い合わせを多くいただきます。
Internet Explorer をアップグレードする際は、前提条件となる更新プログラムが適用されていないと検出されません。
前提条件となる更新プログラムは Internet Explorer のバージョン毎に下記 KB 情報で公開しておりますので、以下にまとめてご紹介いたします。

Prerequisites for installing Internet Explorer 9
http://support.microsoft.com/kb/2399238/en (英語)
http://support.microsoft.com/kb/2399238/ja (日本語機械翻訳)

Prerequisites for installing Internet Explorer 10 in Windows 7 SP1
http://support.microsoft.com/kb/2818833/en (英語)
http://support.microsoft.com/kb/2818833/ja (日本語機械翻訳)

Prerequisite updates for Internet Explorer 11
http://support.microsoft.com/kb/2847882/en (英語)
http://support.microsoft.com/kb/2847882/ja (日本語機械翻訳)

Internet Explorer 9 の場合、Windows 7 で前提条件となる更新プログラム KB2454826 は Service Pack 1 に含まれていますので、Windows 7 SP1 環境においては本更新プログラムを改めて適用いただく必要はございません。
なお、特定の環境においては、以下の更新プログラムも適用する必要があることが報告されております。

Internet Explorer 9 から一部の Canon プリンターを使用して印刷できない
http://support.microsoft.com/kb/2522422/ja

もし、Windows 7 SP1 環境であるにも関わらず Internet Explorer 9 が適用対象とならない場合は、上記更新プログラムの適用をご検討ください。

Internet Explorer 10 や 11 の場合は、KB2670838、KB2729094、KB2834140 など、分類が「更新」や「Feature Packs」となる更新プログラムが前提条件に含まれます。
そのため、WSUS で前提条件となる更新プログラムも配信する場合は、「更新」や「Feature Packs」も同期対象とする必要がありますので、ご留意ください。

※ KB2834140 については、上記 Internet Explorer 10 の技術情報には記載されておりませんが、KB2670838 をインストールした後に発生する問題を修正したプログラムとなるため、前提条件として必要な更新プログラムとなります。こちらも合わせて適用くださいますようお願い申し上げます。

"0x00000050" STOP エラーが Windows 7 SP1 または Windows Server 2008 R2 SP1 を搭載しているコンピューターで更新プログラム 2670838 をインストールした後に発生する
http://support.microsoft.com/kb/2834140

みなさん、こんにちは。
WSUS 担当チームの染谷です。
本日は、Windows Internal Database (WID) に接続する Tips をご紹介します。

Windows Server Update Services (WSUS) では、カタログ情報を保存するデータベースとして、Windows Internal Database (WID) または Microsoft SQL Server のいずれかを使用することができます。
WID は、Windows に組み込まれているミニマムなデータベースです。
通常の WSUS 運用においては、データベースを外部ツールから操作する必要はありませんが、データベースのメンテナンスやバックアップの実行などでデータベースに接続して操作する局面が生じることがあります。
Microsoft SQL Server を使用している場合には、グラフィカルなツールを使用してデータベースに接続することが可能であるため、あまり頭を悩ませることはありません。
しかし、WID には、管理ツールが付属しないため、こういったメンテナンスを実行する際には管理用のツールをインストールする必要があります。
今回は、Windows Server 2012 / Windows Server 2012 R2 の WSUS が使用する WID に接続する方法をご紹介します。

なお、Windows Server 2008 R2 に同梱の WID に接続する方法については、次の記事をご参照ください。
  WSUS データベースを簡単に操作するには
  http://blogs.technet.com/b/jpwsus/archive/2012/03/09/how-to-manage-wid.aspx

事前準備 - SQL Server Management Studio をインストールしよう！
まず最初に事前準備として、データベースに接続する管理ツールである SQL Server Management Studio をインストールします。
Windows Server 2012 / Windows Server 2012 R2 に同梱される WID は Microsoft SQL Server 2012 相当であるため、管理ツールも対応したバージョンを使用します。

以下の Web サイトから、Microsoft SQL Server 2012 Service Pack 2 用の SQL Server Management Studio のインストーラーをダウンロードしてください。
ファイル名は、"SQLManagementStudio_x64_JPN.exe" です。Windows Server 2012 / Windows Server 2012 R2 は、64 ビット版 (x64) のリリースとなりますので間違えないようにご注意ください。

  MicrosoftR SQL ServerR 2012 Service Pack 2 (SP2) Express
  http://www.microsoft.com/ja-jp/download/details.aspx?id=43351

ダウンロードができたら、SQL Server Management Studio をインストールします。
そのままインストールを開始したいところですが、実は、SQL Server Management Studio は .NET Framework 3.5 の機能を必要とします。
Windows Server 2012 / Windows Server 2012 R2 では、既定で .NET Framework 3.5 の機能が有効となっていないため、あらかじめ機能を有効化しておきます。
(インストーラーによって自動的に有効化されますが、有効化に失敗した場合 SSMS のインストールにも失敗するため、できるだけ先に有効化しておくことをお勧めします)

.NET Framework 3.5 を有効化する方法はいくつかありますが、ここではいちばん標準的なサーバー マネージャーを使用した機能の有効化方法をご説明します。
なお、以下の操作では Microsoft Update を使用してモジュールのインストールが実行されますので、WSUS サーバーはインターネット接続が有効な状態で作業を実施してください。
もしオフライン環境などインターネット接続がない環境で .NET Framework 3.5 の機能を有効にする必要がある場合には、後述の参考文献をご参照ください。

1. サーバー マネージャーを開き、[管理] - [役割と機能の追加] の順に選択します。
   
   　
   
   　
   
   
2. ウィザードを進め、機能 ページで ".NET Framework 3.5 (.NET 2.0 および 3.0 を含む)" にチェックを入れます。
   
   　
   
   
   
3. ウィザードの最後で [インストール] ボタンをクリックしてインストールを開始します。

この後、インターネット経由で .NET Framework 3.5 のモジュールがダウンロードされます。
インストールが完了するまではしばらく時間がかかりますので、終わるまで待ちます。
.NET Framework 3.5 のインストールが完了したら、SQL Server Management Studio をインストールします。

1. ダウンロードしたインストーラーをダブルクリックして起動します。
2. SQL Server インストール センターが表示されたら、"SQL Server の新規スタンドアロン インストールを実行するか、既存のインストールに機能を追加します" をクリックします。
   
   
   
   
3. ライセンス条項に同意してウィザードを進め、機能の選択 ページで "管理ツール - 完全" にチェックが入っていることを確認します。
   通常はすでにチェックが入っていますので、既定の状態のままで問題ありません。
   
   
   
   

この後、ウィザードを完了させ、SQL Server Management Studio のインストールを開始します。
これで SQL Server Management Studio をインストールする手順は完了です。

Windows Internal Database へ接続してみよう！
いよいよ WID に接続します。
WID は、コンピューターの管理者権限を持つアカウントで接続する必要がありますので、作業を実行するアカウントに適切な権限が付与されていることを確認して操作を実施してください。

1. ローカルの Administrators グループに属するアカウントでコンピューターにサインインします。
2. SQL Server Management Studio を管理者として実行します。
3. サーバー名に以下の文字列を入力して [OK] をクリックします。
   \\.\pipe\MICROSOFT##WID\tsql\query
   
   
   

接続に成功すると、以下のようにデータベースの一覧が参照できます。
WSUS のデータベースである SUSDB が表示されていることが確認できますね。

それでは、ぜひ素敵な WSUS ライフをお過ごしください！
Enjoy WSUS!!!

.NET Framework 3.5 を有効にするその他の方法
Windows Server 2012 / Windows Server 2012 R2 で .NET Framework 3.5 の機能を有効にする方法は、役割と機能の追加 ウィザードを使用する以外にも、いくつかの方法があります。
インターネット接続がないオフライン環境では、代替ソース パスに OS のインストール メディアを使用して機能を有効化することもできます。
詳しくは、以下の記事をご参照ください。

  Windows 8 または Windows Server 2012 へ .NET Framework 3.5 をインストールする方法
  http://blogs.technet.com/b/askcorejp/archive/2012/12/11/windows-8-windows-server-2012-net-framework-3-5.aspx

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

今回は「WSUS 自動承認規則が反映されない事象」についてご紹介します。

「自動承認を有効としているにも関わらず、自動でインストール承認が行われない更新プログラムが存在する」というお問い合わせをいただくことがあります。自動承認規則にて作成された規則が反映されない更新プログラムは、End User License Agreement (EULA)が付与された更新プログラムであることが主な理由です。このような更新プログラムは、WSUS 管理者の手動での明示的なインストール承認処理を必要とし、自動承認処理を行うことはできません。

EULA が付与された更新プログラムであるかどうかは、WSUS 管理コンソールの追加情報 (赤枠) から確認することができます。

＜EULA ありの更新プログラム＞

＜EULA なしの更新プログラム＞

また、更新プログラムのインストール承認時に以下のようなダイアログボックスが表示された場合には、EULA の同意操作を必要とする更新プログラムであることがわかります。

もし、自動承認規則が有効になっているにもかかわらず、インストール承認が行われない更新プログラムが存在する場合は、上記の内容をもとに、EULA の有無を確認し、手動による更新プログラムのインストール承認処理を行ってください。

＊参考情報＊

WSUS 3.0 SP 2 の配信について

http://blogs.technet.com/b/jpwsus/archive/2009/08/25/wsus-3-0-sp-2.aspx

B.   End User License Agreement (EULA) について

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

本ポストでは、Microsoft Baseline Security Analyzer (MBSA) の脆弱性チェックについてご案内いたします。

MBSA （2014/9 現在最新バージョンは 2.3）で搭載する機能に脆弱性チェックがあります。

この機能は MBSA の旧バージョンより搭載されている機能ですが、ハードコード(*)された脆弱性チェックという造りからその役割を今日では終えつつある状況となります。

(*) 定義ファイルなどをベースとした日々チェック項目が更新されるのではなく、

予め決められた項目（例えばパスワードの複雑性など）についてチェックするのみの機能となります。

現在の OS やアプリケーションに求められるセキュリティ脆弱性チェック機能としては、ハードコードされたチェックは十分とは言えず、また、後述の通り、期待通り動作しない/未サポートとなるケースが増えておりますので、MBSA をご利用いただいておりますユーザー様におかれましては、今後は MBSAは更新プログラムのスキャンツールとしてのみご利用いただくことをご提案したいと存じます。

>> 動作しない例:

Windows 8 以降のバージョンでは脆弱性チェックに対応しておりません。

また、SQL Server の脆弱性チェックにおいても、SQL Server 2005 以降のバージョンで期待通り動作しない状況となっております。

>> 参考資料：

Microsoft Baseline Security Analyzer

http://technet.microsoft.com/ja-jp/security/cc184924.aspx

マイクロソフト アカウントに関する注意: MBSA は Windows 8、およびそれ以降のバージョンのマイクロソフト アカウントに対する脆弱性評価のサポートはしておりません。

(2014/11/27 更新 - 修正完了し、解消いたしました。)
(2014/11/26 更新 - 補足情報を追記しました。)

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

Windows Server 2003 環境において、Microsoft Update 実行時に 0x80248015 エラーが発生する、というお問い合わせを多く頂いております。

本事象につきましては、現在恒久対策の確認を弊社にて行わせて頂いておりますが、ご案内までにしばらくお時間を要する見込みです。
恐れ入りますが、事象の詳細と現在判明している回避策を以下にご紹介させて頂きますので、恒久対処のご案内まで、こちらの実施をご検討くださいますようお願いいたします。
本事象につきましては、2014/11/27 に Microsoft Update サイト側の修正が完了し、現時点では解消しております。事象の詳細と解消前にご案内した回避策を以下にご紹介させていただきます。

(事象の詳細)
Windows Server 2003 環境において、[コントロール パネル] - [自動更新] から、Windows Update Web サイトをブラウザで開き、Microsoft Update へ更新プログラムの確認を実行すると 0x80248015 エラーが発生する。

(発生環境)
以下 3 点の条件を満たす環境で、本事象が発生する事を確認いたしております。

- Windows Server 2003 SP2
- Microsoft Update を有効にしている
- Microsoft Update サイトをブラウザで開き、更新プログラムの確認を実行する

なお、自動更新で更新プログラムを適用している場合は、発生いたしません。

(原因)
Microsoft Update サイトに問題があったため、修正いたしました。

(回避策)
以下を回避策としてご検討くださいますようお願いいたします。

1. [コントロール パネル] – [自動更新] を開き、[更新を通知するのみで、自動的なダウンロードまたはインストールを実行しない] を選択して、[OK] をクリックします。
2. コマンド プロンプトより、wuauclt /detectnow コマンドを実行します。
3. 時間が経過した後、右下に「更新の準備が出来ました。」のバルーンが通知されますので、バルーンをクリックします。

4. 適用したい任意の更新プログラムを選択して、[ダウンロード] をクリックします。
5. 「更新の非表示」ダイアログが表示された場合は、任意でチェック ボックスをオンにして [OK] をクリックします。
6. ダウンロード完了後、再度右下に「更新の準備が出来ました。」のバルーンが通知されますので、バルーンをクリックします。

7. 「高速インストール」もしくは「カスタム インストール」を選択して、インストールを行います。(カスタム インストールの場合は、インストールする更新プログラムを選択することができます。)
8. インストール完了後、再起動が求められる場合がありますので、準備が整い次第再起動を行います。
9. 必要に応じて、コントロール パネルより自動更新を無効にします。

<補足情報>
本回避策は、自動更新を利用して更新プログラムの確認を行う手順となりますので、プロキシ サーバーをご利用の場合は WinHTTP のプロキシ設定を適切に設定していただく必要がございます。
Windows Server 2003 の場合は、proxycfg コマンドを利用して指定することができます。プロキシ設定方法の詳細な手順は以下の KB 情報に記載しておりますので、必要に応じてご確認くださいますようお願い申し上げます。(Internet Explorer のプロキシ設定にて、pac ファイルをご利用の場合は、proxycfg -u コマンドでは WinHTTP のプロキシ設定に反映されません。その場合は、proxycfg -p コマンドを利用してプロキシ サーバーを指定してください。)

プロキシ サーバーを使用する環境にて Windows Update を実行すると通信エラーが発生する
http://support.microsoft.com/kb/2894304

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

今回は、WSUS においてよくある「更新プログラムの検出処理ができない」「更新プログラムのダウンロード処理ができない」「更新プログラムが期待通りにインストール出来ない」場合に、まず実施いただきたい対処方法をご案内します。

ご案内する手順については、エラーや発生事象別に原因を特定して対応するということを目的としたものではなく、とりあえずうまく動かない状況に直面したらまずはこれをやってみよう、ということを目的としたものになります。
WSUS による更新プログラムの配信を行っている場合、まずはエラーが発生した原因の追究より、更新プログラムのインストールをいち早く完了させたい、という状況に直面することもあるのではないでしょうか。
またユーザーが使用する PC のため、何度も対処策を実施するのが難しいという状況もあるかと思います。そのような場合、まず回避優先の対処が求められます。

今回の一連の手順では、Windows Update クライアント側の情報をクリアにすることで、クライアント側に残存しているダウンロード ジョブなどに起因した問題かや Windows Update 情報の不整合があるかどうかを切り分けるために有効な手順となります。当サポート部門に寄せられた多くのお問い合わせでご案内した実績のある手順であり、クライアント側に起因した問題であるかどうかの有効な切り分け方法となります。

但し、注意事項としましては、以下のような影響がございますので、十分ご理解いただいた上で本手順の実施をお願いいたします。

・[更新履歴の表示] の情報がクリアされます。(作業履歴の情報ですので 現時点の適用状態や今後の適用動作には全く影響ありません)
・過去クライアント側の操作によって「非表示」設定（処理対象から除外）していた更新プログラムが存在する場合は、その設定が解除されます。

～ 参考情報 ～
Windows Update の "更新履歴の表示" が示す内容について
http://blogs.technet.com/b/jpwsus/archive/2013/08/22/windows-update-quot-quot.aspx

SoftwareDistribution フォルダーのリセットと BITS ジョブのクリア

以下ステップを順にご実施ください。

a) 自動更新サービスと BITS サービスの停止
b) SoftwareDistribution フォルダーのリネーム
c) BITS のジョブを削除
d) 自動更新サービスと BITS サービスの開始
e) 更新プログラム検出の確認

各手順の詳細は以下の通りです。

a) 自動更新サービスと BITS サービスの停止
コマンド プロンプトから以下のコマンドを実行します。
または、サービス マネージャから [自動更新] または [Automatic Updates] サービスと [Background Intelligent Transfer Services] サービスを停止します。

net stop wuauserv
net stop bits

b) SoftwareDistribution フォルダーのリネーム
SoftwareDistribution フォルダーは、Windows Update に使用されます。例えば Software Distribution フォルダー配下の Download フォルダーにはダウンロードされた更新プログラムが一時的に保管されます。SoftwareDistribution フォルダーをリネームすることで、これまでダウンロードされた更新プログラムやデータベースの情報がクリアされます。
コマンド プロンプトより、以下のコマンドを実行して、更新プログラムが保存されている SoftwareDistribution フォルダーをリネームします。

ren %systemroot%\SoftwareDistribution SoftwareDistribution.old

c) BITS のジョブを削除
Windows Update は BITS という Windows の機能を利用して、アイドル中のネットワーク回線の帯域幅を使用して、バックグラウンドで更新プログラムをダウンロードします。
ダウンロードに失敗した更新プログラムが BITS キューに滞留している場合、以下のコマンドを順番に実行してキューから削除することで、新しくダウンロード ジョブが作成され、ダウンロードに成功する可能性があります。

del "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\qmgr0.dat"
del "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\qmgr1.dat"

更新プログラムがダウンロード中の場合、ダウンロードを中止するために実施します。この作業はダウンロード中ではない場合でも実施することを推奨いたします。

d) 自動更新サービスとBITS サービスの開始
コマンド プロンプトから以下のコマンドを実行します。
または、サービス マネージャから [自動更新] または [Automatic Updates] サービスと [Background Intelligent Transfer Services] サービスを開始します。

net start bits
net start wuauserv

e) 更新プログラム検出の確認
上記の手順を実施後、以下のコマンドを実行して、更新プログラムの検出を実施します。

wuauclt /resetauthorization /detectnow

または、コントロール パネルの Windows Update の UI から [更新プログラムの確認] をクリックします。

約 5 ～ 10 分ほど待ち、更新プログラムのダウンロードおよびインストールが実施できるかどうかを確認します。

手順は以上となります。

※本件は、Visual Studio サポートチームのブログの転載となります。

2014 年 12 月 10 日に公開され、Windows Update で配信された Visual Studio 2012 対象の KB3002339 の更新プログラムをインストールすると、Windows Update が完了しない、システム再起動時に更新が完了せずシステムがハングアップしてしまうという現象が発生することを確認いたしました。

KB3002339

https://support.microsoft.com/kb/3002339/

本問題の報告を受け、Windows Update の配信は既に停止いたしましたが、Windows Server Update Services (WSUS) を使用して更新プログラムを配信されているお客様におかれましては、本更新プログラムの配信を停止していただけますようお願い申し上げます。

既に本更新プログラムを適用し、ハングアップなどの現象が発生している環境での復旧方法につきましては、現在調査中です。進展があり次第、Visual Studio チーム記事にて情報公開させていただきます。最新の内容は下記 Visual Studio チームブログをご覧ください。

Visual Studio サポートチームブログ

[ご注意ください] 12 月 10 日にWindows Update で配信された Visual Studio 2012 対象の更新プログラム KB3002339 をインストールするとシステムのハングアップなどの問題が発生する

http://blogs.msdn.com/b/jpvsblog/archive/2014/12/10/12-10-windows-update-visual-studio-2012-kb3002339.aspx

お客様には多大なご迷惑をおかけしておりますこと、深くお詫び申し上げます。

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

今回は「WSUS 管理コンソール上でオペレーティング システム名が正しく表示されない事象」についてご紹介します。

「WSUS の管理コンソール上のオペレーティング システム項目に、実際の OS 名と異なる名称が表示される」というお問い合わせをいただくことがあります。これは WSUS における不具合で、 WSUS が該当製品の OS 名を正しく取得できていないことが原因です。なお、この事象は WSUS の管理コンソールの表示上の問題であり、その他の機能への影響はありません。

また、本件は Windows Server 2012 R2 の WSUS では修正済みの事象です。

例として、WSUS 3.0 SP2 で Windows Storage Server 2012 クライアントを管理する場合は、管理コンソールのオペレーティング システム項目において Windows Storage Server 2003 と表示されます。

下表が現在事象の発生を確認しているクライアントです。

- 対処方法

Windows Server 2012 R2 クライアントについては、WSUS サーバーに KB2734608 または KB2828185 を適用することで、正しく OS 名が表示されます。

Windows 8.1 および Windows Storage Server 2012 のクライアントについては、WSUS 3.0 SP2 においては残念ながら現時点での対処方法はありません。

なお、Windows Server 2012 以降の WSUS サーバーをご利用いただくことで、すべて正しく表示されます。

※ ただし、Windows Server 2012 R2 の WSUS において、Windows Storage Sever は Windows Server の Stock Keeping Unit (SKU) の一つとして扱われるため、Windows Storage Server 2012 R2 は Windows Server 2012 R2 と表示されます。

<補足情報>

各更新プログラムの詳細な内容については以下で確認できます。

[Windows Server Update Services 3.0 Service Pack 2 用更新プログラム (KB2734608) をご利用いただけます。]

http://support.microsoft.com/kb/2734608/ja

[Windows Server Update Services 3.0 SP2 用の更新プログラムが利用可能 (KB2828185)]

http://support.microsoft.com/kb/2828185/ja

こんにちは。WSUS サポートチームです。
 
今回は、WSUS をご利用いただく環境において、クライアントに対し必須構成となる下記の 2 つのグループ ポリシーについてご紹介します。WSUS クライアントのグループ ポリシーを構成する際に、参考にしてみてください。
 
-------------------------------------------------------------------------------------------
1. [イントラネットの Microsoft 更新サービスの場所を指定する]
2. [自動更新を構成する]
-------------------------------------------------------------------------------------------
 
※ 今回ご案内する  WSUS や Windows Update に関連するポリシーは、グループ ポリシー エディターの [コンピューターの構成] – [管理用テンプレート] – [Windows コンポーネント] – [Windows Update] 配下に配置されています。
 
なお、Windows 8 / Windows Server 2012 以降の OS にてグループ ポリシーを設定する場合の注意点につきまして、下記の記事にて紹介しております。Windows 8 / Windows Server 2012 以降の OS にてグループ ポリシーを設定される場合には、併せて下記の記事も参照してください。
 
・ WSUS クライアントのグループ ポリシー : その 2 - Windows 8 / Windows Server 2012 以降編
http://blogs.technet.com/b/jpwsus/archive/2015/03/24/wsus-2-windows-8-windows-server-2012.aspx

  
< 1. [イントラネットの Microsoft 更新サービスの場所を指定する] >
 

 
設定例 : WSUS サーバーから更新プログラムの配信を行う場合
-------------------------------------------------------------------------------------------
◆ 設定値 : [有効]
◆ オプション :
 - 更新を検出するためのイントラネットの更新サービスを設定する : [<WSUS サーバーの URL>] ※
 - イントラネット統計サーバーの設定 : [<WSUS サーバーの URL>] ※
-------------------------------------------------------------------------------------------
※ Windows Server 2012 以降の WSUS では、既定で利用されるポート番号が 80、443 から 8530、8531 に変更されています。URL を指定する際はポート番号も併せて指定してください。
 
[ポリシーの説明]
このグループ ポリシーを有効にすることで、クライアントが接続を行うサーバーをWindows Update / Microsoft Update のサーバーから、WSUS サーバーへ変更出来ます。
 
このため、WSUS サーバーをご利用いただく際には、必ずこのグループ ポリシーを “有効” に設定し、オプションの 2 箇所共に同じWSUS サーバーの URL を指定してください。
 
 
<2. [自動更新を構成する]>
 

 
設定例 : 新たな更新プログラムの配信された場合は、自動ダウンロードしインストールを 3:00 に自動実行する場合
-------------------------------------------------------------------------------------------
◆ 設定値 : [有効]
◆ オプション :
 - 自動更新の構成 : [4 – 自動ダウンロードしインストール日時を指定]
 - 自動メンテナンス時にインストールする : [無効] ※
 - インストールを実行する日 : [0 – 毎日]
 - インストールを実行する時間 : [03:00]
-------------------------------------------------------------------------------------------
※ Windows 7 / Windows Server 2008 R2 以前の環境ではこの設定はありません。詳細は「WSUS をご利用いただく上で、よくご設定いただくグループ ポリシー : その 2 - Windows 8 / Windows Server 2012 以降編」を参照ください。
 
[ポリシーの説明]
このグループ ポリシーは、WSUS を利用する上で必須の設定ではありませんが、有効にすることで、更新プログラムのインストール処理を、自動実行することが出来る非常に便利なグループ ポリシーです。是非併せて設定いただくことをご検討ください。
 
また、このグループ ポリシーのオプションにて、具体的に更新プログラムのインストール処理を「どの処理まで」自動的に実行させるかも、細かく制御することが出来ます。
 
上述のオプションによって、Windows Update の動作がどのように制御出来るのか、正しく理解するために、まずは手動で Windows Update が実行された際にクライアント内でどのような処理が行われるのか、以下に説明します。
 
 
- Windows Update の処理の実行順序
Windows Update が手動で実行されると、クライアント内にて、下記の順番に処理が行われます。
 
A. 更新プログラムの検出
⇒ クライアントに新たに適用が必要な更新プログラムがあるかどうかの確認処理
B. 更新プログラムのダウンロード
⇒ 「A」にて検出された更新プログラムのダウンロード処理
C. 更新プログラムのインストール
⇒ 「B」にてダウンロードされた更新プログラムのインストール処理
 
なお、上記の順番は、WSUS の設定に関係なく、Windows Update / Microsoft Update サイトに対して更新プログラムの確認を行うよう設定していても、同様の順番に処理されます。
 
 
- “自動更新の構成” オプションの設定
では上記の動作を踏まえ、実際に “自動更新の構成” にて、どのように Windows Update の動作を制御出来るのかご説明します。“自動更新の構成” では、上述の A ～ C の「どの処理まで」自動的に実行するのか設定することが出来ます。具体的には、各設定を行うと下記のように Windows Update の動作が自動実行されます。
 
・ [2 – ダウンロードとインストールを通知] :
⇒  A の処理は自動実行、B 以降の処理は手動実行
・ [3 – 自動ダウンロードとインストールを通知]
⇒  B までの処理は自動実行、C 以降の処理は手動実行
・ [4 – 自動ダウンロードしインストール日時を指定]
⇒  A ～ C すべての処理を自動実行、C の処理は指定した日時に実行し、再起動を実行
・ [5 – ローカルの管理者の設定選択を許可]
⇒  クライアントのコントロール パネルにて、それぞれ設定することを許可
 
例えば、「ユーザーに操作させることなく Windows Update を自動実行したい」場合には、上記の [4] 番の設定を行うと、指定した日時に Windows Update のすべての処理が自動実行されます。逆に「ユーザーが意図しないタイミングで、Windows Update の処理が自動実行されたら困る」場合には、このグループ ポリシー自体を無効に設定すると、A ～ C の処理いずれも自動実行されないようになります。
 
このように環境に併せて、細かく Windows Update の制御が出来るグループ ポリシーですので、ぜひ積極的にご活用ください。
 
 
<補足 : クライアントがドメインに参加していない場合>
もちろん、ドメインに参加していないクライアントでも、ローカル グループ ポリシーやグループ ポリシーに対応するレジストリ値を変更することで、同様に WSUS をご利用いただけますので、是非ご参考にしてください。
 
なお、グループポリシーの各項目とレジストリの値の対応関係につきましては、英語情報のみにて恐縮ですが、以下の公開情報がございますのでご紹介します。
 
WSUS 3.0 SP2 の展開ガイド
" Configure Clients in a Non-Active Directory Environment"
http://technet.microsoft.com/ja-jp/library/dd939844(v=ws.10).aspx

 
なお、下記の日本語版はすでにサポートを終了した前製品：WSUS 2.0 の情報ですが、多くの部分は WSUS 3.0 SP2 にも該当しますので、ご参考までに付記します。
 
WSUS 2.0 の展開ガイド
"Active Directory 以外の環境で自動更新を構成する"
http://technet.microsoft.com/ja-jp/library/cc708449(v=ws.10).aspx

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

前回の投稿では、WSUS をご利用いただく環境において、クライアントに対し必須構成となるポリシーのご紹介をしました。本ブログでは、Windows 8 / Windows Server 2012 以降の OS にて、Windows Update に関する構成可能なポリシーや注意点をご紹介します。

【Windows 8 / Windows Server 2012 以降の環境での注意点】
Windows 8 / Windows Server 2012 以降の環境では、Windows 7 / Windows Server 2008 R2 以前の環境と、自動更新の動作が一部異なりますので、両方共に環境を管理している場合には、特に注意が必要です。

Windows 8 / Windows Server 2012 以降の環境では、Windows 7 / Windows Server 2008 R2 以前と同様の動作を実現するためには、新たに追加された、下記の 3 つのグループ ポリシーを併せて設定することをご検討ください。

【Windows Update に関する ポリシー】
-------------------------------------------------------------------------------------------
1. [自動更新を構成する] – [自動メンテナンス時にインストールする] ※1
2. [スケジュールされた時刻に常に自動的に再起動する] ※1
3. [インターネット上の Windows Update に接続しない] ※2
-------------------------------------------------------------------------------------------
※1 Windows 8 / Windows Server 2012 の環境で、このグループ ポリシーを設定するには KB2883201もしくは KB3013767を適用する必要があります。Windows 8.1 / Windows Server 2012 R2 以降の環境では、本更新プログラムの適用は必要ありません。
※2 Windows 8 / Windows Server 2012 の環境で、このグループ ポリシーを設定するには KB3013767を適用する必要があります。Windows 8.1 / Windows Server 2012 R2 以降の環境では、更新プログラムの適用は必要ありません。

各グループ ポリシーの詳細について、以下にご案内いたします。

< 1. [自動更新を構成する] – [自動メンテナンス時にインストールする] >

設定例 : Windows 7 / Windows Server 2008 R2 以前の環境と同様の動作をさせる場合
-------------------------------------------------------------------------------------------
◆ 設定値 : [有効]
◆ オプション :
- 自動メンテナンス時にインストールする : [無効]
-------------------------------------------------------------------------------------------

[ポリシーの説明]
※ Windows 8 / Windows Server 2012 の環境で、このグループ ポリシーを設定するには KB2883201もしくは KB3013767を適用する必要があります。

以下の記事でもご紹介している通り、Windows 8 / Windows Server 2012 以降の環境からは、自動更新のオプション [4] 番の動作が大きく異なっており、自動インストールの開始タイミングが OS の自動メンテナンス タスクとして制御されるよう、設計が変わっています。

Windows 8 / Windows Server 2012 では 「自動インストール」 の動作が変更されております
http://blogs.technet.com/b/jpwsus/archive/2013/08/14/windows-8-windows-server-2012-4.aspx

このため、自動更新のオプションにて日時を指定している場合でも、自動更新のオプション [4] 番だと、時刻が固定されていない「Idle Maintenance」タスクの一環としてインストール動作が開始されてしまうおそれがあります。

これを、Windows 7 / Windows Server 2008 R2 以前の環境と同様に、指定した日時に必ず更新プログラムのインストールを行うようにするには、上述のオプション “自動メンテナンス時にインストールする” を [無効] に設定してください。

< 2. [スケジュールされた時刻に常に自動的に再起動する] >

設定例 : Windows 7 / Windows Server 2008 R2 以前の環境と同様の動作をさせる場合
-------------------------------------------------------------------------------------------
◆ 設定値 : [有効]
◆ オプション :
- 作業内容の保存にかかる時間（分） : [15]
-------------------------------------------------------------------------------------------

[ポリシーの説明]
※ Windows 8 / Windows Server 2012 の環境で、このグループ ポリシーを設定するには KB2883201もしくは KB3013767を適用する必要があります。

Windows 8 / Windows Server 2012 以降の環境からは、自動更新のオプション [4] 番にて、自動インストールが実行された後の、再起動が実行されるタイミングにも変更が加えられています。

Windows 8 / Windows Server 2012 以降の環境では、ユーザーがログオンしている際に更新プログラムの自動インストールが行われると、すぐに再起動は実施されず 3 日間の猶予期間が設けられるよう変更されています。

このため、Windows 7 / Windows Server 2008 R2 以前の環境と同様に、自動インストールが実行された後に、即時に再起動を実行するには、このグループ ポリシー [有効] に設定してください。

このグループ ポリシーを [有効] に設定すると、自動インストールが完了した後、オプションにて指定した時間が経過すると、必ず再起動が実施されます。

< 3. [インターネット上の Windows Update に接続しない] >

設定例 : Windows 7 / Windows Server 2008 R2 以前の環境と同様の動作をさせる場合
-------------------------------------------------------------------------------------------
◆ 設定値 : [有効]
-------------------------------------------------------------------------------------------

[ポリシーの説明]
※ Windows 8 / Windows Server 2012 の環境で、このグループ ポリシーを設定するには、KB3013767を適用する必要があります。Windows 8.1 / Windows Server 2012 R2 以降の環境では、更新プログラムの適用は必要ありません。

Windows 8 / Windows Server 2012 以降の環境からは、、WSUS サーバーに対して更新プログラムをチェックするように構成していても、WUA（Windows Update Agent） 自身の更新のために、弊社サイトにアクセスするよう動作が変更されています。

これは Windows 8 / Windows Server 2012 以降の環境では Windows ストア アプリのサポートが追加されているためです。WSUS サーバーに対して更新プログラムをチェックするように構成していても、
ストア アプリの更新は WUA の機能を使用するため、弊社サイトに自己更新のためにアクセスする動作が発生するよう変更が加えられています。

上記の動作を無効にし、Windows 7 / Windows Server 2008 R2 以前の環境と同様の動作をさせる場合には、このグループ ポリシーを [有効] に設定してください。

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

本記事では、最近お問い合わせの増えている「更新プログラムの検出処理時、WSUS クライアントの CPU 使用率が高くなる現象」についてご案内いたします。

本記事は、以下過去記事と関連する内容です。

Windows XP や Windows Server 2003 環境において、Windows Update 実行時に Svchost.exe の CPU 使用率が 100 % となる、時間を大幅に要する
http://blogs.technet.com/b/jpwsus/archive/2013/10/18/windows-xp-windows-server-2003-windows-update-svchost-exe-cpu-100.aspx


（事象の概要）
「IE の累積的なセキュリティ更新プログラム」が WSUS サーバー上で承認されていると、WSUS サーバーへの更新プログラムの検出実行時に、WSUS クライアント側の CPU 使用率が高負荷状態となります。

WSUS クライアントは、WSUS サーバーにて承認されている更新プログラムの置き換え関係を過去に遡って参照しますが、このときリリース年数が長いと、評価対象となる情報量も多くなるため、スキャン処理に負荷を要する事象が発生しやすくなります。
更新プログラムの検出処理実行時に、WSUS クライアントの CPU 使用率が上昇すること自体は Windows Update の処理として想定された動作ですが、CPU 使用率 100％ に達する状況が数十分以上続くなど、著しい負荷増が確認される場合、本事象に該当している可能性が考えられます。

なお、上述の過去記事でもご案内している通り、弊社では本問題の恒久対処策として、数年前に公開させて頂いた古い「Internet Explorer の累積的なセキュリティ更新プログラム」を期限切れ（公開停止）とする対処を実施させていただきました。
WSUS をご利用いただいている環境でも、既定のオプション設定では、期限切れの更新プログラムは自動的に置き換え参照時の評価対象となくなる「拒否済み」に設定されます。このため、期限切れの古い「Internet Explorer の累積的なセキュリティ更新プログラム」が自動的に「拒否済み」に設定され、本事象を予防出来ます。
しかしながら、WSUS のオプション設定を既定から変更している場合には、期限切れの古い「Internet Explorer の累積的なセキュリティ更新プログラム」が自動的に「拒否済み」に設定されず、置き換え参照時の評価対象となってしまうため、本事象が発生し易くなります。


（発生環境）
以下の環境では、本事象が発生しやすい状況となります。

-    WSUS クライアントのマシン スペックが低い環境
-    WSUS サーバーにて、リビジョン動作に関連する以下のオプション設定が無効

-----------------------------------
オプション [自動承認] - [詳細]
「更新プログラムの改訂版」：
「承認済み更新プログラムの新しいリビジョンを自動的に承認する」- オフ（既定値 オン）
「新しいリビジョンにより期限切れとなった更新プログラムを自動的に拒否する」- オフ（既定値 オン）
-----------------------------------


（発生要因）
Windows Update による内部的なスキャン処理の実行時には、WSUS にて承認されている更新プログラムの置き換え関係を過去に遡って参照しますが、その置き換え評価対象の更新プログラムの数が、スキャン処理の負荷および時間に影響を及ぼします。
置き換え関係を保有する更新プログラム中、特に注意すべきものは累積型の更新プログラムです。累積型の更新プログラムは、新しいプログラムがリリースされると、過去にリリースされたすべての累積プログラムに対して置き換え関係を保つ必要があります。累積プログラムのリリース数が増えれば増えるほど、置き換え対象となる更新プログラムの数は増えていき、それに伴いスキャン処理の負荷も増大します。

累積型の更新プログラムの中でも、もっともリリース頻度が高いのが「IE の累積的なセキュリティ更新プログラム」です。「IE の累積的なセキュリティ更新プログラム」は、ほぼ月次でリリースされるため、古いバージョンほど、毎回の置き換え対象が多くなり、高負荷の原因となります。

なお、上述の通り、本事象の根本的な要因は、承認されている更新プログラムの置き換え関係を過去に遡って参照された際に、評価対象となる情報量も多くなり、スキャン処理に負荷を要するということです。このため、「IE の累積的なセキュリティ更新プログラム」以外の更新プログラムでも、置き換え関係を多量に保有している更新プログラムでは同様の事象が発生し得ます。


（対処）
--------------------------------------------------------------------------
A. 過去の「IE の累積的なセキュリティ更新プログラム」を WSUS 上で拒否済みに設定
B. 最新の「IE の累積的なセキュリティ更新プログラム」が置き換える更新プログラムを WSUS 上で拒否済みに設定
C. 最新の「IE の累積的なセキュリティ更新プログラム」を問題の発生する端末に手動適用
--------------------------------------------------------------------------

WSUS サーバー側にて「A」および「B」の対処を実施します。

最新の「IE の累積的なセキュリティ更新プログラム」のみを承認し、不要なものを「拒否済み」に設定することで、置き換え参照時の評価対象となる更新プログラムを減らします。

WSUS サーバー側での対処を行えない場合は、「C」の回避策を検討します。

=================================================================
A. 過去の「IE の累積的なセキュリティ更新プログラム」を WSUS 上で拒否済みに設定
=================================================================
最新の「IE の累積的なセキュリティ更新プログラム」は、「累積的」に過去の更新プログラムを包含しているため、最新の更新プログラムのみインストールを行えば過去の更新プログラムによる修正も適用される動作となります。最新のみ承認しておけば、古いものはすべて拒否済みに設定して問題ありません。

下記手順にて、過去の「IE の累積的なセキュリティ更新プログラム」を拒否済みに設定します。

1. WSUS 管理コンソールを起動し、[Update Services] – [<サーバー名>] – [更新] に移動します。
2. メニューバーから [操作] – [検索] の順に選択します。
3. 検索画面が表示されますので、"Internet Explorer" と入力して [検索] をクリックします。
4. 検索結果が表示されますので、拒否に設定する「IE の累積的なセキュリティ更新プログラム」を Shift キーを押下しながら複数一括選択します。
   （同時に拒否済みとする件数は、WSUS の負荷状況に応じて調整します。）
5. 選択した当該更新プログラム上で右クリックし、[拒否] を選択します。
6. メッセージが表示されますので [はい] を選択します。



=================================================================
B. 最新の「IE の累積的なセキュリティ更新プログラム」が置き換える更新プログラムを WSUS 上で拒否済みに設定
=================================================================
「A」の対処を実施しても事象が改善されない場合、更に累積的なセキュリティ更新プログラム "以外" の更新プログラムについても拒否済みに設定します。

下記手順にて、最新の「IE の累積的なセキュリティ更新プログラム」が置き換える更新プログラムを確認して拒否済みに設定します。

1. Microsoft Update カタログ サイトに接続します。

Microsoft Update カタログ
http://catalog.update.microsoft.com/v7/site/home.aspx

2. 画面右に表示されているテキストボックスに、最新の「IE の累積的なセキュリティ更新プログラム」の KB 番号を入力して、[検索] をクリックします。
3. 表示された更新プログラムの一覧から、問題が発生している クライアントの OS  と IE のバージョンに対応するものをクリックします。
4. 追加で表示された画面から、[パッケージの詳細] タブを表示します。
   [この更新プログラムは、次の更新プログラムを置き換えます] に表示されている更新プログラムが、検索した累積的な更新プログラムが置き換えている更新プログラムとなります。
   WSUS サーバー上で拒否済みの設定を行う対象となりますので控えておきます。
5. 「A」と同様の手順にて、設定対象の更新プログラムを拒否済みに設定します。

<対処 「A」,「B」 の注意点>
対処 「A」,「B」 を行うと、置き換え参照時の評価対象となる更新プログラムが減るために現象は改善します。しかしながら、長期的に運用を続けるうちに「累積的な更新プログラム」のリリース状況と時間の経過に伴って、現象が再現することは見込まれます。対処「A」,「B」を定期的に実行するか、後述の（事象再発を防ぐための予防策）を検討します。

=================================================================
C. 最新の「IE の累積的なセキュリティ更新プログラム」を問題の発生する端末に手動適用
=================================================================
対処 「A」,「B」 の WSUS サーバー上の設定が困難な場合は、現時点で最新の「IE の累積的なセキュリティ更新プログラム」を問題端末に手動適用することでも回避可能です。

最新の 「IE の累積的なセキュリティ更新プログラム」は、以下よりダウンロード可能です。

Microsoft Update カタログ
http://catalog.update.microsoft.com/v7/site/home.aspx

<対処 「C」 の注意点>
手動適用した最新版以降にリリースされた「IE の累積的なセキュリティ更新プログラム」の承認を行うと、WSUS クライアントは再度スキャン時に置換関係の評価を行うことになるため、比較的短期間での事象の再発が予測されます。


（事象再発を防ぐための予防策）
長期的な対処として、対処「A」,「B」,「C」のいずれかを定期的に実施する方法もございますが、どれも手動での対処が必要となってしまいます。
下記のいずれかの予防策を実施いただくと、今後の事象の再発を予防出来る可能性がございます。長期的な対処を考慮する場合には、下記のいずれかの予防策を実施することをご検討ください。

--------------------------------------------------------------------------
a. WSUS のオプション設定を変更する
b. クリーンアップ ウィザードの「期限切れの更新」を定期的に実行する
--------------------------------------------------------------------------

=================================================================
a. WSUS のオプション設定を変更する
=================================================================
既存の更新プログラムのリビジョン動作に関連する WSUS サーバーのオプション設定は以下となります。

-----------------------------------
オプション [自動承認] - [詳細]
「更新プログラムの改訂版」：
「承認済み更新プログラムの新しいリビジョンを自動的に承認する」- 既定値はオン
「新しいリビジョンにより期限切れとなった更新プログラムを自動的に拒否する」- 既定値はオン
-----------------------------------

 

本オプションを有効にすれば、古い「Internet Explorer の累積的なセキュリティ更新プログラム」が「期限切れ」として着信すると、対象の更新プログラムは自動的に拒否済みステータスへ変化する動作となります。この場合、管理者による手動作業の必要はありません。

ただし、本オプションを有効にすると、更新プログラムの新しいリビジョンが WSUS に着信した場合、古いリビジョンが承認されていれば、自動的に新しいリビジョンがインストール承認されます。このため、本オプションを有効に設定する場合には、
意図しないタイミングでクライアントに対し、自動的に更新プログラムの新しいリビジョンが配信されてしまう可能性があることを考慮する必要があります。

なお、本オプションを無効にして運用する場合、既存の更新プログラムが「期限切れ」として着信後にも対象の更新プログラムは自動的に拒否済みのステータスにはなりません。そのため、管理者は、期限切れとなった更新プログラムを拒否済みとして手動設定する必要があります。

本オプションによる動作の違いの詳細については以下の記事をご参考ください。

「リビジョン（改訂版）」について
http://blogs.technet.com/b/jpwsus/archive/2011/10/31/3462305.aspx

=================================================================
b. クリーンアップ ウィザードの「期限切れの更新」を定期的に実行する
=================================================================
クリーンアップ ウィザードの「期限切れの更新」を実行することでも、「期限切れ」の古い「Internet Explorer の累積的なセキュリティ更新プログラム」を拒否済みとしていただけます。このため、クリーンアップ ウィザードの「期限切れの更新」を定期的に実行することで、事象を予防することができます。
クリーンアップ ウィザードについては、以下の記事をご参照ください。

更新プログラムのクリーンアップについて
http://blogs.technet.com/b/jpwsus/archive/2010/02/18/3313610.aspx

また、クリーンアップ ウィザードは PowerShell スクリプトから実行することも出来るため、タスク スケジューラーから自動実行させることが可能です。クリーンアップ ウィザードを実行する PowerShell スクリプトは、下記を参考にしてください。

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

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

本記事では、ドメイン コントローラ上での WSUS サーバーの稼動についてご紹介いたします。
本記事は、以下の記事と関連する内容です。

ドメイン コントローラ上での WSUS サーバーの稼動について
http://blogs.technet.com/b/jpwsus/archive/2010/05/07/wsus.aspx

（概要）

Windows Server 2012 以降の環境においても、ドメイン コントローラーと WSUS サーバーを同一筐体に構築することはサポートされています。しかし、上記構成では意図しないトラブルが発生する可能性があるため、推奨はしておりません。上記ブログ記事にて説明されている WSUS 3.0 までのバージョンと同様のサポート方針となります。

本記事では、Windows Server 2012 以降の WSUS 環境での代表的な問題とその対処をご紹介します。

========================
WSUS の役割追加に失敗する
========================

（事象の概要）

WSUS のデータベースに Windows Internal Database (WID) を選択した場合、ドメイン コントローラー構築後に WSUS の役割追加に失敗し、システムの再起動が求められることがあります。

（発生要因）

ドメイン コントローラーの構築に伴って設定される [サービスとしてログオン] のポリシーの制限によって、WID のサービスがサービスとしてログオンすることが許可されず、サービス起動に失敗することが原因となります。

--------------------------------------------------------
[コンピューターの構成]
- [ポリシー]
- [Windows の設定]
- [セキュリティの設定]
- [ローカル ポリシー]
- [ユーザー権利の割り当て]
    -> [サービスとしてログオン]のポリシー
--------------------------------------------------------

本要因により、WID のサービス起動に失敗すると、WSUS の役割追加自体が失敗となり、システムの再起動が求められる動作となります。

～ 参考情報 ～

下記公開情報は、ADFS の役割追加時の事象の紹介となりますが、類似した事象となります。

"MSSQL$MICROSOFT##WID service was unable to log on as NT SERVICE\MSSQL$MICROSOFT##WID" error when you install WID in Windows Server 2012
http://support.microsoft.com/kb/2832204/en-us

（対処）

本事象が発生した場合は、インストールが失敗し、システムの再起動を実行する前に、上記のグループ ポリシー [サービスとしてログオン] のポリシーに、WID のサービス アカウント「NT SERVICE\MSSQL$MICROSOFT##WID」を追加して再起動を行い、WSUS の役割を再度追加すると成功します。

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

Windows Update をお使いの環境でエラーコード：0x80080005 が表示されるとのご相談をいただくことがあります。

本エラー メッセージは Access is denied.：ファイルやレジストリのアクセス拒否が発生したことを意味しますが、純粋に Windows Update の機能が破損している場合以外に、以下のレジストリの設定値に起因する場合があります。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control 

名前: RegistrySizeLimit

種類: REG_DWORD

Windows 7 を含む、Windows XP / Windows Server 2003 以降の環境の場合、既定では RegistrySizeLimit のレジストリは設定されておりませんので、本レジストリの影響で 0x80080005 エラーが発生している可能性があります。

もし Windows Update 中に本エラー コード : 0x80080005 が発生した場合は、後述の手順をお試しください。

<重要>

レジストリを誤って変更すると、深刻な問題が発生することがあります。最悪の場合、オペレーティング システムの再インストールが必要になることがありますので、以下を参考に手順実施前にレジストリのバックアップを必ず取得してください。

■ レジストリをバックアップする

http://windows.microsoft.com/ja-jp/windows/back-up-registry#1TC=windows-7

- RegistrySizeLimit レジストリの確認手順

=========================================

1. 問題が発生しているコンピューターに管理者権限でログインします。

2. [スタート] - [すべてのプログラム] - [アクセサリ] の順に選択し、[ファイル名を指定して実行] を起動します。

3. regedit と入力し、[レジストリ エディター] を起動します。

4. 以下のレジストリが存在するかどうかを確認します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

名前: RegistrySizeLimit

種類: REG_DWORD

5. レジストリが存在する場合には、RegistriSizelimit キーをハイライトし、右クリックします。

6. [修正] をクリックします。

7. [16 進数] にチェックを入れます。

8. 値のデータに、0xffffffff を入力します。

※ 10 進数の場合は、4294967295 を入力します。

9. [OK] をクリックします。

10. RegistriSizelimit キーの「データ」欄が以下のように表示されている事を確認します。

 0xffffffff (4294967295)

※ この値を設定する事によって、レジストリのサイズを最大に設定します。レジストリを最大に設定する事によって、システムに悪影響を及ぼす事はございませんので、ご安心下さい。

11. レジストリ エディターを閉じ、システムを再起動します。

※ 参考情報

Windows Server 2003 および Windows XP からレジストリ サイズの制限が削除されたことについて

http://support.microsoft.com/kb/292726/ja

※ 補足：

レジストリ サイズ制限 (RSL) の概要および設定について

http://support.microsoft.com/kb/124594/ja

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

Windows Server 2012 もしくは Windows Server 2012 R2 上の WSUS サーバーにおいてクリーンアップ ウィザードを実行した際に、以下のイベントが記録されて IIS のプロセスがクラッシュするという事象が報告されています。

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

ログの名前: システム

ソース: Microsoft-Windows-WAS

イベント ID: 5011

レベル: 警告

説明: アプリケーション プール 'WsusPool' に使われているプロセスでWindows プロセス アクティブ化サービスとの通信に重大なエラーが発生しました。プロセス ID は 'xxxx' でした。

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

ログの名前: アプリケーション

ソース: ASP.NET 4.0.30319.0

イベント ID: 1325

レベル: エラー

説明: ハンドルされていない例外が発生し、処理が中止されました。

Application ID: /LM/W3SVC/xxxxx/ROOT/ServerSyncWebService

Process ID: xxxx

Exception: System.NullReferenceException

Message: オブジェクト参照がオブジェクト インスタンスに設定されていません。

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

ログの名前: アプリケーション

ソース: .NET Runtime

イベント ID: 1026

レベル: エラー

説明: アプリケーション:w3wp.exe フレームワークのバージョン: v4.0.30319

説明: ハンドルされない例外のため、プロセスが中止されました。

例外情報: System.NullReferenceException

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

ログの名前: アプリケーション

ソース: Application Error

イベント ID: 1000

レベル: エラー

説明: 障害が発生しているアプリケーション名: w3wp.exe

障害が発生しているモジュール名: KERNELBASE.dl

例外コード: 0xe0434352

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

本現象は Windows Server 2012 / 2012 R2 の不具合により発生することが確認されております。

具体的には、Windows Server 2012 / 2012 R2 上で実行されている WSUS サーバーにて、[不要な更新プログラムと更新プログラムのリビジョン] のクリーンアップを実行した際に本現象が発生することがあります。

この状況に合致する場合には、以下の対処をご検討ください。

対処方法

=================================

[Windows Server 2012 R2 の場合]

Windows Server 2012 R2 においては、更新プログラム KB3000850 に本問題に対する修正が含まれております。本更新プログラムの適用をご検討ください。詳細は以下の技術情報で公開しております。

WSUS database is not cleared correctly after you run Server Cleanup Wizard on a Windows Server 2012 R2-based WSUS server

https://support.microsoft.com/en-us/kb/3000481

[Windows Server 2012 の場合]

Windows Server 2012 において、残念ながら現時点では問題に対する修正が行われておりません。この場合、[不要な更新プログラムと更新プログラムのリビジョン] のクリーンアップを分割して実行することで現象を回避できる場合があります。

WSUS コンソールのクリーンアップ ウィザードで実行する場合、[不要な更新プログラムと更新プログラムのリビジョン] はすべてまとめて処理が行われますが、これを PowerShell のスクリプトで実行することにより、不要な [更新プログラム] と [更新プログラムのリビジョン] に分割して実行することが可能です。

ベースとなる PowerShell スクリプトは以下のスクリプト センターにて公開しております。

WSUS Cleanup

https://gallery.technet.microsoft.com/ScriptCenter/fd39c7d4-05bb-4c2d-8a99-f92ca8d08218/

このスクリプトにおいて、

CompressUpdates が期限切れの [更新プログラムのリビジョン] を削除する処理、

CleanupObsoleteUpdates が期限切れの [更新プログラム] を削除する処理にあたります。

該当する処理以外をコメント アウトすることで、各処理を個別に分割して実行可能です。

以下は、CompressUpdates のみを実行する例です。

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

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")`

| out-null

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();

$cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope;

#$cleanupScope.DeclineSupersededUpdates = $true      

#$cleanupScope.DeclineExpiredUpdates         = $true

#$cleanupScope.CleanupObsoleteUpdates     = $true

$cleanupScope.CompressUpdates                  = $true

#$cleanupScope.CleanupObsoleteComputers = $true

#$cleanupScope.CleanupUnneededContentFiles = $true

$cleanupManager = $wsus.GetCleanupManager();

$cleanupManager.PerformCleanup($cleanupScope);

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

以下は、CleanupObsoleteUpdates のみを実行する例です。

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

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")`

| out-null

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();

$cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope;

#$cleanupScope.DeclineSupersededUpdates = $true      

#$cleanupScope.DeclineExpiredUpdates         = $true

#$cleanupScope.CleanupObsoleteUpdates     = $true

#$cleanupScope.CompressUpdates                  = $true

$cleanupScope.CleanupObsoleteComputers = $true

#$cleanupScope.CleanupUnneededContentFiles = $true

$cleanupManager = $wsus.GetCleanupManager();

$cleanupManager.PerformCleanup($cleanupScope);

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

- 参考情報

なお、デジタル署名のない PowerShell スクリプトをご利用になる場合には、あらかじめ実行環境を設定する必要があります。

以下の方法でスクリプトを実行する WSUS サーバーで Powershell コンソールを起動し、以下のコマンドを実行して、Powershell スクリプトの実行を許可することができます。

Set-ExecutionPolicy RemoteSigned

※ "Set-ExecutionPolicy" の詳細につきましては、コンソール上で

   "get-help Set-ExecutionPolicy -detailed" から参照可能です。

本事象が発生するという報告は非常に稀ですが、発生した際にはこれらの対処をお試しください。