MENU

Exchange 2026年7月SUの混在でOOS連携が失敗する問題｜全サーバー更新が必要

Microsoft

Exchange Serverへ2026年7月のセキュリティ更新プログラム（SU）を段階的に適用したところ、Outlook on the webでOfficeファイルをプレビューできなくなった場合、まず確認すべきなのはExchangeサーバー間の更新レベルが混在していないかです。

Microsoftは、2026年7月SUを適用済みのExchangeサーバーと未適用のサーバーが同じ組織内に存在すると、Office Online Server（OOS）との連携が正常に動作しない可能性があると案内しています。解消するには、組織内のすべてのExchangeサーバーへ2026年7月SUを適用し、更新レベルをそろえる必要があります。2026年8月2日時点では、混在状態のままOOS連携を正常化する別の技術的回避策は公式には示されていません。(TECHCOMMUNITY.MICROSOFT.COM)

そのため、証明書の再発行やOOSファームの再構築を始める前に、Exchangeサーバー全台の更新状況を確認してください。本記事では、影響を受ける条件、正しいバージョン確認方法、段階展開時の注意点、障害発生後の対応手順を具体的に解説します。

目次

Exchange 2026年7月SUの混在でOOS連携が止まる可能性

2026年7月14日に公開されたExchange Server向けSUでは、組織内の一部サーバーだけを更新した状態にすると、Office Online Serverとの連携が期待どおり動作しない場合があります。Microsoftのリリース情報は2026年7月24日に更新され、この注意事項が明記されています。(TECHCOMMUNITY.MICROSOFT.COM)

Office Online Serverは、Exchange Serverと連携することで、Outlook on the web上にWord、Excel、PowerPointなどの添付ファイルを表示します。ユーザーはファイルをダウンロードせず、ブラウザー内で内容を確認できます。(Microsoft Learn)

今回の問題では、次のような症状が発生する可能性があります。

  • Outlook on the webでOffice添付ファイルのプレビューが開かない
  • プレビュー画面が空白になる、またはエラーが表示される
  • 同じ添付ファイルでも、アクセスするタイミングによって表示結果が変わる
  • Wordは表示できても、ExcelやPowerPointのプレビューが失敗する
  • OOSのディスカバリーURLは正常なのに、Exchange経由のプレビューだけが失敗する

Microsoftは具体的な内部原因までは公開していません。そのため、「更新済みサーバーと未更新サーバーの通信方式が異なる」「特定のWOPI要求が拒否される」といった推測を前提に設定を変更するべきではありません。

実務上は、OOSサーバー自体の障害ではなく、Exchange組織内の更新レベル不一致として最初に切り分けることが重要です。

影響を受けやすい構成

複数台のExchangeサーバーを運用しており、2026年7月SUを段階的に展開する組織は注意が必要です。

構成・更新状態今回の問題との関係対応
Exchangeサーバーが1台のみ更新済み・未更新の混在は発生しない通常どおりSUを適用して検証する
複数台のうち一部だけ更新済みOOS連携が失敗する可能性がある残りのサーバーにも速やかに適用する
DAG構成でパッシブ側だけ更新済み組織内では更新レベルが混在しているアクティブ・パッシブを含めて更新を完了する
ロードバランサーから未更新サーバーを外したサーバー自体はExchange組織に残っている公式な解消策とは見なさない
災害対策サイトのサーバーが未更新通常トラフィックを受けなくても混在状態になるDR側も含めて更新計画に入れる
全Exchangeサーバーが更新済み今回の既知条件は解消されるOOS連携を再テストする
OOS連携を使用していないOOS機能への直接影響はないセキュリティ対策としてSUは適用する

特に見落としやすいのが、待機系サーバー、ロードバランサーから一時的に外しているサーバー、別拠点のExchangeサーバーです。

「現在ユーザーの通信を受けていない」という理由だけで更新対象から除外せず、Exchange組織に存在するサーバーをすべて棚卸ししてください。

2026年7月SUの対象バージョンとビルド番号

2026年7月SUは、Exchange Server Subscription Editionと、Extended Security Updateの対象となるExchange Server 2019およびExchange Server 2016向けに公開されています。

2026年8月2日時点の主なKB番号とビルド番号は次のとおりです。(Microsoft Learn)

Exchange Server2026年7月SU適用後のビルド番号
Exchange Server SE RTMKB510321215.2.2562.45
Exchange Server 2019 CU15KB510321315.2.1748.48
Exchange Server 2019 CU14KB510321415.2.1544.43
Exchange Server 2016 CU23KB510321515.1.2507.71

Exchange Server 2016とExchange Server 2019は通常サポートを終了しているため、2025年12月以降の更新を受け取るには、原則としてExtended Security Updateプログラムへの参加が必要です。未参加の組織は、Exchange Server Subscription Editionへの移行も検討する必要があります。(マイクロソフト サポート)

Exchangeサーバー全台の更新状況を確認する方法

Get-ExchangeServerの表示だけで判断しない

更新状況を確認するときに、次のコマンドだけを使用するのは不十分です。

Get-ExchangeServer |
    Format-Table Name, AdminDisplayVersion -AutoSize

AdminDisplayVersionは基本となるCUの情報を確認するためのもので、適用済みのSUやHotfix Updateを正確に表示しない場合があります。

Microsoftも、SUやHUの適用状況を確認する場合は、Exchange Server Health CheckerまたはExSetup.exeのファイルバージョンを使用するよう案内しています。(Microsoft Learn)

ExSetup.exeのバージョンを確認する

各ExchangeサーバーのExchange管理シェルで、次のコマンドを実行します。

Get-Command ExSetup.exe |
    ForEach-Object {$_.FileVersionInfo}

出力されたProductVersionまたはFileVersionを、前述のビルド番号と照合してください。

例えばExchange Server 2019 CU15の場合、2026年7月SUの適用後は次のバージョンになります。

15.02.1748.048

1台でも以前のビルドが残っている場合、OOS連携問題の原因となる混在状態が続いている可能性があります。

Health Checkerで全サーバーを一覧化する

Microsoftは、Exchange Server Health Checkerを使用して、サーバー構成や更新状況を確認することを推奨しています。

複数台を指定して実行する例は次のとおりです。

.\HealthChecker.ps1 -Server EXCH01,EXCH02,EXCH03

取得した結果をHTMLレポートにまとめる場合は、続けて次のコマンドを実行します。

.\HealthChecker.ps1 -BuildHtmlServersReport

Health Checkerは、Exchange Server 2016、Exchange Server 2019、Exchange Server SEに対応しています。管理者権限を持つExchange管理シェルから、最新バージョンのスクリプトを使用してください。(Microsoft GitHub)

確認対象には、少なくとも次のサーバーを含めます。

  • 通常稼働しているメールボックスサーバー
  • DAGのパッシブコピーを保持するサーバー
  • ロードバランサーから一時的に除外しているサーバー
  • 別拠点や災害対策サイトのExchangeサーバー
  • 廃止作業中だがExchange組織から正式に削除していないサーバー

段階展開では「混在期間を短くする」ことが重要

Exchange Serverの更新では、可用性を維持するために1台ずつメンテナンスモードへ移行し、段階的に更新する方法が一般的です。

今回の問題があるからといって、全サーバーを同時停止する必要はありません。ただし、最初の1台を更新してから最後の1台を更新するまでの時間は、できるだけ短くする必要があります。

推奨する進め方は次のとおりです。

  1. 全Exchangeサーバーの一覧と現在のビルドを取得する
  2. 必要な更新ファイルを各サーバーへ事前配置する
  3. バックアップ、DAG、メールキュー、ディスク空き容量を確認する
  4. 1台目をロードバランサーから外し、必要なメンテナンス処理を行う
  5. 2026年7月SUを管理者権限で適用する
  6. 再起動後、Exchangeサービスとメールフローを確認する
  7. 次のサーバーへ進み、組織内の全サーバーを更新する
  8. 最後のサーバー更新後にOOS連携を最終確認する
  9. Health Checkerを再実行して全台の結果を保存する

更新作業を複数日に分けると、OOS連携の不安定な状態が長時間続く可能性があります。可能であれば、同じメンテナンス時間帯、または連続した短い作業枠で全台を更新してください。

1台目の更新後にOOSプレビューが失敗しても、そこでロールバックしない

通常の段階展開では、最初のサーバーをカナリアとして更新し、問題がなければ残りへ展開します。

しかし今回の2026年7月SUでは、カナリアサーバーだけを更新した時点でExchange組織が混在状態になります。そのため、この時点のOOSプレビュー結果を、更新プログラムの合否判定に使用するのは適切ではありません。

検証は、次の2段階に分けると判断しやすくなります。

検証タイミング確認する項目判断上の注意
各サーバーの更新直後Exchangeサービス、イベントログ、メール送受信、キュー、OWAログインOOSプレビューの失敗だけでロールバックを決めない
全サーバーの更新完了後Word、Excel、PowerPointの添付ファイルプレビューこの段階でOOS連携の最終合否を判断する

もちろん、メール配送停止やデータベース障害など、OOS以外の重大な問題が発生した場合は、作業を中断して個別に判断する必要があります。

一方、OOSプレビューだけが失敗しており、未更新サーバーが残っている場合は、既知の混在問題を疑い、残りの更新を優先するのが合理的です。

全サーバー更新後に確認する項目

OOSエンドポイントの設定を確認する

Exchangeでは、OOSのディスカバリーエンドポイントを組織レベルまたはメールボックスサーバーレベルで設定できます。

組織レベルの設定は、次のコマンドで確認します。

Get-OrganizationConfig |
    Format-List WacDiscoveryEndpoint

サーバー単位の設定は、次のコマンドで確認します。

Get-MailboxServer |
    Format-Table Name, WacDiscoveryEndpoint -AutoSize

サーバー単位のエンドポイントが設定されている場合、サーバーごとに異なるURLが登録されていないかも確認してください。Microsoftの構成資料でも、組織レベルとサーバーレベルの両方でOOSエンドポイントを設定できることが説明されています。(Microsoft Learn)

OOSのディスカバリーURLへ接続できるか確認する

ExchangeサーバーからOOSのディスカバリーURLへアクセスします。

Invoke-WebRequest `
    -Uri "https://oos.example.jp/hosting/discovery" `
    -UseBasicParsing

正常な場合は、WOPIディスカバリー情報を含むXMLが返されます。OOSの公式展開手順でも、/hosting/discoveryへアクセスしてXMLが表示されることを確認する方法が案内されています。(Microsoft Learn)

ただし、ディスカバリーURLへ接続できることは、OOSサーバー自体が応答していることを示すだけです。

Exchangeサーバーの更新レベルが混在している状態では、ディスカバリーURLが正常でも、Outlook on the webからの添付ファイルプレビューが失敗する可能性があります。

複数のOffice形式でプレビューを試す

最終確認では、少なくとも次の形式を用意します。

  • Word：DOCX
  • Excel：XLSX
  • PowerPoint：PPTX

内部ネットワークと外部ネットワークの両方からOWAを利用している場合は、それぞれの経路で確認してください。

また、ロードバランサー配下に複数のExchangeサーバーがある場合は、複数回サインインし直すなどして、特定サーバーに依存した問題が残っていないか確認します。

問題発生時に避けたい対応

対応避けたい理由
すぐにOOSファームを再構築するExchange側の更新混在が残っていれば解消しない可能性が高い
OOS証明書を根拠なく再発行する証明書問題でなければ、構成を複雑化させるだけになる
WacDiscoveryEndpointを変更する正常だった設定を変更し、別の接続障害を増やす可能性がある
IISやアプリケーションプールの再起動だけを繰り返すMicrosoftが示した解消条件は全Exchangeサーバーの更新完了
未更新サーバーをロードバランサーから外して放置するExchange組織内の更新レベルはそろわない
更新済みサーバーからSUをアンインストールするセキュリティ修正を失い、脆弱性への露出が再び生じる
数日間に分けて少しずつ更新するOOS連携に影響する混在期間が長くなる

OOSファームの再起動や証明書確認が不要という意味ではありません。

全Exchangeサーバーの更新を完了してもOOS連携が復旧しない場合に限り、通常のOOSトラブルシューティングへ進むという優先順位が重要です。

すぐに全台更新できない場合の暫定対応

Microsoftから、混在状態のままOOS連携を復旧させる公式な技術回避策は示されていません。

業務影響を抑えるための運用上の暫定対応としては、組織のセキュリティポリシーが許可している場合に限り、ユーザーへ次の方法を案内します。

  • 添付ファイルをダウンロードしてデスクトップ版Officeで開く
  • Outlookデスクトップアプリから添付ファイルを確認する
  • 急ぎの資料はPDF形式でも再送してもらう
  • OWA上でのプレビュー障害であり、メール配送障害ではないことを周知する

ただし、OWAメールボックスポリシーで添付ファイルのダウンロードを禁止している環境では、この方法は利用できません。

これはOOS連携を修復する回避策ではなく、更新完了まで業務を継続するための代替手段です。

Office Online Server側にもExchangeのSUを適用する必要はない

今回の解消条件は、Exchange Serverへ2026年7月SUを適用することです。

Office Online ServerはExchange Serverとは別製品であり、OOSサーバーへExchange用SUをインストールするものではありません。OOSにはOOS向けの更新プログラムを、ExchangeにはExchange向けの更新プログラムを適用します。

「OOS連携の問題だからOOSを更新すれば直る」と判断せず、まずExchangeサーバー全台のビルドをそろえてください。

Exchange管理ツールだけを入れた端末も確認する

OOS連携問題の直接的な解消対象はExchangeサーバーですが、Microsoftはセキュリティ対策として、Exchange管理ツールをインストールしたサーバーや管理端末についても、対応する更新を適用するよう推奨しています。(TECHCOMMUNITY.MICROSOFT.COM)

作業完了条件は、次の2つに分けて管理すると分かりやすくなります。

  • OOS連携の復旧条件：組織内のExchangeサーバー全台を更新する
  • セキュリティ更新の完了条件：管理ツールを導入した端末も含めて対象を更新する

管理端末の更新を忘れてもOOSプレビューが必ず失敗するわけではありませんが、セキュリティ更新の展開漏れになります。

全台更新後もOOS連携が失敗する場合

すべてのExchangeサーバーで2026年7月SUの適用を確認しても問題が続く場合は、通常のOOS障害として次を確認します。

  1. OOSのディスカバリーURLがXMLを返すか
  2. ExchangeサーバーからOOSのFQDNを名前解決できるか
  3. TCP 443で通信できるか
  4. OOS証明書の有効期限、SAN、信頼チェーンに問題がないか
  5. WacDiscoveryEndpointに正しいURLが登録されているか
  6. 組織レベルとサーバーレベルで競合する設定がないか
  7. OOSおよびExchangeのイベントログに関連エラーがないか
  8. 内部アクセスと外部アクセスのどちらで失敗するか
  9. 特定のExchangeサーバーやメールボックスデータベースに偏っていないか

この段階で初めて、証明書、DNS、ファイアウォール、OOSファーム、ロードバランサーなどを個別に切り分けます。

まとめ：OOSの故障と決めつけずExchange全台を更新する

Exchange Serverの2026年7月SUでは、更新済みサーバーと未更新サーバーが混在すると、Office Online Server連携が正常に動作しない可能性があります。

最優先で行うべき対応は次のとおりです。

  1. Health CheckerとExSetup.exeで全Exchangeサーバーのバージョンを確認する
  2. DAG待機系や別拠点を含め、組織内の全サーバーへ2026年7月SUを適用する
  3. 混在期間をできるだけ短くする
  4. OOS連携の最終判定は全台更新後に行う
  5. 全台更新後も失敗する場合だけ、証明書やOOS設定を調査する

段階展開そのものを中止する必要はありません。ただし、今回のSUでは「1台ごとの適用完了」ではなく、Exchange組織全体の更新完了をOOS連携の変更完了条件にすることが重要です。

Microsoft
Exchange Server Outlook on the web 2026年7月SU Office Online Server

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次