The Source of SharePoint Problems
SharePoint is built on six different features: business intelligence, business processes, enterprise content management, search, portals, and collaboration. Any one of these areas can cause problems for users, developers, and administrators. Troubleshooting them can be frustrating because one fault can lead to many errors, and finding the fault amongst the errors … that can be challenging. This is due to the fact that If you look at the main features, they are not stand alone features, but integrate seamlessly with others. With that being the case, how do you resolve problems? There are several ways.
Trouble Shooting Flowchart
The following is an example of a troubleshooting flowchart that can start you down the road to solving a set of SharePoint problems. To start, set up an alert to notify you that there is a problem to deal with. Your e-mail can be setup to receive notifications from Sharepoint, this is an alert, or from other users that may have experienced problems.
The flowchart identifies the sequence of alerts that can be followed to trouble shoot SharePoint. It is a tool for the administrator.
If there is a problem, did you receive an alert or a notification? An alert is sent for some problem that your SharePoint system is experiencing, and a notification is sent for a problem that a user is experiencing, such as permissions to SharePoint documents, or projects. Also, timer jobs are important because they are triggers to start to run a specific Windows SharePoint service.
Note that these techniques are general, but the focus on observations about SharePoint can start the process.
The main approach is to avoid a random walk. That is avoid trying just anything, be selective in the approach. While this may seem tedious, it will provide you with a road map on how to pursue the problem.
Trouble Shooting SharePoint Using Web.Config and the Event Viewer
Since you are trying to avoid the random walk, here are some specific steps that you can take to troubleshoot SharePoint. The first set of steps involve the web.config file.
1. Turn on the debug flag from SharePoint web.config.
- Locate the SharePoint web.config file which will be located in C:\Inetpub\wwwroot\wss\VirtualDirectories
- Make a backup of the web.config just in case
- Open the SharePoint web.config using a text editor such as notepad
- Find “CallStack”
- Change the value of CallStack to “true”
- Find “CustomErrors”
- Change the value of CustomErrors mode to ”off”
- Save the web.config file
2. Reproduce an issue you’re having. This is important, because now you can isolate the fault and zero in on the problem set.
3. Examine the error from EventLog. Now be careful because you may not find enough useful information on the EventLog since SharePoint may not provide a trace on the EventLog.
The Log Files
SharePoint, unlike other applications, has many logs. Software Tech specialists frequently use logs, which are text files that are diaries about operations in that software package. If there is a failure in the software, the log file will typically record the date and time, and it will provide some level of detail about the error, what happened, and some troubleshooting techniques. Log files are important because they contain a historical record about the operation in question. This is even more important as software becomes intrinsically sophisticated, and finding faults becomes more time consuming.
SharePoint dumps all logs into C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS. You should be able to find clues by examining logs in this folder. Here are some that may have the information you need.
Web Parts - This is part of the site that can be combined from sections. But the errors that arise may not be readily seen.
Verbose page errors - One can use the web.config file with debug mode to analyze the errors.
IIS Logs - Here everything is available server error numbers or client error numbers, and mundane information like usernames, session info, bytes in, and bytes sent.
Once you have decided on a series of logs, you can use the Microsoft IIS Log parser to analyze the logs. It is a command line utility with SQL like features that looks like this:
With the tool, you can focus in on a problem, by error code, or location.
Trouble Shooting SharePoint Using the SharePoint Log Dumps
Another way to troubleshoot SharePoint is to analyze the dump logs without the log parser tool.
Go to the SharePoint logs folder (c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\Logs).
- Sort the log items by Date Modified
- Open the latest log file using the notepad text editor
- Skip to the bottom
- Look at the most recent log
The hard part now is before you…analyze the error messages; and if necessary, search the Internet for assistance.
Troubleshooting SharePoint can be difficult and exhausting because there are so many areas where a fault could originate. First try to eliminate the random walk; in other words, avoid the “try anything” approach. Look systematically at the problem. There are some tools available like the Log Parser which you can download, or the web.config tool which can help you identify the problem that is occurring. Another tool is the event viewer, which can show you what problems occurred in SharePoint.
This post is part of the series: Troubleshooting SharePoint Services
While SharePoint may be a good working tool for collaborative purposes, there are times when it does not work as intended, and the user is left frustrated with some of those problems. In this series, we look at some troubleshooting techniques.