Redundancia de instantánea

Se aplica a: Exchange Server 2013

La redundancia de la instantánea fue introducida en Microsoft Exchange Server 2010 para proporcionar copias redundantes de mensajes antes de que se entreguen a los buzones de correo. En Exchange 2010, la redundancia de la instantánea retrasaba la eliminación de un mensaje desde la base de datos de transporte de un servidor de transporte hasta que el servidor había comprobado si el siguiente salto de la ruta de entrega del mensaje había completado la entrega. Si el salto siguiente dada error antes de notificar al servidor de transporte que había realizado satisfactoriamente la entrega, este reenviaba el mensaje al siguiente salto. Los servidores Exchange 2010 usaban el verbo XSHADOW para anunciar su soporte de redundancia de la instantánea. Si un servidor SMTP no admitía la redundancia de la instantánea, Exchange 2010 usaba el reconocimiento retrasado basándose en un intervalo de tiempo configurado en el conector de recepción para realizar una copia redundante del mensaje.

La principal mejora en la redundancia de la instantánea en Microsoft Exchange Server 2013 es que el servidor de transporte ahora realiza una copia redundante de cualquier mensaje que recibe antes de notificar la recepción satisfactoria del mismo al servidor de envío. No tiene transcendencia si el servidor de envío admite o no la redundancia de la instantánea. Esto ayuda a garantizar que todos los mensajes de la canalización de transporte de Exchange 2013 son redundantes mientras se encuentran en tránsito. Si Exchange 2013 establece que el mensaje original se ha perdido en tránsito, se entrega la copia redundante del mensaje.

Componentes de la redundancia de instantánea

La tabla siguiente describe los componentes de redundancia de la instantánea. A lo largo de este tema se emplean los términos que se describen a continuación.

Término	Descripción
Servidor de transporte	Servidor de Exchange que tiene colas de mensajes y se encarga de enrutar mensajes. En Exchange 2013, un servidor de transporte es un servidor de buzón de correo (servicio de transporte del servidor de buzón de correo).
Base de datos de transporte	La base de datos de cola de mensajes en un servidor de transporte Exchange 2013. Las colas de instantánea y la red de seguridad también se almacenan en la base de datos de transporte.
Límite de alta disponibilidad de transporte	Grupo de disponibilidad de bases de datos (DAG) en entornos DAG, o un sitio de Active Directory en entornos que no sean parte de un DAG. Cuando un mensaje llega en un servidor de transporte del límite de alta disponibilidad de transporte, Exchange intenta conservar 2 copias redundantes del mensaje en servidores de transporte dentro del límite. Cuando un mensaje abandona el límite de alta disponibilidad de transporte, Exchange deja de conservar copias del mensaje.
Mensaje principal	El mensaje enviado en la canalización de transporte para la entrega.
Mensaje de instantánea	La copia redundante del mensaje que el servidor de instantáneas conserva hasta que confirma que el mensaje principal ha sido procesado con éxito por el servidor principal.
Servidor principal	Servidor de transporte que actualmente procesa el mensaje principal.
Servidor de instantánea	El servidor de transporte que contiene el mensaje de instantánea para el servidor principal. Un servidor de transporte puede ser el servidor principal de algunos mensajes y el servidor de instantánea de otros mensajes de manera simultánea.
Cola de instantáneas	La cola de entrega donde el servidor de instantánea almacena mensajes de instantánea. En mensajes con múltiples destinatarios, cada salto del mensaje principal necesita colas de instantáneas independientes.
Estado de descarte	La información que conserva un servidor de transporte para mensajes de instantánea que indican que el mensaje principal ha sido procesado con éxito.
Notificación de descarte	Respuesta que un servidor de instantáneas recibe de un servidor principal y que indica que un mensaje de instantánea se puede descartar.
Red de seguridad	La versión mejorada del contenedor de transporte en Exchange 2013. Los mensajes que se procesan o se entregan satisfactoriamente a un destinatario de buzón de correo por parte del servicio de transporte en un servidor de buzón de correo se mueven a la red de seguridad. Para obtener más información, consulte Red de seguridad.
Administrador de redundancia de instantánea	Componente de transporte que administra la redundancia de instantánea.
Latido	Proceso por el cual los servidores principales y los servidores de instantáneas comprueban su disponibilidad entre sí.

Requisitos para la redundancia de instantánea

Aunque pueda parecer obvio, la redundancia de la instantánea requiere múltiples servidores de buzón de correo en Exchange 2013. El servidor de buzón de correo puede ser un servidor independiente, o servidores de buzón de correo y de acceso de clientes instalados en el mismo equipo.

• Si el servidor del buzón de correo no es miembro de un DAG, los demás servidores de buzón de correo deben encontrarse en el sitio de Active Directory.
• Si el servidor del buzón de correo es miembro de un DAG, los demás servidores del buzón de correo deben pertenecer al mismo DAG. El resto de servidores de buzón de correo que pertenecen al DAG pueden estar en el sitio local de Active Directory o en un sitio remoto de Active Directory. Si el DAG se extiende en varios sitios de Active Directory, la redundancia de la instantánea prefiere crear una copia redundante del mensaje en un sitio remoto de Active Directory para la resistencia del sitio.

Estas son las situaciones donde la redundancia de la instantánea no puede proteger mensajes en tránsito:

• En entornos de servidor de Exchange solo.
• En DAG infra aprovisionados.
• Durante el error simultáneo de dos o más servidores de transporte que participan en la redundancia de la instantánea de un mensaje.

Redundancia de instantánea está activado por defecto

Por defecto, redundancia de instantánea está activado de manera global en el servicio de transporte de todos los buzones de correo usando el parámetro ShadowRedundancyEnabled en el cmdlet Set-TransportConfig. Por defecto, si el servicio de transporte de un servidor de buzón de correo no puede crear una copia redundante de un mensaje, el mensaje no se rechaza. Sin embargo, puede configurar Exchange 2013 para rechazar un mensaje si no se crea una copia redundante del mensaje mediante el parámetro RejectMessageOnShadowFailure en el cmdlet Set-TransportConfig . El mensaje se rechaza con un error transitorio, pero el servidor de envío puede volver a transmitir el mensaje. El código de respuesta SMTP es 451 4.4.0 Message failed to be made redundant. Debe configurar Exchange 2013 para rechazar los mensajes que no se pueden hacer redundantes solo cuando su organización tiene varios servidores de buzones de Exchange 2013 disponibles.

La tabla siguiente describe los parámetros que permiten redundancia de instantánea.

Parámetros que permiten redundancia de instantánea

Parámetro	Valor predeterminado	Descripción
ShadowRedundancyEnabled en Set-TransportConfig	$true	$true habilita la redundancia de instantáneas en todos los servidores de transporte de la organización. $false deshabilita la redundancia de instantáneas en todos los servidores de transporte de la organización.
RejectMessageOnShadowFailure en Set-TransportConfig	$false	$false: cuando no se puede crear una instantánea del mensaje, los servidores de transporte de la organización aceptan el mensaje principal de todos modos. Esos mensajes de forma redundante no persistieron mientras están en tránsito. $true: ningún servidor de transporte de la organización acepta ni confirma ningún mensaje hasta que se crea correctamente una instantánea del mensaje. En caso de no poder crear una instantánea del mensaje, el mensaje principal se rechaza con un error transitorio. Todos los mensajes de la organización se conservan de forma redundante mientras están en tránsito. Debe establecer este valor $true en solo si tiene varios servidores de buzones de Exchange 2013 en un dag o sitio de Active Directory donde se puede crear una instantánea del mensaje. Este parámetro solo es significativo cuando ShadowRedundancyEnabled es $true.

¿Cómo se crean mensajes de instantánea?

El objetivo principal de la redundancia de instantánea es disponer siempre de dos copias de un mensaje en el límite de alta disponibilidad de transporte mientras el mensaje se encuentra en tránsito. Cuándo y dónde se crea la copia redundante del mensaje depende de la procedencia y el destino del mensaje. Hay tres factores determinantes principales:

• Mensajes recibidos desde fuera de un límite de alta disponibilidad de transporte.
• Mensajes enviados fuera de un límite de alta disponibilidad de transporte.
• Mensajes recibidos desde el servicio de envío de transporte de buzón de correo desde un servidor de correo en el límite de alta disponibilidad de transporte.

El límite de alta disponibilidad de transporte es uno de los siguientes:

• Un DAG, para servidores de correo que son miembros de un DAG. Esto incluye un DAG que abarca múltiples sitios de Active Directory.
• Un sitio de Active Directory, para servidores de buzón de correo que no pertenecen a un DAG.

Redundancia de instantánea nunca rastrea mensajes de instantánea a través de un límite de alta disponibilidad de transporte. Cuando un mensaje cruza el límite de alta disponibilidad de transporte, la redundancia de instantánea comienza o se reinicia. Esto reduce el tráfico de mantenimiento de mensajes de instantánea y evitar que se reenvíen mensajes de instantánea en los límites de alta disponibilidad de tráfico. Los servidores de transporte de concentradores de Exchange 2010 son un caso especial del que se hablará más adelante en este mismo tema.

Mensajes recibidos desde fuera de un límite de alta disponibilidad de transporte

Cuando el servicio de transporte de un servidor de buzón de correo de Exchange 2013 recibe un mensaje externo al límite de alta disponibilidad de transporte, al servidor de buzón de correo no le interesa la compatibilidad o falta de compatibilidad de redundancia de instantánea en el servidor emisor. En la medida en que se habilite la redundancia de instantánea, el servidor de buzón de correo que recibe el mensaje realiza una instantánea del mensaje en otro servidor de buzón de correo en el límite de alta disponibilidad de tráfico antes de acusar recibo del mensaje al servidor emisor. Este es un ejemplo de cómo funciona el proceso:

1. Un servidor SMTP transmite un mensaje al servicio de transporte de un servidor de buzón de correo. El servidor del buzón de correo es el servidor principal y el mensaje es el mensaje principal.

2. Aunque la sesión SMTP original con el servidor SMTP sigue estando activa, el servicio de transporte del servidor principal abre una nueva sesión SMTP simultánea con el servicio de transporte en un servidor de buzón de correo diferente de la organización para crear la copia redundante del mensaje.

   • Si el servidor principal es miembro de un DAG, este se conecta con un servidor de buzón de correo diferente en el mismo DAG. Si el DAG se expande en varios sitios de Active Directory, se prefiere un servidor de buzón de correo en un sitio de Active Directory de manera predeterminada. Esta configuración se controla mediante el parámetro ShadowMessagePreference en el cmdlet Set-TransportService . El valor predeterminado es PreferRemote, pero puede cambiarlo a RemoteOnly o LocalOnly.
   • Si el servidor principal no es miembro de un DAG, el servidor principal se conecta a otro servidor de buzón en el mismo sitio de Active Directory, independientemente del valor del parámetro ShadowMessagePreference .

3. El servidor principal transmite una copia del mensaje al servicio de transporte del servidor de buzón de correo, y el servicio de transporte del otro servidor de buzón de correo notifica que la copia del mensaje se ha creado satisfactoriamente. La copia del mensaje es un mensaje de instantánea, y el servidor del buzón de correo que contiene el mensaje es el servidor de instantánea del servidor principal. El mensaje existe en una cola de instantánea en el servidor de instantánea.

4. Cuando el servidor principal recibe una notificación del servidor de instantánea, el servidor principal acusa recibo del mensaje principal al servidor SMTP original en la sesión SMTP original, y la sesión SMTP se cierra.

Mensajes enviados fuera de un límite de alta disponibilidad de transporte

Cuando un servidor de transporte Exchange 2013 transmite un mensaje fuera del límite de alta disponibilidad de tráfico y el servidor SMTP en el otro lado acusa recibo del mensaje, el servidor de transporte mueve el mensaje a la red de seguridad. No puede volver a enviarse el mensajes desde la red de seguridad una vez que el mensaje principal ha sido transmitido satisfactoriamente a través del límite de alta disponibilidad de transporte. Para obtener más información acerca de la red de seguridad, consulte Red de seguridad.

Mensajes transmitidos dentro de un límite de alta disponibilidad de transporte

El enrutado de mensajes está optimizado en Exchange 2013 de manera que cuando el destino último es un sitio DAG o de Active Directory, no suelen ser necesarios múltiples saltos entre el servicio de transporte en servidores de buzón de correo en dicho sitio DAG o Active Directory. Una vez que el mensaje es aceptado por el servicio de transporte en un servidor de buzón de correo en el sitio DAG o Active Directory que mantiene el último destino del mensaje, el siguiente salto del mensaje suele ser el propio destino último. El objetivo de la redundancia de instantánea de mantener dos copias de un mensaje en tránsito se cumple cuando una instantánea del mensaje existe en cualquier lugar de un sitio DAG o Active Directory. Normalmente, solo las situaciones de fallo en un DAG que exija que el cmdlet Redirect-Message purgue las colas activas en un servidor de buzón de correo requieren múltiples saltos en el mismo límite de alta disponibilidad de tráfico.

La redundancia de instantánea con servidores de transporte de concentradores Exchange 2010 en el mismo sitio de Active Directory

Cuando un servidor de transporte de concentradores de Exchange 2010 transmite un mensaje a un servidor de buzón de correo Exchange 2013 en el mismo sitio de Active Directory, el servidor de transporte de concentradores de Exchange 2010 anuncia la compatibilidad de la redundancia de instantánea usando el comando XSHADOW, pero el servidor de buzón de correo no anuncia la compatibilidad de la redundancia de instantánea. Esto impide que el servidor de transporte de concentradores de Exchange 2010 cree una instantánea del mensaje en un servidor de buzón de correo de Exchange 2013.

Cuando un servicio de transporte en un servidor de buzón de correo Exchange 2013 transmite un mensaje a un transporte de concentradores Exchange 2010 del mismo sitio de Active Directory, el servidor de buzón de correo Exchange 2013 crea una instantánea del mensaje para el servidor de transporte de concentradores Exchange 2010. Una vez que el servidor de buzón de correo Exchange 2013 recibe notificación del servidor de transporte de concentradores Exchange 2010 de que el mensaje ha sido recibido satisfactoriamente, el servidor de buzón de correo Exchange 2013 mueve el mensaje procesado satisfactoriamente en la red de seguridad. Sin embargo, el mensaje procesado satisfactoriamente y almacenado en la red de seguridad por el buzón de correo Exchange 2013 no se vuelve a reenviar a los servidores de transporte de concentradores de Exchange 2010.

Tiempos de espera de SMTP

Durante el intento de realizar una copia redundante del mensaje, la conexión SMTP entre el servidor SMTP de envío y el servidor principal, o la sesión SMTP entre el servidor principal y el servidor de instantánea podría agotar el tiempo de espera. Los conectores de recepción y los conectores de envío tienen un parámetro ConnectionInactivityTimeOut para cuando los datos se transmiten realmente en el conector. Los conectores de recepción también tienen un parámetro ConnectionTimeOut absoluto.

Si alguna de las sesiones SMTP agota el tiempo de espera antes de que la instantánea del mensaje se cree y confirme correctamente, el resultado se controla mediante el parámetro RejectMessageOnShadowFailure en el cmdlet Set-TransportConfig . De forma predeterminada, el valor de este parámetro es $false, lo que significa que el mensaje principal se acepta sin crear una instantánea. Si el valor de este parámetro es $true el mensaje principal se rechaza con el error 451 4.4.0transitorio .

Si la instantánea de un mensaje se crea satisfactoriamente, pero la sesión SMTP entre el servidor SMTP de envío y el servidor principal agota el tiempo de espera, el servidor principal acepta y procesa el mensaje principal. El servidor SMTP de envío reenviará el mensaje no confirmado, pero la detección de mensajes duplicados evitará que los usuarios de Exchange vean mensajes duplicados. Cuando el servidor SMTP de envío reenvía el mensaje, el servidor principal creará otra instantánea del mensaje. No existe relación entre las instantáneas creadas durante el reenvío de mensajes por parte del servidor SMTP de envío.

La siguiente tabla describe los parámetros que controlan la creación de instantáneas

Parámetros de creación del mensaje de instantánea

Origen	Valor predeterminado	Descripción
ShadowMessagePreferenceSetting en Set-TransportConfig	PreferRemote	PreferRemote: intente realizar una instantánea del mensaje en un servidor de buzones de correo en otro sitio de Active Directory. Si la operación falla, intente hacer una instantánea del mensaje en un servidor del sitio local de Active Directory. LocalOnly: solo se debe realizar una instantánea del mensaje en un servidor de transporte en el sitio local de Active Directory. RemoteOnly: Solo debe hacerse una instantánea del mensaje en un servidor de transporte de un sitio local diferente de Active Directory. Este parámetro solo es útil cuando el servidor principal que intenta realizar una instantánea del mensaje es un servidor de buzón de correo que es miembro de un DAG que se extiende en múltiples sitios de Active Directory.
MaxRetriesForRemoteSiteShadow en Set-TransportConfig	4	Este parámetro se emplea cuando el servidor de buzón de correo es miembro de un DAG que se extiende en múltiples sitios de Active Directory. Si ShadowMessagePreferenceSetting está establecido PreferRemoteen , primero el servidor de buzones intenta crear una instantánea del mensaje en otro servidor de buzones de correo en un sitio remoto de Active Directory hasta el número de veces especificado por MaxRetriesForRemoteSiteShadow. Si se produce un error, el servidor de buzones de correo intenta crear una instantánea del mensaje en otro servidor de buzones en el sitio local de Active Directory hasta el número de veces especificado por MaxRetriesForLocalSiteShadow. Si ShadowMessagePreferenceSetting está establecido en RemoteOnly, el servidor de buzones solo intenta crear una instantánea del mensaje en un servidor de buzones de correo en un sitio remoto de Active Directory hasta el número de veces especificado por MaxRetriesForRemoteSiteShadow. El Cuando no se puede crear una instantánea del mensaje correctamente: Si RejectMessageOnShadowFailure es $true, el mensaje principal se rechaza con un error transitorio. Si RejectMessageOnShadowFailure es $false, el mensaje principal se acepta de todos modos, pero no se conserva redundantemente.
MaxRetriesForLocalSiteShadow en Set-TransportConfig	2	Este proceso se usa en las siguientes circunstancias: Si el servidor de buzón de correo es miembro de un DAG que se extiende en múltiples sitios de Active Directory. Si ShadowMessagePreferenceSetting está establecido PreferRemoteen , primero el servidor de buzones intenta crear una instantánea del mensaje en otro servidor de buzones de correo en un sitio remoto de Active Directory hasta el número de veces especificado por MaxRetriesForRemoteSiteShadow. Si se produce un error, el servidor de buzones de correo intenta crear una instantánea del mensaje en otro servidor de buzones en el sitio local de Active Directory hasta el número de veces especificado por MaxRetriesForLocalSiteShadow. Si ShadowMessagePreferenceSetting está establecido LocalOnlyen , el servidor de buzones solo intenta crear una instantánea del mensaje en otro servidor de buzones del sitio local de Active Directory hasta el número de veces especificado por MaxRetriesForLocalSiteShadow. Si el servidor de buzones de correo no es miembro de un DAG o si el servidor de buzones de correo es miembro de un DAG que se encuentra en un sitio de Active Directory, el servidor de buzones solo intenta crear una instantánea del mensaje en un servidor de buzón diferente en el sitio local de Active Directory hasta el número de veces especificado por MaxRetriesForLocalSiteShadow. Cuando no se puede crear una instantánea del mensaje correctamente: Si RejectMessageOnShadowFailure es $true, el mensaje principal se rechaza con un error transitorio. Si RejectMessageOnShadowFailure es $false, el mensaje principal se acepta de todos modos, pero no se conserva redundantemente.
ConnectionInactivityTimeout en Set-ReceiveConnector	5 minutos en el servicio de transporte en los servidores de buzón de correo 5 minutos en el servicio de transporte front-end en los servidores de acceso de cliente. 1 minuto en los servidores de transporte perimetral.	Este parámetro especifica el tiempo máximo que puede permanecer inactiva una conexión SMTP abierta con un servidor de mensajería de origen antes de que se cierre la conexión. El valor de este parámetro debe ser menor que el valor especificado por el parámetro ConnectionTimeout .
ConnectionTimeout en Set-ReceiveConnector	10 minutos en el servicio de transporte en los servidores de buzón de correo 10 minutos en el servicio de transporte front-end en los servidores de acceso de cliente. 5 minutos en los servidores de transporte perimetral.	Este parámetro especifica el tiempo máximo que puede permanecer abierta una conexión SMTP con un servidor de mensajería de origen, incluso aunque el servidor de mensajería de origen esté transmitiendo datos. El valor de este parámetro debe ser mayor que el valor especificado por el parámetro ConnectionInactivityTimeout .
ConnectionInactivityTimeOut en Set-SendConnector	10 minutos	Este parámetro especifica el tiempo máximo que puede permanecer inactiva una conexión SMTP con un servidor de mensajería de destino antes de que se cierre la conexión.

¿Cómo se mantienen los mensajes de instantánea?

Una vez creado un mensaje de instantánea, el trabajo de la redundancia de instantánea no ha hecho más que empezar. El servidor principal y el servidor de instantánea necesitan estar en contacto entre sí para rastrear el progreso del mensaje.

Cuando el servidor principal transmite con éxito el mensaje al siguiente salto, y este acusa recibo del mensaje, el servidor principal actualiza el estado de descarte del mensaje como entrega completa. El estado de descarte consiste básicamente en un mensaje que contiene una lista de mensajes que se están supervisando. Los mensajes que se envían con éxito no necesitan mantenerse en una cola de instantánea, de manera que cuando el servidor de instantánea sabe que el servidor principal ha transmitido con éxito el mensaje al siguiente salto, el servidor de instantánea mueve el mensaje de la cola de instantánea a la red de seguridad.

El servidor de instantánea decide el estado de descarte de los mensajes de instantánea en las colas de instantáneas consultando al servidor principal. Si el servidor de instantánea abre una sesión SMTP con el servidor principal por cualquier motivo, incluida la transmisión de otros mensajes sin relación, el servidor de instantánea emite el comando XQDISCARD para decidir el estado de descarte de los mensajes principales. Si el servidor de instantánea no ha abierto una sesión SMTP con el servidor principal después de un intervalo de tiempo preconfigurado, el servidor de instantánea abrirá una sesión SMTP con el servidor principal y emitirá el comando XQDISCARD. El intervalo de tiempo se controla mediante el parámetro ShadowHeartbeatFrequency en el cmdlet Set-TransportConfig . El valor predeterminado es de 2 minutos. Una vez que el servidor de instantánea abre una sesión SMTP con el servidor principal, este responde con las notificaciones de descarte para los mensajes se aplican al servidor de instantánea que realiza la consulta. En Exchange 2013, las notificaciones de descarte se almacenan en el disco, no en la memoria. Por lo tanto, si el servicio de transporte de Microsoft Exchange se reinicia las notificaciones de descarte persisten. Una vez iniciado el servicio, el servidor principal sigue conocimiento los mensajes que ha procesado satisfactoriamente, y la información está disponible para el servidor de instantánea.

La comunicación SMTP entre el servidor de instantánea y el servidor principal se emplea como ellatido que determina la disponibilidad de los servidores. Si el servidor de instantánea no puede abrir una sesión SMTP con el servidor principal después de un intervalo de tiempo preconfigurado, o si la base de datos de transporte del servidor principal tiene un Id. distinto de base de datos, el servidor de instantánea se promueve como el servidor principal, promueve los mensajes de instantánea como mensajes principales y los transmite al siguiente salto. El intervalo de tiempo lo controla el parámetro ShadowResubmitTimeSpan del cmdlet Set-TransportConfig. El valor predeterminado es 3 horas.

Shadow Redundancy Manager es el componente principal de un servidor de transporte de Exchange 2013 responsable de administrar la redundancia instantánea. El administrador de redundancia de instantánea se encarga de mantener los datos enumerados a continuación de todos los mensajes principales que un servidor procesa actualmente:

• El servidor de instantánea de cada mensaje principal que se está procesando.
• El estado de descarte que se va a enviar a los servidores de instantánea.

El administrador de redundancia de instantánea se ocupa de las siguientes tareas relativas a todos los mensajes de instantánea que un servidor de instantáneas tiene en sus colas de instantáneas:

• Mantener la lista de servidores principales de cada mensaje de instantánea.
• Comparar el Id. original y el Id. actual de la base de datos de la base de datos de cola en el que se almacena la copia principal del mensaje.
• Comprobar la disponibilidad de cada servidor principal para el que hay un mensaje de instantánea en cola.
• Procesar las notificaciones de descarte de los servidores principales.
• Eliminar los mensajes de instantánea de las colas de instantánea una vez que se han recibido todas las notificaciones de descarte previstas.
• Decidir el momento en el que un servidor de instantánea debe hacerse con la propiedad de los mensajes de instantánea y, de este modo, convertirse en un servidor principal.
• Rastrear las bifurcaciones de mensajes y otros efectos secundarios de mensajes como notificaciones de estado de entrega (DSN) e informes de diario para comprobar que la copia redundante del mensaje no se lanza hasta que se han procesado íntegramente todas las bifurcaciones del mensaje.

En la siguiente tabla se describen los parámetros que controlan cómo se mantiene un mensaje.

Parámetro	Valor predeterminado	Descripción
ShadowHeartbeatFrequency en Set-TransportConfig	2 minutos	La cantidad máxima de tiempo que espera un servidor de instantáneas antes de abrir una conexión SMTP en el servidor principal para comprobar el estado de descarte de los mensajes.
ShadowResubmitTimeSpan en Set-TransportConfig	3 horas	El tiempo de espera de un servidor antes de decidir que un servidor principal falla y asume la propiedad de las instantáneas de mensajes en la cola de instantáneas para el servidor principal que es inalcanzable.
ShadowMessageAutoDiscardInterval en Set-TransportConfig	2 días	Intervalo de tiempo en que un servidor conserva eventos de descarte para mensajes entregados correctamente. Un servidor principal pone en cola los eventos de descarte hasta que lo consulta el servidor de seguridad. Ahora bien, si el servidor de seguridad no consulta al servidor de seguridad respecto a la duración que se especifica en este parámetro, el servidor principal elimina los elementos descartados que están en cola.
SafetyNetHoldTime en Set-TransportConfig	2 días	Cuánto tiempo se conservan los mensajes procesados correctamente en la red de seguridad. Los mensajes alternativos no reconocidos finalmente expiran de Safety Net después de la suma de SafetyNetHoldTime y MessageExpirationTimeout en Set-TransportService.
MessageExpirationTimeout en Set-TransportService	2 días	Tiempo que un mensaje puede permanecer en una cola antes de que caduque.

Procesamiento de mensajes después de una interrupción

La redundancia de instantánea reduce el riesgo de que un mensaje se pierda a causa de una interrupción del servidor. Cuando un servidor de transporte vuelve a estar operativo tras una interrupción, pueden darse dos escenarios:

• El servidor vuelve a estar en línea con una nueva base de datos de transporte: en este escenario, la base de datos de transporte no se puede recuperar debido a daños en los datos o errores de hardware. En tal caso, como el servidor de transporte tendrá un nuevo identificador de base de datos, el resto de servidores de transporte de la organización lo identificarán como una nueva ruta. Esto es igualmente aplicable a la situación en la que un servidor no se ha podido recuperar y, por lo tanto, se aprovisiona otro nuevo para sustituirlo.

• El servidor vuelve a estar en línea con la misma base de datos de transporte: en este escenario, no se produjo un error en el servidor de transporte determinado, pero estaba sin conexión el tiempo suficiente para que el servidor de instantáneas asumiera la propiedad de los mensajes y los volviera a enviar. Por ejemplo, a causa de un error en la tarjeta de red o un mantenimiento del servidor muy prolongado.

La siguiente tabla resume cómo redundancia de instantánea reacciona a estas dos situaciones. Para entenderlo mejor, supongamos que el servidor que ha sufrido una interrupción se llama Mailbox01.

Procesamiento de mensajes en situaciones de recuperación

Escenario de recuperación	Acciones realizadas
Mailbox01 vuelve a estar conectado con una base de datos nueva.	Cuando Mailbox01 deja de estar disponible, todos los servidores que tienen mensajes de instantánea en cola para Mailbox01 asumirán la propiedad de dichos mensajes y los volverán a enviar. Los mensajes luego son entregados a sus destinos. El retraso máximo de los mensajes es el valor del parámetro ShadowHeartbeatFrequency en el cmdlet Set-TransportConfig . El valor predeterminado es de 2 minutos.
Mailbox01 vuelve a estar conectado con la misma base de datos.	Cuando Mailbox01 vuelve a estar en línea, entregará los mensajes en sus colas, que ya habrán sido entregadas por los servidores que mantienen instantáneas de los mensajes para Mailbox01. Como consecuencia, lo mensajes se entregarán por duplicado. Los usuarios del buzón de Exchange no verán mensajes duplicados gracias a la detección de mensajes duplicados. Sin embargo, los destinatarios en sistemas de mensajería ajenos a Exchange pueden recibir copias duplicadas de los mensajes. El retraso máximo de los mensajes es el valor del parámetro ShadowResubmitTimeSpan en el cmdlet Set-TransportConfig . El valor predeterminado es 3 horas.