IIS and web requests are used extensively with Enterprise Vault, more so than ever in Enterprise Vault version 8, where the default of the client is to use HTTP over DCOM.
There are numerous ways and tools available to troubleshoot IIS and I will attempt to go through these here . This document will centre around IIS 6, rather 7 and I will perhaps do a document for this in the future though a lot of this document will still apply.
One tool that is extremerly useful with troubleshooting web requests is a tool named Fiddler. This is an HTTP trace utility which is very simple and easy to use.
The Web Sessions list contains the list of HTTP Requests that are sent by your computer. You can resize and reorder the columns in this list for your convenience. You can also sort this list by clicking on the column header.
Certain key information is available in this list, including:
- # - An ID# of the request generated by Fiddler for your convenience
- Result - The Result code from the HTTP Response. Learn more...
- Protocol - The Protocol (HTTP/HTTPS/FTP) used by this session
- Host - The hostname of the server to which the request was sent
- URL - The path and file requested from the server
- Body - The number of bytes in the Response body
- Caching -Values from the Response's Expires or Cache-Control headers
- Process - The local Windows Process from which the traffic originated
- Content-Type - The Content-Type header from the Response
- Custom - A text field you can set via scripting. Learn more...
- Comments - A text field you can set from scripting or the session's context menu
Each session is marked with an icon for quick reference. The Inspectors tab allows you to view the contents of each request and response, in a variety of different formats. This is great for troubleshooting because you can see precisely what is occurring and even where the problem lies. The Filters tab enables you to quickly filter out traffic that is not of interest.
You can also decrypt HTTPS traffic. Fiddler2 includes the ability to decrypt, view, and modify HTTPS-secured traffic for debugging purposes. This feature is disabled by default, but can be enabled in Fiddler's Tools > Fiddler Options dialog. More information can be found using the link below.
If you are unable to use Fiddler for any reason a very similar tool produced by Microsoft is named Wfetch and can be downloaded as part of the resource kit.
To troubleshoot IIS you need to be able to interpret the status codes. See the example line from an IIS log below.
2009-10-08 08:55:19 W3SVC1 192.168.0.2 GET /EnterpriseVault/clienttest.gif - 80 EV7\RHanson 192.168.0.4 EnterpriseVaultOutlookExt-V8.0.0.1404 200 0 0
Note the format of the IIS log, the important ones being below.
· Date
· Time
· Source IP address of the request
· Request
· Port
· Client IP address
· Status Code
A list of status codes and what they mean can be obtained from the link below.
Example Error Codes and there causes
401.1 Authentication Failure
Authentication failures are generally caused by the lack of a valid user name, password, or configuration in the IIS metabase. If administrators cannot manage the remote account database, such as Active Directory or Netware Directory Services, they cannot ensure that the credentials added to the IIS metabase are valid and accurate. For example, suppose the problem involves metabase properties such as AnonymousUserName or UNCUserName. The failure might be a result of one of the following error situations:
· The metabase property for the user name contains invalid data because the value in UNCUserName was typed incorrectly.
· The metabase property for the password contains invalid data because the value in UNCUserPass was typed incorrectly.
· The remote system rejects the authentication because the account is not valid or the password is incorrect.
· For these situations, IIS returns a generic 401.1 "Login Failed" error message.
401.3 Failed ACL on File or Directory
File access permissions cause most of the problems that confront IIS administrators. Often, permission failures occur because content, system files, or components are not secured with the appropriate access control list (ACL) permissions. A common example of this problem is the FTP client without NTFS Write permission. Access can also fail because share permissions are not correctly set.
Troubleshooting permission failures is challenging because it is difficult to determine where the permission failure occurred. It might occur during an attempt to open a handle to the file itself (for example, Default.asp), or to subsequent files such as Asp.dll or Vbscript.dll, or to a file on a remote share that the user does not have permission to access.
500 HTTP Error Codes
These are quite generic but can be reviewed by looking at the Microsoft article below.
403 – Forbidden Access
This is commonly caused by the IP Address not being allowed access to this Web Site in the security settings of the site in IIS.
The IIS logs are usually located on the IIS Server in question in C:\Windows\System32\LogFiles\W3SVC1 by default.
AuthDiag is a very useful tool to check Authentication and Access to IIS. It is also very simple to use. A quick overview in bullet point format of what the tool can do is below.
· Check Authentication Failures (even for specific user, Kerberos)
· Check Access Failuires for Directory or file access.
· Monitor for URL Failures
· Log the results
Tagged in: Untagged
