While reviewing both my shared and dedicated SaaS environment, I noticed the Test Connection under GROUPS & SETTINGS -> All Settings -> System -> Enterprise Integration -> Email (SMTP) fails for some reason.

In case you have yet to configure this setting, check out the link below for details.

System / Enterprise Integration / Email (SMTP)

I do know email alerts, such as enrollment and compliance, are being sent properly. This is particularly important as we configure enrollment through QR code only. I’m still curious to find out what would cause the test connection to fail.

While working with VMware support, we verbosed the ACC log and replicated the issue. We then find the below in the log:

The error message is pretty clear, and VMware support offers the solution below:

1. Create a new receive connector so we do not affect other applications that use the default connector.
2. Make sure that on the network tab you specify the IP of the AirWatch Console Server. ***This is critical! When you add a new receive connector, it defaults to allow ALL IP addresses to send email through the exchange server. This will allow bots on the internet to send spam through the exchange server. Be sure to delete the default IP address in the connector and specify the IP address of the AirWatch console server.***
3. Then match up the following authentication and permission group settings:
a. Under the Authentication tab, only have Externally Secured checked.
b. Under the Permission Groups tab, only have Anonymous users and Exchange servers checked.

When I shared this information with my MS Exchange team, I learned the current setup indeed causes this test connection to fail. The mail relay is purposely disabled for external recipients on the connector, but it does allow mail forwarding to internal recipients (i.e. those meant for our domain.) Chances are, the email address configured for test connection is outside of our domain.

For this test connection to work, we will need another connector which will allow mail relay to external recipients. This does require the web console IP address(s) or hostname to be added to the access list of the connector. There will be no noticeable difference with sending the alerts except they will now be sent via a different connector.

So for me, the choice really depends on what is best for your environment. More important is that proper documentation is in place to avoid any future confusion.