The Rules of SharePoint Troubleshooting

Tags: SharePoint

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…”


  • Thuan Soldier said

    Interesting rules :-).

    Come to MSDN/TechNet Social website, or #sphelp on Twitter when you have issues/problems on SharePoint ambiguously. Try to involve in community to get help. Furuknap talked a little bit here:

    Not really with the #4 because people actually don't have enough time to help you unless you pay money or your problem is easy to solved. I have got many ambiguous questions so I actually don't have time to response many times via email.


  • Bernado Nguyen-Hoan said

    Absolutely correct on ULS.

    In a multi-servers farm the ULS may not be synchronised and you may only find the correlation ID on particular servers. I'd suggest also using the PowerShell command Merge-SPLogFile, which allows you to merge the ULS on all servers in the farm and filter for particular correlation ID (and also timeframe and other useful properties).

  • Anatoly Mironov said

    Great Post! I'll link to it when I answer the help mails, sent personally to me :)

    It was fun to read it, too: First rule: Check the ULS. Second rule: Check the ULS.

    "You have to fight!" The SharePoint fight club! Love this post :)

  • Axel Schneider said

    Thank you for your summary Wictor. I totally agree with your rules (and the order) because they are the most easy tasks you could do if you are in SharePoint-Trouble. Each SharePoint-admin should print it on A1 and pin it to its door... ;-)) I had done a quite similar summary (for my own and for my colleagues) some time ago and it helps very much to read that others are having the same trouble and doing the same things to solve it.

  • Dusty said

    Great article. I appreciate the humor and references. "Troubleshooting will go on as long as it have to" is key. I've spent too many late nights to count troubleshooting, but it has paid off in the end.

  • Ashley said

    I really wish there were more resources for hosted SharePoint. We have Office365 and a SP2010 deployment through that, but it seems like most of the resources are geared towards farm-based SharePoint.

    Since I am the most experienced in using SP in our company (which is not saying much since I have NO technical background), I often google to find answers. Articles like these are helpful to me, but I need more!
    We have an outsourced tech person plus a few internal overtaxed people who also have technical skills, so skilled help is hard to come by for us.

  • Ian said

    Regarding Rule #6 - sometimes you have to break this (as far as I can tell). Being relatively new at SharePoint we tried to deploy a service, something went wrong. Consequently the SharePoint timer service would no longer run, so it was impossible to schedule tasks and attempt to retract the service. The only way I could find was to manually remove the entry from the database.

Comments have been disabled for this content.

About Wictor...

Wictor Wilén is the Nordic Digital Workplace Lead working at Avanade. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for seven consecutive years.

And a word from our sponsors...