Like This ...

SharePoint troubleshooting

A significant part of building a product is actually proving it works the way your customer expects. Doing so you inevitably perform debugging and performance testing. Issues are expected and tackled until satisfaction. It`s all a standard approach where troubleshooting exists, but as a part of the development.

The real purpose here, of SharePoint is to serve your clients. Maintaining and supporting a living environment is a vital necessity. Troubleshooting your clients` issues needs to be your top priority beside anything else. But doing so might not be as easy as it sounds. So we`re going to take a look at few ideas on troubleshooting from that perspective.

The following scenarios are brief examples of various client issues with conditional obstacles for the one doing the support. Those may be due to various onsite arrangements or possible environmental limitations.

Online evaluation

Quite often clients issues are related to lost permissions to content, lost data or certain inability to perform a task. At ground basis you need to be prepared where to look at first. Usually basic support can be performed by a site collection admin that only has the online access to the SharePoint portal. It`s quite limited area as it goes for clearing back-end issues, but we`ll take a look at what can come in handy when it`s a frontend case.

Check effective permissions action

When utilized it can right on the spot identity access levels and reveal those user suspects. Bad thing is that it`s only available for MOSS, but for WSS 3.0 it`s always a close alternative to use that tool.

Audit logs

You do have when in MOSS only, but that`s the only trace you can find on the SharePoint portal itself. There are several reports all as downloadable content. The important task here is to have those auditing configured in advance. True to say it`ll cause a performance impact, but having it set on sensitive data will payoff. Audit settings are configured per sitecollection.

Usage reports

Deserves to be mentioned as it might bring additional idea of what a particular user has been doing. The down-side is that you need the usage reports turned on and collecting data.

Recycle Bins

For missing data always check the sitecollection root recycle bin. Most of the data can be restored back throughout it. Or at least it`ll get you the user that decided to go for a clean-up.

Backtracking

A client should never know what is going on behind the scenes. But that`s only in a better reality. Your users are still capable of causing that SharePoint to mishandle. I`ll skip discussion about how you need to treat code exceptions, but in our case we`ll assume that an user breached expectations, and got one. You having the main responsibility for generic maintenance need to troubleshoot it. It might be an easy one, but how do we start? Log files .. correct, except that we are not looking into an immediate case that just had printed its logs. What we`re looking for is buried in thousands of lines within our daily logs.

I`ll skip some definitions of various logs that are available within a SharePoint environment, assuming you are well known with them.

So our entry point is nothing else but the system`s Event Log, where perspectively we had an Error message debriefing what happened. Rarely it`s enough to solve the case. What we`re looking for is how to gather more data. A logical continuation would be to realize how that issue was caused. For that reason we`ll need to find what exactly the user made to produce it. And there`s the fun part. As long as you are on the same machine, there`s an IIS logs, where all incoming request are kept. Digging through them will give you an entry point for SharePoint to play with. The matching we are looking for is the date-time of the event, but keep in mind that IIS logs might have been exported with UTC timing. Your IIS have a separate log file per each webapplicaton and you need to search them all. A near match in few seconds difference will give you the user`s playground. Now simply redoing the issue will generate you enough data in all other logs (at their very end)(SharePoint logs would be essential here as well) so you can tackle the issue accordingly.

blog comments powered by Disqus