asked on
Messages stuck in Exchange 2007 queue
Hello,
We have Exchange 2007 running on Windows 2K8 R2 that is running solely to send daily report emails from application servers (Network monitoring, Backup, etc). After a scheduled full power outage these emails are now piling up in the message queue with the Last Error 400 4.4.7 Message delayed". Filtering Event logs to the MSExchange Transport source shows the 6 days since the power outage filled with Event ID 1000 'The service is trying to start'.
After this service finally started, the logs then show Event ID 5006, 5008, 5009 and 5026 Routing warnings. The next day Event ID 12014 began showing up; referencing a missing certificate and an inability to "...support the STARTTLS SMTP verb for the connector Barracuda DHHQ SMTP1 with a FQDN parameter of xxxxxxxx.xxxxxxxx.dom"
This transport server is for outbound mail only. Our organization has email service through a different cluster but our internal monitoring applications use this local Exchange server to send daily report messages. No inbound mail comes to it. I believe it still sends mail through a Barracuda filtering device; I do not yet have access to it yet but I'm wondering if there's anything on the Exchange side that is behind these messages no longer flowing. Thanks!
We have Exchange 2007 running on Windows 2K8 R2 that is running solely to send daily report emails from application servers (Network monitoring, Backup, etc). After a scheduled full power outage these emails are now piling up in the message queue with the Last Error 400 4.4.7 Message delayed". Filtering Event logs to the MSExchange Transport source shows the 6 days since the power outage filled with Event ID 1000 'The service is trying to start'.
After this service finally started, the logs then show Event ID 5006, 5008, 5009 and 5026 Routing warnings. The next day Event ID 12014 began showing up; referencing a missing certificate and an inability to "...support the STARTTLS SMTP verb for the connector Barracuda DHHQ SMTP1 with a FQDN parameter of xxxxxxxx.xxxxxxxx.dom"
This transport server is for outbound mail only. Our organization has email service through a different cluster but our internal monitoring applications use this local Exchange server to send daily report messages. No inbound mail comes to it. I believe it still sends mail through a Barracuda filtering device; I do not yet have access to it yet but I'm wondering if there's anything on the Exchange side that is behind these messages no longer flowing. Thanks!
ExchangeWindows Server 2008Email Servers
Last Comment
Jonnie106
Check first that the power failure didn't set one of the involved systems clocks off... Some system might have lost time and started up with a default start time...
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
I still do not have access to the Barracuda to check its time. I have found that while there is a less than two-minutes difference between the Exchange system clock and say, my workstation, this disparity has existed for many months, during which the sending of these daily emails worked flawlessly.
In editing the Send Connectors to use TLS I found it required un/pw credentials, which I could not provide. We use two factor CAC to authenticate in most cases here; username/password accounts are somewhat specific to their uses. A service account's credentials would normally be used here but I'm not aware of any account used exclusively for TLS and I don't think it was configured with one 3 weeks ago when this was working.
I also discovered three send connectors, one disabled. the disabled ones' Network settings are to 'Use domain name system (DNS) MX records to route mail automatically'. The first enabled connectors Network tab uses, 'Route mail through the following smart hosts:' and it lists an IP address and a domain name, which happens to resolve to the same IP. The second enabled connector also has 'Route mail..' selected but lists 3 domain names (Pri.xxxxx.xxx.mil, Sec.xxxxx.xxx.mil and tri.xxxxx.xxx.mil) the first two resolve to two different groups of 4 IP addresses. the third returns non-existent domain.
I enabled this disabled connector and restarted the Transport service. Another queue was created in the queue viewer and all the stuck messages went into this queue but nothing delivered. With no change in behavior I disabled this connector. Moments later the new queue was gone and the stuck messages were back in the original queue, except now there is a different error:
I
451 4.4.0 Primary target IP address responded with: "421 4.2.1 Unable to connect." Attempted failover to alternate host, but that did not succeed. Either there are not alternate hosts, or delivery failed to all alternate hosts.
In editing the Send Connectors to use TLS I found it required un/pw credentials, which I could not provide. We use two factor CAC to authenticate in most cases here; username/password accounts are somewhat specific to their uses. A service account's credentials would normally be used here but I'm not aware of any account used exclusively for TLS and I don't think it was configured with one 3 weeks ago when this was working.
I also discovered three send connectors, one disabled. the disabled ones' Network settings are to 'Use domain name system (DNS) MX records to route mail automatically'. The first enabled connectors Network tab uses, 'Route mail through the following smart hosts:' and it lists an IP address and a domain name, which happens to resolve to the same IP. The second enabled connector also has 'Route mail..' selected but lists 3 domain names (Pri.xxxxx.xxx.mil, Sec.xxxxx.xxx.mil and tri.xxxxx.xxx.mil) the first two resolve to two different groups of 4 IP addresses. the third returns non-existent domain.
I enabled this disabled connector and restarted the Transport service. Another queue was created in the queue viewer and all the stuck messages went into this queue but nothing delivered. With no change in behavior I disabled this connector. Moments later the new queue was gone and the stuck messages were back in the original queue, except now there is a different error:
I
451 4.4.0 Primary target IP address responded with: "421 4.2.1 Unable to connect." Attempted failover to alternate host, but that did not succeed. Either there are not alternate hosts, or delivery failed to all alternate hosts.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
It resolves to a different IP address than the Exchange server. I assume it's the Barracuda. Changes in the org chart and consolidation of devices has made the Barracuda unavailable to me for quite some time now. I will now earnestly begin beating bushes to get access to the spam firewall, which has been the cause of stuck mail in the past, when it was our device to manage.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.