Toll Free: +1 888 900 4529 |   Toll Free: +44 800 088 5522

ECP And OWA Logins Fail With Error 500 in Exchange 2013

Mike Jackson | April 1st, 2015 | general

In November 2013, Cumulative Update 3 was released for Exchange Server 2013. This update resolved many issues with Exchange Server and proved to be advantageous for both Administrator and clients. However, the users can encounter various issues with the Cumulative Updates.

Issues With Cumulative Updates of Exchange Server 2013

With Cumulative or some other updates, the users can come across some difficulties after the installation. Some of the issues include:

  • Powershell shortcuts get omitted.
  • Virtual Directories
  • Missing of Powershell dll’s
  • OWA, ECP or Active sync do not work properly
  • Missing of reference from the registry
  • Issues with the certificate
  • Improper updation or breakage of ASP.net

In case of Cumulative update 3 and above version, the basic functionalities that get hindered are:

  • OWA
  • ECP

exchange-recovery-new

Indication of the issue

On installing Cumulative Update with Exchange Server 2013 and above versions either in DAG or non DAG mode, access to OWA or ECP is denied but it is found that Outlook is working effectively.

If case of such scenarios either of the following errors will be generated:

  • Event ID: 4 & 1309 : caused due to ASP.net
  • Error 500: caused due to login failure of OWA or ECP

However, both the above mentioned errors can prevail in Exchange Server environment but we will focus on “ECP And OWA Logins Fail With Error 500 in Exchange 2013” . Let’s now move to the reason due to which this error occurs.

Cause Of The Error 500 in Exchange 2013

The main reason behind the log in failure of OWA and ECP is the mismatch of canary tokens between the client and server

A canary is usually a secret token between client and Server in OWA, ECP or some other web services that is stored in the cookie collection of the browser and gets submitted with various requests which the browser sends. For each request the value of GUID stored in the URL is compared with the one stored in session state. If the value of GUID stored in these location do not match or if the value of GUID is lost from the URL, the request becomes malicious and it is blocked. As a result of it, the users will encounter “http error message 500: Internal Server Error” and the Server will come across an unexpected condition that stops it from executing the request.

Functioning Of Canary Tokens In Normal Condition And At The Time Of Error Generation

As mentioned above that the mismatch of canary tokens between the client and the Server is responsible for the generation of error 500. Let’s have a practical look on the functionality of Canary tokens in normal state and at the time of error generation.

What Actually Happen

  • Navigate to OWA.
  • Provide username and password of the account.
  • If the login is successful, a session ID will be generated by the Server.
  • A cookie will be send to the user with the session ID.
  • Canary and Session ID gets stored in the session store state.
  • The canary gets rewritten into the URL and is send to the user.
  • The requested page is displayed by the browser.

What Happens When The Error Is Encountered

  • Navigate to OWA.
  • Provide username and password of the account.
  • The Server will generate a Session ID if the login is successful.
  • A cookie will be send to the user with the session ID.
  • The Server is not able to create shared secret token i.e. canary.
  • Canary and Session ID is not stored in the session store state.
  • The canary does not get rewritten into the URL or is send to the user.
  • Error message 500 is encountered by the browser.

How To Get Rid Of The Issue?

If you encounter ECP and OWA logins fail with the error 500 in Exchange 2013 then there is no need to lose your nerves. You can tackle this scenario by following these steps:

NOTE: It is advised to take backup before preceding these steps

  • Navigate to “ADSIEDIT.msc”.
  • Route to

CN=Client Access,CN=“Organization name”,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=“domain”

  • Right click on “CN=your Client Access Server” or “CN=your single or multi role server(s)” and select properties
  • Scroll to msExchCanaryData0msExchCanaryData1,msExchCanaryData2

NOTE: Check the subfolders too, as the canary values can be stored to them.

  • Copy entire value to a text file along with the attribute names and path.
  • Erase all the values on copying them to the text file.
  • Logon to CAS Server(s) or multi role Server.
  • Launch IIS management.
  • Navigate to application pools.
  • Select Recycle by Right clicking on “MSExchangeOWAAppPool”.

NOTE: At the time of recycle the established session will be lost but it is not an issue to be worried about.

  • Cmd: appcmd recycle apppool /apppool.name:”MSExchangeOWAAppPool”
  • Reboot entire mailbox Server, in the case of Single Role Architecture.
  • In case of multi role simply reboot the Server and skip recycling.

Conclusion

With the Cumulative Update 3, Exchange Server 2013 – OWA and ECP logins fail with 500 error. The basic cause of this error is mismatch of canary tokens between the client and the server. It is a tough condition in which the users lose control from OWA and ECP. However, one can tackle this situation manually by following the above mentioned steps.

The following two tabs change content below.

Mike Jackson

Mike Jackson is a technical writer and he wrote numerous blogs or articles regarding Exchange Server corruption issues with their solutions. You can follow him on Google+, Facebook and Twitter. If you have any query & solution regarding Exchange Server & Outlook apps then you can mail Mike at mike.edbtopstpro@gmail.com.