Quantcast
Channel: Japan WSUS Support Team Blog
Viewing all 179 articles
Browse latest View live

WSUS 起動時のスナップインエラーについて

$
0
0

皆さま こんにちは。 マイクロソフトの香取です。

 

本日は WSUS 起動時のスナップインエラーの対処方法についてご紹介します。

 

WSUS 管理者様より WSUS 管理コンソール起動時にスナップインエラーが表示され、WSUS 管理コンソールが起動できなくなったとお問い合わせいただくことがあります。

調査の結果、あるレジストリ値が欠損している場合に、WSUS 管理コンソールが起動できなくなることがわかりました。

もし WSUS 管理コンソールが起動しない事象が発生した場合には、この手順でレジストリ欠損の有無をご確認ください。

 

※以下は WSUS 3.0 SP2 用の手順です。

 

【 事象 】

1. WSUS 管理コンソール起動時に以下のようなスナップインエラー (スナップインのエラーが MMC により検出されたので、スナップインがアンロードされます。) が表示されます。

[OK] ボタンをクリックします。

 

 

2. [OK] ボタンをクリックすると、”スナップインを初期化できません。” と表示されます。

 

 

3. WSUS 管理コンソールが正常に起動できません。

 

または、

WSUS 管理コンソール上に、以下のような CLSID 情報が表示され、正常に起動できません。

 

 

 

このような現象が発生した場合の、対処手順といたしましては以下の通りとなります。

 

【 対処手順 】

1. WSUS サーバーにて [管理者として実行] でレジストリを起動します。

 

2. 以下のキーを検索します。

HKLM\software\microsoft\mmc\SnapIns\FX:{8b6499ed-0241-e032-6508-da4b1c879d7e}

 

3. 値 Type が空になっていることを確認します。

 

 

4. 以下の情報をコピーし、貼り付けます。  (一行で入力します)

Microsoft.UpdateServices.UI.SnapIn.Common.SnapInManager, Microsoft.UpdateServices.UI.SnapIn, Version=3.1.6001.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35

 

5. WSUS 管理コンソールが正常に起動できたことを確認します。


Windows XP / Server 2003 のクリーン インストール後、Microsoft Update でループ

$
0
0

こんにちは、マイクロソフトの福島です。

今回は Windows Update / Microsoft Update の情報を投稿いたします。

# WSUS 環境は本現象の影響を受けないため、直接関係しない情報です。
# Windows Update 専用のサポート担当ブログは無いのでここに投稿いたします。
# ちなみに WSUS と Windows Update は同じ担当者がサポートしております。

 

Windows XP SP3 や Windows Server 2003 SP2 をクリーン インストールし、その後 Windows Update を実行するとき、接続先を「Microsoft Update」に切り替えると、うまくいかず何度も同じ画面に戻ってしまうことがあります。

この事象は、上記 OS の初期状態に含まれている Windows Update クライアント モジュールが非常に古いことと関連しています。

同じく Windows XP SP3 でも、最近まで定期的に Windows Update / Microsoft Update を実行されていた環境では、新しいバージョンの Windows Update クライアントにアップされているため発生しません。

 

■現象

Windows XP / Windows Server 2003 で、Windows Update サイトへ接続し、「Microsoft Update」への切り替えを試みると、「最新バージョンのWindows更新ソフトウェアを確認しています」などのメッセージが繰り返し表示され、更新プログラムの処理を始めることができない。

 

■対処方法

下記をお試しください。

方法A.) Windows Update Agent の手動更新

方法B.) 自動更新による Microsoft Update の実行

 

 方法A.) Windows Update Agent の手動更新

 

1. 下記の弊社サポート技術情報より、Windows Update Agent のインストーラをダウンロードし、問題が発生しているコンピューターのローカルに保存します。

 "Windows Update エージェントの最新バージョンを入手する方法に関する、ネットワーク管理者向けの情報"

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

2. 問題が発生しているコンピューターで、コマンド プロンプトを管理者権限で起動し、上記ファイルを保存したフォルダへ移動します。

3. コマンド プロンプトで Windows Update Agent 3.0 のインストーラを下記のように /WUFORCE オプション付きで実行します。

- 実行例 :

WindowsUpdateAgent30-x86.exe /WUFORCE

 ※注意: インストーラをダブルクリックする方法では、目的の手動適用ができませんので、ご面倒ですがコマンドにて上記オプション付きにてお試しください。

4. インストール ウィザードを進めてインストールを完了します。

5. Microsoft Update を実行し、現象が改善するかご確認ください。

  

方法B.) 自動更新による Microsoft Update の実行

Internet Explorer の画面を終了した状態で Microsoft Update への接続を行います。これには次のように行います。

 

1. Internet Explorer 画面がもし起動していたら、すべて閉じます。

2. [スタート]ボタンから [ファイル名を指定して実行] をクリックし、gpedit.msc と入力して実行します。

3. 左ペインにてフォルダを以下のように展開します。

[コンピュータの構成]

 -[管理用テンプレート]

  -[Windows コンポーネント]

   -[Windows Update]

4. 右ペインの [自動更新を構成する] をダブルクリックして開き、既存の設定内容を確認した上で、以下のように設定変更して [OK] をクリックします。

 ・自動更新を構成する「有効」

 ・自動更新の構成「2-ダウンロードとインストールを通知」

 ※この設定は、後述の手順 7 で元の内容に戻します。既定では「未構成」です。

5. そのまま 5 分間ほど、お待ちください。その後、コマンド プロンプトを起動して、以下のコマンドを実行します。

 wuauclt /detectnow

6. さらにそのまま 5 ~10 分間ほど、お待ちください。その後 Internet Explorer を起動して Microsoft Updateサイトへ接続し、問題事象が改善されているかどうかをご確認ください。

7. 設定を元に戻すため、上記手順 2~ 3 と同じ要領で [自動更新を構成する] を開き、手順 4 で確認した元の設定に戻して、[OK] をクリックします。

 

WSUS の更新プログラムは確実に最新版の適用を行ってください

$
0
0

弊社米国本部の WSUS 開発部門より通達があり、ご案内をいたします。

WSUS の更新プログラムは、全 WSUS サーバーにおいて、確実に適用を行っていただきますようお願いいたします。
OS やアプリケーションの通常の更新プログラムにおける、「問題が発生した時のみ任意に適用いただく」という考え方ではありませんので、ご注意願います。

上記につきまして、背景にあるのは以下のような考え方となります。

1.  企業全体のシステムのセキュリティを司る WSUS サーバーにおいて、最大限の安定性を保証する必要がある。
2.  いくつかの WSUS の更新においては、Windows Update エージェントの更新が不可欠となる。セキュリティ更新プログラムは、各企業が任意のテストを実施いただき、適用可否や時期を検討いただくことに差支えないが、そのアップデート適用を各クライアントで行う Windows Update エージェントについては最新版とすることが任意ではなく、サポート上必須である。Windows Update エージェントは、WSUS サーバーとの通信課程で自動アップグレードされるため、WSUS サーバーを常に最新版とする必要がある。

 

WSUS サーバーのアップグレードに伴う懸念点の解消や、アップグレードに伴うトラブルシュートについては、サポート部門にてご支援をいたしますので、お気軽にご相談をお寄せください。

弊社開発部門におきましても、WSUS の更新プログラムの提供頻度を最小に心がけ、また、適用時に発生する問題も最小限とするよう、開発とテストについて尽力してまいります。
また、弊社サポート部門におきましては、WSUS 更新プログラムのリリースや、適用にあたっての注意事項については、本ブログにて最速での情報発信を心掛けてまいります。
ご不便をおかけしますが、何卒ご協力をいただきますようお願いいたします。

 

2013 年 3 月 13 日現在、WSUS 3.0 SP2 用の更新プログラムの最新版は KB2734608 となります。
適用時の注意点等、詳細は以下ポストをご参考ください。

WSUS 3.0 SP2 の Windows 8 / Windows Server 2012 対応について (KB2734608)
http://blogs.technet.com/b/jpwsus/archive/2012/09/05/kb2734608.aspx

Internet Explorer 10 ( Windows Server 2008 R2 用 ) のタイトル誤表記について

$
0
0

こんにちは、マイクロソフトの福島です。

今回は Windows Update / Microsoft Update の情報を投稿いたします。

# WSUS に対しては、まだリリースはされていませんので、本現象の影響は受けません。
# Windows Update 専用のサポート担当ブログは無いのでここに投稿いたします。
# ちなみに WSUS と Windows Update は同じ担当者がサポートしております。

 

先日、Internet Explorer 10 (以下 IE10) が Windows Update から配信開始されましたが、その Windows Update / Microsoft Update カタログに表示されるタイトル上に誤記があります。Windows Server 2008 R2 用の日本語タイトルが、以下のとおり ”Internet Explorer 9” (以下IE9) と表示されてしまいます。

こちら目下、修正を行っておりますので申し訳ございませんがしばらくお待ちください。現時点の予定としましては日本時間 3/27 (水) 頃の修正リリースを目指し準備中という状況です。

なお、この問題は Windows Update および Microsoft Update カタログに表示される「日本語タイトル情報」のみであり、実際にインストールされる内容には問題ありません ( 正しい IE10 が配信されます )。また Windows Update を経由せず、弊社ダウンロード センターからダウンロード提供されるパッケージについては影響ありません。

 

 

2013/03/27 追記

本日、予定どおり修正されております。大変ご迷惑をお掛けいたしました。

 

 

MS13-054 : KB2687276 ( Office 2010 用セキュリティ更新プログラム ) が着信しない

$
0
0

こんにちは、マイクロソフトの福島です。

本日 公開されたセキュリティ更新プログラム MS13-054のうち Office 2010 用のパッケージ KB2687276が、「WSUS サーバーに着信しないことがある」 という問題が見つかりましたので、取り急ぎご報告いたします。

この問題の影響を受けるかどうかは、WSUS サーバーのオプション「更新ファイルと更新言語」の言語設定に依存します。

WSUS の言語オプションの選択に「英語」が含まれていれば影響を受けませんが、「英語」が指定されていない場合、その WSUS サーバーは現在、KB2687276 を受信することができません。

これは更新プログラムの本体ではなく、配信管理用の情報における問題であると考えられます。現在、調査に入っておりますので、この影響を受けているお客様は、たいへん申し訳ございませんが、今しばらくお待ちください。修正次第リビジョンがリリースされ、その結果 WSUS サーバーに着信するようになる見込みです。

大変ご迷惑をお掛けいたしますことお詫び申し上げます。

 

2013/07/11 追記

本日、修正されております。( リビジョン # 202 ) ただし WSUS の同期実行時刻によっては、まだ着信できていないケースもあるようですので、大変お手数ですが、手動にて同期を実行するなどにて、ご確認をいただけましたら幸いです。

なお オフライン カタログ ファイル wsusscn2.cab の修正にはさらに あと一、二営業日ほど頂く予定です。恐れ入りますが cab ファイルをご利用のお客様はもう少々、お待ちください。

ご迷惑をお掛けしましたこと重ねてお詫び申し上げます。

レプリカ WSUS サーバーの同期がタイムアウトで失敗する

$
0
0

皆さま こんにちは。 マイクロソフトの香取です。

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 サーバーの再構築を検討します。
配信不要な「製品」 および 「クラス」 を同期対象から削除して再構築して頂く事によって、不要なデータが蓄積されていないクリーンな状態で運用して頂け、その結果として、レプリカ同期失敗の事象発生を回避する事が可能です。

 

ご案内は以上となります。

Windows 8 / Windows Server 2012 では 「自動インストール」 の動作が変更されております

$
0
0

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

既にご存知の方も多いかと思いますが、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 サーバーから配信した更新プログラムの内容と "インストールされた更新プログラム" の表示内容が一致しない

$
0
0

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


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 がリストされることになります。

 

 


ユーザーが更新プログラムを手動でインストールできないようにし、バックグラウンドでの自動インストールのみに制御したい。

$
0
0

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

ユーザーが、コンピューターの管理者権限を持つアカウントでログオンしている場合、Windows Update の動作が「自動インストール」の設定になっている場合でも、ユーザーは以下の操作を行うことが可能です。

-   Windows Update 画面から更新プログラムのインストールを任意のタイミングで開始・停止する
-   インストール対象とならないように、更新プログラムを "非表示" に設定する

このような、ユーザーの手動操作の自由度を一切なくしたい、という場合には、「対話的な操作を行えないようにする / アイコンやバルーンを表示しないようにする」ためのグループポリシーがありますので、その設定をご検討ください。

 

手順:
=======================
以下のポリシーを「有効」に設定します。

~~~~~~~~
[ユーザーの構成]
 [管理用テンプレート]
  [Windows コンポーネント]
    [Windows Update]

- [Windows Update のすべての機能へのアクセスを削除する] ポリシー
~~~~~~~~
なお、これを設定しますと、Windows Update 画面から "更新プログラムの確認" の実行や、インストール・ダウンロードの開始、wuauclt /detectnow コマンドの実行等、あらゆる手動操作ができなくなりますのでご注意ください。

また、この設定だけでは、Windows Update のアイコンやバルーンが一切、表示されなくなります。
自動更新の構成が 「4. 自動ダウンロードしインストール日時を設定」 になっている場合、インストール後の自動再起動に関するポップアップまでも表示されず、いきなり再起動が開始されるという結果になってしまいます。
これでは予期しない再起動が発生しますので、さらに次の設定を追加することによって「再起動のポップアップ通知だけは表示する」ことをお勧めいたします。

~~~~~~~~
「Windows Update のすべての機能へのアクセスを削除する」ポリシーのプロパティのオプション項目として「通知の構成」が表示されていたら (※)、その選択肢をクリックし「1-再起動が必要であることを示す通知を表示する」を指定します。
~~~~~~~~

(※) このポリシーに「通知の構成」オプションが存在しないという場合は、お使いのポリシー テンプレートが少し古いバージョンだと思われます。
その場合は、同じフォルダ内に「Windows Update 通知を有効にする」という別のポリシー項目が存在するはずですので、これを「有効」に設定すれば、同じ結果が得られます。

Windows Update の "更新履歴の表示" が示す内容について

$
0
0

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

WSUS クライアント / Windows Update に関するトラブルシュートの際に、「%windir%\SoftwareDistribution」フォルダをリネームするという、Windows Update のキャッシュ削除の対処をご案内する事が多くございます。

ところがこれを実施すると、Windows Update の「更新履歴の表示」の情報が消去される、という副作用があり、この点についてご懸念を伺うことがあります。
本日は、そのご懸念に対する回答についてご案内いたします。

 

- 回答:
-----------------
「更新履歴の表示」は、更新プログラムの適用有無を判断する材料としては使うことができない情報であり、また今後の更新プログラムの適用動作には一切影響しないことから、削除しても差し支えありません

 

- 説明回答解説:
-------------------------
「更新履歴の表示」が示す情報は「WSUS ( またはWindows Update ) クライアントが、更新の適用を試みたという事実、およびその結果」のみです。
Windows Update を利用しない、ユーザー様が明示的に適用した更新プログラムについては( OS にもよりますが ) この履歴では確認ができません。

また履歴上「更新プログラム A をインストールした」とされていても、その後、手動で A をアンインストールしてしまうと、更新履歴からはそのことが判別できません。
このように、更新プログラムの真の適用状況 / システム内の脆弱性の有無を判断するための情報源としては機能しない内容となっています。

では、そのような適用プログラムの要否や脆弱性の有無のチェックは、Windows Update はどうやって行っているかですが、これは履歴情報を参照するのではなく、その時点のシステムの状態 (ファイル バージョン等) をそのつど確認して判定しています。
チェックの結果は、WSUS サーバーに、各クライアントの状態レポートとして格納されていますので、通常はそれを管理情報としてお使いいただけばよいという考え方となっています。

なお「%windir%\SoftwareDistribution」フォルダ自体が、OS のバックアップやスナップショットの対象からも除外されておりますので、システムのリストアを行うとやはりこの情報は消去されます。
この観点からも、更新プログラムの真の適用状況 / システム内の脆弱性の有無を判断するための情報源としては機能しない内容とご理解頂ければと存じます。

KB2760411, KB2760588, KB2760583 がインストール後にも再度検出される

$
0
0

最終更新
~~~~~~~~~~~
米国時間 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 4.0 (Windows Server 2012) アンインストール手順 について

$
0
0

更新 (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 サーバー、IISWindows 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 を右クリックし、 [削除]  ボタンで削除します。

 

ご案内は以上となります。

Windows XP や Windows Server 2003 環境において、Windows Update 実行時に Svchost.exe の CPU 使用率が 100 % となる、時間を大幅に要する

$
0
0

皆さま、こんにちは。
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 の累積的なセキュリティ更新プログラム」を事前に単独で配信しインストール完了させる。

- 暫定対処策 (2)

承認状態とする「Internet Explorer の累積的なセキュリティ更新プログラム」を 1 点のみとし、その他 WSUS サーバー上に同期されているすべての「Internet Explorer の累積的なセキュリティ更新プログラム」については、すべて拒否済みに設定して頂く。
この場合、その他の更新プログラムを同時に承認して頂いても問題ありません。

※補足 1
現時点において最新の Internet Explorer の累積的なセキュリティ更新プログラムは、10 月公開分の KB2879017 となります。
最新の Internet Explorer の累積的なセキュリティ更新プログラムは過去に公開された Internet Explorer の累積的なセキュリティ更新プログラムの修正内容をすべて含んでおりますので、最新のもののみを承認して、古いものをすべて拒否済みに設定して頂いて問題ございません。

※補足 2
以下の手順にて「Internet Explorer の累積的なセキュリティ更新プログラム」をまとめて拒否済みに設定する事ができます。
(なお、同時に選択して拒否済みとする件数は、WSUS の負荷状況に応じて調整して下さい。)

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

 

WSUS からエクスポートしたカタログファイルが 0KB になる事象について

$
0
0

 

************* 16/5/2013 Update ************* 

WSUS からエクスポートしたカタログファイルが 0KB になる事象 を解決するプログラムがリリースされております。

 詳細につきましては以下のサイトをご覧ください。

 WSUS からエクスポートしたカタログファイルが 0KB になる事象について - 続報
http://blogs.technet.com/b/jpwsus/archive/2013/05/16/wsus-cab-0kb.aspx

*******************************************

 

 

皆さま こんにちは。 マイクロソフトの香取です。

 

本日は WSUS サーバーからエクスポートしたカタログファイル (CAB ファイル) が 0 KB になる事象の原因 と その暫定回避方法についてご紹介します。

 

【 エクスポートしたカタログファイルが 0 KB になる事象の原因 】

WSUS サーバーの機能として、 wsusutil.exe コマンドを実行することによりカタログを親 WSUS よりエクスポートし、インターネットの接続が制限または制約されているネットワークに存在する 子 WSUS サーバーへカタログを手動でインポートできます。

 

作成されるこのカタログ ファイルは CAB ファイル形式の技術的な制約から、2 GB までとのサイズ制限があります。

 

また、WSUS サーバーは運用期間に比例して データベース内のカタログ データが蓄積、増大していく傾向があります。

WSUS サーバーは明示的にクリーンアップをしない限り、データベース内のカタログ情報が減少することは無いためです。

 

一方、 wsusutil.exe  によるエクスポート動作は、その時点でデータベースに存在する全ての更新プログラム情報を抽出し、カタログ ファイルとして出力します。

 

そのため、運用中のある時点で、出力結果が 2 GB の制限を超えることがあります。

この状態に至った場合、WSUS サーバーからカタログファイルをエクスポートしようとすると、エクスポートが失敗し、出力された CAB ファイルが 0 KB となる事象が発生します。

 

なお、この事象につきましては弊社として製品の問題として認識しており、対応方法について検討中です。

修正され次第、本ブログなども通じてお伝えしていく予定です。

 

 

WSUS 管理者様には本事象が発生した場合の暫定回避方法をご案内します。

 

 

【 暫定回避方法 】

3 つの回避方法をご紹介します。 いずれも暫定的な対処となりますが、運用に沿った回避方法をお試しください。

 

方針1: クリーンアップを実施する。

ウィザードで実施する場合:

[WSUS 管理コンソール ] - [オプション] - [サーバー クリーンアップ ウィザード]

- [不要な更新および更新のリビジョン] を定期的に実行する。

 

階層構造のWSUS レプリカ構成が存在する場合には以下のサイトを参照ください。

レプリカ構成では サーバー クリーンアップ ウィザード にご注意ください

http://blogs.technet.com/b/jpwsus/archive/2012/06/08/3502667.aspx

 

PowerShell で実施する場合:

以下のサイトを参照し、CompressUpdates と CleanupObsoleteUpdates を

実行します。適宜テストし、ご利用ください。

 

WSUS Cleanup (英語版)

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

 

 

方針2: 更新プログラムの対象となる 「製品とクラス」 を減らす。

今後の同期対象を必要最小限に留める手法です。

既に過去に同期済みの更新プログラムのメタデータは削除されないまま残るため、方針 1 のクリーンアップと併せて実施ください。

 

 

方針3 : WSUS サーバーのデータベースを含めて再構築を行う。

方針 1 と 2 を実施した後にも現象が改善しない場合には、データベース内に格納されたカタログ情報を強制的に削減するため、WSUS サーバーをデータベースを含めて再構築する方法をご検討ください。

再構築を行う際には、同期対象に設定する更新プログラムのクラスや製品を精査し、最小限に設定してください。

再構築前と同じ量の更新プログラムを同期対象とした場合には、数日後同じだけのカタログ情報がデータベース内に格納され、同様の現象が発生する事が考えられます。

 

WSUS サーバーで、一部のダウンロードが失敗する ( File cert verification failure )

$
0
0

こんにちは、マイクロソフトの福島です。

 

最近、新しく構築された WSUS サーバーなどで、更新プログラムの一部がダウンロードに失敗する、とお伺いすることがあります。

調べてみますと、WSUS サーバーに、更新プログラム:KB2749655 が適用されていないことがポイントでした。

 

この現象に合致する場合は、WSUS のログ (※) に、以下のような記録が出力されています。( イベント ログだけでは残念ながらわかりません )

 

(※)  %programfiles%\Update Services\LogFiles の SoftwareDistribution.log

    黄色部分が現象判別のポイントです。

―――――――――――――――――――――――――――

2013-01-25
06:42:14.309 UTC Info WsusService.14 CabUtilities.CheckCertificateSignature File cert verification failed
for d:\WSUS\WsusContent\3E\2C6AB49C5353003F7CBEE327195137A8A9DA4F3E.exe with 2148204801

2013-01-25 06:42:14.316 UTC Warning WsusService.14
ContentSyncAgent.WakeUpWorkerThreadProc Invalid file deleted:
d:\WSUS\WsusContent\3E\2C6AB49C5353003F7CBEE327195137A8A9DA4F3E.exe

―――――――――――――――――――――――――――

 

昨年リリースされた弊社の更新プログラムの中には、KB2749655 に記載された “問題を含む証明書” を使ってファイル署名されたものがあります。

こうした不適切な署名を持つファイルは、証明書の期限が切れると、正常に検証が行われなくなります。期限切れ後のタイミングで WSUS サーバーがファイルの取得を試みますと、ファイル検証動作に失敗し、結果としてダウンロードが失敗に終わります。

KB2749655 を WSUS サーバーへ適用すれば、問題点への対処がなされ、正常にダウンロードを完了できるようになります。

 

なお、ファイル検証動作はダウンロード時点で発生しますので、問題の証明書の期限が切れる前に、こうしたファイルのダウンロードを既に済ませた WSUS サーバーでは、問題が発生しません。

反対に次のようなケースでは、問題が発生する可能性が大いにありますので、お手数ですが、KB2749655 の適用をぜひご検討ください。

・2013 年になってから、WSUS を新規セットアップし更新プログラムの取得を開始した。

・しばらく (数か月) 同期を行っていなかった WSUS を、最近久しぶりに同期し、更新プログラムを取得した。

 

なお、インターネットに接続していないWSUS や、レプリカ構成の 子WSUS サーバーでも、ファイル検証時に同じ問題が発生し、クライアントへの配信ができなくなる可能性がありますので、KB2749655 の適用をお願いいたします。

 

情報:

更新プログラム:KB2749655 については以下のページをご参照ください。

当更新はWSUS や Windows Update でも「重要な更新」というクラスで提供されています。

 

マイクロソフト セキュリティ アドバイザリ (2749655)

署名されたマイクロソフトバイナリに影響を与える互換性の問題

http://technet.microsoft.com/ja-jp/security/advisory/2749655

 

ダウンロードはこちらから:

マイクロソフト セキュリティ アドバイザリ: 署名済みマイクロソフト バイナリに影響する互換性の問題

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

 


WSUS 起動時のスナップインエラーについて

$
0
0

皆さま こんにちは。 マイクロソフトの香取です。

 

本日は WSUS 起動時のスナップインエラーの対処方法についてご紹介します。

 

WSUS 管理者様より WSUS 管理コンソール起動時にスナップインエラーが表示され、WSUS 管理コンソールが起動できなくなったとお問い合わせいただくことがあります。

調査の結果、あるレジストリ値が欠損している場合に、WSUS 管理コンソールが起動できなくなることがわかりました。

もし WSUS 管理コンソールが起動しない事象が発生した場合には、この手順でレジストリ欠損の有無をご確認ください。

 

※以下は WSUS 3.0 SP2 用の手順です。

 

【 事象 】

1. WSUS 管理コンソール起動時に以下のようなスナップインエラー (スナップインのエラーが MMC により検出されたので、スナップインがアンロードされます。) が表示されます。

[OK] ボタンをクリックします。

 

 

2. [OK] ボタンをクリックすると、”スナップインを初期化できません。” と表示されます。

 

 

3. WSUS 管理コンソールが正常に起動できません。

 

または、

WSUS 管理コンソール上に、以下のような CLSID 情報が表示され、正常に起動できません。

 

 

 

このような現象が発生した場合の、対処手順といたしましては以下の通りとなります。

 

【 対処手順 】

1. WSUS サーバーにて [管理者として実行] でレジストリを起動します。

 

2. 以下のキーを検索します。

HKLM\software\microsoft\mmc\SnapIns\FX:{8b6499ed-0241-e032-6508-da4b1c879d7e}

 

3. 値 Type が空になっていることを確認します。

 

 

4. 以下の情報をコピーし、貼り付けます。  (一行で入力します)

Microsoft.UpdateServices.UI.SnapIn.Common.SnapInManager, Microsoft.UpdateServices.UI.SnapIn, Version=3.1.6001.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35

 

5. WSUS 管理コンソールが正常に起動できたことを確認します。

Windows XP / Server 2003 のクリーン インストール後、Microsoft Update でループ

$
0
0

~~~~~~~~~
Update 2013/8/26
~~~~~~~~~
Microsoft Update の画面がループする事象の他に、エラーコード 0x8024D001 が画面に表示され、更新が実行できない事があるとの報告もございます。
このような事象が発生した場合にも、下記にご案内しております 2 点の方法にて、回避して頂く事が可能です。

 

 

こんにちは、マイクロソフトの福島です。

今回は Windows Update / Microsoft Update の情報を投稿いたします。

# WSUS 環境は本現象の影響を受けないため、直接関係しない情報です。
# Windows Update 専用のサポート担当ブログは無いのでここに投稿いたします。
# ちなみに WSUS と Windows Update は同じ担当者がサポートしております。

 

Windows XP SP3 や Windows Server 2003 SP2 をクリーン インストールし、その後 Windows Update を実行するとき、接続先を「Microsoft Update」に切り替えると、うまくいかず何度も同じ画面に戻ってしまうことがあります。

この事象は、上記 OS の初期状態に含まれている Windows Update クライアント モジュールが非常に古いことと関連しています。

同じく Windows XP SP3 でも、最近まで定期的に Windows Update / Microsoft Update を実行されていた環境では、新しいバージョンの Windows Update クライアントにアップされているため発生しません。

 

■現象

Windows XP / Windows Server 2003 で、Windows Update サイトへ接続し、「Microsoft Update」への切り替えを試みると、「最新バージョンのWindows更新ソフトウェアを確認しています」などのメッセージが繰り返し表示され、更新プログラムの処理を始めることができない。

 

■対処方法

下記をお試しください。

方法A.) Windows Update Agent の手動更新

方法B.) 自動更新による Microsoft Update の実行

 

 方法A.) Windows Update Agent の手動更新

 

1. 下記の弊社サポート技術情報より、Windows Update Agent のインストーラをダウンロードし、問題が発生しているコンピューターのローカルに保存します。

 "Windows Update エージェントの最新バージョンを入手する方法に関する、ネットワーク管理者向けの情報"

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

2. 問題が発生しているコンピューターで、コマンド プロンプトを管理者権限で起動し、上記ファイルを保存したフォルダへ移動します。

3. コマンド プロンプトで Windows Update Agent 3.0 のインストーラを下記のように /WUFORCE オプション付きで実行します。

- 実行例 :

WindowsUpdateAgent30-x86.exe /WUFORCE

 ※注意: インストーラをダブルクリックする方法では、目的の手動適用ができませんので、ご面倒ですがコマンドにて上記オプション付きにてお試しください。

4. インストール ウィザードを進めてインストールを完了します。

5. Microsoft Update を実行し、現象が改善するかご確認ください。

  

方法B.) 自動更新による Microsoft Update の実行

Internet Explorer の画面を終了した状態で Microsoft Update への接続を行います。これには次のように行います。

 

1. Internet Explorer 画面がもし起動していたら、すべて閉じます。

2. [スタート]ボタンから [ファイル名を指定して実行] をクリックし、gpedit.msc と入力して実行します。

3. 左ペインにてフォルダを以下のように展開します。

[コンピュータの構成]

 -[管理用テンプレート]

  -[Windows コンポーネント]

   -[Windows Update]

4. 右ペインの [自動更新を構成する] をダブルクリックして開き、既存の設定内容を確認した上で、以下のように設定変更して [OK] をクリックします。

 ・自動更新を構成する「有効」

 ・自動更新の構成「2-ダウンロードとインストールを通知」

 ※この設定は、後述の手順 7 で元の内容に戻します。既定では「未構成」です。

5. そのまま 5 分間ほど、お待ちください。その後、コマンド プロンプトを起動して、以下のコマンドを実行します。

 wuauclt /detectnow

6. さらにそのまま 5 ~10 分間ほど、お待ちください。その後 Internet Explorer を起動して Microsoft Updateサイトへ接続し、問題事象が改善されているかどうかをご確認ください。

7. 設定を元に戻すため、上記手順 2~ 3 と同じ要領で [自動更新を構成する] を開き、手順 4 で確認した元の設定に戻して、[OK] をクリックします。

 

WSUS の更新プログラムは確実に最新版の適用を行ってください

$
0
0

弊社米国本部の WSUS 開発部門より通達があり、ご案内をいたします。

WSUS の更新プログラムは、全 WSUS サーバーにおいて、確実に適用を行っていただきますようお願いいたします。
OS やアプリケーションの通常の更新プログラムにおける、「問題が発生した時のみ任意に適用いただく」という考え方ではありませんので、ご注意願います。

上記につきまして、背景にあるのは以下のような考え方となります。

1.  企業全体のシステムのセキュリティを司る WSUS サーバーにおいて、最大限の安定性を保証する必要がある。
2.  いくつかの WSUS の更新においては、Windows Update エージェントの更新が不可欠となる。セキュリティ更新プログラムは、各企業が任意のテストを実施いただき、適用可否や時期を検討いただくことに差支えないが、そのアップデート適用を各クライアントで行う Windows Update エージェントについては最新版とすることが任意ではなく、サポート上必須である。Windows Update エージェントは、WSUS サーバーとの通信課程で自動アップグレードされるため、WSUS サーバーを常に最新版とする必要がある。

 

WSUS サーバーのアップグレードに伴う懸念点の解消や、アップグレードに伴うトラブルシュートについては、サポート部門にてご支援をいたしますので、お気軽にご相談をお寄せください。

弊社開発部門におきましても、WSUS の更新プログラムの提供頻度を最小に心がけ、また、適用時に発生する問題も最小限とするよう、開発とテストについて尽力してまいります。
また、弊社サポート部門におきましては、WSUS 更新プログラムのリリースや、適用にあたっての注意事項については、本ブログにて最速での情報発信を心掛けてまいります。
ご不便をおかけしますが、何卒ご協力をいただきますようお願いいたします。

 

2013 年 3 月 13 日現在、WSUS 3.0 SP2 用の更新プログラムの最新版は KB2734608 となります。
適用時の注意点等、詳細は以下ポストをご参考ください。

WSUS 3.0 SP2 の Windows 8 / Windows Server 2012 対応について (KB2734608)
http://blogs.technet.com/b/jpwsus/archive/2012/09/05/kb2734608.aspx

Internet Explorer 10 ( Windows Server 2008 R2 用 ) のタイトル誤表記について

$
0
0

こんにちは、マイクロソフトの福島です。

今回は Windows Update / Microsoft Update の情報を投稿いたします。

# WSUS に対しては、まだリリースはされていませんので、本現象の影響は受けません。
# Windows Update 専用のサポート担当ブログは無いのでここに投稿いたします。
# ちなみに WSUS と Windows Update は同じ担当者がサポートしております。

 

先日、Internet Explorer 10 (以下 IE10) が Windows Update から配信開始されましたが、その Windows Update / Microsoft Update カタログに表示されるタイトル上に誤記があります。Windows Server 2008 R2 用の日本語タイトルが、以下のとおり ”Internet Explorer 9” (以下IE9) と表示されてしまいます。

こちら目下、修正を行っておりますので申し訳ございませんがしばらくお待ちください。現時点の予定としましては日本時間 3/27 (水) 頃の修正リリースを目指し準備中という状況です。

なお、この問題は Windows Update および Microsoft Update カタログに表示される「日本語タイトル情報」のみであり、実際にインストールされる内容には問題ありません ( 正しい IE10 が配信されます )。また Windows Update を経由せず、弊社ダウンロード センターからダウンロード提供されるパッケージについては影響ありません。

 

 

2013/03/27 追記

本日、予定どおり修正されております。大変ご迷惑をお掛けいたしました。

 

 

Windows Update が 0x8024800A で失敗する

$
0
0

こんにちは、マイクロソフトの福島です。

今回も前回に続き、Windows Update / Microsoft Update の情報を投稿いたします。

# WSUS は 本現象の影響は受けません。
# Windows Update 専用のサポート担当ブログは無いのでここに投稿いたします。
# ちなみに WSUS と Windows Update は同じ担当者がサポートしております。

 

最近 「Windows Update が エラー 0x8024800A で失敗する」と、複数のお客様からご指摘をいただきました。

確認の結果、これは弊社サイト側に一過性の問題が生じていたことが原因であり、3/23 時点で問題が解消していることが判りましたので、ご報告させていただきます。

ただし、問題発生時のデータがコンピューター側にキャッシュされていると、その影響によってクライアントのエラーが現在も続いてしまう可能性があります。依然として 0x8024800A で失敗し続けているコンピューターがありましたら、まことに恐れ入りますが、データのクリアをお試しください。この手順は以下のとおりです。

 

コンピューター上のデータをクリアする手順

1)   管理者権限でコマンド プロンプトを起動し、以下のコマンドを実行して、サービスを停止します。

net stop wuauserv

net stop bits

2)   引き続き以下コマンドを実行して、フォルダをリネームします。リネーム先のフォルダ名は、ここでは SD.old としてありますが任意で結構です。またエクスプローラ画面から「名前の変更」を行ってももちろん結構です。

ren %windir%\SoftwareDistribution SD.old

3)   以下コマンドを実行して、サービスを再開します。

net start wuauserv

net start bits

 

※補足:上記手順の実施による影響:

・[更新履歴の表示] の情報がクリアされます。

・過去、クライアント側の操作にて「非表示」設定(処理対象から除外する)していた更新プログラムが存在する場合は、その設定が解除されます。

Viewing all 179 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>