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.
