Exchange Server 2013: HTTP 500 Errors for ECP and OWA (Fresh Install)

Exchange Server 2013: HTTP 500 Errors for ECP and OWA (Fresh Install)

Sometime ago I changed my domain name (you can read more about it here: How to: Rename an Active Directory Domain Name) to better address some business needs but unfortunately I had my Exchange Server offline as we are mostly using Exchange Online now. The issue is that if you have the servers offline and you complete the domain name change your old servers don’t get the new changes. This ended up resulting on us being unable to bring that server back to fully functional status and losing our ability to manage our Exchange Hybrid configuration. Long story short I needed a new server to manage Exchange Online. I decided to grab a new VM and deploy Exchange Server 2013 CU2 but I encountered a blank HTTP 500 page after providing my credentials to enter Exchange Server 2013 ECP. Below is a brief story of this long saga:

As many of you probably know by now, HTTP 500 error messages are generally attributed to either Certificate misconfiguration or Authentication misconfiguration of OWA and ECP.

Certificate problems arise when the certificates you are using on the backend are corrupted or there might be another issue like validation, etc. This generally can be easily resolved by assigning a new certificate to your Exchange WebServer. You can do this via Exchange Shell or the not so recommended way: directly on IIS.

Authentication problems arise when you are not using the same authentication methods on your front and backend Exchange WebSites. The default recommended approach is Forms Based Authentication. The recommendation at this point is to use the Exchange Management Shell to establish both the OWA and ECP sites to accept Forms Based Authentication.

Finally, there are some weird issues that might require you to completely remove OWA and ECP virtual directories (again, you can use the Exchange Management Shell) and recreate them. By default Forms Based Authentication should be enabled but feel free to double check.

So that pretty much covers 99% of the problems out there referring to HTTP 500 error when accessing ECP. But in my case it was something much worse.

I had tried the three solutions described above with no avail and proceeded to upgrade to Cumulative Update 3 and the most recent Service Pack 1 in hopes that would do the trick. After many failures I came across a post that narrated a similar situation:

• User had installed an Exchange Server from scratch to the letter (per Microsoft’s instructions)
• User got Error 500 regardless

So he finally got Microsoft on the line and after much troubleshooting they determined a setting on AD was the culprit. I obviously tried deleting those entries and had no luck but it pointed me in the right direction: Something got really messed up on the backend that I couldn’t use Exchange ECP. I could had spent some time on figuring out exactly what was messing up my setup but I decided there were too many variables and too many configurations I was better off starting from scratch. As I mentioned, we had migrated to Exchange Online so wiping all local settings was not a big deal for us.

First, uninstall / remove Exchange Server from all servers that are still loyal to you (lol). Once that is done is time to remove those rebel ones straight from Active Directory as they won’t cooperate. For this you are going to need to use ADSIEDIT and follow this instructions: Exchange 2013: How to completely remove all settings from Active Directory.

Once you have wiped all the Exchange Server Configuration information from Active Directory you are ready to proceed with the installation. You can follow this simple instructions to quickly deploy it: How to Install Exchange Server 2013 SP1. You’ll notice that this time around there is no HTTP 500 blank page after you install Exchange and everything works as it should!

Fortunately it seems that the hybrid configuration is also stored online or somewhere else. After re-installing Exchange 2013 SP1 (with a previous CU I did have some issues) it picked up my hybrid deployment and from elsewhere in AD my users and groups. Because of this I only did a Hybrid sync to reconfigure my connections between onPremise and Cloud Exchanges, assigned a certificate and establish my externals URLs and I’m all good and working again! Yay!