iis-7logging
All IIS7 is telling me is a folder (i.e. C:\inetpub\logs\LogFiles) which contains a couple of subfolders.
How can I tell which subfolder/file I should look at?
What is the logic behind this folder/file structure?
BTW. A side question: Does MS provide any log viewer with a nice UI?
Just to double check, do you have logging set to error_reporting = E_ALL, and display_errors = On in your php.ini? Usually this is enough to display these errors in IIS 7.
Next, take a look at your IIS settings, as it may be set to only show error messages locally. In the IIS 7 configuration editor this is under system.webServer->httpErrors. You will need to change errorMode to Detailed from DetailedLocalOnly. Obviously this now means anyone browsing your site will be able to see the error.
Alternatively, if you want to keep them local you can use Remote Desktop to log in to the server and run the app from there, if you can.
That's IPv6-based access to WSUS that you're seeing there.
Temporarily disable logging so that you don't fill the drive again:
That'll stop the logs from building up.
I can't say that I've seen WSUS-related traffic build up logs that big before. 4.4MB in a day isn't unheard of, but the 1.67GB in a day means that something has gone wrong.
Yesterday's log file is going to tell you lots about what was occurring. I find it hard to believe that it was all WSUS traffic. I wonder if something else didn't start banging on the server computer. Get that larger log file off of the machine and have a look at it.
Your log looks like it's in the W3C extended format. The format of that log file appears to be:
Date, Time, source IP address, HTTP request method, URI stem, probably URI query, server port, username, server IP address, user agent, HTTP result, probably Win32 status, and probably time taken
(The "probably" fields are because I can't be sure without seeing more of the file.) The header on the file will tell you the format for sure.
You need to get a look at that 1.67GB file-- it's gonna tell you what's up. Logging disabled on the site will prevent the hard drive from filling up again, but you want to know what's happening, behind the scenes, since it's going to be impacting server performance in some manner. Ultimately, you want to get to the bottom of the cause and then get logging enabled again (so that you have an audit trail if you have to track down strangeness again in the future).
Best Answer
If you click on the Web Sites node in IIS Manager, there is a site Id. The log path will be c:\inetpub\logs\logfiles\w3svc{siteid}, or msftp{siteid} for ftp. (by default)
MS doesn't have a log viewer UI at this time but I'm sure there are plenty of them out there. MS has 'Log Parser' which rocks, but it's not a UI, it's just very powerful.