SMTP Messages Hanging in queue

I just put a new Exchange 2003 Server in my previously all Exchange 2000 organization.  I set it up to be a front-end SMTP and HTTP server for several back-end servers.  For some reason though, anything sent from this new server to ANY other server in the organization just hangs in the SMTP queue.  The queue information just tells me that "The semaphore timeout period has expired.".  I verified that DNS is working fine and that I can ping and browse to all of these other Exchange servers.  There is nothing in the event logs that would indicate any problems.  Thoughts?
LVL 4
neisnerAsked:
Who is Participating?
 
marc_nivensConnect With a Mentor Commented:
Even with all ports open, some firewalls (PIX for example) still do application layer filtering of SMTP traffic.  Certain verbs that are required for servers within a routing group to communicate are cut off.  To rule this out, I would do the following:

1.  Create another routing group
2.  Put the FE server in that routing group alone
3.  Setup SMTP connectors between the RG's (not Routing Group Connectors)
4.  On the advanced tab of the SMTP connector, specify use helo instead of ehlo

This will effectively bypass any filtering of extended verbs that could be going on.  If it works, try unchecking specify helo instead of ehlo and see if that works.  If it doesn't, you know that the firewall is blocking certain ESMTP verbs.
0
 
MicrotechCommented:
May sound strange .. but what have you called your mail server and the connectors... I have seen this problem before...an underscore was used

here is the ref http://support.microsoft.com/default.aspx?scid=kb;en-us;841091&Product=exch2003
0
 
neisnerAuthor Commented:
Nope, nothing weird in the server or connector names.

One thing I forgot to mention earlier, I made this new server the master for its routing group since it is supposed to replace the current master.  Don't know if that makes any difference...
0
Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

 
marc_nivensCommented:
It actually could make a difference if there is a firewall between the front end and back end.  If the servers in a routing group cannot communicate with the master over port 691, then link state will mark the servers as down and mail will just queue up for those servers.  You can verify whether or not this is happening by running a winroute:

http://www.microsoft.com/downloads/details.aspx?FamilyId=C5A8AFBF-A4DA-45E0-ADEA-6D44EB6C257B&displaylang=en

Just run it, connect to the front end, and see if the other servers show a red x.  If they do, thats probably your issue.  The recommended fix would be to open port 691, an alternative would be to either make the FE its own RG or make another server the master.  

Oh, and if you want to run winroute against any of the 2000 servers, you will need the 2000 specific version (the above is for 2003).  That one comes on the E2k CD.
0
 
SembeeCommented:
Have you put anything in the SMTP virtual server on these machines in the box for SMART HOST? This is the most common mistake as it upsets the routing of the messages.

Can you telnet to port 25 from the troublesome machine to the backend server?

Simon.
0
 
neisnerAuthor Commented:
This new server is in a DMZ, but I allowed all traffic between this box and the other Exchange servers to try to get this going.  I did the winroute as suggested, and there are all green checks next to the other servers.

There is nothing in the Smart Host field for any of the servers.  And yes, I can telnet to port 25 from the new server to all of the back end servers.

Any other suggestions?
0
 
BNettles73Commented:

Have you used telnet to SMTP from both servers to thoroughly test connectivity?
http://support.microsoft.com/default.aspx?scid=kb;en-us;153119

Use Queue Viewer to identify which queue the messages are hanging up in ... if "Awaiting Directory Lookups" you are probably having a GC or DNS issue.

Do you have a DC/GC in the DMZ - if not, have you configured the proper ACL's to allow access?
You should not have any mailboxes or public folders on the Frontend Server. The best practice is to dismount and delete all databases on your server and then disable the Exchange Information Store Service.

After you have successfully placed this server in the DMZ you need to configure the appropriate ports on the firewall.

On the intranet firewall (which connects the DMZ and the internal network) open the following ports:

For Exchange Communication:
Port 80 for HTTP
Port 691 for Link State Algorithm routing protocol
For Active Directory communication:
Port 389 for LDAP (TCP and UDP)
Port 3268 for Global Catalog Server LDAP (TCP)
Port 88 for Kerberos Authentication (TCP and UDP)
Note: You should now configure the DSAccess service for perimeter networks on your Frontend Server. At first you should disable the check for available disk space at netlogon by using RPC. This can be done by changing the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
Registry Value: DisableNetlogonCheck
Value Type: REG_DWORD
Value Data: 1

In addition to this you should prevent DSAccess from pinging domain controllers. This can be done by creating the following key on your Frontend Server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
Registry Value: LdapKeepAliveSecs
Value Type: REG_DWORD
Value Data: 0

Then you should configure your Exchange Frontend Server to connect to the DC and GC you want by editing the server properties in Exchange System Manager.

For DNS communication:
Port 53 for DNS (TCP and UDP)
For RPC communication:
Port 135 – RPC endpoint mapper (TCP)
Ports 1024 and higher for RPC services
Note: You can limit RPCs across the firewall by editing the registry of all your DCs. You should now change the registry setting of the following key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Registry Value: TCP/IP Port
Value Type: REG_DWORD
Value Data: (available port)

If you are using IPSec between Frontend- and Backend Servers you have to open:

Port 500 for IKE (UDP)
Port 51 for Authentication Header (AH)
Port 50 for Encapsulation Protocol (ESP)



Other Articles:
Considerations for E2K3 Front-End - http://support.microsoft.com/default.aspx?scid=kb;en-us;822443
E2K3 Technical Library - http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/default.mspx

0
 
neisnerAuthor Commented:
For troubleshooting purposes, I opened ALL traffic from this new server to ALL backend Exchange servers and domain controllers.  Still no good though...

Yes, I have tested SMTP connectivity and everything looks good.  The messages aren't hanging up in the Awaiting Directory Lookup queue, they are in the SMTP queues for each back-end server.
0
 
BNettles73Commented:

Did you run Forest Prep and Domain Prep again after you introduced the new E2K3 box?
0
 
neisnerAuthor Commented:
No...  I did before introducing it of course...
0
 
BNettles73Commented:
Also ... M$ released a new FE/BE for E2K3 and E2K document just a few days ago ....


Exchange Server 2003 and Exchange 2000 Server Front-End and Back-End Topology
http://www.microsoft.com/downloads/details.aspx?familyid=e64666fc-42b7-48a1-ab85-3c8327d77b70&displaylang=en

0
 
marc_nivensCommented:
If you have multiple NIC's check the binding order too...
0
 
BNettles73Commented:


- You could also turn up logging on MSExchangeTransport and MSExchangeMTA to MAX and review events.

I'm out of ideas for now but if I think of anything else I'll let you know.
0
 
neisnerAuthor Commented:
Ahhh, this sucks...  Still no luck...

I do have multiple NICs doing teaming, but they are only using a single IP address.  I already upped the logging on those two, and nothing worthwhile shows up in the logs.

I am about out of ideas too...  Anyone have any more suggestions?
0
 
SembeeCommented:
There are NO advantages to putting an Exchange server in to the DMZ. The amount of holes that you have to punch through the firewall make it in to swiss cheese.
Bring both servers inside the firewall and punch just port 443 (SSL) and 25 (SMTP) through the firewall. That is a lot more secure.
If the machine in the DMZ gets comprimised then the attacker has a straight run in to your network.

Simon.
0
 
marc_nivensCommented:
Couldn't have said it better myself :-)
0
 
neisnerAuthor Commented:
Well, still no luck.  I got sick of messing with it, so I moved the server out of the DMZ.  Everything started working fine afterwards, so i guess it was the firewall (which is a PIX by the way).  Thanks for the help guys...
0
All Courses

From novice to tech pro — start learning today.