I have two separate physical sites, Site A and Site B. In site A, I have following:

  • 2 CAS servers
  • 2 Hub Transport servers
  • 2 Mailbox servers
  • 2 Edge servers

In site B, I have the following:

  • 1 CAS
  • 1 Hub
  • 1 Mailbox
  • 1 Edge

Currently everything is working out of site A. That is, all users are housed on mailboxes that are in site A and all inbound mail flow is pointing to site A. I would eventually like to be able to move some of the mailboxes to site B without causing a disruption for resliency and redundancy purposes but I am not quite sure how to go about setting this up or if it is even possible.

So far I have created an Edge subscription in site B and am able to send emails out from test accounts set up with mailboxes on the site B Mailbox server. However, I am unable to receive incoming mail messages and am confused.

So I'm thinking incoming mail messages are still being directed to site A and then they are getting stuck because there is no way to route the mail to the site B mailboxes. Is this assumption correct? I am unfamiliar with mail flow and routing so I am not really sure what I need to be looking at?

Would I add the site B hub transport to the Edge subscription in site A? Or I guess more specifically, how would I go about enabling communication and mail flow between mailboxes split up on site A and B?

EDIT Update

Per the suggestion of @Massimo I have done some additional testing. Here is some supplemental information, I hope it helps. I can open up a new question if necessary.

I am able to telnet on port 25 to each of the Hubs from every other Hub.

After flipping mailbox database DAG to site B here are the initial results:

  • I am able to send test emails internally from Site B user to site A user.
  • I am unable to receive test emails internally from site A user to site B user.
  • I am able to send external emails through site B Edge.
  • I am unable to receive emails to site B user.

Where shoud I start looking in order to begin troubleshooting this? At this point is it safe to say there is a mail routing issue?


Intra-organization routing always happens between Hub Transport servers; this is an automated process and doesn't need any action on your own to function.

If a message addressed to a user whose mailbox is in site B gets into Site A (either because it was generated by an user in Site A, or because it was received by an Edge server in Site A), one of Site A's HT servers will relay it to Site B's HT server, which will then deliver it to the destination mailbox; if this isn't happening, then you have mail routing problems between your sites, and you should fix them before anything else. As an easy test, have an internal user in Site A send a message to another internal user in Site B, and see if that gets delivered. If it doesn't, stop here and fix mail routing between the two sites (open a new question if needed, this may require some troubleshooting).

Then, about incoming external messages: their path is defined by the MX records for your SMTP domain(s), which are stored in the public DNS for these domains. If these records point to Site A's Edge servers, incoming Internet messages will be delivered to Site A, which will then deliver them to Site B using the above-described process. You can (and should) add a third MX record pointing to Site B's Edge server, and then some (roughly 1/3) of the incoming messages will be delivered there; but you will have no way to configure things so that messages addressed to users in Site A gets delivered to Edge Servers in Site A (and the same for Site B), unless you use different SMTP domains for the two sites.


About the DAG:

Users' mailboxes are stored on a Mailbox Database, which, when its Mailbox server is a DAG member, can have one active copy and one or more passive copies; then:

  • Users which have their mailbox stored on that database connect to the active copy (actually, to a CAS server in the same site where the active copy is).
  • Messages generated by those users are sent from the Mailbox server hosting the active copy to a HT server in the same site, which then delivers them to their next step.
  • Messages addressed to those users are delivered to a HT server in the same site of the Mailbox server hosting the active copy (if they are anywhere else) and then from the HT server to that Mailbox server.

You want to have your users as near as possible to the Mailbox server hosting the active copy of the database storing their mailboxes, so you should create at least two databases: one for Site A users, and one for Site B users; then, place the active copy of Site A database on one Mailbox server in Site A, (possibly) a passive copy on the other Mailbox server in the same site, and a passive copy on the Mailbox server in Site B; for the Site B database, do the reverse.

About mail routing

Yes, it should work out of the box. If it doesn't, you need to troubleshoot it. First test: can HT servers resolve each other's names, and are they able to connect between themselves using TCP port 25 (SMTP)? What do you get if you perform a telnet SiteBHT.your.ad.domain 25 from a HT server in Site A?

  • I was thinking the mail routing was supposed to work out of the box with the Hubs... I will test the internal mail routing and get back to you. Thanks. – jmreicha Nov 7 '12 at 0:05
  • Answer has been updated. – jmreicha Nov 7 '12 at 3:21
  • Maybe you mean "question"? Now answer has been updated :-) – Massimo Nov 7 '12 at 7:50
  • Heh, yeah sorry that's what I meant. Thanks for your updated answer. As for the DAG stuff, I think my understanding is ok there. The whole reason for this is for an upcoming disaster recovery scenario so the higher ups want to make sure that there is something in place if users are required to user site B. – jmreicha Nov 7 '12 at 14:16
  • Also, I am able to telnet from every hub to every other hub on port 25. – jmreicha Nov 7 '12 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.