you need to put in different folder (C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\inbox\content\incoming

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

Hello there,

we had the same issue here!

Try the following and give me a reply!

https://www-secure.symantec.com/connect/articles/how-clear-corrupt-virus-definitions-sepm

Regards

Marius

delta will be created if there are other revision of definition.

did you config your sepm to store old definitions? SEP needs older definitions in combination with the new ones to destill deltas ot of them. Normally, 3 revisions/day are provided by symantec...

Hi Guys,

yep, I am aware of that. As requested by customer we keep 90 revisions in order to minimize the trraffic for machines whic are rarely connecting.

I checked that we have no diskspace issue on both SEPM and SQL...the current configuration is running fine for almost 2 years. I've upgraded to RU7MP1 immediately after it was released, there is no significant growth in the clients as well.

LU is downloading the correct signatures ( I can paste the Log.Liveupdate after I've reinstalled LU 3.3) and again after appling the .jdb.

In 32 bit SEPM def folder {C60DC234-65F9-4674-94AE-62158EFCA433} :

111207021 - the one that I called it stuck is having deltas and so one

111211006 - the newer one is staying with full.zip content...and that's it

Is there a way to check if the SQL instance is OK ( just to double check that there is enough space available to upload the definitions from the SEPM to the DB ) ?

Hello grodani,

thanks for the answer.

Well, then we should give it a try and force the SEPM to create deltas for testings:

Try the following: http://test-inquira.symantec.com/business/support/index?page=content&id=TECH106032&actp=search&viewlocale=en_US&searchid=1323696439908

regards,

Marius

Hi guys,

lucky me the issue disappeared. I hate to say "disappered" and "fixed by itself "...but.

As I thought and think is correct SEPM LU and .jdb methods worked fine, so I focused on the SQL, since the situation was - definitions were present locally on the SEPMs, but not being processed. I guess the data flow is like this : SEPM downloads whatever defs are needed, the full.zip is going the SQL and right after that split into whatever pieces are needed. But if that transfer of full.zip fails, SEPM use the last used and stored defs in the SQL.

I don't know if I'm right, but after I've decreased the number of revisions kept to 30 and tuned a little bit the Log Settings - voila it's with latest defs now.

I'll be extremely happy if we keep this discussion open and track back the issue :

- Was the SQL instance limited ( Don't know where to look, but will find and reply here how I've tracked it back )

- Is the flow of definitions correct ? Downloaded to SEPM->Put to the SQL -> Processed by the SEPM ? I'm interested in whether this is possible or not ? ( HDD space available on SQL server was above 35 GB on each partition, so somebody have set some limitation )

Thanks Everybody for the Great Support ! Have a nice and happy holidays !

Hi,

   It seems to me like a disk space issue, either on the SEPM (check both C: and the SEPM partition or a FG szie issue on the SQL server.

Sesmlu logs from the /tomcat/logs folder may help.

Definition flow is as follow :

- LU downloads the definition from internet
- SEPM service processes it and stores it in the database
- SEPM service on each SEPM linked to the DB, makes it available to clients in the /inetpub/content folder
- index files in data/outbox/agent are updated to reflect the new definitions being available.
- When clients request the definitions and also currently have definitions still available in the SEPM database, a delta is created and made available, otherwise the client is directed to download the full.zip.

Regards,