Share via


從某群組移轉到另一個群組時,更新並不一定會自動進行,也不一定是您所要的。

亨裡克 · 瓦爾特

交流 2010 年和超 V

**Q。**我們打算部署 Exchange 伺服器 2010年。 公司政策規定所有新的伺服器必須是在 HYPER-V 下運行的虛擬機器 (Vm)。 為了提高應用程式和服務的可用性,所有的 Hyper-V 根伺服器都會加入 Hyper-V 容錯移轉群集。

我們最近看到了這篇博客文章宣佈增強的硬體虛擬化支援 Exchange 2010 年的 Microsoft Exchange 團隊博客上。 我們尤其是發現以下語句有趣的事情:

"結合管理程式基於聚類、 高可用性,或將移動的遷移解決方案或自動容錯移轉郵箱伺服器屬於山聚集的根伺服器之間交換 2010年高可用性解決方案 (資料庫可用性組 [DAGs]),現在支援。"

這對於我們來說是個好消息,因為這意味著我們現在可以在 Hyper-V 容錯移轉群集中部署以 VM 形式加入 DAG 的 Exchange 2010 郵箱伺服器。 在執行此操作時有沒有其他事項需要注意?

**A.**你當然好定時交換 2010年部署。 您肯定認為 Microsoft 現在支援將 DAG 與基於主機的容錯移轉群集和遷移技術相結合。 這不僅適用于 Hyper-V,還適用于參與Windows Server 虛擬化驗證計畫 (SVVP) 的任何硬體虛擬化供應商。

不過,如果您打算即時遷移 DAG 成員,那麼有一些要點需要記住。 為了獲得此支援,您需要安裝 Exchange 2010 SP1 或更高版本。 另外,強烈建議您使用群集共用卷,而不是使用傳遞磁片。 當 Exchange 產品組和 Hyper-V 團隊對各種方法進行了測試後,他們發現通過使用群集共用卷,與移動存儲資源相關聯的離線時間縮短了一半。

如果伺服器離線時間超過五秒鐘,DAG 節點就會被逐出群集。 因此,請務必確保 Hyper-V 容錯移轉群集可以在五秒鐘內完成資源遷移。 如果它無法做到這一點,請將群集檢測信號超時時間調整為更高的值。 但不能將它設置得高於 10 秒鐘。

還應確保已經向 Hyper-V 主機伺服器應用了與 Hyper-V 相關的最新修補程式。 無論即時遷移網路如何,都應確保啟用極大幀且涉及到的開關均支援極大幀。 它還建議您更改為 8192 個每個 HYPER-V 主機上的接收緩衝區。 此外,應盡可能的即時遷移網路部署盡可能多的頻寬 (5 GB 或更高,更可取)。

請務必配置每個 VM,以便當移動或進入離線狀態時它們可以在磁片上保存和恢復狀態。 當目標節點運行 VM 時,任何容錯移轉都必須導致冷開機。 計畫內遷移過程還必須包括關機和冷開機。 受群集控制的離線操作預設情況下設置為“保存狀態”。 但它必須設置為“關機”(參見圖 1),以便在從一個 Hyper-V 節點即時遷移到另一個 Hyper-V 節點時伺服器進行冷開機。

Cluster-controlled offline action set to “Shut down.

圖 1 受群集控制的離線操作設置為關機”。

最近發佈的“利用 Windows Server 2008 R2 Hyper-V 虛擬化 Exchange Server 2010 的最佳做法”白皮書包含了大量有關使用 Hyper-V 進行 Exchange 2010 虛擬化的有用資訊。 最後一個要點是,為了體現這種新的支援觀點,TechNet 上的Exchange 2010 文檔已經更新。

註冊 FQDN

**Q。**我們已經部署了 Exchange 2010 年 1 月,共 12 用戶端訪問伺服器 (CAS) 角色。 我們使用的是主動/被動使用者分發資料中心模型。 這意味著我們有一個主資料中心和一個容錯移轉資料中心。 每個資料中心有六個 CAS 角色。 我們使用基於硬體的負載平衡器解決方案對每個資料中心內的用戶端訪問流量進行負載平衡。 我們大約有 50,000 個使用者,他們最關心的是其郵箱如何使用內部 Outlook 2007/2010 用戶端。

我們最近在 Exchange 團隊博客上看到了這篇博客文章,它建議所有客戶為內部 Outlook 用戶端啟用 Kerberos 身份驗證並解釋了原因。 由於有此建議,我們正打算為我們組織中的內部 Outlook 用戶端啟用 Kerberos 身份驗證。

雖然我們已經詳細閱讀了這篇博客文章並查閱了 TechNet 上的相關 Exchange 2010 文檔,但我們仍不太清楚何時需要將完全限定的功能變數名稱 (FQDN) 註冊為服務主要名稱 (SPN)。 自動發現 FQDN 怎樣? 我們是否也需要註冊此 FQDN?

**A.**我能理解你為什麼有點困惑的是自動發現的 FQDN。 大多數客戶都有一個通常命名為 autodiscover.(companyname).com 的 Autodiscover FQDN。 此 FQDN 針對的是用於自動創建設定檔的外部用戶端(主要是 Outlook Anywhere 和 Exchange ActiveSync 設備)。

有多項 Outlook 2007/2010 功能依賴于自動發現服務(外出時的助理程式 [OOF]、離線通訊錄 [OAB] 和統一消息 [UM])。 但內部 Outlook 2007/2010 用戶端不使用此 Autodiscover FQDN。 它們會使用內部自動發現服務的統一資源識別項 (URI) 來查找 Active Directory 中的服務連接點,該識別字預設指向 CAS FQDN(參見圖 2)。

當您使用負載平衡器解決方案在 CAS 陣列中的 CAS 之間分配用戶端流量時,您通常會將內部自動發現服務 URI 設置為指向與負載平衡器上的相應虛擬服務相關聯的虛擬 IP 位址 (VIP)。 有些客戶會使用專用 FQDN。 其他客戶則會使用用於 Outlook Web App (OWA)、Exchange 控制台 (ECP)、OAB 和 Exchange Web 服務 (EWS) 的同一個 FQDN。

FQDN for the internal Autodiscover service URI.

圖 2:內部的自動發現服務的 URI 的 FQDN。

端點更新

**Q。**我們有一個網站彈性的 Exchange 2010 解決方案與小學和故障切換資料中心。 我們最近進行了一次有計劃的資料中心轉換以驗證我們的資料中心災難恢復計畫中的步驟。 在轉換的過程中,我們注意到一些事情。 雖然將主資料中心內 CAS 陣列的 DNS 記錄更改為指向容錯移轉資料中心內的 CAS 陣列後內部 Outlook 用戶端還能很好地連接,但連接端點從未在用戶端上更新過。

當主資料中心內的 CAS 陣列不可用,而且此 CAS 陣列的 DNS 記錄更新為指向容錯移轉資料中心內的 CAS 陣列時,連接端點不會按照預期那樣也在 Outlook 用戶端中更新嗎?

**A.**您看到的是預期的行為。 在將主資料中心內 CAS 陣列的 DNS 記錄更改為指向與容錯移轉資料中心內的 CAS 陣列相關聯的 IP 位址時,將不會/應該不會更新連接埠。 但您看到自己時,只要 CAS 陣列名稱解析為可訪問的 IP 位址,Outlook 用戶端就會連接的很好。

此行為使得在進行資料中心轉換時少了很多麻煩。 您只需要關注 DNS 複製,而不需要擔心 Outlook 用戶端是否已經更新了其設定檔。

設定檔更新

**Q。**我們擁有多個的 Active Directory 網站,所有 Exchange 2010 SP1 伺服器。 每個網站有三個 CAS 角色。 為了在每個網站的三個 CAS 角色之間分配用戶端流量,我們創建了 CAS 陣列和 DAG 以提供郵箱彈性。

有時候使用者會永久地從一個物理網站轉移到另一個物理網站。 在這種情況下,我們會將該使用者的郵箱轉移到新網站中的郵箱資料庫。 由於我們從中轉移使用者郵箱的郵箱資料庫的 RPC 用戶端訪問伺服器值與目標資料庫的該值不同,所以我們希望使用者的 Outlook 設定檔得到更新以體現目標郵箱資料庫的 RPC CAS 值(參見圖 3)。

RPC Client Access Server value for a mailbox database

圖 3:RPC 用戶端訪問伺服器的郵箱資料庫的值。

我們沒有任何 Outlook 2003 用戶端,只有 2007年至 2010 年。 到目前為止,我們只已經能夠有更新的運行設定檔修復的 Outlook 設定檔。

**A.**我理解您希望 Outlook 設定檔以在跨網站移動郵箱從郵箱資料庫具有一個 RPC CA 值與另一個 RPC CA 值的目標郵箱資料庫中自動更新。 但實際上您所經歷的就是預期行為。

之所以會出現這種現象是因為源 CAS(陣列)會根據 Active Directory 屬性來決定它應該訪問哪個郵箱。 如果 Active Directory 是最新的,那麼就永遠都不會涉及到錯誤的郵箱資料庫,而且永遠都不會收到 anecWrongServer 回應(為了觸發 Outlook 設定檔更新,需要得到此回應)。 Exchange 產品組完全清楚這種現象太不好了。 但還不清楚該問題何時可以得到解決,即使可以得到解決,他們也無話可說。

雖然信任但仍需要驗證

**Q。**我們試圖建立聯邦之間我們交換 2010年組及另一人。 我好像記得,若要在兩個 Exchange 2010 組織之間建立聯合身份驗證信任關係,需要使用協力廠商憑證授權 (CA) 所提供的可信證書。 我想確認一下這是否屬實。

**A.**你可能讀這之前 Exchange 2010 SP1 已被釋放。 有了 Exchange 2010 RTM,您確實需要協力廠商 CA 所提供的可信證書才能在兩個 Exchange 2010 組織之間建立聯合身份驗證信任關係。

不過,發行了 Exchange 2010 SP1 之後事情所有改變。 有了 Exchange 2010 SP1,您可以使用自簽章憑證或由內部 PKI 頒發的證書。 實際上,“新增同盟信任”嚮導會自動創建並安裝專門用於建立聯合身份驗證信任關係的自簽章憑證(參見圖 4)。

The new self-signed certificate created by the “New Federation Trust” wizard

圖 4 由“新增同盟信任”嚮導創建的新自簽章憑證。

Henrik Walther

亨裡克 · 瓦爾特是 Microsoft 認證碩士:Exchange 2007 認證架構師和 Exchange MVP,而且擁有 15 年以上的 IT 從業經驗。 他工作作為技術設計師 Timengo 諮詢 (微軟金牌認證合作夥伴在丹麥) 和 Biblioso 公司技術作家 (基於美國的公司,專門從事管理文檔編制和當地語系化的服務)。

相關內容