Error sending "Email": Connection failed ("smtp.office365.com")

Hi there,

Thanks for the nice formatting! :) Is this an actual o365 Exchange server? Or a plain outlook account?

Kind regards,
Stephan Linke, Tech Support Team

Hello,

[email protected] is a shared mailbox in cloud. smtp.office365.com is general relay address - I don't want to use specific exchange server for various reasons. SMTP relay best practice is described here:

https://support.office.com/en-us/article/How-to-set-up-a-multifunction-device-or-application-to-send-email-using-Office-365-69f58e99-c550-4274-ad18-c805d654b4c4?ui=en-US&rs=en-US&ad=US&fromAR=1

Time to enable the notification delivery debug log:

1. Open up regedit
2. Navigate to HKEY_LOCAL_MACHINE\Software\Wow6432Node\Paessler\PRTG Network Monitor\Server\Core\
3. Create the DWORD value LogNotificationDelivery and set it to 1
4. The log files will be generated with their timestamp as name in the following subfolders of the \Logs (Debug) folder in your PRTG data directory:

• Notification Delivery Debug Log (MX Server)
• Notification Delivery Debug Log (SMTP Relay 1)
• Notification Delivery Debug Log (SMTP Relay 2)
• Notification Delivery Debug Log (HTTP)
• Notification Delivery Debug Log (SMS)
• Notification Delivery Debug Log (Amazon SNS) (as of PRTG 15.4.21)

They should provide further insights. If you like, upload them and post the link to it.
I won't publish the posting, in case it contains confidential information. Make sure to disable it again.

Hi again,

thanks for the quick reply :)

After the LogNotificationDelivery key was added, and Core service restarted, only this shows in logs:

Stat Disconnected.
Stat Disconnected.
Error sending "Email": Connection failed ("smtp.office365.com")

Any firewall issues or something like that? Antivirus keeping PRTG Core Server.exe from connecting?

Windows Firewall allows all outgoing connections without limitations. Antivirus is not blocking specific processes / communications. My test via PowerShell was successful - TCP connection can be established, authentication pass, and I can send emails from this server via given configuration.

I also checked logs on physical firewall, and there is no denies towards smtp.office365.com, only SYN. There is no sign of PRTG trying to reach the SMTP relay on port tcp/587 (which I find strange), but just attempts on tcp/80 - which can easily be SaaS check sensor.

Could it be PRTG is utilizing Windows telnet for sending messages? Otherwise i don't understand why 'HELO ident' mandatory in the config. In that case, there can be some problems with TLS. I did not test telnet as such.

No proxy as well? Weird - could you tap the connection with wireshark on the PRTG Server to verify that no outgoing connection is established?

Windows system proxy (winhttp) and Internet proxies are disabled, all connections are direct.

Wireshark revealed this behaviour:

which fails twice, and then repeats. It really looks like an authentication issue to me.

Can you check if a simple mail client (other than PowerShell) works fine on the PRTG server?

Well, i don't have any other simple email client available, and don't want to install any unnecessary thick client on the server just for test.

I googled a little, and it seems to me telnet cannot be used for Office 365 connections, because it's lacking the right authentication methods. So if telnet is internally used in PRTG, it will never work with Office 365.

I will continue with more research next week. Thanks for your help so far.

Alright then, let me know what you find :)

Hi again, Stephan,

i could not figure out what was wrong for sure, but my best bet is on TLS authentication, which is required for SMTP relay in Office 365.

Testing connection via PowerShell proved the functionality right according to this article: https://blogs.technet.microsoft.com/isantp1/2014/04/11/test-smtp-relay-in-office365/

Finally, i managed to solve the problem by installing SMTP virtual server as a relay on the same server as PRTG. More or less as described in this article: https://support.office.com/en-us/article/How-to-configure-IIS-for-relay-with-Office-365-eb57abd2-3859-4e79-b721-2ed1f0f579c9?ui=en-US&rs=en-US&ad=US&fromAR=1

Until TLS authentication is working correctly, this workaround will suffice.

Thanks again for your help.

Nice workaround! If we receive complaints about PRTG not working with o365, we'll look into this.