Setup a SMTP Connector for Outbound Email to multiple Front End Servers?

We currently have multiple backend servers globally that are currently using smart host setups on each local Backend Exchange to forward email to the FrontEnd. We are looking to migrate to SMTP connectors to have more control over outbound and internal email. Is there a way or a guide that explains how to have the "*" SMTP Connector point to a certain FrontEnd servers depending on the backup server? The goal is to make Overseas BE servers route Outbound email out of the Overseas FrontEnd and the US based BE servers route Outbound out of the US based FE. I really don't want to cluster my FE servers.
We have the following.
MAIL - US FrontEnd
MAIL2 - OverSeas FrontEnd.
Server A -US Based Backend- Smart Host set to MAIL
Server B -US Based Backend- Smart Host set to MAIL
Server C -US Based Backend- Smart Host set to MAIL
Server D -US Based Backend- Smart Host set to MAIL
Server E -Overseas Based Backend- Smart Host set to MAIL2
Server E -Overseas Based Backend- Smart Host set to MAIL2

yes that's generally it except that unless there are some connectivity/bandwidth concerns the connector between the two routing groups should be a "Routing Group" connector, not an smtp connector.
This

Mardyc... One option might be to separate the US and overseas BE servers into separate routing groups (if they aren't already). You can then have two SMTP connectors with the * namespace that are scoped to the routing group.

So you would have two separate routing groups
- "US Routing Group" - would have server MAIL, and Servers A-D as members
- "Overseas Routing Group" - would have Server MAIL2, and Servers E-F as members

You would need to setup a Routing group Connector between the two Routing Groups

You would then also need two SMTP connectors to divide the traffic
Mail - US Frontend - Houses SMTP connector with * namespace and is scoped to the US Routing Group
Mail2 - Overseas Frontend - Houses an SMTP connector with the * namespace and is scoped to the Overseas Routing Group

You could then remove the smart host definitions on the BE SMTP Virtual servers.

Sorry, I should have specified that they are in the same routing groups. I would prefer to keep these servers in the same admin group due to our very tiny IT group for management purposes.
FYI - There are 2 domains within the Exchange org.

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

If they are all in the same routing group today then you could just create a new Routing Group called something like "Overseas"

- Move MAIL2, Server E and Server F to that new routing group (drag and Drop).
- Create a Routing group connector between the two RG's.
- Create a new SMTP connector with a Description of something like "Overseas", and add the SMTP Virtual Server of MAIL2 to the Bridgehead section. On the addresspace tab add the * namespace and at the bottom of that tab set the scope to "Routing Group".
- Change the existing SMTP connector to scope to the Routing group as well.
- Remove your smarthost definitions on the BE servers.
- Restart your SMTP services and Routing Engines.

Routing Groups will not have any affect on the rest of the Exchange setup until I place the SMTP connectors in place? I am trying to minimize down time with the adjustment to the system.
Any problems with this setup for OWA access or Blackberry Enterprise server? I guess worst case I can place it back to the same config I have now.
Can you take a look at my steps and let me know if you see a flaw in my plan?
Steps to follow.
Setup a new routing group.
Migrate the Non US servers to it.
Wait for replication and reboot moved servers (It is Microsoft after all) to be safe.
Setup SMTP connectors between the routing groups.
Setup Outbound SMTP Connectors in each routing group.
Final Config. 2 Routing groups. US Based (original First Routing Group) and Non US (new Routing Group) Both FE servers can still deliver external inbound email to all BE servers via the SMTP connector between groups. Same connector allows internal email to flow between BE servers. The other SMTP connectors (1 in each routing group) route outbound email to the proper FE server for delivery.

yes that's generally it except that unless there are some connectivity/bandwidth concerns the connector between the two routing groups should be a "Routing Group" connector, not an smtp connector.
This should not affect OWA accessibility or the BES environment per se but an interruption in mail delivery system wide would most likely imply that mail delivery through these alternate means is affected as well. As you suggested, worse case you back out all of your changes and go back to where you were.
Steps to follow
- Setup a new routing group
- Migrate Non US servers to it
- Wait about 15 mins for replication
- Create Routing Group connector between Original First Routing Group and Non US (New Routing group).
- Create new SMTP connector for Non US, with MAIL2 SMTP virtual server as Bridgehead and scope it to the Routing Group.
- Check original SMTP connector (used for US servers). Make sure MAIL SMTP virtual server is bridgehead and make sure it is scoped to the routing group as well.
- Remove Smarthost setting on all BE servers.

YOu might want to also verify SMTP security on all of your virtual servers to make sure they can talk to each other.

Once you've completed the configuration then I'd give replication a little time and do the Microsoft salute (reboot).

- Test mail flow from each back end out to the internet.
- Test mail flow between BE servers in different routing groups
- Ensure mail is taking expected paths by checking the header information.
- Test your other applications (OWA, BES, etc..)

Featured Post

Are you going to an event? Are you going to be exhibiting at a tradeshow? Talking at a conference? Using a promotional banner in your email signature ensures that your organization’s most important contacts stay in the know and can potentially spread the word about the event.

Local Continuous Replication is a cost effective and quick way of backing up Exchange server data. The following article describes the steps required to configure Local Continuous Replication. Also, the article tells you how to restore from a backup…

This process describes the steps required to Import and Export data from and to .pst files using Exchange 2010. We can use these steps to export data from a user to a .pst file, import data back to the same or a different user, or even import data t…

In this video we show how to create a Shared Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center.
Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center.
Navigate to the Recipients >> Sha…

In this video we show how to create an Accepted Domain in Exchange 2013. We show this process by using the Exchange Admin Center.
Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center.
Navigate to the Mail Flow >> Ac…