共用方式為

陰影備援

  • 發行項

適用於：Exchange Server 2013

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

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

陰影備援元件

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

術語 描述
傳輸伺服器 具有訊息佇列且負責路由傳送訊息的 Exchange 伺服器。 在 Exchange 2013 中，傳輸伺服器是信箱伺服器上的傳輸服務 (信箱伺服器) 。
傳輸資料庫 Exchange 2013 傳輸伺服器上的訊息佇列資料庫。 陰影佇列和安全網也會儲存在傳輸資料庫中。
傳輸高可用性界限 資料庫可用性群組 (DAG 環境中的 DAG) ，或非 DAG 環境中的 Active Directory 月臺。 當訊息抵達傳輸高可用性界限中的傳輸伺服器時，Exchange 會嘗試在界限內的傳輸伺服器上維護 2 個備援的訊息複本。 當訊息離開傳輸高可用性界限時，Exchange 會停止維護訊息的備援複本。
主要訊息 送出至傳輸管線以進行傳遞的訊息。
陰影訊息 陰影伺服器保留之訊息的備援複本，直到確認主伺服器已成功處理主要訊息為止。
主伺服器 目前正在處理主要訊息的傳輸伺服器。
陰影伺服器 保存主伺服器陰影訊息的傳輸伺服器。 傳輸伺服器可能是某些訊息的主伺服器，而陰影伺服器則是其他訊息的同時伺服器。
陰影佇列 陰影伺服器儲存陰影訊息的傳遞佇列。 對於具有多個收件者的郵件，主要訊息的每個下一個躍點都需要個別的陰影佇列。
捨棄狀態 傳輸伺服器針對陰影訊息維護的資訊，指出已成功處理主要訊息。
捨棄通知 陰影伺服器從主伺服器接收的回應，指出陰影訊息已準備好要捨棄。
安全網 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 信箱伺服器時，才能備援的郵件。

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

啟用陰影備援的參數

參數 預設值 描述
Set-TransportConfig上的ShadowRedundancyEnabled $true
  • $true 在組織中的所有傳輸伺服器上啟用陰影備援。
  • $false 停用組織中所有傳輸伺服器上的陰影備援。
Set-TransportConfig上的RejectMessageOnShadowFailure $false
  • $false：無法建立訊息的陰影複製時，組織中的傳輸伺服器還是會接受主要訊息。 這些訊息在傳輸中時不會重複保存。
  • $true：在成功建立訊息的陰影複製之前，組織中的任何傳輸伺服器不會接受或認可任何訊息。 如果無法建立訊息的陰影複製，則會拒絕主要訊息並出現暫時性錯誤。 組織中的所有訊息都會在傳輸中時重複保存。

    只有在 DAG 或 Active Directory 網站中有多個 Exchange 2013 信箱伺服器可以建立郵件的陰影複本時，才應該將此值 $true 設定為 。

只有當 ShadowRedundancyEnabled 為 時，這個參數才有 $true 意義。

如何建立陰影訊息

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

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

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

  • 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 伺服器在訊息重新提交期間建立的陰影訊息之間沒有任何關聯性。

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

陰影訊息建立參數

來源 預設值 描述
Set-TransportConfig上的ShadowMessagePreferenceSetting PreferRemote
  • PreferRemote：嘗試在不同 Active Directory 網站的信箱伺服器上製作郵件的陰影複本。 如果作業失敗，請嘗試在本機 Active Directory 月臺的伺服器上製作訊息的陰影複製。
  • LocalOnly：訊息的陰影複製應該只在本機 Active Directory 月臺的傳輸伺服器上進行。
  • RemoteOnly：訊息的陰影複製應該只在不同 Active Directory 月臺的傳輸伺服器上建立。

只有當嘗試製作郵件陰影複製的主伺服器是跨多個 Active Directory 網站之 DAG 成員的信箱伺服器時，這個參數才有意義。
Set-TransportConfig上的MaxRetriesForRemoteSiteShadow 4 當信箱伺服器是跨多個 Active Directory 網站的 DAG 成員時，就會使用此參數。
  • 如果 ShadowMessagePreferenceSetting 設定為 PreferRemote ，則信箱伺服器會先嘗試在遠端 Active Directory 網站的另一部信箱伺服器上建立郵件的陰影複製，最多可達 MaxRetriesForRemoteSiteShadow所指定的次數。 如果失敗，信箱伺服器會嘗試在本機 Active Directory 網站的不同信箱伺服器上建立郵件的陰影複本，最多可達 MaxRetriesForLocalSiteShadow所指定的次數。
  • 如果 ShadowMessagePreferenceSetting 設定為 RemoteOnly ，信箱伺服器只會嘗試在遠端 Active Directory 網站的信箱伺服器上建立郵件的陰影複本，最多可達 MaxRetriesForRemoteSiteShadow所指定的次數。
  • 此

當無法成功建立訊息的陰影複製時：

  • 如果 RejectMessageOnShadowFailure 為 $true ，則會拒絕主要訊息並出現暫時性錯誤。
  • 如果 RejectMessageOnShadowFailure 是 $false ，則還是會接受主要訊息，但不會重複保存。
Set-TransportConfig上的MaxRetriesForLocalSiteShadow 2 此參數會在下列情況下使用：
  • 如果信箱伺服器是跨多個 Active Directory 網站的 DAG 成員。
    1. 如果 ShadowMessagePreferenceSetting 設定為 PreferRemote ，則信箱伺服器會先嘗試在遠端 Active Directory 網站的另一部信箱伺服器上建立郵件的陰影複製，最多可達 MaxRetriesForRemoteSiteShadow所指定的次數。 如果失敗，信箱伺服器會嘗試在本機 Active Directory 網站的不同信箱伺服器上建立郵件的陰影複本，最多可達 MaxRetriesForLocalSiteShadow所指定的次數。
    2. 如果 ShadowMessagePreferenceSetting 設定為 LocalOnly ，信箱伺服器只會嘗試在本機 Active Directory 網站的不同信箱伺服器上建立郵件的陰影複製，最多可達 MaxRetriesForLocalSiteShadow所指定的次數。
  • 如果信箱伺服器不是 DAG 的成員，或如果信箱伺服器是位於一個 Active Directory 網站之 DAG 的成員，信箱伺服器只會嘗試在本機 Active Directory 網站的不同信箱伺服器上建立郵件的陰影複本，最多可達 MaxRetriesForLocalSiteShadow所指定的次數。

當無法成功建立訊息的陰影複製時：

  • 如果 RejectMessageOnShadowFailure 為 $true ，則會拒絕主要訊息並出現暫時性錯誤。
  • 如果 RejectMessageOnShadowFailure 是 $false ，則還是會接受主要訊息，但不會重複保存。
Set-ReceiveConnector上的ConnectionInactivityTimeout 在郵件伺服器上傳輸服務的 5 分鐘

在用戶端存取伺服器上前端傳輸服務的 5 分鐘。

邊際傳輸伺服器上的 1 分鐘。		 此參數指定在關閉連線之前，與來源郵件伺服器的開啟 SMTP 連線可以持續閒置的時間上限。 這個參數的值必須小於 ConnectionTimeout 參數所指定的值。
Set-ReceiveConnector上的ConnectionTimeout 在郵件伺服器上傳輸服務的 10 分鐘

在用戶端存取伺服器上前端傳輸服務的 10 分鐘。

邊際傳輸伺服器上的 5 分鐘。		 此參數指定與來源郵件伺服器的 SMTP 連線可以持續開啟的時間上限 (即使來源郵件伺服器正在傳輸資料)。 這個參數的值必須大於 ConnectionInactivityTimeout 參數所指定的值。
Set-SendConnector上的ConnectionInactivityTimeOut 10 分鐘 此參數指定在關閉連線之前，與目的郵件伺服器的開啟 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) 和日誌報告，以確認在完整處理訊息的所有分支之前，不會釋放訊息的備援複本。

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

參數 預設值 描述
Set-TransportConfig上的ShadowHeartbeatFrequency 2 分鐘 陰影伺服器在開啟與主伺服器的 SMTP 連線之前等待的時間上限，以檢查訊息的捨棄狀態。
Set-TransportConfig上的ShadowResubmitTimeSpan 3 小時 伺服器在決定主伺服器失敗之前等待多久，並假設無法連線主伺服器的陰影佇列中有陰影訊息的擁有權。
Set-TransportConfig上的ShadowMessageAutoDiscardInterval 2 天 伺服器保留捨棄事件的時間長度，以便成功傳遞訊息。 主伺服器佇列會捨棄事件，直到陰影伺服器查詢為止。 不過，如果陰影伺服器未在此參數中指定的持續時間內查詢主伺服器，主伺服器就會刪除佇列捨棄事件。
Set-TransportConfig上的SafetyNetHoldTime 2 天 成功處理的訊息會保留在 Safety Net 中多久。 在Set-TransportService上SafetyNetHoldTime和MessageExpirationTimeout的總和之後，未認可的陰影訊息最終會從 Safety Net 過期。
Set-TransportService上的MessageExpirationTimeout 2 天 訊息在到期之前，可以在佇列中保留多久的時間。

中斷後的訊息處理

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

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

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

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

復原案例中的訊息處理

復原案例 採取的動作
Mailbox01 會使用新的資料庫重新上線。 當 Mailbox01 變成無法使用時，每部針對 Mailbox01 排入陰影訊息的伺服器都會假設這些訊息的擁有權，並重新提交這些郵件。 訊息接著會傳遞至其目的地。

訊息的延遲上限是Set-TransportConfig Cmdlet 上ShadowHeartbeatFrequency參數的值。 預設值為 2 分鐘。
Mailbox01 使用相同的資料庫重新上線。 在 Mailbox01 重新上線之後，它會在其佇列中傳遞郵件，這些訊息已由保存 Mailbox01 訊息陰影複本的伺服器所傳遞。 這會導致這些訊息的傳遞重複。 Exchange 信箱使用者不會因為重複的郵件偵測而看到重複的郵件。 不過，非 Exchange 傳訊系統上的收件者可能會收到重複的訊息複本。

訊息的延遲上限是Set-TransportConfig Cmdlet 上ShadowResubmitTimeSpan參數的值。 預設值為 3 小時。