こんにちは、マイクロソフトの福島です。
本日、月例公開された「悪意のあるソフトウェアの削除ツール」の日本語版タイトルが、本来「2013年4 月」となるべきところ、誤って 3 月と表記されております。( ただし英語環境では正しく April となります ) WSUS、Microsoft Update カタログ、Windows Update いずれもそのようになります。こちらの件、ただいま対応中ですので、申し訳ございませんが少々お待ちください。なお本来の３月版との判別には、リリース日や置き換え関係などの情報をご参照いただければと思います。
この問題はタイトル部の日本語表記のみで、内容については正しい 2013 年 4 月バージョンとなっており、配布・実行動作上の差し障りはございません。（ただしログ等の記録上は誤った日本語タイトルが残ってしまいますがご容赦ください）
2013/04/11 追記
本日、修正されております。まことにご迷惑をお掛けいたしました。
更新（10/31/2013）
～～～～～～～～～～
URL の一覧を公開している技術情報サイトに以下を追加いたしました。
こちらもご参照頂く必要がございますので、何卒ご注意くださいますようお願いいたします。
Step 3: Configure WSUS
http://technet.microsoft.com/en-us/library/hh852346.aspx
～～～～～～～～～～
こんにちは。マイクロソフトの三島です。
今回は、「WSUS サーバーにおける Firewall の構成方法」と、それに関連して「よくいただくご質問への回答」をご紹介します。
なお、ご紹介する構成方法は、Windows Update / Microsoft Update 環境にも適用されます。
「WSUS サーバーにおける Firewall の構成方法」
～～～～～～～～～～～～～～～～～～～～～～～
以下 2 点の通信を Firewall にて許可してください。
- 80 番ポートの HTTP 通信
- 443 番ポートの SSL (HTTPS) 通信
すべてのインターネット アドレスに対してこれらの通信を許可できない場合には、以下の 3 点の技術情報サイトに記載されているすべての URL に対して通信を許可してください。
You cannot download updates when you access the Windows Update Web site from a Windows XP-based computer that is behind a firewall or a proxy server
http://support.microsoft.com/kb/896226/en-us
(※Resolution の項目を参照ください。)
You experience problems when you access the Windows Update Version 5 Web site through a server that is running ISA Server
http://support.microsoft.com/kb/885819/en-gb
（※WORKAROUND の項目を参照ください。）
Step 3: Configure WSUS
http://technet.microsoft.com/en-us/library/hh852346.aspx
(3.1 Configure network connections の項目配下をご参照下さい。)
※注意：
通信を許可していただきたい URL のリストは、将来的に更新される可能性があります。
ご不便をおかけいたしますが、上記のサイトを定期的に、あるいは通信に問題が発生した際に、URL のリストに更新がないかを確認してくださいますようお願いいたします。
「よくいただくご質問への回答」
～～～～～～～～～～～～～～～～～～～～～～～
ご質問：
Firewall で通信を許可するため、Windows Update / Microsoft Update サイトの IP アドレスやサーバー名を教えてほしい。
回答：
Windows Update / Microsoft Update サイトの IP アドレス、サーバー名、および使用するドメイン名は、弊社サイトの運用状況に応じて不定期で変更いたします。
そのため、通信の許可を行っていただく際には、上記 2 点のサイトでご案内しております、ワイルドカード (*) を含むドメイン名の指定にて通信を許可してください。
----Update 4/24/2013 --------
MS13-036 (KB2829996) の問題を修正する更新プログラム KB2840149 を再リリースいたしました。
詳細は、以下のページをご参照ください。
KB2823324 (MS13-036) を修正する更新プログラム KB2840149 を再リリースしました
http://blogs.technet.com/b/jpwsus/archive/2013/04/24/kb2823324-ms13-036-kb2840149.aspx
-------------------------------------
こんにちは。マイクロソフトの伊藤です。
今月リリースされた MS13-036 について、適用後に一部の環境で OS が起動しなくなる問題が報告されています。
このため、Microsoft Update サイトからは MS13-036 の配信を一時的に停止しております。
WSUS にも同期のタイミングで配信停止となる予定ですが、配信サーバーが複数存在する関係上、すべての WSUS サーバーへ配信停止が行き渡るまでには時間がかかる見込みです。
もし、WSUS 管理をされていて、MS13-036 の配布を実施している場合には配布の停止をお願いします。
マイクロソフト セキュリティ情報 MS13-036 - 重要
カーネルモード ドライバーの脆弱性により、特権が昇格される (2829996)
http://technet.microsoft.com/ja-jp/security/bulletin/MS13-036
現在、対処方法について確認を進めております。
既知の問題の詳細や暫定的な対処方法については、下記の技術情報をご参照下さい。
2823324 のセキュリティ更新プログラムをインストールした後、Windows 7 で停止 0xc000000e スタートアップ エラーが表示されます。
http://support.microsoft.com/kb/2839011
You receive a Stop 0xc000000e startup error in Windows 7 after you install security update 2823324
http://support.microsoft.com/kb/2839011/en-us
早急に当該更新プログラムの削除を実施したい場合
==================
上記の KB2839011 でもご案内しておりますが、もしインストール対象の OS 上で既に MS13-036 のインストール処理が完了し、OS 再起動待ちとなっている場合には、アンインストールのコマンドを実行することで対処可能です。
具体的には KB 内の “Scenario A - Recovery steps for computers that have installed security update 2823324 but have not yet restarted” に書かれた、下記のコマンドを実行ください。
> wusa.exe /uninstall /kb:2823324 /quiet /norestart
こちらは AD のログオフ スクリプト等の手段で実施することも可能ですので、
もし AD 環境で、多数のクライアントに配布されてしまった可能性がある場合には、ログオフ スクリプトをご検討ください。
(参考情報)
一例ではありますが、シャットダウン スクリプト内で上記コマンドを実行する手順について、ご紹介します。
まず上記のコマンドを含む BAT ファイルを作成し、ドメインに割り当てられたグループポリシーのシャットダウンスクリプトに指定します。
作成した BAT ファイルはあらかじめ、ドメインコントローラーの以下のパスに配置しておきます。
<SysVol 共有フォルダ>\<ドメイン名>\Policies\<GUID>\User\Scripts\Logon
＜GUID＞は グループポリシーのGUIDになります。
グループポリシー管理エディタで対象のGPOに接続し、以下を選択します。
コンピューターの管理
― ポリシー
－ Windows の設定
－ スクリプト（スタートアップ/シャットダウン）
詳細ペインより「シャットダウン」のプロパティを開き、「追加」－「参照」より先のパスに配置した BAT ファイルをスクリプトとして選択します。
シャットダウンスクリプト設定後、コンピューターポリシーは、最大で 120 分以内に各クライアントに反映されます。
以降各コンピューターがシャットダウンする際に、KB2829996 適用後、再起動待ちとなっている状況から KB2829996 を削除できます。
WSUS での配布の停止手順
==================
KB2823324 を [拒否] もしくは [削除の承認] を実施ください。
既に配信してしまった場合には [削除の承認] を実施いただくことを推奨します。
[削除の承認] を設定することによってクライアントへの配信を停止し、また既に KB2823324 が適用済みのコンピューターから KB2823324 をアンインストールすることが可能です。
1. WSUS サーバーにログインします。
2. [スタート] - [管理ツール] - [Windows Service Update Services] をクリックします。
3. WSUS 管理コンソールが起動しますので、左画面から、[セキュリティ更新プログラム] をクリックします。
4. 中央画面の上部から、”承認” を [拒否された更新以外のすべて]、”状態” を [すべて] に設定し、[最新の情報に更新] をクリックし画面を更新します。
5. 中央画面のリストから、問題の更新プログラムである KB2823324 を見つけます。
6. KB2823324 を右クリックして、[承認] をクリックします。
7. “更新の承認” 画面が起動しますので、すべてのコンピューターのドロップダウンから、[削除の承認] をクリックします。
8. [OK] をクリックして、画面を閉じます。
9. WSUS クライアントは定期的に WSUS サーバーへ接続を行いますが、下記コマンドを実行することで WSUS サーバーへ即時接続させ、[削除の承認] の効果を反映させることも可能です。
> wuauclt /resetauthorization /detectnow
※ KB2823324 は OS ごと、プラットフォームごとに公開されておりますので、上記の手順ですべての KB2823324 に対して、削除の承認を設定してください。
ご迷惑をおかけして申し訳ありません。
最新の状況については、追って本ブログでも公開を予定しております。
(関連情報)
KB2839011 Released to Address Security Bulletin Update Issue
http://blogs.technet.com/b/msrc/archive/2013/04/11/kb2839011-released-to-address-security-bulletin-update-issue.aspx
MS13-036 2823324 適用後の問題について
http://blogs.technet.com/b/jpsecurity/archive/2013/04/12/3566398.aspx
日本マイクロソフトの三島です。
皆様に多大なるご迷惑をおかけいたしておりました KB2823324 (MS13-036) について、
修正を行う更新プログラムを、本日、再リリースいたしました。
再リリース版は「KB2840149」としてリリースされており、配信停止した KB2823324 とは別の KB 番号が割り当てられています。
お手数ではございますが、問題の発生した/していない端末にかかわらず「KB2840149」の更新プログラムの適用をお願いいたします。
Microsoft Security Bulletin MS13-036 - Important
http://technet.microsoft.com/en-us/security/bulletin/ms13-036
-----本文抜粋------
V3.0 (April 23, 2013): Rereleased bulletin to replace the 2823324 update with the 2840149 update for NTFS.sys when installed on supported editions of Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. See the Update FAQ for details.
-------------------
MS13-036: Description of the security update for the Windows file system kernel-mode driver (ntfs.sys): April 9, 2013
http://support.microsoft.com/kb/2840149
※現在は、英語記載のみでの更新となっておりますが、日本語記載のページについても順次公開が予定されています。
恐れ入りますが、今しばらくお待ちください。
※KB2840149 の詳細についてのご質問につきましては MS13-036 の FAQ をご参照ください。
こんにちは。
WSUS サポート担当の三島です。
2013 年 5 月の月例セキュリティ更新プログラムの公開より、「セキュリティ更新プログラム」 および 「セキュリティ アドバイザリ」 として配信される更新プログラムの公開について、運用に一部変更を加えさせて頂いております。
変更内容については、以下の弊社技術情報サイトでもご案内させて頂いておりますが、本ブログでは、より判りやすく変更点と変更理由を皆様にご案内させて頂きます。
Security advisories in the current landscape and the May 2013 bulletin release Changes to the classification of security content in advisories and bulletins
http://support.microsoft.com/kb/2849195
========
変更点
========
1. 多層防御の観点からリリースしたセキュリティ更新プログラム（※1）については、MSRC 重要度を 「指定なし」 で公開いたします。
- 変更前
クラス ： 「セキュリティ問題の修正プログラム」
MSRC 重要度 ： 「緊急」「重要」「警告」「注意」 のいずれかを設定しておりました。
- 変更後
クラス ： 「セキュリティ問題の修正プログラム」
MSRC 重要度 ： 「指定なし」 で今後公開いたします。
図 1 ： MS13-038 (KB2847204) の Internet Explorer 9 については多層防御の観点からセキュリティ更新プログラムが公開されております。そのため MSRC 重要度は 「指定なし」 となっております。(画像をクリックすると大きく表示されます。)
2. セキュリティ アドバイザリ（※2）で配信される更新プログラムは、セキュリティ問題の修正プログラムのクラスで公開いたします。
- 変更前
クラス ： 「重要な更新」あるいは「修正プログラム集」 などのセキュリティ以外のクラスで公開しておりました。
MSRC 重要度 ： 「指定なし」
- 変更後
クラス ： 「セキュリティ問題の修正プログラム」 のクラスで今後公開いたします。
MSRC 重要度 ： 「指定なし」
図 2.： KB2837285 はセキュリティ アドバイザリですが、「セキュリティ問題の修正プログラム」 のクラスで公開されております。 (画像をクリックすると大きく表示されます。)
- 補足：上記の変更は、2013 年 5 月の月例の公開日以降に新規あるいは更新で配信されるもののみが対象となります。
（※1）
影響を受けるコードが悪用されることはありませんが、影響を受けるコードが存在しているため、将来的に特定される可能性のある攻撃方法を防ぐために公開させていただくセキュリティ更新プログラムを指します。
例として、セキュリティ情報のサイトでは、以下のような内容で多層防御の観点からリリースした更新プログラムであるとご説明しております。
～～～
このセキュリティ更新プログラムは、Microsoft Windows 2000、Windows XP および Windows Server 2003 について、深刻度を「重要」と評価しています。Windows Server 2008、Windows Vista、Windows 7 および Windows Server 2008 R2 については、影響を受けるコードが悪用されることはありませんが、影響を受けるコードが存在しているため、多層防御としてこの更新プログラムが提供されており、深刻度の評価の対象とはなっていません。
～～～
（※2）
セキュリティ アドバイザリの詳細は、以下をご参照ください。
マイクロソフト セキュリティ アドバイザリ
http://technet.microsoft.com/ja-jp/security/advisory/
========
変更を行わせて頂いた理由
========
セキュリティ アドバイザリが「セキュリティ問題の修正プログラム」以外のクラスでリリースされる事によって、セキュリティの強化を目的とした更新プログラムである事を把握して配信する事が難しいとのご意見を多数頂いておりました。
今回の変更によって、「セキュリティ問題の修正プログラム」 を適用するだけで、セキュリティに関わる更新を把握・管理できるようにし、少しでも管理者様の運用・管理工数の軽減になれば幸いです。
こんにちは。
日本マイクロソフトの石井です。
Windows Server 2012 上の WSUS (WSUS 4.0) が、Microsoft Update と正常に接続出来ない問題について、修正プログラムがリリースされました。
WSUS の役割をインストールしている環境で、Proxy サーバーを使用する場合、Proxy サーバーとの認証が必要と構成されている場合には、あらかじめ WSUS のオプション設定で認証情報を登録可能です。
しかしながら、このように設定していても、正常に接続出来ない場合があった問題を修正いたしました。
WSUS server can't connect to Windows Update in Windows Server 2012
http://support.microsoft.com/kb/2838998
下記の設定箇所を利用している場合に、更新プログラムの適用をお願いいたします。
その他の問題の修正はありませんので、お客様の Proxy サーバーにおいてユーザー認証が必要な環境でのみ、適用して下さい。
更新プログラムの適用にあたって、サーバーの再起動が発生する可能性があります。
WSUS を System Center 2012 Configuration Manager から利用している場合も、条件に一致する場合には、本更新の適用をお願いいたします。
皆さま こんにちは。 マイクロソフトの香取です。
先日の投稿にて、WSUS からエクスポートしたカタログファイルが 0KB になる事象についてご紹介しましたが、この事象を解決するプログラムがリリースされております。
現時点での最新情報をまとめましたので、WSUS 管理者の方は、是非ご一読ください。
WSUS 4.0 (Windows Server 2012) の場合
CAB file that is exported by using the Wsusutil.exe command is displayed as 0 KB on a Windows Server 2012-based WSUS server
http://support.microsoft.com/kb/2819484/en-us
※ 修正プログラムとしてのリリースとなります。適用の注意点につきましては以下のサイトを参照ください。
Hotfix Online Submission – 修正プログラムの入手に関するご案内とご注意
http://support.microsoft.com/gp/HotfixNotice
WSUS 3.0 SP2 (Windows Server 2003 R2, Windows Server 2008, or Windows Server 2008 R2) の場合
An update for Windows Server Update Services 3.0 SP2 is available (KB2828185)
http://support.microsoft.com/kb/2828185/en-us
WSUS サーバーに上述の修正プログラムを適用したうえで、エクスポート / インポート時に実行するコマンドを、以下例のように変更することにより、問題を回避できます。
wsusutil.exe export export.xml.gz export.log
wsusutil.exe import import.xml.gz import.log
なお適用後はサーバーを再起動してください。
また KB2828185 には KB2734608 が含まれております。 適用する際にはご留意くださいますようお願いいたします。
KB2734608 の詳細につきましては以下のサイトをご参照ください。
<重要> WSUS の更新プログラムは確実に最新版の適用を行ってください
http://blogs.technet.com/b/jpwsus/archive/2013/03/13/lt-gt-wsus.aspx
WSUS を親子構成されている環境の場合、または WSUS NLB を構成されている場合には、手順上の留意点があります。
この点は 上記 KB2828185 上に記載されておりますが、若干わかりづらいため、以下の blog をあわせてご参照ください。blog の内容は KB2734608 を対象としておりますが、今回の更新プログラムについても同様です。
WSUS 3.0 SP2 の Windows 8 / Windows Server 2012 対応について (KB2734608)
http://blogs.technet.com/b/jpwsus/archive/2012/09/05/kb2734608.aspx
---------一部抜粋---------
親子構成の WSUS サーバーへ KB2734608 を適用する際には、下記の順で適用をお願いします。
1. 親の WSUS サーバーを Microsoft Update サイトと同期させる
2. KB2734608 を適用する
3. 再度 Microsoft Update サイトと同期させる
4. 同期が完了するまで待つ
5. 子の WSUS サーバーへ KB2734608 を適用し、親の WSUS サーバーと同期させる
NLB 構成の WSUS サーバーを運用されている場合には、KB2734608 の "How to upgrade NLB on all computers" セクション内手順をご確認ください。
ちなみに、ステップ 2 と 3 は記載が曖昧なため、下記操作であるとご理解ください。
2. すべてのフロント エンド WSUS サーバーで、下記コマンドを実行し IIS と WSUS のサービスを停止します。
iisreset /stop
net stop wsusservice
3. すべてのフロント エンド WSUS サーバーで、nlb.exe disable コマンドを実行します。
※コマンド実行例
nlb.exe disable all
もし KB2734608 の適用前に Windows 8 / Windows Server 2012 を WSUS 3.0 SP2 サーバーへ接続した場合には、KB2734608 の適用後に WSUS クライアント上で下記手順を実施してください。
1. 管理者権限のコマンドプロンプトを起動します
2. 下記のコマンドを順に実行します
> Net stop wuauserv
> rd /s %windir%\softwaredistribution\
> Net start wuauserv
3. 次回の WSUS サーバー接続時には、正しく処理が行われます
---------------------------
皆さま こんにちは。 マイクロソフトの香取です。
本日は Windows Server 2012 の WSUS の主な変更点についてご紹介します。
現在、WSUS 3.0 SP2 をご利用いただいている WSUS 管理者様や今後、Windows Server 2012 にて WSUS の構築をご検討いただいていらっしゃる方々にご一読いただけますと幸いです。
－ WSUS の概要
－ WSUS の製品バージョン
－ WSUS 3.0 SP2 との WSUS 4.0 の主な変更点
－ WSUS 4.0 のインストールについて
【 WSUS の概要 】
WSUS の機能概要については下記の公開情報をご参照ください。
WSUS 3.0 SP2 との変更点についても、こちらでご紹介しております。
Windows Server Update Services の概要
http://technet.microsoft.com/library/hh852345.aspx
【 WSUS の製品バージョン 】
Windows Server 2012 の WSUS 製品バージョンは WSUS 4.0 となります。WSUS のヘルプから確認することができます。
また、以下の弊社 technet サイトにおいても WSUS 4.0 として言及おります。
System Requirements: Update Management
http://technet.microsoft.com/en-us/library/gg610633.aspx
(Software requirements の Software 列)
Step 3: Configure WSUS
http://technet.microsoft.com/en-us/library/hh852346.aspx
(3.1. Configure network connctions の Note)
【 WSUS 3.0 SP2 との WSUS 4.0 の主な変更点 】
WSUS 3.0 SP2 との WSUS 4.0 の主な変更点としましては、以下の 2 点です。
1. 既定ポートは 80 から 8530 に変更されました。
WSUS 3.0 SP2 は 既定のポートが 80 に指定されておりました。 WSUS 4.0 では既定のポートが 80 から 8530 に変更されました。
手順1: WSUS 展開の準備を行う
http://technet.microsoft.com/ja-jp/library/hh852344.aspx
----------一部抜粋----------
既定では、WSUS サーバーでは、Microsoft から更新プログラムを取得するために、HTTP プロトコルにはポート 8530、HTTPS プロトコルにはポート 8531 を使用します。
-----------------------------
2. WSUS 4.0 のアンインストールは従来の手順では実施出来ません。
WSUS 3.0 SP2では、[コントロールパネル] - [プログラムと機能] からアンインストール時にデータベース、ログファイル、コンテンツを選択し、削除することができました。
WSUS 4.0 では、アンインストール後も IIS 上の サイト、データベース、コンテンツ、いずれもすべて残ります。これらを削除したい場合は手動で別途、削除作業が必要となります。 (こちらの詳細は、別途ブログにてご紹介予定です)
【 WSUS 4.0 のインストールについて 】
WSUS 4.0 のインストールについては、以下のサイトにサーバー マネージャーの [役割と機能の追加] から WSUS をインストールする手順が公開されております。
※ WSUS 4.0 のインストーラーのご用意はなく、Windows Server 2012 の役割と機能の追加から構築してください。
手順 2: WSUS サーバーの役割をインストールする
http://technet.microsoft.com/ja-jp/library/hh852338.aspx
また、WSUS 4.0 のインストールをコマンドから実施する方法もあります。
STEP 1 ：サーバーマネージャーの 「役割と機能の追加」 から WSUS の追加を選択し、PowerShell で使用するための構成ファイルを作成します。
STEP 2 ： PowerShell を起動し、STEP 1 の構成ファイルを指定し、Install –WindowsFeature を実行します。
Install-WindowsFeature
http://technet.microsoft.com/en-us/library/jj205467.aspx
Installing WSUS on Windows Server “8” Beta using PowerShell
http://blogs.technet.com/b/sus/archive/2012/03/20/installing-wsus-on-windows-server-8-beta-using-powershell.aspx
----------一部抜粋 (データベースが WID を利用の場合) ----------
3. In the PowerShell Console type Install-WindowsFeature -Name UpdateServices, UpdateServices-Ui and press ENTER.
4. The installation process will start and a progress counter will appear on the screen. Wait until the installation reaches 100% and you receive a message that the installation succeeded before moving on to the next step.
-------------------------------------------------------------------
STEP 3 ： wsusutil postinstall コマンドを実行します。
コンテンツ フォルダのパスおよびデータベースの情報をオプションとして指定します。データベースが WID の場合は、後者のオプションは不要となり、以下例の要領で実行します。
wsusutil postinstall contentdir=C:\MyContent
注意点としましては、コマンド投入後、処理が開始された旨のメッセージが表示されますので、そのままお待ちください。
完了するとさらに、終了メッセージが一行追加されます。
----------上記資料より一部抜粋 (データベースが WID を利用の場合) ---
5. Type & ‘C:\Program Files\Update Services\Tools\WsusUtil.exe’ postinstall contentdir=C:\Mycontent and press ENTER.
------------------------------------------------------------------------
こんにちは、マイクロソフトの福島です。
今月 公開されたセキュリティ更新プログラム MS13-044 のうち Visio 2010 用のパッケージ KB2810068 のメタデータについて問題が見つかり、それを修正するリビジョンが本日、公開されました。
この影響により、設定によっては 「急に 本日 KB2810068 が WSUS サーバーに新規着信した」 ということが生じることがあります。月例リリースから一週間以上遅れてのご提供となり、お客様にはご迷惑をお掛けいたしますことお詫び申し上げます。
本件の影響の有無は次のとおりです。
WSUS サーバーのオプション「更新ファイルと更新言語」の言語設定にて「英語」が選択されているお客様：
本修正の影響はありません。既にクライアントへの配信を開始されていた場合、サーバー/クライアントとも、昨日までの同じ動作を継続します。お客様におけるアクションは不要です。
※ なお WSUS サーバー上で KB2810068 を確認すると、昨日までは「サポートされる言語」が「英語」と表示されていましたが、本日のリビジョンを着信した後は「すべて」に変わります。
「英語」が選択されていないお客様：
今回の修正により WSUS に初めて KB2810068 が着信します。申し訳ございませんが、必要に応じ検証や承認など、通常のセキュリティ更新のリリースに対するご対応をお願いいたします。
こんにちは、マイクロソフトの福島です。
本日 公開されたセキュリティ更新プログラム MS13-054のうち Office 2010 用のパッケージ KB2687276が、「WSUS サーバーに着信しないことがある」 という問題が見つかりましたので、取り急ぎご報告いたします。
この問題の影響を受けるかどうかは、WSUS サーバーのオプション「更新ファイルと更新言語」の言語設定に依存します。
WSUS の言語オプションの選択に「英語」が含まれていれば影響を受けませんが、「英語」が指定されていない場合、その WSUS サーバーは現在、KB2687276 を受信することができません。
これは更新プログラムの本体ではなく、配信管理用の情報における問題であると考えられます。現在、調査に入っておりますので、この影響を受けているお客様は、たいへん申し訳ございませんが、今しばらくお待ちください。修正次第リビジョンがリリースされ、その結果 WSUS サーバーに着信するようになる見込みです。
大変ご迷惑をお掛けいたしますことお詫び申し上げます。
2013/07/11 追記
本日、修正されております。( リビジョン # 202 ) ただし WSUS の同期実行時刻によっては、まだ着信できていないケースもあるようですので、大変お手数ですが、手動にて同期を実行するなどにて、ご確認をいただけましたら幸いです。
なお オフライン カタログ ファイル wsusscn2.cab の修正にはさらに あと一、二営業日ほど頂く予定です。恐れ入りますが cab ファイルをご利用のお客様はもう少々、お待ちください。
ご迷惑をお掛けしましたこと重ねてお詫び申し上げます。
皆さま こんにちは。 マイクロソフトの香取です。
WSUS サーバーを長期的に運用していただいている管理者より、 「レプリカ WSUS サーバーの同期がタイムアウトにて失敗する」 というお問い合わせをいただくことがあります。
レプリカとして構成されている WSUS サーバーは 自律の WSUS サーバーと異なり、承認情報は親 WSUS サーバーが保持しています。
親 WSUS サーバーで大量の 「拒否済み」 の更新プログラムがある状態で、レプリカの WSUS サーバーが同期を行うとタイムアウトが発生し、同期が失敗する可能性があることが判っています。
目安としましては、親 WSUS サーバーにて一度に約 1,000 件ほどの更新プログラムを手動で「拒否済み」に変更し、レプリカ WSUS サーバーで同期を行いますと、タイムアウト発生に至る場合があることを確認しております。同期の条件 (初回か2回目以降か等) や 性能面の条件（データベースの状態、サーバー スペック、WSUS サーバーの全体的な負荷等）によっても変動いたします。
また、多数の 「拒否済み」 データをレプリカ同期において取り扱えないという点は、WSUS サーバーの設計上の問題として認識しております。
【 「拒否済み」 の更新プログラムが大量にあることでレプリカの WSUS サーバーで同期が失敗する主な要因】
拒否済みの更新プログラムの件数が多くなりやすく、この事象が特に顕著に出やすいパターンは以下の 3 点です。
1. WSUS サーバーの構築後、長期間にわたりサーバー クリーンアップ ウィザードを実施していないこと。
2. 定義更新ファイル (※) をクラスとして選択していること。
定義更新プログラムは、下記の弊社サイトにてご紹介しているとおり、1 日に 3 回の頻度で古い更新プログラムを置き換える、新しい更新プログラムが公開されます。
置き換えられた古い更新プログラムは、期限切れ（配信停止の設定）となり、この更新プログラムの承認ステータスは、自動的に「拒否済み」 となります。（既定のオプション設定の場合に限ります。）
そのため、定義更新プログラムを同期対象としている場合には、拒否済みの更新プログラムが蓄積されやすい構成といえます。
なお、期限切れとなった更新プログラムは、サーバー クリーンアップ ウィザードで削除する事ができます。
(※)＜参考情報＞
－ Forefront エンドポイント セキュリティ定義の更新について
http://support.microsoft.com/kb/977939/ja
---------------一部抜粋-------------------------
新しい定義更新パッケージは、通常、1 日に 3 回 Windows Server Update Services に公開されます。これらの更新プログラムをコンピューターが利用できる頻度は、WSUS サーバーがマイクロソフトと同期する頻度および更新プログラムの展開が承認される方法によって決まります。
-------------------------------------------------
3. WSUS サーバー管理者様が配信不要と判断し、手動にて 「拒否済み」 にステータスを変更した更新プログラムが大量にあること。
【レプリカの WSUS サーバーで同期エラーの対処方法】
対処方法といたしましては、「拒否済み」 の更新プログラムの件数を、減らす事となります。
拒否済みの更新プログラムの件数を削減する、 3 点の方法をご紹介いたします。
A. サーバー クリーンアップ ウィザードにて、 「不要な更新および更新のリビジョン」 を実行します。
これによって、期限切れとなった結果、拒否済みのステータスとなっている更新プログラムを、WSUS データベースから削除する事ができます。
＜注意点＞
クリーンアップは 子 WSUS サーバー ⇒ 親 WSUS サーバーの順番に実行します。
－ レプリカ構成では サーバー クリーンアップ ウィザード にご注意ください
http://blogs.technet.com/b/jpwsus/archive/2012/06/08/3502667.aspx
＜補足事項＞
WSUS サーバーを長期的に運用され、一度もサーバー クリーンアップ ウィザードを実施されていない場合には、クリーンアップがタイムアウトしてしまう可能性がございます。
インデックスの再構成を実行して、WSUS データベースをメンテナンスする事によって、タイムアウトを軽減する事が可能です。
手順は、以下の情報もご参照下さい。
－ WSUS DB インデックスの再構成の手順について
http://blogs.technet.com/b/jpwsus/archive/2013/02/01/wsusdb.aspx
B. 手順A. にて解消せず、また WSUS 管理者様が明示的 (手動作業) に、手動で 「拒否済み」 に設定した更新プログラムが多い場合には、 手動で「拒否済み」 のステータス設定した更新プログラムを 「未承認」 に戻します。 更新プログラムのステータスを 「未承認」 に変更することで 「拒否済み」 の件数が減少し、同期の失敗は解消されることが期待されます。
C. 手順 A. および 手順 B. を実施して現象が改善した後にも、直ぐに現象が再発する場合や、手順 B の実施が運用ポリシー上、難しい場合には、親 WSUS サーバーの再構築を検討します。
配信不要な「製品」 および 「クラス」 を同期対象から削除して再構築して頂く事によって、不要なデータが蓄積されていないクリーンな状態で運用して頂け、その結果として、レプリカ同期失敗の事象発生を回避する事が可能です。
ご案内は以上となります。
11/26/2013 更新
~~~~~~~~~~~~~~~~~~~~~
こちらのブログ記事でご紹介させて頂きました、Windows 8 / Windows Server 2012 からの自動インストールの動作変更ですが、以下の "更新プログラムのロールアップ" を適用して頂く事によって、Windows 7 以前の環境と同じように、更新プログラムのインストール日時を指定する事ができるようになりました。
Windows RT と Windows 8 の Windows Server 2012 の更新プログラムのロールアップ: 2013 年 10 月
http://support.microsoft.com/kb/2883201
動作変更への詳細なご説明は、以下のサイトでご案内させて頂いております。
Windows 8 と Windows Server 2012 での自動更新の構成を許可します。
http://support.microsoft.com/kb/2885694/ja
自動更新のポリシーは以下のようになり、自動メンテナンスタスク時に更新プログラムをインストールする機能も引き続きご利用頂けます。
~~~~~~~~~~~~~~~~~~~~~
こんにちは。日本マイクロソフトの三島です。
既にご存知の方も多いかと思いますが、Windows 8 / Windows Server 2012 からは、「自動インストール」 の動作が大きく変更されております。
「動作変更の詳細」と、「運用へのご提案」をご説明させていただきますので、想定外のインストールや再起動が発生する事を未然に防ぐためにも、ぜひご一読頂ければと思います。
動作変更の詳細について
============================
Windows Vista / Windows Server 2008 R2 以前の環境では、以下のように自動更新を設定する事によって、更新プログラムは自動ダウンロードし、指定した日時にインストールを実行するよう設定できていたかと存じます。
～～～～
[コンピューターの構成]
-> [管理用テンプレート]
--> [Windows コンポーネント]
---> [Windows Update]
[自動更新を構成する] を有効に設定し、
[4 - 自動ダウンロードしインストール日時を指定] のオプションを選択
～～～～
しかしながら、Windows 8 / Windows Server 2012 の環境では、自動インストールの開始タイミングが OS のメンテナンス タスクとして制御されるよう、設計が変わっています。
そのため、「自動更新のオプション 4 番」を設定している場合には、時刻が固定されていない「Idle Maintenance」タスクの一環としてインストール動作が開始する可能性があり、結果として、ユーザーの意図していないタイミングで再起動が発生するおそれがあります。
インストールの実行時間や、再起動のタイミングをコントロールしたいご要望がある場合には、この設定を行わないことを強くお勧めいたします。
運用へのご提案について
=========================
インストールの実行時間や、再起動のタイミングをコントロールしたいご要望がある場合には、以下の運用を検討して下さいますようお願いいたします。
1. 自動ダウンロードし、手動インストールする「自動更新のオプション 3 番」で運用頂く。
2. Windows Update API を利用したスクリプトを使用して自動更新を実行する。
運用案 2. の詳細や、サンプル スクリプトについては、以下の記事をご参照下さい。
Windows Update 処理を厳密に制御したい
http://blogs.technet.com/b/jpwsus/archive/2013/01/25/windows-update.aspx
こんにちは。日本マイクロソフトの三島です。
WSUS や Windows Update を用いて更新プログラムをインストールした場合、ごくまれにですが、次のような状況が発生することがあります。
状況：
================
更新プログラムを 1 件、WSUS からクライアントへ配信したところ、クライアントの「インストールされた更新プログラム」リストには該当の更新プログラム名の代わりに、別の 2 件の更新プログラムが表示された。
理由：
================
これは、WSUS 上で「1 件」として表示・管理される更新プログラムの内部に、実は 2 件のインストーラーが含まれていたためです。
WSUS の配信単位と、実際に内部で動作するインストーラーの数や KB 番号が相違している更新プログラムにおいては、このような状況が発生します。
しかしこれは想定される動作であり、異常ではありません。
こうしたケースとして、たとえば KB982526 という .NET Framework 3.5 SP1 用の更新プログラムがあります。
この実体は KB958488 と KB979900 という 2 つの更新プログラムで構成されており、クライアント上で実際に動作するのはこの 2 つのインストーラーです。
これに対し KB982526 という番号は、両者をまとめる情報管理上の番号にすぎず、この番号を持つインストーラーは存在しません。
こうした場合、「インストールされた更新プログラム」の画面はインストーラー単位での表示となるため、KB958488 と KB979900 の 2 件がリストされます。（ KB982526 という表示はありません ）
一方、Windows Update の「更新履歴の表示」画面は、WSUS が認識する管理上の内容を表示しますので、この場合、KB982526 がリストされることになります。
こんにちは。日本マイクロソフトの三島です。
ユーザーが、コンピューターの管理者権限を持つアカウントでログオンしている場合、Windows Update の動作が「自動インストール」の設定になっている場合でも、ユーザーは以下の操作を行うことが可能です。
- Windows Update 画面から更新プログラムのインストールを任意のタイミングで開始・停止する
- インストール対象とならないように、更新プログラムを "非表示" に設定する
このような、ユーザーの手動操作の自由度を一切なくしたい、という場合には、「対話的な操作を行えないようにする / アイコンやバルーンを表示しないようにする」ためのグループポリシーがありますので、その設定をご検討ください。
手順：
=======================
以下のポリシーを「有効」に設定します。
～～～～～～～～
[ユーザーの構成]
[管理用テンプレート]
[Windows コンポーネント]
[Windows Update]
- [Windows Update のすべての機能へのアクセスを削除する] ポリシー
～～～～～～～～
なお、これを設定しますと、Windows Update 画面から "更新プログラムの確認" の実行や、インストール・ダウンロードの開始、wuauclt /detectnow コマンドの実行等、あらゆる手動操作ができなくなりますのでご注意ください。
また、この設定だけでは、Windows Update のアイコンやバルーンが一切、表示されなくなります。
自動更新の構成が 「4. 自動ダウンロードしインストール日時を設定」 になっている場合、インストール後の自動再起動に関するポップアップまでも表示されず、いきなり再起動が開始されるという結果になってしまいます。
これでは予期しない再起動が発生しますので、さらに次の設定を追加することによって「再起動のポップアップ通知だけは表示する」ことをお勧めいたします。
～～～～～～～～
「Windows Update のすべての機能へのアクセスを削除する」ポリシーのプロパティのオプション項目として「通知の構成」が表示されていたら (※)、その選択肢をクリックし「1-再起動が必要であることを示す通知を表示する」を指定します。
～～～～～～～～
(※) このポリシーに「通知の構成」オプションが存在しないという場合は、お使いのポリシー テンプレートが少し古いバージョンだと思われます。
その場合は、同じフォルダ内に「Windows Update 通知を有効にする」という別のポリシー項目が存在するはずですので、これを「有効」に設定すれば、同じ結果が得られます。
こんにちは。日本マイクロソフトの三島です。
WSUS クライアント / Windows Update に関するトラブルシュートの際に、「%windir%\SoftwareDistribution」フォルダをリネームするという、Windows Update のキャッシュ削除の対処をご案内する事が多くございます。
ところがこれを実施すると、Windows Update の「更新履歴の表示」の情報が消去される、という副作用があり、この点についてご懸念を伺うことがあります。
本日は、そのご懸念に対する回答についてご案内いたします。
- 回答：
-----------------
「更新履歴の表示」は、更新プログラムの適用有無を判断する材料としては使うことができない情報であり、また今後の更新プログラムの適用動作には一切影響しないことから、削除しても差し支えありません
- 説明回答解説：
-------------------------
「更新履歴の表示」が示す情報は「WSUS ( またはWindows Update ) クライアントが、更新の適用を試みたという事実、およびその結果」のみです。
Windows Update を利用しない、ユーザー様が明示的に適用した更新プログラムについては( OS にもよりますが ) この履歴では確認ができません。
また履歴上「更新プログラム A をインストールした」とされていても、その後、手動で A をアンインストールしてしまうと、更新履歴からはそのことが判別できません。
このように、更新プログラムの真の適用状況 / システム内の脆弱性の有無を判断するための情報源としては機能しない内容となっています。
では、そのような適用プログラムの要否や脆弱性の有無のチェックは、Windows Update はどうやって行っているかですが、これは履歴情報を参照するのではなく、その時点のシステムの状態 (ファイル バージョン等) をそのつど確認して判定しています。
チェックの結果は、WSUS サーバーに、各クライアントの状態レポートとして格納されていますので、通常はそれを管理情報としてお使いいただけばよいという考え方となっています。
なお「%windir%\SoftwareDistribution」フォルダ自体が、OS のバックアップやスナップショットの対象からも除外されておりますので、システムのリストアを行うとやはりこの情報は消去されます。
この観点からも、更新プログラムの真の適用状況 / システム内の脆弱性の有無を判断するための情報源としては機能しない内容とご理解頂ければと存じます。
最終更新
～～～～～～～～～～～
米国時間 9 月 13 日に、本問題の修正を完了いたしております。
更新 （9/12/2013)
～～～～～～～～～～～
本事象につきましては、インストールが必要なセキュリティ更新プログラムを検出するロジックに問題があることがわかっており、数日以内に修正を完了することを予定しています。
なお、一度セキュリティ更新プログラムをインストールした場合は、正しくセキュリティ更新プログラムは適用されており、脆弱性より保護されている状態です。
本問題により、再度、セキュリティ更新プログラムを適用するよう求められても、再度インストールを行う必要はありません。
セキュリティ情報 MS13-072/MS13-073 - 繰り返し適用を求められる現象について
http://blogs.technet.com/b/jpsecurity/archive/2013/09/12/3596117.aspx
こんにちは。日本マイクロソフトの三島です。
9 月分のセキュリティ更新プログラムとして公開されております、以下の 3 点の更新プログラムにおきまして、
インストール完了後にも、再度必要な更新プログラムとして検出されるとの報告がございます。
～～～～～～～～～
セキュリティ更新プログラムを Microsoft Excel 2007 (xlconv x none.msp) MS13-073: 説明: 2013 年 9 月 10 日
http://support.microsoft.com/kb/2760588
2007 セキュリティ更新プログラムの説明を MS13-072: システムの Office (MSO): 2013 年 9 月 10 日
http://support.microsoft.com/kb/2760411
Microsoft Office Excel 2007 セキュリティ更新プログラムの MS13-073: 説明: 2013 年 9 月 10 日
http://support.microsoft.com/kb/2760583
～～～～～～～～～
本件の事象につきましては、現在、弊社にて調査を実施しております。
要因が判明次第、こちらの記事に情報を公開させて頂きますので、今しばらくお待ち下さい。
更新 (10/25/2013)
～～～～～～～～～～～～～
前回公開させて頂きました手順では、「%program files%\Update Services」フォルダを手動削除する手順を含めさせて頂いたおりましたが、このフォルダを削除した場合には、 WSUS サーバーの再構築時にエラーが発生する事が確認されました。
「%program files%\Update Services」 のフォルダ削除を抜いた手順を以下に記載させて頂きましたので、恐れ入りますが、こちらを最新手順としてご利用くださいますようお願いいたします。
～～～～～～～～～～～～～
皆さま こんにちは。 マイクロソフトの香取です。
以前、「[WSUS 4.0] Windows Server 2012 の WSUS の主な変更点について」 の記事で WSUS 4.0 のアンインストール手順について別途ご紹介することを記載しました。
WSUS 4.0 のアンインストール手順をまとめましたので、現在、Windows Server 2012 にて WSUS の構築や検証を行っていただいていらっしゃる方々にご一読いただけますと幸いです。
【 Windows Server 2012 の環境における WSUS 4.0 をアンインストールする手順 】
A) WSUS サーバー、IIS、Windows Internal Database のアンインストール
**********************************************************************
サーバー マネージャー から WSUS サーバー、IIS、Windows Internal Database をアンインストールします。
1. サーバー マネージャー ダッシュ ボードにて、[ローカル サーバー] を選択します。
2. 画面右上メニュー バー [管理] - 「役割と機能の削除」を選択します。
3. [開始する前に] タブにて、[次へ] ボタンをクリックします。
4. [サーバーの選択] タブにて、[次へ] ボタンをクリックします。
5. [サーバーの役割] タブにて、「Windows Server Update Server (WSUS)」のチェックを外します。
6. 「役割と機能の削除ウィザード」が表示されます。「管理ツールを削除する（存在する場合）」にチェックを入った状態で、 [機能の削除] ボタンをクリックします。
7. IIS を他アプリケーションで利用していない場合は、「Web サーバー(IIS)」 のチェックを外します。
8. 次へをクリックします。
9. [機能] タブにて、「Windows Internal Database」のチェックを外します。
10. 次へをクリックします。
11. [確認] タブにて、[削除] ボタンをクリックします。
※即時再起動して問題ない場合は、「必要に応じて対象サーバーを自動的に再起動する」のチェックを入れてください。
12. 以上の作業後、再起動を実施します。
B) 削除されたサービスの確認
**********************************
A) の作業完了後、以下のサービスが削除されている事を確認します。
- WSUS Services
- Windows Internal Database
- IIS Admin Service
C) Windows Internal Database で残存するファイルの削除
******************************************************
%windir%\WID\DATA フォルダ内のファイルを全て手動で削除します。
※SUSDB.MDF, SUSDB_log.ldf ファイルが WSUS に関連するファイルとなります。
D) WSUS コンテンツ フォルダの削除
***********************************
インストール時に指定した WSUSCONTENT フォルダを手動で削除します。
※C:\WSUS\WSUSContent 等になります。
E) Microsoft Report Viewerの削除方法
************************************
レポート参照用に Microsoft Report Viewer 2008 SP1 再頒布可能パッケージをインストールした場合には、以下の手順にてアンインストールします。
1. コントロール パネル から [プログラムと機能] を開きます。
2. 「プログラムのアンインストールと変更」にて、「Microsoft Report Viewer 再頒布パッケージ 2008 SP1」を選択し、「アンインストールと変更」をクリックします。
3. 「アンインストール」を選択し、「次へ」をクリックします。
(※ 補足情報 ※)
補足として、 手順 A の 7 で IIS を削除しない場合には、WSUS のアプリケーションプールと仮想ディレクトリは残存します。
以下の手順にてWSUS のアプリケーションプールと仮想ディレクトリの削除を行えます。
1. インターネット インフォメーション サービス (IIS) マネージャーを起動します。
2. アプリケーション プール 「WsusPool」 を [削除] ボタンで削除します。
3. Web ページ 「WSUS の管理」 を含む記載のある WebPage を右クリックし、 [削除] ボタンで削除します。
ご案内は以上となります。
12/11/2013 更新
～～～～～～～～～
本事象が、12 月公開分の IE の累積更新プログラム（KB2898785）の検出時においても発生するとの報告がございました。
なお、KB2898785 をインストール完了して頂く事によって事象が改善する事も確認されております。（※こちらは暫定対処策 1 に該当します。）
この事象につきましては、情報に更新があり次第、随時当該ブログでご案内させて頂きます。
～～～～～～～～～
11/27/2013 更新
～～～～～～～～
本日、本事象への恒久対処策として、数年前に公開させて頂いた古い「Internet Explorer の累積的なセキュリティ更新プログラム」を期限切れ（公開停止）とする対処を実施させて頂きました。
暫定対処策を実施されていない WSUS 環境におきましても、これによって置き換え関係を参照する対象が少なくなり、その結果として、IE の累積更新プログラムを検出する際の高負荷の状況が緩和される事が考えられます。
なお、期限切れの情報は、WSUS サーバーを Microsoft Update サイトと同期して頂ければ、着信可能です。
また、以下の WSUS のオプションを既定のままオンで運用されている場合には、期限切れの着信に伴って期限切れとなった古い IE の累積更新プログラムが、自動的に拒否済みに設定される動作となります。
そのため、管理者様が恒久対処策の反映のために追加で作業を実施する必要はございません。
--------
WSUS サーバーの [自動承認] オプションの [詳細] タブの設定
- [承認済み更新プログラムの新しいリビジョンを自動的に承認する] がオン
- [新しいリビジョンにより期限切れとなった更新プログラムを自動的に拒否する] がオン
--------
しかしながら、オフで運用されている場合には、期限切れが着信した後にも IE の累積更新プログラムは自動的に拒否済みとなりません。
管理者様が手作業で期限切れとなった IE の累積更新プログラムを拒否済みに設定して頂く必要がございますので、ご注意くださいますようお願いいたします。
～～～～～～～～
11/22/2013 更新
～～～～～～～～
本事象は、11 月公開分の「Internet Explorer の累積的なセキュリティ更新プログラム」でも同様に発生する事を確認しております。
恒久対策につきましては、現在、検討中の段階でございますので、ご不便をおかけいたしておりますが、暫定対処策の実施をご検討賜りますようお願い申し上げます。
～～～～～～～～
11/20/2013 更新
～～～～～～～～～～
暫定対処策 (2) に、「※補足 3」 を追記いたしました。
～～～～～～～～～～
皆さま、こんにちは。
WSUS サポートチームです。
Windows XP や Windows Server 2003 環境において、Windows Update 実行時に Svchost.exe の CPU 使用率が 100 % となる、時間を大幅に要する というお問い合わせを多く頂いております。
本事象につきましては、現在恒久対策の確認を弊社にて行わせて頂いておりますが、ご案内までにしばらくお時間を要する見込みです。
恐れ入りますが、事象の詳細と、現在判明している暫定対処策を以下にご紹介させて頂きますので、恒久対処のご案内まで、こちらのご実施をご検討くださいますようお願いいたします。
(事象の詳細)
WSUS サーバーへの更新プログラムの検出実行時において、svchost.exe の CPU 使用率が 100% となる。
更新プログラムの検出処理自体は時間を要する場合があるものの、最終的には成功に至りインストールも正常に完了する。
(発生環境)
以下 2 点の条件を満たす環境で、本事象が発生する事を確認いたしております。
- Windows Server 2003 および Windows XP
- Single Core CPU、Hyper Threading なし等、マシン スペックが比較的不利である
(原因)
本事象は「Internet Explorer の累積的なセキュリティ更新プログラム」の検出処理に起因しており、下記の 4 点において特に顕著であることが確認されております。
KB2846071（7月公開分）
KB2862772（8月公開分）
KB2870699（9月公開分）
KB2879017（10月公開分）
(暫定対処策)
以下の 2 点を暫定対処策としてご検討くださいますようお願いいたします。
- 暫定対処策 (1)
「Internet Explorer の累積的なセキュリティ更新プログラム」を事前に単独で配信しインストール完了させる。
最新の "Internet Explorer の累積的なセキュリティ更新プログラム" は、以下のサイトよりダウンロードして頂けます。
（現在最新である 11 月公開分は、KB2888505 で検索してダウンロードして頂けます。）
(※12/11/2013 追加：現在最新である 12 月公開分は KB2898785 で検索してダウンロードして頂けます。)
Microsoft Update カタログ
http://catalog.update.microsoft.com/v7/site/home.aspx
- 暫定対処策 (2)
承認状態とする「Internet Explorer の累積的なセキュリティ更新プログラム」を 1 点のみとし、その他 WSUS サーバー上に同期されているすべての「Internet Explorer の累積的なセキュリティ更新プログラム」については、すべて拒否済みに設定して頂く。
この場合、その他の更新プログラムを同時に承認して頂いても問題ありません。
※補足 1
現時点において最新の Internet Explorer の累積的なセキュリティ更新プログラムは、11 月公開分の KB2888505 となります。
現時点において最新の Internet Explorer の累積的なセキュリティ更新プログラムは、12 月公開分の KB2898785 となります。
最新の Internet Explorer の累積的なセキュリティ更新プログラムは過去に公開された Internet Explorer の累積的なセキュリティ更新プログラムの修正内容をすべて含んでおりますので、最新のもののみを承認して、古いものをすべて拒否済みに設定して頂いて問題ございません。
※補足 2
以下の手順にて「Internet Explorer の累積的なセキュリティ更新プログラム」をまとめて拒否済みに設定する事ができます。
（なお、同時に選択して拒否済みとする件数は、WSUS の負荷状況に応じて調整して下さい。）
1. WSUS 管理コンソールを起動し、[Update Services] – [<サーバー名>] – [更新] に移動します。
2. メニューバーから [操作] – [検索] の順に選択します。
3. 検索画面が表示されますので、Internet Explorer と入力して [検索] をクリックします。
4. 検索結果が表示されますので、拒否に設定する「Internet Explorer の累積的なセキュリティ更新プログラム」を Shift キーを押下しながら複数一括選択します。
5. 選択した当該更新プログラム上で右クリックし、[拒否] を選択します。
6. メッセージが表示されますので [はい] を選択します。
※補足 3
古い Internet Explorer の累積的なセキュリティ更新プログラムをすべて拒否済みに設定して頂いた後にも事象改善に至らない場合には、累積的なセキュリティ更新プログラム "以外" の更新プログラムにつきましても、追加で拒否済みに設定可能な更新プログラムがございます。
拒否済みに設定可能な更新プログラムの一覧につきましては、以下の手順で確認して頂く事が可能です。
一覧の中に、拒否に設定していない更新プログラムがある場合には、すべて拒否済みに設定し、事象が改善するかを確認して下さい。
1. Microsoft Update カタログ サイトに接続します。
Microsoft Update カタログ
http://catalog.update.microsoft.com/v7/site/home.aspx
2. 画面右に表示されているテキストボックスに、置き換え関係を調べる対象とする "Internet Explorer の累積的なセキュリティ更新プログラム" の KB 番号を入力して、[検索] をクリックします。
（10 月分を対象とする場合には、KB2879017 と入力します。）
3. 表示された更新プログラムの一覧から、問題が発生している クライアントの OS と IE のバージョンに対応するものを見つけてクリックします。
4. 追加で表示された画面から、[パッケージの詳細] タブを表示します。
[この更新プログラムは、次の更新プログラムを置き換えます] に表示されている更新プログラムが、
検索した累積的な更新プログラムが置き換えている更新プログラムとなります。
こちらが、WSUS サーバー上で拒否済みの設定対象となります。
皆さま、こんにちは。
WSUS サポートチームです。
Windows XP や Windows Server 2003 環境において、Windows Update 実行時に Svchost.exe の CPU 使用率が 100 % の状態が長時間継続する事象につきましては、2014 年 1 月の更新プログラムのリリースにあわせて、改めて 「IE の累積的なセキュリティ更新プログラム」 を期限切れ （公開停止） とする対処を実施いたしました。
2013 年 11 月に実施した対処では、古い 「IE の累積的なセキュリティ更新プログラム」 を期限切れといたしましたが、それでは、十分な改善がみられないというご報告がございました。このため、さらに多くの 「IE の累積的なセキュリティ更新プログラム」 を期限切れとする対処を実施させていただきました。上記の対処により、以下のポストにてご案内いたしました、暫定対処策を実施していない Windows XP や Windows Server 2003 においても、更新プログラム検出処理に長時間かかる問題に対しての緩和が見込まれます。
「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>
なお、今月公開分のセキュリティ更新プログラムでは、KB2898785 (昨年 12 月リリース) より新しい IE の累積更新プログラムは公開いたしておりません。
そのため、KB2898785 が適用済みのコンピューターへの動作確認につきましては、新しい IE の累積更新プログラムが公開された後 (来月のセキュリティ更新プログラムのリリース日以降) にご確認下さいますようお願いいたします。
事象解消までご迷惑をおかけいたしまして、誠にご不便をお掛けいたしました。
深くお詫び申し上げます。
こんにちは。WSUS サポートチームです。
更新プログラムの検出に関して、MBSA をご利用いただいているお客様も多いかと存じます。
今回は、昨年リリースされた最新版 MBSA 2.3 の要件について、ご案内いたします。
Microsoft Baseline Security Analyzer
http://technet.microsoft.com/ja-jp/security/cc184924.aspx
MBSA 2.3 のサポート対象 OS については、上記文書に記載のとおりですが、
MBSA 2.3 では、新たなセキュリティ上の要件として、MSXML 6.0 が必要となっております。
MSXML 6.0 が未適用の環境で、MBSA 2.3 のスキャンを実行すると、以下のメッセージが出力され、
正しい検出結果を確認することができません。
CUI モードでコマンドラインから mbsacli.exe を実行した場合も同様です。
出力されるメッセージ :
" WSUS サーバーで承認されているセキュリティ更新プログラムがないか、またはこのコンピュータに利用できるセキュリティ更新プログラムはありません。"
弊社では、Windows Server 2003 の環境で、MSXML 6.0 が未適用であったために、上記事象が発生したという
お問い合わせをいただいております。
対処方法としては、MSXML 6.0 をインストールしていただいた後に、MBSA 2.3 のスキャンを実行してください。
MSXML 6.0 は、以下のサイトよりダウンロードしていただけます。
Microsoft Core XML Services (MSXML) 6.0
http://www.microsoft.com/ja-jp/download/details.aspx?id=3988