陰影備援

適用於：Exchange Server 2013

陰影備援是在 2010 年 Microsoft Exchange Server導入，可在訊息傳遞至信箱之前提供備援的訊息複本。 在 Exchange 2010 中，陰影備援延遲從傳輸伺服器上的傳輸資料庫刪除訊息，直到伺服器驗證訊息傳遞路徑中的下一個躍點已完成傳遞為止。 如果下一個躍點在回報成功傳遞回傳輸伺服器之前失敗，傳輸伺服器會將訊息重新提交至下一個躍點。 Exchange 2010 伺服器使用 XSHADOW 動詞來公告其陰影備援支援。 如果 SMTP 伺服器不支援陰影備援，Exchange 2010 會根據接收連接器上設定的時間間隔，使用延遲通知來建立訊息的備援複本。

在 Microsoft Exchange Server 2013 中陰影備援的主要改善是，傳輸伺服器現在會先備援所接收的任何訊息複本，再確認已成功將訊息接收回傳送伺服器。 傳送伺服器對陰影備援的支援或缺乏支援並不重要。 這有助於確保 Exchange 2013 傳輸管線中的所有訊息在傳輸時都會變成備援。 如果 Exchange 2013 判斷原始訊息在傳輸過程中遺失，則會重新傳遞訊息的備援複本。

陰影備援元件

下表描述陰影備援的元件。 這些詞彙會在整個主題中使用。

陰影備援的需求

雖然看起來很明顯，但陰影備援需要多部 Exchange 2013 信箱伺服器。 信箱伺服器可以是獨立伺服器，或是安裝在同一部電腦上的信箱伺服器和用戶端存取伺服器。

• 如果信箱伺服器不是 DAG 的成員，則其他信箱伺服器必須位於本機 Active Directory 網站。
• 如果信箱伺服器是 DAG 的成員，則其他信箱伺服器必須屬於相同的 DAG。 屬於 DAG 的其他信箱伺服器可以位於本機 Active Directory 網站或遠端 Active Directory 月臺中。 如果 DAG 跨越多個 Active Directory 月臺，陰影備援會偏好在遠端 Active Directory 月臺中建立訊息的備援複本，以進行月臺復原。

以下是陰影備援無法保護傳輸中訊息的情況：

• 在單一 Exchange 伺服器環境中。
• 在布建不足的 DAG 中。
• 在涉及訊息陰影備援的兩部或多部傳輸伺服器同時失敗期間。

預設會啟用陰影備援

根據預設，在Set-TransportConfig Cmdlet 上使用ShadowRedundancyEnabled參數，在所有信箱伺服器上的傳輸服務中全域啟用陰影備援。 根據預設，如果信箱伺服器上的傳輸服務無法建立訊息的備援複本，則不會拒絕郵件。 不過，如果未使用Set-TransportConfigCmdlet 上的 RejectMessageOnShadowFailure參數來建立訊息的備援複本，您可以將 Exchange 2013 設定為拒絕訊息。 訊息因暫時性失敗而遭拒，但傳送伺服器可以再次傳輸訊息。 SMTP 回應碼是 451 4.4.0 Message failed to be made redundant. [您應該設定 Exchange 2013] 來拒絕只有當您的組織有多個可用的 Exchange 2013 信箱伺服器時，才能備援的郵件。

下表描述啟用陰影備援的參數。

啟用陰影備援的參數

如何建立陰影訊息

陰影備援的主要目標是在訊息傳輸時，一律在傳輸高可用性界限內擁有兩份訊息複本。 訊息備援複本的建立位置和時間取決於訊息的來源和來源。 有三個主要決定因素：

• 從傳輸高可用性界限外部接收的訊息。
• 在傳輸高可用性界限外傳送的訊息。
• 從信箱傳輸提交服務從傳輸高可用性界限內的信箱伺服器接收到的訊息。

傳輸高可用性界限是下列其中一項：

• DAG，適用于屬於 DAG 成員的信箱伺服器。 這包括跨越多個 Active Directory 網站的 DAG。
• Active Directory 網站，適用于不屬於 DAG 的信箱伺服器。

陰影備援永遠不會跨傳輸高可用性界限追蹤陰影訊息。 當訊息跨越傳輸高可用性界限時，陰影備援會開始或重新開機。 這可減少陰影訊息維護流量，並防止陰影訊息重新提交跨傳輸高可用性界限發生。 Exchange 2010 Hub Transport Server 是特殊案例，稍後會在本主題中討論。

從傳輸高可用性界限外部接收的訊息

當 Exchange 2013 信箱伺服器上的傳輸服務收到來自傳輸高可用性界限外部的訊息時，信箱伺服器並不在意傳送伺服器支援或缺乏陰影備援的支援。 只要啟用陰影備援，接收訊息的信箱伺服器就會在傳輸高可用性界限內的另一部信箱伺服器上建立訊息的備援複本，然後才確認接收回傳送伺服器的郵件。 以下是程式運作方式的範例：

1. SMTP 伺服器會將訊息傳輸至信箱伺服器上的傳輸服務。 信箱伺服器是主伺服器，而訊息是主要訊息。

2. 雖然與 SMTP 伺服器的原始 SMTP 會話仍在使用中，但是主伺服器上的傳輸服務會開啟新的同時 SMTP 會話，並在組織中不同的信箱伺服器上與 Transport 服務一起開啟，以建立訊息的備援複本。

   • 如果主伺服器是 DAG 的成員，主伺服器會連線到相同 DAG 中不同的信箱伺服器。 如果 DAG 跨越多個 Active Directory 網站，預設會偏好使用不同 Active Directory 網站中的信箱伺服器。 此設定是由Set-TransportService Cmdlet 上的ShadowMessagePreference參數所控制。 預設值為 PreferRemote ，但您可以將它變更為 RemoteOnly 或 LocalOnly 。
   • 如果主伺服器不是 DAG 的成員，無論 ShadowMessagePreference 參數的值為何，主伺服器都會連線到相同 Active Directory 月臺中的不同信箱伺服器。

3. 主伺服器會將訊息的複本傳輸到其他信箱伺服器上的傳輸服務，而其他信箱伺服器上的傳輸服務則確認已成功建立郵件複本。 訊息的複本是陰影訊息，而保存它的信箱伺服器則是主伺服器的陰影伺服器。 訊息存在於陰影伺服器的陰影佇列中。

4. 主伺服器收到來自陰影伺服器的認可之後，主伺服器會認可接收到原始 SMTP 會話中原始 SMTP 伺服器的主要訊息，且 SMTP 會話已關閉。

在傳輸高可用性界限外傳送的訊息

當 Exchange 2013 傳輸伺服器在傳輸高可用性界限外傳輸訊息，而另一端的 SMTP 伺服器認可成功接收訊息時，傳輸伺服器會將訊息移至 Safety Net。 成功跨傳輸高可用性界限傳輸主要訊息之後，就無法從安全網重新提交訊息。 如需 Safety Net 的詳細資訊，請參閱 Safety Net。

傳輸高可用性界限內傳輸的訊息

郵件路由已在 Exchange 2013 中優化，因此當最終目的地位於 DAG 或 Active Directory 網站時，通常不需要該 DAG 或 Active Directory 月臺中信箱伺服器上傳輸服務之間的多個躍點。 在保存郵件最終目的地之 DAG 或 Active Directory 網站上的信箱伺服器上，傳輸服務接受郵件之後，郵件的下一個躍點通常是最終目的地本身。 當 DAG 或 Active Directory 網站內的任何位置都存在訊息的一個陰影複製時，陰影備援的目標就是在傳輸中保留兩份訊息複本。 一般而言，只有 DAG 中需要 Redirect-Message Cmdlet 以清空信箱伺服器上作用中佇列的容錯移轉案例，才需要相同傳輸高可用性界限內的多個躍點。

在相同 Active Directory 月臺中使用 Exchange 2010 中樞傳輸伺服器的陰影備援

當 Exchange 2010 Hub Transport Server 將訊息傳輸至相同 Active Directory 網站中的 Exchange 2013 信箱伺服器時，Exchange 2010 中樞傳輸伺服器會使用 XSHADOW 命令公告陰影備援的支援，但信箱伺服器不會公告陰影備援的支援。 這可防止 Exchange 2010 Hub Transport Server 在 Exchange 2013 信箱伺服器上建立訊息的陰影複製。

當 Exchange 2013 信箱伺服器上的傳輸服務將訊息傳輸至相同 Active Directory 網站中的 Exchange 2010 中樞傳輸時，Exchange 2013 信箱伺服器會遮蔽 Exchange 2010 Hub Transport Server 的訊息。 在 Exchange 2013 信箱伺服器收到來自 Exchange 2010 Hub Transport Server 的確認訊息已成功接收之後，Exchange 2013 信箱伺服器會將已成功處理的郵件移至安全網。 不過，Exchange 2013 信箱儲存在 Safety Net 中成功處理的郵件永遠不會重新提交至 Exchange 2010 中樞傳輸伺服器。

SMTP 逾時

嘗試建立訊息的備援複本期間，傳送 SMTP 伺服器與主伺服器之間的 SMTP 連線，或主伺服器與陰影伺服器之間的 SMTP 會話可能會逾時。 當資料實際在連接器上傳輸時，接收連接器和傳送連接器都有 ConnectionInactivityTimeOut 參數。 接收連接器也有絕對 ConnectionTimeOut 參數。

如果在成功建立並認可訊息陰影複製之前，任何 SMTP 會話逾時，結果會由Set-TransportConfig Cmdlet 上的RejectMessageOnShadowFailure參數控制。 根據預設，此參數的值為 $false ，這表示不需建立陰影複製，就會接受主要訊息。 如果此參數的值為 $true ，則會拒絕主要訊息，並出現暫時性錯誤 451 4.4.0 。

如果成功建立訊息的陰影複製，但傳送 SMTP 伺服器與主伺服器之間的 SMTP 會話逾時，主伺服器會接受並處理主要訊息。 傳送的 SMTP 伺服器會重新傳遞未確認的訊息，但重複的訊息偵測會防止 Exchange 信箱使用者看到重複的郵件。 當傳送 SMTP 伺服器重新提交訊息時，主伺服器會建立另一個訊息的陰影複本。 傳送 SMTP 伺服器在訊息重新提交期間建立的陰影訊息之間沒有任何關聯性。

下表描述控制陰影訊息建立的參數

陰影訊息建立參數

如何維護陰影訊息

成功建立陰影訊息之後，陰影備援的工作才剛開始。 主伺服器和陰影伺服器必須彼此保持聯繫，才能追蹤訊息的進度。

當主伺服器成功將訊息傳輸到下一個躍點，而下一個躍點認可收到訊息時，主伺服器會在傳遞完成時更新訊息的 捨棄狀態 。 捨棄狀態基本上是包含受監視訊息清單的訊息。 成功傳遞的訊息不需要保留在陰影佇列中，因此，一旦陰影伺服器知道主伺服器已成功將訊息傳輸到下一個躍點，陰影伺服器就會將陰影訊息從陰影佇列移至 Safety Net。

陰影伺服器會藉由查詢主伺服器來判斷陰影佇列中陰影訊息的捨棄狀態。 如果陰影伺服器因為任何原因而開啟與主伺服器的 SMTP 會話，包括傳輸其他不相關的訊息，陰影伺服器會發出 XQDISCARD 命令來判斷主要訊息的捨棄狀態。 如果陰影伺服器在預先設定的時間間隔之後尚未開啟與主伺服器的 SMTP 會話，陰影伺服器將會開啟與主伺服器的 SMTP 會話，併發出 XQDISCARD 命令。 時間間隔是由Set-TransportConfig Cmdlet 上的ShadowHeartbeatFrequency參數所控制。 預設值為 2 分鐘。 在陰影伺服器開啟與主伺服器的 SMTP 會話之後，主伺服器會回應套用至查詢陰影伺服器之訊息 的捨棄通知 。 在 Exchange 2013 中，捨棄通知會儲存在磁片上，而不是儲存在記憶體中。 因此，如果 Microsoft Exchange Transport 服務重新開機，就會保存捨棄通知。 服務啟動之後，主伺服器仍然知道它已成功處理的訊息，而且該資訊可供陰影伺服器使用。

陰影伺服器與主伺服器之間的 SMTP 通訊會作為決定伺服器可用性 的活動訊號 。 如果陰影伺服器在預先設定的時間間隔之後無法開啟與主伺服器的 SMTP 會話，或主伺服器的傳輸資料庫有不同的資料庫識別碼，陰影伺服器會將本身提升為主伺服器、將陰影訊息升階為主要訊息，並將訊息傳輸到下一個躍點。 時間間隔是由Set-TransportConfig Cmdlet 上的ShadowResubmitTimeSpan參數所控制。 預設值為 3 小時。

陰影備援管理員 是負責管理陰影備援之 Exchange 2013 傳輸伺服器的核心元件。 陰影備援管理員負責維護伺服器目前正在處理之所有主要訊息的下列資訊：

• 正在處理之每個主要訊息的陰影伺服器。
• 要傳送至陰影伺服器的捨棄狀態。

陰影備援管理員會針對陰影伺服器在其陰影佇列中擁有的所有陰影訊息負責下列事項：

• 維護每個陰影訊息的主伺服器清單。
• 比較儲存訊息主要複本之佇列資料庫的原始資料庫識別碼和目前資料庫識別碼。
• 檢查陰影訊息排入佇列的每部主伺服器的可用性。
• 處理從主伺服器捨棄通知。
• 在收到所有預期的捨棄通知之後，從陰影佇列中移除陰影訊息。
• 決定陰影伺服器何時應取得陰影訊息的擁有權，成為主伺服器。
• 追蹤訊息迴圈和其他副作用訊息，例如傳遞狀態通知 (DSN) 和日誌報告，以確認在完整處理訊息的所有分支之前，不會釋放訊息的備援複本。

下表描述控制陰影訊息維護方式的參數。

中斷後的訊息處理

陰影備援可將伺服器中斷所造成的訊息遺失降至最低。 當傳輸伺服器在中斷後重新上線時，有兩種情況：

• 伺服器使用新的傳輸資料庫重新上線：在此案例中，傳輸資料庫因為資料損毀或硬體故障而無法復原。 在此情況下，因為傳輸伺服器會有新的資料庫識別碼，所以組織中的其他傳輸伺服器會將它辨識為新的路由。 這也適用于無法復原伺服器，且已布建新的伺服器做為取代的情況。

• 伺服器使用相同的傳輸資料庫重新上線：在此案例中，特定傳輸伺服器不會失敗，但離線時間夠長，讓陰影伺服器能夠假設訊息的擁有權並重新提交。 例如，網路卡故障或伺服器上的長時間維護會導致此案例。

下表摘要說明陰影備援如何回應這兩個案例。 為了清楚起見，假設發生中斷的伺服器名為 Mailbox01。

復原案例中的訊息處理