Share via

慢、慢、慢...

  • Article

英文原文已於 2012年 2 月 20 日星期一發佈

您或許已經發現到，我們在前陣子發佈了 Exchange 2010 Service Pack 2 更新彙總套件 1 之後，緊接著又發佈了許多修正。我想利用這個部落格，特別談談其中一項修正，同時也對於這些問題的成因與解決方式稍加說明。

我要談的是多變的 2556113 (可能為英文網頁) (標題為＜使用者必須花費很長的時間才可從 Exchange Server 2010 組織中下載離線通訊錄 (OAB)＞)。

看到這個標題，您可能會認為我們一定是想出了某種方法，讓離線通訊錄 (OAB) 的下載速度可以變快，有可能是隨機刪除一些使用者，例如四樓會計部您不認得的同事；或是精簡離線通訊錄 (OAB) 中所含括的詳細資料，好比移除像姓氏、辦公室位置或電話號碼一類的非必要資訊；抑或是升級網際網路的速度等這幾種不太費力的做法。

不過您猜錯囉！我們的做法是加入一些邏輯，促使 Outlook 能夠從其鄰近的 CAS 下載離線通訊錄 (OAB) (雖然我們也很希望能夠從網際網路這方面著手，來個斧底抽薪之計)。

您或許會好奇原因何在？那麼我會說：「因為知識庫文章有提到『必須考慮下列幾種情況...』。」

  • 您在 Microsoft Exchange Server 2010 組織設有兩個 Active Directory 網站，而且使用的網路速度很慢。
  • 您的 Active Directory 網站上設有一部 Exchange Server 2010 用戶端存取伺服器與一部 Exchange Server 2010 信箱伺服器。
  • 您有一部 Exchange Server 2010 用戶端存取伺服器，又在另一個 Active Directory 網站上新增了一名 Office Outlook 使用者。
  • 信箱位於在其他 Active Directory 網站上的使用者嘗試圖下載 Exchange 離線通訊錄 (OAB)。

在上述任一種情況下，下載離線通訊錄 (OAB) 都會需要一段很長的時間。

我是說真的，沒有在開玩笑。您的離線通訊錄 (OAB) 若是十分龐大，就真的需要花上許多時間。容我進一步解釋一下這個情況，老實說，我認為有一件事您必須知道，一個 AD 網站上如果只有 CAS，對大多數的人來說並不是一件有利的事。

現在再更深入地試想一下這個情況

  • 您採用集中式佈署。所有信箱皆位於同一處。
  • 您分割了許多小位置讓人員使用及操作。
  • 這些位置透過連線效能不佳的網路、衛星、ISDN、PSTN、對流層散射系統 (可能為英文網頁)(我的一位客戶曾經用過其中一種系統。實在很棒！不過在一次暴風雨中陣亡了)、通訊品質不良的線路等等，連線到中央網站。
  • 您的離線通訊錄 (OAB) 很大、很龐大、不小等等，請選一個您認為最能表達出通訊錄大小已達到不容小觑程度的用語。
  • 您的 Outlook 用戶端嘗試下載位於中央資料中心的離線通訊錄 (OAB)。如果這時坐在您身旁的同事，以及坐在角落看起來怪怪的同事也是使用 Outlook 用戶端，而且都是透過同一條通訊品質不良的線路，在下載「同一份」離線通訊錄 (OAB)，得到的結果就是非常慢！

有時候您會發現大家在工作的同時，也會在爭奪相同的頻寬，而且雖然下載離線通訊錄 (OAB) 時使用 BITS 用戶端技術很不錯，但其實無法幫上什麼忙。

因此您在每個遠端位置上都新增了 CAS。而且實際上您已依據 https://technet.microsoft.com/zh-tw/library/bb232155.aspx 中的詳細圖表建議進行。用戶端電腦從本機 CAS 下載其所需的離線通訊錄 (OAB) 之想法，也許聽起來是個好主意，但這並不是 2010 SP2 RU1 之前版本的 Exchange 運作之方式。

那它到底是如何運作的？為何我說 TechNet 在騙您？

回應您的第一個問題，用戶端用以下載離線通訊錄 (OAB) 的 URL，由自動探索服務提供給用戶端。而自動探索程式碼一律會從您信箱所在的 AD 網站，選出您應下載之離線通訊錄 (OAB) 的 URL，而不會從用戶端電腦所在的 AD 網站下載。

至於第二個問題，您必須先了解 TechNet 從不出錯的 (就像我在 UE 的朋友 Scott Schnoll，若您暗指他們的文章有誤，他可是會很生氣的)，有時候只是從某個論點來看不是那麼正確而已。TechNet 說明這件事的方式，就好像是它是設計 2007 當時原本 PM 的規格一樣。也許我不該跟您說這些，但實際上就是如此，而且還沒結束呢。當一個軟體產品有超過兩千萬條隨時不斷更動的程式碼時，就會發生這種事。TechNet 不會騙人，嗯，或者應該是說騙不大啦。

再回到產品的運作方式來。只要稍微想一下，您的離線通訊錄 (OAB) 有 1 GB，而您將該 OAB 的複本新增至使用者所在之遠端 AD 網站的 CAS，但使用者卻從未使用過 (除非他們的信箱也存在於相同的 AD 網站，但這不是設想中的情況)，是不是令人覺得很悶？沒錯，我聽到您說「對」了，這種情況看起來有點像此圖表。

圖像

Outlook 會為用戶端的自動探索要求，使用與該用戶端電腦最近的 CAS (而且它也應該要這麼做，我們稍後會再回頭說這件事)，但傳回的 OAB URL 卻是在與信箱相同的 AD 網站中之 CAS 的 OAB URL。所以即使我們複製離線通訊錄 (OAB) 至 AD 網站 B，用戶端仍會從 AD 網站 A 取得離線通訊錄 (OAB)。

因此，擁有大量小型網站與為數眾多之離線通訊錄 (OAB) 的許多客戶，告訴我們這種方法不管用，而下載只是會耗損客戶的 WAN 頻寬而已。因此，我們該怎麼辦才好？有幾種方法可以解決這問題。而且我必須說，想出解決方法是我工作中相當有趣的部分，這正是書呆子的長才。

  1. 雖然我們詢問過客戶是否可以縮減其離線通訊錄 (OAB) 的大小、加速其 WAN，或將遠端辦公室移到較近的地方等等。但以上這些對客戶來說都不是解決方法。
  2. 我們可建立許多具有相同內容的離線通訊錄 (OAB)。並以各個使用者為單位或是以使用者下載離線通訊錄 (OAB) 的各個資料庫為單位加以指定，然後在遠端位置上只提供該離線通訊錄 (OAB)。這樣一來，自動探索就只會提供在遠端位置上所找到的 URL。喔，這聽起來很不錯... 除了要將使用者從一個網站搬到另一個網站，而且每下載一次就會讓網路慢兩倍。糟糕，自踩痛腳了。
  3. 而信箱也有相同的問題，像是將信箱移到遠端位置等等... 信箱移來移去，再加上讓管理與高可用性變得更為複雜，成本自然也就增加了。
  4. 我們可以做一些像是將 IP 位址反向處理對應到 AD 網站等動作。我相信這是我們原本預計要用來解決此問題的方法，但這方法實際上有點難。而困難的原因在於您要確保所有用戶端來源的子網路，都位於 AD 網站與服務中，接著要嘗試並為使用者所在的 AD 網站進行反向工程，然後要再了解站台連結成本，以及... 我希望您懂我的意思了。這個方法很複雜，而且很容易因為 NAT 或者是管理員沒列出 AD 網路及服務中所有可能的子網路而失敗。
  5. 我們可以「干擾」DNS 或自動探索 XML，試圖讓用戶端認為它在和集中式位置進行通訊，但實際上它是在和本機 IIS 執行個體通訊。而且實作與支援既困難又不容易進行，如果您要問的話，其實就是很煩啦。
  6. 顯而易見地，我選擇這項方法的原因就是因為其他方法看起來真的太難。

現在請您回想幾個段落前有一句「Outlook 會為用戶端的自動探索要求，使用與該用戶端電腦最近的 CAS」開頭的那個段落，我有提到會回頭講的那段。而值得回頭去看的原因是因為一個稱為 AutoDiscoverServiceSiteScope 的東西。

AutoDiscoverServiceSiteScope 是一種 CAS 設定，可協助 Outlook 用戶端對應 AD 網站至 CAS，其目的在於為自動探索要求找到離用戶端最近的 CAS。其作法是找出實際上為自動探索服務的指標之服務連線點 (SCP)。

現在來看看這是怎麼運作的吧！在 Outlook 用戶端啟動時，會進入一個有時也稱之為 'AD' 的三角形，以尋找所有 Exchange 設定所放置的服務連線點 (SCP)，希望他會找到許多項目，且每項都有一個 Keywords 屬性，此屬性會因為使用 Set-ClientAccessServer (如 AutoDiscoverServiceSiteScope: ADSiteNameA、ADSiteNameB 等) 而設定/改變或有時候弄亂。Keywords 屬性可用以指定針對自動探索要求，CAS 要負責哪一個 AD 網站。

當 Outlook 用戶端找到一個以上的服務連線點 (SCP) 時，會在自己的 AD 網站上 (當使用者啟動或變更 IP 位址時，本機 Netlogon 服務會動態更新此網站)，藉由比對儲存於 Keywords 屬性的值，建立其本身的可用服務連線點 (SCP) 清單。

接著他會建立一份清單。有可能是符合其 AD 網站 (Keywords屬性 = 用戶端 AD 網站) 的所有項目，或是在沒有任何符合項目時，清單內會包含每一個服務連線點 (SCP)。這些即是使用者可用於自動探索要求的伺服器。

使用者隨即會先從清單的頂端開始 (清單一律會以安裝日期的相同順序排列)，接著會嘗試連接到內含於 ServiceBindingInformation 屬性中的 URI (自動探索服務本身的位置) 。使用者接著會發佈 XML、取得回應等。從此之後就是過著快樂的生活啦。如需自動探索這項好東西的詳細資訊，請參閱此處。

為何這個東西很有趣呢？嗯，假設管理員已正確地設定了網站範圍 (我們會告訴管理員如何進行) 的話，AutoDiscoverServiceSiteScope 這玩意可有助於 Outlook 找出離用戶端位置最近的 CAS。 所以我們一旦收到要求，就真的不需找出哪個 CAS 離用戶端最近，因為在要求傳到 CAS 時就已經找到了。

當要求傳到 CAS 時，我們會知道傳回用戶端的設定，但總是會忘記另一件事，那就是使用者所需要的離線通訊錄 (OAB) 對於執行要求的 CAS 來說可能位於本機，但是我們卻會給使用者很遠很遠的 CAS 的 URL。這點就是該修正的地方。

因此該問題的解決方法理論上十分簡單，這代表我們不用發明新的方法找出離用戶端最近的 CAS，因為我們已經有個運作相當良好的機制了，真是感謝。

若我們假設管理員已正確地設定好 AutoDiscoverServiceSiteScope，則 CAS 用戶端會為自動探索連線至離用戶端最近的 CAS。若此項假設為真，那麼當這個 CAS 要知道自動探索 XML 中要傳回的內容時，只要檢視自己是否已有使用者應該正在使用的離線通訊錄 (OAB) 複本即可。而且如果是這樣的話，他就只要提供自己的離線通訊錄 (OAB) URL， 而非使用者信箱所在的 AD 網站中之 CAS。當然，若是他沒有使用者所需的離線通訊錄 (OAB) 複本，就會回到舊行為，也就是 CAS 將傳回位於信箱 AD 網站中之 CAS 的離線通訊錄 (OAB) URL。

基本上這張圖就會變成以下這樣：

圖像

現在是不是覺得 WAN 又更親近了呢？在 WAN 上只有一份複本，而且所有位於該位置的用戶端，現在都會從本機 CAS 取得離線通訊錄 (OAB)

您該怎麼做才能讓這種新行為發揮功效呢？只要兩件事：在 CAS 上佈署 SP2 RU1，並確認您的 AutoDiscoverServiceSiteScope 參數設定正確。

我希望這份資訊對您有幫助，並希望您的 WAN 永遠都暢行無阻 (可能為英文網頁)。

Greg Taylor
Exchange 客戶經驗
首席專案經理

這是翻譯後的部落格文章，英文原文請參閱 It Takes a Long Time…