Exchange 2013 - Outbound Mail

Hi there,

Hope you can help :)

We have 3 Exchange 2013 Mailbox Servers as part of a DAG, each server has it's own NAT rule to send mail out via smart host (message labs)

Each host needs to be added into Message Labs to be part of an "Authorised outbound IP Address" list to send mail to them, we removed 1 of them as a test and mail was held in the queue with the error "open relay not allowed" which was expected... however I had to run the PowerShell command "Redirect-Message" to forward mail out of another MBX server.

Is there anything I need to configure so the mail will auto retry out of one of the other MBX servers in the DAG? I thought the shadow redundancy queue would of sorted that but maybe I'm wrong....

Hope that makes sense!

Many Thanks :)
TerellionAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Guy LidbetterCommented:
Hi Terellion,

The Shadow Redundancy Queue does not route mail, it only holds a copy of the email until successful delivery of the mail to the next hop. ( for redundancy ;-p )

The only thing you can do for complete mail flow redundancy in this case is create a send connector for each server, increasing the cost for each one. Mail will always flow through one mailbox out, but if it fails mail will automatically flow through the second, then third.

If you are worried about mail volume, have one send connector with two servers and a second connector at a higher cost with the third server as a backup.

Regards

Guy

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
TerellionAuthor Commented:
Hi Guy,

The email kept on retrying but it just showed as "Open Relay not allowed" and wouldn't try using another one of the MBX servers, all the MBX servers are in the same connector with the same cost so you'd think it would try out of the other MBX servers?

Very weird :(
Guy LidbetterCommented:
No it wouldn't... if a server in a connector has a routing issue, the mail will queue. .

With all servers in the same connector, they all have the same cost, and assumed same edge exit route. The system assumes that the path would be made redundant in some way (e.g. load balancing), and will always be available. If the route is down, the servers in the connector would take the same logical path so there's no point in letting someone else try as they would be down too... so the fail back would be a second connector at a higher cost.
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Simon Butler (Sembee)ConsultantCommented:
I am not entirely sure the higher cost connector would be used for this scenario.

In my experience the scenario you have posted - a connection being made and then being refused - does NOT cause the Exchange server to reprocess the message through another route. It presumes the remote side has a problem and queues the message.

The only time I have seen email be reprocessed is when the remote server does not respond.

In that case your testing method was flawed. If you wanted to ensure that email would flow in the event of a problem at your end, you need to block one of the servers from connecting to the internet, rather than removing it from Message Labs.

Your original design of one Send Connector is what I would have done - I tend to use a single Connector per AD site, rather than a connector per server - UNLESS the servers are using different ISPs or have a 1:1 NAT and I need to have unique FQDNs on the Send Connector.

Simon.
TerellionAuthor Commented:
Right... I removed the mailbox server from the send connector and it re-routed the mail automatically which was perfect so I thought if a mail was queued due to an issue at Message Labs it would do the same?

Makes sense so I guess i'd just have to rely on maybe detecting if the queue gets to a certain amount and then "Redirect-Message" to another MBX Server?
Simon Butler (Sembee)ConsultantCommented:
You should be monitoring the queues anyway. As you are using Message Labs, if the queue goes above three or four then that would be an alarm.

Simon.
TerellionAuthor Commented:
Okay understood thanks very much for your help :)
Guy LidbetterCommented:
I assume the reasoning behind the test, is if a mailbox somehow failed to deliver due to a networking failure would it reroute?

@Simon : Terellion did state that there is a 1:1 NAT. So the multiple send connectors are a viable option.

In the very very unlikey event Messagelabs drops your IP on their receive connector, or you change your external NAT for one of the servers and forget to update them with it, as Simon stated, you would receive the "denied" error as expected and the message would queue. But I don't see this as being a probable issue.

So we are down to a drop connection, and the secondary connector comes into play.
TerellionAuthor Commented:
Hi Guy,

Yep that was the reason behind the test, we don't want mail queuing really... if it does queue then to auto re-route out of another mailbox server but it probably makes sense to just monitor the queues and then I can maybe set up a scheduled powershell script for something like if the queue exceeds 50 or 100 then to redirect all mail to another mailbox server...
Guy LidbetterCommented:
Hi Terellion,

Although active monitoring of the queue is something you should be doing anyway, in the case there is a send issue with a single connector, it is always a good idea to have an alternative path if you have the option.

In scenarios where a single external address is used, you are limited, however you have 3 NAT's going to Messagelabs, I would most definitely leverage this with the backup connector model. This is especially useful as you do not require the use of an external powershell script to pick up a queue and redirect - it would be automatic.

If the issue was on the messagelabs side, no amount of redirection would resolve the issue, so your script would be draining and redirecting constantly until the issue is resolved. A secondary higher cost connector once failed would queue and sequentially retry until the connection is resolved without moving the messages back and forth.

The script then would be far more useful to pick up the queue and notify you of this fact because then you really do have a problem you need to look into.
TerellionAuthor Commented:
Hi Guy,

Sounds good to me thanks very much for your help :)
TerellionAuthor Commented:
Hi there,

Please can you re-open and i'll close off with the correct answer.

Thanks
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.