公開された予定表 (.ics) は、予定表アプリケーション用の HTTP 500 を返します

適用先
Exchange Server SE Exchange Server 2019 Exchange Server 2016

2026 年 8 月のセキュリティ更新プログラム (Exchange Server SE、ビルド 15.2.2562.46) をインストールすると、匿名で発行された Exchange 予定表へのサブスクリプションの更新が停止します。 サブスクライブ アプリケーションがサーバー エラーを報告し、URL が HTTP 500 を返します。

詳細情報

同じ公開済み予定表 URL を Web ブラウザーで開くと、正常に動作し、予定表を返します。 サーバーは、User-Agent ヘッダーからクライアントを分類します。 Calendar アプリケーションは Web ブラウザーではありません。 そのため、サーバーはそれらを認識せず、8 月の更新プログラムで無効にされたコード パスに要求をルーティングします。 その後、要求は失敗し、"HTTP 500" メッセージを返します。

次のクライアントが影響を受けます。

クライアント 結果
Microsoft Outlook、インターネット予定表のサブスクリプション HTTP 500
iOS と macOS での Apple Calendar HTTP 500
Google Calendar、URL から予定表を追加 HTTP 500
Mozilla Thunderbird HTTP 500
スクリプト化または自動化されたフィード コンシューマー HTTP 500
Chrome、Edge、Firefox、Safari、Android Chrome、iOS Safari HTTP 200、予定表が返されました

回避策

1 つの URL 書き換えルールを IIS の Exchange バックエンド サイトに追加します。 このルールは、/owa/calendar/ より下の.ics要求に layout=premium を追加します。 この操作により、サポートされているコード パスが選択され、フィードが復元されます。

重要

Exchange バック エンド サイトにのみルールを適用します。 "既定の Web サイト" には適用しないでください。また、サーバー上のすべてのサイトについて評価されるサーバー レベルでは適用しないでください。

注

どちらの方法でも、IIS URL 再書き込みモジュールが必要です。 Exchange Server セットアップではモジュールはインストールされません。 モジュールが存在するかどうかをチェックするには、Test-Path "$env:windir\System32\inetsrv\rewrite.dll" を実行します。 モジュールがインストールされていない場合は、 <rewrite> セクションを applicationHost.config に追加すると、IIS は予定表パスだけでなく、Exchange バックエンド サイト全体に対して "HTTP 500.19" を返します。

ルール パターンは、/owa/calendar/ の下にあるすべての.ics要求と一致します。 したがって、同じように失敗する reachcalendar.ics および発行済みのスケジュール フィードについても説明します。

次のセクションでは、いずれかの方法を使用します。 どちらの方法でも同じスコープで同じルールを構成するため、変更プロセスに適した方を選択してください。

方法 A: IIS マネージャー

  1. IIS マネージャを開きます。 サーバーを展開し、[ サイト] を展開し、[ Exchange バック エンド] を選択して、[ URL の書き換え] をダブルクリックします。

    サイト ツリー

  2. 右側の操作ウィンドウで、ルールの追加 を選択し、受信ルールの下の 空のルール を選択して、OK を選択します。

    規則の追加

  3. 名前を入力し、次の値で [ Match URL] (一致 URL) セクションに入力します。

    フィールド 値
    Name OWA 公開済み予定表による Premium レイアウトの強制適用
    要求された URL パターンに一致する
    使用 正規表現
    パターン ^owa/calendar/.+\.ics$
    大文字と小文字を区別しない 計算されます

    Match-URL

  4. [ 条件] を展開し、[ 追加... ] をクリックして、次の値を使用してダイアログを完了します。 レイアウト パラメーターが既に保持されている場合、この条件は要求をオンにします。

    フィールド 値
    条件の入力 {QUERY_STRING}
    入力文字列が パターンに一致しない
    パターン (^|&)layout=

    追加条件

    [ OK] をクリックすると、条件が一覧に表示され、 論理グループは[すべて一致] のままになります。

    条件一覧

  5. [ アクション] を展開し、次の値を入力して入力します。

    フィールド 値
    アクションの種類 書き換え
    URL の書き換え {R:0}?layout=premium&{QUERY_STRING}
    クエリ文字列の追加 クリア済み
    後続のルールの処理を停止する 計算されます

    アクション

    重要

    [ クエリ文字列の追加 ] チェック ボックスをオフにします。 チェック ボックスをオンのままにすると、IIS によって元のクエリ文字列がもう一度追加されます。 これにより、要求のパラメーターが重複します。

    [ アクション] ウィンドウで、[ 適用] を選択してルールを保存します。

  6. ルールが [URL の書き換え ] リストに表示されていることを確認します。 展開して条件を確認します。

    ルール一覧

アプリケーション プールのリサイクルは必要ありません。 IIS によって構成が自動的に再読み込みされます。

注

サーバーの機能委任設定に応じて、IIS マネージャーはルールを applicationHost.config または Exchange バックエンド サイト (%ExchangeInstallPath%\ClientAccess\web.config) のルート web.config ファイルに書き込みます。 両方の場所が有効です。 後でルールを確認または削除する場合は、このことに留意してください。

方法 B: applicationHost.config を編集する

構成管理ツールなどを使用して、ファイル変更として構成を展開する場合は、この方法を使用します。

ファイル:C:\Windows\System32\inetsrv\config\applicationHost.config

  1. ファイルをバックアップします。

    Copy-Item C:\Windows\System32\inetsrv\config\applicationHost.config "C:\Windows\System32\inetsrv\config\applicationHost.config.bak-$(Get-Date -f yyyyMMdd-HHmmss)"

  2. <location path="Exchange Back End">要素を見つけます。 存在しない場合は、他の <location> 要素と並んでファイルのルートに作成します。 <system.webServer>内に<rewrite>ブロックを追加します。

    <location path="Exchange Back End">
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="OWA published calendar force premium layout" stopProcessing="true">
          <match url="^owa/calendar/.+\.ics$" />
          <conditions>
            <add input="{QUERY_STRING}" pattern="(^|&amp;)layout=" negate="true" />
          </conditions>
          <action type="Rewrite" url="{R:0}?layout=premium&amp;{QUERY_STRING}" appendQueryString="false" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</location>

重要

appendQueryString="false" 属性を保持します。 属性の既定値は true です。 したがって、これを省略すると、IIS は元のクエリ文字列をもう一度追加します。 これにより、要求のパラメーターが重複します。

重要

このファイルでは、アンパサンドを &amp; として記述する必要があります。 IIS マネージャーで、単純な &を入力します。 ただし、applicationHost.config は XML であるため、文字をエンコードする必要があります。 ここでリテラル & すると、IIS は予定表パスだけでなく、サイト全体に対して "HTTP 500.19" を返します。

ファイルを保存します。 IIS は変更を自動的に適用します。

検証

サブスクライバーが使用するのと同じネットワーク パス経由で、organization 外のマシンから次のコマンドを実行します。 URL を、公開されている予定表のアドレスに置き換えます。 -A パラメーターは、問題を再現するブラウザーではなく、予定表アプリケーションとして要求を表示します。

curl.exe -s -o NUL -D - -A "iOS/26.6.1 (23G83) dataaccessd/1.0" "https://mail.contoso.com/owa/calendar/{id}/{token}/calendar.ics"

変更前:

HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: /owa/calendar/auth/errorFE.aspx?httpCode=500
Set-Cookie: OwaLight=; expires=Mon, 24-Aug-2026 13:47:06 GMT; path=/
Content-Length: 161

要求はエラー ページにリダイレクトされ、予定表データは返されません。

変更後:

HTTP/1.1 200 OK
Content-Type: text/calendar; charset=utf-8
Content-Length: 1780

値、 HTTP/1.1 200 OK 、 Content-Type: text/calendarを確認します。 Set-Cookie: OwaLight= ヘッダーは、要求が失敗した場合にのみ存在します。 したがって、それがない場合、ルールが有効であることを確認しています。

予定表の内容を表示するには、コマンドから -o NUL -D - を削除します。 作業中の応答は BEGIN:VCALENDAR から始まります。

curl.exe -s -A "iOS/26.6.1 (23G83) dataaccessd/1.0" "https://mail.contoso.com/owa/calendar/{id}/{token}/calendar.ics"

IIS 自体がルールを認識していることを確認し、ルールを保持しているファイルを特定するには、サーバーで次のコマンドを実行します。

& "$env:windir\System32\inetsrv\appcmd.exe" list config "Exchange Back End" -section:system.webServer/rewrite/rules
Select-String -Path "$env:windir\System32\inetsrv\config\applicationHost.config" -Pattern 'OWA published calendar'
Select-String -Path "$env:ExchangeInstallPath\ClientAccess\web.config" -Pattern 'OWA published calendar' -ErrorAction SilentlyContinue

また、発行された予定表が引き続きブラウザーで開くこと、および通常の /owa/ サインインに影響がないことを確認します。

ロールバック

回避策を削除するには、IIS マネージャーでルールを削除するか、ルールを保持するファイルから <rewrite> ブロックを削除します。 この変更では、再起動は必要ありません。

ルールはどちらにも格納できるため、両方の場所にチェックを入れてください。

  • C:\Windows\System32\inetsrv\config\applicationHost.config
  • %ExchangeInstallPath%\ClientAccess\web.config

コピーがもう一方のファイルに残っている間に、一方のファイルからルールを削除すると、書き換えはアクティブなままになります。

  • 発行された予定表を提供するすべてのサーバーに規則を適用します。 この規則はサーバーごとの IIS 設定であり、organization 全体の設定ではありません。 ロード バランサーは、配列のすべてのメンバーにサブスクリプション要求を分散します。 そのため、見逃したサーバーは引き続き "HTTP 500" メッセージを返します。 結果として生じる断続的な障害は、一貫した障害よりも診断がかなり困難です。 各サーバーで規則を確認します。 それがすべての場所に適用されていると思い込まないでください。

  • 累積的な更新プログラムとセキュリティ更新プログラムのたびに再チェックします。 サイト レベルの IIS 構成は通常、Exchange の更新プログラムの後も存続しますが、この状態は保証されません。 Exchange の更新手順にこのルールのチェックを含めて、将来の更新中に回避策が消えないようにします。

  • これは一時的な回避策です。 Microsoft では、これを既知の問題として確認しました。 製品チームはこの動作を認識しており、将来の更新プログラムでの潜在的な改善を評価しています。 現時点では、解決の推定期間はありません。 このルールは、修正プログラムを含むビルドが配置された後に削除する必要があります。