次の方法で共有

CAS 陣列物件大解謎 - 第 1 部分

  • [アーティクル]

英文原文已於 2012 年 3 月 24 日星期六發佈

Exchange 2010 自從 2009 年上市以來，迴響始終十分熱烈。在教育並協助客戶移轉至 Exchange 2010 的過程中，我們發現了幾個常見的錯誤觀念。其中一個現象是有關於「Client Access Server 陣列物件」(簡稱 CAS 陣列物件) 的誤解。當我在一場 Microsoft 內部發佈小組會議上提到這個現象時，技術文件撰寫員兼部落格寫手 Scott Schnoll (可能為英文網頁) 建議我動筆 (或應該說是敲鍵盤吧) 寫一篇文章加以說明，也就是這篇貼文的起源。

我不打算在這裡討論 CAS 陣列物件的所有技術層面。因為 Nagesh Magadev 先前的貼文中已有十分精彩的說明：探索 Exchange 2010 RPC 用戶端存取服務 (可能為英文網頁)。

以下列出一些關於 CAS 陣列物件的事實，是許多客戶所不甚清楚的，也是我將為各位釋疑的重點。第 1 部分討論前三項，後三項則會在第 2 部分說明。

  1. CAS 陣列物件不會使您的流量達到負載平衡
  2. CAS 陣列物件不會服務 Autodiscover、OWA、ECP、EWS、IMAP、POP 或 SMTP
  3. CAS 陣列物件的 FQDN 不需要包含在您的 SSL 憑證中
  4. CAS 陣列物件不可由外部用戶端解析 (透過 DNS)
  5. CAS 陣列物件不應在建立 Exchange 2010 信箱資料庫和將信箱移入資料庫後才進行設定或變更
  6. 即使您只有一個 CAS 或單一個多角色伺服器，也應為 CAS 陣列物件進行設定

聽得一頭霧水嗎？很好。現在就讓我一一為各位解惑。在這篇文章中將會出現一些伺服器名稱，我就先給您們看看我實驗室的環境吧。

名稱 伺服器角色 管理員顯示版本
E2K10-MLT-01 Mailbox、ClientAccess、HubTransport 版本 14.2 (建置 247.5)
E2K10-MLT-02 Mailbox、ClientAccess、HubTransport 版本 14.2 (建置 247.5)
E2K7-MLT-02 Mailbox、ClientAccess、HubTransport 版本 8.3 (建置 83.6)
E2003-BE 無 版本 6.5 (建置 7638.2：Service Pack 2)

好的，開始吧！

1. CAS 陣列物件不會平衡負載您的流量

CAS 陣列物件不會進行負載平衡。它是一個 Active Directory 物件，可用以自動化某些 Exchange 中的功能，但是僅止於此而已。Exchange 2010 說明文件到處都建議您使用負載平衡 (LB) 來平衡 CAS 的流量。所以我說 CAS 陣列物件沒辦法負載平衡又是什麼意思呢？

負載平衡器真正的功用是平衡通過 CAS 集區 (或許您可以稱它為 CAS 的陣列) 之流量，而不是 CAS 陣列物件本身的流量。兩者的分別雖然微妙，卻有明顯的差異。也許我們一開始取的名稱不夠明確，太容易害大家混淆了。

CAS 陣列物件之所以存在最重要的原因也或許是唯一的原因，就是為了負責自動填寫任何與 CAS 陣列物件在同一個 Active Directory 網站中新建立之 Exchange 2010 信箱資料庫的 RpcClientAccessServer 屬性。

RpcClientAccessServer 屬性則是用以在設定檔建立期間告訴 Outlook 用戶端，設定檔內的伺服器名稱應是哪一個。但差不多也就是如此而已，沒有什麼神奇的功能。一旦您建立好 CAS 陣列物件之後，它就僅僅是 Active Directory 中的物件而已，也不會有任何負載平衡在此階段進行。

接下來要做的事全由您自行決定。您可以選擇：

  • 在 DNS 中建立一筆 ‘A’ 記錄，讓用戶端機器得以解析 IP 位址的主機名稱。此 IP 位址最有可能會是僅供內部用戶端連結的 LB 的虛擬 IP (VIP)。此 VIP 就是 Outlook 或任何其他具有 MAPI/RPC 功能的應用程式將會連接以取得 Exchange 2010 信箱資源存取權的位址。
  • 設定您的負載平衡解決方案，以透過 VIP 途徑傳遞流量至 CAS 伺服器集區。

CAS 本身並不知道有任何負載平衡正在進行中。

您也可能不太清楚，當使用 New-ClientAccessArray Cmdlet 建立好 CAS 陣列物件後，或使用 Get-ClientAccessArray Cmdlet 查看既有的 CAS 陣列物件時，能看到些什麼。

這裡我要在我的實驗室中新建一個名為 CASArray-A 的 CAS 陣列物件，它的 FQDN 是 outlook.lab.local，而 Active Directory 網站我就簡單命名為 Site-A。


圖 1：建立 Client Access 陣列

首先，我的 [FQDN] 及 [名稱] 欄位並不相同，因為 [名稱] 只不過是顯示名稱而已，純粹好看。您想取什麼名字都可以，只要能讓您知道那個 CAS 陣列物件是用來做什麼的就行。FQDN 就是您接著必須在 DNS 中建立的記錄，否則用戶端將永遠無法將其解析為要連接的 IP 位址。此時我必須提醒您，一個 Active Directory 網站最多只能有一個 CAS 陣列物件。

那麼為什麼建立完成之後，成員屬性立即出現了兩個 CAS 呢？我不是剛剛才說過這個階段不會有任何負載平衡嗎？難道我在唬您嗎？

老實說，成員屬性是一個會害人誤解的玩意。假設您建立 CAS 陣列物件時沒有一邊對照說明步驟，您可能會以為這樣就弄完了。您會看到 CAS 陣列物件已經建立好，兩個 CAS 也自動加入陣列了。就在您可能想說大功告成，該下樓去喝一杯，或是跑去偷吃一些這位仁兄 (可能為英文網頁) 的餅乾時，快請留步啊，朋友！

由於我們有將 CAS 陣列物件關聯到 Active Directory 網站 Site-A，Cmdlet 只不過是直接去找出所有登錄為位於 Site-A 中的用戶端伺服器，然後將其列於 [成員] 欄而已。我會建議客戶將這一欄想成是「潛在成員欄」，或如 Kamal Abburi (Microsoft 的另一位 PFE) 所建議的，將它看做是「網站 CAS 成員欄」。您可在您的負載平衡解決方案中增加這些用戶端存取伺服器做為節點，因為它們全都位於同一個 Active Directory 網站內。但直到負載平衡設定完成前，我們都還沒有任何負載平衡。

Cmdlet 怎麼知道 CAS 在哪個網站內呢？很高興您們問了，我這就請出大家最好的朋友 AdsiEdit.msc 來深入剖析 Active Directory 的設定部分，找出它的魔力所在。


圖 2：Exchange 2010 伺服器的 msExchServerSite 屬性中包含有該伺服器所在的 Active Directory 網站

每個 Exchange 伺服器都有一個 msExchServerSite 屬性，其中包含它們目前所在的 Active Directory 網站。我知道您在想什麼，沒錯，它會動態更新。只要您將 Exchange 伺服器移到新的網站時，Microsoft Exchange Active Directory 拓撲服務就有機會執行並更新一些內容。但是 AutoDiscoverSiteScope 屬性 (Get/Set-ClientAccessServer 的一部分) 將不會自動更新。視您網站、伺服器與用戶端格局之不同，在此問題解決之前，Autodiscover 都有可能會傳回一些亂七八糟的結果。

2. CAS 陣列物件不會服務 OWA、ECP、EWS、自動探索、IMAP、SMTP 或 POP

讓我們再回頭看一下 CAS 陣列物件真正的用途。它負責填寫 Exchange 2010 信箱資料庫的 RpcClientAccessServer 屬性，該屬性隨後將用以告知 Outlook：當使用 RPC (over TCP) 時，應該要連線到何處。對於「Outlook 無所不在」(HTTPS) 用戶端，它會指出從 RPC-over-HTTP 的 Proxy 傳出的流量應替用戶端連線到哪裡，才能連到他們的信箱。

那麼當使用 RPC (over TCP) 時，Outlook 用戶端會嘗試連接什麼服務呢？

首先 Outlook 會連接至 TCP/135 上的 CAS 陣列物件，以便與「RPC 端點對應程式」通訊，找出下列兩項服務正在接聽的 TCP 連接埠。

  1. Microsoft Exchange RPC 用戶端存取 (又稱為 MSExchangeRPC)
  2. Microsoft Exchange 通訊錄 (又稱為 MSExchangeAB)

RPC (over TCP) 模式說完了！

瞭解 Outlook 無所不在 (又稱為使用 RPC over HTTP 從 Outlook 用戶端存取 Exchange 的詳細技術資料) 用戶端會藉著解析「Outlook 無所不在」的外部主機名稱，或 Outlook 設定檔中 Proxy 伺服器的名稱，連接到 CAS 在 TCP/443 上的 RPC-over-HTTP Proxy 元件。

如果您也自認是電腦達人的話，有一點您可能會感興趣，那就是 Outlook 會悄悄地自動將 /rpc/rpcproxy.dll 加到指定的伺服器名稱，那也就是它真正必須連接的目標，但是如果我們要求大家輸入這些名稱，就像 Outlook 2003 的年代那樣，您能想像有多少人會打錯嗎？


圖 3：在 Outlook 2003 中指定 RPC Proxy URL

RPC-over-HTTP Proxy 傳出的流量會路由到合適的 MAPI/RPC 端點，利用幾個固定而非動態指派的 TCP 連接埠：也就是 TCP 6001、TCP 6002 和 TCP 6004。「Outlook 無所不在」的外部主機名稱刻意取成和 CAS 陣列物件的 FQDN 不同，我稍後會解釋為什麼。

用戶端也可能以 HTTPS 連線到自動探索、OAB 下載、EWS、POP 或 IMAP 等服務，但這些服務皆是由完全不同的方法所定義，例如虛擬目錄 URL 或 AutoDiscoverServiceInternalUri 值等等。這些額外服務沒有一個受 CAS 陣列物件所服務，因為它們都沒有用到 RPC，雖然也可能就是它們所連接的同一部伺服器。CAS 陣列物件的 FQDN 可以和其他服務的 URL 共用相同的 VIP，但我們強烈建議如果使用分割的 DNS 的話，CAS 陣列物件 FQDN 就不要設成和其他服務的 URL 一樣。有關最後這點我待會還會再深入解釋。

3. CAS 陣列物件的 FQDN 不需要包含在 SSL 憑證名稱清單中

這是一個很常見的誤解，原因就來自上面那一點。SSL 憑證在這篇文章中只有在我們想要從事一些特別的動作 (比方說建立一個有 SSL 保護的 HTTP 工作階段時) 才會用到。因為 RPC (over TCP) 並不是 HTTP 工作階段，所以它將不會受到 SSL 保護，因此我們不需要在 SSL 憑證的主旨名稱中包含 CAS 陣列物件的 FQDN。讓我們來看看。

下面是 Outlook 2010 於 MAPI/RPC 模式下連接到 Exchange 2010 CAS 陣列物件的樣子。


圖 4：Outlook 2010 RPC (over TCP) 連接到 Exchange 2010 CAS

我們可以看到它已經建立了一個目錄和兩個郵件連線。在 netstat 輸出的結果中 (螢幕擷取畫面標出的部分) 我們看到機器已建立了一個連到 CAS 陣列物件的端點對應程式連線 (TCP 135)，以及連到 TCP 59531 與 TCP 59532 的連線。它們也就是本實驗室分別固定指派給 MSExchangRPC 和 MSExchangeAB 服務的 TCP 連接埠。

在伺服器這一端，我們可以使用 netstat –n –b 命令，查看正在接聽的服務。


圖 5：使用 RPC (over TCP) 時 Outlook 必須連接的服務

和我預期的一樣，它會顯示出目前沒有任何服務透過 HTTP (至 TCP 443) 連線。這就是為什麼您不需要在 SSL 憑證上包含 CAS 陣列物件 FQDN。

Outlook 在 HTTPS 模式下顯示連線的方式，有時可能會讓您以為必須在 SSL 憑證上包含 CAS 陣列物件 FQDN，如下所示。


圖 6：Outlook 無所不在連線

這回我們從螢幕擷取畫面看到 Outlook 2010 已建立了兩個郵件連線，以及一個 [公用資料夾] 連線，也看到我們正在使用 HTTPS。從 Outlook 內看起來，我們像是正連線到 outlook.lab.local 和 E2K10-MLT-01.lab.local (部分來說是)，但再用 netstat 看看後發現，我們實際上是連到在 TCP/443 (HTTPS) 上位於 webmail.lab.local 的 RPC-over-HTTP Proxy。Outlook 永遠都會顯示最終連到的伺服器，無論是透過資料本身或著透過 RPC-over-HTTP Proxy。您若覺得奇怪為什麼用 netstat 看到的連線是 6 個而不是 3 個，那是因為 HTTP 是一種半雙工通訊協定，所以我們會為 Outlook 中見到的每個連線建立一個 RPC_DATA_IN 與 RPC_DATA_OUT 通道。

您會想說：「等等，Outlook 2007 和 2010 預設不就是會加密 RPC 工作階段嗎？憑證上還是要寫有名稱的！」錯了，朋友，因為下面看到的加密設定採用的是 RPC 加密法，和 SSL 一點關係也沒有。通訊仍然透過 RPC 而不是透過 HTTPS 進行。


圖 7：使用 RPC (over TCP) 進行連線時，Outlook 會採用 RPC 加密法

簡單吧！當 CAS 陣列物件遇上憑證授權單位 (CA) 時，假如 CA 說：「兄弟，您需要我！來吧，我便宜賣您一張超棒的萬用憑證！」CAS 陣列物作只會回答：「老子不吃這一套！」然後可能再海扁 CA 一頓。當然您必須照我的建議做，將其他服務 FQDN 設成和您現在用的 CAS 陣列物件不同的 FQDN，才能有這樣的結果囉。是滴，我就要說到原因了…

希望本文章的第 1 部分到目前為止有替您釐清一些 CAS 陣列物件常見的誤解，也請繼續收看第 2 部分，我們將會繼續討論剩下的三種 CAS 陣列物件常見的錯誤認知。

Brian Day
首席實務工程師，訊息部門

這是翻譯後的部落格文章。英文原文請參閱 Demystifying the CAS Array Object - Part 1