none
Exchange 2013 OWA Login Error HTTP 500

    Question

  • I have a dual Exchange server 2013 setup with two servers running both Café and Mailbox roles in a DAG. We are in the process of migrating from 2010 to 2013, all mailboxes have been moved, and everything is pointing to the new servers.  The only thing left on 2010 is our public folder database.

    Here is the problem:

    After attempting to login to our server at https://mail.domain.ca/owa, they get a big frown and a message that says "something went wrong Sorry, we can't get that information right now. Please try again later. If the problem continues please contact your helpdesk"

    In the address bar it says httpCode=500

    The weird thing is that if they change the url to https://mail.domain.ca/ecp, they can log into their "My account" just fine.

    Exchange ActiveSync is up and running just fine, no errors at all, and all our outlook 2010/2013 clients are working perfectly fine as well, it is only OWA.

    Monday, August 12, 2013 9:14 PM

Answers

  • I was on the phone with Microsoft for a few hours, and here is what we did to fix the problem:

    1. Upgraded to the latest version of Exchange 2013 CU2 (V2).  We were on the initial build (712.22), and CU2 V2 is 712.24.

    2. Changed bindings of the default website to conform to Microsoft recommended settings ({http port 80 *}{http port 80 127.0.0.1}{https port 443 *}{https port 443 127.0.0.1})

    3. Insure that "Require SSL" is checked on the root of the default website

    4. remove all of those "HTTP Redirect" settings that we like to use to make the users life easier

    So between those four items the issue seems to have been resolved.

    Thursday, August 15, 2013 6:57 PM

All replies

  • Hi,

    Based on my research, you can refer to the following resolutions.

    1. Try rebuilding the OWA virtual directory

    To remove: Remove-OwaVirtualDirectory -Identity "exchange server name\owa (default Web site)"

    To build: New-OwaVirtualDirectory –WebSiteName  <default website>

    1. Verify that the Microsoft Forms Based Authentication service is running on all Exchange servers. 

         A similar thread: http://social.technet.microsoft.com/Forums/exchange/en-US/8cf6886f-a96f-44f1-88ee-bd3a42349fa9/owa-brings-up-logon-screen-but-after-login-gives-http-500-internal-server-error

         To check:  Get-OwaVirtualDirectory -Server <server name> | fl *auth*

         To enable: Set-OwaVirtualDirectory -Identity " server name \owa (Default Web Site)" -FormsAuthentication $true

    Hope it can help you.

    Best regards

    Tuesday, August 13, 2013 12:18 PM
  • Thanks, I did try rebuilding the OWA directories, but it didn't appear to make a difference.

    Exchange 2013 doesn't appear to have a separate forms based authentication service.

    What makes this extra-weird is that it will generally work fine on my work machine, but doesn't work on anyone else's machine. It also affecting the ECP directory as well, logging in will give the error message "Sorry, your request couldn't be completed. Try deleting the cookies from your browser, and then sign in again. If the problem continues, contact your helpdesk.".

    Of course, on my own machine at work the ECP works 100% fine and always has.

    • Edited by daedalus7 Tuesday, August 13, 2013 10:01 PM
    Tuesday, August 13, 2013 10:01 PM
  • Hi,
    For further troubleshooting,  please collect the IIS log.
    1)    On the Exchange 2013 Client Access Server, locate the folder “c:\inetpub\logs\logfiles\W3SVC1” (If the IIS log is not enabled, please enable it and try to reproduce this issue.)
    2)    Check the log files inside the folder and post the related error codes.

    Thanks

     

    Thursday, August 15, 2013 2:54 AM
  • I was on the phone with Microsoft for a few hours, and here is what we did to fix the problem:

    1. Upgraded to the latest version of Exchange 2013 CU2 (V2).  We were on the initial build (712.22), and CU2 V2 is 712.24.

    2. Changed bindings of the default website to conform to Microsoft recommended settings ({http port 80 *}{http port 80 127.0.0.1}{https port 443 *}{https port 443 127.0.0.1})

    3. Insure that "Require SSL" is checked on the root of the default website

    4. remove all of those "HTTP Redirect" settings that we like to use to make the users life easier

    So between those four items the issue seems to have been resolved.

    Thursday, August 15, 2013 6:57 PM