Is IIS 8 supported yet? If not, is there a way to make it work?

Nathan, can you post the exact error you're getting when attempting to use the IIS7 connector?

I've seen a couple errors. The first occurs when the log file path is configured in these ways:

1. C:\\inetpub\\logs\\LogFiles\\W3SVC1\\u_ex140118.log
2. C:\inetpub\logs\LogFiles\W3SVC1\
3. C:\\inetpub\\logs\\LogFiles\\W3SVC1\\
4. C:\inetpub\logs\LogFiles\W3SVC1

I get:

     Event Field Information

     Description Failed to start FAST reader: reader failed to report the error

If I configure it in this way:

1. C:\\inetpub\\logs\\LogFiles\\W3SVC1

I get:

     Event Field Information

     Description Corrupt or manually edited file.  Skipping this line: 0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6683;+Pro) - 404 0 2 97

Thanks for any info you're able to give me.

We've confirmed with our QA team that IIS8 DOES in fact work, but there are similar problems with IIS8 as there are commonly with IIS7. You'll need to go into the IIS logging configuration (in Logging, "Select Fields") and add fields that are de-selected by default but LEM uses to get key data like the hostname/source of the message. You definitely need to add the s-computername field which might be enough to resolve your error and get you moving, but you may need to add more fields to get the full range of data to show up.

I'm hoping we have this documented somewhere and if I find it, I'll be sure to have IIS 8 added to it and let you know where to find it.

Thanks for the reply. I've been working on this issue off-and-on, but I'm still having some trouble getting this connector to work. I've enabled the field as suggested (and fiddled around with a few others), but for whatever reason, I'm still getting the same issues as above. Mostly, though, it just says that it failed to start and failed to report an error. Could this be a file locking issue or something? In the instances it does seem to be able to read the file, it seems like it gets partially through the log then at some point decides it doesn't like the middle of one of the lines and says that it's manually edited. Any further suggestions would be greatly appreciated!

For reference, here are the fields I'm currently using directly from the logfile. I've seen other forum posts where these work, but it just doesn't seem to do the trick on our servers:

• #Fields: date time s-computername s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken

A possible commonality I'm finding is for the cs-method field, the lines that it says it can read either have OPTIONS as the method for either that event specifically or the event previous. Is the connector tripping up when it sees that?

Hmm, that's interesting, and a good lead. Any chance you can send the agent log (should be in windows\system32 or syswow64\contegospop\spoplog.txt or agent.log) and a sample IIS log that has both types of lines in it so we can validate and possibly fix? You can post here if the data is relatively clean, start a conversation with me in private, email to me, or even open a support case (but then you have to start from the beginning ).

Another thing - is this agent running 5.7, the latest version? We did do some fixes that might be relevant in the newer agent.

Just wanted to follow up - we're still investigating the issue, but one thing our QA team found that SEEMS reliable is to enable ALL fields. You might try that and see if you have better luck in the meantime.

Did this ever get resolved to a more definable point? I'm encountering the same issues with IIS 8, and enabling all fields does not resolve the error.