如何使用 Exchange Admin API

為補足 EWS 遷移缺口而設計的有限 API

Microsoft 於 11 月 17 日推出  Exchange Admin API 。此 API 的定位就像是一塊「補丁」，用來填補開發人員在 Exchange Web Services（EWS） 與 Microsoft Graph API 之間所面臨的部分明顯功能落差。

Microsoft 已規劃於 2026 年 10 月 將 EWS 自 Exchange Online 退役，因此留給開發人員將 EWS 程式碼遷移至受支援平台的時間並不充裕。Exchange Admin API 正是為了協助這項遷移工作而存在。

其設計初衷是讓正在從 EWS 遷移程式碼的應用程式（例如電子郵件用戶端），能透過 Exchange Admin API 使用「包裝器（Wrapper）」的方式執行 Exchange PowerShell Cmdlet，以重建 EWS 中經常使用的功能。這些Cmdlet 會回傳資料，供應用程式在後續處理流程中使用。

如同接下來將會看到的，Exchange Admin API 的功能相當有限，許多你直覺認為可行的事情，在實際上往往無法做到。這是刻意的設計。Microsoft 並不是要打造一個全新的、以 REST 為基礎、可用於一般用途的 Exchange Online 管理 API。

相反地，Exchange Admin API 僅提供最低限度的支援，用來協助開發人員在 Microsoft Graph API 尚未提供對應功能的有限情境下，將應用程式自 EWS 遷移出去。

在大多數情況下，為 Exchange Online 建立管理自動化的正確選擇，仍然是使用 PowerShell，並搭配 Exchange Online 模組與 Microsoft Graph PowerShell SDK 中的 Cmdlet。我實在想不到任何理由，會讓正在撰寫PowerShell 指令碼的人考慮使用 Exchange Admin API，原因很簡單：指令碼本身就能原生執行該 API 所支援的Cmdlet。更棒的是，直接原生執行 Cmdlet，在功能性與能力上都比透過 Exchange Admin API 執行來得更完整且強大。

不過，了解其運作方式仍然很有意思；如果你曾透過 PowerShell 使用過 Microsoft Graph，那麼大多數所需的操作都會是熟悉的領域。接下來，讓我們看看如何透過 Exchange Admin API 與 Exchange 進行互動。

適合哪些使用情境？

主要鎖定 從 EWS 遷移中的應用程式，例如：

📧 Email Client（郵件用戶端）

🛠️ 管理型工具（信箱設定、原則、委派權限）

🔄 需要重現 EWS 特定行為、但 Graph 尚未支援的功能

👉 不是給新 App 從零開始用的第一選擇
👉 而是「遷移過渡用 API」

實際該怎麼用？（高階流程）

1.盤點既有 EWS 功能

🟢找出你目前 EWS 使用的功能

🟢確認哪些：

✔ Graph 已支援

❌ Graph 尚未支援（這些就是 Exchange Admin API 的使用目標）

2.使用 Exchange Admin API 包裝 PowerShell Cmdlet

🟢將原本 EWS 呼叫

🟢改為：

API → PowerShell Cmdlet → 回傳資料

🟢常見做法是建立 Wrapper Layer

3.App 處理 Cmdlet 回傳資料

🟢Cmdlet 會回傳結構化資料

🟢App 再依原本邏輯處理（與 EWS 類似）

4.長期策略：逐步移除

🟢隨著 Graph API 功能補齊

🟢將 Exchange Admin API 視為：

暫時性橋接方案

非永久依賴

重點一句話總結

🔚 EWS 將於 2026 退役

🔀 Graph 還沒補齊所有功能

🩹 Exchange Admin API 是「過渡用補洞工具」

🧑‍💻 幫助開發者用 PowerShell Cmdlet 重建 EWS 行為