• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1104
  • Last Modified:

Don't understand how Shadow Redundancy in Exchange 2010 work

I've reading Shadow Redundancy article from Microsoft site:
http://technet.microsoft.com/en-us/library/dd351027(EXCHG.140).aspx

Question 1: In the document, it gives an example of "Multiple Hop Scenario", the step 3 says:

3.The Chicago hub queries the New York hub for discard status and receives the discard notification for the message. At this time, it can remove the shadow message from its database. Whether the message was delivered from London to Dublin doesn't have an impact on when the Chicago server deletes the shadow message.

Why "whether the message was delivered from London to Dublin doesn't have an impact on when the Chicago server deletes the shadow message"???

It seems to comflict with the Microsoft definition of "Shadow Redundancy" saying "With shadow redundancy, the deletion of a message from the transport database is delayed until the transport server verifies that all of the next hops for that message have completed delivery"

it clearly says that the deletion of a message until verifying that ALL of the next hops for that message have completed delivery!

Anyone can help to explain that?

Thanks in advance,
Jerry
0
JerryJay
Asked:
JerryJay
  • 3
  • 2
  • 2
5 Solutions
 
endital1097Commented:
because at that point the new york ht has passed the message to the next hop so the message is no longer in its queue, therefore to the chicago server the message has been "delivered"
0
 
endital1097Commented:
the best way to think of it is that exchange will always attempt to deliver the message to the final destination
so with shadow redundancy it is still taking the best possible route, but after the message is handed off to the next hop, to the source hub transport server that's its destination. at that point the purpose of shadow redundancy is to ensure that hop processed the messag
when the message no longer exists at that hop shadow redunancy considers the message delivered

shadow redundancy is not guaranteed delivery from source to destination, just from hop to hop
0
 
AkhaterCommented:
Back to exchange 2007 we had an issue that a failing HUB will lead all the emails in its queue to be lost.
 

With Exchange 2010 Microsoft tries to make hardware "disposable" meaning that any failing hardware can be replaced without any impact or data loss.

For the HUB servers they have implemented Shadow Redundancy which means that each hop will only delete the email after it gets the confirmation that the next hop was able to relay it.

assuming the email sent from A to B needs to pass by Server1 -> Server2 -> Server3

Server1 will delete the email only when it gets the confirmation from Server2 that it was able to deliver it to server 3.

that's the 3 hop concept
0
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

 
JerryJayAuthor Commented:
thanks to all above comments, now I understand "shadow redundancy is not guaranteed delivery from source to destination, just from hop to hop" as endital1097 explained

But...

Akhater says: "With Exchange 2010 Microsoft tries to make hardware "disposable" meaning that any failing hardware can be replaced without any impact or data loss"

The document talked about an example of an Hub trying to deliver a msg to an Edge, after delivery, it query the Edge for confirmation of delivery, but failed to talk to the Edge, it then resent the msg from Shadow queue to another Edge for delivery. sounds great!!! but what about in a senario that the very first Hub server picks up whole bunch of messages from a Mailbox server, but before it tries to deliver them, it fails. will that cause any data lost? it answer is YES, how can Microsoft make hardware "disposable".

My understanding is the shadow Redundancy is for data protection between hub to hub/edge communication, not for mailbox to hub communication. If a hub fails, there will be data lost if it didn't deliver msgs which it picked up from mailbox servers. this can be very common, i think, when a hub fails
0
 
endital1097Commented:
take a look at the following:
http://technet.microsoft.com/en-us/library/dd351091.aspx

but to answer your question (taken from link)

Message submissions from MAPI or Windows Mobile clients aren't redundant. After the message is successfully stored on the Mailbox server, Exchange high availability features can take effect and help prevent data loss. This scenario provides a complete picture of message flow, from beginning to end.
0
 
AkhaterCommented:
The document talked about an example of an Hub trying to deliver a msg to an Edge, after delivery, it query the Edge for confirmation of delivery, but failed to talk to the Edge, it then resent the msg from Shadow queue to another Edge for delivery. sounds great!!! but what about in a senario that the very first Hub server picks up whole bunch of messages from a Mailbox server, but before it tries to deliver them, it fails. will that cause any data lost? it answer is YES, how can Microsoft make hardware "disposable".


no the answer is no since, in this case, they are still on the mailbox server. Mailobx -> hub messages are also redundant with shadow redundancy.

for the Mailbox server, however, you will need DAG for redundancy
0
 
JerryJayAuthor Commented:
many thanks to Akhater and endital1097. good answers! appreicate all your help here.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 3
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now