已發佈的行事曆 (.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 運作正常，並傳回行事曆。伺服器會從用戶端的 User-Agent 標頭分類用戶端。 Calendar 應用程式不是網頁瀏覽器。因此，伺服器無法辨識它們，並將要求路由傳送至八月更新停用的程式碼路徑。然後要求失敗，並傳回「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，傳回行事曆

因應措施

新增一個 URL 重寫規則至 IIS 中的 Exchange 後端 網站。此規則會 layout=premium 附加至 /owa/calendar/ 下方的.ics要求。此動作會選取支援的程式碼路徑，並還原摘要。

重要

僅將規則套用至 Exchange 後端 網站。請勿套用至「預設網站」，也不要在伺服器層級套用，因為伺服器層級會針對伺服器上的每個網站進行評估。

注意

這兩種方法都需要 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 管理員

開啟 [IIS 管理員]。展開伺服器，展開 [網站]，選取 [Exchange 後端]，然後按兩下 [URL 重寫]。
在右側的 [動作] 窗格中，選取 [新增規則] (s) ...，選取 [輸入規則] 底下的 [空白規則]，然後選取 [確定]。
輸入名稱，然後使用下列值完成 [ 比對網址 ] 區段。

欄位值

Name (名稱) OWA 已發佈行事曆強制進階版面配置

要求的 URL 符合模式

使用規則運算式

模式 ^owa/calendar/.+\.ics$

忽略大小寫已選取
展開 [條件]，按一下 [ 新增...] ，然後使用下列值完成對話方塊。如果要求已經包含版面配置參數，此條件會讓它們不理會。

欄位值

條件輸入 {QUERY_STRING}

檢查是否輸入字串 與模式不相符

模式 (^|&)layout=

按一下 [確定] 之後，條件會顯示在清單中，而邏輯群組則保留在 [全部符合]。
展開 [動作]， 並使用下列值完成它。

欄位值

動作類型改寫

重寫網址 {R:0}?layout=premium&{QUERY_STRING}

附加查詢字串 已清除

停止後續規則的處理已選取

重要

清除 [附加查詢字串 ] 核取方塊。如果您將核取方塊保留為選取狀態，IIS 會再次附加原始查詢字串。這會導致要求具有重複的參數。

在 [動作 ] 窗格中，選取 [套用 ] 以儲存規則。
確認規則已列在 [URL 重寫 ] 清單中。展開以查看狀況。

欄位	值
Name (名稱)	OWA 已發佈行事曆強制進階版面配置
要求的 URL	符合模式
使用	規則運算式
模式	`^owa/calendar/.+\.ics$`
忽略大小寫	已選取

欄位	值
條件輸入	`{QUERY_STRING}`
檢查是否輸入字串	與模式不相符
模式	`(^\|&)layout=`

欄位	值
動作類型	改寫
重寫網址	`{R:0}?layout=premium&{QUERY_STRING}`
附加查詢字串	已清除
停止後續規則的處理	已選取

不需要應用程式集區回收。 IIS 會自動重新載入設定。

注意

依據伺服器的功能委派設定，IIS 管理員會將規則寫入 applicationHost.config 或 Exchange 後端網站 (%ExchangeInstallPath%\ClientAccess\web.config) 的根 web.config 檔案。這兩個位置都有效。稍後驗證或移除規則時，請留意這點。

方法 B：編輯 applicationHost.config

如果您希望將設定部署為檔案變更，例如透過設定管理工具，請使用此方法。

檔案：C:\Windows\System32\inetsrv\config\applicationHost.config

備份檔案。

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

找出元素 <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 會第二次附加原始查詢字串。這會導致要求具有重複的參數。

重要

您必須如本檔案所述 & 撰寫符號。在 IIS 管理員中，輸入純文字 &。不過，由於 applicationHost.config 是 XML，因此字元必須經過編碼。這裡的常值 & 會造成 IIS 針對整個網站傳回 “HTTP 500.19”，不只是針對行事曆路徑。

儲存檔案。 IIS 會自動套用變更。

驗證

從組織外部的電腦，透過訂閱者使用的相同網路路徑執行下列命令。以您自己發佈的行事曆位址取代 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 設定，而不是全組織的設定。負載平衡器會在陣列的所有成員之間分散訂閱要求。因此，您錯過的伺服器繼續傳回「HTTP 500」訊息。由此產生的間歇性故障比持續的故障更難診斷。在每個伺服器上驗證規則。不要以為它適用於所有位置。
在每次累積更新和安全性更新後再次檢查。 網站層級 IIS 設定通常會在 Exchange 更新後繼續運作，但無法保證這種情況。請在 Exchange 更新程序中包含此規則的檢查，以免在將來更新時該因應措施消失。
這是暫時的因應措施。 Microsoft 已確認此為已知問題。產品團隊已發現此行為，並正在評估未來更新中的潛在改進。目前，沒有解決方案的預估期限。部署包含修正程式的組建後，應移除規則。

已發佈的行事曆 (.ics) 會傳回行事曆應用程式的 HTTP 500

其他資訊

因應措施

方法 A：IIS 管理員

方法 B：編輯 applicationHost.config

驗證

復原

此資訊是否有幫助?

感謝您的意見反應!

已發佈的行事曆 (.ics) 會傳回行事曆應用程式的 HTTP 500

其他資訊

因應措施

方法 A：IIS 管理員

方法 B：編輯 applicationHost.config

驗證

復原

相關資訊

此資訊是否有幫助?

感謝您的意見反應!