[Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 492
  • Last Modified:

How internal hub transport mail flow works between exchange servers

How internal hub transport mail flow works between exchange servers in an organization.
0
Yogesh_Exchange_Expert
Asked:
Yogesh_Exchange_Expert
  • 15
  • 12
1 Solution
 
AkhaterCommented:
what do you mean by how ?

mailbox server delivers to hub1 in the same ad site as the sender's mailbox

hub1 delivers to other hub2 in the same ad site as the recipient mailbox

Hub2 delivers to the mailbox server on which recipient mailbox exists.


if both sender and receiver are in the same ad site then mailbox deliver to hub and hub to mailbox

0
 
PostmasterCommented:
If you have worked with older versions of Exchange there used to be a Message Transport Agent (MTA).
Effectively this role is done by the Hub servers, so mailbox servers cannot move mail anywhere, the Hub does the moves.
This means that even a message from one mailbox to another in the same database must go via a Hub.
They are the "pipes" through which the exchange mail flows.
0
 
Yogesh_Exchange_ExpertAuthor Commented:
is there any use of site and services for mail flow from hub to hub.
0
Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

 
AkhaterCommented:
Yes did you read my reply first in this thread? I explained it for you
0
 
Yogesh_Exchange_ExpertAuthor Commented:
like see what is the scenario here hub2007 kept in differenet AD site and hub2010 kept in different AD site. is there any settings we have to do in site and services.
0
 
AkhaterCommented:
no there is no settings to be done in AD sites and services, the HUB servers will know alone in which AD site they are and mail flow will happen as I pointed in my reply earlier
0
 
Yogesh_Exchange_ExpertAuthor Commented:
then any setting you know which we have to mention in both hub servers so that they start knowing each other  right now i am getting these error while doing message tracking.

The message has been queued on server 'dc-u' since 10/19/2011 8:47:42 AM (UTC-07:00) Mountain Time (US & Canada). The last attempt to send the message was at 10/19/2011 9:25:21 AM (UTC-07:00) Mountain Time (US & Canada) and generated the error '451 4.4.0 Primary target IP address responded with: "451 5.7.3 Cannot achieve Exchange Server authentication." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.'.

0
 
AkhaterCommented:
No there is nothing to do on the hubs either you should have stated from the start you have a problem !

try to telnet from one server to the other on port 25 what is the reply ?
0
 
Yogesh_Exchange_ExpertAuthor Commented:
telnet is working fine.
0
 
AkhaterCommented:
what do you mean by working fine? what is the result ?
0
 
Yogesh_Exchange_ExpertAuthor Commented:
i tried sending through helo and ehlo but no use mails stills in the queue.
0
 
AkhaterCommented:
please jut telnet from server1 server2 port 25 and give me the reply, copy paste it
0
 
AkhaterCommented:
listen I just saw your other questions but the errors are different in both so which one are you getting ?

the authentication error is usually due to a firewall smtp inspection



1. Make sure you can telnet from one to the other and that you are getting the Exchange banner as reply
2. Make sure that SMTP inspection is DISABLED on the firewalls
3. make sure DNS resolution is working between the two
0
 
Yogesh_Exchange_ExpertAuthor Commented:
SMTP inspection is disabled if it possible that will work if disable esmtp other resuls i will give you soon.
0
 
Yogesh_Exchange_ExpertAuthor Commented:
telnet results

220 ****************************************************************************
******************
0
 
Yogesh_Exchange_ExpertAuthor Commented:
DNS resolution is also working fine.
0
 
AkhaterCommented:
no 220*********************** means exactly that it is pix firewall that is answering to you and not exchage so SMTP inspection is NOT disabled, your pix should NOT deal with SMTP traffic that's the problem
0
 
Yogesh_Exchange_ExpertAuthor Commented:
if smtp inspection is disabled then what message i will get by doing telnet
0
 
AkhaterCommented:
you should get the exchange banner. something like

220 exchange.domain.com Microsoft ESMTP MAIL Service ready at Wed, 19 Oct 2011 22:45:56 +0530
0
 
Yogesh_Exchange_ExpertAuthor Commented:
no smtp inspection is disabled i have verified what about esmtp
0
 
AkhaterCommented:
both, the firewall should not interfere with SMTP at all, it should just let it pass. I have seen this many times you should see the echange banner
0
 
Yogesh_Exchange_ExpertAuthor Commented:
i am not getting you please explain.
0
 
AkhaterCommented:
when you telnet from one server to another you should see the exchange banner, it will look like


220 exchange.domain.com Microsoft ESMTP MAIL Service ready at Wed, 19 Oct 2011 22:45:56 +0530



you should NOT get 220***********************


talk to your firewall guys
0
 
Yogesh_Exchange_ExpertAuthor Commented:
ok i have escalated them they are working on it.
0
 
Yogesh_Exchange_ExpertAuthor Commented:
tried to disable esmtp service but no use and smtp inspection is already disabled.
0
 
Yogesh_Exchange_ExpertAuthor Commented:
we have asked the client also to do the settings at their end lets see whats the results we will get.
0
 
Yogesh_Exchange_ExpertAuthor Commented:
we have disabled disable esmtp service and issues resolved.
0
 
AkhaterCommented:
Thank you for the updates and the points
0

Featured Post

Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

  • 15
  • 12
Tackle projects and never again get stuck behind a technical roadblock.
Join Now