了解 Proxy 與重新導向
適用版本： Exchange Server 2010 SP2, Exchange Server 2010 SP3
上次修改主題的時間： 2016-11-28
在 Microsoft Exchange Server 2010 組織中，一個 Client Access Server 可作為組織內其他 Client Access Server 的 Proxy。組織中不同的 Active Directory 站台有多個 Client Access Server，而且這些站台中至少有一個不在網際網路上公開時，這相當有用。
Client Access Server 也可以執行 Microsoft Office Outlook Web App URL 和 Exchange ActiveSync 裝置的重新導向。當使用者連接到非本機 Active Directory 站台的 Client Access Server，或者 Active Directory 站台間的信箱遭到移動時，重新導向便相當實用。如果使用者應確實使用更有效的 URL，這也很有幫助。例如，使用者應使用較接近其信箱所在的 Active Directory 站台的 URL。
Client Access server 的回應會因通訊協定而異。不過，如果 Client Access server 接收要求的使用者信箱是位於 Active Directory 站台，而不是 Client Access server 所屬的站台，則 Client Access server 通常會採取下列動作：在此情況下，該伺服器會在位於與使用者信箱相同之 Active Directory 站台中 Client Access server 的相關虛擬目錄上，尋找 ExternalURL 內容是否存在。如果 ExternalURL 內容存在，且用戶端類型支援重新導向 (例如，Outlook Web App 或 Exchange ActiveSync)，Client Access Server 會執行對該用戶端的重新導向。如果 ExternalURL 內容不存在，或用戶端類型不支援重新導向 (例如，POP3 或 IMAP4)，Client Access Server 將嘗試由目標 Active Directory 站台代理此連線。
本主題說明代理及重新導向、各自的使用時機，以及如何針對各個案例設定 Client Access Server。
.gif "注意事項") 附註： |
|---|
| 如果您的組織中沒有多個 Active Directory 站台，就不需要針對 Proxy 處理或重新導向設定 Exchange 2010。不過，您可以依照本主題稍後的說明來設定 URL 的負載平衡。 |
| 附註： |
|---|
| 未在網際網路上公開的 Client Access Server 不需要有安全通訊端層 (SSL) 憑證，即可允許 Proxy 處理來自另一部 Client Access Server 的流量。依據預設，它們可以使用與 Exchange 2010 一起安裝的自我簽署憑證。不過，這些憑證通常不受內部用戶端 (如 Outlook Web App 或 Outlook) 的信任，而且使用這些憑證通常會導致憑證警告出現。如果內部用戶端位於與含有自我簽署憑證的 Client Access Server 相同的 Active Directory 站台中，您應該以用戶端信任的憑證授權單位所發出的憑證來取代自我簽署憑證。 |
目錄
Proxy 處理概觀
重新導向概觀
具有網路負載平衡的 Proxy 處理
用戶端存取方法摘要
Proxy 處理效能及延展性
Proxy 處理概觀
在 Microsoft Exchange Server 2003 中，前端伺服器會透過 HTTP 與後端伺服器通訊。在 Exchange Server 2007 和 Exchange 2010 中，Client Access Server 會透過 RPC 與 Exchange 信箱伺服器進行通訊。您必須在每個包含 Exchange 2010 信箱伺服器的 Active Directory 站台中，都有 Exchange 2010 Client Access Server。Proxy 處理會在 Client Access Server 傳送流量到其他 Client Access Server 時發生。Exchange 2010 Client Access Server 可以在下列情況下 Proxy 處理要求：
在 Exchange 2010 Client Access Server 之間 Proxy 處理兩部 Exchange 2010 Client Access Server 之間的要求可以讓具有多個 Active Directory 站台的組織指定某部 Client Access Server 作為網際網路方向伺服器，並且讓該伺服器 Proxy 對未顯現在網際網路上之 Client Access Server 的要求。然後網際網路方向 Client Access Server 會將要求 Proxy 處理至最靠近使用者信箱的 Client Access Server。
在 Exchange 2010 Client Access Server 和 Exchange 2007 Client Access Server 之間 Proxy 處理一個 Exchange 2010 站台內或 Exchange 2007 站台之間的 Active Directory Client Access Server 與 Active Directory Client Access Server 之間的要求，可讓 Exchange 2010 和 Exchange 2007 在相同組織中共存。如需如何升級與共存的詳細資訊，請參閱從 Exchange 2003 Client Access 升級和從 Exchange 2007 Client Access 升級。
Proxy 處理支援使用 Outlook Web App、Exchange ActiveSync、Exchange 控制台 (ECP)、POP3、IMAP4 和 Exchange Web 服務的用戶端。Proxy 處理支援在目的地 Client Access Server 執行與來源 Client Access Server 相同版本的 Microsoft Exchange 或舊版 Microsoft Exchange 時從某個 Client Access Server 到其他 Client Access Server，除了特定版本 URL 是必要的執行個體。如需混和的 Exchange 2007 和 Exchange 2010 環境中特定版本 URL 及傳統主機名稱的詳細資訊，請參閱從 Exchange 2007 Client Access 升級。如需混和的 Exchange 2010 和 Exchange 2013 環境中特定版本 URL 及傳統主機名稱的詳細資訊，請參閱建立舊版 Exchange 主機名稱。
.gif "警告") 警告： |
|---|
| 當使用 NTLM 驗證的 IMAP4 用戶端嘗試連線到沒有包含目標信箱之 Active Directory 站台的 Client Access Server，連線將會失敗。如果您要將 IMAP4 用戶端從一個 Active Directory 站台 Proxy 處理到另一個站台，則必須選擇備用的驗證方法。 |
| 附註： |
|---|
| 在每個想要允許網際網路用戶端存取的 Exchange 組織中，至少有一個 Active Directory 站台必須是網際網路方向。所有非網際網路方向的 Active Directory 站台都仰賴網際網路方向的 Client Access Server 或伺服器來 Proxy 來自外部用戶端的所有相關要求。 |
Client Access Proxy 處理
在上一張圖表中，使用者 1 的信箱位於信箱伺服器 1。使用者 2 的信箱位於信箱伺服器 2，而使用者 3 的信箱則位於信箱伺服器 3。每個信箱伺服器位於不同的 Active Directory 站台。使用者 1 可以透過 Client Access Server 1 存取其信箱，不需使用 Proxy 處理，而使用者 2 可以透過 Client Access Server 2 存取其信箱。如果使用者 3 嘗試透過 Client Access Server 1 或 2 存取其信箱，則伺服器會將其要求 Proxy 處理至 Client Access Server 3。Client Access Server 3 不是網際網路方向，但是可以接收防火牆內其他伺服器的要求。使用者看不到 Proxy 處理。
| 附註： |
|---|
| 不同站台中 Client Access Servers 間的通訊是透過安全 HTTP (HTTPS) 進行，但 Client Access Server 不會檢查預設使用的憑證狀態。該憑證只用於加密而非驗證，所以會忽略名稱不符、到期日期及信任狀態等項目。 |
Proxy 處理概觀
重新導向概觀
存取位於與包含信箱之站台不同之 Active Directory 站台中網際網路方向 Client Access Server 的 Outlook Web App 使用者，在 Client Access Server 是網際網路方向的情況下，可以被重新導向至相同站台中作為信箱伺服器的 Client Access Server。當 Outlook Web App 使用者嘗試連線至位於包含其信箱伺服器的 Active Directory 站台之外的 Client Access Server 時，會看到包含其信箱正確 Client Access Server 連結的網頁。這就是所謂的手動重新導向。在 Exchange 2010 SP2 中，系統管理員可以在使用者不知道的情況下設定跨網站無訊息重新導向，促使此重新導向程序發生。如需詳細資訊，請參閱本主題稍後的「跨網站無訊息重新導向」。
| 附註： |
|---|
| 在同時使用內部部署 Exchange Server 與 Office 365 的混合環境中，您無法使用跨網站無訊息重新導向。 |
存取位於與包含其信箱的站台不同的 Exchange ActiveSync 站台中網際網路方向 Client Access Server 的 Active Directory 使用者，如果 Client Access Server 是網際網路方向，而且用戶端行動電話或裝置已正確將實作的重新導向邏輯內建至與 Exchange 2007 和 Exchange 2010 進行通訊時使用的通訊協定，可以被重新導向至相同站台中作為其信箱伺服器的 Client Access Server。向裝置傳送包含裝置應使用之 URL 的 HTTP 451 錯誤碼，即可達成 Exchange ActiveSync 使用者的重新導向。然後裝置會自行重新設定為使用新的 URL。
下圖顯示重新導向如何在多個 Active Directory 站台中具有多個 Client Access Server 的組織中運作。
Exchange 2010 中 Exchange ActiveSync 與 Outlook Web App 的重新導向
在上一張圖表中，使用者 1 通常會使用他們的行動電話存取其位於 Active Directory 站台 1 中的信箱。接著系統管理員會將他們的信箱移至 Active Directory 站台 2 中的信箱伺服器 2。下一次裝置嘗試進行同步處理時，伺服器會以 HTTP 451 狀態錯誤回應。其中包含裝置目前針對該使用者應該使用的 URL。在流程的步驟 3 中，裝置會自行重新設定，並連線至所指定的 URL。信箱位於 Active Directory 站台 2 的使用者 2 會嘗試使用 Outlook Web App，透過網際網路連線至 Client Access Server 1 來開啟他們的信箱。使用手動重新導向時，使用者一驗證，Client Access Server 1 就會對使用者顯示網頁，其中含有連結到 Active Directory 站台 2 Client Access Server 的 Outlook Web App 的 URL。當使用者按一下連結，就會被帶到 Active Directory 站台 2 並且再次登入以存取他們的信箱。使用無訊息重新導向時，使用者驗證後，就會在無訊息的情況下重新導向到 Active Directory 站台 2 Client Access Server 的 Outlook Web App URL。
跨網站無訊息重新導向
| 附註： |
|---|
| 在同時使用內部部署 Exchange Server 與 Office 365 的混合環境中，您無法使用跨網站無訊息重新導向。 |
Exchange 2010 SP2 可讓系統管理員設定跨網站無訊息重新導向。跨網站無訊息重新導向會對於用戶端指向位在同一 Exchange 組織內不同 Active Directory 站台之 CAS 的要求執行無訊息重新導向。例如，具有 Active Directory 站台 A 的信箱的使用者存取 Active Directory 站台 B 的 Outlook Web App URL 將會以無訊息的方式重新導向到 Active Directory 站台 A 的 Outlook Web App URL。
若要設定跨網站無訊息重新導向，系統管理員必須使用已新增至 Set-OWAVirtualDirectory Cmdlet 的 CrossSiteRedirectType 新參數。此參數有兩個可能的設定。預設值是 Manual。
無訊息 採用此設定時，只要 Client Access Server 必須將 Outlook Web App 要求重新導向到 Client Access Server 或位於其他 Active Directory 站台的伺服器陣列時，使用者的 Web 瀏覽器就會被自動重新導向。在來源和目標 CAS OWA 虛擬目錄 (必須要有 SSL) 上設定表單式驗證時，則無訊息重新導向也會是單一的登入事件。若要使重新導向發生，目標 Client Access Server Outlook Web App 虛擬目錄必須設定
ExternalURL值。手動 當採用此設定時，使用者將會收到通知，表示使用者所存取的 URL 錯誤且必須按一下連結以存取其信箱的正確 Outlook Web App URL。只有在 Client Access Server 判斷它必須將 Outlook Web App 要求重新導向到 Client Access Server 或位於其他 Active Directory 站台的伺服器陣列時，才會發出此通知。若要使重新導向發生，目標 Client Access Server Outlook Web App 虛擬目錄必須設定
ExternalURL值。
例如：
Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent
如需有關 Set-TransportRule Cmdlet 的詳細資訊，請參閱：Set-OwaVirtualDirectory
Exchange ActiveSync 的 Proxy 處理及重新導向
以下一系列步驟顯示如何為使用行動電話連線至名為 CAS-01 之 Exchange 2010 Client Access Server 的使用者處理連入要求。
Client Access Server 會查詢 Active Directory 以判斷使用者信箱的位置及信箱伺服器上安裝的 Microsoft Exchange 版本。
如果使用者的信箱位於 Exchange 2003 伺服器上，則會將連入要求直接 Proxy 處理至 Exchange 2003 伺服器，該伺服器主控使用者的信箱和 Exchange ActiveSync 虛擬目錄。依預設，在 Exchange 2003 中，Exchange ActiveSync 虛擬目錄安裝在所有信箱伺服器上。使用者信箱的 Active Directory 站台不適用於此情形，因為 Exchange 2003 不使用 Active Directory 站台來判斷位置。其連線的方向永遠是直接從 Exchange 2010 Client Access Server 到 Exchange 2003 信箱伺服器。
附註：在 Exchange 2003 伺服器上擁有信箱的使用者嘗試透過 Exchange 2010 Client Access Server 使用 Exchange ActiveSync 時會收到錯誤，而且除非在 Exchange 2003 伺服器的 Microsoft-Server-ActiveSync 虛擬目錄上啟用整合式 Windows 驗證，否則無法進行同步處理。整合式 Windows 驗證可讓 Exchange 2010 Client Access Server 和 Exchange 2003 後端伺服器進行通訊。 如果使用者的信箱位於 Exchange 2007 信箱伺服器上，CAS-01 會將 Exchange 2007 Client Access Server 放置於與使用者的信箱伺服器相同的 Active Directory 站台。這可以是與 CAS-01 相同的 Active Directory 站台。CAS-01 代理 Exchange ActiveSync 要求至 Exchange 2007 Client Access Server 的 InternalURL，無論其 ExternalURL 設定為何。此要求位於 IIS 中的 Microsoft Server Exchange ActiveSync 虛擬目錄的 /Proxy 虛擬目錄之下，且預設情況下會針對該虛擬目錄啟用整合式 Windows 驗證。
如果使用者的信箱位於與 CAS-01 相同之 Active Directory 站台的 Exchange 2010 信箱伺服器上，CAS-01 便會提供對信箱的存取。如果使用者的信箱位於不同 Active Directory 站台的 Exchange 2010 信箱伺服器上，CAS-01 會將 Client Access Server 放置於與使用者的信箱伺服器相同的 Active Directory 站台。CAS-01 會判斷位於該 Active Directory 站台的任何 Exchange 2010 Client Access Server 是否已在 Exchange ActiveSync 虛擬目錄上設定 ExternalURL 屬性。如果已設定，CAS-01 會向用戶端發出一個 HTTP 錯誤碼 451，其中包含 ExternalURL 值，並指示用戶端重新導向至該位置。如果未設定 ExternalURL 值，則會使用 InternalURL 屬性所指定的 FQDN，將連線 Proxy 處理至 Client Access Server 上的 /Proxy 虛擬目錄。此虛擬目錄是位於 IIS 中的 Exchange ActiveSync 虛擬目錄之下，且預設情況下會針對該虛擬目錄啟用整合式 Windows 驗證。
.gif "重要事項")
重要事項：使用基本驗證的虛擬目錄之間無法進行 Proxy 處理。對於要在不同伺服器上 Exchange ActiveSync 虛擬目錄之間 Proxy 處理的用戶端通訊，/Proxy 虛擬目錄必須使用整合式 Windows 驗證。
Proxy 處理概觀
Outlook Web App 的 Proxy 處理及重新導向
以下一系列步驟顯示如何為使用 Outlook Web App 連線至名為 CAS-01 之 Exchange 2010 Client Access Server 的使用者處理的連入要求。
Client Access Server 會查詢 Active Directory 以判斷使用者信箱的位置及信箱伺服器上安裝的 Microsoft Exchange 版本。
如果使用者的信箱位於 Exchange 2003 伺服器，且使用者嘗試使用 https://domain name/owa 存取 Outlook Web App，則這些使用者會收到錯誤訊息，因為 Exchange 2010 Client Access Server 無法讓 Outlook Web App 直接存取 Exchange 2003 信箱。不過，如果系統管理員已設定從 Exchange 2010 至 Exchange 2003 的重新導向 (這在從 Exchange 2003 移轉至 Exchange 2010 時相當有用)，則 Outlook Web App 虛擬目錄的 Exchange2003URL 屬性會設定為網際網路方向之 Exchange 2003 伺服器的值。
如果使用者的信箱位於 Exchange 2007 信箱伺服器，CAS-01 會將 Client Access Server 放置於與使用者的信箱伺服器相同的 Active Directory 站台。如果 Exchange 2007 信箱伺服器位於與 CAS-01 相同的 Active Directory 站台，則會執行四個可能動作中的其中一個動作。
CAS-01 會尋找 ExternalAuthenticationMethods 設定與 Exchange 2010 Client Access Server 上 InternalAuthenticationMethods 設定相同的 Exchange 2007 ExternalURL 屬性。如果設定相符，CAS-01 將會重新導向到此外部 URL。如果來源和目標 CAS 啟用表單型驗證 (FBA)，則來源 CAS 會向包含使用者認證和 FBA 設定 (連同重新導向 URL) 的瀏覽器發回隱藏的表單。這對使用者是透明的。
如果找不到相符的 ExternalURL 設定，CAS-01 會尋找已設定 ExternalURL 屬性的 Exchange 2007 Client Access Server，而不論是否相符。如果有找到，CAS-01 將會重新導向至此外部 URL。此時會提示使用者進行驗證。
如果找不到相符的 ExternalURL 設定，CAS-01 會尋找其 InternalURL 內容中的 InternalAuthenticationMethods 設定與 Exchange 2010 Client Access server 的 InternalAuthenticationMethods 設定相同的 Exchange 2007 Client Access server。如果有找到，CAS-01 將會重新導向至此 InternalURL。如果已啟用表單式驗證，則會進行單一登入的重新導向動作。
如果找不到相符的 InternalURL，CAS-01 將會尋找已設定 InternalURL 的 Exchange 2007 Client Access Server，而不論是否相符。如果有找到，CAS-01 將會重新導向至此 InternalURL。此時會提示使用者進行驗證。
如果 Exchange 2007 信箱伺服器位於不同的 Active Directory 站台，CAS-01 會判斷該 Active Directory 站台內是否已設定 ExternalURL 屬性。如果已設定，而跨網站無訊息重新導向並未啟用，則 CrossSiteRedirectType 值會設定為 [手動[，並且會發出手動重新導向。在此情況下，使用者會得到一個重新導向至指定 URL 的可點選連結。
如果跨網站無訊息重新導向已經啟用，則 CrossSiteRedirectType 值會設為 [無訊息]，而使用者會自動重新導向至指定的 URL。如果 ExternalURL 屬性不存在，且 /OWA 虛擬目錄的驗證方法設定為整合式 Windows 驗證，CAS-01 會將使用者的要求 Proxy 處理至 InternalURL 屬性所指定的 Client Access Server。
重要事項：若要讓 Exchange 2010 Client Access Server 將 Outlook Web App 要求 Proxy 處理至另一個 Exchange 2007 站台中的 Active Directory Client Access Server，您必須從目標 Exchange 2007 站台的 %installpath%\ClientAccess\OWA\ 資料夾中，將版本最高的資料夾從 Active Directory Client Access Server 複製到提出 Proxy 要求的 Exchange 2010 Client Access Server 上相同的路徑。 重要事項：Exchange 2010 Client Access Server 絕不會將 Outlook Web App 要求 Proxy 處理至相同 Active Directory 站台中的 Exchange 2007 Client Access Server。相同 Active Directory 站台中所有的要求將根據所設定的屬性 (使用 Client Access Server 的 InternalURL 或 ExternalURL 屬性) 重新導向至 Exchange 2007 Client Access Server。 如果使用者的信箱位於與 CAS-01 相同之 Active Directory 站台的 Exchange 2010 信箱伺服器上，CAS-01 便會提供對信箱的存取。如果使用者的信箱位於不同 Active Directory 站台的 Exchange 2010 信箱伺服器上，CAS-01 會將 Client Access Server 放置於與使用者的信箱伺服器相同的 Active Directory 站台。找到所需的站台時，Exchange 2010 會判斷該 Active Directory 站台的 Client Access Server 是否已設定 ExternalURL 屬性。如果已經設定，而跨網站無訊息重新導向並未啟用，則使用者會得到一個重新導向至指定 URL 的可點選連結。如果跨網站無訊息重新導向已經啟用，則使用者會自動重新導向至指定的 URL。如果未設定 ExternalURL，且虛擬目錄上的驗證方法設定為整合式 Windows 驗證，CAS-01 會將使用者的要求 Proxy 處理至 InternalURL 屬性所指定的 Client Access Server。
Exchange 控制台的 Proxy 處理
Exchange 2010 為使用者和組織系統管理員提供 Web 式介面，可讓他們為信箱或組織進行設定。透過 Outlook Web App 的 [選項] 功能表存取，或在 Outlook 2010 中選擇 [語音信箱] 選項、要求郵件追蹤資訊，或設定行動通知，皆可存取 Exchange 控制台 (ECP)。在 Outlook 內選取這些選項將啟動 Web 瀏覽器工作階段。
工作階段的目的地取決於 Outlook 用戶端的目前連線狀態。如果 Outlook 用戶端是使用 RPC over TCP 連線，則用戶端會連線至 ECP 虛擬目錄的 InternalURL 值。如果用戶端是使用 Outlook 無所不在進行連線，則 Outlook 用戶端會啟動瀏覽器工作階段。瀏覽器工作階段將嘗試連線至 ECP 虛擬目錄的 ExternalURL 值。URL 是經由自動探索服務提供給 Outlook 用戶端。
內部用戶端透過 TCP 連線時，ECP 工作階段始終會連線至相同 Active Directory 站台中作為使用者信箱的 Client Access Server。此案例中未使用 Proxy 處理。企業網路外部的用戶端使用 Outlook 無所不在進行連線時，用戶端會開啟對 ECP 虛擬目錄之外部 URL 的瀏覽器工作階段，如果使用者的信箱位於非網際網路方向的站台中，則會開啟網際網路方向 Active Directory 站台之外部 URL 的瀏覽器工作階段。
ECP 的 Proxy 處理邏輯與 Outlook Web App 相同。如果使用者的信箱位於相同 Active Directory 站台中作為 Client Access Server 的 Exchange 2010 信箱伺服器上，則該 Client Access Server 會提供對信箱的存取。如果使用者的信箱位於不同 Active Directory 站台的 Exchange 2010 信箱伺服器上，Client Access Server 會將 Client Access Server 放置於與使用者的信箱伺服器相同的 Active Directory 站台。原始的 Client Access Server 會將使用者的要求 Proxy 處理至該 Client Access Server。
ECP 會執行重新導向動作，但除非使用者明確輸入存取 ECP 的 URL，否則將很少進行。如果使用者是從 Outlook Web App 存取 ECP，Outlook Web App 會負責確保使用者使用的是正確的 URL。如果使用者使用的是 Outlook 2010，則由 Outlook 和自動探索服務負責確保使用者使用的是 ECP 的正確 URL。
Proxy 處理概觀
Exchange Web 服務的 Proxy 處理
Exchange Web 服務所提供的 XML 訊息介面，可讓您管理 Exchange 儲存區項目，並且可以從用戶端應用程式存取 Exchange 伺服器功能。從 Proxy 處理、重新導向和用戶端觀點來看，此功能通常用於下列其中一種情況：
可用性服務要求
自動探索要求
設定和檢查自動回覆 (OOF) 狀態
使用 Exchange Web 服務撰寫的應用程式可以針對設定自動回覆 (郵件答錄機) 訊息之類的工作使用 Proxy 處理行為，這些訊息可視需要在 Active Directory 站台間進行 Proxy 處理。
下列步驟顯示如何為針對名為 CAS-01 的 Exchange 2010 Client Access Server 提出可用性服務要求的使用者處理連入要求。使用者使用 Outlook Web App 來檢查相同 Exchange 組織中其他使用者的可用性。
CAS-01 會查詢 Active Directory 以判斷使用者信箱的位置及信箱伺服器上安裝的 Microsoft Exchange 版本。
如果使用者的信箱位於 Exchange 2003 伺服器上，Outlook Web App 會建立對 Exchange 2003 伺服器之 /Public 虛擬目錄的 HTTP 連線，並從空閒/忙碌系統資料夾接收所要求的資訊。
如果使用者信箱位在 Exchange 2007 信箱伺服器上，則會傳回錯誤給使用者。任何 Exchange 組織中的 Exchange 2007 信箱伺服器上若包含信箱，則必須有可從外部存取的 Exchange 2007 Client Access Server。自動探索服務負責將正確的 Exchange Web 服務 URL 傳回給用戶端。此 URL 與使用者信箱所在的信箱伺服器的版本必須符合。
如果使用者的信箱位於與 CAS-01 相同之 Active Directory 站台的 Exchange 2010 信箱伺服器上，CAS-01 會存取信箱本身，以擷取所要求的資訊。如果使用者的信箱位於不同 Active Directory 站台的 Exchange 2010 信箱伺服器上，CAS-01 會使用 /EWS 虛擬目錄之 InternalURL 屬性所指定的 FQDN，將要求 Proxy 處理至該 Active Directory 站台的 Client Access Server。
重要事項：Exchange Client Access Server 會將可用性服務要求從某個伺服器 Proxy 處理至另一個伺服器，而不論是否設定 ExternalURL 屬性。 重要事項：某些 Exchange Web 服務應用程式會使用 GetEvents 和 Unsubscribe 等 Web 方法，這些方法具有非常強大的 Client Access Server 相似性。當某個 Client Access Server 必須將這些要求 Proxy 處理至另一個 Active Directory 站台時，可以使用 Client Access Server 的 InternalNLBBypassURL 屬性進行，該屬性應始終設定為主機伺服器本身的 FQDN。如此可確保 Client Access Server 提出的要求可以與目標 Active Directory 站台中特定的 Client Access Server 保持相似性。
Exchange Web 服務本身不提供重新導向功能，因為自動探索服務 (用於提供 URL 給應用程式) 會提供存取特定信箱所需的 URL。例如，在 Active Directory 站台間移動信箱時，Outlook 會在下一次提出查詢時，從自動探索服務接收到更新的 Active Directory 站台特定 URL。這有時會導致用戶端對 Active Directory 站台中的 Client Access Server 提出可用性服務要求，而不是對其信箱所在的 Client Access Server 提出可用性服務要求。不過，由於可用性服務仍會處理這些要求，並視需要對這些要求進行 Proxy 處理，因此對使用者沒有影響。
| 重要事項： |
|---|
| 任何 Exchange 組織中的 Exchange 2007 信箱伺服器上若包含信箱，則必須有可從外部存取的 Exchange 2007 Client Access Server。當自動探索服務將正確的 Exchange Web 服務 URL 傳回給要求用戶端時，此 URL 符合使用者信箱所在之伺服器的版本。對於任何在 Exchange 2007 信箱伺服器和 Exchange 2010 信箱伺服器上都包含信箱的 Exchange 組織，必須為 Exchange Web 服務設定兩個外部 URL，各用於每個已安裝的 Exchange 版本。 |
POP3 和 IMAP4 的 Proxy 處理
Exchange 2010 可以 Proxy 處理 Client Access Server 和 Active Directory 站台之間的 POP3 和 IMAP4 工作階段。
下列步驟顯示如何為使用 POP3 用戶端，對名為 CAS-01 之 Exchange 2010 Client Access Server 提出要求的使用者處理連入要求。
CAS-01 會查詢 Active Directory 以判斷使用者信箱的位置及信箱伺服器上安裝的 Microsoft Exchange 版本。
如果使用者的信箱位於 Exchange 2003 伺服器上，CAS-01 會將連線 Proxy 處理至主控使用者信箱的 Exchange 2003 伺服器上執行的 POP3 服務。
如果使用者的信箱位於 Exchange 2007 信箱伺服器上，CAS-01 會將 Exchange 2007 Client Access Server 放置於與使用者的信箱伺服器相同的 Active Directory 站台，該站台可以與 CAS-01 位於相同的 Active Directory 站台。CAS-01 會將要求 Proxy 處理至 Client Access Server。
如果使用者的信箱位於與 CAS-01 相同之 Active Directory 站台的 Exchange 2010 信箱伺服器上，CAS-01 會存取信箱本身。如果使用者的信箱位於不同 Active Directory 站台的 Exchange 2010 信箱伺服器上，CAS-01 會將要求 Proxy 處理至使用該伺服器之 POP 組態的 InternalConnectionSettings 屬性所指定 FQDN 的 Client Access Server。
重要事項：POP3 或 IMAP4 服務沒有 InternalURL 或 ExternalURL 設定，而 Exchange 2010 Client Access Server 會視需要將 POP3 和 IMAP4 服務要求從某部伺服器 Proxy 處理至另一部伺服器。 重要事項：Client Access Server 嘗試 Proxy 處理至其他 Active Directory 站台時，不會檢查 POP3 或 IMAP4 服務是否確實在遠端 Client Access Server 上執行。因此，不僅需要確定遠端 Active Directory 站台中的每一部 Client Access Server 皆執行該服務，也需要考慮使用負載平衡的服務。本主題稍後將討論負載平衡。
Proxy 處理概觀
Proxy 處理組態
如果 Client Access Server 是網際網路方向，則使用 Exchange 管理主控台 (EMC) 或 Exchange 管理命令介面 (命令介面) 設定 /Microsoft-Server-ActiveSync、/OWA、/ECP 和 /EWS 虛擬目錄上的 ExternalURL 屬性。EWS 虛擬目錄只能使用命令介面進行設定。在 Exchange 2010 的初始設定期間會自動設定 InternalURL 屬性，並且應該只有在您想要使用負載平衡的解決方案時才進行變更。ExternalURL 屬性應包含針對 DNS 中您的 Exchange 組織註冊的 FQDN。
下表包含使用 URL https://mail.contoso.com 存取 Outlook Web App 的 Exchange 組織的網際網路方向 Client Access Server 的 ExternalURL 和 InternalURL 屬性的適當值。第二張表格包含相同組織的第二個 Active Directory 站台中非網際網路方向 Client Access Server 的 ExternalURL 和 InternalURL 屬性的適當值。您必須確實將所有虛擬目錄上的驗證方法設定為整合式 Windows 驗證。除了 POP3 和 IMAP4 之外 (其使用 SSL/TLS 並 Proxy 使用者的基本驗證憑證)，Proxy 處理不支援使用其他驗證方法的虛擬目錄。
| 附註： |
|---|
| 如果使用命令介面建立新的 Outlook Web App 虛擬目錄，您必須手動設定這些虛擬目錄的 InternalURL 屬性。 |
網際網路方向 Client Access Server 的 InternalURL 和 ExternalURL 設定
| Exchange 2010 服務 | InternalURL 設定 | ExternalURL 設定 |
|---|---|---|
Outlook Web App |
https://fullyqualifiedcomputername/OWA |
https://mail.contoso.com/OWA |
Exchange ActiveSync |
https://fullyqualifiedcomputername/Microsoft-Server-ActiveSync |
https://mail.contoso.com/Microsoft-Server-ActiveSync |
Exchange Web 服務 |
https://fullyqualifiedcomputername/EWS/Exchange.asmx |
https://mail.contoso.com/EWS/Exchange.asmx |
Exchange 控制台 |
https://fullyqualifiedcomputername/ECP |
https://mail.contoso.com/ECP |
非網際網路方向 Client Access Server 的 InternalURL 和 ExternalURL 設定
| Exchange 2010 服務 | InternalURL 設定 | ExternalURL 設定 |
|---|---|---|
Outlook Web App |
https://fullyqualifiedcomputername/OWA |
|
Exchange ActiveSync |
https://fullyqualifiedcomputername/Microsoft-Server-ActiveSync |
|
Exchange Web 服務 |
https://fullyqualifiedcomputername/EWS/Exchange.asmx |
|
Exchange 控制台 |
https://fullyqualifiedcomputername/ECP |
|
設定重新導向
如果您有一個以上網際網路方向的 Active Directory 站台，請使用 EMC 或命令介面設定 /OWA 和 /Microsoft-Server-ActiveSync 虛擬目錄上的 ExternalURL 屬性，以允許在它們之間進行重新導向。在 Exchange 2010 的初始設定期間會自動設定 InternalURL 屬性，並且應該只有在您想要使用負載平衡的解決方案時才進行變更。下列兩張表格列出 Contoso 公司兩個 Active Directory 站台中 Client Access Server 的 ExternalURL 和 InternalURL 設定。這兩個站台分別是 usa.contoso.com 和 europe.contoso.com。
| 附註： |
|---|
| 如果使用命令介面建立新的 Outlook Web App 虛擬目錄，您必須手動設定這些虛擬目錄的 InternalURL 屬性。 |
usa.contoso.com 站台中網際網路方向 Client Access Server 的 InternalURL 和 ExternalURL 屬性設定
| Exchange 2010 服務 | InternalURL 設定 | ExternalURL 設定 |
|---|---|---|
Outlook Web App |
https://fullyqualifiedcomputername/OWA |
https://usa.contoso.com/OWA |
Exchange 控制台 |
https://fullyqualifiedcomputername/ECP |
https://usa.contoso.com/ECP |
Exchange ActiveSync |
https://fullyqualifiedcomputername /Microsoft-Server-ActiveSync |
https://usa.contoso.com/ Microsoft-Server-ActiveSync |
Exchange Web 服務 |
https://fullyqualifiedcomputername /EWS/Exchange.asmx |
https://usa.contoso.com/EWS/Exchange.asmx |
europe.contoso.com 站台中網際網路方向 Client Access Server 的 InternalURL 和 ExternalURL 屬性設定
| Exchange 2010 服務 | InternalURL 設定 | ExternalURL 設定 |
|---|---|---|
Outlook Web App |
https://fullyqualifiedcomputername/OWA |
https://europe.contoso.com/OWA |
Exchange 控制台 |
https://fullyqualifiedcomputername/ECP |
https://europe.contoso.com/ECP |
Exchange ActiveSync |
https://fullyqualifiedcomputername /Microsoft-Server-ActiveSync |
https://europe.contoso.com/ Microsoft-Server-ActiveSync |
Exchange Web 服務 |
https://fullyqualifiedcomputername /EWS/Exchange.asmx |
https://europe.contoso.com/EWS/Exchange.asmx |
| 附註： |
|---|
| 如果沒有在至少一個 Active Directory 站台上的 Exchange ActiveSync 虛擬目錄上設定 ExternalURL 屬性，自動探索服務將在設定行動電話時失敗，因為在自動探索處理期間，會將 ExternalURL 屬性的設定值傳遞給行動電話。 |
Proxy 處理概觀
具有網路負載平衡的 Proxy 處理
在具有多個 Active Directory 站台以及各個站台中有多個 Client Access Server 的組織中，您可以使用網路負載平衡 (NLB)，將負載平衡流量 Proxy 處理到各個站台中的 Client Access Server，並讓使用者直接存取這些伺服器。單是部署負載平衡器並不足以確保流量能有效地平衡。您也必須對 InternalURL 和 ExternalURL 內容執行一些額外的組態。建議您在負載平衡陣列中只包含相同 Active Directory 站台內的 Client Access Server。您可以在網際網路方向 Active Directory 站台和非網際網路方向 Active Directory 站台中部署 NLB。
下表列出您應在網際網路方向和非網際網路方向站台中，針對 Client Access Server 的虛擬目錄進行的設定。您應在 DNS 中設定 NLB 的 FQDN，以解析負載平衡裝置或服務。接著負載平衡解決方案會將負責將流量轉送至適當的 Client Access Server。
使用 NLB 之組織中 Client Access Server 的虛擬目錄設定
| 虛擬目錄/服務 | InternalURL | ExternalURL (網際網路方向的 Active Directory 站台) | ExternalURL (非網際網路方向的 Active Directory 站台) |
|---|---|---|---|
/OWA |
NLB FQDN (請參閱下列方針) |
NLB FQDN |
$null |
/ECP |
NLB FQDN (請參閱下列方針) |
NLB FQDN |
$null |
/Microsoft-Server-ActiveSync |
NLB FQDN |
NLB FQDN |
$null |
/OAB |
NLB FQDN |
NLB FQDN |
$null |
/EWS |
NLB FQDN |
NLB FQDN |
$null |
POP/IMAP |
(InternalConnectionsSettings) NLB FQDN |
不適用 |
不適用 |
我們建議您採用下列方針設定 InternalURL 屬性：
如果內部有 Outlook 2010 使用者，則 Active Directory 站台中所有 Client Access Server 上的 /OWA 與 /ECP 虛擬目錄的 InternalURL 屬性可以設定為該站台中伺服器的 NLB FQDN。
如果 Active Directory 站台中的 Client Access Server 是任何其他 Active Directory 站台中 Client Access Server 的 Outlook Web App 或 ECP Proxy 處理要求的目標，則請務必設定您的負載平衡器以確保相似性的維持。這是因為網際網路方向站台的 Client Access Server 無法針對每個個別要求選取伺服器並維持自身的相似性。
下表列出使用網路負載平衡 (NLB) 的組織中虛擬目錄所需的各種驗證設定。在使用 NLB 的組織中，NLB URL 用於取代用戶端連線的特定 Client Access Server URL。
使用 NLB URL 進行容錯和負載平衡的組織中 Client Access server 的虛擬目錄驗證設定
| 虛擬目錄/服務 | 網際網路方向的 Active Directory 站台 | 非網際網路方向的 Active Directory 站台 |
|---|---|---|
/OWA |
如果使用 Microsoft Forefront Threat Management Gateway 2010 (Forefront TMG) 或 Microsoft Forefront Unified Access Gateway 2010 (Forefront UAG)，且已啟用表單式驗證，請根據防火牆規則委派設定，決定要使用基本或整合式 Windows 驗證。 如果流量是從網際網路傳遞至未預先驗證的 Client Access Server，則使用表單式驗證。 您應該在 /OWA 和 /ECP 虛擬目錄上啟用相同的驗證方法。 |
整合式 Windows 驗證 |
/ECP |
如果使用 Forefront TMG 或 Forefront UAFG，且已啟用表單式驗證，請根據防火牆規則委派設定，決定要使用基本或整合式 Windows 驗證。 如果流量是從網際網路傳遞至未預先驗證的 Client Access Server，則使用表單式驗證。 您應該在 /OWA 和 /ECP 虛擬目錄上啟用相同的驗證方法。 |
整合式 Windows 驗證 |
/Microsoft-Server-ActiveSync |
基本驗證。 |
基本驗證 (使用 /Proxy 子虛擬目錄執行 Proxy 處理)。 |
/OAB |
基本或整合式 Windows 驗證，取決於防火牆規則委派設定。 |
基本或整合式 Windows 驗證，取決於防火牆規則委派設定 (OAB 的要求不會在 Active Directory 站台間 Proxy 處理。此虛擬目錄只限 Outlook 用戶端使用)。 |
/EWS |
基本 (選用，取決於防火牆規則委派設定)。 需要整合式 Windows 驗證。 |
整合式 Windows 驗證 |
POP/IMAP |
用戶端連線方法所需。 |
用戶端連線方法所需 |
Proxy 處理概觀
在 Active Directory 站台之間進行 Proxy 處理時 Client Access Server 使用的負載平衡邏輯
將成為 Proxy 嘗試目標的站台中存在多部 Client Access Server，且使用者的信箱所在的伺服器為合併的 Client Access Server 和信箱伺服器時，來源 Active Directory 站台中的 Client Access Server 始終會選擇合併的 Client Access Server 和信箱伺服器作為 Proxy 嘗試的目標。
Outlook Web App、ECP 和 Exchange Web 服務會處理不同於可用性服務和 Exchange ActiveSync 所進行的負載平衡。將 Outlook Web App、ECP 和 Exchange Web 服務部署於相同 Active Directory 站台中的多部 Client Access Server 上時，會實作各自的負載平衡。如果使用者嘗試透過 https://mail.contoso.com/owa 存取 Outlook Web App，並且 Proxy 處理至 CAS-01，下次使用者嘗試存取 Outlook Web App 時，即使 CAS-02 的同時連線較少，還是會再次 Proxy 處理至 CAS-01。這麼做是為了確保長期交易得以完成，而不需重新驗證或再次要求資料。這就是所謂的「相似性」。如果 CAS-01 無法使用，則會將使用者 Proxy 處理至 CAS-02，且可能會再次要求使用者進行驗證。
在 Exchange 站台之間進行 Proxy 處理時，儘管已使用 NLB URL 設定目標伺服器的 InternalURL 屬性，Active Directory Web 服務仍然可以維持相似性。這是因為 Client Access Server 會為需要相似性的應用程式 (使用目標伺服器上的 InternalNLBBypassURL 屬性) 建立 Proxy 要求。InternalNLBBypassURL 屬性會設定為目標伺服器的 FQDN，且預設會使用 Windows 驗證。
| 附註： |
|---|
| 對於 Outlook Web App、ECP 和 Exchange Web 服務，您的防火牆應設定 Cookie 型相似性或 IP 型相似性。這可確保特定用戶端應用程式每次都能連線至相同的伺服器。這是必要步驟，如此就不用在每次要求時重複執行 SSL 交涉。請務必讓從用戶端應用程式到最終參與交易的 Client Access Server 保持相似性。 |
| 附註： |
|---|
| 您不需要在 Client Access Server 上變更InternalNLBBypassURL 屬性的值。如果變更它，就會中斷所 Proxy 處理的 Exchange Web 服務要求。 |
Exchange ActiveSync 的處理程序不同。網際網路方向的 Client Access Server 將要求 Proxy 處理至非網際網路方向的 Client Access Server 時，要求的 Client Access Server 會在目標站台中尋找 Client Access Server，並嘗試使用 InternalURL 屬性中設定的值連線至該伺服器。如果伺服器未回應，要求將失敗，且會傳回錯誤給用戶端。建議您在 NLB 陣列中實作循環配置資源的負載平衡，並將 InternalURL 屬性設定為負載平衡值。
同時也建議實作可用性服務的負載平衡。可用性服務要求不需要維持其連線狀態。也就是說，相同用戶端的兩個連續可用性服務要求可以 Proxy 處理至目的地 Active Directory 站台中不同的 Client Access Server，而不會影響效能，而且如果已將 InternalURL 屬性設定為負載平衡值，則不會發生驗證問題。此外，將 InternalURL 屬性設定為負載平衡值，有益於任何內部的 Outlook 2007 和 Outlook 2010 用戶端，因為自動探索服務會為那些用戶端提供 InternalURL 屬性中設定的負載平衡值，以允許它們完成它們的可用性服務要求。
如需網路負載平衡的詳細資訊，請參閱瞭解 Exchange 2010 中的負載平衡。
| 附註： |
|---|
| 在許多部署中，Client Access server role 和 Hub Transport server role 是安裝在同一部電腦上。在此拓撲中，您可以個別設定 Client Access server role 和 Hub Transport server role 的 NLB。Hub Transport server role 目前不支援 NLB。但是，Client Access server role 支援網路負載平衡。若要設定 Client Access server role 而非 Hub Transport server role 的 NLB，請針對用戶端存取設定通訊埠 80 和 443。Hub Transport server role 會執行自己軟體內的高可用性。 |
Proxy 處理概觀
用戶端存取方法摘要
下表摘要說明用於存取 Exchange 2010 的通訊協定，以及如何用於 Proxy 處理及重新導向。
重新導向和 Proxy 處理的用戶端存取通訊協定
| 通訊協定/應用程式 | 支援 Client Access Server 之間的重新導向 | 支援 Client Access Server 之間的 Proxy 處理 | 註解 |
|---|---|---|---|
Outlook Web App |
是 |
是 |
每個 Active Directory 站台中都必須有 Client Access Server 才能使用 Outlook Web App。 |
Exchange 控制台 |
是 |
是 |
每個 Active Directory 站台中都必須有 Client Access Server 才能使用 ECP。 |
Exchange ActiveSync |
是 |
是 |
每個 Active Directory 站台中都必須有 Client Access Server 才能使用 Exchange ActiveSync。 |
Exchange Web 服務 |
無 (自動探索服務會提供正確的 ExternalURL 值給應用程式) |
是 |
每個 Active Directory 站台中都必須有 Client Access Server 才能使用 Exchange Web 服務。 |
可用性服務 |
無 (自動探索服務會提供正確的 ExternalURL 值給應用程式) |
是 |
每個 Active Directory 站台中都必須有 Client Access Server 才能使用可用性服務。 |
POP3 及 IMAP4 |
否 |
是 |
每個 Active Directory 站台中都必須有 Client Access Server 才能使用 POP3 和 IMAP4。 |
Proxy 處理效能及延展性
在 Exchange 2010 Proxy 處理環境中，當 Client Access Server 收到大量的並行要求時通常都會導致效能不佳。此問題的原因通常是因為 ASP.NET 的 Web 服務要求造成的執行緒和可用連線耗盡，使 Client Access Server 拒絕要求或在處理要求時呈現高延遲。
若要解決這些問題，您可以設定數個 ASP.NET 參數，方法是在 Client Access Server 上編輯 Machine.config 檔案。如需如何設定這些參數的相關資訊，請參閱 Microsoft 知識庫文章 821268 當您從 ASP.NET 應用程式進行 Web 服務要求時發生的爭用、效能不佳和死結。
知識庫文章 821268 中說明的兩個參數在 Exchange 2010 代理環境中必須設為不同的值。建議您允許每個處理器有 36 個執行緒，並將 maxconnections 值設為 2,000。
如需伺服器效能的詳細資訊，請參閱管理 Windows Server 2003 上的 .NET Framework。
© 2010 Microsoft Corporation. 著作權所有，並保留一切權利。