共用方式為


Exchange 問答 令人費解的附件增大、複製公用資料夾及更多內容

Henrik Walther

問:我們的組織消息傳遞基礎結構基於 Exchange Server 2007。 我們在整個組織內設置了一個相對嚴格的消息大小限制 (12MB)。

我們發現了一個異常行為,似乎與郵件附件的大小有關。 當我將一封附帶了一個附件(假設 11MB)的電子郵件發送給外部使用者時,收件人如期收到了郵件。 但如果將此郵件(包括附件)轉發回內部網路中的寄件者,寄件者卻收到了一份發送失敗報告 (NDR),指明此郵件大小超出了當前系統限制或收件人的郵箱已滿。

仔細研究問題後我們發現:在郵件離開組織的某個時候,附件大小增加了約 30%。 我想知道,通過 Internet 發送和接收電子郵件時附件大小為什麼會增加?更重要的是,這種現象正常嗎?

答:簡單地說,是。 這種現象通常是預料之中的,不僅對 Exchange Server 2007 是這樣,而且對 Exchange Server 的早期版本以及任何其他支援 MIME(多用途 Internet 郵件擴展)和使用 Base64 對附件進行編碼的消息傳遞系統都是這樣的。 內部 Exchange 使用者向 Exchange 組織內的收件人發送的郵件不需要執行任何內容轉換。 這意味著在傳送過程中您是看不到郵件或附件的大小增加的。 而發送到外部收件人的郵件可能需要執行內容轉換。

標準 SMTP 郵件(也稱為純文字郵件)包含郵件信封和郵件內容—郵件標題和郵件正文。 這些元素以 7 位 US-ASCII 純文字為基礎。 當郵件包含非 US-ASCII 純文字的元素時,必須對元素進行編碼。 處理這類非文本內容(包括附件)時,使用 MIME 進行編碼。 Exchange 2007 和早期版本的 Exchange Server 使用 Base64 演算法對附件進行編碼。 Base64 的缺點是它會使附件的大小增加 33%。

在 Exchange 2007 中,除使用 Outlook Web Access 外,其他大部分與傳輸相關的內容轉換均在集線器傳輸伺服器上執行。 有關更詳細的解釋,請參閱 technet.microsoft.com/library/bb232174 上的主題“瞭解內容轉換”。

問:我們正在從 Exchange 2003 向 Exchange 2007 過渡。 我們已經將所有使用者郵箱都遷移到了 Exchange 2007 郵箱伺服器,所有伺服器均已使用群集連續複製 (CCR) 進行了配置。 目前,我們正在將所有公用資料夾從原有的 Exchange 2003 公用資料夾伺服器複製到基於 CCR 的郵箱伺服器上。 但是,我們在測試中發現,當 CCR 群集上出現資料丟失容錯移轉時,其他節點上的公用資料夾資料庫就不會連線。 容錯移轉後,我們也無法對其進行手動裝入。

我們擁有可以鏡像生產環境中 Exchange 2007 基礎結構的實驗室環境,測試顯示這裡也出現了同樣的問題。 在發生容錯移轉的任何 CCR 群集上,任何郵箱資料庫中都沒有這一問題,因此這似乎與 CCR 群集上的公用資料夾資料庫有很大的關係。 我們想對所有資料庫(包括公用資料夾資料庫)實現真正的冗余,您能幫我們剖析一下導致這種行為的根源嗎?

答:CCR 使用的複製方法與 Exchange 2007 中公用資料夾複製所使用的方法截然不同。 因此,如果其中一個公用資料夾資料庫在基於 CCR 的郵箱伺服器上託管,建議您不要將 Exchange 組織內的多個公用資料夾資料庫與基於 CCR 的郵箱伺服器合併在一起。 在過渡期間您可以實際這樣操作,Exchange 產品組支援將公用資料夾資料庫託管在基於 CCR 的郵箱伺服器上(例如,原有的 Exchange 2003 伺服器)。 但強烈建議您在複製完所有公用資料夾資料後刪除非基於 CCR 郵箱伺服器上的公用資料夾資料庫。

您在 Exchange 消息傳遞環境中遇到的問題屬於正常現象。 如果您有多個公用檔集資料庫,而其中一個託管在基於 CCR 的郵箱伺服器上,則在容錯移轉(即非計畫中斷)時,基於 CCR 的郵箱伺服器上的公用檔集資料庫將會離線。

實際上,在上一個主動節點再次出現之前,無法使公用資料夾資料庫連線。 此外,對於託管公用資料夾資料庫的存儲組,所有事務日誌檔都必須可用。

如果不具備這種條件,那就應該考慮從上一個完好的備份中還原公用資料夾存儲,流覽可用日誌,然後從還原的資料庫為其他節點重新設定種子。 或者,也可以從頭開始創建公用資料夾存儲。 在這種情況下,必須恢復原始的主動節點、新建公用資料夾資料庫,並從 Exchange 組織內的其他公用資料夾伺服器中複製公用資料夾資料。

頗有些奇怪的是執行無損(有計劃)中斷時公用資料夾資料庫處於連線狀態。 這是正常的表現。 有關詳細資訊,請參閱 規劃群集連續複製上的“群集連續複製和公用資料夾資料庫”。

問:在我們基於 Exchange 2007 的消息傳遞基礎結構中,所有郵箱伺服器都是使用 CCR 配置的。 我們對 CCR 的工作方式非常滿意,但希望您可以解答一個問題。

每晚進行連線維護時,我們要連線整理碎片。 我們如何確保 CCR 群集內被動節點上的資料庫在連線維護期間可以完成磁碟重組。

答:在此過程中連線磁碟重組任務(刪除所有標記為移除的項,然後將這些項佔用的空間變為可用空間)會生成新的事務日誌檔。 在 CCR 主動節點上生成所有的事務日誌檔都會被覆制到被動節點,造成其上資料庫的更改。

明確這一點後,請確保計畫連線維護時間,以免與您的備份時間發生衝突(因為這會強制連線磁碟重組中斷)。 就這一點而言,並不需要每天、每週、甚至每隔一周進行磁碟重組。 以前,Exchange 產品組指南中規定連線磁碟重組至少每隔一周進行一次。 但因每個組織的環境不同,隨著 Exchange Server 2007 SP1 的推出,情況發生了變化。 有關該新指南的詳細資訊,請參閱 Microsoft Exchange 團隊博客上的帖子。

問:我們計畫使用 Exchange 2007 CCR 實現郵箱伺服器的真正冗余。 目前,我們正在研究如何與 CCR 結合使用傳輸轉儲程式,以確保在從 CCR 主動節點向被動節點進行丟失資料容錯移轉時不會丟失任何郵件。 您知道哪些需要我們注意的傳輸轉儲程式問題嗎?

答:傳輸轉儲程式可確保在從使用 CCR 的 Exchange 2007 郵箱上的一個節點向另一個節點進行丟失資料容錯移轉時,資料的損失最小。 這可以通過重新傳送最近提交至郵箱伺服器的郵件來完成。 在丟失資料容錯移轉期間,您很有可能會丟失一些事務日誌檔,並還會因此丟失實際資料。 如前所述,傳輸轉儲程式重新傳送最近提交至郵箱伺服器的郵件,從而確保能夠恢復丟失資料容錯移轉期間損失的資料。 不過,由於傳輸轉儲程式駐留的集線器傳輸伺服器只傳送郵件,因此在即將進行丟失資料容錯移轉時創建的某些資料將會丟失,例如任務和日曆項等。

問:目前我們正計畫從 Exchange 2003 組織向新 Active Directory 林中的 Exchange 2007 組織進行跨林遷移。 我們廣泛研究了跨林遷移文檔“ 如何從單林向跨林過渡”,該文檔指出應該建立林信任而不是在各林之間建立外部信任。 為什麼不能使用外部信任?

答:儘管 TechNet 雜誌上的 Exchange 2007 文檔指出您應該使用林信任而不是外部信任,但這並不意味著您不能使用外部信任。 實際上,雖然外部信任非常適合跨林 Exchange 遷移,但它有一個缺點。 由於您不能使用已登錄使用者的憑據(無論為其分配了哪些許可權),因此在創建連結郵箱時您必須指定一個具有適當許可權的帳戶,用於訪問受信林中的網域控制站(參見圖 1)。

fig01.gif

圖 1 創建連結郵箱時在“Master Account”(主帳戶)頁面上指定一個帳戶

問:我們的組織剛剛過渡到 Exchange 2007,到目前為止我們對新版本非常滿意,只有一個例外。 當初我們在使用 Exchange 2003 SP2 時,能夠將我們的環境配置為將使用者郵箱的簡單顯示名做為出站郵件的寄件者顯示。 遺憾的是,在 Exchange 2007 中找不到類似的功能。 Exchange 2007 中千萬不要沒有該功能!

答:Exchange 2007 RTM 中確實缺失了這一功能,之後在 2008 年 10 月發佈的 Exchange 2007 SP1 Rollup Update 4 (RU4) 中才得到了修正。 利用 SP1 RU4,您可以再次將 Exchange 配置為在出站郵件中顯示簡單顯示名,效果同使用 Exchange 2003 SP2 一樣。 此任務可以使用 Windows PowerShell Set-RemoteDomain cmdlet 和參數 –UseSimpleDisplayName 完成。 例如,要在發送到 contoso.com 域的出站郵件上啟用簡單顯示名,請使用圖 2 中所示的命令。

fig02.gif

圖 2 將簡單顯示名用於出站郵件

問: 對基於 Exchange 2007-CCR 的郵箱伺服器中被動節點上的資料庫副本進行磁碟重組時,有什麼最佳做法?如果對 CCR 中一個節點上的資料庫進行了磁碟重組,但未對其他節點上的資料庫執行此操作,會不會令 Exchange 產生混淆?

答:如果需要離線整理碎片,那麼應始終在 CCR 群集中的主動節點上執行,切勿使用被動節點。 還請注意,如果您對主動節點上的一個或多個資料庫執行了離線磁碟重組,則必須對被動節點上的特殊資料庫徹底重新設定種子。

舉例來說,如果您有一個 200GB 的資料庫(若使用 CCR,通過超過 1GB 的網路複製時建議的資料庫大小為 200GB),對其進行磁碟重組將需要幾個小時(好的經驗法則是每小時2-4GB)。 但在完成磁碟重組後,您還將需要將 200GB 的資料複製到被動節點上。 如果通過公共網路傳送日誌檔,這會影響您最終使用者體驗到的網路整體性能。

在大多數情況下,執行離線磁碟重組的目的是要刪除資料庫中的所有空白區域,以便減小資料庫的大小。 但由於空白區域在資料庫進一步增大之前就會被重新使用,通常沒必要這樣做。 資料庫中或磁片本身是否有可用空間並不重要,明白了嗎?

如果在資料庫中有許多千百萬位元組的空白區域,而您想將其刪除,那麼更好的方法是將全部郵箱移出該資料庫,移入一個新的資料庫內。

Henrik Walther 是一名 Microsoft 認證架構師:Exchange 2007 和 Exchange MVP,而且具有 14 年以上的 IT 從業經驗。 他是 Interprise Consulting(位於丹麥的 Microsoft 金牌合作夥伴)的技術架構師,同時身兼 Biblioso Corporation(一家專門從事託管文檔和當地語系化服務的美國公司)的技術撰稿人。