The Strange Case of IE9, MMC, and Exchange: Some light appears at the end of the tunnel

On August 17, I wrote about an annoying and longstanding problem that surfaced on computers where the Exchange 2007 or Exchange 2010 management tools are installed once IE9 is introduced to the mix. Microsoft had been pretty quiet on the topic ever since reports first emerged in April that the Exchange Management Console (EMC) refused to close properly after the installation of IE9 and a firm impression had taken hold within the Exchange community that the Microsoft engineering groups responsible for the technology involved in the situation (Exchange, IE, and the Microsoft Management Console - MMC) were having some difficulty in figuring out the root cause and how best to address the problem.

No one questions the fact that large organizations have their own tempo when it comes to resolving internal debates. Furthermore, no one questions that it can be hellishly difficult to determine just what’s going wrong when a new software mix suddenly exhibits odd behavior. Microsoft would therefore have been forgiven if they had used their own software bug reporting and resolution processes to address the bug in a reasonable timeframe. For the purpose of discussion, let’s say that two months is a reasonable time. But as the summer months wore on the people who followed the topic in the TechNet forum for Exchange were puzzled and concerned that progress seemed to be extraordinarily slow. And despite the best efforts of the redoubtable Scott Schnoll of Microsoft to explain what was going on, the situation didn’t improve as the problem entered its fifth month. Excusing the matter by asserting that issues reported in the TechNet forum don’t really count until they are formally logged with Microsoft or that this wasn’t really an important issue didn’t cut the mustard either.

In fact, the perception within the Exchange community steadily worsened because people put two and two together when they compared the IE9 problem to other quality issues that Exchange had suffered with Roll-Up Updates 3 and 4 for Exchange 2010 SP1 in the same timeframe. The question was whether Microsoft’s QA and testing processes were capable of finding bugs before they surfaced in production. To be fair, Kevin Allison, the General Manager of Exchange Customer Experience, acknowledged that Microsoft had some work to do to improve their QA processes in a post about the withdrawal of RU4 to the EHLO blog that said:

We are commencing an internal review of our processes to determine how we can best prevent issues such as this one arising in future.”

The IE9 issue is not linked to the problems that afflicted RU3 and RU4 and I don't believe that the recent hiccups reflect an overall quality problem with Exchange. My personal experience with Exchange is that they take quality very seriously and the proof of that is seen in the work done in areas such as the elegant user interface delivered in Outlook Web App and the high availability features of the Database Availability Group. In this instance, I think that the RU problems were simply scenarios that were not covered in Microsoft’s automated tests that code goes through before it is released. Gaps in coverage are regrettable but probably inevitable over the lifetime of a very complex and very large product. The important thing is that Microsoft acknowledged the problem and is working to address it. In fact, I believe that the Exchange team now pays enormous attention to testing updates before they see the light of day outside Microsoft. Long may this attention last!

What the IE9 issue demonstrates is that the reuse of code from another engineering group makes great economic sense but can deliver a sting in the tail. A note from a senior Exchange manager to me reported:

The root of the issue is IE9 made a change in the way it handled the hosting of html. This change did impact all MMC snap-ins (not just Exchange), was identified in Beta, and IE felt they had resolved this as part of their release bits. The problem is that depending on the action taken in the MMC a hidden window is opened up, perceived to be a dialogue box by IE, and IE will not close with the dialogue box open. What has happened since then is we have identified a scenario specific to Exchange’s snap-in that the fix did not resolve.“

So there you have it. MMC was affected by a change that was made in IE9. The problem was identified and the IE9 engineers thought that they had fixed the bug only to discover that Exchange 2007 and Exchange 2010 expose a scenario that hadn’t been considered when the bug was fixed.

Microsoft posted to EHLO last Friday to say that:

“… things are still in process and we do not have a firm solution or a date to share with you yet. We do, however, want to say that we are very aware of this issue and several teams are collaborating and working to get this addressed. Once more details are available, we will be sure to share them here.”

Exchange uses their EHLO blog extremely well in terms of communicating information about the product. It's one of the most popular and content-rich blogs run by Microsoft engineering groups so the silence on this topic was surprising. It’s great to read the reassurance from the Exchange team that they are working with the IE group to resolve the issue and identify if any other cross-dependencies exist, it’s an enormous pity that this particular problem has been allowed to fester for so long and that Microsoft has been so quiet on the communications front before now. Communication creates confidence and people would have been a lot happier had Microsoft come out far sooner to say “we know that a problem has been seen with EMC after IE9 is installed on computers and the Exchange and IE engineering groups are working together to investigate and rectify the root cause.” Of course, you’d hope that action would back up the words and that the engineers in the  IE, MMC, and Exchange groups would then work to turn aspiration into reality.

I hope that the lesson is learned and this is the last time that we see a five month delay before the tens of thousands of talented people who work within Microsoft listen to their customers and move to fix a problem that might have been informally reported first but then rapidly spiraled to became a Cause Célèbre. Or in plain English, something that simply needed to be fixed fast.

Discuss this Blog Entry 4

on Sep 14, 2011
Tony, you say "Gaps in coverage are regrettable but probably inevitable over the lifetime of a very complex and very large product". maybe the real reason is this: Exchange is very complex and very large. Most probably too complex and too large. There hasn't ever a need to be so complex and so large. E-mail should have been like utilities: you turn the tap and water flows. Exchange has not been simple and easy to implement, to use, to maintain, starting with Exchange 2007. There are too many roles, too many command line commands, too many dependencies. Everything is too much. And you get so little. It is just contrary to what Microsoft claims "Do more with less". What can be done now? The main idea behind the Exchange Server must be changed. The structure must be simple: simple to implement, simple to operate, simple to maintain. And Microsoft must remember in-place upgrade again: For the last two versions of Exchange, you can't do in-place upgrade.
on Sep 16, 2011
Well, I disagree that Exchange is too large and complex. I think the product has evolved to meet the needs of customers - mostly enterprise customers at this stage. But that's probably OK because I think that most of the small to medium businesses that use on-premises Exchange today and who possibly are confused by the power and range of Exchange will move to Office 365. Customers that stay with the on-premises version will have specific reasons to do so and will be prepared to invest the time necessary to tweak Exchange to meet their needs. As to the in-place upgrade argument, I don't buy the need for this to happen at all. There has been too many changing parts (including a transition to 64-bit Windows OS) to make it practicable to engineer a high-quality in-place upgrade process that is capable of catering for the huge array of environments into which Exchange is deployed. Of course, everyone is entitled to their own views... TR
on Nov 14, 2011
last windows update: no more Error on closing the Exchange console
on Sep 16, 2011
The problem isn't the complexity of Exchange, it is the flawed architecture of having MMC dependent in any way, shape or form on IE! It no doubt harkens back to that flawed decision by Microsoft to integrate the browser into the Operating System. It has bitten them many times, here is just another example. I agree 100% with Murat on the in-place upgrade, or lack there-of with Exchange. How does that approach reduce cost of ownership for businesses? Doesn't happen in IBM/Lotus Domino architecture.

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×