On a couple of engagements in the recent past, I encountered situations where I was configuring Inbound/Outbound mail for newly-installed vRealize Automation environments. Despite assurances from mail admins that settings provided to me by them were correct, I found that mail didn’t just work smoothly and I had to do some minor investigations. There isn’t much guidance on the web on where and how to look for issues so here are a couple of things to look at which I think will resolve most of such issues.
For example, you might get this error, when configuring “Inbound” or “Outbound” mail:
70064 – Connection failed. Check logs for detail.
Which log? I hear you ask. Well, those sort of events (and many others) are usually found in:
/var/log/vmware/vcac/catalina.out
on the primary vRealize Automation appliance. If you’ve just tried this, then
tail -100 /var/log/vmware/vcac/catalina.out | more
should point you in the right direction. If it was some time ago, the relevant messages might be buried deeper in the file, as it logs pretty much everything. In which case, replace “tail -100” with “cat”. There will be a lot of text so read patiently and carefully. A PuTTY session works much better than a direct console one, as you can fit a lot more text on it by resizing the window. Usually doing a “grep” for “send” cuts down on content but be careful as you might miss some important information that way.
I currently don’t have a screenshot or text handy for exactly which messages you will see in the log in case of failure but they will be along the lines of having created and sent the message/notification, the system was unable to confirm delivery of it. This along with the message shown above, is usually a sign that there are ports blocked between vRealize Automation appliance and the mail server. To check, one can use the following command:
netstat -c | grep -i <short name of destination server>
This command constantly looks for network connectivity between the local and destination machines (until cancelled using CTRL+C) and reports the current state of connections. As you can see from the screenshot above, it’s trying “smtp” and presence of “SYN_SENT” here basically means that it’s not getting through on smtp (or port 25). If this is what you’re seeing, it’s time to speak to someone who takes care of firewalls. Once this is fixed, hopefully you will be able to configure the mail correctly. Still doesn’t guarantee that the settings given to you by the mail admin were correct but at least, firewall should not be the issue.
Although the screenshots shown above are for “Outbound” or SMTP configuration, the same technique can be used for “Inbound” or IMAP/POP connections as well. You might also want to check if the destination server FQDN is correct, as a lot of organizations have different servers for POP or IMAP mail and I have been given the wrong destination by IT (on more than one occasion), assuming it would be the same.
All that said, you might be able to successfully configure say the “Outbound” connection and yet not receive any notifications. That happens because in most organizations, sending SMTP mail (especially unauthenticated) is protected by only allowing “known” servers to send mails through the mechanism. Sometimes, it’s hard to detect as the destination server just “drops” mails from unauthorised servers without a bounce or reply. The only indication in those case would be if you’re not receiving any notifications from the system. If you are confident that there isn’t a port block issue as discussed above, you should confirm with the mail admin if there is an allowed mail server list on the mail relay. If so, get your vRealize Automation appliances’ IP addresses added to that list and you should start getting the notifications soon after.
These techniques have helped me a few times so it would be great to know if you’ve also seen these issues and if this article was able to help you.
Thanks for sharing.