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

W3svc1 log files filling up disk volume

Created: 08 Mar 2008 • Updated: 21 May 2010 | 3 comments

I checked the KB and haven't found this, nor have I seen it that I can recall in this forum.  Thought I was stable enough to wait out the release of MR2, but got bitten while on travel this week on real work.

Checked my server and it took forever to login.  No wonder, it only had 23Mb of free space.  After compressing files and removing anything not necessary, I was able to free up about 1.8Gb of a 20Gb boot partition and stabilize the system (our only server in a small business environment).

Another couple hours of poking around revealed over 13Gb in the following directory: 

C:\WINDOWS\system32\LogFiles\W3SVC1

Daily log files closed out at less than 9Kb until installation of SEPM last November.  File sizes have been growing steadily and now are around 300Mb per day and growing by 40Mb per day.  Deleted all but the current two days and freed up 11Gb of space.

Anybody seen this or found a reason/solution?

Comments 3 CommentsJump to latest comment

reza akhlaghy's picture
Hi
 
Goto IIS Manager, under properities of these virtual directories (in your default website), uncheck Log visits:
secars,
secreg,
reporting,
content,
clientpackages
 
By the way, you can delete all those log files that use your disk space.
 
Paul Murgatroyd's picture
this is changed in MR2, by default we won't log visits to our virtual directories.

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

Ongoing pain's picture

First, thanks to Reza for the quick solution - took care of the problem.

For Paul:  I certainly hope for Symantec's sake, that MR2 solves at least half the problems it's promising.  My boss is not going to keep putting up with the labor sink on this product much longer.  I would have thought that a known issue (undocumented feature) such as this would have at least had a KB article or been included in the SBS best practices paper long before now.  Fearing to log onto our only server because of the unknown surprises is getting old.  This is the second time in three months, the server has almost crashed because of a full disk - each time due to a different issue.