This tip pertains to all versions of SharePoint and no versions of SharePoint. Again, it is really more of an IIS troubleshooting tip.

Since you have gone through Tip 30 and enabled all of the extended logging options in IIS you will not doubt have access to the “Protocol Status” and “Protocol Substatus” fields in all of your IIS logs. If not, go back and run through the tip and enable the options.

When a user cannot access a resource in SharePoint there can be many reasons for it. To track down the “why” of the failed access request a good place to start are the IIS logs. These logs are available in the location specified in the logging options in the web site properties. By default they are located at %SYSTEMROOT%\system32\Logfiles in IIS6 and c:\inetpub\Logfiles in IIS7.

The following list was taken from; The HTTP status codes in IIS 7.0.

• 401.1 - Logon failed.
• 401.2 - Logon failed due to server configuration.
• 401.3 - Unauthorized due to ACL on resource.
• 401.4 - Authorization failed by filter.
• 401.5 - Authorization failed by ISAPI/CGI application.

I will get a little more in depth on these status codes as they relate to SharePoint. As there are many links in the chain of SharePoint security, it is best to have a starting point to begin troubleshooting and the HTTP status code will help in finding that starting point.

401.1

• Usually means that the account information you are giving is incorrect. Check your username and password again, check the Caps Lock key. Make sure to specify the domain for Windows Integrated authentication sites that prompt for credentials (anything that is not in the Intranet zone).

• This can also happen when you browse on the same machine as IIS is installed and the hostname does not match the server part of the URL. See http://support.microsoft.com/kb/896861 for more information.

401.2

• The authentication method that your browser is trying to use is not supported by the site. Many of these are common on servers that have Windows Integrated authentication enabled because browsers will try to connect to the site using anonymous authentication first.

401.3

• This HTTP status will most likely be shown in your browser stating that; “You are not authorized to view this page”. The most likely cause of this is that you are browsing to a file that is located on the file system of the server and the ACL permissions do not allow the application pool process account from reading the file. Check that the application pool is a member of the required local groups on the server and that the correct permissions are set on the file in the file properties security dialog.

401.4

• This status code can be sent when using Digest Authentication and password is either not stored in reversible encryption, or the password has not been reset (http://support.microsoft.com/kb/241832). Since Digest is only used when running IIS on a domain controller and SharePoint should not be running on a domain controller (Except for SBS companyweb) this should not happen often. In fact I have never seen this status code while troubleshooting SharePoint.

401.5

• This status code is sent when an ISAPI filter or CGI application is denying access to a resource. The most likely source of this is an antivirus solution or URL rewriter, but there are many ISAPI filters so check the listing of ISAPI filters in the IIS Management console for clues to the cause.

200.0

• Wait, this is not an HTTP access denied status. That is true, but when you are denied access from SharePoint permissions this is the HTTP status you will see in the IIS logs. There will be a request for /layouts/AccessDenied.aspx with a 200 status code from the user trying to access the SharePoint resource. Adding permissions to SharePoint or changing the group to a group that has access to the resource will clear this up.

This tip is for Windows SharePoint Services 2.0, SharePoint Portal Server 2003, Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007, SharePoint Foundation 2010 and SharePoint Server 2010 when running on Windows 2003 SP1 w/Scalable Networking Pack and versions of Windows since 2003 SP2.

There can be a lot of network traffic on a SharePoint server; incoming HTTP requests, incoming and outgoing SQL data and all of the rest of traffic that other applications may create. The networking updates can help with networking performance in these situations. That is, when the network adapter and driver support the updated networking features. If the network card or driver does not support or is having issues you may see errors on the server like; “General Network error”, “Communication link failure” and “A transport-level error has occurred” for more information check; http://support.microsoft.com/kb/945977.

To check whether or not a computer is using the TCP Offloading feature use Netstat –t at the command prompt and view the Offload Status column for each IP connection. More information is available in the following KB; http://support.microsoft.com/kb/951037.