Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Updates rolled back 1 month

Created: 03 Jul 2013 • Updated: 03 Jul 2013 | 34 comments
This issue has been solved. See solution.

Hello,

I walked in today to notice that all systems using SEP have rolled back exactly one month (to June 3rd 2013's virus definitions). I have sent out updates again, but it has not done anything.

What may have cause this? It was working perfectly last night.

Operating Systems:

Comments 34 CommentsJump to latest comment

Rafeeq's picture

I have not seen such issues so far. Did you check if its showing Jul or Jun?

to check if someone rolled back the defs

open sepm , policies, liveudpate policy, on the right hand side click on Liveupdate Content. check the defitnions set to use. Can you confirm if you sepm is having latest defs?

.Brian's picture

Who else has access?

Go to your LU policy and select LiveUpdate Content tab >> Security definitions

Is the radio box for "Select a revision" checked with a different revision?

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

DavidC1988's picture

Only I usually access these, and I just send out Updates and Active Scans (Everything was setup by my boss a year ago and was perfectly fine until now).

I have checked the policies and they are set to use the latest definitions. 

SebastianZ's picture

What version of latest definitions available is your SEPM reporting?

DavidC1988's picture

Currently, June 3rd 2013...

As I said, it was perfectly fine, maybe there was an issue with the updates I rolled out around 1pm EST yesterday.

.Brian's picture

Not sure how SEPM definitions could roll back, this can only be done on the clients that I know of.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

SebastianZ's picture

Strange, if you run Liveupdate on SEPM - does it find any newer defs available online? Is your SEPM updating directly from internet liveupdate servers?

DavidC1988's picture

Clients do not have access to touch anything on SEP besides running a scan. 

.Brian's picture

I mean from the SEPM

Does anything show in your audit logs?

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

DavidC1988's picture

Only shows me viewing my policies as you asked me to do above. 

Could there be an issue with the updates I rolled out yesterday afternoon (the revision for 1pm EST yesterday)?

Rafeeq's picture

open sepm

monitors -logs  - type system

check the client server activity. see if they did download from SEPM

DavidC1988's picture

Every user that reports shows that it has "Client has downloaded the issued command".

Rafeeq's picture

Open a SEP clinet, click on help and support - troubleshooting. Do you see the server name or it shows as Self Managed? Did you apply any package update to the clients because if you did autoupgrade it would uninstall previous defs and install new.

Open sepm

admin

servers, show LU downloads, what version of defs do you see?

DavidC1988's picture

Clients are taking updates from the server that is deploying said updates.

July 3, 2013 10:52:32 AM EDT:  LiveUpdate failed.  [Site: My Site]  [Server: ]
July 3, 2013 10:52:32 AM EDT:  LUALL.EXE finished running.  [Site: My Site]  [Server:]
July 3, 2013 10:52:32 AM EDT:  LiveUpdate encountered one or more errors. Return code = 4.  [Site: My Site]  [Server: ]
July 3, 2013 10:52:32 AM EDT:  LUALL.EXE has been launched.  [Site: My Site]  [Server: ]
July 3, 2013 10:52:32 AM EDT:  Download started.  [Site: My Site]  [Server: ]
 
 
Ruh Roh..This showed when I selected "Download live update content"..
Rafeeq's picture

whats the date it shows when you check Show liveupdate downloads? is it June 3rd?

You will get Error code 4 if you dont set proper proxy for SEPM. Follow this doc set the proxy and download the defs 

"Error: LiveUpdate encountered one or more errors. Return code = 4" in LiveUpdate status in Symantec Endpoint Protection Manager

 

http://www.symantec.com/business/support/index?page=content&id=TECH103112

DavidC1988's picture

Shows as June 3rd 2013...

Will try this, give me a few minutes :)

DavidC1988's picture

Does not work. My boss was looking at our Firewall last night, I am thinking he removed an exception, because up to that point it was working 100%. 

David-Z's picture

As a workaround, you can use a .JDB file to update your SEPM and get your clients up to date while you continue to investigate the cause of the failure.

Please see http://www.symantec.com/docs/TECH102607 for more information.

That being said, return code 4 is a generic error returned by Windows LiveUpdate when it encounters a problem.

Is it possible for you to post a copy of the Log.Liveupdate from this SEPM for more detail?

You should be able to find it in one of these locations:

C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\log.liveupdate

C:\ProgramData\Symantec\LiveUpdate\Log.liveupdate

Hope that helps!

David Z.

Senior Principal Technical Support Engineer, Symantec Corporation

Enterprise Security, Mobility and Management

Rafeeq's picture

My guess was right. Your SEPM has June 3rd defs thats why it send all your clients that defs. 

Download the JDB from internt and update the manager first as your clients are running with one month old defs.

How to update definitions for Symantec Endpoint Protection Manager (SEPM) using a .jdb file

DavidC1988's picture

The JDB files are still inside the INCOMING folder.

Still not working.

.Brian's picture

Unless this was configured to so do from the SEPM (sounds like it was not) why would the clients accept or rollback to definitions older than what they currently have??

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

DavidC1988's picture

This I do not know. Is there a setting I can look at that can let me see if this is set?

.Brian's picture

You can rollback defs on the clients by configuring this on the SEPM.

In the LU policy, select LiveUpdate Content tab and open the policy

Once open, check the Security Defintions tab

I believe you already said this was normal.

I'm just questioning why if clients had newer defs, why they would rollback to older ones. There is no setting for that that I'm aware.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

DavidC1988's picture

Could there be a bug with yesterdays updates? Something is bloody wrong and this is making me angry..

SEPM won't load now...The manual update in the Incoming folder is still sitting there, when they said it would be gone within a minute..like WHAT IS GOING ON angry

.Brian's picture

I would suspect if there was, the forum would be loaded with more posts on this. I can confirm mine is fine.

Latest defs are 7/3/2013 r2

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

DavidC1988's picture

Then one of the following is happening:

1) My boss removed an entry from our firewall, doesn't want to admit he made a mistake

2) Our server that contains SEPM is infected

3) I am doing something wrong, yet following steps how can I do it wrong :/

.Brian's picture

Run the Symhelp tool on the SEPM, see if any errors come up:

http://www.symantec.com/docs/TECH170752

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

David-Z's picture

Given that the .JDB file is unable to process, I suspect that PackageTask may be hung or something similar. The .JDB file should normally process within 5 minutes depending on SEPM activity.

It may be in your best interest at this point to open a technical support case for further assistance. I would recommend having the SymHELP report ready for when you open up the case so that someone can take a look with you.

http://my.symantec.com

-or-

http://www.symantec.com/support/techsupp_contact_phone.jsp

David Z.

Senior Principal Technical Support Engineer, Symantec Corporation

Enterprise Security, Mobility and Management

DavidC1988's picture

Brian81,

I ran the Symhelp tool, it found a few errors, but my boss restarted our server before I could fix the issues. Hopefully the restart fixes the issue. Will advise.

DavidC1988's picture

Update...32bit updates are July 3rd, but everything else is still showing June 3rd

The part above where I showed where it launches LUALL.EXE then gives the error, that is not happening anymore...but still users are not updated

DavidC1988's picture

Am now getting this when doing the Admin > Servers > LU Download Updates

"July 3, 2013 3:07:07 PM EDT:  The process ConfigServerHandler.publishLuInventory can not lock the process status table. The process status has been locked by the server 68915961C0A8040A01800CE803EB604C (ConfigServerHandler.processLUContent) since 2013-07-03 15:07:01.  [Site: My Site]  [Server:]"

DavidC1988's picture

It seems restarting the IIS page for Symantec and Default web page, along with the defaultpool, fixed this...

Thanks for the help guys :D

SOLUTION
David-Z's picture

Restarting the services likely removed the lock issues PublishLuInventory/processLUContent was running into. It's possible that the 64-bit content would've eventually processed if you would've waited it out since we can see that the process status was actually locked by "processLUContent". This means that the restart allowed the .JDB file to finish processing into the SEPM.

PublishLuInventory is what changes the listed available virus definitions in the SEPM.

There may still be a problem with Liveupdate downloading, so I would continue to monitor the situation and ensure it updates fine on its own at least once.

If it isn't able to continue updating on its own, then grab that SymHELP report (it contains a copy of Log.Liveupdate) and open up a case with support for further assistance or feel free to zip up the raw Log.Liveupdate and upload it here so we can take a look and assist with why it's failing to download the content.

Hope that helps!

David Z.

Senior Principal Technical Support Engineer, Symantec Corporation

Enterprise Security, Mobility and Management