多くの企業や組織で利用されてきたOffice 2013ですが、Windows Server 2019環境で古いセキュリティ更新プログラムを手動インストールしようとするとエラーが発生するケースが報告されています。特にサポート終了後のパッチ適用には多くの注意点があり、慎重な対策が求められます。以下では、具体的な原因や回避策、そして今後の推奨方針について詳しく解説します。
Office 2013とWindows Server 2019におけるパッチ適用の背景
Office 2013の環境に古いセキュリティパッチを当てようとして失敗する背景には、Microsoftのサポートライフサイクルや更新プログラムの配布形態など、複数の要因が存在します。ここではまず、Office 2013とWindows Server 2019という組み合わせがどのような状況にあるのかを整理していきましょう。
Office 2013のサポートライフサイクル
Office 2013は、2023年4月11日をもって延長サポートが終了しています。製品には「メインストリームサポート」と「延長サポート」が設けられていますが、この両方が終了した時点で、公式に新しいセキュリティ更新プログラムは原則として提供されません。
- メインストリームサポート: 製品発売後5年間程度、機能アップデートや無償サポートが受けられる期間。
- 延長サポート: メインストリームサポート終了後、さらに5年間程度セキュリティ更新プログラムが提供される期間。
Office 2013はすでにこれらのサポートを経て、いわゆる「サポート切れ」の状態になっています。そのため、Microsoft公式サイトから古いパッチを入手しようとしても、すでに公開停止またはサポート終了による制限がかかっている場合があります。
メインストリーム サポートと延長サポートの違い
Office製品の場合、延長サポートはセキュリティ更新を主眼としたものになります。メインストリームサポート期間中は機能改善や仕様変更に対応したアップデートが提供されますが、延長サポート期間に入ると新機能追加は行われず、セキュリティ修正が中心となります。したがって、延長サポート終了後はセキュリティパッチすらも配布されないため、リスク管理を考える場合はサポートが終了している製品を使い続けること自体が大きなデメリットになります。
Windows Server 2019とOffice 2013の組み合わせで起こりやすい問題
Windows Server 2019は比較的新しいサーバーOSですが、この上でOffice 2013を稼働させると以下のような相性問題やサポート上の課題が表面化しやすくなります。
- パッチの互換性: Office 2013発売当時のサーバーOSはWindows Server 2008 R2や2012が主流でした。そのため、後から登場したWindows Server 2019環境での挙動はMicrosoftの公式テスト範囲が限定的となる可能性があります。
- アップデート経路の不一致: Windows Server 2019側でのWindows Updateと、Office 2013が依存する更新プログラムの配信チャネルが食い違う場合、パッチ適用のロジックが複雑化しエラーの原因となることがあります。
レガシーパッチのインストールが失敗する主な原因
今回のケースで報告されている「.cabファイル形式でダウンロードした更新プログラムがDISMコマンドで適用できない」「.mspファイルを実行しても『この更新プログラムは適用対象ではありません』と表示される」などの現象には、いくつかの典型的な原因が考えられます。
Superseded(後継)パッチの存在
Office製品の更新プログラムでは、過去のセキュリティ修正が新しいロールアップやKBで包括的に上書きされることがよくあります。これを「Supersede(後継)」と呼び、以下のような影響があります。
- 旧パッチよりも新しい統合パッチがすでに適用されている場合、古いパッチを後から適用しようとしても「対象外」と判断される。
- Windows UpdateやMicrosoft Update経由でOffice 2013を最新の状態に近づけていれば、意図せず古いパッチを単体でインストールする必要は基本的になくなる。
そのため、手動で古いパッチを適用しようとする前に、本当に必要な修正が最新パッチに含まれていないか、まずは確認することが肝要です。
Office向けMSPファイルの互換性
Office更新プログラムの多くはMSPファイル(Microsoft Patch)形式で提供され、その中でOfficeの機能修正やセキュリティ修正が行われます。一方、Windowsの更新プログラムはMSU形式やCAB形式といった異なるパッケージ形式となることが一般的です。
- DISMコマンドは主にWindowsコンポーネント(CBSベース)を対象としており、Office固有のインストーラー(Windows Installer)で取り扱うMSPとは必ずしも互換ではない。
- CABファイル内に含まれるMSPを直接抽出し、msiexecコマンドで適用する方法もありますが、そもそも環境に合わなければ「適用不可」とエラーが出る可能性が高い。
DISMコマンドによるインストールエラーの特徴
DISM (Deployment Image Servicing and Management)コマンドは、主にWindowsのイメージ管理や特定のシステムファイルの更新に用いられます。Office 2013のパッチはWindows OSのコアコンポーネントではないため、DISMを使ってCABファイルを適用しようとしてもうまくいかない事例が多数報告されています。
- 「ファイルが見つかりません (0x80070002)」
- 「該当の更新は適用できません」
これらのエラーは、Office固有の更新メカニズムがWindowsのパッケージ管理システムとは独立していることに起因します。
具体的な対処法・解決策
次に、レガシーパッチの適用を試みても失敗してしまう場合にどう対応すればよいのか、具体的な対処法を挙げていきます。
1. そもそもOfficeのアップグレードを検討する
サポート終了後の製品にこだわらず、より新しいOfficeバージョンを導入することが最も安全かつ推奨される方法です。Microsoftは以下の2種類を主な後継製品として提案しています。
- Microsoft 365 Apps (旧Office 365 ProPlus): 常に最新機能とセキュリティ更新を受け取れるサブスクリプションモデル。
- Office LTSC 2021: 永続ライセンス型で、一定期間セキュリティ更新が提供される。
セキュリティリスクを低減し、生産性の面でも最新機能を享受できるため、組織の規模や利用形態に合わせて早めの移行を検討する価値があります。
2. 手動適用の前提チェック
どうしてもOffice 2013のまま特定の古いパッチを適用したい場合は、まず以下の点を確認しておくとトラブルを回避しやすくなります。
Officeのビルド番号と更新履歴を確認
Office 2013がどのビルドバージョンになっているかを確認することで、すでにロールアップや他のKBで修正済みのセキュリティ更新プログラムに該当している可能性があります。確認手順としては以下のような流れが一般的です。
手順 | 内容 |
---|---|
1 | Office 2013アプリ(WordやExcelなど)を起動し、「ファイル」→「アカウント」を選択する。 |
2 | 画面右側の「製品情報」にバージョンやビルド番号が表示されるのでメモする。 |
3 | Microsoft公式の更新履歴サイト(またはKB情報)でビルド番号と照合し、どの更新プログラムが適用されているかをチェックする。 |
4 | 過去のパッチ番号(KBxxxxxx)と照合し、すでに同等の修正が含まれているか判断する。 |
実際に古いセキュリティパッチを適用しようとしても、「すでに別の更新プログラムで包含済み」の場合にはエラーが発生することが多いため、ここを確認せずにインストールを強行しても失敗につながりがちです。
3. msiexecコマンドでのインストールを試す
CABファイルから展開したMSPファイルを、Windows Installerが認識できる形式で適用する場合には、以下のようなコマンドを試すことが考えられます。ただし、前述の通り環境やパッチの種類次第ではエラーが発生する可能性があります。
コマンド例
msiexec /p パッチファイル.msp /qb /norestart
/p
: パッチを適用する指定。/qb
: インストール画面のモード(最小限のUI表示)を指定。/norestart
: インストール後の自動再起動を抑制。
もし適用が可能なパッチであれば、このコマンドを実行することでOffice 2013に対して更新プログラムを当てることができます。しかし、「この更新プログラムは適用対象ではありません」あるいはエラーコード(例: 1642)で終了する場合、そのパッチは適合しないということになるでしょう。
サーバー環境の検証とWSUSの活用
Windows Server 2019を運用している場合、WSUS(Windows Server Update Services)を構成しているケースも多いはずです。WSUSを使うと、ネットワーク内部のクライアント(ここではOffice 2013をインストールしたマシン)に対する更新プログラムの配布を集中管理できます。
Windows UpdateとWSUSの設定確認
- WSUSにOffice更新プログラムが含まれているか: 管理コンソールで「製品と分類」の設定を確認し、Office 2013の更新プログラムを配信対象としているかどうかチェックする。
- Office更新プログラムが配布されていない理由: WSUSに古いOffice 2013パッチがダウンロードされていない場合、サポート終了に伴うMicrosoft Updateカタログ上の提供終了などが影響している可能性がある。
仮にWSUSで適切にOffice更新プログラムの配信を管理できない場合、Windows Updateを直接用いたオンライン更新、または手動でMSPを入手する形となりますが、どちらにせよサポート終了後はリソースが限定されるため、十分な検証が必要です。
SFCやDISMを用いたシステム修復
エラーの原因がOffice単体ではなく、Windows Server 2019のシステムファイル破損やアップデートコンポーネントにある場合も考えられます。下記のようなコマンドでシステム全体の整合性をチェックし、問題が見つかった場合は修復を試みる手段があります。
sfc /scannow
DISM /Online /Cleanup-image /Scanhealth
DISM /Online /Cleanup-image /Restorehealth
これらの操作はOffice 2013に直接パッチを適用する方法ではありませんが、前提となるOSやWindowsアップデートコンポーネントに不具合がないかを確認・修復することで、エラー原因を切り分ける助けになります。
サポート終了製品を使い続けるリスク
Office 2013をWindows Server 2019環境で使い続けるとき、以下のようなリスクやデメリットが挙げられます。
セキュリティ面の脆弱性
サポート終了後は新たな脆弱性が見つかってもセキュリティパッチが提供されません。そのため、未知の攻撃に対してシステムが防御しきれないリスクが高まります。とりわけサーバー環境でOfficeを運用している場合、社内ファイルサーバーやメールサーバーとの連携など、攻撃の侵入口として利用される可能性も無視できません。
Microsoftからの公式支援は期待できない
サポート終了後、Microsoftの電話やオンラインサポートを利用しても、「延長サポートが終了した製品」については原則として支援対象外となります。仮に特殊な不具合が見つかっても、修正プログラムは提供されず、事実上自己解決を強いられる状態になるでしょう。これでは緊急事態が発生した際、迅速な問題解決が困難になる可能性があります。
まとめ: 今後の推奨方針
Windows Server 2019環境でOffice 2013のレガシーパッチを適用しようとしてエラーが出る場合、以下の流れで検討するのが現実的です。
- Officeバージョンのアップグレード
可能であればMicrosoft 365 AppsやOffice LTSC 2021などサポート対象となる新しいOfficeバージョンへ移行する。これが最もセキュリティリスクを下げる方法。 - すでに統合されているパッチで済むか確認
レガシーパッチが後継のロールアップやKBに含まれている場合、単体での適用は不要。Officeのビルド番号と更新履歴を照合し、本当に必要な更新が見つからなければ無理に古いパッチを当てる必要はない。 - 手動インストールをどうしても行う場合
- msiexecコマンドで直接MSPファイルを当てる方法を試す。
- 事前にOffice 2013がSP1や最新のロールアップを当てた状態であるか確認する。
- Windows Server 2019のシステムファイルが正常であること(SFC/ DISMチェック)を確認する。
- サポート切れ製品を使うリスクの再認識
正式サポートが終了している場合、緊急時のセキュリティ修正は期待できない。組織全体のITリスク管理という観点からも、早急に移行計画を立てることが重要。
これらを踏まえると、レガシーパッチの適用が困難もしくは不可能である状況を前提として、やはり「サポート対象バージョンへアップデートする」という選択肢が最善策として浮上します。もしどうしてもOffice 2013を続行せざるを得ない場合は、可能な限り最新に近い更新プログラムを適用した状態を維持したうえで、不足する部分は代替のセキュリティ対策を講じるなど、複層的なアプローチを検討する必要があります。サーバー管理者としては、一時しのぎの対策ではなく、中長期的な視点でシステム全体を安全に保つ方法を模索することが求められるでしょう。
コメント