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

Massive log files in IIS 6.0 created by Symantec

Created: 19 Dec 2007 • Updated: 21 May 2010 | 11 comments

I'm getting undreds and hundreds of megabytes a day in log files in the Windows\system32\logfiles\W3SVC1 directory on my Symantec Endpoint Server. Same issue as this guy, but he never recieved an answer.

The logfiles only say:
GET /secars/secars.dll (followed by random stuff)

Comments 11 CommentsJump to latest comment

JVE Tech's picture
We, too, are having the same issue - several gigabytes of data grow on a daily basis. Does anyone have a clue? As a workaround, I have been deleting the contents of the W3CVS(n) folders.
Matt Pierce's picture

We are having the exact same issue.  I'm working on a scheduled task that will clear out files over a certain threashold.  But these buggers grow so quickly that its hard work out the right level of threasholding.  You can turn off IIS logging and get the disk space back.  I'm considering that and just turning on webloging durring problem times.

Julio Cesar 2's picture

Same issue over here , SEP IIS log are using  500 MB daily with only couples hundres client , MR1 already applied , opened a case with support.



Message Edited by Julio Cesar on 01-02-2008 09:20 AM

SKlassen's picture
FYI, this also affects II5 (windows 2000).
 
I'm experiencing this as well, but not going to bother filing a support case for it, but if anyone here gets any relevent info from Symantec, please post here.
 
Just to try something out, I've changed the heartbeat interval from 5 minutes to 15 minutes.  In theory, this should cut down the amount by 2/3.  Other possible things I was thinking of are turning off IIS logging or doing up a quick VBScript to delete IIS logs older than a few days and having it run as a scheduled task each night.  Plenty of examples for this kind of script can be found by googling.
Paul Murgatroyd's picture
there isn't much we can about this - we use IIS for our clients to check in and upload log files.
 
each time a client checks in it sends some information about itself, this is plain text which is then hashed and forms the majority of the line after secars.dll?h=  The SEPM receives this information and decodes it back into plain text and writes logs into the database, etc.
 
Feel free to disable IIS logging (you should be able to do it for just the secars virtual directory), you don't need to see any of this communication UNLESS you are having a problem with communications between clients and SEPM's but at that point we could temporarily turn logging back on.
 
I'm going to raise this as a possible enhancement, but we can get it KB'd

Paul Murgatroyd
Principal Product Manager, Symantec Endpoint Protection
Endpoint twitter feed: http://twitter.com/symc_endpoint

toasale's picture
I use Ccleaner, known affectionately as crap cleaner, from www.ccleaner.com  to rid myself from SEP and many other programs listing files in IIS. Saves going through different 3rd. party utils to do the work of one.
 
HTH (hope this helps)  :smileyvery-happy:
djmarkm's picture
Paul,
 
You mention disabling logging on the secars virtual directory.
 
I may be missing something here but I dont think that can be done on IIS6 (Windows 2003 Server).
 
Logging is at site level and not folder level. Unfortunately many SBS customers will be using their default site for other things as well as SPEM ie. Exchange OMA / OWA, Certificate Services & Internal Sharepoint Sites, In which case disabling logging on all of this would probably be unwise.
 
A better solution would surely be to allow SEPM to be configured to use a seperate site on an alternate port as the Symantec Exchange plug in already does.
 
 
Mark
SKlassen's picture
Logging parameters are set on the site level, but you can stop logging for specific directories.  Right click the virtual directory and select properties.  On the Home Directory tab there is an item called Log Visits.  Uncheck the box for this item and you'll be good to go.
 
As you mentioned Paul, the log info should only be necessary for troubleshooting issues.  How about putting in a feature request change for inclusion in the next patch to have the logging OFF by default, with an entry added to the admin manual about turning it on temporarily if necessary. 
dfhbac0's picture
I am having the same issues.  I agree with the last remark how this should be fixed.
 
bc
Paul Murgatroyd's picture
thats exactly what I was meaning - the issue was logged last week, so its on our list.

Paul Murgatroyd
Principal Product Manager, Symantec Endpoint Protection
Endpoint twitter feed: http://twitter.com/symc_endpoint