Why can't Microsoft get IE9 to work with the Exchange Management Console?

The thread complaining about problems administrators have running the Exchange Management Console (EMC) on their Exchange servers once they’ve installed IE9 must be one of the longest-running and least productive (in terms of Microsoft response) of any on the TechNet forums. Certainly I can’t think of another discussion that has lasted four months (the original post was made on 7 April 2011) about what seems to be a pretty fundamental issue without a patch or some other positive response from the Exchange engineering group. Given the quality problems due to test issues that have occurred in two recent roll-up update releases for Exchange 2010 SP1, this kind of issue makes you think that the recent actions taken to improve testing before the Exchange development group releases anything might need to take IE into account.

The problem is simple: when you have IE9 and Exchange 2010 installed on a Windows 2008 server (any version, any patch level), you cannot close EMC. Any attempt to close the console results in the error:

“You must close all dialog boxes before you can close Exchange Management Console”

This occurs even when all dialogs (such as those that you’d use to view mailbox properties) are closed.

The same issue occurs with Exchange 2007 servers and on workstations that have the Exchange management tools installed once IE9 shows up and makes its presence felt.

The only workarounds are to either use Task Manager to kill mmc.exe every time you need to close EMC or to remove IE9. The second option seems to be much the better option as the problem simply doesn’t occur with IE7 or IE8 on the server. Of course, the most proactive approach is simply to prevent anyone installing IE9 on a server - and threatening dire consequences should anyone accept the offer of Windows Update to helpfully download and install IE9 for you.

EMC is an important tool for most Exchange administrators. Sure, you can fire up the Exchange Management Shell (EMS) and manage servers by typing individual commands in the shell but my experience is that quite a few administrators don’t like EMS very much and try to do as much as possible in EMC. They find that the GUI of EMC protects them from making mistakes that they fear are too easy to make when you’re unused to EMS commands and they like the wizards that Microsoft has thoughtfully built into EMC to make tasks easier to perform. Therefore any problem that afflicts EMC becomes a huge issue that needs to be resolved.

Indications from Microsoft are that the root cause lies in the interaction between the Microsoft Management Console (MMC) framework and IE9. Details are sparse but speculation is that IE9 has introduced some code changes that interferes with the commands EMC executes in response to an administrator attempt to close the console.

Now, everyone who works in the technology industry understands the complex nature of the software that we use today and can easily comprehend how a bug might find its way into code and elude even the most thorough and automated test suites. Such is the nature of technology life. However, it’s quite another matter when the development groups responsible for major Windows components such as IE9 and MMC can’t extract the proverbial finger after four months of user angst to provide a fix. I don’t actually blame the Exchange development group for this fiasco as they don’t have responsibility for the code where the problem lies. You could ask them to beat up the IE9 and MMC teams to force a resolution but that might not lead to the right result. I’m sure that the Exchange team is having the right kind of pointed, direct, one-syllable and easily understandable conversation with their colleagues to convince them of the need to do the right thing and get a fix out but their effort doesn’t seem to have had the right result to date.

I don’t like IE and haven’t liked IE for quite a few years. My preference is to use Chrome in as many situations as possible and leave IE alone to fester in whatever version of the software comes along with an O/S build. Maybe that’s why I haven’t been concerned until now about this long-running saga. So come on Microsoft, show that your development groups can actually work together to solve issues that cause administrators pain and grief in their working life, and let’s do it soon, before we all die of old age or conclude that IE is an abomination that should never be trusted on any working system.