最後の Exchange Server に期限が付きました

Exchange Online がメールを受け付ける最低バージョンを引き上げるとき、Microsoft は通常それを誰にも知らせません。2023 年以降、その基準はセキュリティ更新プログラムが出るたびに静かに上がってきました。9 月 2 日、Exchange チームは例外的にこれをブログ記事で告知しました。興味深いのは、そうした理由のほうです。

9 月第 2 週以降、ハイブリッドの受信コネクタ経由で Exchange Online にメールを渡す Exchange 2016 または 2019 サーバーには、2025 年 10 月のセキュリティ更新プログラムが適用されている必要があります。これは、Microsoft がこの 2 つのバージョン向けに一般公開した最後の更新プログラムでもあります。それより古いサーバーは Exchange Online から見て最新ではないと判断され、最初はレポートに載り、1 か月後にはメールが遅延し、3 か月後にはメールがまったく届かなくなります。この期限について、Microsoft 自身は「This update level was released almost a year ago, and all organizations should have updated to it.」とコメントしています。もっともな話です。

日ごとに何が起きるか

一晩で遮断されることはありません。Exchange Online は Microsoft が 2023 年に構築したのと同じトランスポートベースの適用システムを使い、少しずつ締め付けを強めます。サーバーが検出されてから最初の 30 日間は、誰にとっても何も変わりません。そのサーバーは、ほとんどの管理者が開いたこともないレポートに表示されるだけです。その後は 10 日ごとに状況が厳しくなります。Exchange Online は 1 時間ごとに 5 分間、一時的な 450 を返すようになり、その時間が 10 分、20 分と延びていきます。サーバーはメールをキューに入れて再試行するので、メールはすべて届きますが遅れます。最初のチケットには「スキャンが届くまで 20 分かかった」といった内容が書かれているはずです。

61 日目からは、恒久的な 550 が加わります。こうなるとメッセージはキューで待つことなく、バウンスします。リレー構成で問題になるのはここです。バウンスは送信者に返されますが、その送信者はコピー室のスキャナーで、誰も読まない差出人アドレスを使っています。ドキュメントはそのまま消えてしまいます。91 日目からは、すべてのメッセージがそうなります。

影響を受けるサーバーは、Exchange 管理センターの Reports > Mail flow > Out-of-date connecting on-premises Exchange servers で確認できます。同じページに Enforcement Pause リンクがあり、PowerShell でも同じ操作ができます。

New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer -NumberOfDays 30

テナントごとに暦年あたり 90 日の一時停止日数が与えられ、自由に分割して使えます。使う前に知っておくべきことが 2 つあります。日数は申請した時点からカウントされるため、翌朝にパッチを当てても戻ってきません。また、一時停止で得られるのは時間だけで、この先の方向性は何も変わりません。

パッチで稼げるのは数年ではなく数か月

2025 年 10 月の更新プログラムをインストールすれば、ひとまずリストからは外れます。ただし Microsoft は、次に何が起きるかについて珍しく率直に語っています。Microsoft 自身の見積もりでは数か月後に最低バージョンが再び引き上げられ、今度は一般公開の更新プログラムでは到達できないビルドが基準になります。その日以降、Exchange Online にメールを渡せるサーバーは 2 種類だけです。1 つは有償の Extended Security Update プログラムに参加しているサーバーで、その第 2 期間は 2026 年 10 月に終了し、第 3 期間は予定されていません。もう 1 つは Exchange Server Subscription Edition です。Exchange 2019 CU14 または CU15 であれば、SE へのインプレースアップグレードが可能です。Exchange 2016 の場合は、新しいサーバーと移行が必要になります。

つまり、サーバールームで何年も誰にも触られずに動いてきたあのサーバーには、サブスクリプションか、移行プロジェクトか、停止計画のいずれかが必要になります。4 つ目の選択肢はもうありません。スロットリングそのものよりも、これこそが Microsoft の記事の本当のニュースです。

その 1 台のサーバーについて

ほとんどのハイブリッド環境のお客様で、同じ構図が見られます。メールボックスは何年も前に Exchange Online に移行し、Exchange Server が 1 台だけ 2 つの仕事のために残っています。Active Directory の受信者属性の管理と、プリンター、スキャナー、監視、ERP など、建物内で今もプレーンな SMTP しか話せないあらゆるもののためのメールリレーです。

1 つ目の仕事には、2022 年以降サーバーは必要ありません。Exchange 2019 CU12 以降は Exchange Management Tools が単独で受信者管理を担い、Microsoft は最後のサーバーをアンインストールするのではなくシャットダウンするよう推奨しています。残るのはリレーです。サーバーを動かし続けている理由はこの仕事だけで、しかも少し皮肉なことに、今回の適用が対象とするのはまさにこのトラフィックです。デバイスがそのサーバーに渡すメールはすべて、Exchange Online が現在チェックしている OnPremises コネクタを通って出ていくからです。

今週やるべきこと

1. レポートを開き、表示されるサーバーをすべて書き出します。空であれば、良い知らせか、Partner タイプのコネクタかのどちらかです。適用の対象は、今のところ OnPremises タイプだけです。
2. ビルドを Microsoft のビルド番号一覧 と照らし合わせ、2025 年 10 月の更新プログラムが適用されていないサーバーにはインストールします。サーバー 1 台なら、プロジェクトではなく一晩の作業です。
3. 一時停止日数は本当の緊急時のために取っておきます。90 日は十分に思えますが、間違った月に 60 日を使ってしまえばそうではなくなります。
4. 次の引き上げの後にどうするかを決めます。選択肢は 10 月までの ESU、Exchange SE、または停止です。

リレーがそのサーバーの唯一の存在理由なら、4 つ目の判断は簡単です。Sendman はまさにそのために作りましたが、それはまた別の記事で取り上げます。

出典

• Microsoft Exchange Team: Exchange 2016/2019: Throttling and Blocking up to the Final Public Update Baseline、2026 年 9 月 2 日
• Microsoft Exchange Team: Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online、2023 年 5 月
• Microsoft Exchange Team: How to pause throttling and blocking of out-of-date on-premises Exchange Servers
• Microsoft Exchange Team: Announcing Period 2 Exchange 2016/2019 Extended Security Update (ESU) program
• Microsoft Learn: Manage recipients in Exchange Hybrid environments using Management tools
• heise online: Alte Exchange-Server riskieren Mailblockaden
• CodeTwo: Exchange Online transport enforcement system explained、図中の各段階の時間（分）の出典