Exchange 2010 SP2 中的 OWA 跨網站無訊息重新導向

  • Articolo

英文原文已於 2011 年 12 月 13 日星期二發佈

已經有很多人看過探討通訊錄原則 (可能為英文網頁)、主機變更以及混合式設定精靈的文章，不過，我知道各位都希望我們能夠討論未來 Exchange 2010 SP2 會包含的功能。

不好意思，您說什麼？是的，我知道 Tony 曾說過「SP2 的新功能不會引發任何爭論」，而他也在其發佈於 Windows IT 專業人員上的文章 (可能為英文網頁)表示 SP2 不會有那麼多新功能 (我相信他指的是 SP2 的新功能會「相對較少」)。

我就在這裡搶先公佈真相吧。Exchange 2010 SP2 有一個很少被提及的殺手級功能。沒錯，是時候討論 Outlook Web App 的跨網站無訊息重新導向了！

定義

首先，讓我們查看一些定義以確定我們的進度是一樣的。

  • 做為網際網路介面的 Active Directory 網站：包含 CAS 的 Active Directory 網站，其中 CAS 具有會因相關服務而擴展的 ExternalURL (所謂的相關服務指的是如 OWA 此類的服務)。通常這是部署 Exchange 2010 的主要資料中心/網站。
  • 區域性做為網際網路介面的 Active Directory 網站：包含 CAS 的 Active Directory 網站，其中 CAS 具有會因相關服務 (例如 OWA) 而擴展的 ExternalURL。
  • 非做為網際網路介面的 Active Direcotry 網站：包含 CAS 的 Active Directory 網站，其中 CAS 不具有會因相關服務而擴展的 ExternalURL。
  • 直接連接：CAS 使用代管信箱資料的信箱伺服器來建立 RPC 工作階段的程序。
  • Proxy：做為網際網路介面的 Active Direcotry 網站 CAS 將非做為網際網路介面的 Active Directory 網站 (位於存取信箱伺服器的相同網站中) CAS 傳入要求當做 Proxy 的程序。
  • 重新導向：Active Directory 網站中做為網際網路介面的 CAS，將使用者重新導向至其他位於與存取信箱伺服器相同網站中做為網際網路介面的 CAS 之程序。
  • 無訊息重新導向：CAS 發佈無訊息重新導向回到使用者瀏覽器的程序，用來告知瀏覽器建立連至指定 URL 的連線。
  • 單一登入 (SSO) 重新導向：CAS 發佈無訊息重新導向回到使用者瀏覽器的程序，用來告知瀏覽器將要求與驗證提交給目標 CAS，以便改善登入經驗。

OWA 連接程序

若要了解各種 Proxy 與重新導向案例，就務必先了解使用者認證 CAS 來存取 OWA 時的幕後運作機制，這些機制存在於 Exchange 2010 SP2 搶鮮版中：

  1. 使用者透過網頁瀏覽器存取 OWA URL。
  2. 使用者輸入認證。
  3. CAS 透過服務探索要求來認證使用者並擷取下列資訊：
    1. 使用者的信箱版本
    2. 使用者的信箱位置 (Active Directory 網站)
  4. 如果知道使用者信箱位置的話，CAS 就會依據信箱資訊來收集其他相關資訊，以便執行正確的作業：
    1. 如果信箱為 Exchange 2010 或本機電腦，則 CAS 會執行直接連接。
    2. 如果信箱為 Exchange 2007 或本機電腦，則 CAS 會擷取並將 Exchange 2007 CAS 的 ExternalURL 無訊息重新導向 (如果其中一部信箱尚未定義，則會使用 InternalURL)。
    3. 如果信箱為 Exchange 2003，則 CAS 會擷取並將 Exchange2003URL 無訊息重新導向。
    4. 如果信箱不是本機電腦，則 CAS 會擷取目標並將 ExternalURL (如果已定義) 無訊息重新導向，另外，如果未在目標 Active Directory 網站中定義 OWA ExternalURL 的話，則 CAS 會將 ExternalURL 當做 Proxy，而不是將 ExternalURL 無訊息重新導向。

SP1 OWA 重新導向類型

我們在 Exchange 2010 SP1 中所做的些微變更會對內部部署產品產生三種類型的 OWA 重新導向經驗：

  • 手動重新導向
  • 暫時手動重新導向
  • 傳統無訊息重新導向

手動重新導向

手動重新導向可讓客戶無需在 CAS 接近使用者信箱時控管或將所有來自中心位置的流量當做 Proxy。

手動重新導向會在 CAS 需將 OWA 要求重新導向至 Exchange 2007，或位於其他 Active Directory 網站的 Exchange 2010 CAS 基礎結構時執行。如前面所述，若要執行手動重新導向，目標 OWA 虛擬目錄必須具有 ExternalURL。您的使用者會看見下列手動重新導向訊息與其他 Active Directory 網站 CAS 的 ExternalURL：

1 
圖 1：信箱位於其他 Active Directory 網站的手動重新導向

 

暫時手動重新導向

我們在 SP1 中為 OWA 新增了另一個重新導向類型：暫時手動重新導向。暫時手動重新導向適用於兩種案例：

  1. 資料中心啟動回溯事件時，使用者的網頁瀏覽器仍可能會快取不正確的 DNS 項目，而讓網頁瀏覽器指向無法裝載信箱之 Active Directory 網站的 CAS 基礎結構。因此，即使 CAS 會向正確的 Active Directory 網站發出手動重新導向，但是卻會重新導向至使用者正在使用的 URL。為防止使用者無法存取郵件的情況發生，CAS 會偵測傳回的工作階段 Cookie 是否相同，如果相同，則會查看目標 CAS 是否具有 OWA 虛擬目錄的 FailbackURL 值。如果已指定 FailbackURL，那麼 CAS 會發佈暫時手動重新導向頁面來提供 FailbackURL。如果尚未指定 FailbackURL，則 CAS 會發佈錯誤頁面來要求使用者關閉所有瀏覽器工作階段，並在稍後再試一次。

    3
    圖 2：資料中心啟動回溯時的暫時手動重新導向

  2. 第二個案例，是 CAS 會在偵測到本機 CAS 網站符合信箱資料庫的 RpcClientAccessServer 值時發佈暫時手動重新導向頁面，不過，由於該資料庫已裝載在其他 Active Directory 網站中，所以 CAS 會向代管裝載資料庫網站之 CAS 的 ExternalURL 發佈暫時重新導向。

    2
    圖 3：信箱裝載在其他 Active Directory 網站時的暫時手動重新導向

傳統無訊息重新導向

對於 Outlook Web Access 來說，Exchange 2010 CAS 不支援顯示舊版 Exchange 的信箱資料。Exchange 2010 CAS 會依據目標信箱的版本與/或位置進行下列其中一個案例：

  • 如果 Exchange 2007 信箱與 CAS2010 位於相同的 Active Directory 網站中，則 CAS2010 會以無訊息的方式將工作階段重新導向至 Exchange 2007 CAS。
  • 如果 Exchange 2007 信箱位於其他做為網際網路介面的 Active Directory 網站中，則 CAS2010 會以手動的方式將使用者重新導向至 Exchange 2007 CAS。
  • 如果 Exchange 2007 信箱位於非做為網際網路介面的 Active Directory 網站中，則 CAS2010 會將 Exchange 2007 CAS 的連線做為 Proxy。
  • 如果信箱位於 Exchange 2003 伺服器上，則 CAS2010 會以無訊息的方式將工作階段重新導向至預先定義的 URL。

如上所述，只有 Echange 2010 CAS 與傳統基礎結構之間的同網站重新導向事件，才可使用傳統無訊息重新導向。當執行傳統無訊息重新導向時，CAS2010 會發佈無訊息重新導向回到使用者瀏覽器，來告知瀏覽器建立連至傳統 CAS2007/FE2003 基礎結構的連線。若要成功重新導向至傳統基礎結構，請務必進行下列設定動作：

  • 若要重新導向 Exchange 2003 信箱，必須將 Exchange2003URL 填入 Exchange 2010 OWA 虛擬目錄。
  • 若要重新導向 Exchange 2007 CAS，目標 Exchange 2007 OWA 虛擬目錄必須具有 ExternalURL。

傳統無訊息重新導向也可以在來源與目的地 OWA 虛擬目錄上使用表單型驗證 (FBA) 時，向網頁瀏覽器發佈欄位填寫完成的隱藏式 FBA 表單來提供單一登入經驗。這個隱藏表單包含的資訊與使用者提交給 CAS2010 FBA 頁面的資訊 (使用者名稱、密碼、公用/私人選取器)、重新導向至目標 Exchange 特定路徑以及查詢字串的資訊相同。載入完成之後，就會立即將這個表單提交給目標 URL。最後就會自動認證使用者，並可存取信箱資料。

手動重新導向有什麼問題？

未深入分析之前，您可能會覺得「Microsoft 的手動重新導向真好用」，某些程度上來講，您說的沒錯。對於需要控制使用者存取資料的 IT 組織而言，這的確是不錯的功能 (因為 IT 組織能夠使用這個功能來強制使用者使用正確的網路連結)。不過，這對於使用者而言就不是這麼一回事了。使用者在使用錯誤的 OWA URL 時，會執行下列動作：

  1. 使用者將錯誤的 URL 輸入網頁瀏覽器。
  2. 使用者認證並在 CAS (錯誤的網站) 驗證。
  3. CAS (錯誤的網站) 執行服務探索並認為其可將使用者重新導向至正確的 CAS。
  4. CAS (錯誤的網站) 提供使用者包含 CAS (錯誤的網站) 連結的頁面。
  5. 使用者從正確的網站按一下存取 OWA 的連結。
  6. 使用者認證並在 CAS (正確的網站) 驗證。

使用者被告知使用的 URL 錯誤且必須重複輸入認證，就這樣得到對於手動重新導向的不理想經驗。

Exchange 2010 SP2 中的跨網站無訊息重新導向

若要避免這種不理想的經驗 (順便一提，Greg 將這種經驗稱為糟糕的經驗)，我們為 Exchange 2010 SP2 中的 OWA 提供了第四種重新導向經驗：跨網站無訊息重新導向。如其名稱，跨網站訊息重新導向只會執行其他 Active Directory 網站 (在相同 Exchange 組織內) 之 CAS 要求的無訊息重新導向，而該 Active Directory 網站具有 OWA ExternalURL。

另外，也建立了可支援跨網站無訊息重新導向的新參數：CrossSiteRedirectType。您可從 Set-OWAVirtualDirectory Cmdlet 存取這個參數，此外，此參數可支援兩種值：Manual 與 Silent。預設不會啟用跨網站無訊息重新導向 (預設值為 Manual)，這表示如果您目前在其他 Active Directory 網站的 CAS 之間執行手動重新導向，手動重新導向會在您部署 SP2 之後繼續。

若要啟用跨網站無訊息重新導向，請將 CrossSiteRedirectType 設定為 Silent，CrossSiteRedirectType 位於以下做為網際網路介面的 CAS OWA 虛擬目錄上：

Set-OWAVirtualDirectory -Identity "Contoso\owa (預設網站)" -CrossSiteRedirectType Silent

在經過更新之後，現在 OWA 連線程序已可支援跨網站無訊息重新導向。CAS 可在服務探索期間執行下列步驟：

  1. 評估信箱版本 (Exchange 2007 或 Exchange 2010)。
  2. 檢查信箱的位置。
  3. 取得目標 CAS 的 ExternalURL。
  4. 取得來源 CAS 的重新導向類型。
    1. 如果 CrossSiteRedirectType=Manual，則發佈手動重新導向。
    2. 如果 CrossSiteRedirectType=Silent，則發佈無訊息重新導向。
      1. 如果來源與目標 CAS 已啟用 FBA，則來源 CAS 會將隱藏的表單及 URL 重新導向發佈回包含使用者認證與 FAB 設定的瀏覽器。
      2. 如果來源與目標 CAS 尚未啟用 FBA，則來源 CAS 會發佈 302 重新導向。

沒錯，跨網站無訊息重新導向可在來源與目標 OWA 虛擬目錄利用表單型驗證時做為 SSO 經驗。當 OWA 虛擬目錄驗證機制為 Windows 整合式驗證，並將 OWA 命名空間新增至「近端內部網路」安全性區域時，內部只有部署 OWA 的客戶也能達到 SSO 經驗。

什麼時候無法取得 SSO 經驗？

以下是在 Active Directory 網站之間執行重新導向時無法取得 SSO 經驗的幾個案例：

  1. 在來源與目標 OWA 虛擬目錄上使用基本驗證。
  2. 使用來源與目標 OWA 虛擬目錄上的其他驗證設定。
  3. 使用來源與目標 OWA 虛擬目錄上的雙因素驗證解決方案。
  4. 使用會利用其他來源與目標 OWA 命名空間網頁接聽程式的預先驗證解決方案 (例如，Microsoft Threat Management Gateway 2010)。
  5. 本機 CAS 向其他 Active Directory 網站的 CAS 發佈暫時重新導向時。

請記住，以上無法取得 SSO 經驗的案例仍會發生 302 重新導向 (又稱為無訊息重新導向)。

跨網站無訊息重新導向可讓使用者只需按一下連結即可獲得正確的 OWA 基礎結構，另外還可除去二次輸入認證的麻煩，因而提升使用者的滿意度。如果您還在使用 OWA 手動重新導向，強烈建議您在部署 Exchange 2010 SP2 時，啟用跨網站無訊息重新導向！

Ross Smith IV
資深專案經理
Exchange 客戶經驗

這是翻譯後的部落格文章。英文原文請參閱 OWA Cross-Site Silent Redirection in Exchange 2010 SP2