Endpoint Protection

Environment

Windows 7 Professional SP1 64 bit

SEP 14 MP2 UNMANAGED clients

Issue - intermittent LiveUpdate error "An update for SONAR Definitions from LiveUpdate failed to install.  Error"  Postsession callback failed (208).

We are download updates from the Symantec LiveUpdate server.  No SEPM is involved.

Anyone know what a Postsession callback failure (208) is?  Why do they happen?  What is the fix?

We can manually run LiveUpdate immediately after the postsesson callback error and the SONAR update is successful.

We are assuming that there is something wrong with the SONAR update package.  We may go for days with successful SONAR updates and then have a failure.

Don't tell us to Cleanwipe and reinstall or run SymHelp or whatever.   We're looking for an answer as to what and why a postsession callback failure occurs.

I've seen it happen in the past when the LUE engine fails to decompress the content and causes the extraction to fail. It had to due with higher memory consumption on the client.

The recommended fix I've seen is to download the Intelligent Updater and manually run it:

https://www.symantec.com/security_response/definitions/download/detail.jsp?gid=sonar

But I've also seen it happen in older versions and to "upgrade to the latest version" 

I can't say 100% in your case without advanced logs / process monitor, etc. but that's all I have to go on.

-Brian

Hmmm - we've got 16gigs of memory (plenty free) on the clients and beaucoup free disk space.  This particular sesson callback error issue started about a month ago in IPS defs - we were running SEP 12.1.4 at the time.   We upgraded to SEP 14 MP2 a couple of weeks abo.   The session callback errors stopped occuring on the IPS defs and "jumped" over to SONAR defs.

We don't quite understand how Intelligent Updater is going to fix the issue - perhaps you can elaborate.  We can run LiveUpdate a second time (or, have an automatic update run) and the SONAR defs install with no problem - same version of the defs.

We may try Cleanwipe and fresh installs.  These cllients have been updated multiple times from SEP 11 through SEP 12.1.4 to SEP 14 MP2.  Maybe there's some junk hanging around from previous versions that is causing us problems. 

Anyway, if you can help us understand how Intelligent Updater will fix the issue we will be most appreciative.   We don't doubt your word, just want to understand the rationale behind running Intelligent Updater vs. LiveUpdate.  It's not that we can't update the SONAR defs at all, it's more the intermittent nature of the session callback error.  Usually the SONAR defs update successfully with no intervention - About once a week or so, the SONAR defs fail with the session callback error and we have to manually run LiveUpdate.  We need a permanent fix.

Thanks for your reply.

I don't have technical details on how Intelligent Updater works. It performs a "cleanup" of sorts and installs the latest content. With that being said, I'll defer to any of the Symantec employees who check in here to answer. With the more advanced issues, I generally suggest that a support case get opened up so that support can remote in, correct logs can be pulled, and root cause analysis performed. Especially, if you don't get additional replies or guidance here. It could  be specific to your network configuration or something on the Symantec side, which I'm not privy to.

Thanks for the insight - no pun intended.   Just the fact that Intellegent Updater "performs a cleanup" makes sense.  We will keep poking at this and see if we can correct it.  We'll probably Cleanwipe and install SEP 14 RU1 and try your Intelligent Updater fix if the Cleanwipe doen't work.  If all else fails, we'll open a support case.

Thanks again, Brian.  You're always helpful.

No resolution at this point.  

Is support working on it? Is this a known issue?

We didn't open a support case.  We are closely monitoring the situation at this point.   Could have been a hiccup in the network or something on Symantec's end.

Don't know if it's a known issue.

Whatever it was seems to have gone away.   Could have been either a network issue or something on Symantec's end.