Microsoft SharePoint is a complex platform consisting of ASP.Net websites, WCF web services, SQL Server databases, Windows Services, DNS records, SSL certificates, and much more. Based on your application, it can be an enterprise content management system, records management system, workflow hosting solution, enterprise search gateway, a business intelligence portal, your company’s intranet, your company’s public website, a corporate social media platform, or even your IT help desk ticketing system.
SharePoint is a very powerful and flexible technology hub that almost every Fortune 500 company has running in its datacenters. For new SharePoint administrators or help desk professionals, it can seem like a daunting task to fully understand the intricacies, integrations, and dependencies that may lead to end user errors when accessing a site, saving a file, or publishing page content.
As a SharePoint administrator with a decade of experience digging into error codes, event logs, ULS logs and other failure indication sources I’d like to bestow upon you some of my lessons learned and the strategy I follow when troubleshooting errors reported by an end user, SCOM monitoring alert, or just plain funkiness when browsing through SharePoint sites. Due to the sheer complexity of SharePoint, its dependencies, and all the bells and whistles you can enable, the list of possible errors is endless. Throughout this series we will discuss tools that will help you decode issues and how to logically dig deeper and deeper into the root cause of an error.
Let’s start with a common error which would indicate a complete SharePoint site outage – HTTP Error 503. The service is unavailable.
This would classify as a major problem as the SharePoint site is completely inaccessible, but it is probably not that difficult to fix. If you load developer tools in Internet Explorer or in Google Chrome by hitting F12, click the Network tab, and click enable capturing you’ll get a little more information about what is\is not returned from the web server. The browser developer tools are very useful when troubleshooting partially loading pages or slow pages.
So it seems like our web request is probable making it to the web server, but IIS is not responding. Assuming you have access to remote into the SharePoint web server we can verify this by finding and opening the IIS logs. You can find Internet Information Services (IIS) management console by clicking Start > RUN > IIS and clicking on IIS.
Once the console opens you can locate the IIS logs by clicking the server name in the tree view and then on the main panel finding “Logging.”
Double click on Logging and you’ll see the IIS log location under the Directory field. In our case they are saved to L:\IISLogs
Before we hop over to the log location on the L drive we need to find the ID of the IIS site. To do this click on “Sites” in the IIS tree view. This will open a new panel that has a column for site ID. The one we are interested is US Cloud Demo 1604 site. Note the ID ends in 9448.
Let’s go find the IIS log for this IIS Site in L:\IISLogs.
You’ll find a folder corresponding to the IIS Site ID we just looked at above.
Let’s open up the folder for our demo site and open the most recent .log file.
As you can see there are no 503 errors reported in the log so the request never made it to our IIS site. There has to be something preventing the request within IIS. If you are not familiar with IIS, there is something called an application pool that manages the threads used for one or more IIS sites. Each application pool has a service account that it runs. Let’s go back to IIS and click on Application pools.
In this case we have an application pool with a descriptive name that is stopped. This should not be stopped. To verify this app pool in fact controls our SharePoint IIS site named USCloud Demo 6104, highlight the application pool and click on view applications.
You can see here that our application pool is mapped to the US Cloud Demo 1604 SharePoint site which is not responding. Let’s click back on Application pools and then right click on the usclouddemo1604 pool. Then click start.
If you now try and browse to the SharePoint site in your internet browser of choice the site will load!
This is just one example of a common error and fix that a SharePoint user could encounter. There could be other causes for 503 errors and for the application pool to be stopped or crashing. Usually if the application pool continuously crashes on every web request you may have a permission missing on the filesystem for the application pool account.
We hope you found this article and walkthrough helpful. Stay tuned for more SharePoint troubleshooting goodness!
Let’s discuss your unique needs!
You can hang on to it for handy reference!