Logging into my Exchange 2013 Exchange Control Panel (ECP) this morning at https://exchangehead/ecp , I was presented with the usual login screen. When I submitted my credentials, the site returned an HTTP 500 Internal Server Error:
I tried to access the page on “ExchangeSatellite”, my secondary Exchange server, with the same result. Using different user accounts made no difference. A quick glance through the Microsoft Exchange services showed most services ‘Running’.
Having never seen this error before, I deployed Google-Fu and read through Brendon Lee’s TechNet Blog entry HTTP 500 Internal Server Error when logging into Exchange 2013 Exchange Control Panel (ECP). Bingo. Brendon described how this error can happen when the user’s mailbox GUID is not properly proxied between the Client Access Server (CAS) and the Mailbox server (in my case, both roles share the single server). A common reason the ExchangeGuid is not handled is because its not found in the first place. As Brendon explains,
If the Exchange 2013 CAS needs to know where to proxy a request, but the request is coming from an account that has no mailbox, and thus no ExchangeGuid associated with it, how does Exchange know which mailbox server to proxy?
Exactly: Exchange recognizes the account as being present and valid, authenticates and logs me in, and then comes up empty when it looks for the ExchangeGuid. My first thought was to check if any of the mailbox databases are mounted. Since I couldn’t get into ECP, Exchange Management Shell (EMS) came to my rescue:
So it seems both databases are unmounted. Are they both Mailbox Databases?
So, with crossed fingers, let’s try to Mount them cleanly:
No red errors… let’s see.
They don’t seem to be mounted, and a login attempt return the same HTTP500 error.
Doing a bit more research, the culprit may be the Microsoft Exchange Replication service. I recently (yesterday) added a secondary Exchange server to the domain, so I check the service on both Exchange Servers. Sure enough, the service is stopped on ExchangeHead. I start the service, and retry the database mount. Now, we see they’ve both mounted succesfully.
Let’s attempt an ECP login…
All is well. ECP shows the databases as mounted:
I haven’t looked into why the databases unmounted. In a production environment, this could cause catastrophic problems for mail flow and client access, and would need to be a) remedied ASAP, and b) the root cause determined. Thankfully my environment can accept failures like this, although this presents a learning opportunity to determine why the dismounts occurred.