Troubleshooting SharePoint Solutions with CloudShare – Part I

By Danielle Arad - May 29, 2012

When troubleshooting in SharePoint 2010 On-Premise environments, there are some tools, services, & techniques that every SharePoint person should know and have configured and available in his/her SharePoint Development environment.

In this article I will show you some of the troubleshooting pieces I have set up in my CloudShare development environment.

Integrated services, tools & techniques for troubleshooting

Out of the box, the SharePoint 2010 platform has some really cool services and tools that help you to find more information about specific issues or problems you experience in your farm. Additionally, there are some techniques commonly used to obtain more information about errors produced in your SharePoint sites.

  • Usage and Health Data Collection service application: this works together with the SharePoint Health Analyzer and the SharePoint Best Practices Analyzer in order to collect usage and health data of a SharePoint environment, automatically fix common configuration and performance issues, or propose solutions to manually solve problems. The SharePoint Health Analyzer uses an extensible, rules-based engine to monitor farm health. Additionally, there are several health and usage reports (you can also create your own reports) that provide quick access of the collected data to a SharePoint Administrator. In order to use this powerful capability, you must properly provision and configure the Usage & Help Data Collection Service Application

Once you have your service application running, you can start checking the health of your SharePoint farm by clicking “Review problems and solutions” under “Health Analyzer” in the monitoring section of the SharePoint 2010 Central Administration. You will see a report with the problems and issues grouped by category as specified in the definition of the related health analyzer rule.

For each problem found, you can check complete details, see the proposed solution, and try to fix manually. One you have solved the problem, you can do a re-analysis of the rule in order to ensure the issue will not appear again.

  • The Developer Dashboard: A powerful tool that you can choose to activate and have available at every site collection. You can enable the dashboard by using STSADM, PowerShell or the SharePoint Server Object Model. For example, the object model approach indicates to use a code block similar to the following, once defined in a Visual Studio 11 Beta console application project:

After executing the previous code, you will be able to see (on demand) how every page of your SharePoint farm is performing, by means of artifacts load times, T-SQL sentences executed, and so on. The developer dashboard is almost like an ASP.NET trace that eases the process of identifying performance bottlenecks on your pages. You can even identify which WebParts are the slowest.

As with the Health rules case, you can also extend the Developer Dashboard by “injecting” your own logging information. You can find an example of this extensibility in this great post written by Steve Graegert.

  • web.config file modifications to enable troubleshooting – modify web.config files at the Web Application level. Doing so allows you to obtain detailed information of the problems being caused by custom assemblies deployed to your SharePoint farm. The idea is to obtain more information in case SharePoint returns a really generic error, like the following one that occurred when a request to a specific resource was done:

In SharePoint 2010, you must take the following into account when modifying a web.config file:

  • First, remember to backup every web.config file you are going to modify. By doing this you ensure a recovery strategy just in case something goes wrong when modifying web.config files.
  • Second, you have to decide on a suitable approach to modify these files: manually or programmatically. I recommend you select the programmatic approach because it allows you to have high control of the modifications.
  • Third, you should know that there is more than one web.config file to be modified. You will have to modify at least two files:
    • The first one is located in the following path: c:\inetpub\wwwroot\wss\virtualdirectories\<puerto>, where <port> identifies the SharePoint Web Application with the web.config file we want to modify.
    • The second one is located in the SharePoint _Layouts folder under the 14 hive (c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS).
    • Fourth, do the following modifications to these web.config files:
    • Change the values of the following parameters in the web.config file at the Web Application level:
      • Debug change to “true” value.
      • CallStack change to “true” value.
      • CustomErrors change to “Off” value.
    • In the web.config files stored in the _Layouts folder change the value of the property CustomErrors to “Off” value.

Once you have made these changes you will see detailed information about the errors being produced:

Third party tools for managing SharePoint LOGs

In addition to the usage and health data collected by SharePoint, a great amount of what happens in your farm is written in SharePoint log files. These are found in the LOGs folder under the 14 hive (..\14\LOGS). In these files, you not only find information about errors or issues registered, but also general information about how the farm is running. In order to register appropriate information in LOG files, you have to establish a suitable configuration. This can be done through the SharePoint 2010 Central Administration, PowerShell cmdlets, or the SharePoint Object Model. For example, in the Monitoring area of the SharePoint 2010 Central Administration you will find the “Configuring diagnostic logging” link that redirects you to the related configuration page:

Once you have completed all required configurations and related Timer Jobs, the information starts registering in LOG files and you can start reviewing the collected data. Reading LOGs directly using Notepad or another text editor can be a tedious task, so I recommend you use one of the following free third-party tools:

For every record registered in a LOG file (or several files), you can see a detailed view of the information collected.

  • ULS Viewer ( this is another desktop tool similar to the previous one, but with additional capabilities for analyzing data collected in log files. You can see information registered in real time by connecting the tool directly to the SharePoint ULS.

I recommend you try these tools for reading SharePoint LOGs because they highly improve the user experience.

Make your own logging system

Finally, to conclude this article, there is a valid alternative: build your own SharePoint logging system. If you have this idea in mind for your SharePoint solutions, I recommend you as a starting point to check the solution proposed in the Patterns & Practices SharePoint Guidance.

And that’s troubleshooting SharePoint Solutions with CloudShare. You can expect more articles on this subject in the future. Happy CloudSharing!