some ePO log must contain the result of an email sending test, I would say perhaps the orion.log. Launch a task that wants to send email and monitor this orion.log.
Better still, use a network monitor and see what is actually happening.
Possible reasons I can think of are an authentication issue to the SMTP server (missing or incorrect configuration in ePO) or even SMTP server name is incorrect
Same issue here..... Getting ready to call support... The only think I can find in the Orion log that *might* be related is this:
2012-05-14 08:51:10,636 ERROR [http-8443-Processor25] squid.GroupDT - errror getting full path name for node 2 null
2012-05-14 08:54:55,497 ERROR [http-8443-Processor19] squid.GroupDT - errror getting full path name for node 2 null
2012-05-14 08:55:05,091 ERROR [http-8443-Processor25] squid.GroupDT - errror getting full path name for node 2 null
No RSD, it's an automated response when a virus is found on a computer.
Oddly, i rebooted the server this morning (MS patches) and it started to send automated responses again. Before that they were not even logged in Tasks.
I'll continue to monitor it.
I also got my automatic responses to work.... The only two things I did was reboot and delete all old disabled automatic responses.
Same here, automatic responses are unstable since upgrade from ePO 4.6.0 to 4.6.2 but better since rebooting server. Still having issues with agents failing to communicate to ePO server since the upgrade. Would anyone having this isue please confirm if they can perform a "collect and send properties" or "send events" from the agent side without having any timeouts or errors in the ePo agent logs such as "failed to communicate with ePo server" ?
No, here the agent to Epo server communication seems to work fine
I have the same problem. No alerts send emails any more. Rebooting the server has not fixed the problem. Nor has the fix which was suggested to change epo services account to an administrator account and not "system".
Is there a fix yet for this, please?
It took at least one reboot and a few days for the server to "digest" the upgrade to 4.6.2... but what really helped was setting an agent handler a few days later to unload the main ePO server. We were never able to proove that the upgrade to 4.6.2 broke anything... although I am convinced that the server started acting differently right after updating to 4.6.2. If you manually tested the notification configuration and it works fine then I recommentd you delete your automatic notification tasks and create them from scratch Make sure all the ePO servies are started and monitor your ePO counters from Performance Monitor (Perfmon) to have a better understanding of how your server is busy in the background. Call suport if the problem persists.. there was no magic solution for us unfortunatelly... but I can say everything is functionnal on our side.