Trouble Shooting MOSS 2007

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 Logs

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
(http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en) LogParser.msi (v2.2)
 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.

Summary

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.

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.

General guideline for troubleshooting SharePoint issues

This is the list of steps to follow for troubleshooting general SharePoint issues.

1. Turn on the debug flag from SharePoint web.config

Note: Enabling debugging is not recommended on a production environment.

a. Locate the SharePoint web.config file which is typically located under one of the virtual directories in C:\Inetpub\wwwroot\wss\VirtualDirectories.
b. Make a backup of the web.config just in case.
c. Open the SharePoint web.config using a Visual Studio or a text editor such as notepad.
d. Find “CallStack”
e. Change the value of CallStack to “true”f. Find “CustomErrors”
g. Change the value of CustomErrors mode to ”Off”h. Save the web.config.

2. Reproduce an issue you’re having i.e. by refreshing the broken web page

3. Examine the error from EventLog. In most cases, you will find no useful information from EventLog since SharePoint does a poor job leaving a trace on the EventLog.

4. Go to SharePoint logs folder (c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\Logs). SharePoint dumps all logs in this folder, and so you should be able to find clues by examining logs in this folder.

a. Sort items by Date Modified
b. Open the latest log file using a notepad or other text editors.
c. Scroll down to the bottom
d. Examine the latest log

5. Analyze error messages found from Step 2, 3 and 4.

6. Investigate issue for 10 minutes

a. Examine the system account used for an application pool of a SharePoint application. Does the account have proper permissions?

7. If you’re stuck for more than 10 minutes, stop what you’re doing.

8. Search for the clues from Internet — Many times, we forget how useful Internet is and that somebody else typically had the same problem before.

9. If no clues have been found, ask for help.

a. Describe detailed steps how to reproduce the issues
b. Ask colleagues or reach out communities such as the MSDN SharePoint Forums [1]

10. Iterate the step 1 to step 5 until an issue is resolved.

[1] – http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=328&SiteID=1

Troubleshooting the SharePoint “File not found” Error

Have you ever come across a “File Not Found” error when accessing some part of your WSS 3.0 or MOSS 2007 portal? So have I. There are some modifications that the farm administrator can make to the web application’s web.config file to show more information about the error.

Follow these steps:

1.    Navigate Here: C:\inetpub\wwroot\wss\Virtual Directories\<your web app's virtual directory>

a.    You can also open IIS

b.    Expand Sites

c.    Right click on your SharePoint site

d.    Choose explore

e.    proceed to step 2

                Copy and paste the web.config file (making a backup)

                Open web.config using notepad

                Search for “CallStack” , set this equal to true

                Search for “Custom”, set the customerrors = “Off”

                Save the web.config file and refresh your page in the browser

You should now see what the error actually is. Many times it is a web part assembly reference missing from the web.config or something similar.

This should at least give you a more precise troubleshooting starting point. Remember to turn CustomErrors back “On” in the web.config after fixing the issue so that your end users won’t see an ugly Asp.Net error if this happens again.