How Office Updates - The Basics
Our Update Strategy Today
Before we get into the considerations of release cadence and Service Compatibility, it is probably good to start at the beginning. I find these posts are always useful as a digest to initiate the new users, and to refresh those who haven't visited this subject in a while. A myth defrag is usually in order. In this post, I'll break down some of the fundamentals of our update strategy, including what we ship, where, to whom. Beyond explaining the basics, I'll get into some of the lesser known aspects of updating the clients. All of what I am describing applies equally to our MSI-based installations as well as Click 2 Run. We'll get into the practical differences between MSI and C2R in a future post.
Gratuitous image as a vague temporal marker.
Our Support Policy
Office client updates are distributed on a regular basis to improve the quality of our products. Updates generally fall into a basic category: Security, Customer-requested hotfix, or just a plan "change." In the past, virtually all fixes for Office in-market products were a direct result of customer escalations. That is less true today with the increase of telemetry sources, our alignment to Office 365 and other factors. Over time we have moved from more of the cause / effect or direct engagement model to one where we are better at anticipating customer challenges and resolving them before they become actual problems. The most obvious example is our work with security agencies to address vulnerabilities before they become public, or looking at installation failure rates for a given update before their broad-scale release.
The most important factor in determining which products we update and with what changes is best outlined in the Microsoft Product Support Lifecycle. You can read the details beneath the link, but generally:
Our current releases of Office benefit from a 10-year product lifecycle. In other words, we will be publishing updates for our existing releases until 10 years after their initial availability. The dates for Office product support can be found here. As you will see from the site, Office 2000 and Office XP are no longer supported. We are no longer issuing updates for those products. Office 2003 is set to expire next year, along with Windows XP. You will also observe that Office 2013 is supported until October of 2023.
The first 5 years of product release are for hotfix release, service packs and security / critical changes. In this initial 60-month period, we respond to Microsoft Premier Customer requests for hotfixes, we respond to other requests, for example, from our consumer support teams or from other product groups seeking changes to improve compatibility across our product lines. We call this phase "Mainstream Support."
In mainstream support, we have historically offered 3 service packs during the 60-month mainstream support window. Service Packs are important milestones in deployment - they are a roll-up of all fixes to date, and they reset the support baseline for a given release. For example, the recently released Office 2010 Service Pack 2 is the current baseline for the 2010 release. Per the terms of the Office Service Pack Support Lifecycle, the prior baseline will expire from support 12 months from this release date, giving customers a full year to deploy the release.
The second 5-year period of support is termed "Extended Support" and we offer only security, critical and compatibility changes for products that are in this phase. Office 2003 and Office 2007 are both in their extended support phase, and if you take a look at Microsoft Update for Office 2003, for example, you'd see that the only available updates are marked as either security or critical.
Our Release Cadence is Designed to be Predictable and Transparent
Public Updates ship on "Patch Tuesday," or the 2nd Tuesday of each month. They contain Security Updates, Critical Updates and Global Updates. These are provided to everyone and designed to be installed by every user. These are offered to users via Microsoft Update, and WSUS Catalogs, and as Click 2 Run images.
Cumulative Updates ship on the 2nd Tuesday of even numbered months. (Feb, April, June, Aug, Oct, Dec). These are generally unadvertised, because they are releases of hotfixes requested by our Microsoft Premier customers. These are delivered to the hotfix server, and require an email address to download. For Click 2 Run customers, an image containing these updates is available, but the changes are not automatically downloaded until the next public update. More on how PU and CU relate to each other later.
Service Packs ship on the 4th Tuesday of the month. We tend to ship them once per 18 months, although there is no pre-determined schedule for those releases. The purpose of a Service Pack is to reset the support baseline, so that we can keep customers current and offer them the best support possible. Service Packs are published to Microsoft Update, the Download Center and in WSUS Catalogs.
Determining the Contents of a Release
The contents of a release can be determined by an examination of the associated KB Articles, which detail the affected packages or changes we're delivering. We keep a handy blog here, and we maintain an Update Center on TechNet, which has a handy feed to which you may subscribe. We also publish content to known channels like the Security Bulletin center on TechNet and other places.
Office Updates are Always Cumulative
This aspect of our strategy is not well understood, but has been true for a long time. All Office updates are cumulative. Every change or update installation contains all changes to date for that component. For example, a Security Update for Word contains all changes to date for Word, which includes all prior security fixes, hotfixes, bug fixes and other changes. What we don't do is create separate versions for specific updates or release channels - there isn't a "Public Update only" version of Word or a "Hotfix only" version. All changes are cumulative.
For Click 2 Run, this makes things very simple. Each time a new image is delivered to you, you have all changes to Office that have been released. Because those images currently ship on Patch Tuesday, you are getting the most current version of Office on a 30-day cadence.
For MSI installations, the problem is somewhat more nuanced, but the end effect is the same. If you install all MSI packages, you will be current on all changes for those packages. For example the Outlook.MSP package delivered in a PU release will contain all changes to date for the files in that package. By design, these packages interoperate with the existing support baseline, corresponding to a released service pack level. In other words, Office 2010 changes apply to the new SP2 baseline, and they will apply to the SP1 baseline for one year after the release of SP2. After this 12-month period expires, those updates will no longer target the SP1 baseline.
This detail is destructive to the myth we frequently encounter related to Service Pack testing. Because Service Packs are roll-ups of existing fixes plus some additional change, customers current on Public Updates have already installed the bulk of changes in a given Service Pack. The binary versions are sometimes updated and there are incremental changes, but these are generally of the variety of changes that don't meet the bar for a customer release - e.g., too small. I covered this a while back in a blog post on my team's site.
#1 FAQ - What's the Best Way to Stay Current?
I'm asked this question a lot. The answer is pretty simple -- Use Automatic Updates.
If you are a Click 2 Run customer (e.g. you are a user of the Office365 product, or you bought Office 2013 in a retail outlet) keep updates turned on. The image updates on Patch Tuesday will be streamed to you when they are available. This is a very low-maintenance approach to getting current.
To enable automatic updates for Click 2 Run products like Office365 or Office retail products, visit the "Account" Tab under the file menu.
For MSI customers, use Microsoft Update to take automatic updates. You won't update as much as we change in any given Click 2 Run update, but you will accumulate all changes to relevant parts of Office over time.
For managed deployments, I'd encourage you to examine your desktop updates policy closely, to determine whether it is appropriate to take updates through Microsoft Updates. In most cases it is perfectly appropriate (better), and in those cases C2R versions of Office are worth considering because they make the update process so much easier. We will continue to invest heavily in C2R technology moving forward.
Of course all the fine-grained control of MSI installations remains available. This is appropriate in many environments, and we will continue to support this customer need.
In my next post I'll dive into some of the practical differences between MSI and Click 2 Run technologies, and explain the implications for managing desktops.
Comments
Anonymous
January 01, 2003
Hi Ed, Yes, that would certainly help explain things, but in the CU case (remember these are gated behind an email address on the hotfix server) customers are often looking for a specific change and may not need or want to take subsequent changes. More importantly, however, is the prohibitive nature of continually updating legacy KB articles with a newly published KB#. This is something we are asked from time to time and we're looking at ways to address this change. On Click 2 Run we actually use a static KB number that we refresh each time we ship. For various reasons this is harder with MSI, but something we're looking at fixing. Thank you for the feedback.Anonymous
August 08, 2013
OK. From the section "Office Updates are Always Cumulative", wouldn't the KB for cumulative updates [and others] mention that the new CU replaces an old CU?