Video Screencast Help

System disk full - yet another SEP problem!

Created: 08 Jan 2008 • Updated: 21 May 2010 | 8 comments
Encountered another SEP problem today when the system partition was reported full. Checking out the problem I noticed that the cause of the problem was a huge directory under Symantec\Symantec Endpoint Protection Manager\inetpub\content.
Check further and finding a Symantec Tech Support article regarding this issue on internet - "Symantec Endpoint Protection Manager has large number of files in \Program Files\Symantec\Symantec Endpoint Protection Manager\Inetpub\content folder".
Followed the instruction that involved setting a parameter - scm.lucontentcleanup.threshold=5, which should default to "10" if not present.
Setting this parameter achieved absolutly nothing and the default value apparently didn't work either since there were a large number of folders under the different subfolders.
Did a manual cleanup according to date and things seem to be fine at the moment. Bound to happen again though, if the above parameter doesn't work as advertised. All users of SEP are bound to run into this problem if it doesn't get fixed!! The folder contained > 10 GB of data before the manual cleanup.
Is it true that there is a new release of SEP? Does it fix the above problem?

Comments 8 CommentsJump to latest comment

ecshop's picture
The new release is MR1. I tried the cleanupcontent command, it seems to be working. Although I'm still curious as to how big it will grow. Only difference this will make on clients is that they will have to download a larger definite update, according to Symantec.
 
One thing I'm worried about is the log files in the Win2k3Server: C:\Windows\system32\LogFiles\W3SVC1
 
This folder seems to grow each day and when there are more clients in SEPM. Anyone know how to purge these files properly? I tried setting my Log Retention to delete logs older than 7 days (as opposed to the default: 14). I also set the client log settings to retain for 7 days (as opposed to the default: 14). I'm not sure if these changes help.



Message Edited by ecshop on 01-08-2008 05:04 PM

jeffwichman's picture
Can someone provide a link to that kb article?  I cannot seem to find it in the knowledge base.
wabe's picture
Dispater
 
The kb-article is incomplete and doesn't work if you don't:
- Put the command at the end of the mentioned file
- Stop the Symantec Endpoint Protection Manager Service
- Clean out all the numbered subfolder in the subfolders under 'content'
- Restart the server
 
This solution is mentioned on page two in this forum. There is also a tip regarding how to decrease the size of the 'Symantec shared'-folder under Common folder that might be of interest to you
 
I've made these changes but cannot yet verify that all is well
lawman 2's picture

There are 2 different questions.  The first has to do with the inetpub\content folder.  From what I have seen there is not really a problem with SEP but with good documentation on sizing guidelines and what SEP is putting in this location. There are several factors that will determine how much space will be taken up.  The scm.lucontentcleanup.threshold value definitely will affect the space.  Some of the other factors are # of client types such as 32 and 64 bit, do you have support for additional languages?   

 

 

 

The other question was in reference to the log files in the Win2k3Server: C:\Windows\system32\LogFiles\W3SVC1 directory. These log files are generated by IIS and you have several options.

a) You can delete old log files without any issue (the log files should be named by the day or month that they are logging requests for - depending on your settings0

b) You can change the location that IIS creates these log files in, so as to prevent exhausting space on your system drive (Using IIS Manager select properties of the default web site and then "enable logging" properties and change the location)

c) You can disable logging for part, or all, of the default website. (Using IIS Manager select properties of the default web site and uncheck enable logging)

d) You can use 3rd party tools to manage the logs (Compress,delete,etc)

 

 

 

Matt Pierce's picture

I've been trying to get a solution to this problem with support and I'm getting no where.   Since installing Sep11 we noticed that our content folder gets huge.  Its currently about 9 gigs.   This issue has run our server out of disk space several times now and we don't have any more room to grow.  I'm consdering rebulding the server but I'm afraid I'll just run into the problem again.

We set the scm.lucontentcleanup.threshold=5 property on the recomendation of support.  There was never a cleanup of the files in the content/ directories.  I've also tried stopping the service, verifying that the above property was the last one set in the config file.  Next I cleared out all the numbered directories under the content folders.  Then restarted the service.  We seemed to have good success with this because things settled down to about 3 Gig useage.  What we didn't know was we had caused the metadata error.  Last night I managed to fix the Binary_files table entries and next thing I know I'm out of disk space.

Today I spend three hours with India support repeating these steps.  Delete the full.dat and full.dax while leaving the conent folders in place. Restart the service.  Watch the disk get consumed.  Rinse Repeat Lather.  After a few goes of that he had me delete all but the two oldest directorys and then stop and restart the service.  Its a bit agreavating when the guy explicitly instructed me not to stop the service before deleting these directories despite the documentation saying to do so.  After that he had me clear out the C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads and the C:\Program Files\Common Files\Symantec Shared\VirusDefs\*dated folders directores and delete all the folders under content.  We kept repeating these steps until I had to break for lunch.  The good news is, All the temp directory clearing and old defenitions et all I'm sitting with 100meg disk space free after it finally finished repopulating itself.  That will of course quickly get consumed in the next few days as defentions are released.

From all the support calls I've had and from reading tickets on this board here is how I think things are supposed to work.  Every so often a task is supposed to run and clean up the content directory.   By default there should only be 10 directories left after a cleanup run.  With the scm.lucontentcleanup.threshold=5 property set that is lowered to 5.  

I currently have over 60 folders in the x32 and x64 av def folders.  I'm utilizing over 9 gigs of disk space for virus defs.   Is this consistent with what yall see in your implementatons?  Is there a command to force the cleanup cycle or a log file I can look for that would point out the cause of the failure?   Anyone else with this issue get a real solution from support?


Abhishek Pradhan's picture

@ Matt -

If possible, please download the MR1 package (maintainence release) from the portal from where you normally download your entitlement / software.

The MR1 fixes almost all of the major and minor :smileyvery-happy: bugs that were encountered during the installation and administration of the initial RTM package. Also, please refer to the following post for cross-ref. to your content update issues -

https://forums.symantec.com/syment/board/message?b...

Do reply to this thread in case you have any further queries

Abhishek Pradhan, PMP, MCT
Blog: http://blog.abhishekpradhan.net | SIG Lead - Pune IT Pro (Microsoft Pune User Group) | http://www.puneusergroup.org

Matt Pierce's picture

Thanks for your reply Abhishek Pradhan.  I've followed the steps in the cited article as well as similar steps with support.  We are running MR1 and are still experiencing this issue.  In fact our server has ground to a halt as a result of this.  I'm currently waiting on a call back from the support engineers as they said they need to work with backend support.  For now, I'm just waiting, hoping for a cure.  I'd like to rebuild my server but I don't have a guarentee that I won't have the same issue after rebuilding.