Protiviti / SharePoint Blog

SharePoint Blog

September 02
SharePoint Troubleshooting 101

To begin any troubleshooting task, first you should have a good toolbox to pull from in times of crisis.  For example, the same way a plumber needs a pipe wrench to fix a leak, a gardener needs a shovel to fill a hole or a roofer needs a hammer to lay shingles, every SharePoint admin should have their own box of tools to help fix those cyberspace anomalies.  This blog entry is intended to help provide some general SP knowledge, troubleshooting process flow and tips-n-tricks to help build your SharePoint toolbox!

When there is a problem, the biggest challenge as a SharePoint Admin is deciphering the communication provided via the end user about the problem.  The issue generally is reported something like this: “I can’t update the info on this page XXX.  I believe it’s because the content is also on another page”, “I can’t upload documents to the library” or “Why isn’t this event page showing up?  I know I published it.”  These statements in general can be vague and you could potentially spend a lot of time ruling out insignificant items.

Below is a list of tips and tricks for the SharePoint Admin:

1.       Be Warned:  If the user had the answer to the problem; then most likely they wouldn’t be asking for help.  Also, if you take the user’s solution at full value and move forward allowing it to dictate your course of action, then ultimately you get the backlash when it’s wrong.

2.       Be wary of statements that include “I know.”  We all make mistakes and oversights.  It’s always best just to double check.

3.       Always try to get the Who, What, Where, When, Why, and How in the beginning. There is nothing that can make you feel sillier than hindsight (because it’s 20/20).  

a.       Who was having the issue? (What specific user account was performing the task?)

b.      What was the specific action taken when the issue occurred? (Clicked on publish, hit the submit button, typed *** in search, etc.)

c.       Where were you in the site?  (A specific URL location is best, SP has a lot of document libraries)

d.      When did this happen?  (Time of occurrence.  It’s always possible there may have been other things going on in the environment when this happened.)

e.      Why were you trying to perform that action?  Ultimately what is the end user’s goal? (Ex: creating a page, adding to a page, editing a document, adding a web part, etc.)

f.        How did the site respond?  (Ex: Error Access Denied, Sorry something went wrong, the site just timed out, or even nothing at all)

Who knew beginning to trouble shoot SharePoint would be so much like crime scene investigation?  You have to know all the details to make sure you are on the right track to solve the crime...I mean issue.  Good Luck!

Quick Launch

© Protiviti 2020. All rights reserved.   |   Privacy Policy