ADM: Transport Dumpster & shadows redundancy

Transport Dumpster

Cuando se envía un mensaje desde el servidor Hub Transpor a un DAG, el mensaje se almacena en el Transport Dumpster (contenedor de transporte) para que en caso de fracaso, los mensajes todavía pueden enviarse a los usuarios.

Introducido por primera vez en Exchange 2007, el Transport Dumpster existe en el hub transport server y solo se activaba para Coninuoos Cluster replication (CCR) y LCR y si despues del fallo de un Mailbox Clusterizado, tars volver online lo hacia con poca perdidad de datos ya que el mensaje se reenviaba al usuario porque estaba en el dumpster

The transport dumpster has been revamped in Exchange 2013 and is now known as the Safety Net

Cuando un mensaje se envía desde un Hub Transport a un mailbox Server que forma parte de un DAG, el mensaje se almacena en el Transport Dumpster Queue (diseñado para DAG) hasta que el Hub Transport recibe una notificación que el log de transacciones para un mensaje determinado ha sido a todas las copias del DAG y controlado por el Mailbox

Una vez que los miembros del DAG confirman que el Log ha sido “committed“, el mensaje se purga de la cola, pero si un miembro del DAG no confirma el Log o reporta que el Log ha fallado, el Transport Dumpster reenvía la información a ese miembro del DAG

Los mensajes en el Transport Dumpster se almacenan por un periodo de tiempo controlado por la configuración MaxDumpsterTime, el cual son 7 dias por defecto, o cuando el tamaño de la cola es alcanzado (18 Mb)


Para cambiarlo, lo configuramos a nivel de transporte

Microsoft recomienda que se configure a 1,5 veces del tamaño máximo de mensaje, por lo que si el “MaxSendSize” de la organización es 30 Mb, nosotros deberíamos configurar el dumpster a 45MB.

El tiempo de vida le daremos 4 días (esto no es una recomendación)

  • Set-TransportConfig -MaxDumpsterSizePerDatabase 45MB    //1,5 veces del maxSendSize
  • Set-TransportConfig -MaxDumpsterTime 4

 

Es importante saber que el Transport Dumpster no protege contra la perdida de datos durante un Failover cuando el mensaje es enviado o a una Public Folder, a una base de datos de mailbox que no es parte de un DAG

 

También lo podemos configurar en EMC a nivel de Organizacion > Hub Transport > Global settings

 


 

Shadow Redundancy

La técnica es la misma que el Transport Dumpster. Nos asegura que un mensaje es entregado desde un salto a otro salto (por ejemplo desde un Hub Transport a un Edge transport, reteniendo los mensajes en tránsito de un salto al otro, hasta que se asegura que el mensaje se ha entregado al siguien salto

Esta configuracion esta activada por defecto y trabaja con mail transmitidos entre servidores HubTransport y/o Edge transports

Esta cola proporciona una copia de los mensajes antes de que se entreguen a los mailboxes. Shadow Redundancy no borra el mensaje del Hub Transport hasta que comprobara que el mensaje se había entregado al siguiente salto

Resumiendo, si un mensaje iba a Internet, el Hub Trnspor almacena el mensaje en la Shadow Redundancy hasta que comprueba que el mensaje lo ha recibido el siguiente salto, nuestro Edge Transport que a su vez tendrá una copia hasta que confirma que el destino lo ha recibido

Como vemos los mensajes se almacenan en el Hub Transport, los cuales han sido enviados al ET para salir a Internet


Activar Shadow Redundancy

  • Set-TransportConfig –ShadowRedundancyEnabled $True


Cuando está activado, por defecto no rechaza los mensajes cuya copia redundante no se ha creado. Esto se puede activar usando el parámetro RejectMessageOnShadowFailure en la configuración de Set-TransportConfig

 

Componentes Shadow Redundancy

  • Transport server: The transport server is the server that contains all message queues and routes all messages to the servers. In Exchange 2013, a transport server and Mailbox server are both same.
  • Transport database: Transport database refers to the message queue database. It also stores the Shadow queues and Safety Net.
  • Transport high availability boundary: It can be either a database availability group (DAG) in the DAG environments, or an Active Directory site in non-DAG environments. Exchange maintain two redundant copies of the message upon arrival at transport server in the transport high availability boundary. These redundant copies are removed once the message leavers the transport high availability boundary.
  • Primary server: It is the transport server processing a primary message
  • Primary message: The original message which is in transit before delivery is known as the primary message.
  • Shadow message: The redundant copy of the message maintained by the shadow server as long as the primary message is in transit. It is deleted once the shadow server ensures that the delivery of the primary message is successfully processed by the primary server.
  • Shadow server: As the name suggests, it is the transport server that maintains the shadow message for the primary server. A transport server can simultaneously be the primary server for one messages and the shadow server for another.
  • Shadow queue: It is the delivery queue maintained by the shadow server which contains the shadow messages. For messages with more than one recipient, each hop will contain a shadow queue.
  • Discard status: It is an indicator that the primary message is successfully processed. It is maintained in the transport server.
  • Discard notification: It is the notification given to the shadow server by the primary server whenever a shadow message is ready to be discarded.
  • Shadow Redundancy Manager: It is the transport component that manages shadow redundancy.
  • Heartbeat: It is a very aptly titled process which indicates the availability of primary servers and shadow servers to each other.

 

Componentes Shadow Redundancy

Shadow Redundancy no trabajara en estas situaciones:

  • En un entorno con un unico Exchange Server
  • Con un DAG (para eso está el Transport Dumpster)
  • Durante el fallo simultaneo de 2 más Transport servers (HUB o EDGE) envueltos en la “shadow redundancy” de un mensaje

 

Activar Shadow Redundancy

  • Set-TransportConfig –ShadowRedundancyEnabled $True


Cuando está activado, por defecto no rechaza los mensajes cuya copia redundante no se ha creado. Esto se puede activar usando el parámetro RejectMessageOnShadowFailure en la configuracion de Set-TransportConfig

 

 

 

Como funciona Shadow Redundancy

Correcto

El HUB contacta con EDGE en el puerto 25 y emite un EHLO, El EDGE responde con 250 XSHADOWS. El 250 XSHADOW es un mensaje de exitode que el HUB puede contactar con el EDGE como espera

Cuando el Edge entrega el mensaje correctamente, el status del mensake se actualizara como que esta entregado el mensaje. El status de los mensajes enviados chequeado a intervalos por el HUB (cada 15 minunto) usando el comando XDISCARD.

El EDGE emitirá una lista de los mensajes con el status “successfully deliver”. Entonces el HUB eliminara estos mensajes de Shadow Redundancy


 

Fallo (Edge out or down)

Una vez que el mensaje es enviado y el EDGE no es alcanzable por el HUB dentro de un periodo de tiempo, el HUB reenvia el mensaje a otro EDGE. El Primary owner del mensaje en el Shadow Redundancy Queue sera cambiado al segundo EDGE.

Cuando no hay otra ruta alternativa el mensaje no sera reenviado y se auto-eliminara de la Redundancy Queue


 

 

 

 

 

 

Exchange 2010 Error 451 4.4.0 Error DNS Query Failed

We’ve seen this happen at two environments recently. Both with Small Business Server 2011 running Exchange 2010 SP1 Rollup 3-v3 and 4. Our service provides monitoring of the Exchange server; however, we don’t have an eye on the queues. So, no alarms go off when a message is delayed.

When logging on to the Exchange Server and looking at the Outbound queues, we noticed mail for only a particular domain being held with the 451 4.4.0 Error DNS Query Failed error. Other symptoms:

  1. The nslookup command run on the Exchange server could resolve the domain, proving the internal DNS server was normal.
  2. After gaining the MX record from who.is, the nslookup command resolved the mail server’s IPv4 address, proving the receiver’s mail server was resolvable.
  3. A telnet session to the MX record successfully contacted the suspected domain’s mail server on port 25.
  4. Internal email delivery was functioning.
  5. All other external mail delivery was functioning.

Now we’re down to Exchange itself, since everything DNS related on the server is working correctly. This is the current fix we use:

 

Step 1: Change the Network properties of the Edge Transport Server

  1. En el Edge Transport > Propiedades > Pestaña “External DNS Lookups” > Use these DNS


 

 

 

 

 

 

Step 2: Configure the Hub Transport to use the External DNS for external domains.

Click on the Hub Transport of Organization Configuration > Send Connectors > Right click > properties > Network Tab > Check the Use External DNS Looku

 

Step 3: Restart the Transport Service

  • Restart-Services MSExhangeTransport

The queue should empty immediately.

With this fix, we’re just telling Exchange to bypass the internal DNS for an external one for outbound mail that isn’t delivered to its domain.

Other fixes that may help:

1. Flush the DNS caches on the internal DNS servers and the Exchange server.
2. Add a Forwarder to the internal DNS server. I’m not a big fan of this one as the Root Forwarders should be sufficient. It did work at one site, though.

Be the first to comment

Leave a Reply