Oh dear… Problems do seem to have a habit of reoccurring, especially when it comes to software. Or maybe it’s just that repeated problems seem more obvious when seen in software. Or just that those who work in IT are narky people who complain a lot (I definitely fall into this category).
Last August, I wrote about the way that the Exchange team had included a security update into Exchange 2010 SP2 RU4. The issue was simple. Because the update was marked as having fixed a security issue, it became much more of a pressing matter to install RU4 quickly. And because RU4 was deployed quickly, people did not have the chance to analyze the contents of the update and then test it thoroughly as they normally would before putting the new software into production. AS it turned out, RU4 included a change to the way that the Managed Folder Assistant processed calendar items that could have caused some difficulties for deployments.
Coming right up to date, a problem was quickly found in Exchange 2010 SP2 RU5 when it was released in November. Microsoft pulled RU5 back and the fixed version (now dubbed RU5 V2) was released along with Exchange 2010 SP1 RU8 and Exchange 2007 SP3 RU9 on December 11. The initial feeling of well-being was quickly dispelled when people realized that RU5 V2 includes a security fix, making it a more pressing update to deploy. I think it’s fair to say that the decision to include the security fix in RU5 V2 did not impress the Exchange community. At least, that’s what the comments on the EHLO blog indicates. To be fair to the Exchange Customer Experience (CXP) team who put out updates, their hand might have been forced on the issue by internal Microsoft guidelines that dictate how security fixes are released to customers.
The jury is still out as to whether RU5 V2 is any better than its predecessor. The DAG bug seems to have gone away, which is good, but some have reported installing the update, which isn’t so good. And curiously, KB2748870 has been removed from RU5 V2 and its page taken down from Microsoft’s web site (but is still available in some non-English versions, such as Turkish – experience the joy of automatic translation and see if you can figure out what it’s all about). I don’t like this very much because it creates a nagging question in my mind as to why KB2748870 was in the original RU5. Did Microsoft find another problem with this fix after RU5 was released? Is this another indication of sagging quality standards for Exchange updates?
Clearly there have been quite a few snafus around Exchange updates in the recent past and it’s fair to say that some doubt now exists as to the effectiveness of Microsoft’s regression testing before roll-up updates are released. Testing is a huge problem for complex software packages – just look at what happened to Google last week when a faulty configuration change on one component affected Gmail and caused Chrome browsers to crash. I do have sympathy with Microsoft around the difficulties of testing what has become a very complex product, but even accepting that testing is complex, would you not expect the world’s largest software company to have this down to a fine art? As so aptly observed by one customer who commented on the EHLO blog:
"Microsoft, what is the problem with getting these rollups right? You are seriously sucking lately."
Quite. Not much more can be said about that.
Another issue then cropped up for Exchange administrators when Microsoft Management Framework 3.0 (WMF) made an appearance in WSUS, which meant that WMF became a candidate to be automatically pushed out to servers and then installed by the unwitting administrator on the basis that an update provided by Microsoft must be a very good thing. In fact, WMF 3.0 is exactly the last thing that you would want to apply to anything but an Exchange 2013 server. WMF 3.0 contains PowerShell 3.0 and although Exchange 2007 and Exchange 2010 both make very good use of PowerShell, they emphatically do not support PowerShell 3.0. Exchange 2007 probably never will and Exchange 2010 won’t until Microsoft releases Exchange 2010 SP3 sometime in the New Year.
Installing WMF 3.0 on your non-Exchange 2013 servers is a recipe for a world of hurt at this point, so you have got to ask why Microsoft got into the position where WSUS was allowed to push out WMF 3.0. It would be good if WSUS exhibited some intelligence about how it pushed software to servers that might not be able to cope with the update. For those who want to decline the relevant updates, it seems that you should decline both KB2506146 and KB2506143 (the first is for Windows 2008 SP2, the other for Windows 2008 R2 SP1). These are marked as optional updates, but I bet a lot of people take a Microsoft "optional" label as meaning "you should really apply these updates to your server else eternal damnation will swiftly follow and your server will be consigned to become twisted metal".
Thankfully Microsoft Support got on top of the case quickly and issued firm advice in this EHLO note last Friday, saying "Our guidance at this time is that Windows Management Framework 3.0 should not be deployed on servers running Exchange 2007 or Exchange 2010". Not much more to say really, except to wonder why one side of Microsoft (WSUS) can't talk to another (Exchange), not to mention other product groups that are similarly effected, such as SharePoint. Oh well, if everything was perfect, we should have nothing to complain about and where's the fun in that?
Follow Tony @12Knocksinna
