擺脫 IE 模式依賴系統的實務指南

本文一句話總結

「在正式運用下安全地使用 IE 模式，同時一點一點減少依賴，最終讓 IE 模式歸零」──這才是現實可行的戰略。丟掉之前，先好好管理它。

背景：IE 模式可以用到「什麼時候」

這裡要特別注意的是，並不是因為能用到 2029 年就可以放心擱著不管。這段期間終究只是「為了有計畫地脫離而給的緩衝時間」，若不想在 2029 年逼近時才慌張，現在就只能開始準備。

為什麼無法擺脫對 IE 模式的依賴

IE 模式是在以 Chromium 為基礎的 Edge 之中，只用 Trident（MSHTML）引擎 繪製舊網站的一套機制。這個 Trident 引擎承接了下面這些東西。

• 舊式的文件模式（Document Mode）
• ActiveX 控制項 / BHO（Browser Helper Object）
• 舊式的安全性區域設定
• Enterprise Mode 的相容性設定

只要還依賴這些東西，光是把瀏覽器升級到最新版本，問題並不會解決。看清依賴的真正面貌，是第一步。

現場常見的問題

1. 文件模式設定錯誤 → 畫面跑版、腳本錯誤
2. 中立網站設定遺漏 → SSO（單一登入）出現重新驗證循環或重新導向循環
3. Enterprise Mode Site List 的格式不符 → IE 模式整合不支援 schema v.1，需要遷移到 schema v.2
4. Edge 只會處理一份網站清單 → Edge 端的原則優先於 IE 端的原則

依賴的分類：先確認「依賴的是什麼」

步驟一：延命對策──先安全地運用

1. 好好管理網站清單（最重要）

把「重新載入」交給使用者自行判斷是很危險的。要透過原則正式管理。

該做的事：改用 Cloud Site List Management，統一管理誰、在哪些網站、用到什麼時候的 IE 模式。

2. 鞏固認證相關設定

一旦牽涉到 SSO，在 IE 模式與 Edge 模式之間切換時，認證常常會壞掉。

• 正確設定中立網站（Neutral Site） → 明確指定 SSO 伺服器
• 必要時設定 Cookie 共用
• 在還無法確定認證伺服器之前，可暫時使用「在 IE 模式中保留頁面內導覽」的原則（但一旦確定下來就要停用）

3. 善用診斷工具

不靠感覺，而是根據觀測數據來判斷。

4. 無法修復的部分就「隔離」

步驟二：脫離對策──如何減少依賴

模式比較表

★ 是實務上的第一候選。

各模式的使用場合

階段式重構是最現實的選項。

• 不需要一次全部重做
• 只要一個畫面、一個功能地逐步現代化即可
• 新舊並存期間的「導引設計」（哪個畫面用哪個引擎執行）很重要

WebView2 封裝是用來「重新劃定邊界」的。

• 不是為了原樣保留 ActiveX 或 COM 依賴
• 把「檔案操作」「裝置整合」「Windows 驗證」等屬於作業系統的責任移到原生端，讓 Web UI 端現代化
• 但要注意 WebView2 Runtime 的發布責任會落在自己身上

微前端只有在「團隊邊界」和「部署邊界」一致時才有效。不應該因為流行就採用。

全面重寫是最後的手段，只限於對 ActiveX 或 BHO 的依賴太深、無法拆解的情況。

步驟三：具體的推進方式（路線圖）

評估 → 排定優先順序 → PoC → 測試 → 展開 → 運用

1. 評估──依賴盤點

• 用 Enterprise Site Discovery 列出對象 URL
• 用 edge://net-export 將網路轉換過程視覺化
• 把依賴分類成「文件模式」「ActiveX/BHO」「認證」「客戶端憑證」「檔案/列印」「裝置/COM」

2. 排定優先順序──從哪裡開始

依照下列觀點重新排序。

• 重要程度（一旦停擺會有多大影響）
• 使用者人數
• 安全性暴露程度
• 對其他系統的波及程度
• 是否容易拆解（邊界是否清楚）

特別是把「切開邊界就能推進的功能」和「必須連同邊界一起替換的功能」分開，之後的規劃會更容易進行。

3. PoC（概念驗證）──先小規模嘗試

第一個對象，先從「業務價值高、依賴程度中等」的一個工作流程開始。

成功條件有以下 4 點。

1. 不再需要 IE 模式
2. 維持 SSO 正常運作
3. 回應效能達到可比較的水準
4. 可以回滾（能還原到原狀）

4. 測試──應對新舊並存

• 現代化路徑 → 用 Playwright 對 Edge 進行自動化測試
• IE 模式路徑 → 診斷頁面 + 人工確認
• 新舊並存期間，要明確標示「哪個入口用哪個引擎運作」（不標示清楚，故障就很難重現）

5. 展開──逐步擴大

• Canary 發布（先從部分使用者展開）
• 用 Extended Stable（8 週週期）確保驗證窗口
• 把網站清單的更新間隔與瀏覽器重新啟動要求納入運作流程
• 使用雲端網站清單時，不要忘記必須先登入 Edge

6. 運用──持續減少

• 利用 Cloud Site List Management 的意見回饋功能，回收使用者自行新增的網站或誤設定
• 建立每月縮減 IE 模式對象清單的運作週期
• 「延命對策」一定要搭配「減少的運用方式」一起執行

整體流程（流程圖）

flowchart TD
    A[盤點對象資產] --> B[依賴分類]
    B --> C{依賴的種類是？}
    C -->|以文件模式・SSO為主| D[正式運用 IE 模式]
    C -->|以作業系統整合・COM為主| E[封裝化]
    C -->|可依畫面單位拆解| F[階段式重構]
    C -->|多團隊平行開發| G[微前端]
    C -->|依賴太深| H[全面重寫]

    D --> I[調整中立網站與 Cookie]
    E --> J[WebView2/原生邊界]
    F --> K[新舊共存與階段替換]
    G --> K
    H --> L[重新設計新架構]

    I --> M[PoC]
    J --> M
    K --> M
    L --> M

    M --> N[自動化測試與運作測試]
    N --> O[階段展開]
    O --> P[收集使用狀況與意見回饋]
    P --> Q[縮減 IE 模式對象]
    Q --> R[判定廢止]

步驟四：治理──管理框架

將 IE 模式明文化為「例外運用」

• 新增的 IE 模式對象 URL,一定要設定以下項目。
  • 業務負責人（誰是責任人）
  • 技術負責人（誰負責技術層面的管理）
  • 失效日期（何時之前要脫離）
  • 替代方案（如何脫離）
• 若既有的 XML 網站清單是 schema v.1,要遷移到 IE 模式整合可用的 schema v.2
• 變更歷程要用 Cloud Site List Management 或組態管理工具追蹤

安全性方面的注意事項

• 固定使用舊版 Edge 運作是危險的 → 要使用最新的 Stable/Beta 系列
• 需要驗證期間時，使用 Extended Stable（8 週週期）
• GPO 的品質確認可使用 Security Compliance Toolkit 或 Policy Analyzer
• 比起「IE 模式本身的漏洞」,「周邊瀏覽器運作管理粗糙」更容易導致事故

從時間軸倒推

• IE 模式支援結束：2029 年
• Win10 22H2 的 Edge/WebView2 更新結束：2028 年 10 月

這些是「撤退期限的外框」。應該先做出一張在支援結束前把依賴降到零的倒推時間表。

依規模劃分的建議策略

常見錯誤與對策

總結

標準戰略 = 正式運用 IE 模式（避免事故）
           + 讓依賴可視化（盤點）
           + 階段式減少（一個一個脫離）

• 小規模就採用階段式重構
• 大規模就用網站清單統一管理 + 組合管理
• 預算緊縮就用虛擬化封鎖現況，同時停止新增依賴
• 全面重寫是最後的王牌
• 容器通常不在候選之列，VDI 是避難所，IE 模式 是跑道（是為了起飛而存在的）

參考連結

• IE 與 Edge 的生命週期常見問題 ─ IE 模式的 2029 年方針
• IE 模式概觀 ─ 支援範圍的基本資料
• IE 模式的原則組態 ─ 整合設定的三個階段
• Enterprise site configuration strategy ─ 中立網站、Cookie 共用、schema v.2
• IE mode troubleshooting and FAQ ─ 診斷頁面、net-export 的使用方式
• Cloud Site List Management ─ 在系統管理中心集中管理
• Enterprise Site Discovery ─ 盤點的起點
• WebView2 文件 ─ 用於檢討封裝化
• Azure Virtual Desktop / RemoteApp ─ 作為隔離策略
• Windows Containers 遷移指南 ─ 不適合作為 GUI 延命方案
• App Assure ─ IE 模式設定協助的範圍
• Playwright ─ Edge 自動化測試
• single-spa ─ 微前端的基礎
• webpack Module Federation ─ 獨立建置整合

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

Edge 的 IE 模式能用到什麼時候？

Edge 的 IE 模式方針是至少支援到 2029 年，而且會在停用前一年通知。另外，Windows 10 22H2 上的 Edge / WebView2 Runtime 更新，則至少會持續到 2028 年 10 月。不過，這段期間只是為了讓企業能有計畫地脫離而給的緩衝時間，2029 年不該被當成「開始準備」的年份，而應該被當成「必須完成脫離」的期限，反過來倒推規劃。IE11 桌面應用程式本身則早已停止支援。

為什麼無法擺脫對 IE 模式的依賴？

因為 IE 模式是在以 Chromium 為基礎的 Edge 之中，只用 Trident（MSHTML）引擎去繪製舊網站的一套機制，而這個 Trident 引擎承接了舊式文件模式、ActiveX 控制項與 BHO、舊式安全性區域設定，以及 Enterprise Mode 的相容性設定。只要還依賴這些東西，光是把瀏覽器升級到最新版本並不會解決問題。第一步是先把依賴分類成文件模式、ActiveX/BHO、認證與 SSO、客戶端整合、舊有運作前提，弄清楚依賴的真正面貌。

脫離 IE 模式有哪些方法？

主要的選項有六種：繼續運用 IE 模式、WebView2 封裝、階段式重構、微前端、全面重寫，以及 VDI / RemoteApp 隔離。實務上的第一候選是階段式重構，可以一個畫面、一個功能地逐步現代化。WebView2 封裝並不是為了保留 ActiveX，而是把檔案操作、裝置整合等屬於作業系統層的責任移到原生端，重新劃定邊界。全面重寫則是在依賴太深、無法拆解時的最後手段。

如果暫時還要繼續使用 IE 模式，該做什麼？

首先，網站清單不該交給使用者自行「重新載入」，而要透過原則正式納入管理。改用 Cloud Site List Management 之後，就能做到多份清單發布、變更歷程記錄、依群組分別指派。牽涉到 SSO 時，要正確設定中立網站，必要時再設定 Cookie 共用。同時，新增的 IE 模式對象 URL 一定要設定業務負責人、技術負責人、失效日期與替代方案，並搭配每月縮減對象清單的運作週期。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。