0

I configured a SharePoint 2013 server to be accessible through a reverse proxy by doing relevant changes in Alternate Access Mappings. I am able successfully login via the reverse proxy and perform other tasks like viewing calendar, adding tasks, viewing documents etc.

However, when I try to add a new document, it fails. After little investigation I found that when I click on the Add New Document button, there a 500 Internal Server Error for the corresponding GET request to upload.aspx.

Currently I have no clue how to resolve this. Any help will be appreciated.

5
  • 1
    Can you provide the subcode for the HTTP 500? You'll find this in IIS logs.
    – user6024
    Commented Mar 3, 2016 at 15:51
  • What reverse proxy is that? I've seen ISA do this with when dealing with extended chars in URL, but it was long time ago. support.microsoft.com/en-us/kb/940248 Commented Mar 3, 2016 at 16:59
  • @AzizKabyshev It is OpenIG (openig.forgerock.org). @TrevorSeward Can you please tell me where does to IIS log reside? I checked C:\Program files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS but there are so many files I am lost. Commented Mar 3, 2016 at 17:18
  • @SoumyaKanti IIS logging is documented here. Please find corresponding logging directory, reproduce the error, and look for lines that contain both upload.aspx and 500. Add that to the question Commented Mar 6, 2016 at 12:16
  • @AzizKabyshev Thanks for the info, I have been able to locate the IIS logs. However, after reproducing the scenario, I did not find any entry in the log file for upload.aspx or 500 Internal Server Error. When I match the call flow with that of at the Network panel of the browser, I can see logs for preceding and following exchanges that were successful. Very strange! I tried both W3C and IIS logging formats. Commented Mar 7, 2016 at 6:03

1 Answer 1

0

Based on your comment:

I did not find any entry in the log file for upload.aspx or 500 Internal Server Error. When I match the call flow with that of at the Network panel of the browser, I can see logs for preceding and following exchanges that were successful.

IMO, this most likely shows your reverse proxy is the reason. Long time ago ISA Server was known to fail to handle extended chars in URLs and show misleading HTTP 500.

What you can do:

  1. Diagnose further with IIS Failed Request Tracing turned on
  2. Change HTTP 500 error page in IIS at SharePoint and reproduce to see if 500 you are seeing is 500 from SharePoint
  3. Update reverse proxy solution bits to the latest available, test once more and if that fails - create a ticket with its helpdesk

I'd do #3.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.