Who's Online
11 visitors online now
2 guests, 9 bots, 0 members
Support my Sponsor

Common troubleshooting step : SharePoint web site and Central Admin 500 Internal Server Error

Saw a number of users facing issue “HTTP 500 Internal Server Error” when try to browse Central Admin site or SharePoint web site.


  • Try below Troubleshooting Steps:
  1. Open IIS Manager to make sure (Central Admin or Web Site) Application Pool was stopped Or SecurityTokenServiceApplicationPool application pool was stopped
  2. Navigate back to IIS manager -> Central Admin or Web Site or SecurityTokenServiceApplicationPool application pool-> Advanced Settings
  3. Navigate to the Identity option.
  4. Now Start the Application pool and try to browse the site.
  5. Open IIS manager again to check if all Application pool are started


  • If we still face same issue, try below:
  1. Go to Start > Administrative tools > Local Security Policy > Local Policies > User Right Assignments > Impersonate a client after authentication properties
  2. Add the Application Pool account for the site which is not working
  3. Reboot the server, so the changes can take effect
  4. Browse the site and it should work fine


  • If we still face same issue, try below:
  1. Log on to the SharePoint server Domain Administrator.
  2. Open Internet Information Services (IIS) Manager > In navigation tree, select the server >Click on the Feature Delegation icon
    3. In the Actions area, click Custom Site Delegation > select the SharePoint Central Administration\SharePoint Web Site.
    4. In the list of features, select the Modules feature > In Actions area, click Read/Write.
    5. n the list of features, select the Handler Mappings feature > In Actions area, click Read/Write.
    6. In the list of features, select the HTTP Response Headers feature > In Actions area, click Read/Write.
  3. Close Internet Information Services (IIS) Manager
  4. Perform IISRESET and try to browse site


  • If we still face same issue, try below:
  1. Open powershell > browse to below path
    C:\Windows\Microsoft.NET\Framework\v4.0 folder
    aspnet_regiis.exe –iru
  1. Also perform same below folder
    C:\Windows\Microsoft.NET\Framework\v2.0 folder
    aspnet_regiis.exe –iru


  • If we still face same issue, try below:
  1. Click Start > Run > type Inetmgr
  2. In the left pane: expand until you see the Central Admin\ Effected website
  3. Click on it > In the middle pane > double click on IIS-Authentication >Enable Basic Authentication
  4. Restart IIS
  5. Try to browse site


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.
Go to c:\inetpub\wwwroot\wss\VirtualDirectories\<sitename>.  Look at the web.config file. Does it have a recent modified date? If yes, someone might have modified it

Open IIS and enable Failed Request Tracing.
1. In IIS, click on the down site in the left pane under the Sites heading > In right panel > under the Configure heading > click Failed Request Tracing > Click the Enable checkbox > notice the path of the logfile.

  1. 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 > choose Next> For the status code, enter 500 >  Click Next > Leave all providers checked >Click Finish

  2. Now go try to access the site, and get the 500 error

4. 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. Review the error for details

  1. 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.

Leave a Reply