Internet Information Services (IIS) Log Tools — Detailed Usage & Practical Guide (English)

Meta Description: Learn how to collect, parse, forward and analyze IIS logs using Log Parser, Filebeat+ELK, Splunk, Windows Event Tools, ETW & FREB. Hands-on configurations, queries, dashboards and best practices.
Focus Keywords: IIS log tools, Internet Information Services logging, Log Parser, Filebeat ELK, Splunk IIS logs, ETW FREB, IIS monitoring, IIS log best practices

1. Introduction

IIS (Internet Information Services) generates rich telemetry that is essential for security, performance troubleshooting, compliance and forensic investigations. This guide explains the most useful IIS log tools and demonstrates detailed, practical usage: how to configure IIS to emit the right fields, how to parse and forward logs, and how to create meaningful alerts and dashboards. The examples focus on Windows environments and common log stacks (ELK, Splunk), but the principles apply to any centralized logging setup.

2. What IIS logs look like — formats & fields

IIS typically writes W3C-formatted access logs. A W3C record contains a header describing fields and then lines with space-separated values. Common fields to enable:

• date time — timestamp of request

• s-ip — server IP

• cs-method — HTTP method

• cs-uri-stem — requested resource path

• cs-uri-query — query string

• s-port — destination port

• cs-username — authenticated user (if any)

• c-ip — client IP

• cs(User-Agent) — user agent

• sc-status — response status code

• sc-substatus, sc-win32-status — extra status info

• time-taken — request duration in ms

Make sure to include cs-username, c-ip, cs(User-Agent) and time-taken for security and performance analysis.

3. Enabling & configuring IIS logging (practical)

GUI (IIS Manager)

1. Open IIS Manager → Select site → Logging.

2. Log file format: choose W3C.

3. Click Select Fields and enable the fields listed above.

4. Configure log file rollover (size or daily) and log directory (prefer non-system volume).

5. Save.

PowerShell (example)

Import-Module WebAdministration

# Enable W3C logging for site "Default Web Site"
Set-ItemProperty "IIS:\Sites\Default Web Site" -Name logFile -Value @{logExtFileFlags="Date,Time,ClientIP,UserName,Method,UriStem,UriQuery,ServerPort,UserAgent,Status,SubStatus,Win32Status,TimeTaken"}
# Set log folder
Set-ItemProperty "IIS:\Sites\Default Web Site" -Name logFile.directory -Value "D:\IISLogs\DefaultWebSite"
# Roll daily
Set-ItemProperty "IIS:\Sites\Default Web Site" -Name logFile.period -Value "Daily"

Tip: Store logs on a dedicated volume and restrict NTFS permissions so only administrators and log-collection services can read them.

4. Failed Request Tracing (FREB) & ETW — when you need deeper detail

• Failed Request Tracing (FREB) captures detailed per-request trace events (module-level) when requests match configured status codes or slow thresholds. Enable FREB in IIS Manager → Failed Request Tracing Rules and set trace conditions (e.g., status codes 500 or time-taken > 2000ms).

• Event Tracing for Windows (ETW) provides low-level IIS and HTTP.SYS events (connections, queue drops). Use logman or wevtutil to collect ETW sessions or a tool like Windows Performance Recorder.

Practical uses: debug intermittent 500s, slow pages, or module failures that don’t show clearly in access logs.

5. Local parsing: Log Parser 2.2 & alternatives

Log Parser 2.2 (Microsoft)

A powerful CLI tool that treats log files as SQL tables. Useful for quick queries on IIS W3C logs.

Sample queries

• Top 10 slowest pages:

LogParser.exe "SELECT TOP 10 cs-uri-stem, AVG(time-taken) as avg_ms, COUNT(*) as hits FROM D:\IISLogs\u_ex*.log GROUP BY cs-uri-stem ORDER BY avg_ms DESC" -i:W3C

• Distinct client IPs with 5xx counts:

LogParser.exe "SELECT c-ip, COUNT(*) AS errors FROM D:\IISLogs\u_ex*.log WHERE sc-status >= 500 GROUP BY c-ip ORDER BY errors DESC" -i:W3C

Log Parser Lizard is a GUI wrapper for Log Parser that helps craft queries and visualize results if you prefer UI.

Alternatives

• PowerShell parsing with Get-Content + ConvertFrom-String for small datasets.

• goaccess or awstats for simple web analytics (not IIS-specific detail).

6. Forwarding to centralized systems — Filebeat / Winlogbeat / Syslog

For production you should forward logs to a centralized collector.

Filebeat (Elastic Stack)

1. Install Filebeat on IIS host.

2. Configure filebeat.inputs to read the IIS log directory (use wildcard u_ex*.log).

3. Use decode_csv_fields processor because W3C logs are space-delimited. Or use Filebeat's iis module which includes parsers.

filebeat.yml (snippet)

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - D:\IISLogs\*\*.log
  fields:
    source: iis
  multiline.pattern: '^\#Fields:'
  multiline.negate: true
  multiline.match: after

filebeat.config.modules:
  path: ${path.config}/modules.d/*.yml

output.logstash:
  hosts: ["elk-collector:5044"]

Use Filebeat iis module (enables pipeline ingest templates in Elasticsearch) to parse the W3C fields into structured fields.

Winlogbeat for Windows Event Logs & ETW

Use Winlogbeat to forward Windows Event logs (Application/System/Security) and ETW channels to ELK or SIEM.

7. Parsing & ingestion in ELK (Logstash / Ingest pipeline)

Logstash grok example (for raw W3C if not using Filebeat module)

input { beats { port => 5044 } }

filter {
  if "iis" in [fields][source] {
    grok {
      match => { "message" => "%{YEAR:date} %{TIME:time} %{IP:server_ip} %{WORD:method} %{DATA:uri_stem}(?: %{DATA:uri_query})? %{INT:status}" }
    }
    date { match => [ "date time", "yyyy MM dd HH:mm:ss" ] }
  }
}
output { elasticsearch { hosts => ["http://elasticsearch:9200"] } }

Better: use Filebeat iis module which ships an ingest pipeline to Elasticsearch — less fragile than custom grok.

8. Splunk ingestion & search examples

Indexing

• Forward logs via Universal Forwarder or HTTP Event Collector (HEC).

• Use field extractions to map W3C fields.

Sample Splunk SPL

• Top client IPs hitting 500 errors:

index=iis_logs sc_status>=500 | stats count by c_ip | sort -count

• Detect possible web shell upload attempts (POSTs with suspicious extensions):

index=iis_logs cs_method=POST cs_uri_stem="*.*" | where like(cs_uri_stem, "%.aspx%") OR like(cs_uri_stem, "%.ashx%") | stats count by cs_uri_stem, c_ip

Create saved searches and alerts to notify on thresholds.

9. Detection rules & alert examples

Design detection rules that combine indicators for higher confidence:

• Credential stuffing: multiple failed authentication responses (401/403) from same IP across many accounts → alert & block IP.

• Web shell upload: POST to upload endpoint + new file in webroot (FIM) + new process connecting outbound → high-severity alert.

• Slow responses: average time-taken > threshold for critical pages → performance alert.

• Information leakage: requests that return stack traces or 500 with verbose errors → notify devs.

Automated response: integrate with firewall or WAF to block IPs, or with orchestration (Playbooks) to quarantine host.

10. Forensics: acquiring logs & preserving integrity

• Rotate & archive logs regularly to immutable storage (read-only retention) for compliance.

• Hash archived logs (SHA256) and store the hash separately to prove integrity.

• If incident occurs, collect relevant IIS logs, FREB traces, ETW captures, Windows Event logs, and take a filesystem snapshot. Maintain chain-of-custody.

11. Performance & retention considerations

• High-traffic servers produce many GB/day. Plan disk capacity and use compression (daily zipped archives).

• Retention policy should balance compliance and cost (e.g., keep detailed logs 90 days, aggregated metrics longer).

• Index only what you need in ELK/Splunk; use warm/cold nodes or archive to object storage.

12. Hands-on practical exercise (end-to-end)

Goal: Collect IIS logs, forward to ELK, create a dashboard and an alert.

1. Enable IIS logs on a test site and include fields: date time c-ip cs-method cs-uri-stem cs-uri-query sc-status sc-substatus sc-win32-status time-taken cs(User-Agent) cs-username.

2. Install Filebeat on the IIS host and enable the iis module:

   PS> .\filebeat.exe modules enable iis
   PS> .\filebeat.exe setup --dashboards
   

3. Start Filebeat to forward logs to Logstash/Elasticsearch.

4. In Elasticsearch, verify filebeat-* index has parsed fields (client.ip, http.request.method, url.path, http.response.status_code, http.response.body.bytes).

5. Create Kibana visualization:

   • Top client IPs by request count.

   • 5xx errors over time.

   • Average time-taken per endpoint.

6. Create alert: watch http.response.status_code:500 rate increase by X% over Y minutes → send Slack/email and create a ticket.

7. Test: Trigger a simulated error page (in a controlled environment), verify it appears in dashboard and alert fires.

This exercise demonstrates the full pipeline from log enablement to detection.

13. Security & compliance best practices

• Protect logs: restrict access, encrypt at rest and in transit (TLS for forwarders).

• Tamper-evidence: use integrity checks and append-only storage for critical logs.

• Least privilege: log collectors should run with limited permissions needed to read logs.

• Privacy: avoid logging sensitive PII in cleartext; mask or tokenize sensitive fields where required by policy.

• Audit & test: periodically validate log collection by generating synthetic events and ensuring they appear in SIEM.

14. Useful tools summary

• IIS Manager & PowerShell — configure logging and FREB.

• Log Parser 2.2 / Log Parser Lizard — local ad-hoc queries.

• Filebeat + Winlogbeat — lightweight forwarding to Elastic.

• Logstash / Elasticsearch / Kibana — parse, index, visualize.

• Splunk — enterprise SIEM, search & alert.

• Wazuh / OSSEC — FIM and endpoint monitoring.

• Suricata / Zeek — network telemetry to correlate with IIS logs.

15. Conclusion

IIS logs are a powerful source of truth for performance monitoring, security detection and incident forensics. A practical logging pipeline includes enabling the right fields in IIS, collecting advanced traces (FREB/ETW) when needed, forwarding logs securely to a central system, parsing them into structured fields, and creating high-confidence detection rules and dashboards. Follow retention, integrity and privacy best practices and validate your pipeline with routine tests.