For some reason I get a lot of questions in my inbox about different SharePoint problems people have. I don’t mind, as long as they are polite. If I have time I do try to help out, but sometimes time is not enough. I’m sorry if I don’t answer all of them. But in order to help more people I have compiled a set of rules for SharePoint Troubleshooting.

First rule of of SharePoint troubleshooting: You should always check the ULS logs

The Trace Logs, often called ULS Logs, is where you find your answer to most of your problems. Always use ULS Viewer -  if you do not have that tool in your kit, then you’re out on thin ice, period! Check the correlation id, search for exceptions and warnings. Things I almost always find the answer to here is “file not founds” (404) and “Access Denied”s (401). If you cannot find it immediately in the logs and you can re-create the problem, turn up the logging level to Verbose.

Second rule of SharePoint troubleshooting: You SHOULD ALWAYS check the ULS logs

That’s right! This is the first thing I ask people when they are in trouble and in 99% of the cases the problem is detailed in the logs.

Third rule of SharePoint troubleshooting: If SharePoint yells stop or goes limp, do an IISRESET

Using IISRESET will solve a lot of issues with SharePoint, or any IIS based product for that matter. Note that IISRESET often only temporary solves the problem, so you would most likely want to investigate it further, hence the other rules…

Wish there was a noderunnerreset in 2013…

Fourth rule of SharePoint troubleshooting: At least two guys to a fight

When in doubt – ASK SOMEONE! You don’t have to e-mail Spence Harbar the first thing you do, but please, please ask someone else before you start to mess with your farm, without knowing what you are doing. The first question back you’re going to get is of course – “Have you checked the ULS Logs”, so make sure to do that!

Ask the community, use the Twitter #sphelp hashtag, use the great forums out there such as SharePoint StackExchange, there’s almost always someone there who would like to help you. Oh, and most likely you will find it on your first Bing attempt.

Fifth rule of SharePoint troubleshooting: One problem at a time fellas

This is also a very obvious rule, but I so often see that once a problem occur SharePoint “Professionals” try to fiddle with all the knobs and dials in SharePoint to mitigate the problem, only to get themselves out on deeper water. Step away from the keyboard, take it easy, check the ULS logs and isolate and understand your problem!

Sixth rule of SharePoint troubleshooting: No database fiddling

Touching the SharePoint databases is a big no-no. There are tons of blog posts out there that “solves” problems by manually editing the SharePoint databases. Once you’ve done that you will be unsupported and you will live in shame forever. Just don’t do it!

Seventh rule of SharePoint troubleshooting: Troubleshooting will go on as long as it have to

Prepare for a long fight with SharePoint. Sometimes she is a really vicious one, and you will often see others having the same problem(s) on forums etc., but most often without any decent answers. I’ve spent numerous long nights trying to figure out what the heck is happening. Always remember, that you can open a case with Microsoft – and let them stay up all night instead!

Then eight and final rule of SharePoint troubleshooting: Is this is your first problem, you have to fight!

This is the rule most people have problems with. But if you follow the rest of the rules you will while troubleshooting realize how much you learn about SharePoint and all the surrounding products. And this will make your next troubleshooting much, much easier!

“Without pain, without sacrifice, we would have nothing…”