※ 本件は、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 チームブログ（※12/17 アップデート内容がございます）をご覧ください。
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
(12/11 追記転載) 本現象の発生条件、ならびに弊社での本問題に対する対応状況について以下にお伝えいたします。
・本問題は Windows Update から KB3002339 の更新プログラムをインストールした場合に発生します。KB3002339 の更新プログラムをダウンロード センターから入手し、単体でインストールした場合には発生しません。
・KB3002339 の更新プログラムは、Visual Studio 2012 がインストールされている環境が適用対象となります。また、Visual Studio 2012 Shell (Isolated) を利用するアプリケーションがインストールされている場合も適用対象となることが想定されます。
・今回の問題について修正した新しいパッケージをリリースする予定です。リリースの日程が決まりましたら本 Blog でご案内します。なお、既に KB3002339 の更新プログラムがインストールみの環境では、特に問題が生じることはありませんので、処置を行っていただく必要はありません。
・本更新プログラムはセキュリティに関する修正ではありませんので、KB3002339 に記載されている現象が発生していない環境では、インストール時の問題が修正されたパッケージがリリースされるまで適用をお待ちいただいても問題はありません。
・KB3002339 の更新プログラムの適用後、Windows Update の画面でインストールが完了しない現象が発生した場合は、タスク マネージャーから “VS11-KB3002339.exe” プロセスを終了させることで処理を続行させることが可能です。その後、前述のダウンロード センターからインストーラー パッケージを入手し、更新プログラムを単体でインストールすることで現象を回避できる可能性があります。
(12/17 転載元追記) 本日 12 月 17 日 (米国時間 12 月 16 日)、Windows Update より KB3002329 が再リリースされました。再リリースされた更新プログラムでは、Windows Update としてのパッケージングに関する問題を修正しております。
KB3002329 の更新プログラムに含まれるモジュール自体には問題はございませんので、モジュールは変更されておりません。このため、既に KB3002329 を適用されている場合には、改めてご適用いただく必要はありません。
お客様には多大なご迷惑をおかけしておりますこと、深くお詫び申し上げます。
こんにちは。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 においてよくある「更新プログラムの検出処理ができない」「更新プログラムのダウンロード処理ができない」「更新プログラムが期待通りにインストール出来ない」場合に、まず実施いただきたい対処方法をご案内します。ご案内する手順については、エラーや発生事象別に原因を特定して対応するということを目的としたものではなく、とりあえずうまく動かない状況に直面したらまずはこれをやってみよう、ということを目的としたものになります。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 wuauservnet 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 bitsnet start wuauserv
e) 更新プログラム検出の確認上記の手順を実施後、以下のコマンドを実行して、更新プログラムの検出を実施します。wuauclt /resetauthorization /detectnow
または、コントロール パネルの Windows Update の UI から [更新プログラムの確認] をクリックします。約 5 ～ 10 分ほど待ち、更新プログラムのダウンロードおよびインストールが実施できるかどうかを確認します。手順は以上となります。
(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
本ポストでは、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、およびそれ以降のバージョンのマイクロソフト アカウントに対する脆弱性評価のサポートはしておりません。
今回は「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 担当チームの染谷です。本日は、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 の機能を有効にする必要がある場合には、後述の参考文献をご参照ください。
この後、インターネット経由で .NET Framework 3.5 のモジュールがダウンロードされます。インストールが完了するまではしばらく時間がかかりますので、終わるまで待ちます。.NET Framework 3.5 のインストールが完了したら、SQL Server Management Studio をインストールします。
この後、ウィザードを完了させ、SQL Server Management Studio のインストールを開始します。これで SQL Server Management Studio をインストールする手順は完了です。
Windows Internal Database へ接続してみよう！いよいよ WID に接続します。WID は、コンピューターの管理者権限を持つアカウントで接続する必要がありますので、作業を実行するアカウントに適切な権限が付与されていることを確認して操作を実施してください。
接続に成功すると、以下のようにデータベースの一覧が参照できます。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
2014/7/31 更新
～～～～～～～～～
TechNet の改版により内容を修正いたしました。
本ポストにて、WSUS サーバーでは、Microsoft から更新プログラムを取得するために、HTTP プロトコルにはポート 8530、HTTPS プロトコルにはポート 8531 を使用することをご案内いたしました。公開情報の修正にもとづき、リンクに情報を改版いたしました。
正しくは、「WSUS サーバーでは、Microsoft から更新プログラムを取得するために、HTTP プロトコルにはポート 80、HTTPS プロトコルにはポート 443 を使用」します。
皆さま こんにちは。 マイクロソフトの香取です。
本日は Windows Server 2012 の WSUS の主な変更点についてご紹介します。
現在、WSUS 3.0 SP2 をご利用いただいている WSUS 管理者様や今後、Windows Server 2012 にて WSUS の構築をご検討いただいていらっしゃる方々にご一読いただけますと幸いです。
－ WSUS の概要
－ WSUS 3.0 SP2 との Windows Server 2012 の WSUS の主な変更点
－ Windows Server 2012 の WSUS のインストールについて
【 WSUS の概要 】
WSUS の機能概要については下記の公開情報をご参照ください。
WSUS 3.0 SP2 との変更点についても、こちらでご紹介しております。
Windows Server Update Services の概要http://technet.microsoft.com/library/hh852345.aspx
【 WSUS 3.0 SP2 との Windows Server 2012 の WSUS の主な変更点 】
WSUS 3.0 SP2 との Windows Server 2012 の WSUS の主な変更点としましては、以下の 2 点です。
1. WSUS サーバー ⇔ WSUS クライアント間で利用される既定ポートは 80 、443 から 8530、8531 に変更されました。
WSUS 3.0 SP2 は 既定のポートが 80、443 に指定されておりました。Windows Server 2012 の WSUS では WSUS サーバー ⇔ WSUS クライアント間で利用される既定のポートが 80、443 から 8530、8531 に変更されました。また、Windows Server 2012 の WSUS にて親子構成を行った場合には、WSUS サーバー間の通信でもポート 8530、8531 が利用されます。しかし、WSUS サーバーが Microsoft から更新プログラムを取得する際は、Windows Server 2012 の WSUS でも WSUS 3.0 SP2 と同様にポート 80、443 が利用されます。
Step 1: Prepare for Your WSUS Deploymenthttp://technet.microsoft.com/en-us/library/hh852344.aspx
----------一部抜粋----------By default, the WSUS server uses port 80 for HTTP protocol and port 443 for HTTPS protocol to obtain updates from Microsoft.(中略)By default, the WSUS server uses port 8530 for HTTP protocol and port 8531 for HTTPS protocol to provide updates to client workstations.-----------------------------なお、以下の日本語の Technet の情報においては、修正が行われておりません。恐縮ですが、上記の英語の弊社公開情報をご参照くださいますようお願いいたします。手順1: WSUS 展開の準備を行うhttp://technet.microsoft.com/ja-jp/library/hh852344.aspx
----------一部抜粋----------既定では、WSUS サーバーでは、Microsoft から更新プログラムを取得するために、HTTP プロトコルにはポート 8530、HTTPS プロトコルにはポート 8531 を使用します。-----------------------------
2. Windows Server 2012 の WSUS のアンインストールは従来の手順では実施出来ません。
WSUS 3.0 SP2では、[コントロールパネル] - [プログラムと機能] からアンインストール時にデータベース、ログファイル、コンテンツを選択し、削除することができました。
Windows Server 2012 の WSUS では、アンインストール後も IIS 上の サイト、データベース、コンテンツ、いずれもすべて残ります。これらを削除したい場合は手動で別途、削除作業が必要となります。 こちらの詳細は、下記のブログ記事をご参照ください。
WSUS 4.0 (Windows Server 2012) アンインストール手順 についてhttp://blogs.technet.com/b/jpwsus/archive/2013/10/01/wsus4_2d00_0_2d00_uninstall.aspx
【 Windows Server 2012 の WSUS のインストールについて 】
Windows Server 2012 の WSUS のインストールについては、以下のサイトにサーバー マネージャーの [役割と機能の追加] から WSUS をインストールする手順が公開されております。
※ Windows Server 2012 の WSUS のインストーラーのご用意はなく、Windows Server 2012 の役割と機能の追加から構築してください。
手順 2: WSUS サーバーの役割をインストールするhttp://technet.microsoft.com/ja-jp/library/hh852338.aspx
また、Windows Server 2012 の WSUS のインストールをコマンドから実施する方法もあります。
STEP 1 ：サーバーマネージャーの 「役割と機能の追加」 から WSUS の追加を選択し、PowerShell で使用するための構成ファイルを作成します。
STEP 2 ： PowerShell を起動し、STEP 1 の構成ファイルを指定し、Install –WindowsFeature を実行します。
Install-WindowsFeaturehttp://technet.microsoft.com/en-us/library/jj205467.aspx
Installing WSUS on Windows Server “8” Beta using PowerShellhttp://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.------------------------------------------------------------------------
こんにちは。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 9http://support.microsoft.com/kb/2399238/en (英語)http://support.microsoft.com/kb/2399238/ja (日本語機械翻訳)
Prerequisites for installing Internet Explorer 10 in Windows 7 SP1http://support.microsoft.com/kb/2818833/en (英語)http://support.microsoft.com/kb/2818833/ja (日本語機械翻訳)
Prerequisite updates for Internet Explorer 11http://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
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 SSLhttp://blogs.technet.com/b/wsus/archive/2014/04/16/solution-to-kb2919355-preventing-interaction-with-wsus-3-2-over-ssl.aspx
弊社日本法人の公式コーポレート ブログの記事においても、ご紹介しております。
Windows 8.1 Update : WSUS での公開と展開タイミングの延長についてhttp://blogs.technet.com/b/microsoft_japan_corporate_blog/archive/2014/04/17/windows-8-1-update-wsus.aspx
2014/4/17 更新
WSUS への公開に関する blog 記事を公開いたしました。
Windows 8.1 Update (KB2919355) を WSUS に公開しました。http://blogs.technet.com/b/jpwsus/archive/2014/04/17/windows-8-1-update-kb2919355-wsus.aspx
本事象に関する KB も更新いたしました。
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 SSLhttp://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 サポートチームです。 今回は 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 サポートチームです。 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 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 サーバー自身には、データベースのインデックスをメンテナンスする機能が含まれていません。運用継続に伴ってデータベースのパフォーマンスが劣化する可能性があります。(※1)このメンテナンス用スクリプトが公開されていますので、これを利用し定期的にインデックスの再構成を実施いただくことをお勧めします。(※1) 例えばWSUS サーバーを運用するにあたり、定期的にクリーンアップ ウィザードを実施していただくことを推奨しておりますが、今まで、定期的にクリーンアップ ウィザードを実施していない場合は、クリーンアップ処理に数時間を要することもあります。処理完了までの時間を少しでも削減するために、まずはインデックスの再構成を行ってください。インデックスの再構成を行う手順は下記のとおりとなります。＜作業概要＞WSUS のデータベースである SUSDB に対して、下記ページに記載されている WSUS データベース メンテナンス用のスクリプトを実行します。スクリプトをコピーペーストする際の注意点をこちらの記事の最後に記載してございますので、ご一読ください。 (※2)スクリプトは WSUS サーバー上で実行してください。WSUS サーバーを親子構成している場合は、親子両方の WSUS サーバー上で実行してください。"Re-index the WSUS 3.0 Database"<http://go.microsoft.com/fwlink/?LinkId=87027>＜作業手順＞ご利用いただいているデータベース製品にあわせて、以下のいずれかの作業を実施してください。
どちらのデータベースを現在利用しているかにつきましては、WSUS サーバーの以下のレジストリから判断できます。"SqlServerName" の値が %computername%\MICROSOFT##SSEE となっていれば、WID です。それ以外は SQL Server です。※ Windows Server 2012 の場合は、MICROSOFT##WID となっていれば、WID です。
******[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup]“SqlServerName”******
＜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 認証※ Windows Server 2012 の場合、サーバー名は \\.\pipe\Microsoft##WID\tsql\query を指定してください。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 サポートチームです。更新プログラムの検出に関して、MBSA をご利用いただいているお客様も多いかと存じます。
今回は、昨年リリースされた最新版 MBSA 2.3 の要件について、ご案内いたします。
Microsoft Baseline Security Analyzerhttp://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.0http://www.microsoft.com/ja-jp/download/details.aspx?id=3988
皆さま、こんにちは。
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 の累積更新プログラムが公開された後 (来月のセキュリティ更新プログラムのリリース日以降) にご確認下さいますようお願いいたします。
事象解消までご迷惑をおかけいたしまして、誠にご不便をお掛けいたしました。
深くお詫び申し上げます。
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 サーバー上で拒否済みの設定対象となります。
更新 (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 を右クリックし、 [削除] ボタンで削除します。
ご案内は以上となります。
最終更新～～～～～～～～～～～米国時間 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
本件の事象につきましては、現在、弊社にて調査を実施しております。要因が判明次第、こちらの記事に情報を公開させて頂きますので、今しばらくお待ち下さい。
WSUS クライアント / Windows Update に関するトラブルシュートの際に、「%windir%\SoftwareDistribution」フォルダをリネームするという、Windows Update のキャッシュ削除の対処をご案内する事が多くございます。ところがこれを実施すると、Windows Update の「更新履歴の表示」の情報が消去される、という副作用があり、この点についてご懸念を伺うことがあります。本日は、そのご懸念に対する回答についてご案内いたします。
- 回答：-----------------「更新履歴の表示」は、更新プログラムの適用有無を判断する材料としては使うことができない情報であり、また今後の更新プログラムの適用動作には一切影響しないことから、削除しても差し支えありません
- 説明回答解説：-------------------------「更新履歴の表示」が示す情報は「WSUS ( またはWindows Update ) クライアントが、更新の適用を試みたという事実、およびその結果」のみです。Windows Update を利用しない、ユーザー様が明示的に適用した更新プログラムについては( OS にもよりますが ) この履歴では確認ができません。また履歴上「更新プログラム A をインストールした」とされていても、その後、手動で A をアンインストールしてしまうと、更新履歴からはそのことが判別できません。このように、更新プログラムの真の適用状況 / システム内の脆弱性の有無を判断するための情報源としては機能しない内容となっています。
では、そのような適用プログラムの要否や脆弱性の有無のチェックは、Windows Update はどうやって行っているかですが、これは履歴情報を参照するのではなく、その時点のシステムの状態 (ファイル バージョン等) をそのつど確認して判定しています。チェックの結果は、WSUS サーバーに、各クライアントの状態レポートとして格納されていますので、通常はそれを管理情報としてお使いいただけばよいという考え方となっています。
なお「%windir%\SoftwareDistribution」フォルダ自体が、OS のバックアップやスナップショットの対象からも除外されておりますので、システムのリストアを行うとやはりこの情報は消去されます。この観点からも、更新プログラムの真の適用状況 / システム内の脆弱性の有無を判断するための情報源としては機能しない内容とご理解頂ければと存じます。
ユーザーが、コンピューターの管理者権限を持つアカウントでログオンしている場合、Windows Update の動作が「自動インストール」の設定になっている場合でも、ユーザーは以下の操作を行うことが可能です。
- Windows Update 画面から更新プログラムのインストールを任意のタイミングで開始・停止する- インストール対象とならないように、更新プログラムを "非表示" に設定する
このような、ユーザーの手動操作の自由度を一切なくしたい、という場合には、「対話的な操作を行えないようにする / アイコンやバルーンを表示しないようにする」ためのグループポリシーがありますので、その設定をご検討ください。
手順：=======================以下のポリシーを「有効」に設定します。
～～～～～～～～[ユーザーの構成] [管理用テンプレート] [Windows コンポーネント] [Windows Update]
- [Windows Update のすべての機能へのアクセスを削除する] ポリシー～～～～～～～～なお、これを設定しますと、Windows Update 画面から "更新プログラムの確認" の実行や、インストール・ダウンロードの開始、wuauclt /detectnow コマンドの実行等、あらゆる手動操作ができなくなりますのでご注意ください。
また、この設定だけでは、Windows Update のアイコンやバルーンが一切、表示されなくなります。自動更新の構成が 「4. 自動ダウンロードしインストール日時を設定」 になっている場合、インストール後の自動再起動に関するポップアップまでも表示されず、いきなり再起動が開始されるという結果になってしまいます。これでは予期しない再起動が発生しますので、さらに次の設定を追加することによって「再起動のポップアップ通知だけは表示する」ことをお勧めいたします。
～～～～～～～～「Windows Update のすべての機能へのアクセスを削除する」ポリシーのプロパティのオプション項目として「通知の構成」が表示されていたら (※)、その選択肢をクリックし「1-再起動が必要であることを示す通知を表示する」を指定します。～～～～～～～～
(※) このポリシーに「通知の構成」オプションが存在しないという場合は、お使いのポリシー テンプレートが少し古いバージョンだと思われます。その場合は、同じフォルダ内に「Windows Update 通知を有効にする」という別のポリシー項目が存在するはずですので、これを「有効」に設定すれば、同じ結果が得られます。
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 がリストされることになります。
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 サーバーを長期的に運用していただいている管理者より、 「レプリカ 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 サーバーの再構築を検討します。配信不要な「製品」 および 「クラス」 を同期対象から削除して再構築して頂く事によって、不要なデータが蓄積されていないクリーンな状態で運用して頂け、その結果として、レプリカ同期失敗の事象発生を回避する事が可能です。