Endpoint Protection

This feels like it is just a coincidence, nonetheless ever since I did the SEPM update to 12.1.5337.5000 a few days ago on a customer network and rebooted the server, now I no longer receive email alerts from either SEPM and also from Backup Exec 2012.  Each program is using a different email address to send their alerts (same domain though), and yet both are not working.  I have changed no settings anywhere.  However when SEPM finished and ran LiveUpdate, I think I saw some Backup Exec stuff in there.  So maybe both got updated, and within those updates was some kind of change to how email security is handled? 

Not sure if anybody has experience with Exchange 2010 but I went into my Receive Connectors.  I have an internal-only one that receives mail from SEPM and BE.  Port 25, internal FQDN, receiving on "all IPv4" addresses and listening for traffic only from the IP's of the servers on the network.  So the IP filter list is ok.  In terms of the Receive Connector's Authentication and Permission Gropups tabs, these are unchanged from before the SEPM update, and are:

Authentication tab: the only items checked are the TLS check (but not it's sub-checkbox), and the Externally Securied checkbox

Permission Groups tab:  the only items checked are Anonymous Users, and Exchange Servers

I am wondreing if I should have Exchange users checked or not, seems it would make sense.  I'll test later. 

So maybe this is an Exchange issue, but I"m equally unsure of the SEPM situation.  I have rebooted this server several times, and never had it that the email alerts from both Symantec products simultaneously stop.  This would suggest Exchange is the single point of failure but perhaps LiveUPdate put in some kind of higher security requirement on the email settings therefore my ccurrent settings no longer function.  ??

I'll try to find the SEPM logs - do a test email from the SEPM console and see if it generates anything. 

I'd test out sending mail using telnet to see if this is a network/exchange issue, or one within the SEPM.

http://support2.microsoft.com/kb/153119

Quick question too, do you have the POP/SMTP component of SEP installed on the SEPM?  This can mess with the emailing out.

Finally, do you really require TLS internally?

HI guys thanks for the fast replies. 

I tried the SEPM email test, using a variety of combinations of the fields on the Email Servers tab of the server prorerties screen in SEPM, and nothing worked.  Also sepm.log apparently does not record any of this activity since today is Sept 30 and there are only entries from sept 29 (considered UTC and all that too). 

I doubt I need TLS internally true.  But I had thought that the Exchange server uses each of the authentication types in descending order or something like that...trying TLS first but going to others if no luck.  I can still uncheck it anyway to see how things go. 

Since everything with SEP 12.1.x prior to this upgrade to 12.1.5 had SMTP working, I imagine the upgrade would not have removed that . But during the setup I don't recall havintg the option not to select that . The installer recognized my previous install and just did a migration to the last version, database conversion etc.  I don't think I even had the choice to not select certain components....I think. 

I"ll try the telnet test now.  With and without the TLS option checked. 

If you have it enabled, check out the SMTP logs on the exchange server itself.

We want to determine if the exchaneg server is seeing the connection attempt and denying it, or if something is blocking the connection attempt entirely.

Regarding the POP/SMTP component, this is omitted from the "Full Protection for Servers" feature set by default, I was wondering if this had been added in at some point (as it will mess with mail delivery).  If it was there before and working though, I see no reason why it would suddenly start failing with the upgrade....

Most certainly the Exchange server is not seeing any SMTP attempts.  Why?  Because I just discovered the the Microsoft Exchange Transport service did not start after my recent reboot (a reboot done becaus the SEP client had also updated to 12.1.5337.5000 via the Installed Packages tab of the client screen in SEPM).  Amazing how things begin to work when the basic services are running. 

Too bad EMC doesn't do anything to inform you that the services are not running.  I may watch too many movies but is it beyond capacity for the world's leading software company to make stuff a bit more intelligent to where it tells you something is not running?  :) Just wishful thinking. 

Thanks guys for your help, sorry it turned out to be such a simple thing.  I will start a new thread for something else I'm uncertain about, hopefully that's one where I can provide a Mark As Solution to you guys since this thread was a false positive :(