Microsoft 的 EWS 退場對行事曆同步代表什麼
Exchange Web Services 自 2026 年 10 月 1 日起開始關閉,並於 2027 年 4 月 1 日完全停用。以下說明哪些功能真的會中斷、哪些不會,以及決定您落在哪一組的兩個租用戶設定。
Microsoft 正在讓 Exchange Online 中的 Exchange Web Services (EWS) 退場。全球停用作業自 2026 年 10 月 1 日開始,EWS 則於 2027 年 4 月 1 日完全關閉。以 Microsoft Graph 運作的行事曆同步不受影響。真正會中斷的是合作夥伴組織之間的跨租用戶空閒/忙碌查詢、使用 Kiosk、F1 與 F3 授權的信箱,以及任何仍在呼叫 EWS 的第三方應用程式。
重點摘要:如果您的租用戶今天的 EWSEnabled 值是 Null,Microsoft 會在 2026 年 10 月 1 日將它改成 False,租用戶中所有依賴 EWS 的應用程式都會在當天停止運作。Null 是目前的預設值,所以什麼都不做本身就是一種決定。
時程與確切日期
有四件事發生在四個不同的日期。它們經常被當成同一件事報導,這也是許多管理員記錯期限的原因。
| 日期 | 發生什麼事 | 受影響對象 |
|---|---|---|
| 2026 年 9 月 1 日 | 跨租用戶的空閒/忙碌、MailTips 與行事曆共用完成從 EWS 遷移至 Microsoft 365 Cross-Tenant Access Policy。推出作業始於 2026 年 8 月。 | 與合作夥伴租用戶共用空檔資訊的組織 |
| 2026 年 10 月 1 日 | EWS 開始在全球被停用。仍設為 Null 的租用戶會被改成 False。自此日起,存取 EWS 也必須有已填入內容的允許清單。 | 所有尚未採取行動的租用戶 |
| 2026 年 10 月 1 日 | 使用 Kiosk、F1 與 F3 授權的信箱完全失去 EWS 存取權。要求會回傳 HTTP 403。任何允許清單項目都無法讓它們例外。 | 第一線與 Kiosk 人員 |
| 2027 年 4 月 1 日 | EWS 完全停用。任何允許清單、授權或設定都無法讓它繼續運作。 | 所有人 |
Microsoft 早在 2018 年就宣布 EWS 不再獲得功能更新,並於 2023 年訂下 2026 年 10 月的停用日期。2024 年 1 月的 Midnight Blizzard 事件與 EWS 有關,使得影響範圍從第三方應用程式擴大到 Microsoft 自家產品,這也是 Outlook、Office、Teams 與 Dynamics 365 全都要轉離 EWS 的原因。
決定一切的兩個設定
EWS 的停用由兩個租用戶層級的屬性控制,而組織最常在這兩者的交互作用上出錯。
EWSEnabled
它有三種值:True、False 與 Null。Null 是目前的預設值,而它現在的行為等同於 True。2026 年 10 月 1 日,當推出作業擴及您的租用戶時,Null 會被改成 False。光是這一項變更,就會同時封鎖租用戶內所有應用程式的 EWS 存取。
如果在 2026 年 10 月至 2027 年 4 月之間,您仍有應用程式真的需要 EWS,就必須明確將 EWSEnabled 設為 True。維持預設值並不等於「維持現狀」。
EWSAllowedAppIDs
光是把 EWSEnabled 設為 True 已經不夠。自 2026 年 10 月 1 日起,您還需要一份已填入內容的允許清單,列出獲准呼叫 EWS 的 App ID。少了其中任何一半,所有依賴 EWS 的功能都會停止。
對於尚未建立清單的租用戶,Microsoft 會在 2026 年 9 月之前依據各租用戶自身觀察到的使用情形,預先填入這份清單。這確實有幫助,但它是根據您的租用戶近期恰好呼叫過的內容建立的。每季才執行一次的應用程式,或是在取樣期間閒置的應用程式,都可能不在您以為已經完整的清單裡。
如何檢查您自己的租用戶
在規劃任何事情之前,先連線到 Exchange Online PowerShell 並讀取目前狀態:
Get-OrganizationConfig | Format-List EWSEnabled, EWSAllowedAppIDs, EWSApplicationAccessPolicy, EWSAllowList, EWSBlockList
接著查明是否真的有東西在呼叫 EWS。Microsoft 365 系統管理中心的 EWS 使用情形報告會依應用程式顯示實際流量,比在內部四處詢問可靠得多。
如果您與合作夥伴組織共用空檔資訊,請檢查底層依賴 EWS 的三項設定:
Get-OrganizationRelationship | Format-List Name, DomainNames, FreeBusyAccessEnabled
Get-AvailabilityAddressSpace | Format-List Name, ForestName, AccessMethod
Get-SharingPolicy | Format-List Name, Domains, Enabled
三者都沒有結果,就代表跨租用戶的部分與您無關。Microsoft 將這則訊息中心通知寄給了每一個租用戶,因此有相當多管理員收到的是關於他們根本沒在使用的功能的警告。
哪些會中斷,哪些不會
真正關鍵的分野在於:某個工具是透過 EWS 還是透過 Microsoft Graph 與 Exchange Online 溝通。Graph 是接替的 API,完全不受上述任何日期影響。
| 功能 | 2026 年 10 月後的狀態 |
|---|---|
| 建立在 Microsoft Graph 上的行事曆同步 | 不受影響 |
| 透過 Organization Relationship 的跨租用戶空閒/忙碌 | 必須遷移至 Cross-Tenant Access Policy |
| 跨租用戶的 MailTips 與行事曆共用 | 必須遷移至 Cross-Tenant Access Policy |
| 僅具備 Kiosk、F1 或 F3 授權的信箱 | EWS 遭封鎖,且無法例外 |
| 仍在呼叫 EWS 的第三方應用程式 | 未列入允許清單即遭封鎖,且最多只能撐到 2027 年 4 月 |
| 使用 EWS Managed API 的舊有內部指令碼 | 必須改寫為使用 Graph |
這會影響 CalendarBridge 嗎?
不會。CalendarBridge 透過 Microsoft Graph 連線至 Microsoft 365,使用委派的 Calendars.ReadWrite 與 User.Read 範圍。它沒有任何 EWS 相依性,因此 2026 年 10 月或 2027 年 4 月的日期都不會改變您同步連線的運作方式,CalendarBridge 也不需要出現在您的 EWSAllowedAppIDs 允許清單中。
如果您正在期限前盤點供應商,這就是值得逐一詢問的問題:Graph 還是 EWS。任何仍停留在 EWS 的行事曆工具,都會在 2027 年 4 月面臨硬性中斷,而且必須在那之前完成遷移。
依您實際的情況決定如何遷移
沒有單一的遷移路徑。該怎麼做取決於上述四種情況中哪些適用於您,而多數組織不只符合其中一種。
| 如果您有 | 該怎麼做 | 期限 |
|---|---|---|
| 呼叫 EWS 的內部指令碼或應用程式 | 改寫為使用 Microsoft Graph。用 EWS Analyzer 找出這些呼叫,再依官方發布的 EWS 對 Graph 操作對照表進行轉換。 | 2027 年 4 月 1 日;並在 2026 年 10 月 1 日前將它們列入允許清單以爭取時間 |
| 與合作夥伴組織的跨租用戶空閒/忙碌查詢 | 將 Organization Relationship 遷移至 Cross-Tenant Access Policy,或改以行事曆同步取代該查詢。以下都會說明。 | 2026 年 9 月 1 日 |
| 使用 EWS 的第三方工具 | 請供應商以書面提供其 Graph 遷移日期。如果對方沒有明確日期,現在就規劃替代方案,而不要等到 2027 年 3 月。 | 2027 年 4 月 1 日 |
| 使用 EWS 工具的 Kiosk、F1 或 F3 使用者 | 將他們改為具備 EWS 權限的授權,或改用完全不需要 EWS 的工具。允許清單在這裡幫不上忙。 | 2026 年 10 月 1 日 |
以行事曆同步取代跨租用戶空閒/忙碌查詢
跨租用戶這一塊最可能影響到一般行事曆使用者,因此值得先了解其中的取捨,而不是直接選擇一比一的遷移。
Cross-Tenant Access Policy 沿用目前的模式:每當有人開啟排程小幫手時,其中一個租用戶就即時查詢另一個租用戶。它保留了即時查詢,如果您確實需要跨組織、精確到秒的空檔資訊,這就是正確答案。代價是您得遷移一整套跨租用戶的信任設定,而且事後兩邊的租用戶都必須維持其正常運作。
行事曆同步則把模式反過來。CalendarBridge 不去查詢合作夥伴租用戶,而是把事件複製到您自己租用戶內的行事曆,讓它們的行為與其他事件無異。它們會佔用時間、會出現在排程小幫手與 Find a Time 中,而且無論兩個租用戶之間的關係後續發生什麼變化都能繼續運作,因為根本沒有即時查詢會壞掉。
當需求只是讓大家看到對口人員何時已被預約時,同步通常比較合適。而當您需要即時準確度,或需要真正雙向查看合作夥伴行事曆的細節時,Cross-Tenant Access Policy 才是較好的選擇。
為個人設定
- 將兩個帳戶連結至 CalendarBridge。Microsoft 365 帳戶透過 OAuth 連線,使用委派的
Calendars.ReadWrite與User.ReadGraph 範圍,因此完全不涉及 EWS,也不需要允許清單項目。 - 從合作夥伴或次要行事曆建立單向同步,同步到您實際使用的行事曆。
- 在同步連線的隱私設定中,讓主旨、說明、地點與與會者維持未勾選,這樣每個副本都只是單純的忙碌時段。如果您希望這些副本在 Outlook Scheduling Assistant 與 Google Find a Time 中顯示為忙碌,也請一併勾選 All Private(全部設為私人)。
為整個組織設定
如果您要取代的是服務整間公司的 Organization Relationship,應該採用受管理同步,而不是要求每位使用者自行設定:
- 建立採用同步授權(而非使用者授權)的群組帳戶。
- 在每個存放您所需行事曆的租用戶中授權受管理同步的存取權。在 Microsoft 365 上,這是由租用戶管理員授予的應用程式權限,同樣走 Graph。
- 將已授權的網域連結至群組帳戶,每個租用戶各一次。
- 建立受管理的同步連線。少於二十組時可逐一指派;二十組以上請使用批次工作,一次匯入整份對應清單。
由於這是以各租用戶自身管理員所授予的應用程式權限運作,因此不依賴 Organization Relationship、Availability Address Space 或 Sharing Policy。2026 年 9 月要遷移的那三項設定,都不在這條路徑上。
如果您只需要發布空檔資訊
有些跨租用戶關係存在的唯一目的,就是讓外部人員看到您的人員何時有空。若是如此,公開日曆訂閱源比上述兩種做法都更簡單。挑選行事曆、關閉每一個詳細資訊欄位,然後分享產生的連結或 ICS 訂閱網址即可。收件者不需要 Microsoft 365 租用戶、不需要與您的租用戶建立關係,也不需要任何帳戶。逐欄位的完整說明請參閱如何在不共用活動詳細資訊的情況下同步行事曆。
無論您選擇哪一條路,都請先完成盤點。在規劃跨租用戶遷移之前,先執行 Get-OrganizationRelationship。收到這則訊息中心通知的租用戶中,有相當高的比例根本沒有設定任何跨租用戶共用,對於 9 月的日期完全不需要採取行動。
接下來六週該做的事
- 讀取目前狀態。執行上面的
Get-OrganizationConfig命令,並記下EWSEnabled今天的設定值。 - 調出使用情形報告。查明實際上有什麼在呼叫 EWS,而不要憑既有印象判斷。
- 檢查跨租用戶設定。如果
Get-OrganizationRelationship沒有回傳任何結果,您就不必再擔心 9 月的日期。 - 稽核授權指派。Kiosk、F1 與 F3 使用者會失去 EWS 且無法例外。如果他們之中有人依賴以 EWS 為基礎的工具,就需要換一種授權。
- 向供應商提出 Graph 這個問題。取得書面答覆,並把含糊其詞本身視為一種答案。
允許清單是一座橋,不是終點。您在 2026 年 10 月加入其中的任何項目,到了 2027 年 4 月一樣會停止運作,因此請利用這段時間完成遷移,而不是拖延。
常見問題
EWS 到底何時會停止運作?
EWS 自 2026 年 10 月 1 日起開始在全球被停用,並於 2027 年 4 月 1 日完全停用。在這兩個日期之間,只有當租用戶的 EWSEnabled 設為 True,且呼叫端應用程式的 App ID 已列入 EWSAllowedAppIDs 允許清單時,EWS 才能繼續運作。2027 年 4 月 1 日之後,任何設定都無法讓它繼續運作。
EWS 退場後,我的行事曆同步會停止運作嗎?
只有在您的行事曆同步工具使用 EWS 時才會。建立在 Microsoft Graph 上的工具不受影響,因為 Graph 是接替的 API,而不是這次退場的受害者。CalendarBridge 使用 Microsoft Graph,不需要允許清單項目,也不需要任何設定變更。
如果我在 2026 年 10 月 1 日前什麼都不做,會怎麼樣?
EWSEnabled 仍設為 Null 的租用戶,會在推出作業擴及時被改成 False,這會封鎖該租用戶內所有應用程式的 EWS 存取。Null 是目前的預設值,因此多數未採取任何行動的租用戶都會被自動關閉。
EWS 退場會影響跨租用戶的空閒/忙碌查詢嗎?
會。透過 Organization Relationship、Availability Address Space 或 Sharing Policy 設定的跨租用戶空閒/忙碌、MailTips 與行事曆共用,全都以 EWS 運作。Microsoft 正在將它們遷移至 Microsoft 365 Cross-Tenant Access Policy,推出作業自 2026 年 8 月開始,並於 2026 年 9 月 1 日前完成。
Kiosk、F1 與 F3 信箱可以保留 EWS 存取權嗎?
不行。自 2026 年 10 月 1 日起,僅持有 Exchange Online Kiosk、Microsoft 365 F1 或 Office 365 F3 授權的信箱,其 EWS 要求會回傳 HTTP 403。允許清單無法讓它們例外。這些使用者需要包含 EWS 權限的授權,例如 Exchange Online Plan 1 或 2,或 Microsoft 365 E3 或 E5。
我要如何找出哪些應用程式仍在使用 EWS?
請使用 Microsoft 365 系統管理中心的 EWS 使用情形報告,它會依應用程式細分顯示實際的 EWS 流量。Microsoft 也發布了 EWS Analyzer 工具,可掃描內部程式碼中的 EWS 呼叫。
資料來源
時程與運作機制均已對照 Microsoft 官方文件查證:Deprecation of Exchange Web Services in Exchange Online、Exchange Online EWS, Your Time is Almost Up、Introducing EWSAllowedAppIDs,以及 Migrate to Microsoft 365 Cross-Tenant Access Policy。訊息中心參考編號:MC1446796、MC1227454、MC1191578。
十月的遷移清單上可以少一項
CalendarBridge 透過 Microsoft Graph 同步 Google、Microsoft 365、iCloud 與 CalDAV 行事曆,因此 EWS 退場完全不會改變您的同步連線。不需要允許清單項目、不需要變更設定,也沒有期限要趕。
開始免費試用