Partager via

Windows 製品の更新プログラム (KB) のインストールの失敗 … よくある質問

  • Article

本記事の最新版をフォーラムにて紹介しております。

記事の改訂が含まれる場合がございますので、フォーラムの情報を参照してください。
フォーラムへのリンク

こんにちは、Windows プラットフォームサポート Setup/Deployment チームの宮崎です。

”Windows 製品の更新プログラム (KB) のインストールの失敗 … ログ分析の進め方” で紹介しましたトラブルシューティングの進め方について、よくお寄せいただく質問とその回答を本記事で紹介いたします。

事象の発生や業務への支障を予防するにはどうすればいいか

本来、問題が発生しないことが最も望ましい形となりますが、以下のような要因で事象が発生することがあるため OS の仕組みだけで完全に予防することは技術的に困難となります。

  • 何等かの理由でプロセスや OS が不正に終了する
  • 弊社製品の利用方法として想定しない OS の内部パラメータの変更がされている（運用要件が優先され既定のサービスを強制的に無効化している等）
  • 何等かのサードパーティー製品のフィルタードライバー（OSの処理に介入するモジュール）の影響を受ける

更新プログラムのインストールの失敗は脆弱性の対応のため早急な解決が必要とされる一方で、トラブルシューティングは解決までに時間をかけて診断と対処のプロセスを繰り返していく必要があります。また、診断結果として現状復旧が不可能と判断されインプレースアップグレードや再構築が必要となることもございます。

運用方法自体を以下のように見直すことでこのような問題の発生頻度や影響を低減させることができます。

* 更新プログラムを定期的にインストールする（インストールの期間を空けない）

半年～１年に一度という長いスパンで更新プログラムを適用する運用計画は、脆弱性や機能を修正し問題を予防することが更新プログラムの目的であることを踏まえると、弊社の推奨いたしかねる運用方法となります。また、長期にわたって更新プログラムのインストール作業を行わないことで表面化しない問題が潜在する懸念があり、適用完了が早期に求められるタイミング（改元対応など）でトラブルが発生し適用計画がスムーズに進まない場合がございます。更新プログラムを定期的に適用いただくこと自体がヘルスチェックにつながりますので、ぜひご検討ください。

一方、業務の目的、更新プログラムの既知の問題、他のアプリケーションとの兼ね合いの観点からも適用計画の検討が必要です。各 OS の既知の問題は以下の URL に記載しておりますので、ぜひ活用にしてください。

* 業務機能を Azure に移管する

業務機能を OS から他のサービスに移管することで問題を発生させないようにすることが可能です。Microsoft では Windows の機能の一部は Azure にて同等以上の内容を提供しており、クラウドに業務機能を移管することで更新プログラムの管理以外の側面からも運用コストを低減できます。

- 参考情報

PaaS とは - サービスとしてのプラットフォーム

* マシンのインプレース アップグレード、再構築、再展開自体を業務フローに入れる

不整合（ファイルやレジストリ情報の欠損など）によるトラブルなどは発生台数が一部となるため、原因追及に進まずにインプレース アップグレード・再構築・再展開を進めることで迅速かつ確実に解決いただけます。

一度のログ採取で原因のすべてを洗い出すことはできるか

不整合が潜在的に複数ある場合、最初の不整合の箇所でインストールが失敗し処理が中断されてしまう場合があります。そのため、分析・対処・再適用の繰り返しが必要となる場合があります。

なお、"Windows 製品の更新プログラム (KB) のインストールの失敗 … 一般的な対処策" で紹介しました一般的な対処策 A (DISM /Restorehealth コマンド及びシステム更新準備ツール) や 対処策 B (SFC コマンド) では網羅的にシステムのヘルスチェックを行い同時に複数の不整合を検出できる場合がございます。このような一般的な対処策を実施せずにログ分析に進むことは、システム全体の状況を鑑みずに詳細調査に進む工程となります。紹介している対処策はいずれもリスクが低く、実施いただきやすいものとなっておりますので、初期対応としてご検討ください。

不整合（何等かの情報の欠落など）に至った根本原因を追究できるか

不整合（何等かの情報の欠落など）に至った根本原因をログから判断することは、残念ながら技術的にできません。これは調査に用いる Setup イベントログや CBS ログ等はあくまでも操作やコンポーネントへの処理の過程のみを記録しており、OS のすべての状態を逐次、記録していないためです。

ファイル・レジストリのアクセス処理を網羅的に監視する方法として Process Monitor や、ある特定のプロセスをステップ単位で記録する方法として Time Travel Debugging があります。しかし、これらはシステムへの負荷が大きく常時稼働が現実的でないツールとなります。また、根本原因の調査を行う場合には不整合自体が発生させる最小限の再現手順が必要となりますが、通常、不整合の発生タイミングや手順の特定自体が困難となります。一方、OS の標準機能である監査は負荷の低い機能となりますが、このような問題に対して一般的に採取できる情報が十分でなく不整合の特定を行うには不十分な調査手法となります。

不整合を完全に予防することは技術的に困難であり、トラブル発生時にトラブルシューティングできる運用体制を整えていただくことをお勧めいたします。

サードパーティー製品のアンインストールでの切り分けする理由について

よくお客様から質問いただく一つに「事象が発生しているマシンと発生していないマシンは、運用用途も動作しているソフトウェアも全く一緒だから、事象が発生しているマシンであえてソフトウェアのアンインストールなどの切り分けを行う必要がないのではないか」というお問合せをいただくことがございます。

事象が発生しているマシンと発生していないマシンで同様の作業・運用をしていても、マシンごとの細かな内部情報によって条件分岐の差異が生じ異なる処理が行われる場合がございます。例えば、あるモジュールにおいて特定の条件・一定の確率のみ発生する動作があり、端末ごとに動作が異なることはコンピューター・ソフトウェアという仕組み上、発生する可能性がございます。事象が発生していないマシンとの比較は切り分けを行う作業の優先順位付けとしては有用な情報とはなりますが、必ずしも事象が発生しているマシンの対処プランを限定しないことにご注意ください。

なお、フィルター ドライバーは主に以下のようなソフトウェアに含まれるモジュールとなります。

  • セキュリティ対策ソフト
  • バックアップソフト
  • 暗号化ソフト
  • 資産管理ソフト

更新プログラムが適用できない直接の原因としてサードパーティー製品が影響している場合（例えば、システム ファイルへのアクセスを意図せずブロックしている場合など）、最も確実な切り分けはアンインストール対応を通じてソフトウェアをマシンから完全に削除することとなります。運用上の理由から直接マシン上でアンインストールが行えない場合、以下が緩和策となります。

  1. Disk2Vhd を用いてイメージを仮想環境へ複製して仮想環境で作業を行う
  2. 物理マシンでは復元ポイント、仮想マシンではチェックポイントを活用し、アンインストール対応後の復元作業を容易にする
  3. サードパーティー製品のサービスを無効化する (モジュール自体を取り除いていないため十分な切り分けとならない場合がございます。)

- サービスの無効化の手順

  1. 管理者権限で "システム構成" (msconfig) を起動します。

  2. "システム構成" ウィンドウの [サービス] タブで、[Microsoft のサービスをすべて隠す] チェック ボックスをクリックしてオンにし、[すべて無効] をクリックします。

  3. [適用] - [OK] を押下します。再起動を求められるため、再起動を実施してください。

    ※ 設定を元に戻す場合は、"システム構成" (msconfig) を起動し、[システム構成] ダイアログ ボックスの [サービス] タブで [すべて有効] を押下し、[適用] - [OK] を押下し、システムの再起動を実施します。

本記事は以上となります。皆様の運用の一助となりましたら誠に幸いです。

本記事は Windows 製品の更新失敗時の進め方 より紹介しております。

本記事におきましては予告なく内容を変更させていただくことがあります。今後、情報のアップデートがあれば、本記事にて引き続き情報を提供いたします。