My June 7 post exploring the thought that Exchange 2010 SP2 RU3 was a roll-up update (RU) with some of the characteristics of a full-blown service pack (because it includes some interesting functionality enhancements in addition to the normal collection of bug fixes) provoked some further thinking about the influence that cloud-based systems have on their on-premises counterparts.
One response I received from a member of the Exchange development team pointed me to the post by Rajesh Jha (corporate Vice President for Exchange) on the EHLO blog that describes Microsoft’s development cadence for Exchange Online, the version that runs as part of . I already reviewed that post last October and concluded that companies that switch to a cloud platform have to revise their expectation about the rate of change of software and factor this into their deployment plans.
Then I read an article that examined how Microsoft can keep Windows 8 “fresh” after it is released by Hal Berenson, who was a Distinguished Engineer and General Manager at Microsoft before he retired. Not only was the article interesting because of the insight it provided into the evolution of the desktop version of Windows over the years, it provoked further thought about the increasing pace of software development and concluded that, with Windows 8, Microsoft has to balance the need to refresh its O/S to keep it competitive while also providing a stable platform that can be easily deployed and supported within large corporations. Berenson said that he thinks that Microsoft should release service pack updates for Windows every six months as “frequent small updates are too disruptive”.
Moving back to Exchange, here are some data points to summarize the current situation:
With the greatest of respect to SharePoint Online and Lync Online, there’s little doubt that email is the easiest application to move to a cloud platform and is the fastest to achieve a return on investment after the move. As such, there’s lots of pressure to keep Exchange Online moving forward. And although there’s lots of work for the developers to do to improve aspects such as automation and manageability for Office 365, they also work on new features and the result of the work trickles through to the on-premises server, which might be contributing to the sort of creeping change seen in Exchange 2010 SP2 RU3.
The prospects of having to understand, test, and deploy an evolving server every six weeks or so are unattractive to many administrators. Taking the arguments advanced by Berenson, software stability is important to administrators as it facilitates better planning and (usually) a better operational experience. With this in mind, deploying every RU soon after Microsoft releases the update might not be the best approach. I think it’s important to review the list of fixes contained in each RU to check whether any of the fixes is important to your deployment and install the RU if such a fix is found. But apart from that, a pragmatist might decide to install every third RU on the basis that eighteen to twenty weeks is a reasonable period to run a particular software version that also gives sufficient time for the planning and deployment process to be managed efficiently with the framework of normal software release cycles. RUs are cumulative so installing the latest update means that a server is brought completely up to date.
Microsoft used to be criticized because they didn’t fix software quickly enough. The interesting thing about the current situation is that Microsoft could be construed to be pushing out updates so fast that it’s difficult for some customers to deal with them. I guess it’s the pace of the new, improved, cloud-centric world that we have to figure out how best to harness. It’s a strange old world at times.
Follow Tony @12Knocksinna