Three reasons behind Exchange 2010 Management Console failures
It’s not uncommon for the Exchange 2010 management console to break down. Some failures may be attributed to changes made since Exchange 2007, but there are other causes as well.
Exchange Server 2010 is a complex product and there are a number of technical problems that can occur. Surprisingly, one of the most common issues admins encounter is Exchange 2010 Management Console failures. Let’s find out why the console may cease to function and how to fix it.
1. Connection problems
The Exchange Management Console (EMC) has changed a lot since Exchange Server 2007. In Exchange 2007 the console has relatively few dependencies. Things work much differently in Exchange 2010 though. Every EMC session is treated as a remote session, even if you’re opening the console locally on an Exchange 2010 server. If the console can’t connect to the “remote” Exchange server then you’ll probably receive an error message (Figure 1).
Figure 1. Connection failures often cause the Exchange Management Console to break down.
The EMC is essentially a graphical front end to the Exchange Management Shell (EMS), which is built on PowerShell. Therefore, when you open the EMC, the console opens a remote PowerShell connection. There are three main mechanisms at work when this happens: Internet Information Services (IIS), WinRM and Web Services for Management (WS-Management).
To solve problems like the one above, first check to make sure that the Default Web Site is accessible on all of your Exchange servers. The error shown in Figure 1 was triggered when I opened the IIS Manager, selected the Default Web Site and clicked Stop.
Although stopping the Default Web Site can trigger an EMC failure, the console can also fail if the Default Web Site is running. If anything prevents the Default Web Site from being accessible, then it has the same effect on the EMC as stopping the site.
In order for the EMC to establish a remote PowerShell session, WinRM must be able to communicate with IIS over TCP Port 80. Therefore, if you have a firewall on, or in front of, your Exchange server that is blocking HTTP traffic, the firewall might be the source of the problem. Remember, it’s not just client access servers that must be able to receive HTTP traffic. All Exchange 2010 servers must be accessible to WinRM via TCP Port 80.
2. Site redirection problems
Site redirection is another common cause of an Exchange 2010 Management Console failure. Some administrators try to configure their client access server> (CAS) so that any inbound HTTP requests are automatically redirected to the OWA virtual directory.
If done incorrectly, this type of redirection effectively prevents HTTP traffic from reaching the Default Web Site, resulting in an EMC failure. Forcing the redirection of HTTP traffic on your client access servers can also impact ActiveSync and Outlook Anywhere.
3. Authentication problems
The EMC can also break down as a result of an authentication failure. When a remote PowerShell session is established, IIS uses Kerberos to authenticate the connection. As strange as it may seem, Kerberos only functions properly if the PowerShell virtual directory treats it as a native module.
To test this, go to the IIS Manager and navigate to Sites -> Default Web Site -> PowerShell. Next, double-click the Modules icon, then scroll through the list of modules until you locate KERBAUTH. This module should point to C:\Program Files\Microsoft Exchange Server\Bin and it should be listed as a Native module (Figure 2).
Figure 2. The Kerberos authentication module must be listed as Native.
If the Kerberos Authentication module is listed as a Managed module rather than a Native module, it’s because the module is being directly used by the Default Web Site. If you select the Default Virtual Directory container and double-click the Modules icon, you should not see KERBAUTH listed.
If the module is listed, you must determine which virtual directories require the module. You must then remove the module from the Default Web Site and apply it directly to the virtual directories that require it. Exchange 2010 automatically adds the Kerberos Authentication module to the virtual directories where necessary. Therefore, you should only encounter this particular problem if the server is hosting a non-Exchange website that’s using Kerberos authentication.
As you can see, there are a number of potential causes for an EMC failure. If none of the techniques I’ve described correct the problem, check the bindings for the Default Web Site to make sure that the HTTP bindings have not been removed. The EMC can’t function if IIS only has bindings for HTTPS (SSL).
ABOUT THE AUTHOR: Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO at a national chain of hospitals and health care 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.
