One of the most common problems with Exchange Server 2013 is not being able to access the Exchange Administration Center (EAC). This problem usually has an easy fix. Let's look at some troubleshooting techniques you can use if you're having problems with the EAC.
What happens when you access the EAC?
You should base your troubleshooting efforts around what happens when you try to access the
You may discover you can log in to the Web portal, but are unable to access the Exchange Admin Center. For example, you might see a generic message indicating something went wrong (Figure 1).
If you get this type of error, there are a few things to check. First, make sure your client access server can communicate with your domain controllers and back-end mailbox servers. If your firewall is configured to allow Internet Control Message Protocol traffic, you could use the ping command to verify connectivity.
If the client access server can communicate with the domain controllers and any back-end mailbox servers, then check Exchange-related services. There are a number of Exchange-related services that must be running for the EAC and Office Web App (OWA) to work properly (Figure 2). Any service with an Automatic startup type should be running. If a service isn't running, try to manually start the service by right-clicking on it and selecting the Start command from the shortcut menu.
It's worth noting that although the Client Access Server hosts the Exchange Admin Center, the problem might not always be on the Client Access Server itself. Theoretically, it's possible for a mailbox server service failure to cause the EAC to malfunction.
Outlook Web App
Another common problem is when an attempt to access the Exchange Admin Center takes you into OWA instead. There are several things you can check to resolve this issue:
Check the URL. Before you delve too deeply into the troubleshooting process, double-check the URL you're using. To access the Exchange Admin Center, you should enter http://<server name>/ecp. Exchange will take you into OWA if you are entering http://<servername>/owa, even if you're logged in as an administrator. This is by design.
Assuming you're entering the correct URL and you're attempting to log in using an account with Exchange administrative privileges, try adding a slash to the end of the URL: http://your server/ecp/. The trailing slash technically shouldn't be required, but some Exchange admins report the slash made the difference between the URL working and not working.
Append the URL string. If you're running Exchange 2010 and Exchange 2013 in the same organization, the location of your Exchange mailbox will affect your ability to access the Exchange Admin Center. If your mailbox is stored on an Exchange 2010 server, then entering http://your server/ecp will take you to the Exchange Control Panel, not to the EAC. Similarly, if your mailbox resides on an Exchange 2013 server, entering http://your server/ecp will take you to the EAC -- not to the Exchange Control Panel.
The easiest way around this issue is to append the version of the client access server you want to access to the end of the URL string. Exchange Server 2010 is version 14 and Exchange 2013 is version 15, so you can append the ExchClientVer parameter to the end of the URL string and specify either 14 or 15 to access the Exchange 2010 or 2013 client access server. For example, if your mailbox resides on an Exchange 2010 server and you need to access the EAC, you can use this URL: http://your server/ecp?ExchClientVer=15.
One of these workarounds should fix the problem. If not, there is one last bit of advice. If you're entering the Exchange Admin Center URL and are being taken to an OWA logon prompt, attempt a logon. In some cases, Exchange will display an OWA logon prompt but will redirect you to the EAC after a successful login.
About the author:
Brien Posey is a 10-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a chief information officer at a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation's largest insurance companies and for the Department of Defense at Fort Knox.
This was first published in September 2013