Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
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!
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
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...
It sounds like you're using a barracuda as a smart host and your send connector is not using TLS, yet your barracuda is requiring it.
Instead of creating a new send connector, you would just modify your original send connector.
https://technet.microsoft.com/en-us/library/ee428172(v=exchg.80).aspx
You can also configure the barracuda to consider your exchange server a trusted relay by changing the setting in "Relay Using Trusted IP/Range" under the BASIC tab. I "think" this will allow a TLS bypass, but this will also bypass the spam engine.
Instead of creating a new send connector, you would just modify your original send connector.
https://technet.microsoft.com/en-us/library/ee428172(v=exchg.80).aspx
You can also configure the barracuda to consider your exchange server a trusted relay by changing the setting in "Relay Using Trusted IP/Range" under the BASIC tab. I "think" this will allow a TLS bypass, but this will also bypass the spam engine.
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.
Assuming your energizer updates are current with barracuda, I'd file a support case. For some reason, your barracuda is rejecting your messages.
It resolves to the ip address of the barracuda or the exchange server?
'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
It resolves to the ip address of the barracuda or the exchange server?
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.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial