Теневая избыточность

Область применения: Exchange Server 2013

Теневое избыточние было введено в Microsoft Exchange Server 2010 для предоставления избыточных копий сообщений перед их доставкой в почтовые ящики. В Exchange 2010 теневая избыточность задерживала удаление сообщения из транспортной базы данных на транспортном сервере до тех пор, пока сервер не убедится, что следующий переход на пути доставки сообщения завершен. Если следующий переход завершался ошибкой до сообщения об успешной доставке транспортному серверу, транспортный сервер повторно отправлял сообщение этому следующему скачку. Серверы Exchange 2010 использовали глагол XSHADOW для объявления своей поддержки теневой избыточности. Если SMTP-сервер не поддерживал теневое резервирование, Exchange 2010 использовал отложенное подтверждение на основе заданного интервала времени в соединителе получения для создания избыточной копии сообщения.

Основным улучшением теневой избыточности в Microsoft Exchange Server 2013 является то, что транспортный сервер теперь создает избыточную копию всех сообщений, которые он получает, прежде чем подтвердить успешное получение сообщения обратно на отправляющий сервер. Поддержка или отсутствие поддержки теневой избыточности сервером-отправителем не имеет значения. Это позволяет сделать все сообщения в транспортном конвейере Exchange 2013 избыточными во время их перемещения. Если Exchange 2013 определяет, что исходное сообщение было потеряно при перемещении, избыточная копия сообщения доставляется повторно.

Компоненты теневого резервирования

В следующей таблице описаны компоненты теневой избыточности. Эти термины используются во всей статье.

Термин	Описание
Транспортный сервер	Сервер Exchange с очередями сообщений, отвечающий за маршрутизацию сообщений. В Exchange 2013 транспортным сервером является сервер почтовых ящиков (транспортная служба на сервере почтовых ящиков).
База данных о транспорте	База данных очереди сообщений на транспортном сервере Exchange 2013. Теневые очереди и сеть безопасности также хранятся в транспортной базе данных.
Граница высокой доступности транспорта	Группа доступности баз данных (DAG) в средах DAG или сайт Active Directory в средах, отличных от DAG. Когда сообщение поступает на транспортный сервер в границу высокой доступности транспорта, Exchange пытается сохранить две избыточные копии сообщения на транспортных серверах в пределах границы. Когда сообщение покидает границу высокой доступности транспорта, Exchange прекращает поддерживать избыточные копии сообщения.
Основное сообщение	Сообщение, отправленное в транспортный конвейер для доставки.
Теневое сообщение	Избыточная копия сообщения, которую теневой сервер сохраняет, пока не убедится, что основное сообщение было успешно обработано основным сервером.
Основной сервер	Транспортный сервер, который в данный момент обрабатывает основное сообщение.
Теневой сервер	Транспортный сервер, на котором хранится теневой сервер для основного сервера. Транспортный сервер может быть основным сервером для некоторых сообщений и теневым сервером для других сообщений одновременно.
Теневая очередь	Очередь доставки, где теневой сервер хранит теневые сообщения. Для сообщений с несколькими получателями каждый следующий прыжок для основного сообщения требует отдельной теневой очереди.
Состояние удаления	Информация, хранящаяся на транспортном сервере для теневых сообщений, указывающая на то, что основное сообщение было успешно обработано.
Уведомление об удалении	Ответ, который теневой сервер получает от основного сервера, и который указывает, что теневое сообщение готово к отклонению.
Сеть безопасности	В Exchange 2013 улучшена версия транспортного мусорного контейнера. Сообщения, которые были успешно обработаны или доставлены в почтовый ящик получателя транспортной службой на сервере почтовых ящиков, перемещаются в сеть безопасности. Дополнительные сведения см. в разделе Система безопасности.
Диспетчер теневой избыточности	Компонент транспорта, управляющий теневой избыточностью.
Пульс	Процесс, который позволяет основным серверам и теневым серверам проверять доступность друг друга.

Требования для теневого резервирования

Хотя это может показаться очевидным, теневое избыточние требует использования нескольких серверов почтовых ящиков Exchange 2013. Серверами почтовых ящиков могут быть автономные серверы либо серверы почтовых ящиков и серверы клиентского доступа, установленные на одном компьютере.

• Если сервер почтовых ящиков не входит в группу обеспечения доступности баз данных, остальные серверы почтовых ящиков должны находиться на локальном сайте Active Directory.
• Если сервер почтовых ящиков является участником DAG, другие серверы почтовых ящиков должны принадлежать той же самой DAG. Другие серверы почтовых ящиков, относящиеся к группе обеспечения доступности баз данных, могут находиться на локальном сайте Active Directory или на удаленном сайте Active Directory. Если группа обеспечения доступности баз данных охватывает несколько сайтов Active Directory, функция теневой избыточности предпочтительнее создать избыточную копию сообщения на удаленном сайте Active Directory для обеспечения устойчивости сайта.

Ниже указаны ситуации, в которых системе теневого резервирования не удается защитить сообщения, находящиеся в пути.

• В средах с одним сервером Exchange Server.
• В DAG, подготовка которых не завершена.
• При одновременном отказе двух или более транспортных серверов, участвующих в теневом избыточном сообщении.

Теневое резервирование включено по умолчанию

По умолчанию теневая избыточность включается глобально в службе транспорта на всех серверах почтовых ящиков с помощью параметра ShadowRedundancyEnabled командлета Set-TransportConfig . По умолчанию, если транспортная служба на сервере почтовых ящиков не может создать избыточную копию сообщения, оно не отклоняется. Однако вы можете настроить Exchange 2013 на отклонение сообщения, если избыточная копия сообщения не создается с помощью параметра RejectMessageOnShadowFailure в командлете Set-TransportConfig . Сообщение отклоняется с временным сбоем, но отправляющий сервер может передать его снова. Код 451 4.4.0 Message failed to be made redundant. отклика SMTP: В Exchange 2013 следует настроить для отклонения сообщений, которые невозможно сделать ненужными только в том случае, если в организации доступно несколько серверов почтовых ящиков Exchange 2013.

В следующей таблице описаны параметры, которые включают теневую избыточность.

Параметры, включающие избыточность теней

Параметр	Значение по умолчанию	Описание
ShadowRedundancyEnabled по Set-TransportConfig	$true	$true Включает теневое резервирование на всех транспортных серверах в организации. $false Отключает теневой избыточность на всех транспортных серверах в организации.
RejectMessageOnShadowFailure в Set-TransportConfig	$false	$false. Если теневую копию сообщения создать невозможно, основное сообщение все равно принимается транспортными серверами организации. Эти сообщения не сохраняются избыточно во время транспортировки. $true: ни одно сообщение не принимается и не подтверждается ни одним транспортным сервером в организации до тех пор, пока не будет успешно создана его теневая копия. Если теневую копию сообщения создать невозможно, основное сообщение отклоняется с временной ошибкой. Для всех сообщений в организации, находящихся в пути, сохраняются резервные копии. Это значение следует устанавливать только $true в том случае, если на сайте группы обеспечения доступности баз данных или на сайте Active Directory имеется несколько серверов почтовых ящиков Exchange 2013, на которых можно создать теневую копию сообщения. Этот параметр имеет значение только в том случае, если ShadowRedundancyEnabled имеет значение $true.

Порядок создания теневых сообщений

Главная цель теневого резервирования состоит в том, чтобы всегда хранить две копии сообщения в пределах границы высокой доступности транспорта, пока сообщение находится в пути. Где и когда создается избыточная копия сообщения, зависит от того, откуда пришло сообщение и куда оно направляется. Есть три основных определяющих фактора:

• Сообщения, полученные из-за пределов транспортировки и высокой доступности.
• Сообщения, отправленные за пределы границы высокой доступности транспорта.
• Сообщения, полученные от службы отправки транспорта почтовых ящиков с сервера почтовых ящиков в пределах границы высокой доступности.

Границей высокой транспортной доступности является одна из следующих:

• Группа обеспечения доступности баз данных для серверов почтовых ящиков, входящих в состав группы обеспечения доступности баз данных. Сюда входит группа обеспечения доступности баз данных, охватывающая несколько сайтов Active Directory.
• Сайт Active Directory для серверов почтовых ящиков, не входящих в группу обеспечения доступности баз данных.

Теневое избыточние никогда не отслеживает теневые сообщения через границу высокой доступности транспорта. Когда сообщение пересекает границу высокой доступности транспорта, начинается или перезапускается теневая избыточность. Это уменьшает трафик обслуживания теневых сообщений и предотвращает повторную отправку теневых сообщений через границу высокой доступности транспорта. Транспортные серверы-концентраторы Exchange 2010 — особый случай, который обсуждается далее в этой статье.

Сообщения, полученные из-за границы высокой доступности транспорта

Когда транспортная служба на сервере почтовых ящиков Exchange 2013 получает сообщение из-за пределов высокой доступности транспорта, сервер почтовых ящиков не беспокоится о поддержке или отсутствии поддержки теневой избыточности сервером-отправителем. Пока теневое резервирование включено, сервер почтовых ящиков, принимающий сообщение, создает резервную копию сообщения на другом сервере почтовых ящиков в пределах границы высокой доступности транспорта, прежде чем отправить подтверждение получения сообщения на отправляющий сервер. Ниже показан пример такого процесса.

1. SMTP-сервер передает сообщение в транспортную службу на сервере почтовых ящиков. Сервер почтовых ящиков является основным сервером, а сообщение — основным сообщением.

2. Когда исходный SMTP-сеанс с SMTP-сервером все еще активен, транспортная служба на основном сервере открывает новую одновременную SMTP-сессию с транспортной службой на другом сервере почтовых ящиков в организации для создания избыточной копии сообщения.

   • Если основной сервер является участником DAG, он подключается к другому серверу почтовых ящиков в той же DAG. Если группа обеспечения доступности баз данных охватывает несколько сайтов Active Directory, по умолчанию предпочтительнее использовать сервер почтовых ящиков на другом сайте Active Directory. Этот параметр управляется параметром ShadowMessagePreference командлета Set-TransportService . Значение по умолчанию — PreferRemote, но его можно изменить на RemoteOnly или LocalOnly.
   • Если основной сервер не является членом группы обеспечения доступности баз данных, то основной сервер подключается к другому серверу почтовых ящиков на том же сайте Active Directory, независимо от значения параметра ShadowMessagePrefer .

3. Основной сервер передает копию сообщения в транспортную службу на другом сервере почтовых ящиков, а транспортная служба на другом сервере почтовых ящиков подтверждает, что копия сообщения была успешно создана. Копия сообщения является теневым сообщением, и сервер почтовых ящиков, на котором она находится, является теневым сервером по отношению к основному серверу. Сообщение присутствует в теневой очереди на теневом сервере.

4. После того, как основной сервер получает подтверждение от теневого сервера, основной сервер подтверждает получение основного сообщения исходному SMTP-серверу в исходном SMTP-сеансе, и SMTP-сеанс закрывается.

Сообщения, отправленные за пределы границы высокой доступности транспорта

Если транспортный сервер Exchange 2013 передает сообщение за пределами границы высокой доступности транспорта, а SMTP-сервер на другой стороне подтверждает успешное получение сообщения, транспортный сервер перемещает сообщение в сеть безопасности. После успешной передачи основного сообщения через границу высокой доступности транспорта повторная отправка сообщения из сети безопасности не выполняется. Дополнительные сведения о сети безопасности см. в статье Safety Net.

Сообщения, передаваемые внутри границы высокой доступности транспорта

Маршрутизация сообщений в Exchange 2013 оптимизирована таким образом, что, когда конечным адресатом является сайт группы обеспечения доступности баз данных или Active Directory, многократные переходы между транспортной службой на серверах почтовых ящиков на этом сайте группы обеспечения доступности баз данных или сайте Active Directory обычно не требуются. После того как сообщение принято транспортной службой на сервере почтовых ящиков в группе обеспечения доступности баз данных или сайте Active Directory, на котором находится конечный пункт назначения сообщения, следующий переход для сообщения, как правило, является самим конечным пунктом назначения. Цель теневой избыточности (сохранение двух копий сообщения в пути) достигается при наличии одной теневой копии сообщения в любом месте группы обеспечения доступности баз данных или сайта Active Directory. Как правило, только для сценариев отработки отказа в группе обеспечения доступности баз данных, требующих использования командлета Redirect-Message для очистки активных очередей на сервере почтовых ящиков, потребуется несколько переходов в пределах одной границы высокой доступности транспорта.

Теневое резервирование с помощью транспортных серверов-концентраторов Exchange 2010 на одном сайте Active Directory

Когда транспортный сервер-концентратор Exchange 2010 передает сообщение на сервер почтовых ящиков Exchange 2013 с того же сайта Active Directory, транспортный сервер-концентратор Exchange 2010 объявляет о поддержке теневой избыточности с помощью команды XSHADOW, но сервер почтовых ящиков не объявляет о поддержке теневой избыточности. Это не позволяет транспортному серверу-концентратору Exchange 2010 создавать теневую копию сообщения на сервере почтовых ящиков Exchange 2013.

Когда транспортная служба на сервере почтовых ящиков Exchange 2013 передает сообщение транспортному средству-концентратору Exchange 2010, находящемуся на том же сайте Active Directory, сервер почтовых ящиков Exchange 2013 выполняет тень сообщения для транспортного сервера-концентратора Exchange 2010. После того как сервер почтовых ящиков Exchange 2013 получает подтверждение от транспортного сервера-концентратора Exchange 2010 о том, что сообщение было успешно получено, сервер почтовых ящиков Exchange 2013 перемещает успешно обработанное сообщение в сеть безопасности. Однако успешно обработанные сообщения, сохраненные в почтовом ящике Exchange 2013 в сети безопасности, никогда не отправляются повторно на транспортные серверы-концентраторы Exchange 2010.

Время ожидания SMTP

Во время попытки создать избыточную копию сообщения может истечь время ожидания SMTP-соединения между отправляющим SMTP-сервером и основным сервером или SMTP-сеанса между основным сервером и теневым сервером. Соединители получения и соединители отправки имеют параметр ConnectionInactivityTimeOut, указывающий на фактическую передачу данных через соединитель. Соединители получения также имеют абсолютный параметр ConnectionTimeOut.

Если время ожидания какого-либо из SMTP-сеансов истекает до того, как теневая копия сообщения успешно создана и подтверждена, результат контролируется параметром RejectMessageOnShadowFailure командлета Set-TransportConfig . По умолчанию значение этого параметра равно $false, что означает, что основное сообщение принимается без создания теневой копии. Если значение этого параметра является $true основным, сообщение отклоняется с переходной ошибкой 451 4.4.0.

Если теневая копия сообщения успешно создана, но время ожидания SMTP-сессии между отправляющим SMTP-сервером и основным сервером истекло, то основной сервер принимает и обрабатывает основное сообщение. Отправляющий SMTP-сервер повторно доставит неподтвержденное сообщение, но обнаружение дубликатов сообщений не позволит пользователям почтовых ящиков Exchange увидеть дубликаты. Когда отправляющий SMTP-сервер повторно отправит сообщение, основной сервер создаст еще одну теневую копию сообщения. Нет никакой связи между теневыми сообщениями, создаваемыми при повторной отправке сообщений SMTP-сервером.

В таблице ниже описаны параметры, управляющие процессом создания теневых сообщений

Параметры создания теневых сообщений

Source	Значение по умолчанию	Описание
ShadowMessagePreferenceSetting на Set-TransportConfig	PreferRemote	PreferRemote. Попробуйте создать теневую копию сообщения на сервере почтовых ящиков на другом сайте Active Directory. Если операция завершится неудачно, попробуйте создать теневую копию сообщения на сервере локального сайта Active Directory. LocalOnly: теневую копию сообщения следует создавать только на транспортном сервере на локальном сайте Active Directory. RemoteOnly. Теневую копию сообщения следует создавать только на транспортном сервере на другом сайте Active Directory. Этот параметр имеет смысл только в том случае, если основной сервер, который пытается создать теневую копию сообщения, является сервером почтовых ящиков, который является членом группы обеспечения доступности баз данных, охватывающей несколько сайтов Active Directory.
MaxRetriesForRemoteSiteShadow on Set-TransportConfig	4	Этот параметр используется, если сервер почтовых ящиков является участником группы обеспечения доступности баз данных, охватывающей несколько сайтов Active Directory. Если параметру ShadowMessagePreferenceSetting присвоено значение PreferRemote, то сначала сервер почтовых ящиков пытается создать теневую копию сообщения на другом сервере почтовых ящиков на удаленном сайте Active Directory столько раз, сколько раз задает MaxRetriesForRemoteSiteShadow. Если это завершается ошибкой, сервер почтовых ящиков пытается создать теневую копию сообщения на другом сервере почтовых ящиков на локальном сайте Active Directory столько раз, сколько указано в MaxRetriesForLocalSiteShadow. Если параметру ShadowMessagePreferenceSetting присвоено значение RemoteOnly, сервер почтовых ящиков пытается создать теневую копию сообщения на сервере почтовых ящиков на удаленном сайте Active Directory только столько раз, сколько задает MaxRetriesForRemoteSiteShadow. Параметр Если не удается создать теневую копию сообщения: Если имеет значение RejectMessageOnShadowFailure , $trueосновное сообщение отклоняется с временной ошибкой. Если RejectMessageOnShadowFailure имеет значение $false, основное сообщение все равно принимается, но не сохраняется излишне.
MaxRetriesForLocalSiteShadow on Set-TransportConfig	2	Этот параметр используется в следующих случаях: Если сервер почтовых ящиков является участником группы обеспечения доступности баз данных, охватывающей несколько сайтов Active Directory. Если параметру ShadowMessagePreferenceSetting присвоено значение PreferRemote, то сначала сервер почтовых ящиков пытается создать теневую копию сообщения на другом сервере почтовых ящиков на удаленном сайте Active Directory столько раз, сколько раз задает MaxRetriesForRemoteSiteShadow. Если это завершается ошибкой, сервер почтовых ящиков пытается создать теневую копию сообщения на другом сервере почтовых ящиков на локальном сайте Active Directory столько раз, сколько указано в MaxRetriesForLocalSiteShadow. Если параметру ShadowMessagePreferenceSetting присвоено значение LocalOnly, сервер почтовых ящиков только пытается создать теневую копию сообщения на другом сервере почтовых ящиков на локальном сайте Active Directory столько раз, сколько задает MaxRetriesForLocalSiteShadow. Если сервер почтовых ящиков не является членом группы обеспечения доступности баз данных или если сервер почтовых ящиков является членом группы обеспечения доступности баз данных на одном из сайтов Active Directory, сервер почтовых ящиков пытается создать теневую копию сообщения только на другом сервере почтовых ящиков на локальном сайте Active Directory до количества раз, указанного в MaxRetriesForLocalSiteShadow. Если не удается создать теневую копию сообщения: Если имеет значение RejectMessageOnShadowFailure , $trueосновное сообщение отклоняется с временной ошибкой. Если RejectMessageOnShadowFailure имеет значение $false, основное сообщение все равно принимается, но не сохраняется излишне.
ConnectionInactivityTimeout on Set-ReceiveConnector	5 минут в транспортном сервисе на серверах почтовых ящиков 5 минут в службе транспорта переднего плана на серверах клиентского доступа. 1 минута на серверах пограничного транспорта.	Этот параметр определяет максимальное время, в течение которого открытое SMTP-соединение с исходным сервером обмена сообщениями может оставаться бездействующим до закрытия соединения. Значение этого параметра должно быть меньше значения, указанного параметром ConnectionTimeout .
ConnectionTimeout on Set-ReceiveConnector	10 минут в транспортном сервисе на серверах почтовых ящиков 10 минут в службе транспорта переднего плана на серверах клиентского доступа. 5 минут на серверах Edge Transport.	Этот параметр определяет максимальное время, в течение которого SMTP-соединение с исходным сервером обмена сообщениями может оставаться открытым, даже если исходный сервер обмена сообщениями передает данные. Значение этого параметра должно быть больше значения, указанного параметром ConnectionInactivityTimeout .
ConnectionInactivityTimeOut on Set-SendConnector	10 минут	Этот параметр задает максимальное количество времени, в течение которого подключение по протоколу SMTP к конечному серверу обмена сообщениями может оставаться открытым при его бездействии.

Как хранятся теневые сообщения

После успешного создания теневого сообщения работа теневой избыточности только начинается. Основной и теневой серверы должны постоянно находиться в контакте друг с другом, чтобы отслеживать ход сообщения.

Когда основной сервер успешно передает сообщение для следующего прыжка и следующий прыжок подтверждает прием сообщения, основной сервер обновляет состояние удаления сообщения, указывая, что оно доставлено. Состояние удаления по сути представляет собой сообщение, содержащее список отслеживаемых сообщений. Успешно доставленное сообщение не обязано находиться в теневой очереди, поэтому когда теневой сервер узнает, что основной сервер успешно передал сообщение для следующего прыжка, теневой сервер перемещает теневое сообщение из теневой очереди в систему безопасности.

Теневой сервер определяет состояние удаления теневых сообщений в теневой очереди путем опроса основного сервера. Если теневой сервер открывает SMTP-сеанс с основным сервером по какой-либо причине, включая передачу других, не связанных с ним сообщений, теневой сервер выполняет команду XQDISCARD для определения состояния удаления основных сообщений. Если теневой сервер не открыл SMTP-сеанс с основным сервером по истечении заданного интервала времени, теневой сервер открывает SMTP-сеанс с основным сервером и выполняет команду XQDISCARD . Временной интервал управляется параметром ShadowHeartbeatFrequency командлета Set-TransportConfig . Значение по умолчанию — 2 минуты. После того как теневой сервер откроет сеанс SMTP с основным сервером, основной сервер отвечает уведомлениями об удалении для сообщений, относящихся к запрашивающему теневому серверу. В Exchange 2013 уведомления об отмене хранятся на диске, а не в памяти. Поэтому при перезапуске службы транспорта Microsoft Exchange уведомления об отсылке сохраняются. После запуска службы основной сервер по-прежнему знает о сообщениях, которые он успешно обработал, и эти сведения доступны теневому серверу.

SMTP-связь между теневым сервером и основным сервером используется в качестве пульса, определяющего доступность серверов. Если теневой сервер не может открыть SMTP-сессию с основным сервером по истечении заранее заданного интервала времени или если транспортная база данных основного сервера имеет другой идентификатор базы данных, теневой сервер позиционирует себя как основной сервер, повышает уровень теневых сообщений как основные сообщения и передает сообщения на следующий шаг. Временной интервал управляется параметром ShadowResubmitTimeSpan командлета Set-TransportConfig . Значение по умолчанию — 3 часа.

Диспетчер теневой избыточности является основным компонентом транспортного сервера Exchange 2013, отвечающим за управление теневой избыточностью. Диспетчер теневого резервирования отвечает за хранение указанных ниже сведений для всех основных сообщений, обрабатываемых в настоящее время сервером.

• Теневой сервер для каждого обрабатываемого основного сообщения.
• Состояние удаления, которое необходимо отправить на теневые серверы.

Shadow Redundancy Manager отвечает за следующие действия для всех теневых сообщений, которые теневой сервер имеет в своих теневых очередях:

• сохранение списка основных серверов для каждого теневого сообщения;
• сравнение исходного идентификатора базы данных и текущего идентификатора базы данных очереди, где хранится основная копия сообщения;
• проверка доступности каждого основного сервера, в очередь для которого помещено теневое сообщение;
• обработка уведомлений об удалении для основных серверов.
• удаление теневых сообщений из теневых очередей после получения всех ожидаемых уведомлений об удалении;
• принятие решений о том, когда теневой сервер должен вступить во владение теневыми сообщениями и стать основным сервером.
• Отслеживание бифуркаций сообщений и других побочных эффектов, таких как уведомления о состоянии доставки (DSN) и отчеты журнала, чтобы убедиться, что избыточная копия сообщения не выпущена до тех пор, пока все ветви сообщения не будут полностью обработаны.

В следующей таблице описаны параметры, управляющие сохранением теневых сообщений.

Параметр	Значение по умолчанию	Описание
ShadowHeartbeatFrequency on Set-TransportConfig	2 минуты	Максимальный период времени, в течение которого теневой сервер ждет перед открытием SMTP-подключения к основному серверу, чтобы проверить состояние удаления из сообщения.
ShadowResubmitTimeSpan on Set-TransportConfig	3 часа	Время ожидания сервера до принятия решения о том, что на основном сервере произошел сбой, и присвоения владения теневыми сообщениями в теневой очереди для недоступного основного сервера.
ShadowMessageAutoDiscardInterval on Set-TransportConfig	2 дня	Время, в течение которого сервер сохраняет события удаления для успешно доставленных сообщений. Основной сервер ставит в очередь события отмены, пока не последует запрос теневого сервера. Однако, если теневой сервер не запрашивает основной сервер в течение периода, указанного в этом параметре, основной сервер удаляет события отмены, поставленные в очередь.
SafetyNetHoldTime по Set-TransportConfig	2 дня	Время, в течение которого успешно обработанные сообщения хранятся в сети безопасности. Неподтвержденные теневые сообщения в конечном итоге удаляются из Safety Net после суммирования значений SafetyNetHoldTime и MessageExpirationTimeout в Set-TransportService.
MessageExpirationTimeout по Set-TransportService	2 дней	Как долго сообщение может оставаться в очереди до истечения срока его действия.

Обработка сообщений после сбоев

Теневое избыточние сводит к минимуму потери сообщений из-за сбоев сервера. Когда транспортный сервер подключается к сети после сбоя, возможны два сценария:

• Сервер подключается к сети с новой транспортной базой данных: В этом сценарии транспортная база данных невосстановима из-за повреждения данных или сбоя оборудования. В этом случае, поскольку транспортный сервер получит новый идентификатор базы данных, он будет распознан другими транспортными серверами организации как новый маршрут. Это также относится к ситуации, когда не удалось восстановить сервер, а для замены был подготовлен новый сервер.

• Сервер возвращается в оперативный режим с той же транспортной базой данных: в этом сценарии конкретный транспортный сервер не дал сбой, но был в автономном режиме достаточно долго, чтобы теневой сервер мог принять на себя права собственности на сообщения и повторно их отправить. Например, сбой сетевой карты или длительное обслуживание сервера могут привести к такому сценарию.

В следующей таблице обобщено, как теневая избыточность реагирует на эти два сценария. Для ясности предположим, что сервер, на котором произошел сбой, называется Mailbox01.

Обработка сообщений в сценариях восстановления

Сценарий восстановления	Выполняемые действия
Почтовый ящик01 подключается к сети с новой базой данных.	Когда Mailbox01 становится недоступным, каждый сервер, на котором есть теневые сообщения в очереди для Mailbox01, принимает на себя право собственности на эти сообщения и отправляет их повторно. Затем сообщения доставляются по адресатам. Максимальная задержка для сообщений — это значение параметра ShadowHeartbeatFrequency в командлете Set-TransportConfig . Значение по умолчанию — 2 минуты.
Mailbox01 подключается к сети с той же базой данных.	После того как сервер Mailbox01 возобновит работу, он доставит сообщения, находящиеся в его очередях, которые уже были доставлены серверами, хранящими теневые копии сообщений для сервера Mailbox01. Это приведет к дублированию всех таких сообщений. Пользователи почтовых ящиков Exchange не видят дубликатов сообщений из-за обнаружения повторяющихся сообщений. Однако получатели в системах обмена сообщениями, не относящихся к Exchange, могут получать дубликаты сообщений. Максимальная задержка для сообщений равна значению параметра ShadowResubmitTimeSpan в командлете Set-TransportConfig . Значение по умолчанию — 3 часа.