Tag: Troubleshooting

SharePoint Log Viewer

Anyone that spends much time administering or developing against SharePoint knows what a pain it can be to work with the log files in a text editor.  The SharePoint LogViewer developed by Overroot provides a great interface making it easy to work with and filter down the log files.

Give it a try here:  http://sharepointlogviewer.codeplex.com/

Troubleshooting Page Loading Issues

This article will cover some techniques that I typically use for troubleshooting performance issues when loading a particular page in SharePoint.  Troubleshooting the overall platform and member servers are outside the scope of this article.

On occasion I have run into situations where a specific page or collection of pages take longer than expected to load.  I say longer than expected because everything is relative to your content, user activity and your underlying server architecture.  If most pages load in under 10 seconds, but one in particular takes 30-40 seconds or consistently times out then there is clearly something that needs to be reviewed.

Review the SharePoint Page

The first place I start is by reviewing the actual SharePoint page(s) having the trouble.  It is possible, and somewhat common, to have content on a given page that is not displayed. 

Look for Hidden Web Parts

It is possible to have hidden web parts on the page, and while there are some valid reasons for this, in most cases it is done by mistake.  Some users do not understand the difference between the Close and Delete option in the web part menu.  Close will essentially hide the web part, Delete will actually remove it from the page.  Since in both cases it is no longer displayed, most do not think anything more about it after it is gone.  That content is still being loaded even if it is not being displayed.  I have seen a few instances were multiple instances of a large lists are being loaded in this manner which slowed the page load down by 20+ seconds. 

To check for this through the browser, add “?contents=1” to the end of the URL.  This will redirect you to the Web Part Maintenance page displayed below.

Web Part Maintenance Page

From there you can remove the Web Part by selecting the checkbox and clicking the Delete button.  If you want to restore it, return to the page go into Edit Mode and select the Add a Web Part button.  For sites with Publishing Features you will then need to go into the Advanced Web Part gallery options to see the regular Web Part menu.  Select the “Closed Web Parts” gallery listed at the top and add it back to the appropriate zone on the page.

Closed Web Part Gallery

Use of Audiences

Check to see if Audiences are being used.  While this may be a very useful feature in some instances, it can also be inappropriately used.  Just like the Closed web parts mentioned above, this content will load for everyone, but it is only displayed for people in the appropriate audience.  It is a good idea to try and avoid this on top level or heavily trafficked pages.

Trace the Requests

I’ll then use a tool like Fiddler which is able to track all of the network requests from the client computer to the servers.  It is important to note that when running this you will want to close out any other applications that might be making network requests.  Things like your email client or even apps like the Google Toolbar can be pretty chatty and make the results a little harder to read. 

Fiddler will let you now exactly how long it takes to load the page, and break down each and every resource that is also loaded in order to render the page. 

Review Content Locations

From the trace results, take note of where the requested resources are located.  If everything is being requested from the same server it should be pretty straightforward, but in some cases there may be images, styles, scripts, or other resources referenced on other servers. 

Review each of the sources and see if there are any connectivity issues with that particular server.   If any of those servers are outside of your network it may be even harder to have consistent page load times.  In some cases it might be possible to relocate some of those resources closer to the application.  Images, styles, and scripts that are frequently used, but that do not change very often are good candidates for that.  

Review What Is Cached

This is also a great tool for determining what is and what is not being cached.  During SharePoint design or branding projects it is a good idea to clear your browser cache and compare the first request versus a subsequent request where images and related resources are cached.  In some cases new or infrequent users may be having trouble getting resources to load that regular users already have cached.


Hopefully these tips will help you isolate ay performance problems and bottlenecks in order to keep your page load times as quick as possible.

Related Posts

Reworking SharePoint Security – Fixing a Bad SharePoint Implementation

This is the first in a series of posts relating to topics that may need to be addressed to recover from a bad SharePoint implementation.

SharePoint security continues to be misunderstood by many SharePoint power users and some Administrators. It was designed to be flexible, and in doing so can lead people down a road to ruin. One of SharePoint’s greatest assets is that it enables site and content owners to maintain their own permissions. Gone are the days that every request has to be routed through a central IS/IT group. Unfortunately I have yet to see this reach its potential. There are numerous reasons; some site owners do not receive the proper training, some are too busy, some just do not buy into the ownership, and others inherit previously built sites.

To take full advantage of the platform’s capabilities owners need to understand and be committed to following through.

Reinforce the Site Owner Contract
Make sure that Site Owners know what is expected of them. If they are responsible for maintaining security for their site(s), then reinforce the specifics since in some cases this may not be fully understood. This should also carry into that group’s resource planning. If people are informally assigned the ownership tasks it may not be figured into their normal work schedule. If it is not part of the resource planning shortcuts will inevitably be taken. Furthermore, I have seen a few site administrators cut during downsizing without any visibility to those responsibilities. What is worse, in many cases nobody assumes that ownership after the resource leaves the organization.

When developing Site Administrator or Site Owner training, be sure to address proper security. Show examples of where it is done correctly, but also where it was done horribly wrong. Be sure to provide different types of training; in person, written, and interactive.

The Microsoft Office site has a great overview that is easily consumable: http://office.microsoft.com/en-us/sharepointtechnology/HA101001441033.aspx?pid=ch100649861033

Perform and Audit
The best way to get a handle on what the current issues are and to generate a plan to resolve those issues is to start by performing an audit. Look at the site collection and subsites and determine what is set to inherit and what is set to be unique. Then look at the individual lists and libraries to review the same.

Most of the issues I’ve seen come from site administrators breaking inheritance at the list/library level without understanding what that means. I have also seen issues in libraries where multiple levels of folders are in place with security being set differently at each folder level. Hopefully groups are used to control the access, but in many cases it is individuals. The easiest way to resolve these issues is to just start over. Work with the site owner/administrator to understand the intent and set it to inherit from the parent object and then go back through the steps to setup the specific permissions required.

Groups versus Individuals
Wherever possible, use groups to provide access to the securable objects. Adding individuals directly to an object does not promote reuse or central management. This creates many of the maintenance issues that lead to problems as sites and content evolves. Using SharePoint Groups versus Active Directory Security Groups has been widely debated so I will not cover it here. Use what is appropriate for your environment.

Following these recommendations will help transition the system from chaos to something that meets the site owner’s requirements and promotes maintainability. The next post in this series will cover navigation and Information Architecture issues.

Beginning SharePoint Troubleshooting

SharePoint can prove to be a pain to troubleshoot if you are new to the system, or do not have a good understanding of the system. I intend to give some basic info on how to get started. Use this as a springboard to build your knowledge of the system.

Event Viewer
I think it is safe to say that all admins know where the Event Viewer is and how to use it. The bad news is that I do not find the Event Viewer nearly as useful with SharePoint as with other apps. It definitely cannot be used alone to resolve most issues unless you have previously encountered the issue(s) and know the fix.

Universal Logging Service (ULS)
The ULS logs are vital to the troubleshooting effort. They contain all kinds of information for both success and failures relating to all of the SharePoint services. They can also be tuned to get additional data when troubleshooting.

Some things to know…

ULS versus Event Logs – The ULS logs will contain all of the SharePoint messages that bubble up to the event viewer and a whole lot more. This is why I believe it is difficult to troubleshoot based on the Event Viewer alone. What the Event Viewer will tell you that is not located here are non-SharePoint messages dealing things like general server health, connectivity, etc.

ULS Location – The logs are stored in the “logs” folder in what is commonly known as the 12 hive. The 12 hive has a default location of “c:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12”

Multiple Servers – It is important to note that these logs are stored on each server in the farm running a SharePoint service. If you have multiple Web Front Ends (WFEs) you will need to make sure that you check all instances of the logs to be sure that you have all of the information. For example if the user generates an error it will only show up in the logs for the server that user interacted with.

Log Viewer – I have previously written a review of Stefan Gordon’s ULS Viewer available on CodePlex. It really makes it easier to filter and read the logs. http://ulsviewer.codeplex.com/

Configuring Diagnostics – You can configure the diagnostic levels by navigating to the Central Administration website, Operations, Diagnostic logging.

Adjust the levels as appropriate to try and get the information you need. As the name implies, Verbose will give you the most detailed diagnostics. I would not recommend setting all services to Verbose though; I would try and target specific areas in order to reduce the amount of noise extra data creates.

How big are the logs? – The size of the logs will vary depending on the level of diagnostics set for each service, the amount of usage on the system, and of course what issues you are experiencing. I have for example seen a database server go offline generating over 1000 errors a minute until the db was available again.

Within the diagnostic configuration screen, there are settings to help manage both the number of files and the period of time each log will cover. By setting these two fields to an appropriate value you can help to minimize the storage requirements, and also make each log easier to read.

What to look for? – My first course of action is to look for the first error in the log relating to the issue I’m trying to resolve. I then try and look at the information directly preceding that to try and determine if it is related. In many instances the actual error reporting is sort of a generic dump that does not specify the condition or point where the failure occurred.

I also look for patterns throughout the file to try and see what might be related, what might be a symptom, and what else is going on that maybe is not related.

It should go without saying that if the databases are not available the system will not be as well. Errors like “Cannot connect to Configuration database” will ruin your day in a hurry.

Validate Connectivity – I normally start my db troubleshooting by validating connectivity using the main SharePoint service account. An over zealous dba may have made a change that prevents access to the db.

Automated Updates – In some rare cases, I believe primarily with WSS, I have seen Windows Update push a patch or update that requires further administration before the system is available again.

Basic Install – In cases were a basic install was originally done, you may experience some additional hurdles in maintaining and troubleshooting the database.

The WSS install uses what is called the Windows Internal Database which has some interesting limitations. The biggest limitation is that you cannot administer is using your regular toolset like the SQL Server Management Studio, you need to download and use a command line cool called SQL Cmd. http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835cdc&displaylang;=en

The databases are located at C:WINDOWSSYSMSISSEEMSSQL.2005MSSQLData
Further info on the database and how to work with it is available here: http://www.wssdemo.com/Pages/db.aspx

Roles and Services
Early on in your admin career you will probably start with broad moves like restarting the server(s) to clear up issues. As you get a better understanding of the system and when you start to relate the error with a specific server role or service you can start to zero in on the specific sub systems. At that point you can target restarting specific services instead of rebooting one or all of the servers in the farm.

One key to maintaining a healthy farm is early detection of issues, and being able to interpret the early symptoms before it leads to a real problem. One example of this that I struggled with for awhile pertained to issues doing a Full Crawl on a medium farm with about 150Gb of content. I started to see a pattern where a seemingly unimportant message in the logs would signal that the indexing service was going to lock up. It is good to know this early in the process, and not 5 hours into the process. Initially the fix included restarting the server, but in this case simply restarting the indexing service was enough to clear up the issue. We then setup a monitor to look for the initial warning message saving us time in getting updated content into the index.

Where to turn for SharePoint help?
There are a number of no cost community resources including:
MSDN/TechNet Forums
SharePoint University Forums

There are also a number of paid options
MS Support
Other Vendors – A number of other vendors offer per incident or contracted support

Other Considerations
Backup & Recovery needs to be thought about before you have any issues. I cannot count the number of times I have run into people that are trying to fix a major issue but have no current or meaningful backup. This should be a top priority.

Disaster Recovery is also vital, but it should be a different approach than normal Backup & Recovery since it includes the whole platform; features and content.

Patches and Maintenance should be handled with care and ideally should be tested in a non-production environment first. The time it takes and the issues that may result vary quite a bit. When issues arise, and they will at some point, you need to know how to proceed and/or you need to contact a qualified technician asap.

Resolving the MySite File Exists Error

I have seen this error come up a few times, and reported frequently on the MSDN/TechNet Forums. Once the problem is understood, it is fairly easy to correct.

There are a few different pieces that come into play when a user clicks on the My Site link at the top of a MOSS page. The user goes through a centralized MySite.aspx page that acts as a redirect. A check is done to see if the user already has a My Site specified in their profile. If there is a site specified it sends them to the site, if the site is not specified it sends them through the site creation process.

On a couple of occasions I have seen the following error:

The file exists. (Exception from HRESULT: 0x80070050)

Troubleshoot issues with Windows SharePoint Services.

This happens because the user’s profile does not contain a valid path in the Personal site field. The user is then pushed into the site provisioning process, but since the site paths have to be unique, the process is unable to create a new site.

For some reason the profile field was reset or corrupted leaving it blank or filled with something like an error code or invalid statement.

To resolve this issue, you want to first validate the path to the user’s site. The path will vary depending on your setup and naming conventions, but it should be something like http://servername/personal/juser

Once you know what the valid path is, update the Personal site property to include the valid path. Ex. “/personal/juser”

To update the user’s profile:

  • Navigate to the Shared Service Provider
  • Click the User profiles and properties link
  • Click the View user profile link
  • Search for the user’s profile
  • Click the Edit option in the item’s menu
  • Update the Personal site property
  • Click the Save and close option in the toolbar

What causes the error?
On a few occasions the cause could not be determined. Since it was easy to fix we didn’t spend a whole lot of time looking into the cause. The majority of the instances happened after an Active Directory migration where the user’s profile was migrated incorrectly.

When going through an account migration either through Active Directory, or in switching to something like Forms Based Authentication (FBA), make sure you migrate the user profiles using Migrate User. Additional information can be found on that topic at the blog post titled SharePoint AD Migrations: Users and Servers.

%d bloggers like this: