The IT Service Excellence Tool Kit has best practices to keep your clients happy and business booming. Inside, you’ll find everything you need to increase client satisfaction and retention, become more competitive, and increase your overall success.
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!
Who is Participating?
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
I wear a lot of hats...
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
LVL 15
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?
Experts Exchange Solution brought to you by
Your issues matter to us.
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
Start your 7-day free trial
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.
The Barracuda in question is being retired. We've pointed SMTP apps to our sister site's Barracuda filter and mail has resumed. The powers that be deemed this workaround to be easier than renewing support on a defunct appliance on its way out. Thanks for all input!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange
From novice to tech pro — start learning today.
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.