Right to the very end of the Technet article for Shadow Redundancy, there's the example of one Mailbox server (Mailbox01) that has failed. 2 outcomes are illustrated - A the server is rebuilt, thus using a new transport database ID and B the server is brought back online using the same transport database.

For case A, it's stated that "When Mailbox01 becomes unavailable, each server that has shadow messages queued for Mailbox01 will assume ownership of those messages and resubmit them", indicating a total delay for the messages of only 2 minutes (the default value of ShadowHeartbeatFrequency). However wouldn't there have to pass 3 hours (default ShadowResubmitTimeSpan value) for the time it takes for the shadow servers to assume ownership of the shadow messages for Mailbox01) until those messages are delivered ? Or is it implied that the time taken for re-submission is indeed 2 minutes, but from the point in time when Mailbox01 is re-built, and the other shadow servers open a SMTP session only to discover that the transport database ID is different, thus issuing immediate delivery of the messages ?