When I tried to access the SharePoint Central Administration site, I would get HTTP 500 errors. I was able to resolve this issue so I thought I should share some of my troubleshooting tips.
As SharePoint admins, we get sucked into IIS and SQL Server, it's just the nature of the beast. Save yourself therapy and hours crying yourself to sleep and just accept it. Today we’re going to look at a few different steps as we troubleshoot issues with issues when the SharePoint sites don’t come up, specifically in IIS.
First, what is the HTTP 500?
Ah yes, our nemesis, our old friend, the page could not be displayed. The important piece of this page is the status code on the top right – 500. That’s the status code. You can find more on general status codes in this
Microsoft KB article. It’s a fairly generic error code. How do we know what’s broke? There are many causes for this error, so I just try to give you a basic checklist of things to check that should point you in the right direction.
Troubleshooting Steps
Here are a few steps that I like to do when SharePoint appear to be down:
1. If the SharePoint sites don’t come up for you, first try another client machine to make sure it’s not just you. These are unlikely to be client-side, but let’s rule that out anyway. OK, so neither you nor your users can get to SharePoint, awesome.
2. The next step in my mind is to get on the SharePoint server and let’s rule out DNS or networking issues. Pull up the SharePoint sites via their URL on the server desktop. If this works, then go to your IT admins as Domain Name System (DNS) or there’s something with the network. I had one issue one time where IT had switched the subnets around, and only users on a remote subnet couldn’t access SharePoint. It happens. If it still doesn’t come up, it’s definitely something server-side and it’s time to dig deeper.
3. From the SharePoint server, try to pull up the Central Administration site. This should usually come up with this error. If this doesn’t come up, we would likely be facing like a database access error or something. But it’s good to rule out. Assuming it comes up, go check the AAM (alternate access mappings) and make sure nothing changed.
4. From here you could do a couple things. But since one web application works and one doesn’t, there’s only a few things that allow some sites to work and others not. Let’s go check the IIS application pools. Open up IIS Manager, expand the server node and click Application Pools. Make sure the application pool that hosts your non-working SharePoint site is started (note – it’s normal for the SharePoint web services root to be stopped). Sometimes this can happen after a server reboot. You could also do an iisreset or even a full reboot here, but it is unlikely to resolve it.
Besides being stopped, it could be started or continuously stop. Causes could be authentication related. Check the IIS event logs (Event Viewer), and the SharePoint ULS logs and see if they point you in a direction.
5. While in your IIS, go to the site(s) in question and check their bindings. Are the correct hostname bound to the site? This just makes sure that IIS is listening on the right host.
6. So at this point, we’ve checked all the normal things and the problem seems to point with the site itself. What does this leave? Things like the web.config, applicationHost.config, etc.
7. Go to c:\inetpub\wwwroot\wss\VirtualDirectories\<sitename>. Look at the web.config file. Does it have a recent modified date? In my case, it did. OK, so we’re highly suspect of the web.config, how do we know what?
Let’s go back to IIS and let’s enable Failed Request Tracing.
In IIS, click on the down site in the left pane under the Sites heading. We have to enable Failed Request Tracing. Do this via the right panel, under the Configure heading, click Failed Request Tracing. Click the Enable checkbox, and notice the path of the logfile.
Now that FRT is enabled, we have to tell it what to capture. In the middle pane, under the IIS group, click the icon called Failed Request Tracing. On the right under Actions, click Add.
In the wizard, leave All Content select and choose Next.
For the status code, enter 500. Click Next.
Leave all providers checked, and click Finish.
8. Now go try to access the site, and get the 500 error.
9. That should have written what we needed to the log file. Go to the path defined for the log earlier. You will find two files, an XML file (the log with errors) and an XSLT that styles the XML for easy viewing. Open the XML in a browser to see the error.
10. Review the error for details:
This will show you a specific error, and notice that the line number with the issue is listed as well. Great! Now we have something to work with.
11. In my case, in the web.config there was a Session state entry was duplicated. This is normal, but there was a remove statement that prevented one of them from being loaded, which was commented out, in turn causing the duplicates to both load:
<!-- <remove name="Session" /> –>
I removed the comment out lines (highlight) and saved my web.config. Success - the site came up! Confetti fell from the rooftops, Champagne flowed from the heavens, and there were many celebratory handshakes.
So do you want to leave tracing enabled? I don’t see the harm. It is capped per the initial configuration, so it won’t fill up the C drive. If you’re getting that many HTTP 500 errors, you likely have other issues.
I hope this gives you a few more tools in your bag of troubleshooting tricks when SharePoint won’t come up!
