• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 332
  • Last Modified:

Exchange server 2007 mail flow halted

I have a SBS server 2008 with Exchange and the useres reported that they were no longer receiving email.

I investigated and found the cause most likely to be the Back Pressure issue. I edited edgetransport.exe.config to chance the monitoring line to false, then proceeded to clean up the C: drive (mostly old log files) to fre up space.

After editing the file the edgetransport service refused to start so i restored the backup file and it still refused to start.

Following a tip off technet i changed the account the service ran under to the local system account and the service started but users are still not receiving email and they can no longer send out as well.

Checking the logs the only error i could find was error 12014.

Any help would be greatly appreciated.
0
BrandanC
Asked:
BrandanC
1 Solution
 
Shreedhar EtteCommented:
Run Exchange 2007 Best Practise Analyser from the Tools under Exchange Management Console and fix the errors reported.
0
 
abhijitmdpCommented:
If you are getting the error 12014. It means that some how you have broken your certificate installed on your servers. You'll need to go through below process to check for the certificate:
1. Open "Exchange Management Shell".
2. Write "get-ExchangeCertificate" and press on "Enter" button.
3. Write down the Thumbprint of the certificate that reflect the required FQDN name of the server.
4. Review the current certificate that use by the Exchange server and each certificate function.
5. Write "Enable-ExchangeCertificate -Thumbprint 2rtd265417915234ad096c48eb3b847fc7457662 -Services "SMTP" and press on 'Enter" button.
The value of -Thumbprint obtained in stage 3.
6. Restart the Exchange server.

For referance you can follow below links as well:
http://social.technet.microsoft.com/Forums/en/exchangesvrsecuremessaging/thread/9039f2c4-58ec-4171-aafd-22b5ef376a82
http://support.microsoft.com/kb/555855
0
 
BrandanCAuthor Commented:
Alright i went the steps to re-enable the Certificate however that did not restore mail flow.

The best Practices Analyser came back with one critical error related to backups.

All the rest were warnings realted to drivers except for three that say

The 'Host' (A) record for server SERVER.ADname.local cannot be retrieved from DNS server '192.168.0.1'. This can cause message routing delays and other service failures. Verify that the DNS server is online and that the 'Host' record is present.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
BrandanCAuthor Commented:
Also the required FGDN name is that the external name of the server or the instal AD name of the server?
0
 
BDoellefeldCommented:
You for sure want to pay attention to this problem:
The 'Host' (A) record for server SERVER.ADname.local cannot be retrieved from DNS server '192.168.0.1'. This can cause message routing delays and other service failures. Verify that the DNS server is online and that the 'Host' record is present.


Is 192.168.0.1 the SBS server or something else? Since the server is SBS it should be pointing to itself. Also, if you are using DNS forwarders recheck are they valid.
0
 
BrandanCAuthor Commented:
192.168.0.1 is the router. 192.168.0.2 is the SBS server.

the DNS server is online and the Host record is in there. I double checked and in the LAN config the SBS server is set as the primary DNS server. The DNS forwarders are valid and appear to be working just fine.

What's weird is that if i send or receive email from this server it ends up in the submission queue so it navigates tot he server but it never hits mailboxes or makes it out to the outside world.
0
 
BDoellefeldCommented:
This still sounds like some form of DNS issue to me. If Exchange cannot get a DNS result for a MX record the mail will sit in queue.

Is DNS running on the SBS server?

Since 192.168.0.1 is the router then its most likely pointing to some external DNS which of course cannot resolve your "ADname.local" zone. Whatever internally that is pointing to 192.168.0.1 for DNS you need to change to point to internal DNS would which should be the SBS server (as long as DNS is operational on it). As long as the forwarders are good... (maybe give Google Public DNS at 8.8.4.4 or 4.4.4.4 a shot)

With this error mentioning 192.168.0.1...
The 'Host' (A) record for server SERVER.ADname.local cannot be retrieved from DNS server '192.168.0.1'. This can cause message routing delays and other service failures. Verify that the DNS server is online and that the 'Host' record is present.
...then its pretty clear the server is either not looking at itself for DNS or you have an entry in the host file that may be pointing it incorrectly.
0
 
BrandanCAuthor Commented:
Does Exchange get its DNS server information anywhere else besides from the configured adapter?

The local adapter has 192.168.0.2 as the primary and then

192.168.0.1 as the alternate.
and two more alternates of 4.2.2.1 and 4.2.2.2
0
 
BrandanCAuthor Commented:
To add additional information:

After running the mail flow troubleshooter the error message i get when running the "Messages to users are delayed or not received by som recipients" is:

Mail submission failed: Error message: Server does not support secure connections..
0
 
BrandanCAuthor Commented:
Also all messages are piling up in the submissions queue, no other queues are showing.
0
 
BDoellefeldCommented:
Does Exchange get its DNS server information anywhere else besides from the configured adapter?

Yes its possible. Check the configuration on the (Internet) send connector, you should be able to see if it is using the hosts DNS settings for MX lookups or if a DNS server has been statically assigned to it.

What are the Transport logs showing? I'm not 100% sure about SBS but by default pretty sure this is the path.
C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpSend
 
0
 
BrandanCAuthor Commented:
It actually ended up being a problem with Forefront security. For some reason the administrator before me had installed a trial version of Forefront and left it that way. When i rebooted the Transport service the expiration took effect and killed all mail flow.

I de-integrated Forefront and the problem was resolved.
0
 
BrandanCAuthor Commented:
Turned out to be something completely unrelated to the original problem.
0

Featured Post

Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

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