Exchange 問答: 令人費解的附件增大、復(fù)制公用文件夾及更多內(nèi)容
問：我們的組織消息傳遞基礎(chǔ)結(jié)構(gòu)基于 Exchange Server 2007。我們在整個組織內(nèi)設(shè)置了一個相對嚴格的消息大小限制 (12MB)。
我們發(fā)現(xiàn)了一個異常行為，似乎與郵件附件的大小有關(guān)。當我將一封附帶了一個附件（假設(shè) 11MB）的電子郵件發(fā)送給外部用戶時，收件人如期收到了郵件。但如果將此郵件（包括附件）轉(zhuǎn)發(fā)回內(nèi)部網(wǎng)絡(luò)中的發(fā)件人，發(fā)件人卻收到了一份發(fā)送失敗報告 (NDR)，指明此郵件大小超出了當前系統(tǒng)限制或收件人的郵箱已滿。
仔細研究問題后我們發(fā)現(xiàn)：在郵件離開組織的某個時候，附件大小增加了約 30%。我想知道，通過 Internet 發(fā)送和接收電子郵件時附件大小為什么會增加？更重要的是，這種現(xiàn)象正常嗎？
答：簡單地說，是。這種現(xiàn)象通常是預(yù)料之中的，不僅對 Exchange Server 2007 是這樣，而且對 Exchange Server 的早期版本以及任何其他支持 MIME（多用途 Internet 郵件擴展）和使用 Base64 對附件進行編碼的消息傳遞系統(tǒng)都是這樣的。內(nèi)部 Exchange 用戶向 Exchange 組織內(nèi)的收件人發(fā)送的郵件不需要執(zhí)行任何內(nèi)容轉(zhuǎn)換。這意味著在傳送過程中您是看不到郵件或附件的大小增加的。而發(fā)送到外部收件人的郵件可能需要執(zhí)行內(nèi)容轉(zhuǎn)換。
標準 SMTP 郵件（也稱為純文本郵件）包含郵件信封和郵件內(nèi)容—郵件標題和郵件正文。這些元素以 7 位 US-ASCII 純文本為基礎(chǔ)。當郵件包含非 US-ASCII 純文本的元素時，必須對元素進行編碼。處理這類非文本內(nèi)容（包括附件）時，使用 MIME 進行編碼。Exchange 2007 和早期版本的 Exchange Server 使用 Base64 算法對附件進行編碼。Base64 的缺點是它會使附件的大小增加 33%。
在 Exchange 2007 中，除使用 Outlook Web Access 外，其他大部分與傳輸相關(guān)的內(nèi)容轉(zhuǎn)換均在集線器傳輸服務(wù)器上執(zhí)行。有關(guān)更詳細的解釋，請參閱 technet.microsoft.com/library/bb232174 上的主題“了解內(nèi)容轉(zhuǎn)換”。
問：我們正在從 Exchange 2003 向 Exchange 2007 過渡。我們已經(jīng)將所有用戶郵箱都遷移到了 Exchange 2007 郵箱服務(wù)器，所有服務(wù)器均已使用群集連續(xù)復(fù)制 (CCR) 進行了配置。目前，我們正在將所有公用文件夾從原有的 Exchange 2003 公用文件夾服務(wù)器復(fù)制到基于 CCR 的郵箱服務(wù)器上。但是，我們在測試中發(fā)現(xiàn)，當 CCR 群集上出現(xiàn)數(shù)據(jù)丟失故障轉(zhuǎn)移時，其他節(jié)點上的公用文件夾數(shù)據(jù)庫就不會聯(lián)機。故障轉(zhuǎn)移后，我們也無法對其進行手動裝入。
我們擁有可以鏡像生產(chǎn)環(huán)境中 Exchange 2007 基礎(chǔ)結(jié)構(gòu)的實驗室環(huán)境，測試顯示這里也出現(xiàn)了同樣的問題。在發(fā)生故障轉(zhuǎn)移的任何 CCR 群集上，任何郵箱數(shù)據(jù)庫中都沒有這一問題，因此這似乎與 CCR 群集上的公用文件夾數(shù)據(jù)庫有很大的關(guān)系。我們想對所有數(shù)據(jù)庫（包括公用文件夾數(shù)據(jù)庫）實現(xiàn)真正的冗余，您能幫我們剖析一下導致這種行為的根源嗎？
答：CCR 使用的復(fù)制方法與 Exchange 2007 中公用文件夾復(fù)制所使用的方法截然不同。因此，如果其中一個公用文件夾數(shù)據(jù)庫在基于 CCR 的郵箱服務(wù)器上托管，建議您不要將 Exchange 組織內(nèi)的多個公用文件夾數(shù)據(jù)庫與基于 CCR 的郵箱服務(wù)器合并在一起。在過渡期間您可以實際這樣操作，Exchange 產(chǎn)品組支持將公用文件夾數(shù)據(jù)庫托管在基于 CCR 的郵箱服務(wù)器上（例如，原有的 Exchange 2003 服務(wù)器）。但強烈建議您在復(fù)制完所有公用文件夾數(shù)據(jù)后刪除非基于 CCR 郵箱服務(wù)器上的公用文件夾數(shù)據(jù)庫。
您在 Exchange 消息傳遞環(huán)境中遇到的問題屬于正?，F(xiàn)象。如果您有多個公用文件集數(shù)據(jù)庫，而其中一個托管在基于 CCR 的郵箱服務(wù)器上，則在故障轉(zhuǎn)移（即非計劃中斷）時，基于 CCR 的郵箱服務(wù)器上的公用文件集數(shù)據(jù)庫將會脫機。
實際上，在上一個主動節(jié)點再次出現(xiàn)之前，無法使公用文件夾數(shù)據(jù)庫聯(lián)機。此外，對于托管公用文件夾數(shù)據(jù)庫的存儲組，所有事務(wù)日志文件都必須可用。
如果不具備這種條件，那就應(yīng)該考慮從上一個完好的備份中還原公用文件夾存儲，瀏覽可用日志，然后從還原的數(shù)據(jù)庫為其他節(jié)點重新設(shè)定種子?；蛘?，也可以從頭開始創(chuàng)建公用文件夾存儲。在這種情況下，必須恢復(fù)原始的主動節(jié)點、新建公用文件夾數(shù)據(jù)庫，并從 Exchange 組織內(nèi)的其他公用文件夾服務(wù)器中復(fù)制公用文件夾數(shù)據(jù)。
頗有些奇怪的是執(zhí)行無損（有計劃）中斷時公用文件夾數(shù)據(jù)庫處于聯(lián)機狀態(tài)。這是正常的表現(xiàn)。有關(guān)詳細信息，請參閱規(guī)劃群集連續(xù)復(fù)制上的“群集連續(xù)復(fù)制和公用文件夾數(shù)據(jù)庫”。
問：在我們基于 Exchange 2007 的消息傳遞基礎(chǔ)結(jié)構(gòu)中，所有郵箱服務(wù)器都是使用 CCR 配置的。我們對 CCR 的工作方式非常滿意，但希望您可以解答一個問題。
每晚進行聯(lián)機維護時，我們要聯(lián)機整理碎片。我們?nèi)绾未_保 CCR 群集內(nèi)被動節(jié)點上的數(shù)據(jù)庫在聯(lián)機維護期間可以完成碎片整理。
答：在此過程中聯(lián)機碎片整理任務(wù)（刪除所有標記為移除的項，然后將這些項占用的空間變?yōu)榭捎每臻g）會生成新的事務(wù)日志文件。在 CCR 主動節(jié)點上生成所有的事務(wù)日志文件都會被復(fù)制到被動節(jié)點，造成其上數(shù)據(jù)庫的更改。
明確這一點后，請確保計劃聯(lián)機維護時間，以免與您的備份時間發(fā)生沖突（因為這會強制聯(lián)機碎片整理中斷）。就這一點而言，并不需要每天、每周、甚至每隔一周進行碎片整理。以前，Exchange 產(chǎn)品組指南中規(guī)定聯(lián)機碎片整理至少每隔一周進行一次。但因每個組織的環(huán)境不同，隨著 Exchange Server 2007 SP1 的推出，情況發(fā)生了變化。有關(guān)該新指南的詳細信息，請參閱 Microsoft Exchange 團隊博客上的帖子。
問：我們計劃使用 Exchange 2007 CCR 實現(xiàn)郵箱服務(wù)器的真正冗余。目前，我們正在研究如何與 CCR 結(jié)合使用傳輸轉(zhuǎn)儲程序，以確保在從 CCR 主動節(jié)點向被動節(jié)點進行丟失數(shù)據(jù)故障轉(zhuǎn)移時不會丟失任何郵件。您知道哪些需要我們注意的傳輸轉(zhuǎn)儲程序問題嗎？
答：傳輸轉(zhuǎn)儲程序可確保在從使用 CCR 的 Exchange 2007 郵箱上的一個節(jié)點向另一個節(jié)點進行丟失數(shù)據(jù)故障轉(zhuǎn)移時，數(shù)據(jù)的損失最小。這可以通過重新傳送最近提交至郵箱服務(wù)器的郵件來完成。在丟失數(shù)據(jù)故障轉(zhuǎn)移期間，您很有可能會丟失一些事務(wù)日志文件，并還會因此丟失實際數(shù)據(jù)。如前所述，傳輸轉(zhuǎn)儲程序重新傳送最近提交至郵箱服務(wù)器的郵件，從而確保能夠恢復(fù)丟失數(shù)據(jù)故障轉(zhuǎn)移期間損失的數(shù)據(jù)。不過，由于傳輸轉(zhuǎn)儲程序駐留的集線器傳輸服務(wù)器只傳送郵件，因此在即將進行丟失數(shù)據(jù)故障轉(zhuǎn)移時創(chuàng)建的某些數(shù)據(jù)將會丟失，例如任務(wù)和日歷項等。
問：目前我們正計劃從 Exchange 2003 組織向新 Active Directory 林中的 Exchange 2007 組織進行跨林遷移。我們廣泛研究了跨林遷移文檔“如何從單林向跨林過渡”，該文檔指出應(yīng)該建立林信任而不是在各林之間建立外部信任。為什么不能使用外部信任？
答：盡管 TechNet 雜志上的 Exchange 2007 文檔指出您應(yīng)該使用林信任而不是外部信任，但這并不意味著您不能使用外部信任。實際上，雖然外部信任非常適合跨林 Exchange 遷移，但它有一個缺點。由于您不能使用已登錄用戶的憑據(jù)（無論為其分配了哪些權(quán)限），因此在創(chuàng)建鏈接郵箱時您必須指定一個具有適當權(quán)限的帳戶，用于訪問受信林中的域控制器（參見圖 1）。
.gif)
圖 1 創(chuàng)建鏈接郵箱時在“Master Account”（主帳戶）頁面上指定一個帳戶
問：我們的組織剛剛過渡到 Exchange 2007，到目前為止我們對新版本非常滿意，只有一個例外。當初我們在使用 Exchange 2003 SP2 時，能夠?qū)⑽覀兊沫h(huán)境配置為將用戶郵箱的簡單顯示名做為出站郵件的發(fā)件人顯示。遺憾的是，在 Exchange 2007 中找不到類似的功能。Exchange 2007 中千萬不要沒有該功能！
答：Exchange 2007 RTM 中確實缺失了這一功能，之后在 2008 年 10 月發(fā)布的 Exchange 2007 SP1 Rollup Update 4 (RU4) 中才得到了修正。利用 SP1 RU4，您可以再次將 Exchange 配置為在出站郵件中顯示簡單顯示名，效果同使用 Exchange 2003 SP2 一樣。此任務(wù)可以使用 Windows PowerShell Set-RemoteDomain cmdlet 和參數(shù) –UseSimpleDisplayName 完成。例如，要在發(fā)送到 contoso.com 域的出站郵件上啟用簡單顯示名，請使用圖 2 中所示的命令。
.gif)
圖 2 將簡單顯示名用于出站郵件
問：對基于 Exchange 2007-CCR 的郵箱服務(wù)器中被動節(jié)點上的數(shù)據(jù)庫副本進行碎片整理時，有什么***做法？如果對 CCR 中一個節(jié)點上的數(shù)據(jù)庫進行了碎片整理，但未對其他節(jié)點上的數(shù)據(jù)庫執(zhí)行此操作，會不會令 Exchange 產(chǎn)生混淆？
答：如果需要脫機整理碎片，那么應(yīng)始終在 CCR 群集中的主動節(jié)點上執(zhí)行，切勿使用被動節(jié)點。還請注意，如果您對主動節(jié)點上的一個或多個數(shù)據(jù)庫執(zhí)行了脫機碎片整理，則必須對被動節(jié)點上的特殊數(shù)據(jù)庫徹底重新設(shè)定種子。
舉例來說，如果您有一個 200GB 的數(shù)據(jù)庫（若使用 CCR，通過超過 1GB 的網(wǎng)絡(luò)復(fù)制時建議的數(shù)據(jù)庫大小為 200GB），對其進行碎片整理將需要幾個小時（好的經(jīng)驗法則是每小時2-4GB）。但在完成碎片整理后，您還將需要將 200GB 的數(shù)據(jù)復(fù)制到被動節(jié)點上。如果通過公共網(wǎng)絡(luò)傳送日志文件，這會影響您最終用戶體驗到的網(wǎng)絡(luò)整體性能。
在大多數(shù)情況下，執(zhí)行脫機碎片整理的目的是要刪除數(shù)據(jù)庫中的所有空白區(qū)域，以便減小數(shù)據(jù)庫的大小。但由于空白區(qū)域在數(shù)據(jù)庫進一步增大之前就會被重新使用，通常沒必要這樣做。數(shù)據(jù)庫中或磁盤本身是否有可用空間并不重要，明白了嗎？
如果在數(shù)據(jù)庫中有許多千兆字節(jié)的空白區(qū)域，而您想將其刪除，那么更好的方法是將全部郵箱移出該數(shù)據(jù)庫，移入一個新的數(shù)據(jù)庫內(nèi)。
Henrik Walther 是一名 Microsoft 認證架構(gòu)師：Exchange 2007 和 Exchange MVP，而且具有 14 年以上的 IT 從業(yè)經(jīng)驗。他是 Interprise Consulting（位于丹麥的 Microsoft 金牌合作伙伴）的技術(shù)架構(gòu)師，同時身兼 Biblioso Corporation（一家專門從事托管文檔和本地化服務(wù)的美國公司）的技術(shù)撰稿人。
文章出處：TechNet中文網(wǎng)
【編輯推薦】
