Troubleshooting IIS: Effective Data Collection for Common Web Server Issues

Table of Contents

Internet Information Services (IIS) web server provides extensive capabilities for administrators, site owners, and web application developers to monitor performance and gather telemetry data for hosted web applications. This includes various sources ranging from IIS request logs and failed request log tracing to event viewer entries and more. However, these valuable pieces of telemetry can be scattered across different locations within a Windows Server running IIS. Collecting and consolidating this information for troubleshooting can become a time-consuming task, especially when dealing with a large number of hosted applications. To address this challenge, the IIS support team has developed a tool called LogCatcher. This tool is designed to streamline the collection of IIS telemetry and configuration data into a centralized location. LogCatcher allows administrators to target the entire server or specific subsets of applications and define a specific time frame for data collection.

Symptoms¶

Connection problems can arise when running ASP.NET, ASP.NET Core, or other types of websites and web applications on an IIS web server hosted on Windows Server.

Note: Currently supported versions of Windows Server include Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, and Windows Server 2012.

This article will outline effective data collection strategies for troubleshooting common issues related to IIS web servers.

SSL and SSL Server Certificate Issues¶

When a client (such as a web browser) connects to an IIS-hosted website via HTTPS, a critical process called a Transport Layer Security (TLS) handshake occurs. During this handshake, the server and client negotiate a secure connection.

Note: TLS is the modern, updated version of Secure Sockets Layer (SSL), though the term “SSL” is still commonly used when referring to security certificates.

As part of this negotiation, IIS is responsible for delivering a server certificate to the connecting client. Problems arise when the certificate presented is not the expected one, or if the client does not trust the certificate. This can prevent the client from successfully establishing a secure TLS connection to the web server. Common SSL-related issues include:

• Certificate Mismatch: The certificate presented by the server does not match the website’s domain name. This often happens after website migrations or when the wrong certificate is bound to the site in IIS.
• Expired Certificate: SSL certificates have a limited validity period. If the certificate has expired, browsers will display warnings or block access to the site.
• Untrusted Certificate Authority: The certificate is issued by a Certificate Authority (CA) that is not trusted by the client’s operating system or browser. This is common with self-signed certificates or certificates from less common CAs.
• Incorrect Certificate Chain: SSL certificates rely on a chain of trust, linking the server certificate back to a root CA. If the intermediate certificates in this chain are missing or incorrectly configured on the server, clients may not be able to verify the certificate’s validity.

Runtime Exceptions and Errors, Including HTTP 4xx and 5xx Status Codes¶

When users interact with IIS-hosted web applications by accessing specific resources or performing actions, they might encounter runtime exceptions and errors. These errors are often indicated by HTTP status codes in the 4xx and 5xx ranges. These status codes provide valuable information about the nature of the problem.

• 5xx Status Codes (Server Errors): These errors indicate problems on the server side. A common example is the “500 Internal Server Error,” which is a generic error indicating that something went wrong on the server but the server couldn’t be more specific. Other 5xx errors could be due to application crashes, database connection failures, or problems with server-side code execution.
• 4xx Status Codes (Client Errors): These errors suggest issues originating from the client’s request. “400 Bad Request” indicates that the server could not understand the request due to invalid syntax. “401 Unauthorized” or “403 Forbidden” status codes relate to authentication and authorization problems, indicating that the client is either not authenticated or does not have permission to access the requested resource.

These errors can be intermittent or consistent, and diagnosing them requires detailed logs and error information from the IIS server.

Handler-Mapping Problems¶

IIS uses handler mappings to determine how to process requests for different types of files or resources. Each request sent to the web server is mapped to a specific handler, such as the Managed .NET handler for ASP.NET applications or the Static File handler for serving static content like images or HTML files. Handler mappings are configured within the web application’s settings in IIS.

Issues occur when requests are routed to the wrong handler. For example, if a request intended for an ASP.NET application is mistakenly processed by the Static File handler, it will likely result in an error, often a “403.14 Forbidden” status code. This specific error indicates that “directory listing is not allowed” because the Static File handler is not configured to execute code or handle dynamic requests.

Incorrect handler mappings can be caused by:

• Misconfiguration in IIS: Accidental changes or errors in the handler mapping configuration within IIS Manager.
• Application Deployment Issues: Problems during the deployment process of a web application, leading to incorrect or missing handler mappings.
• Conflicting Mappings: Overlapping or conflicting handler mappings that cause ambiguity in how requests are processed.

HTTP Redirection Problem¶

HTTP redirection is a common technique to guide users to different URLs. Websites often use redirection for various reasons, such as:

• Enforcing HTTPS: Redirecting users from a non-secure HTTP connection to a secure HTTPS connection.
• URL Changes: Redirecting old URLs to newer, updated URLs after website restructuring.
• Canonicalization: Redirecting different variations of a URL (e.g., with or without “www”) to a single preferred URL.

Redirection problems can manifest in several ways:

• Missing HTTPS Redirection: A website fails to redirect users accessing it over HTTP to HTTPS, leaving the connection insecure.
• Incorrect Redirection: Redirections lead to the wrong destination URL, resulting in users not reaching the intended content.
• Redirection Loops: The client is continuously redirected between two or more pages, creating an infinite loop that eventually causes a browser error message. This often occurs due to misconfigured redirection rules.

These issues can disrupt user experience and accessibility to the website’s content.

Errors in IIS Management Console¶

The IIS Management Console (IIS Manager) is the primary tool for configuring and managing IIS web servers. Errors within the IIS Manager itself can indicate deeper configuration problems or issues with the IIS installation.

Common errors encountered in IIS Manager include:

• Configuration Errors: Error messages indicating an incorrect or invalid configuration when accessing website or application settings. This might prevent access to specific sections of the configuration, such as authentication settings, registered modules, or handlers.
• Console Unresponsiveness: IIS Manager becomes unresponsive or freezes when trying to start it or connect to a specific website. This could be due to corruption in the IIS configuration files or issues with the IIS service itself.
• Extension Conflicts: When adding IIS extensions like Application Request Routing (ARR) to enhance functionality (e.g., for load balancing or reverse proxy), conflicts or misconfigurations can lead to errors in the IIS Manager or unexpected behavior in the web server.

FTP Service Issues¶

The FTP (File Transfer Protocol) service within IIS allows users to upload and download files to and from the server. It’s a crucial component for content management and file sharing. Both standard FTP and secure FTPS (FTP over SSL/TLS) connections are supported.

Problems with the FTP service can prevent users from effectively managing files on the server. Common FTP issues include:

• Connection Errors: Clients are unable to connect to the FTP server.
• Authentication Failures: Users are prompted for credentials but are unable to log in, even with correct usernames and passwords.
• “5xx” Status Codes: When attempting to list directories, download, or upload files, the FTP server returns “5xx” status codes. For example, a “550” status code often indicates that a requested command could not be executed due to file permissions or server-side issues.

These FTP problems can disrupt file management workflows and website deployments.

Server Farm Configuration Issues¶

In larger, more complex web infrastructures, websites and applications are often hosted on server farms. A server farm consists of multiple IIS servers working together to handle web traffic. Load balancers distribute incoming requests across the servers in the farm.

Issues can arise in server farms when subsequent requests from the same client are routed to different servers within the farm. This can lead to inconsistencies and errors, ranging from “4xx” client errors to “5xx” server errors.

Common causes of server farm issues include:

• Configuration Inconsistencies: Differences in the configuration of IIS across the servers in the farm. This could be related to application settings, handler mappings, or other IIS configurations.
• Session Management Problems: If the application relies on session state and session management is not properly configured across the farm, users might lose session data when requests are routed to different servers.
• Load Balancer Misconfiguration: Incorrectly configured load balancers can lead to uneven distribution of traffic or routing requests to unhealthy servers.

Resolution¶

When reporting IIS issues to Microsoft Support, providing comprehensive telemetry data is crucial for efficient diagnosis and resolution. For production servers experiencing problems, a well-executed and timely data collection strategy significantly reduces resolution time. The Microsoft LogCatcher tool is specifically designed for automated data collection, enabling faster and more consistent gathering of all necessary telemetry data from the web server. Microsoft Support agents may request you to download and install this tool from its GitHub repository.

The LogCatcher welcome screen provides clear instructions for its usage. The user interface is designed for ease of use, as shown in the screenshot above. At the bottom of the main window, LogCatcher displays a list of websites hosted on the server, along with their corresponding application pools and content locations.

To customize the data collection, you can filter the data to be collected from a subset of websites and specify a time duration (in days, counting backward from the current date). Use the Site IDs and Logs Age filter text boxes to define these criteria.

1. Determine Filters: Decide which websites to include and the desired time period for log collection.
2. Apply Filters: Enter the Site IDs and Logs Age in the respective text boxes.
3. Generate ZIP: Click the GENERATE ZIP button to initiate the log collection process.

Once data collection is complete, the status bar at the bottom will turn green, confirming successful collection and compression into a .zip file. The status bar also displays the file’s location. Windows File Explorer will automatically open to the folder containing the generated compressed log file.

LogCatcher automatically collects the following critical information:

• IIS Configuration Files: Located at C:\WINDOWS\system32\inetsrv\config. These files contain all IIS settings and configurations.
• HTTP.sys Logs: Located at C:\Windows\System32\LogFiles\HTTPERR. These logs capture HTTP-level errors and issues.
• Event Logs: System, Application, Security, Setup, Microsoft-IIS-Configuration, and CAPI2 event logs. These logs provide a broad view of system events and errors.
• IIS Log Files for Selected Sites: Detailed logs for the specified websites, capturing request and response information.
• Failed Request Traces for Selected Sites: Detailed traces for failed requests, providing in-depth information about request processing and errors.

Important Note: LogCatcher does not automatically upload the generated archive files to Microsoft servers. It solely automates the data collection process. You have the option to inspect the contents of the .zip archive to review the collected data or upload it to Microsoft for analysis as instructed by support personnel.

For scenarios involving multiple servers or for users who prefer command-line operations, LogCatcher can be run directly from PowerShell. To access detailed instructions and available parameters, use the Get-Help command within PowerShell after navigating to the LogCatcher script directory.

Here are PowerShell command examples for using LogCatcher:

-------------------------- EXAMPLE 1 --------------------------
PS C:\>     .\LogCatcher.ps1

This command launches LogCatcher with its graphical user interface.

-------------------------- EXAMPLE 2 --------------------------
PS C:\> .\LogCatcher.ps1 -Quiet $true -ZipLocation "C:\Temp"

This command runs LogCatcher in command-line mode (without UI) and specifies a custom location (C:\Temp) for the generated .zip archive.

-------------------------- EXAMPLE 3 --------------------------
PS C:\> .\LogCatcher.ps1 -Quiet $true -LogAge 45 -SiteIds "1,2,3,4"

This command runs LogCatcher in command-line mode, sets the maximum log age to 45 days, and collects logs only for websites with IIS Identifiers 1, 2, 3, and 4.

More Information¶

Effective troubleshooting of IIS web server issues relies heavily on comprehensive data collection. Tools like Microsoft LogCatcher streamline this process, enabling faster problem resolution and minimizing downtime. By understanding common IIS symptoms and utilizing efficient data collection strategies, administrators can proactively maintain healthy and performant web server environments.

---

Feel free to leave a comment below if you have any questions or experiences related to troubleshooting IIS or using the LogCatcher tool! We encourage you to share your insights and help others in the community.