I had a client call me the other day as he was having an issue with a
couple of his SharePoint 2010 sites that seemed strange, the sites just
stopped working. When anyone tried to access the sites, they would get
HTTP 500 errors. I was able to resolve this issue for the client 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?
The page could not be displayed.
The important piece of this page is the status code on the top right
– "HTTP 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 c
orrect 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!
