From: Steve Schofield on
What types of functions are handled through IIS? I'd look to see if this
is internet exposed, if not, then I'd look at turning logging off. Sounds
like you are on the right track!

SS


"Bill Glidden" <bill(a)glidden.net.au> wrote in message
news:u6lHUJ1aKHA.3668(a)TK2MSFTNGP06.phx.gbl...
> Steve Schofield wrote:
>> I'm not real familar with IIS and SBS 2008 settings. It's probably the
>> same. It is kind of scary if there is something in your environment
>> infected, making bogus attempts, sql injection etc. I don't want to
>> scare you, but that does come to mind. How big are your logs per day?
>> And / or you can use log parser to see if there are some attacks. Here
>> is a blog posting with some examples.
>>
>> http://weblogs.asp.net/steveschofield/archive/2008/04/26/clarification-on-iis-reported-sql-injection-exploits.aspx
>>
>> Maybe it's just someone scanning your box.
>>
>> SS
>>
>> "Bill Glidden" <bill(a)glidden.net.au> wrote in message
>> news:eClsBqWaKHA.4932(a)TK2MSFTNGP02.phx.gbl...
>>> Steve Schofield wrote:
>>>> Having the log files can be handy for troubleshooting a variety of
>>>> issues. It appears you are not using them so turning off is probably
>>>> safe. If you run into an issue, then turning on is something as a
>>>> troubleshooting step.
>>>>
>>>> The other alternative is enable only what you need, have a script of
>>>> some sort that compresses or deletes them on a periodic basis. To have
>>>> 67 GB worth of logs, your site must be pretty busy. As others have
>>>> suggested, I'd put them on a separate partition so your operating
>>>> system isn't effected. It's really your call, hopefully this has
>>>> helped.
>>>>
>>>>
>>>>
>>>> SS
>>>>
>>>>
>>>> "Bill Glidden" <bill(a)glidden.net.au> wrote in message
>>>> news:4B01E3FB.5040303(a)glidden.net.au...
>>>>> .._.. wrote:
>>>>>> Yes, you should be managing them. Depending on what information you
>>>>>> are getting (probably not much, if you didn't know they were that
>>>>>> large) you can zip them up and delete the originals, make reports and
>>>>>> then delete the originals, or just delete them.
>>>>>>
>>>>>> I would STRONGLY ADVISE moving them to a separate partition so they
>>>>>> do not fill up the space available to the Windows install.
>>>>>>
>>>>>> If you are not using the data, you can also just turn off logging by
>>>>>> unchecking the box in the site properties.
>>>>>>
>>>>>> "Bill Glidden" <bill(a)glidden.net.au> wrote in message
>>>>>> news:O4iqNUmZKHA.1592(a)TK2MSFTNGP06.phx.gbl...
>>>>>>> I have been wondering why my system volume of my SBS 2008 keeps
>>>>>>> running out of disk space. I now see that
>>>>>>> c:\inetpub\LogFiles\W3SVC1372222313\ contains a bajillion u_ex*.log
>>>>>>> files, totalling 67.1GB. Is this something I�m supposed to be
>>>>>>> managing or is something wrong? They range in date from mid-August
>>>>>>> to today. The files are frequently over 1GB in size. The server has
>>>>>>> been commissioned since August.
>>>>> Thanks "-" and Steve.
>>>>> Should I not be worried about the size of these files? Do they not
>>>>> indicate a possible problem? I am happy to turn off logging, since I
>>>>> do not use these files. Are they ever useful for diagnostic purposes?
>>>>> If so, I can always re-enable logging for a period.
>>>>> Cheers, Bill
>>>>
>>> Hi Steve,
>>>
>>> Thanks for your help. It has been useful. I guess I should have
>>> mentioned that this particular SBS 2008 server is my own office one and
>>> is *not* a big one. There are no special websites(except Trend WFBS).
>>> There are no sites exposed to the outside world other than the standard
>>> SBS ones, e.g.,OWA. This was why I was concerned about the size of these
>>> files: was this indicative of some error condition or is IIS compromised
>>> in some way? I have had a look at some of these log files and don't
>>> understand them. Can't see errors, only transactions. Maybe error
>>> conditions don't appear explicitly in them and the sheer volume is the
>>> error?
>>> Cheers,
>>> Bill
>>
>>
> Hi Steve,
>
> Ran both of those LogParser commands and it came up clean, so at least
> it's not that. Could be someone scanning, as you suggest but wouldn't ther
> also be many failed login attempts, too?
> Cheers,
> Bill