淺談Exchange Server郵件存儲系統(tǒng)原理篇

1、轉(zhuǎn)帖淺談Exchange Server郵件存儲系統(tǒng)-原理篇來源：Winmag國際中文版作者/喻勇導(dǎo)讀：本文從數(shù)據(jù)庫基本原理的角度入手，通過對Exchange Server Store模塊的分析，來揭示Exchange Server郵件存儲系統(tǒng)的工作原理和維護(hù)技巧。文章適合有一定Exchange Server管理經(jīng)驗(yàn)的專業(yè)IT人員閱讀，目的是使讀者在維護(hù)Exchange Server郵件系統(tǒng)時，能夠做到知其然，更知其所以然。Information Store和Extensible Storage Engine的層次關(guān)系眾所周知，在Exchange Server中，Information Stor

2、e （簡稱IS）Service是至關(guān)重要的。這個服務(wù)控制了對郵箱和公共文件夾數(shù)據(jù)庫的操作請求。更進(jìn)一步的來看，事實(shí)上Exchange Server的數(shù)據(jù)庫系統(tǒng)是由名為Extensible Storage Engine（簡稱ESE）的數(shù)據(jù)庫引擎來管理的。這個ESE引擎是微軟專門為保存非關(guān)系型數(shù)據(jù)而開發(fā)的，在微軟的很多系統(tǒng)中都有應(yīng)用：例如，AD的數(shù)據(jù)庫（ntds.dit文件）、Windows DHCP、Windows WINS、SRS等，后臺都是由ESE數(shù)據(jù)庫來提供支持的。我們知道，Exchange Server的數(shù)據(jù)庫由edb文件、stm文件和眾多的log文件組成。在這些文件內(nèi)部，微軟使用了名為

3、“B+樹”的內(nèi)部數(shù)據(jù)結(jié)構(gòu)，ESE引擎的任務(wù)之一，就是當(dāng)Information Store服務(wù)請求訪問數(shù)據(jù)庫的時候，把這些請求轉(zhuǎn)化成對內(nèi)部數(shù)據(jù)結(jié)構(gòu)的讀寫訪問。B+樹的特點(diǎn)是能夠?qū)Υ鎯υ诖疟P上的數(shù)據(jù)提供快速的訪問能力。微軟選用B+樹作為ESE后臺結(jié)構(gòu)的一個原因，就是盡可能提高訪問數(shù)據(jù)時的I/O性能。這些B+樹的結(jié)構(gòu)對于Exchange Server Store服務(wù)來說是透明的，Store只需要把請求發(fā)給ESE即可，ESE會對這些數(shù)據(jù)結(jié)構(gòu)進(jìn)行操作。另外，作為一個數(shù)據(jù)庫系統(tǒng)，ESE有責(zé)任提供事務(wù)（Transaction）級別操作的支持，并維護(hù)整個數(shù)據(jù)庫的完整性和一致性。對于現(xiàn)代數(shù)據(jù)庫系統(tǒng)，當(dāng)我們提到事

4、務(wù)時，一般用ACID這樣的縮寫來描述事務(wù)的特點(diǎn)：我們會在后面的篇幅中詳細(xì)的討論Exchange Server和ESE是怎樣實(shí)現(xiàn)上述的要求的。對于Information Store Service來說，ESE封裝了對數(shù)據(jù)庫操作的所有細(xì)節(jié)，IS只要根據(jù)ESE提供的接口進(jìn)行調(diào)用既可。在Exchange Server 2000中，IS服務(wù)對應(yīng)的進(jìn)程是store.exe，每一個Storage Group會在store.exe進(jìn)程中產(chǎn)生一個ESE引擎的實(shí)例。Exchange Server 2000/2003 存儲系統(tǒng)的新特點(diǎn)在微軟發(fā)布Exchange Server 2000時，Exchange Serve

5、r的存儲系統(tǒng)得到了很大的更新和改進(jìn)。從ESE引擎的角度來看，ESE的版本由5.5中的ESE97升級為ESE98，并且在如下方面得到了改進(jìn)：1.I/O性能得到進(jìn)一步的優(yōu)化和提高2.對日志文件增加了計算校驗(yàn)和的操作，進(jìn)一步降低了數(shù)據(jù)庫出錯的可能性3.提高了ESEUtil等維護(hù)工具的速度相比幕后的ESE引擎，Information Store方面的更新更加引人注意，例如：1.在每臺Server上提供多個Storage Group和Store的支持，這是區(qū)別于5.5的最大特征之一2.數(shù)據(jù)庫中stm流文件格式的引入，提高了操作Internet郵件的性能3.Web Storage System的引入，用戶

6、可以使用多種協(xié)議訪問數(shù)據(jù)庫EDB文件和STM文件的關(guān)系在Exchange Server 5.5中，數(shù)據(jù)庫只有擴(kuò)展名為edb的文件。在Exchange Server 5.5發(fā)布的時候，微軟的重點(diǎn)還是企業(yè)內(nèi)部的郵件傳輸系統(tǒng)，當(dāng)時主推的協(xié)議是MAPI協(xié)議，這是微軟的私有郵件協(xié)議，edb格式的數(shù)據(jù)庫為此協(xié)議作了專門的優(yōu)化。因此，Exchange Server 5.5為了支持Internet標(biāo)準(zhǔn)的SMTP郵件格式，必須在每次處理Internet郵件時將其轉(zhuǎn)化為edb可以識別的格式，這樣做帶來的巨大的性能損失。在Exchange Server 2000中，微軟加大了對Internet標(biāo)準(zhǔn)協(xié)議SMTP的支持

7、力度。因此，適用于Internet格式郵件的存儲就應(yīng)運(yùn)而生：這就是stm文件。MAPI格式的郵件是基于微軟的RPC和二進(jìn)制標(biāo)準(zhǔn)的，而Internet格式的郵件是由純文本的郵件頭和經(jīng)過MIME編碼的字符流組成的。這兩者的特性就決定他們無法共存在一種數(shù)據(jù)庫結(jié)構(gòu)的文件中。因此，在Exchange Server 2000中，微軟分別使用edb文件和stm文件保存這兩種格式的郵件，并在edb和stm文件之間建立了關(guān)聯(lián)和引用。對于用戶來說，他的郵箱內(nèi)容實(shí)際上是由跨越了edb和stm文件中的內(nèi)容共同組成的。值得一提的是，edb文件中除了實(shí)際的信件信息以外，還保存了每個用戶的郵箱結(jié)構(gòu)、每一個文件夾的內(nèi)容列表和

8、視圖等信息。這是區(qū)別于stm中只保存字符流的地方。我們分下面幾種情況討論edb和stm文件的使用：1.用戶使用Outlook 以MAPI協(xié)議的方式和發(fā)送和訪問郵件2.用戶使用 SMTP/POP3等Internet協(xié)議訪問Exchange Server。情景一：當(dāng)郵件從MAPI協(xié)議的客戶端(通常是Microsoft Office中的Outlook)提交到數(shù)據(jù)庫后，郵件內(nèi)容被保存在edb文件中。當(dāng)用戶通過MAPI協(xié)議的客戶端對郵箱中的郵件進(jìn)行讀取訪問時，如果請求的郵件是保存在edb文件中的，那么信件被直接打開后返回給用戶。如果被請求的信件保存在stm文件中（此信件是SMTP格式的），那么，Exch

9、ange Server數(shù)據(jù)庫引擎首先會做一個轉(zhuǎn)換，把stm文件中的數(shù)據(jù)格式轉(zhuǎn)換成MAPI可以識別的格式，然后再發(fā)送給客戶端。這個過程稱之為“On-demand Conversion”。情景二：用戶使用SMTP/POP3客戶端（如Outlook Express, FoxMail等）跟郵箱連接。當(dāng)SMTP協(xié)議向Exchange Server提交郵件時，郵件的內(nèi)容被保存在stm文件中。前面提到過，edb文件中包含了用戶郵箱的文件夾和信件內(nèi)容列表，因此，當(dāng)郵件被保存到stm文件后，數(shù)據(jù)庫引擎把這封郵件的一些重要信息（通常是郵件頭中的內(nèi)容和信件在stm文件中的位置）提取出來，保存到edb文件，這個過程稱

10、之為“Property Promotion”。正是有了這個過程，用戶才可以得到信箱內(nèi)容的完整列表，MAPI客戶端需要訪問位于stm文件中的郵件時，由此能夠得到stm文件中信件的正確保存位置。當(dāng)用戶使用POP3協(xié)議來讀取郵件時，如果被訪問的郵件位于edb文件中，同樣，一個從MAPI到Internet格式的轉(zhuǎn)化（“ On-demand Conversion”）也會在后臺悄悄的發(fā)生。通過上面的描述，我們知道在實(shí)際的Exchange Server環(huán)境中，這兩個文件是緊密關(guān)聯(lián)的。在任何時候都不要單獨(dú)的操作這兩個文件，要始終把他們視為一個整體。edb文件中包含了每一個郵箱的內(nèi)容列表（store table

11、s），當(dāng)客戶端需要得到文件夾的內(nèi)容時，都必須向edb文件發(fā)出請求。兩種格式的文件，對兩種類型的協(xié)議分別提供了支持，有效的減少了不必要的格式轉(zhuǎn)換的發(fā)生。Log文件的作用我們討論Exchange Server的郵件存儲，就不得不談?wù)勊娜罩疚募Ｎ也恢挂淮蔚穆牭紼xchange Server的管理員抱怨：日至文件每天都在瘋長，太消耗硬盤空間了。我們來看看這些日志文件到底有些什么作用。對于每一個Storage Group，Exchange Server會產(chǎn)生一系列與之對應(yīng)的日志文件。這些日志文件的大小為5M，擴(kuò)展名為log，他們的前綴為E0x,其中x是日志文件所對應(yīng)的Storage Group的編號

12、腳注:雖然在Storage Group的屬性中有“Log File Prefix”這一個文本框，但實(shí)際上這是不能更改的。因此第一個Storage Group的日志文件前綴為E00，第二個的為E01，依次類推。這樣做的目的是當(dāng)存在多個Storage Group時，可以避免管理員在維護(hù)的時候把日志文件”張冠李戴”。另外，除了連續(xù)的Log文件，我們還能看到E0x.chk、Res1.log、Res2.log等文件。很多管理員都對日志文件非常的頭疼，那么，微軟在Exchange Server的數(shù)據(jù)庫系統(tǒng)中引入Log文件的目的是什么呢？我們從以下幾個方面來看：1.作為一個企業(yè)級的郵件數(shù)據(jù)庫系統(tǒng)，必須做到數(shù)

13、據(jù)安全和完整性的萬無一失。必須能夠面對隨時可能發(fā)生的崩潰和宕機(jī)，What happens if we crash? 要能夠把數(shù)據(jù)的損失減少到最新程度。2.必須提供高性能的郵件吞吐能力，對數(shù)據(jù)庫中的郵件的事務(wù)操做在完成后必須馬上被記錄到存儲介質(zhì)上（事務(wù)的持久性）。3.當(dāng)災(zāi)難發(fā)生時，使用數(shù)據(jù)庫的備份恢復(fù)必須要返回到災(zāi)難發(fā)生前一刻的數(shù)據(jù)庫狀態(tài)?，F(xiàn)在我們更進(jìn)一步的來看一下，當(dāng)我要修改郵箱中的內(nèi)容時，被修改的內(nèi)容首先被讀取出來放到內(nèi)存中。實(shí)際的修改發(fā)生在內(nèi)存中，當(dāng)修改完成后，這些內(nèi)容必須被寫回存儲介質(zhì)，才能表示一個修改成功地完成了。對于這樣的修改過程，在數(shù)據(jù)庫級別上，我們叫做一個“事務(wù)”。我們知道，為了

14、確保數(shù)據(jù)庫的完整性和一致性，事務(wù)的操作是“原子級別”的。如果一個事務(wù)成功，那么標(biāo)志著他所作的改變被永久的保存下來了；如果一個事務(wù)失敗，系統(tǒng)必須回到事務(wù)開始之前的狀態(tài)。當(dāng)系統(tǒng)在內(nèi)存中完成修改時，事務(wù)并沒有完成。如果這個時候宕機(jī)，數(shù)據(jù)庫中保存的仍然是沒有更改的內(nèi)容。那么，怎么樣確保在內(nèi)存中完成的修改能夠在第一時間寫入到數(shù)據(jù)庫呢（以達(dá)到數(shù)據(jù)庫事務(wù)持久性的要求）？注意，這里的要是第一時間，也就是越快越好。如果我們直接向edb文件寫入，無法做到最快，因?yàn)椋琫db文件通常都很大，I/O系統(tǒng)在對大的文件進(jìn)行隨機(jī)寫入操作時，會花費(fèi)大量的時間在等待磁盤查找到合適的磁道和扇區(qū)，當(dāng)系統(tǒng)繁忙時，這將會是一個瓶頸。因此

15、，數(shù)據(jù)庫系統(tǒng)使用日志文件，當(dāng)內(nèi)存中的更改完成后，首先寫入到日志文件中。日志文件的尺寸很小，寫入性能要遠(yuǎn)遠(yuǎn)優(yōu)于龐大的edb文件。在寫入完成后，事務(wù)也隨之成功的保存在存儲介質(zhì)上了。Exchange Server 的數(shù)據(jù)庫引擎會在后臺把Log文件中的內(nèi)容寫入到數(shù)據(jù)庫中，因?yàn)榇藭r事務(wù)操作已經(jīng)完成，即使此時掉電或者宕機(jī)，也不會使完成的事務(wù)遺失。這是日志文件的第一個作用：確保事務(wù)能夠在第一時間保存到非易失存儲介質(zhì)上。（提供持久性Durable支持）根據(jù)上面的描述，我們知道在運(yùn)行中的Exchange Server數(shù)據(jù)庫，是由三部分組成的內(nèi)存中已經(jīng)完成修改但是還沒有寫入日志文件的內(nèi)容（Dirt Page）。還

16、沒有寫入到數(shù)據(jù)庫文件的日志文件內(nèi)容。Edb和stm文件。對于內(nèi)存中的數(shù)據(jù)（Dirt Page），這些數(shù)據(jù)會在系統(tǒng)掉電或者崩潰時遺失。Exchange Server使用了一個名為E0x.chk（Check Point）的文件記錄了那些Log文件已經(jīng)寫入到了數(shù)據(jù)庫文件。這是一個類似指針的記錄。我們可以使用命令 ESEUTIL /MK來查看這個文件chk的內(nèi)容C:.ExchsrvrBIN> ESEUtil /mk “C:.Exchsrvrmdbdatae00.chk”Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0

17、Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved. Initiating FILE DUMP mode.Checkpoint file: C:program filesexchsrvrmdbdatae00.chkLastFullBackupCheckpoint: (0x0,0,0)Checkpoint: (0x8,26DA,30)FullBackup: (0x0,0,0)FullBackup time: 00/00/1900 00:00:00IncBackup: (0x0,0,0)IncBackup time:

18、 00/00/1900 00:00:00Signature: Create time:03/28/2004 20:26:10 Rand:6519986 Computer:Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers)( off, 202, 10100, 1365, 10100, 128, 10240, 40828)Operation completed successfully in 1.47 seconds.在命令的輸出中， Checkpoint: <0x8,26DA,30>表示了當(dāng)前提交

19、到數(shù)據(jù)庫文件的Log完全位置。其中，0x8是Log文件的序號，一般對應(yīng)于E0x00008.log,剩下的兩個參數(shù)是Log文件內(nèi)部頁面（page）的編號。下面我們再看一下日志文件對系統(tǒng)備份和恢復(fù)的作用。前面提到過，Exchange Server要求在災(zāi)難發(fā)生后能夠恢復(fù)到災(zāi)難發(fā)生前一刻的狀態(tài)。對于一般的系統(tǒng)，我們總是每周或者每天進(jìn)行備份，那么，在備份之后和災(zāi)難發(fā)生之前這段時間的數(shù)據(jù)如何保護(hù)？答案是日志文件。我們知道，對于數(shù)據(jù)庫的任何更改，都會先被寫入到日志文件，然后再由日志文件更新到數(shù)據(jù)庫中。我們現(xiàn)在假設(shè)有這樣一套系統(tǒng)，在每天的3:00 AM進(jìn)行備份，備份完成后，系統(tǒng)正常運(yùn)轉(zhuǎn)。如果在中午12:00

20、的時候系統(tǒng)出現(xiàn)故障，管理員用3:00AM的磁帶恢復(fù)了系統(tǒng)，那么，從3:00AM到12:00AM這段時間的數(shù)據(jù)，將由log文件來填補(bǔ)的。具體的情況是，當(dāng)3:00AM的備份恢復(fù)完成后，Exchange Server會自動掃描到跟這個store相關(guān)聯(lián)的日志文件夾，如果發(fā)現(xiàn)有比當(dāng)前數(shù)據(jù)庫還新的日志存在，Exchange Server會自動把這些日志按照順序?qū)懭氲綌?shù)據(jù)庫中。因此，從3:00AM到12:00AM這段時間對數(shù)據(jù)庫所作的更改，可以被恢復(fù)回來。這是日志文件第二個重要的作用。（前提是沒有開啟循環(huán)日志功能）有人可能會問，如果數(shù)據(jù)庫文件和日志文件同時損壞怎么辦？答案是這樣的：避免這種情況發(fā)生。首先，數(shù)

21、據(jù)庫文件損壞的概率要遠(yuǎn)遠(yuǎn)大于日志文件，另外，微軟推薦的做法是把數(shù)據(jù)庫文件和日志文件分別放置在不同的磁盤上。我們會在下一期的文章中著重討論這個問題。管理員針對日志文件的抱怨是，這些文件會每天不斷的增長，大量消耗硬盤空間。對于這個問題，唯一合理的解決辦法是：定期的做針對Storage Group的全備份或增量備份。因?yàn)镋xchange Server會在全備份或增量備份完成后把這次備份之前產(chǎn)生的Log文件全部刪除。很多管理員手動的刪除日志文件，或者啟動“循環(huán)日志”來減少對硬盤空間的消耗，這都是不正確的做法。殘缺不全的日志文件會使系統(tǒng)在進(jìn)行備份恢復(fù)的時候無法還原到最近的狀態(tài)。如果你的系統(tǒng)是一周做一次全

22、備份，而你碰巧又在備份后刪除了一些日志文件，那么你就有可能在需要恢復(fù)的時候丟失備份以后的數(shù)據(jù)。記住，數(shù)據(jù)總是比磁盤空間更寶貴。ESE數(shù)據(jù)庫引擎以及Information Store服務(wù)的啟動和關(guān)閉在ESE引擎加載數(shù)據(jù)庫文件時，它會檢查數(shù)據(jù)庫文件的一個特殊標(biāo)志位。這個標(biāo)志位保存了數(shù)據(jù)庫文件上次是否被正常關(guān)閉。這個狀態(tài)由“ Consistent”或“ Inconsistent”來表示。對于一個正常關(guān)閉的數(shù)據(jù)庫文件，所有在Log文件和內(nèi)存中的內(nèi)容都應(yīng)該已經(jīng)提交到數(shù)據(jù)庫文件中，只有在這個時候，數(shù)據(jù)庫才會被標(biāo)記為“ Consistent”。有一點(diǎn)需要注意，在運(yùn)行中的數(shù)據(jù)庫，它的狀態(tài)一定是“ Incons

23、istent”，因?yàn)樵贚og文件中肯定還有沒提交到數(shù)據(jù)庫文件內(nèi)容。對于一個已經(jīng)關(guān)閉并且狀態(tài)被標(biāo)示為“ Inconsistent”的數(shù)據(jù)庫，并不意味著這個數(shù)據(jù)庫庫文件損壞了，“ Inconsistent”只是表示，還有未曾寫入到數(shù)據(jù)庫文件的內(nèi)容保存在Log文件中。使用命令 ESEUTIL /MH可以查?？磾?shù)據(jù)庫的關(guān)閉狀態(tài)。C:.ExchsrvrBIN> ESEUtil /mh “C:.Exchsrvrmdbdatapriv1.edb”Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0 Copyright (C) M

24、icrosoft Corporation 1991-2000. All Rights Reserved. Initiating FILE DUMP mode.Database: C:program filesexchsrvrmdbdatapriv1.edbFile Type: DatabaseFormat ulMagic: 0x89abcdefEngine ulMagic: 0x89abcdefFormat ulVersion: 0x620,9Engine ulVersion: 0x620,9Created ulVersion: 0x620,9DB Signature: Create time

25、:03/28/2004 20:26:24 Rand:6536656 Computer:cbDbPage: 4096dbtime: 63139 (0-63139)State: Clean Shutdown <-表示數(shù)據(jù)庫關(guān)閉時的狀態(tài)Log Required: 0-0Streaming File: YesShadowed: YesLast Objid: 574<略> Operation completed successfully in 1.391 seconds.State字段的“Clean Shutdown”表示數(shù)據(jù)庫處在Consistent狀態(tài)。當(dāng)ESE加載數(shù)據(jù)庫文件時，對

26、于“Consistent”的數(shù)據(jù)庫文件，它直接Mount其中的Store；對于“In consistent”的數(shù)據(jù)庫文件，ESE將執(zhí)行稱之為“Soft Recovery”的過程，在這個過程中，未及時提交進(jìn)數(shù)據(jù)庫文件的日志內(nèi)容將被寫入數(shù)據(jù)庫。當(dāng)所有的日志都寫入完畢，數(shù)據(jù)庫才會被標(biāo)記為“ Consistent”狀態(tài)，然后正常加載。Soft Recovery開始的時候，ESE會根據(jù)check point文件所指向的位置來進(jìn)行Log文件的寫入(如果check point文件也損壞或者不存在，那么數(shù)據(jù)庫就從最舊的Log文件開始)。當(dāng)ESE從Log文件向Store寫入數(shù)據(jù)時，它會根據(jù)dbTime這個時間戳

27、來決定是否需要把Log文件寫入到數(shù)據(jù)庫。在這個過程中，Event Log中會有如下的記錄Event Type: InformationEvent Source: ESE98Event Category: Logging and RecoveryEvent ID: 301Date: 10/17/2001Time: 5:52:11 AMUser: N/AComputer: Description: Information Store (XXXX) The database engine has begun replaying logfile .E0014553.log.我們也可以針對已經(jīng)“Dis-

28、mount”的并且是處在“Inconsistent”的數(shù)據(jù)庫手工地進(jìn)行“Soft Recovery”。具體的命令是“eseutil /r”，后跟數(shù)據(jù)庫文件的路徑。（推薦在掉電重啟以后執(zhí)行此命令，可以先運(yùn)行eseutil /mh確定數(shù)據(jù)庫狀態(tài)，如果是“Inconsistent”，再執(zhí)行此命令）由此我們可以發(fā)現(xiàn)，Exchange Server有能力對未正常關(guān)閉的數(shù)據(jù)庫進(jìn)行“自我修復(fù)”。因此，ESE確保了即使在突然掉電的情況下，數(shù)據(jù)庫仍然能夠處在一個可恢復(fù)的狀態(tài)，并且會在重啟服務(wù)以后自動完成狀態(tài)檢測和恢復(fù)。M盤的來龍去脈在Exchange Server 2000發(fā)布時，微軟提出了“Web Stora

29、ge System”的概念，其核心就是提供多種途徑來訪問Exchange Server的數(shù)據(jù)庫。這些途徑包括文件系統(tǒng)/IFSHttp WebDAVExOLEDB/ ADOCDO其中，提供文件系統(tǒng)服務(wù)的IFS技術(shù)是引起爭議比較多的一個模塊。在安裝Exchange Server 2000后，系統(tǒng)會出現(xiàn)一個M盤。這個M盤，就是由微軟通過IFS（Installable File System）技術(shù)實(shí)現(xiàn)的一個數(shù)據(jù)庫到文件系統(tǒng)的映射。開發(fā)人員可以通過標(biāo)準(zhǔn)的文件操作API（如CreateFile, OpenFile等）來訪問Exchange Server的郵箱和郵件。打開M盤，你可以看到一個以你當(dāng)前域名命名

30、的文件夾。在這個文件加下面，你會看到一個包含了所有郵箱的文件夾，名為MBX。MBX下面，是以用戶的姓名來命名的郵箱文件夾，在每個文件夾下面，都可以看到Inbox、Outbox等郵箱的內(nèi)容。每一封信件，都是以擴(kuò)展名為EML的文件來表示的。ExIFS使用了一個名為.BackOfficeStorage的特殊共享名稱來指向數(shù)據(jù)庫文件。你可以在命令行中運(yùn)行“Dir .BackOfficeStoragedomain.conMBX”，這個命令的實(shí)行結(jié)果跟直接使用M盤作為盤符是一樣的。我們可以通過修改注冊表的方式所來改變Exchange Server所映射的盤符。HLKMSystemCurrentControlSetServicesExIFSParametersName: DriveLetterData Type: REG_SZValue: Drive letter for IFS (盤符，不需要跟冒號)在更改注冊表以后，需要重啟Information Store Service使更改生效。我們也可以使用如下的命令行工具來改變M盤的映射：Subst X: .BackOfficeStorage 注釋：把Exchange Store映射到X盤Subst /d M: 注釋：刪除對M盤的映