Exchange Server 2003 郵件路由
上次修改主題的時間： 2007-03-06
對於寄給非本機收件者的郵件，路由引擎必須向進階佇列引擎提供目的地傳輸路徑中下一個躍點主機的資訊，以及下一個躍點類型 (如上一個主題所述)。下一個躍點主機是實際的路由位址，而下一個躍點類型決定了進階佇列引擎如何處理郵件。為提供這項重要資訊，路由引擎必須全面掌握整個路由拓撲。包括所有路由群組及其伺服器、路由群組連接器，以及連到外部郵件系統的連接器。在 Exchange Server 2003 中，此資訊可從 Active Directory 目錄服務取得。
每一部 Exchange 2003 伺服器都會依據 Active Directory 及連結狀態資訊，在記憶體中動態地維護自己的路由表格，此表格稱為連結狀態表，包含下列資訊：
與路由相關的 Active Directory 資訊 此資訊儲存於組織物件、路由群組物件、連接器物件及伺服器物件的屬性中。這些物件位於組態目錄磁碟分割中，可以定義整個 Exchange 組織的路由拓撲。
.gif "note")
附註：在 Exchange 組織中，系統管理群組不是路由拓撲的一部份。 連結狀態資訊 此資訊指出路由拓撲中的每一個連接器可用 (開啟) 還是不可用 (關閉)。連結狀態資訊是動態的，當連接器遇到傳輸問題或傳輸問題解決時，此資訊可能會有所變更。如需跨 Exchange 組織變更連結狀態及傳播連結狀態資訊的相關資訊，請參閱連結狀態傳播。
啟動時，每一部 Exchange 伺服器都會使用下列 Active Directory 資訊，初始化其連結狀態表：
- 組織物件 路由拓撲的界限為 Exchange 組織。亦即，連結狀態表不包含外部 Bridgehead 伺服器或外部郵件系統中之郵件連接器的任何相關資訊。對於路由引擎而言，路由拓撲到外部郵件系統的連接器處便結束。因此，路由引擎會讀取在 Active Directory 中 Exchange 組織物件的 objectGUID 屬性中註冊的 GUID，並在連結狀態表上加上 GUID 戳記，以決定此路由資訊所屬的組織。
- 路由群組物件 路由引擎會列舉所有系統管理群組中的所有路由群組，並向每一個路由群組查詢所有的物件屬性，包括列出所有路由群組成員伺服器的 msExchRoutingGroupMembersBL 屬性。路由引擎會將此資訊放置於連結狀態表中。路由引擎還會將伺服器與其路由群組的 GUID，一起放置於記憶體的伺服器快取中。伺服器快取中的每一個項目，都是一個附加了伺服器路由群組 GUID 的伺服器 FQDN。
另一個重要的路由群組屬性為 msExchRoutingMasterDN 屬性，它會指向選定路由群組中路由群組主機的辨別名稱。如需路由群組主機之工作及責任的相關資訊，請參閱本節後面論述。 - 郵件連接器物件 此路由引擎會列舉在每一個路由群組的 [連線] 容器內，所有物件類型為 msExchconnector 的子物件。[連線] 容器內的 msExchconnector 物件為路由群組連接器，以及路由群組中設定連到外部郵件系統的連接器。路由引擎會從這些連接器物件讀取所有屬性，以判定位址空間、成本值、限制等等。路由引擎會將每一個連接器的資訊放置於連結狀態表中。如此一來，郵件便能夠路由到本機路由群組以外的目的地。
處理程序會繼續進行，直到路由引擎識別所有直接及間接連接的路由群組，並查詢其郵件連接器的組態詳細資料。當此處理程序結束時，路由引擎即全面掌握 Exchange 組織中所有可用的傳輸路徑。所有連結都假設已啟用且可用於郵件傳輸。初始化連結狀態表之後，路由引擎會與本機伺服器上的 Microsoft Exchange Routing Engine 服務進行通訊，以取得反映每一個連接器目前狀態的動態連結狀態資訊。Exchange 路由引擎服務透過 TCP 通訊埠 691 連接至本機路由群組中的路由群組主機，以擷取此資訊。如需連結狀態資訊的相關資訊，請參閱本主題後面的＜檢查連結狀態表＞一節。
傳輸子系統中的路由引擎與 Exchange 路由引擎服務具有不同的角色。Exchange 路由引擎服務不會執行任何郵件路由作業。Exchange 路由引擎服務會在本機路由群組中，執行 Exchange 2000 Server 與執行 Exchange Server 2003 的伺服器之間，進行連結狀態資訊通訊。Exchange 路由引擎服務以 resvc.dll 的形式實作，resvc.dll 位於 \Program Files\Exchsrvr\bin\ 目錄中。服務名稱為 RESvc。如需 Exchange Server 2003 之 Microsoft Windows 服務的相關資訊，請參閱 Exchange Server 2003 服務依存性。
Exchange 路由引擎服務是一種路由群組內部連結狀態通訊服務，而不是路由引擎。SMTP 進階佇列引擎及 Exchange MTA 實際用來路由郵件的路由引擎，是以名為 reapi.dll 的檔案形式實作。至於 Exchange MTA，則還有一部份程式碼在 mtaroute.dll 中。因此，當 Exchange 路由引擎服務停止時，進階佇列引擎及 Exchange MTA 兩者仍會使用 reapi.dll 中的程式碼來路由郵件。不再繼續接收的資訊僅有連結狀態表的動態更新。
| 附註： |
|---|
| 您可以停用組織中所有執行 Exchange Server 2003 之伺服器上的 Exchange 路由引擎服務，但通常不建議這樣做。reapi.dll 中的程式碼仍可以使用 Active Directory 中的資訊，來初始化每一部伺服器上的連結狀態表，但是不會對連結狀態表進行動態更新。在此情況下，Exchange Server 2003 會執行靜態的郵件路由作業。 |
連結狀態表是一個小型的、記憶體中的資料庫，它不儲存於磁碟上。若要查看路由引擎在決定路由時所參考的項目，您可以使用 Exchange Server 2003 WinRoute 工具 (Winroute.exe)，此工具可以從 Exchange Server 2003 下載網站 (英文) 下載。
| 附註： |
|---|
| Exchange 2000 Server 亦內附有 WinRoute 工具，不過您最好下載此 Exchange Server 2003 版工具，並在組織內所有的 Exchange 2000 及 Exchange Server 2003 伺服器上使用。 |
WinRoute 工具可連接至選定 Exchange 伺服器上的連結狀態通訊埠 (TCP 通訊埠 691)，並抽選連結狀態表。此表中的資訊是一系列的 GUID 及 ASCII 文字，它們代表路由群組、路由群組成員及路由群組中的連接器。連結狀態表中還包含每一個連接器組態的相關資訊。連結狀態表中的資訊欄位是以括弧隔開，方式如下：
'General Info' ('Routing Group' 'Routing Group Master' 'Version Info' 'Routing Group Addresses' (Routing Group Members) (Connectors in Routing Group (Connector configuration))).
以下是連結狀態表的簡化範例 (除了一個移除的路由群組以外)：
d38082e7c9ecd74dbff32bada8932642 d037d6eaf2fa7cd10934aca433390623 (489416bfa3a4ff459b8f4403f20cad0d 1650c1fe32aef740be236e1089e0da6a 8 0 2 c2da71f9b39ec748aaf44119a2bdcb36 {26}*.489416BF-A3A4-FF45-9B8F-4403F20CAD0D {4c}c=DE;a= ;p=TailspinToys;o=Exchange;cn=489416BF-A3A4-FF45-9B8F-4403F20CAD0D;* {55}/o=TailspinToys/ou=First administrative Group/*/489416BF-A3A4-FF45-9B8F-4403F20CAD0D ( 1650c1fe32aef740be236e1089e0da6a YES 1 1b20 {10}0701000000000101 ) ( aa582d35e9621c4ca8ae57aa33d953a1 ( CONFIG {4}SMTP {} {23}_aa582d35e9621c4ca8ae57aa33d953a1_D {63}/o=TailspinToys/ou=First administrative Group/cn=Configuration/cn=Connections/cn=RGC RG A <-> RG B 0 0 0 0 ffffffff ffffffff 0 1 0 () 0 () 0 () 0 () ARROWS ( {2}RG {20}83bd0e29fad06d4eb8b00faab3265cd5 1 {4}X400 {23}c=DE;a= ;p=TailspinToys;o=Exchange; 1 ) BH () TARGBH ( 766a192b43bfc3459ee85608d65a98a9 CONN_AVAIL {19}server01.TailspinToys.com ) STATE UP)))
(... next routing group... (... next routing members...) (... connectors in routing group (... connector configuration..)))
下表是此資訊在連結狀態表中的對應資訊欄位。
| 欄位 | 值 | 註解 | ||||
|---|---|---|---|---|---|---|
組織 objectGUID |
|
在 Active Directory 中，於 Exchange 組織物件的 objectGUID 屬性中註冊的 GUID。 |
||||
MD5 摘要 |
|
MD5 摘要或雜湊值。此為加密的簽章，代表連結狀態表的版本號碼。根據此資訊，路由引擎可以判定它們是否擁有相同的連結狀態資訊。如果資訊不同，則路由引擎會交換 OrgInfo 封包，以判定哪個伺服器擁有最新資訊。OrgInfo 封包包含連結狀態表，以及路由拓撲的所有詳細資料及狀態。本節後面會討論連結狀態資訊的傳播。 |
||||
路由群組 objectGUID |
|
路由資訊所屬之路由群組物件在 objectGUID 屬性中註冊的 GUID。此 GUID 緊跟在連結狀態表中的下一個 GUID 之後。 |
||||
路由群組主機 objectGUID |
|
在此路由群組中，作為路由群組主機之伺服器的 objectGUID 屬性中註冊的 GUID。 每個路由群組中的路由群組主機負責維護連結狀態資訊，並將該資訊傳達給所有路由群組成員。每個路由群組中僅存在一個路由群組主機。如需路由群組主機之角色的相關資訊，請參閱本節後面的論述。 |
||||
版本資訊 |
|
值 8 0 2 分別是連結狀態資訊的主要、次要及使用者版本。路由引擎使用此版本資訊，來分類連結狀態資訊的更新，如下所示：
其餘資料是此版本資訊的 GUID。 |
||||
路由群組位址 |
|
將 SMTP、X.400、X.500 及位址資訊對應到個別路由群組 GUID。路由引擎使用此資訊，來產生內部伺服器快取，以用於決定路由拓撲中每個伺服器的路由群組。伺服器快取是路由引擎的內部表格。 例如，假設在名為「預設路由群組」的路由群組中，SERVER01 的 FQDN 為 SERVER01.TailspinToys.com。根據路由群組位址定義，路由引擎會在伺服器快取中建立 SERVER01 的項目，如下所示：
在路由事件期間，當進階佇列引擎將 FQDN 傳遞至路由引擎時，路由引擎將查閱伺服器快取，尋找 SERVER01.TailspinToys.com 的項目並迅速判定目標路由群組。X.400 及 X.500 位址亦是如此；只是位址資訊更為複雜。 |
||||
路由群組成員 |
|
包含所有屬於此路由群組的伺服器清單，並識別其狀態。不過，請注意，路由引擎不會將此資訊用於郵件路由。如本節前面所述，路由引擎會使用伺服器快取。 在 Routing Group Members () 清單中列出了路由群組成員，供系統監視。當您在 Exchange 系統管理員中依序開啟 [工具] 節點、[監視及狀態]、[狀態] 時，即可檢視此資訊。 Routing Group Members () 清單中的伺服器狀態項目，包含下列資訊：
使用者資料指出伺服器的狀態。如果值的開頭為 0701，則伺服器可用並處於作業狀態。如果值的開頭為 0702，則伺服器處於警告狀態。如果值的開頭為 0703，則伺服器處於嚴重狀態。 您可以將伺服器切換到維護模式，以暫時取消選取伺服器監視功能，在此情況下，該值的開頭為 0781。 |
||||
路由群組中的連接器 |
|
從下一個左括弧開始，每個屬於該路由群組的連接器都列成一個項目，該項目包括連接器的 objectGUID 及路由引擎用於決定郵件路由的組態資訊。
|
||||
連接器 objectGUID |
|
唯一識別 Exchange 組織中連接器的 GUID。 |
||||
連接器類型 |
|
此欄位接在 CONFIG 關鍵字之後，並可識別連接器類型。類型可為 SMTP、X.400、Notes 或 Exchange 開發套件 (EDK)。Notes 及 EDK 類型是指 MAPI 型郵件連接器的執行個體 (並連接至非 Exchange 郵件系統)。如需 MAPI 型連接器的相關資訊，請參閱閘道郵件連接器結構。
|
||||
來源 Bridgehead 位址 |
|
此欄位可以具有下列三個值中的一個：
|
||||
目的 Bridgehead 位址 |
|
與 [來源 Bridgehead 位址] 欄位相同，此欄位可以具有下列三個值中的一個：
|
||||
傳統辨別名稱 |
|
此為傳統 Exchange 5.5 目錄格式的連接器辨別名稱。該值對應到 Active Directory 中連接器物件的 legacyExchangeDN 屬性。 |
||||
排程識別碼 |
|
[排程識別碼] 欄位未使用，所以永遠設為 0。進階佇列引擎及 Exchange MTA 會查詢 Active Directory，以判定連接器的啟用排程。 |
||||
限制 |
|
[限制] 欄位可識別連接器的領域、郵件大小限制，以及其他限制，如下所示：
|
||||
位址空間 |
|
每一個連接器都至少有一個相關位址空間。路由引擎會使用此資訊，並藉由比對收件者地址與可用位址空間資訊，來判定特定郵件可能的連接器。 在連結狀態表中，ARROWS () 清單包含屬於連接器的個別位址空間。每一個位址空間項目都包含下列三則資訊：
|
||||
來源 Bridgehead |
|
BH 欄位列出連接器的本機 Bridgehead 伺服器及其狀態資訊。Bridgehead 伺服器可以使用下列三則資訊來識別：
|
||||
目的 Bridgehead |
|
與 BH () 清單相同，TARGBH () 清單包含連接器的目的 Bridgehead 伺服器。此清單對於路由群組連接器尤為重要，因為路由群組連接器可以具有多個遠端 Bridgehead 伺服器。 在範例中，下列資訊會識別遠端 Bridgehead 伺服器：
|
||||
狀態 |
|
連接器的狀態。此欄位可以具有兩個可能的值：
連接器狀態繼承自連接器的來源 Bridgehead 伺服器狀態。至少有一個來源 Bridgehead 伺服器可用時 (CONN_AVAIL)，連接器才會是 STATE UP。如果連接器的來源 Bridgehead 虛擬伺服器都不是啟動狀態 (VS_NOT_STARTED)，或來源 Bridgehead 無法建立連線 (CONN_NOT_AVAIL)，則連接器狀態為 STATE DOWN。
|
| 附註： |
|---|
| 如果 WinRoute 工具擁有 Active Directory 的存取權，則該工具可以提供路由拓撲及連結狀態表的直觀檢視，方法是將連結狀態表中的 GUID 解析成您可閱讀的名稱格式。WinRoute 程式視窗的上方窗格會顯示解譯後的資料，中間窗格會列出全部現有位址空間，下方窗格則會顯示連結狀態表的原始資訊。如需 WinRoute 工具的相關資訊，請參閱＜Exchange Server 2003 工具＞ 中的工具下載。 |
在具有多個路由群組的組織中，可能會有不同路由可以到達同一目的地。通常，會將最有效的 (亦即最短或最便宜的) 路由用於郵件傳輸，而其他路由則繼續待命，以防最佳路由暫時無法使用。例如，在下圖所顯示的拓撲中，所有路由群組之間都存在多個傳輸路由。
.gif "b83a8987-67cd-4228-a68b-faf721d763d8")
| 附註： |
|---|
| 郵件路由應當遵循實體網路拓撲。如果基礎網路拓撲是按真正的中樞與支點排列方式 (將路由群組 A 當作中樞) 來設計，則按上圖的方式定義路由群組連接器將毫無意義。相反地，路由群組 B、C、D 及 E 必須直接連接至路由群組 A，且所有路由群組間的郵件傳輸必須透過路由群組 A 來路由。真正的中樞與支點排列方式中，並沒有替代的郵件路徑，因此路由路徑選取是直接的。不過，在本節說明中，假設實體網路拓撲為網狀，並遵循上圖所示之路由群組連接器的排列狀態。 |
路由引擎會使用下列資訊，來判定最佳路由：
位址空間 設定路由群組連接器時，您可以藉由使用連接器內容中的 [已連線的路由群組] 索引標籤，將可能的目的地與郵件連接器建立關聯。不過，路由群組連接器不會提供此索引標籤。因為此連接器僅用於連接至路由群組，所以路由引擎可以從連接器組態來判定路由群組位址空間。
.gif "db861687-48f0-40cf-9e55-4fb6e7224d49")
位址空間可以透過 [位址空間] 索引標籤新增至連接器。如「連結狀態表中的資訊」所示，位址空間是由地址類型 (如 RG、SMTP、X400、MSMAIL 或 CCMAIL)、地址及成本值組成。您指派給位址空間的成本值是一個重要的路由準則。路由引擎會使用 Dijkstra 最短路徑演算法，來做出路由決定。此演算法以成本值為基礎。連接器領域 到外部郵件系統的連接器領域可能會限制在連接器的路由群組，在此情況下，僅會允許連接器本機路由群組中的使用者使用此連接器。所有連接器預設都會具有 [整個組織] 的領域。
附註：路由群組連接器一直可跨整個組織使用。 限制 路由引擎會判定郵件大小、優先順序及郵件類型 (亦即是否是系統郵件)。路由引擎會將這些屬性與可用連接器限制資訊進行比較。然後，它會將那些基於有效連接器限制而無法傳輸郵件的連接器，從可能的連接器清單中排除。
狀態 路由選取處理程序中僅會加入可用連接器。每一個連接器的狀態欄位，會指出連接器可用 (STATE UP) 還是不可用 (STATE DOWN)。
為了選取到目的地的最佳路由，路由引擎會使用 Dijkstra 最短路由演算法，來計算 Exchange 組織中，從來源路由群組到目的地路由群組的最短傳輸路由。然後，路由引擎會判定進階佇列引擎郵件傳輸應使用之最短路由上的下一個躍點。
路由路徑選取處理程序可以分為兩個步驟：
- 進階佇列引擎呼叫路由引擎 IMessageRouter 介面上的 GetMessageType 方法。在 GetMessageType 方法中，進階佇列引擎將郵件以 MailMsg 物件形式傳遞至路由引擎。
在此步驟中，路由引擎會執行下列處理程序：檢查郵件追蹤資訊，以偵測郵件迴圈。如果偵測到郵件迴圈，則會捨棄該郵件，並將 NDR 傳送給寄件者。
閱讀或重新計算 (需要的話) 目前組織拓撲 (亦即，它會判定路由拓撲中，從本機路由群組到所有目的地的最短路由清單)。
檢查並可能會重新整理連結狀態表中有關連接器的限制資訊。
判定組織拓撲中所有連到郵件目的地的連接器，然後分析郵件特性及連接器限制，以排除所有不可用於傳輸郵件的連接器。
計算郵件的篩選值，該值可以唯一定義郵件類型。郵件類型會識別具有類似特性之郵件可以使用的實際路徑。會快取郵件類型。因此，路由引擎不會針對具有類似特性的後續郵件，重新計算篩選值。
附註：進階佇列引擎會為每一郵件類型保持單獨的郵件佇列。 建立相關郵件類型。相關郵件類型與實際郵件類型類似，但是計算時的限制較為寬鬆。如果由於連接器限制，而導致實際郵件類型無法使用傳輸路徑，則相關郵件類型可讓 SMTP 傳輸子系統傳回延伸錯誤碼。
將已快取郵件類型的索引傳回至進階佇列引擎。
- 路由引擎判定最短路由上的下一個躍點。為了完成此步驟，進階佇列引擎會呼叫 IMessageRouter 介面上的 GetMessageType 方法。此時進階佇列引擎所傳送給路由引擎的最重要資訊，就是目的位址及郵件類型 ID。對於 Exchange 組織中的收件者來說，目的位址為收件者主伺服器的 FQDN。路由引擎會從伺服器快取判定目的地路由群組、檢查郵件類型的可用路由，並將到目的地路由群組之路由上的下一個躍點傳回給進階佇列引擎。然後，進階佇列引擎會將郵件傳輸至目的地路由上的下一個躍點。
為了做出正確的路由決定，路由引擎必須知道到達路由拓撲中所有可能目的地的最短路由。在複雜的路由拓撲中，路由引擎必須要找到從所有可用傳輸路由到所有目的地的最短路由。此問題稱為單一來源最短路徑問題。
下圖顯示即使在相當直接的路由拓撲中，從一個路由群組到任何其他路由群組之間可存在許多路由。該圖以簡化形式顯示圖 5.4 的路由群組連接器，其預設成本值為 1。
.gif "0bdc24c5-23dc-4590-b888-f551d15521ad")
1959 年，Edsger Dijkstra 教授解決了單一來源最短路徑問題，他開發了一種演算法，僅經過一次計算，即可找到拓撲中從指定來源到所有點的最短路徑。
這套路由引擎便是使用 Dijkstra 演算法，如下所示：
- 假設路由拓撲為跨越樹狀目錄，代表一個路由群組到所有其他路由群組的所有路徑。這決定拓撲必須包括所有的路由群組及路由群組連接器，且路由群組之間無迴圈。因此，路由拓撲中允許郵件返回來源路由群組的路徑，是無效的傳輸路徑，且不會包括在計算之內。
- 根據 Dijkstra 演算法，路由引擎維護兩組路由群組。第一組包括所有已確定距來源路由群組路徑最短的群組。第二組則包括所有剩餘的路由群組。最初，已確定距來源路由群組路徑最短的一組路由群組是空的。只要存在尚未處理的路由群組，路由引擎便會執行步驟 3 到 6，如下所示。
- 路由引擎會根據距路由群組的目前精確估計距離 (亦即成本值的總和)，來排序剩餘的路由群組。
- 然後它會將距離最近的路由群組，新增到已確定最短路徑的一組路由群組中。
- 然後，路由引擎更新連接至該路由群組之所有路由群組的成本 (如果這可以改進每個剩餘路由群組之最短路徑的精確估計)，方法是將那些路由群組之間連接器的成本值加入距離值。
- 它會更新所有已更新路由群組的前置路由群組。此前置路由群組清單，最終會定義從每個路由群組到目的地路由群組的最短路徑。
下列步驟說明路由引擎如何找出路由群組 A 到路由拓撲中所有其他路由群組的最短路徑：
- 在這個範例中，由於來源為路由群組 A，因此會從路由群組 A 開始計算。路由群組 A 到其自身的距離值為零。所有其他路由群組的距離值則尚未確定。
- 將路由群組 A 新增到已確定距來源路由群組最短路徑的一組路由群組中。然後，與路由群組 A 相鄰之所有路由群組的距離值，都以其連接器的成本值更新。接著更新所有這些鄰近路由群組的前置路由群組 (黑色箭頭的來源)。前置路由群組為路由群組 A。
- 路由引擎根據距路由群組的目前精確估計距離，來排序剩餘的路由群組。它會將距離最近的路由群組新增到已確定最短路徑的一組路由群組中。因為路由群組 B 與 C 具有相同的距離值，所以路由引擎會隨機選取一個路由群組。此範例假設路由引擎選取路由群組 B。
- 路由引擎藉由將路由群組 B 及相鄰路由群組之間連接器的成本值與路由群組 B 的距離值結合，來計算與路由群組 B 相鄰之所有剩餘路由群組的距離值。僅在計算的距離值小於已指派給路由群組的值時，才會更新相鄰路由群組的距離值，接著才會更新前置路由群組 (由黑色箭頭指出)。
路由群組 B 的鄰近群組是路由群組 C、D 及 E。路由群組 C 及 D 目前的距離值尚未定義。因此，以其連接器的成本值來更新其距離值，再加上路由群組 B 的距離值 (1+1)。接著更新所有這些鄰近路由群組的前置路由群組 (黑色箭頭的來源)。前置路由群組為路由群組 B。
未更新路由群組 C，因為路由群組 C 的距離值與連接器成本的總和 (1+1) 大於路由群組 C 目前的距離值。 - 路由引擎根據距路由群組的目前精確估計距離，來排序剩餘的路由群組；將距離最近的路由群組新增到已確定最短路徑的一組路由群組中。演算法現在會選取路由群組 C，因為此路由群組具有最小的距離值。
- 路由引擎藉由將路由群組 C 及相鄰路由群組之間連接器的成本值與路由群組 C 的距離值結合，來計算與路由群組 C 相鄰之所有剩餘路由群組的距離值。僅在計算的距離值小於已指派給路由群組的值時，才會更新相鄰路由群組的距離值，接著才會更新前置路由群組 (由黑色箭頭表示)。
與路由群組 C 剩餘的鄰近路由群組，是路由群組 D 及 E (路由群組 A 及 B 已處理)。
路由群組 D 及 E 目前的距離值為 2。此值小於連接器成本與路由群組 C 距離值的總和 (1+2)。因此，不更新路由群組 D 與 E 的距離值及前置路由群組清單。 - 路由引擎根據距路由群組的目前精確估計距離，來排序剩餘的路由群組 (路由群組 D 及 E)；將距離最近的路由群組新增到已確定最短路徑的一組路由群組中。
因為路由群組 D 與 E 具有相同的距離值，所以路由引擎隨機選取一個路由群組。此範例假設路由引擎選擇路由群組 D。
唯一剩餘的鄰近路由群組為路由群組 E，其距離值為 2。此值小於連接器成本與路由群組 D 距離值的總和 (1+2)。因此，不更新路由群組 E 的距離值及前置路由群組清單。
最後一個尚未新增到已確定最短路徑之路由群組清單的路群組為路由群組 E。無剩餘的相鄰路由群組。此時，便已完成最短路徑的計算。已確定路由群組 A 到拓撲中任何其他路由群組的最短路徑。
如果存在多個具有相同成本值的路徑，則路由引擎會隨機選取一個傳輸路徑，如先前的步驟所示。不過，路由引擎不執行負載平衡。如前所示，路由引擎快取郵件類型資訊，以參照到郵件傳輸到其目的地的最短路徑。因此，即使存在其他具有相同成本值的路徑 (例如，路由群組 A > 路由群組 B > 路由群組 E 及路由群組 A > 路由群組 C > 路由群組 E)，所有同一類型的郵件也會經由同一路徑進行傳輸。
路由群組間的實際負載平衡只可以使用一個具有多個 Bridgehead 伺服器的路由群組連接器所達成。
下表列出您可在路由群組之間使用的負載平衡組態。
| 可能的組態 | 註解 | ||
|---|---|---|---|
單一路由群組連接器具有多個來源或多個目的 Bridgehead 伺服器，或二者兼有。 |
路由引擎會使用這些類型的連接器，將下一個躍點資訊中的連接器 GUID 傳回給進階佇列引擎使用。然後，進階佇列引擎隨機選取必須使用的 Bridgehead 伺服器，從而平衡跨所有 Bridgehead 伺服器的郵件傳輸負載。 如果群組連接器具有多個來源 Bridgehead 伺服器，而郵件到達其中一個來源 Bridgehead 伺服器，則不會將郵件重新路由到任何其他來源 Bridgehead 伺服器。郵件到達路由群組連接器後，便可直接將郵件傳輸到目的地路由群組。因此，信箱位於 Bridgehead 伺服器上的使用者一律會使用本機伺服器，將郵件傳輸至目的地路由群組。
|
||
具有相同位址空間 (或已連線的路由群組)、相同加權 (成本) 的多個連接器，而且每個都具有單一來源及目的 Bridgehead 伺服器 |
在此類型的組態中，並未達到真正的負載平衡。只有選取針對指定郵件類型初始之連接器的情況，才會執行負載平衡。路由引擎會判定郵件類型一次，並快取此資訊，然後透過同一個連接器路由所有相同類型的郵件。僅當第一個連接器失敗，才使用第二個連接器。不過，第二台伺服器可能選取第二個連接器，並透過此方式，達到某種程度的負載平衡。
|
||
具有相同位址空間 (或已連線的路由群組)、不同加權 (成本) 的多個連接器，而且每個都具有單一來源及目的 Bridgehead 伺服器 |
如果您想要設定連接器自動容錯移轉，則可在不同的 Bridgehead 伺服器上建立兩個個別連接器，它們各有不同的主機。連接器的連結狀態是由其本機 Bridgehead 伺服器來決定。如果慣用連接器 (具有最低成本) 上的 Bridgehead 伺服器無法使用，即會將連接器視為無法使用，而且路由會自動選擇第二個連接器。當控管具有最低成本的連接器之 Bridgehead 伺服器變成可用時，Exchange 伺服器就會開始重新使用它。 |
根據此案例，有一些方法可以達到跨 SMTP 連接器的負載平衡。
- 如果想要跨傳送組織中的多台伺服器進行輸出要求的負載平衡，可設定多個來源 Bridgehead。
- 如果想要跨多台目的伺服器進行流量的負載平衡，可請目的地系統管理員正確設定 DNS (使用 MX 及 A 記錄的適合組態)，或是在連接器上指定多個智慧主機位址。
或者，如果想要確定容錯移轉回復性，可建立多個範圍設為相同位址空間、不同成本及不同來源 Bridgehead 的 SMTP 連接器。如果慣用連接器 (具有最低成本) 上的 Bridgehead 伺服器無法使用，則會將連接器視為無法使用，而且路由會自動選擇第二個連接器。如果您使用兩個具有相同成本的連接器，則 Exchange 伺服器會隨機選取要使用的 Bridgehead 伺服器及連接器。如果後來此 Bridgehead 伺服器變成無法使用，則他們會容錯移轉至第二個連接器。不過，當第一個 Bridgehead 伺服器又變成可用後，這些伺服器並不會再錯誤後回復到此伺服器，因為此路由與他們已經使用的伺服器具有相同成本。
例如，對於容錯移轉組態而言，下圖中的連接器組態不是負載平衡的，因為位址空間不相符。傳送到 .NET 網域中之外部使用者的郵件，一定會透過具有 .NET 位址空間的 SMTP 連接器傳送。這是因為路由引擎會先選擇最詳細的地址，再評估成本。
.gif "7de23cb6-9bd9-43b1-b725-90ce114b2c4e")
| 附註： |
|---|
| 如果具有 *.NET 位址空間的連接器存在限制，而這些限制讓特定郵件無法穿越此連接器 (例如，因為拒絕寄件者透過此連接器傳輸郵件)，則路由引擎會將郵件傳回給具有 NDR 的寄件者。路由引擎不利用第二個連接器來傳輸這些郵件。最詳細的位址空間決定用於傳輸郵件的連接器。會將位址空間較不詳細的連接器從路由計算中排除。 |
如果連接器無法傳輸郵件，則進階佇列引擎會通知路由引擎連結失敗。這會導致路由引擎將連接器標示為關閉，在此情況下，所有佇列郵件都會重新路由。
如果滿足下列其中一個條件，則路由引擎會將連接器視為關閉狀態：
- 路由引擎無法與連接器的至少一個來源 Bridgehead 伺服器建立連線，且路由群組主機與來源 Bridgehead 伺服器之間不存在通訊埠 691 的 TCP/IP 連線。無法使用的來源 Bridgehead 伺服器在連結狀態表中標示為 VS_NOT_STARTED。
- 來源 Bridgehead 伺服器均無法將郵件成功傳輸到目的 Bridgehead 伺服器。無法將郵件傳輸到目的地的來源 Bridgehead 伺服器標示為 CONN_NOT_AVAIL。
| 附註： |
|---|
| 如果使用 X.400 連接器，而該連接器無法傳輸郵件，則 Exchange MTA 會通知路由群組發生連結失敗的狀況。來源 Bridgehead 伺服器的狀態即為 CONN_NOT_AVAIL。X.400 連接器只能擁有一個來源 Bridgehead 伺服器。 |
為了保證有效的郵件傳輸，路由引擎會立即通知進階佇列引擎及 Exchange MTA 任何關於連結狀態的變更。為了避免以中斷的路徑傳送郵件，必須重新路由所有佇列郵件。此處理程序稱為重新路由。在重新路由中，進階佇列引擎會捨棄所有快取的下一個躍點資訊，因為此資訊不再有效。目前等待傳輸的每一封郵件，都會被再次傳遞至路由引擎，以重新計算下一個躍點。這是一項耗費資源的工作。
下圖顯示重新路由範例，其中路由群組 E 的 Bridgehead 伺服器為關閉狀態。目前尚無郵件可到達此路由群組。路由引擎為傳送到路由群組 E 中收件者的郵件重新計算最短路徑時，會發現無可用的路徑。標示為關閉的連接器已從路由處理程序中排除。因此，路由群組 E 目前處於隔離狀態。
.gif "3e7b77fb-c3c7-47c4-8961-8a3ea10d7581")
因為不存在有效的路徑，所以路由引擎無法為等待傳輸到路由群組 E 的郵件判定下一個有效的躍點。路由引擎會在下一個躍點類型資訊中，通知進階佇列引擎目前無法到達下一個躍點。進階佇列引擎必須保留郵件，直到至少有一個傳輸路徑可用為止，或直到郵件過期連同 NDR 一起傳回給寄件者為止。
| 附註： |
|---|
| 如果路由群組只存在一個連接器，且無替代路徑，則連結狀態會一直標示為可用，以減少路由拓撲中連結狀態變更的次數。Exchange Server 2003 將郵件放入佇列並在路由再次可用時進行傳送。 |
與負載平衡相同，Exchange Server 2003 僅透過具有相同位址空間的連接器重新路由郵件。例如，您可以在不同的 Bridgehead 伺服器上建立兩個不同的連接器，它們具有相同位址空間，但是成本不同。如果常用的連接器無法使用，則路由引擎會自動選取第二個連接器，直到主要連接器再次可用為止。
| 附註： |
|---|
| 路由引擎不會將郵件從具有特定位址空間的連接器重新路由到位址空間較不明確的連接器，因為路由引擎會將後者視為不同之目的地。在具有詳細位址空間的連接器可用之前，郵件將保留在來源 Bridgehead 伺服器上。 |
如果具有 *.NET 位址空間的連接器存在限制，而這些限制讓特定郵件無法穿越此連接器 (例如，因為拒絕寄件者透過此連接器傳輸郵件)，則路由引擎會將郵件傳回給具有 NDR 的寄件者。路由引擎不利用第二個連接器來傳輸這些郵件。最詳細的位址空間決定用於傳輸郵件的連接器。位址空間較不詳細的連接器將會從路由計算中排除。
路由引擎以下列其中一種方式，判定連接器是否再次可用：
- VS_NOT_STARTED 路由群組主機在來源 Bridgehead 伺服器上建立到 TCP 通訊埠 691 的連線。來源 Bridgehead 伺服器會標示為 CONN_AVAIL。因為至少有一個來源 Bridgehead 伺服器可供連接器使用，所以連接器狀態會切換至 STATE UP。
- CONN_NOT_AVAIL 對於無法使用的連接器，即使沒有郵件等待傳輸，來源 Bridgehead 伺服器亦會繼續重試連線 (間隔 60 秒)。建立連線時，進階佇列引擎或 Exchange MTA 向路由引擎報告從來源 Bridgehead 伺服器成功輸出連線。然後，路由引擎會將來源 Bridgehead 伺服器切換至 CONN_AVAIL，並將連接器切換至 STATE UP。
您可以為所有類型的連接器設定排程，以便在特定時間傳輸電子郵件。連接器可以設定為一直處於作用中、僅在特定時間處於作用中，或永不處於作用中；在最後一個情況中，除非連接器排程有所變更，否則連接器不會傳輸郵件。您還可以將連接器設定為遠端啟動，這表示連接器不會自行啟動連線。相反的，它會等待遠端伺服器連線再觸發郵件傳輸。
連接器排程僅會影響郵件傳輸。郵件路由並不受到影響。只要連接器的狀態為 STATE UP，則無論該連接器的排程類型為何，路由引擎均會將該連接器視為可用狀態。因此，甚至可以將郵件路由到啟用排程設定為「永不」的連接器。這些連接器不會發生連結狀態變更及重新路由。郵件會在連接器的佇列中等待，直到變更啟用排程為止。遠端啟動的連接器亦是如此。不會重新路由等待擷取的郵件。
.gif "tip") 秘訣： |
|---|
| 如果您要避免將郵件路由到連接器，請將連接器的郵件大小上限設為 1 KB。 |