Some side-effects of the Exchange 2013 cumulative update strategy


Now that we have had a chance to digest the ramifications of the new cumulative update strategy for Exchange 2013 as laid out by Microsoft, it’s a good time to speculate how things will work in a practical sense.

Three points deserve some debate. The first is the cadence for updates. Three months is an eminently sensible period for “the service” (the name Microsoft uses for Office 365). The nature of cloud services and the competitive imperative to stay fresh means that new features “light up” on a frequent basis. I have no problem with Exchange Online and the other Office 365 products being updated every thirteen weeks, but I wonder whether the IT staff responsible for running on-premises Exchange servers will be quite so happy to be forced to maintain the same pace. After all, no other company has the same technical resources as Microsoft, and no other company has invested so heavily in standardization and automation within their datacenters, two of the basic principles that facilitate frequent updates.

Having a new cumulative update delivered every three months is unlikely to be welcomed. Being forced to update because the support policy dictates that only the two most recent updates are covered. The exact text in Microsoft’s statement is “A CU will be supported for a period of three (3) months after the release date of the next CU”. Three plus three equals a short six month period during which you had better deploy if you don’t want to be met with the stock answer of “deploy the current update” anytime you report a problem to Microsoft support.

So that’s two out of three issues that are pressing on my mind. The last is the effect that the new Microsoft-dictated schedule will have on ISVs. Exchange is not an island and few Exchange servers function without some form of non-Microsoft software that helps to keep the show running. Simple stuff like backup software, for instance. System administrators tend to like ISVs to verify their code against shipping software, which means that ISVs can only really begin to validate their products after Microsoft has shipped a new cumulative update. Of course, the magical mystery three-month clock has started at that point and you can bet your bottom dollar (or currency of choice) that it will take ISVs at least a couple of weeks before they make absolutely sure that their code runs well with Exchange 2013 CUx. So now we have maybe ten weeks to deploy, maybe less if one of the ISVs runs into some trouble with an API or other component. In short, it’s a bit of a mess.

The other thing to remember is that no one signed up for a frenetic update schedule when they committed to buy and install Exchange. No one. No customer. No ISV. No partner. No one. Microsoft has taken it upon themselves to impose a schedule that makes perfect sense for their Office 365 service while leaving everyone else gasping on the ground. It must be a new way of generating customer loyalty through exertion. You know… “the more software installs you do, the happier you’ll be with Exchange”.

Don’t get me wrong. There are some good things in Microsoft’s new update strategy such as the ability to deploy the latest CU in a one-time operation to install Exchange rather than having to deploy the latest service pack and then the latest update as happens with Exchange 2010. But the pain caused by the three-month cadence is too much and I think that Microsoft has to figure out a better approach.

No one will object if they continue to light up new features for Exchange Online every three months – but that’s a highly optimized and standardized massively scalable multi-tenant environment that is unique and totally unlike any customer on-premises infrastructure. You cannot fit a square peg into a round hole and you can’t force unnatural update practices onto Exchange administrators. Over to you, Microsoft – come back and tell us when you’ve figured out how to make on-premises customers happy. And by the way, three months should not figure in your new answer.

Follow Tony @12Knocksinna

Advertisement

About Tony Redmond

Lead author for the Office 365 for IT Pros eBook and writer about all aspects of the Office 365 ecosystem.
This entry was posted in Exchange 2013, Office 365 and tagged , , , , . Bookmark the permalink.

23 Responses to Some side-effects of the Exchange 2013 cumulative update strategy

  1. John says:

    Great Article Tony, and Thank You for being a voice for us Hundreds of Thousands worldwide Exchange On-Premises customers that are feeling left out now.

  2. Tom says:

    I agree with John. Thank you Tony for being a voice for Exchange On-Premises customers with your great articles.

  3. Gulab says:

    Good article Tony. I wonder if they will continue with Interm Updates? As we have experienced in past exchange updates. Sometime (well it happened several time in last 2 Q of 2012) that there are issues or some or the other things gets broken when you install UR. Now if the same thing happens with CU’s. I wonder what is Microsoft plan is? I guess people back in Redmond has lost there minds.Forcing customers, clients, partners, vendors to do something like this without taking them into favor is crazy.
    Good job Tony

  4. Patel says:

    Indeed very good article Tony and please continue your support for Exchange On-Premises customers worldwide.
    Thank you.

  5. Dustin says:

    I know that this may seem onerous, and that may very well prove to be the case… however, with the capability to do maintenance without downtime by rolling active database copies and load balancing of client access, this should be feasible without being much of a problem. Patches do occur outside of CU/RU/SP, and they should be considered for deployment and properly tested, so from that perspective, this could actually streamline activities for shops that regularly review and patch systems.

    I find that folks are still overly cautious with new maintenance paradigms that have become available with related technologies (including virtualization and live migration/vMotion).

    This cycle will definitely have an impact and it is a great topic with many considerations. I am particularly concerned with the issues from recent RUs from Exchange 2010 and how this will play out now. Perhaps Microsoft needs to reconsider the support time for older builds.

    Of course, this seems like more ffort to “push” people to the cloud. Increasing on-premise licensing costs and potentially increasing the TCO via labor and that is what you get… a concerted effort to diminish on-premise deployments.

  6. Tom says:

    Any service can go to the public cloud today such as AD, SQL, Oracle, SharePoint, Back-up, SAN ……the list goes on & on. And I think that could be the case with SMBs but many Enterprises still would like to have in-house control over the Mission-Critical service such as Exchange, and all the sales pitch from the Microsoft Rep will not work.

  7. FedUp says:

    It should abundantly clear by now that Microsoft’s goal is to force everyone to their online solution, and to make running their on-premise solution as difficult as possible. They claim ease of support and co-existence as reasons, but really the ease of support is for them and not us.

    In Exchange 2013 they dropped Forefront Protection for Exchange, the much celebrated antivirus multi-engine solution, for no good reason. They also dropped AVAPI so you can no longer scan the database contents in real time, because no one would EVER have something in their mailbox that needed to be scanned outside of the transport mechanism. Now they are forcing you to update the product every 6 months or face lack of support regardless of enviornmental impact, and the CUs could contain schema updates just like a Service Pack, and uninstalling them really aren’t an option.

    If this track record continues, my organization will start looking at other solutions that are more manageable and less costly (and there are other options), because we will not have our arm twisted into going to the cloud nor are we here to make Microsoft’s support mechanism for their online service easier…

    • Gulab says:

      Totally agree with you. MS is trying tooth and nail to force everyone to get on their cloud.

    • Tom says:

      If Microsoft thinks EVERY customer worldwide will move to Exchange on public cloud, Microsoft has bet on the wrong horse.
      And with all the hard work they done by building Exchange On-Premises for the last 15 years, Microsoft will start losing Exchange On-Premises customers one by one to other On-Premises solutions.

    • 365 says:

      sounds like you should be on Exchange Online.

  8. Eric Fleischman says:

    Tony, do you have a proposal?

    • Yes, and I gave it direct to the PG at the recent MVP Summit. Basically I think the cadence is too rapid for most on-premises customers and ISVs, especially with the support requirement to keep servers updated to stay supported. The cadence works really well when you have a standardized, highly automated infrastructure that does not use add-on products, but that’s Office 365 and not typical of a typical on-premises environment. I think that pushing out updates regularly is a good thing as long as customers have some control over how new features “light up” (control via organization settings, not registry hacks too) and software is supported for at least a year after release. More rapid releases are a fact of life now, but their provision has to take account of real-life operational scenarios rather than assuming that every company can consume software updates as quickly as Microsoft can.

      TR

      • Eric Fleischman says:

        I’ll ask again: Do you have a proposal? Put it out there for all to chew on. If you are going to make public the problem, make public your view on how to solve it. Else it is just complaining.

      • I think my views are pretty clear in the previous response (more control over when new features appear, longer support period). Besides, it is not up to me to fix a problem that Microsoft has created. I’ve already expressed myself to the product group, as did many other MVPs. We will just have to wait and see whether they will modify the plan as published.

        As to complaining, I am happy to accept that label. Someone has to complain about a strategy that has the potential to cause problems for customers.

        TR

    • zumarek says:

      Eric

      Perhaps you never really worked in real world where it is important to have stable and fairly inexpensive solutions. Constant change is not something that goes in line with the above.

  9. Jim says:

    I think this is pushing the panic button too early. Did everyone read the section where the update is tested with the Online service first? This should reduce the issues with updates as they are released. The frequency may be a concern, but how many issues are resolved by updates that are not applied?

    • Gulab says:

      Online services is totally different as compare to on-premises environment. One thing I fail to understand is, with 90K+ army of employees, how come MS can’t release any update with full testing. I would say most of there updates for (exchange at least) come up with some of the other issues. Latest was UR5 for SP2 and then they release RU5 v2 still there was issue.
      What we all can do is, keep our finger cross and hope for the best.

      • Eric Fleischman says:

        Gulab, I can answer this for you. There are a couple of major reasons:
        1) Time & engagement constrained: A test pass takes X amt of time but customers want the fix in <X time. What's more, the 'full test pass' you elude to often times requires 3rd parties to participate depending upon the product (TAPs, ISV testing, etc.) and they don't want to test every update.
        2) Opportunity cost: You use the old "MSFT has 90K+ people" as if most of them are kicking around doing nothing. Every thing that is done comes at the cost of something else. The company is not endlessly rich as often thought from the outside. There is an opportunity cost to every decision. THis is true for all assets the company has…money, people, etc.

    • FedUp says:

      @Jim – The online service is hardly a representation of the local on-premise solution. First they don’t have the 3rd party product integration we do, and secondly they don’t support every feature/functionality that the on-premsis versions do. Just for example they still don’t support Public Folders: http://blogs.technet.com/b/lystavlen/archive/2012/03/06/public-folders-in-office-365.aspx

      So deploying updates to a more limited and less integrated version of their On-Premises product hardly makes the update vetted for the rest of us.

  10. Tom says:

    Microsoft needs to pay more attention to Exchange On-Premises customers worldwide regarding testing updates before sending updates to us. I hope Microsoft will start paying more attention to Exchange On-Premises customers from now on because that is where most of customers worldwide are and Will be for Enterprises. Bottom lines listen to us or lose us.

  11. Gulab says:

    Here is another reason why CU’s wouldn’t be right idea (until or unless fully tested)
    http://support.microsoft.com/kb/2822208/en-us

    • Andrew Mazurek says:

      Switch to something else … otherwise get used to “Microsoft made it this way and you will like it” – the only way this will get fixed if we direct our $$$s somewhere else. There is still time.

  12. Andrew Mazurek says:

    Tony
    I disagree with “You cannot fit a square peg into a round hole” – yes you can, now results of such a fitting are less than desirable, but this is what Microsoft seems to be doing. Hopefully they will apply some sense as they did with Windows 8 (reverse – Blue).

Leave a Reply to 365 Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.