瞭解資料庫可用性群組

 

適用版本： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上次修改主題的時間： 2015-03-09

資料庫可用性群組 (DAG) 是內建在 Microsoft Exchange Server 2010 中的高可用性與站台回復性架構的基礎元件。DAG 是一組多達 16 個信箱伺服器的群組，可主控資料庫集，並提供從影響個別伺服器或資料庫的失敗中自動進行資料庫層級復原的功能。

DAG 是信箱資料庫複寫、資料庫與伺服器轉換、容錯移轉，以及名為 Active Manager 之內部 Exchange 2010 元件的界限。Active Manager 會在 DAG 中的每部伺服器上執行，負責管理轉換和容錯移轉。如需 Active Manager 的相關資訊，請參閱 瞭解 Active Manager。

DAG 中的任何伺服器都可以主控來自 DAG 中任何其他伺服器的信箱資料庫副本。當伺服器新增至 DAG 後，它即可與 DAG 中其他的伺服器搭配使用，以便針對影響信箱資料庫的失敗 (例如磁碟故障或伺服器失敗) 進行自動復原功能。

目錄

資料庫可用性群組週期

使用資料庫可用性群組以獲取高可用性

使用資料庫可用性群組來取得站台回復性

使用資料庫可用性群組的用戶端體驗

資料庫可用性群組週期

DAG 會善用稱為增量部署的 Exchange 2010 功能，此功能可在 Exchange 安裝完畢後，針對所有信箱伺服器與資料庫部署服務與資料可用性。部署 Exchange 2010 完畢後，您可以建立 DAG、將信箱伺服器新增至 DAG，然後在 DAG 成員之間複寫信箱資料庫。

附註：
若是伺服器與解決方案與 Exchange 2010 系統需求 相容，則可支援建立包含實體信箱伺服器與虛擬信箱伺服器組合的 DAG。與所有 Exchange 高可用性組態相同，您必須確定已適當地調整 DAG 中的所有信箱伺服器，以處理排定或未排定中斷期間的必要工作量。

使用 New-DatabaseAvailabilityGroup 指令程式可建立一個 DAG。DAG 一開始是在 Active Directory 中建立的空物件。目錄物件是用於儲存 DAG 的相關資訊，例如伺服器成員資格資訊。當您新增第一個伺服器到 DAG 時，就會自動為 DAG 建立容錯移轉叢集。這個容錯移轉叢集由 DAG 獨佔使用，而且必須專供 DAG 使用，不支援將此叢集用於其他任何用途。

除了建立容錯移轉叢集之外，還會初始化監視伺服器是否發生網路失敗或伺服器失敗的基礎結構，然後使用容錯移轉叢集活動訊號機制和叢集資料庫來追蹤和管理可能快速變更的 DAG 資訊，例如資料庫裝載狀態、複寫狀態和最後裝載位置。

建立期間會為每個 DAG 指定一個唯一名稱，並指派一個或多個靜態 IP 位址，或設定為使用動態主機設定通訊協定 (DHCP)。您可以使用 DatabaseAvailabilityGroupIPAddresses 參數，來指定單一 IP 位址或逗號分隔的 IP 位址清單。

此範例顯示具有三部伺服器的 DAG。其中兩部伺服器 (EX1 和 EX2) 位於同一個子網路 (10.0.0.0)，而第三部伺服器 (EX3) 位於另一個子網路 (192.168.0.0)。

New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

附註：
使用 0.0.0.0 的值來設定 DatabaseAvailabilityGroupIPAddresses 參數時，可以將 DAG (叢集) 設為使用 DHCP 來取得 IP 位址或 IP 位址資源。

將 EX1 新增至 DAG 時，會建立 DAG1 的叢集。在叢集建立期間，Add-DatabaseAvailabilityGroupServer 指令程式會擷取為 DAG 設定的 IP 位址，並忽略在 EX1 上發現但不符合任何子網路的位址。在此範例中，會以 10.0.0.5 的 IP 位址來建立 DAG1 叢集，並忽略 192.168.0.5 的 IP 位址。

接著新增 EX2，並由 Add-DatabaseAvailabilityGroupServer 指令程式再次擷取為 DAG 設定的 IP 位址。由於 EX2 與 EX1 皆位於相同的子網路上，因此叢集的 IP 位址不會有任何變更。

接著再新增 EX3，而 Add-DatabaseAvailabilityGroupServer 指令程式也會再次擷取為 DAG 設定的 IP 位址。由於 EX3 上有符合 192.168.0.5 的子網路，因此會將 192.168.0.5 位址當成 IP 位址資源新增至叢集群組。此外，還會針對每個 IP 位址資源自動設定網路名稱資源的 OR 相依性。當叢集群組移至 EX3 時，叢集就會使用 192.168.0.5 的位址。

當網路名稱資源連線時，Windows 容錯移轉叢集會將叢集的 IP 位址註冊到網域名稱系統 (DNS)。此外，會在 Active Directory 中建立叢集名稱物件 (CNO)。系統會以保護 DAG 和內部通訊的用途，在內部使用叢集的名稱、IP 位址和 CNO。系統管理員和使用者不需要處理或連線到 DAG 名稱或 IP 位址 (不論原因為何)。

除了名稱與一或多個 IP 位址之外，還可將 DAG 設為使用見證伺服器與見證目錄。見證伺服器與見證目錄可由系統自動指定，或是由系統管理員手動指定。

根據預設，DAG 主要是使用內建的連續複寫功能，在 DAG 中的伺服器之間複寫信箱資料庫。如果您所使用的協力廠商資料複寫功能支援在 Exchange 2010 中的協力廠商複寫 API，您必須使用 New-DatabaseAvailabilityGroup 指令程式並搭配 ThirdPartyReplication 參數，在協力廠商複寫模式中建立 DAG。此模式一經啟用，就不能停用。

DAG 建立完畢後，就可以將信箱伺服器新增至 DAG。新增第一台伺服器至 DAG 時，會形成叢集以供 DAG 使用。多個 DAG 可以在有限範圍內使用 Windows 容錯移轉叢集技術，例如叢集活動訊號、叢集網路與叢集資料庫 (用於儲存變更的資料，例如資料庫從主動到被動的狀態變更，或是從裝載到卸載的狀態變更，皆反之亦然)。隨著其他伺服器陸續新增至 DAG，這些伺服器每一台都會加入基礎叢集，系統會自動調整叢集的仲裁模型，並新增至 Active Directory 中的 DAG 物件中。

在將信箱伺服器新增到 DAG 之後，您可以設定各種 DAG 的內容，例如是否在 DAG 內的資料庫複寫作業中使用網路加密或網路壓縮。您也可以設定 DAG 網路，並建立額外的 DAG 網路。

將成員新增至 DAG 並設定好 DAG 之後，每一台伺服器上的主動信箱資料庫，就可以複寫到其他 DAG 成員上。建立好信箱資料庫副本之後，您可以使用各種內建的監視工具，來監視副本的健康狀況與狀態。此外，您也可以執行資料庫與伺服器轉換。

如需建立 DAG、管理 DAG 成員資格、設定 DAG 內容、建立與監視信箱資料庫副本，以及執行轉換等相關資訊，請參閱管理高可用性及站台恢復。

資料庫可用性群組仲裁模型

每個 DAG 之下都有一個 Windows 容錯移轉叢集。容錯移轉叢集使用仲裁的概念，其使用投票人的合意以確保一次僅有一子集的叢集成員 (可指所有成員或多數成員) 在作用中。仲裁並不是 Exchange 2010 的新概念。舊版 Exchange 中高可用性的信箱伺服器也會使用容錯移轉叢集和它的仲裁概念。仲裁代表成員共同的觀點與資源，而仲裁一詞也用於說明代表叢集之間的組態之實體資料，此為所有叢集成員之間所共有。因此，所有 DAG 皆要求其基礎容錯移轉叢集具有仲裁。如果叢集失去了仲裁，所有 DAG 作業會終止，所有已安裝且由 DAG 主控的資料庫將會卸載。在此情況下，將需要系統管理員介入，以修正仲裁問題與恢復 DAG 作業。

對於確保一致性、作為避免分割的平局決勝者，以及確保叢集回應能力來說，仲裁都是非常重要的概念：

• 確保一致性   Windows 容錯移轉叢集的主要需求是每個成員的叢集檢視一定要與其他成員的叢集檢視一致。叢集登錄區是所有與叢集相關之組態資訊的最終存放庫。如果叢集登錄區無法在 DAG 成員上從本機載入，叢集服務就不會啟動，因為無法保證該成員符合具有與其他成員一致之叢集檢視的需求。

• 作為平局決勝者   在DAG 中，仲裁見證資源會搭配偶數數量的成員一起使用，以避免核心分裂的狀況，並確保 DAG 中只有一個成員集合會被視為正式集合。當仲裁需要見證伺服器時，任何能夠與見證伺服器通訊的 DAG 成員都可以對見證伺服器的 witness.log 檔案加上伺服器訊息區塊 (SMB) 鎖定。鎖定見證伺服器的 DAG 成員 (稱為*「鎖定節點」*) 會保留額外一票供仲裁使用。與鎖定節點連絡的 DAG 成員屬於多數且會維護仲裁。無法連絡鎖定節點的任何 DAG 成員則屬於少數，因此會遺失仲裁。

• 確保回應能力   為了確保回應能力，仲裁會確定每當叢集執行時，都有足夠的分散式系統成員能夠正常運作及通訊，而且能夠保證叢集目前的狀態至少有一個複本。您不需要花費任何額外的時間讓成員開始通訊，或者判斷特定的複本是否一定存在。

具有複數成員的 DAG 會使用容錯移轉叢集的「節點與檔案共用多數」仲裁模式，而這個模式會運用外部見證伺服器作為平局決勝者。在這種仲裁模式中，每個 DAG 成員都會獲得一票。此外，會使用見證伺服器提供一個 DAG 成員加權過的選票 (例如，取得兩票而非一票)。依預設，叢集仲裁資料會儲存在 DAG 每個成員的系統磁碟上，而且在這些磁碟之間保持一致。不過，仲裁資料的副本不會儲存在見證伺服器上。見證伺服器中的檔案會用於追蹤具有最新資料副本的成員，但見證伺服器並不會具有叢集仲裁資料的副本。在這種模式下，多數的投票者 (DAG 成員加上見證伺服器) 必須運作正常且能夠彼此通訊，才能維護仲裁。如果多數投票者無法彼此通訊，DAG 的基礎叢集會遺失仲裁，而且 DAG 必須讓系統管理員介入恢復運作。

具有奇數成員的 DAG 會使用容錯移轉叢集的「節點多數」仲裁模式。在這個模式下，每個成員都會取得一票，而且每個成員的本機系統磁碟都可用來儲存叢集仲裁資料。如果 DAG 的組態有所變更，則該變更會反映到不同的磁碟上。只有在對半數 (向下捨去) 再加一個成員的磁碟進行變更後，才會將該項變更視為已認可且成為持續性。例如，在有五個成員的 DAG 中，必須在二加一個成員 (也就是總共三個成員) 上進行變更。

仲裁要求多數投票者必須能夠彼此通訊。假設某個 DAG 擁有四個成員。因為這個 DAG 具有偶數的成員，所以它會使用外部見證伺服器來提供一名叢集成員第五票，也就是平局決勝的一票。為了維持多數投票者 (並因而達成仲裁)，至少要有三個投票者必須能夠彼此通訊。不論任何時候，最多可以有兩個投票者離線，而不致於造成服務和資料存取中斷。如果有三個或更多投票者離線，DAG 便會遺失仲裁，而且直到您解決問題之前，服務和資料的存取都會中斷。

回到頁首

使用資料庫可用性群組以獲取高可用性

為方便說明 DAG 如何為您的信箱資料庫提供高可用性，我們假設下例範例使用含五台成員的 DAG。DAG 如下圖所示。

具有五個成員的 DAG

在上圖中，綠色資料庫是主動信箱資料庫副本，而藍色資料庫則是被動信箱資料庫副本。在本範例中，資料庫副本不會鏡射到每一台伺服器上，而是平均分佈到多台伺服器上。此舉可確保 DAG 中沒有兩台伺服器擁有相同的資料庫副本集合，因此可以提供給 DAG 更大的失敗恢復，包括當其他元件因為正常維護作業而無法使用的失敗情況。

假設下列案例中使用以上範例 DAG，來說明多台資料庫與伺服器失敗的回復性。

一開始，所有資料庫和伺服器都很健全。您需要在 EX2 上安裝一些作業系統更新。您執行伺服器轉換作業，進而啟動另一台信箱伺服器上的 DB4 副本。伺服器轉換會將所有的主動信箱資料庫副本從目前的伺服器移到 DAG 中一或多部其他信箱伺服器，以因應目前伺服器的排定中斷狀況。可以在 Exchange 管理命令介面中執行下列命令，來快速執行伺服器轉換作業。

Move-ActiveMailboxDatabase -Server EX2

在本範例中，EX2 (DB4) 上只有一台主動信箱伺服器，因此只能移動一個主動信箱資料庫副本。藉由在先前命令中省略 ActivateOnServer 參數，選擇讓系統儘可能選取最新的主動副本，而系統則是選擇 EX5 上的副本，如下圖所示。

伺服器離線進行維護的 DAG

當您在 EX2 上執行維護作業時，EX3 會因災難性的硬體失敗而離線。要離線之前，EX3 會裝載 DB2 的主動副本。為了從失敗中復原，系統會自動於 30 秒內啟動裝載在 EX1 上的 DB2 副本。如下圖所示。

伺服器離線進行維護和失敗伺服器的 DAG

當 EX2 完成排定的維護作業之後，您就可以讓伺服器上線。一旦 EX2 可用，其他 DAG 成員伺服器會收到通知，並自動將裝載在 EX2 上的 DB1、DB4 與 DB5 副本，與每一個資料庫上的主動副本同步處理。如下圖所示。

DAG，具有正在同步其資料庫副本的已還原伺服器

當您以新的元件來更換 EX3 中失敗的硬體元件之後，就可以讓 EX3 上線。在 EX3 可以使用之後，其他 DAG 成員伺服器會收到通知，並自動讓 EX3 上主控的 DB2、DB3 和 DB4 副本，與每一個資料庫上的主動副本保持同步。如下圖所示。

DAG，具有正在同步其資料庫副本的已修復伺服器

回到頁首

使用資料庫可用性群組來取得站台回復性

除了在資料中心裡提供高可用性之外，DAG 還可以延伸至一或多個資料中心，並透過組態為一或多個資料中心提供站台回復性。在先前的範例圖表中，DAG 位於單一資料中心與單一 Active Directory 站台。您可以使用增量部署將此 DAG 延伸至次要資料中心 (以及次要 Active Directory 站台)，方法是部署信箱伺服器與必要的支援資源 (亦即，一或多台 Active Directory 伺服器，以及一台或多台集線傳輸伺服器與用戶端存取伺服器)。之後將信箱伺服器新增至 DAG，如下圖所示。

遍佈兩個 Active Directory 站台的 DAG

在本範例中，Redmond 資料中心裡的每一個主動資料庫，會在 Dublin 資料中心裡的 EX6 上設定一個被動副本。不過，還有其他許多 DAG 組態範例可提供站台回復性。例如：

• EX6 可以主控所有主動副本，或是混合主控主動與被動副本，而不是只主控被動資料庫副本。

• 除了 EX6 之外，還可以將多個 DAG 成員部署在 Dublin 資料中心裡，以提供避免其他錯誤的保護。這個組態也提供額外的容量，因此如果 Redmond 資料中心發生錯誤，Dublin 資料中心便可支援更大量的使用者人數。

使用多個資料庫可用性群組來取得站台失敗恢復

在上面的範例中，單一 DAG 遍佈多個資料中心，以便為其中一個或兩個資料中心提供站台回復性。在您將 DAG 延伸至其上的每個資料中心都有使用中使用者人數的環境中，使用單一 DAG 提供站台回復性時，廣域網路 (WAN) 連線中會有單一失敗點。這是因為仲裁要求多數投票者必須正在作用，而且能夠彼此通訊。

在前面的範例中，多數投票者是位於 Redmond 資料中心裡。如果 Dublin 資料中心主控了主動信箱資料庫，而且具有本機使用者人數，WAN 中斷將會造成 Dublin 使用者的訊息服務中斷。當 WAN 連線中斷時，只有 Redmond 資料中心的 DAG 成員會保留仲裁並繼續提供訊息服務。

在您需要提供站台回復性給多個資料中心，而每個資料中心都有使用中的使用者人數時，若要避免 WAN 變成單一失敗點，您應該部署多個 DAG，讓每個 DAG 在個別的資料中心裡都有多數投票者。當發生 WAN 中斷狀況時，將會封鎖複寫功能，直到還原連線為止。使用者將會有訊息服務，因為每個 DAG 都會繼續為其本機使用者人數提供服務。

回到頁首

使用資料庫可用性群組的用戶端體驗

DAG 可以用來提供高可用性和站台回復性。使用 DAG 時的用戶端體驗取決於用戶端的類型和版本，以及用戶端用來存取信箱資料的通訊協定。例如，如果發生跨站台資料庫容錯移轉，POP3 或 IMAP4 用戶端使用的行為和重新連線邏輯，與 Microsoft Outlook 2010 用戶端使用的行為和重新連線邏輯就會不同。

下列章節說明各種案例中的用戶端行為與邏輯。其中說明的行為假設：

• 此環境在每個 Active Directory 站台中都含有單一 Client Access Server 陣列，而且每個站台包含至少兩部 Client Access Server。

• 已在 Client Access Server 之前安裝及設定適當的硬體型或軟體型負載平衡器。

• 已完成適當的命名空間和憑證規劃與組態，包括必要的 DNS 記錄。

Microsoft Outlook 的行為和邏輯

一般來說，對於單一資料中心和單一 Outlook 站台內發生的資料庫容錯移轉，所有的 Active Directory 版本都會出現相同的行為。與舊版 Exchange 不同，在 Exchange 2010 中，Outlook 已經不會直接連線到信箱伺服器上的 Exchange 儲存區。相反地，Outlook (和其他任何 MAPI 用戶端) 會連線到 Client Access server role 上的 RPC 用戶端存取服務和通訊錄服務，而且使用者的 Outlook 會設定為連線到 Client Access Server 陣列，然後再由後者將用戶端連線到個別的 Client Access Server。這種將 Outlook 連線抽離信箱伺服器的作法具有下列優點：

• 發生資料庫容錯移轉時，Outlook 可與 Client Access Server 陣列中的同一部伺服器保持連線。發生這種情況時，在 Client Access Server 上執行的 Active Manager 用戶端能夠分辨哪一個 DAG 成員會主控來自 DAG 之 Active Manager 的主動資料庫副本。接著，Client Access Server 會連線到該信箱伺服器，而且 Outlook 也會指出它已連線到 Exchange 伺服器。

• 如果 Client Access Server 陣列的其中一個 Client Access Server 因為排定或未排定的中斷狀況而無法使用，該陣列中的其餘 Client Access Server 便會處理用戶端負載。由於 Outlook 是設定為連線至 Client Access Server 陣列，而非個別的 Client Access Server，因此 Client Access Server 陣列成員可能會個別發生錯誤或以手動方式離線，而不會影響使用者的 Outlook 設定檔。此作業可以自動執行 (例如，根據陣列前面的負載平衡器所執行的監視功能，自動重新設定陣列)，或者您也可以手動執行此作業。

對於在兩個資料中心和兩個 Outlook 站台之間發生的資料中心轉換，所有的 Active Directory 也都會表現出相同的行為。資料中心轉換包括將用戶端存取命名空間 (例如 Microsoft Office Outlook Web App、SMTP、POP3、IMAP4、自動探索、Exchange Web 服務或 RPC 用戶端存取) 使用的 IP 位址，從主要資料中心裡的 IP 位址變更成次要資料中心裡的 IP 位址。因此，使用者的 Outlook 設定檔中所使用的命名空間不會變更，而且自動探索會繼續將用戶端指向同一個 Client Access Server 陣列命名空間。

Outlook 在跨站台資料庫容錯移轉之後的行為，與它在單一 Active Directory 站台資料庫容錯移轉或是資料中心轉換之後的行為不同。

Outlook 版本的行為範例

下列範例說明 Outlook 2010、Office Outlook 2007 和 Office Outlook 2003 在發生跨站台資料庫容錯移轉之後的行為。每個範例中所使用的拓撲都是含四個成員的 DAG 延伸到兩個 Active Directory 站台：Redmond 和 Portland。使用者的信箱是由 DB1 主控，而 DB 1 則會複寫到每部伺服器上。在每個範例中，DB1 的主動副本都會從 MBX2 容錯移轉到 MBX3。

示範 Outlook 在跨站台資料庫容錯移轉後之行為的拓撲範例

每個用戶端都將 CAS1 設為其主伺服器，而讓 Redmond 變成*「Outlook 設定檔站台」。由於用戶端位於 Redmond，因此 DB1 的 RPCClientAccessServer 內容是設定為 CAS1，讓 Redmond 成為「優先的資料庫站台」。因為 DB1 在 MBX2 上已失效，並在 MBX3 變成作用中狀態，所以 Portland 是「裝載資料庫站台」*。

Outlook 2010 和 Outlook 2007 的範例

如果 Redmond 站台有可用的 Client Access Server，則 Outlook 2010 和 Outlook 2007 會繼續連線到 Redmond 站台中的 RPC 用戶端存取陣列。用戶端所用的用戶端存取伺服器，將會使用 MAPI RPC 與 Portland 站台中使用者的信箱伺服器進行通訊。

如果 Redmond 站台中沒有可用的 Client Access Server，則必須執行從 Redmond 到 Portland 的資料中心轉換，以便還原對服務和資料的存取。如需執行資料中心轉換的詳細步驟，請參閱執行伺服器轉換。

Outlook 2003 的範例

當 Outlook 2003 嘗試連線到 CAS1 時，它也會在回應中收到 ecWrongServer 訊息。但與 Outlook 2010 和 Outlook 2007 不同的是，Outlook 2003 並未包含自動探索功能，因此必須使用其他方法來更新使用者的設定檔。Outlook 2003 所採用的機制是 MAPI 設定檔重新導向。MAPI 設定檔重新導向要求原始的來源伺服器必須為連線狀態。如果 CAS1 無法使用，而且如果陣列中的其他所有 Client Access Server 也無法使用 (或是陣列中只包含 CAS1)，Outlook 2003 便無法以不需手動介入的方式執行 MAPI 重新導向或連線到使用者的信箱資料庫。

使用公用資料夾時 Outlook 的行為和邏輯

雖然隸屬 DAG 成員的信箱伺服器可以主控公用資料夾資料庫，但是公用資料夾資料庫並不會使用連續複寫，而且需依賴公用資料夾複寫來提供高可用性。Outlook 用戶端在信箱資料庫容錯移轉之後重新連線到公用資料夾資料庫的行為，不只需視失敗的性質而定，也需取決於您的公用資料夾複寫組態設定，以及公用資料夾資料庫的健康狀況和流通狀態。因為連續複寫不適用於公用資料夾資料庫，所以公用資料夾資料庫的高可用性，需透過部署多個公用資料夾資料庫並將它們設定為彼此複寫的方式來達成。我們建議您設定每個資料夾的多個複本。

非 Outlook 用戶端的行為和邏輯

一般來說，Outlook 和 MAPI 以外之用戶端和通訊協定的行為會隨著使用的應用程式以及失敗案例而改變。和 Outlook 一樣，對於單一資料中心和單一 Exchange 站台內發生的資料庫容錯移轉，一般的 Outlook Web App 應用程式和用戶端 (例如 Exchange ActiveSync、Microsoft Exchange、POP3、IMAP4 和 Active Directory Web 服務) 通常都會表現出現同的行為。同樣地，上述所有用戶端和通訊協定 (包括 SMTP 和 Windows PowerShell) 在轉換之後也全都會表現出與 Outlook 相同的行為。

如果發生跨站台資料庫容錯移轉，這些用戶端和通訊協定則會表現出不同的行為。下表列出這些用戶端的行為。

一般 Exchange 用戶端的跨站台資料庫容錯移轉行為

用戶端或通訊協定	行為
Outlook Web App	手動重新導向。在這個案例中，用戶端命名空間會從 http://mailred.contoso.com 變更為 http://mailpdx.contoso.com。在使用者輸入登入認證之後，便會透過手動重新導向頁面將使用者重新導向至 Portland 站台中的 CAS2，而且手動重新導向頁面中會說明使用的 URL 不正確，正確的 URL 是 https://mailpdx.contoso.com/owa。
Exchange ActiveSync	Proxy 或重新導向。在這個案例中，用戶端行為是由用戶端裝置上 Exchange ActiveSync 通訊協定的實作方式和版本來決定。
POP3 及 IMAP4	代理。這個案例一定會牽涉到 Client Access Server 對 Client Access Server 的代理。
Exchange Web 服務	使用自動探索來決定新的連線端點。

回到頁首

 © 2010 Microsoft Corporation. 著作權所有，並保留一切權利。