A while back, we provided some information about the upcoming release of Office 2010 Service Pack 1 (SP1.) This release is important because it is our first update to the 2010 product family that changes the support baseline. In this post we'll describe some Service Pack and Support Policy basics, and provide some background to better understand how Service Packs are managed. This will help you think through some of the implications for deploying Office & Windows together, especially if you are considering Windows 7 SP1.
Decoding the Service Pack Release Schedule for Office and SharePoint
This page has a complete description of our support policy, and that’s a great place for us to start the discussion. Our releases have two phases of support: a 5 year Mainstream Support lifecycle, and an additional 5-year period of Extended Support. The difference between the two is in the types of changes we offer.
During the Mainstream Support phase we address many things, including critical and security issues, feedback on design issues, and escalations related to specific functionality. In the Extended Support phase we update products to address security issues and other problems of a critical nature. For Office 2010 and SharePoint 2010 products, Mainstream Support ends in 2015, and Extended Support concludes in 2020. This page includes a list of prior versions of our products.
We offer updates through as few primary channels. Public Updates, offered on Microsoft Update, are published once per month, on the second Tuesday (also known as "Patch Tuesday.) Every 8th week, we also roll up our quick fixes and customer escalations into a release we term "Cumulative Update." On periodic intervals during the Mainstream Support phase, we roll these releases and a set of additional fixes into a single delivery referred to as a Service Pack.
Service Packs are a convenience to customers; they include all fixes-to-date for a given set of products in a single installation. We typically (not always) ship 3 Service Packs for a major version of Office and SharePoint. For example, during its 5-year mainstream support window, we offered SP1, SP2 and SP3 for Office 2003.
You can do some basic math to get a sense for the window in which a Service Pack will be timed. In a 60-month Mainstream support window, we typically like to have 3 service packs. By simple math, you'd figure on one SP release per major version every 20 months. This isn't precise, in truth we don't have a pre-determined SP schedule, and we also must time those releases around other activities that are happening in our division. It is never likely to be a 20-month interval (in fact, it probably has never been a perfect 20 months.) But it is usually not far from that.
We are often asked for early disclosure on our Service Pack plans. The request is reasonable, customers carefully plan deployment cycles. In turn, we are careful about disclosing dates prematurely because of the number of variables that may alter the schedule or contents late in the cycle. Early disclosure of the schedule presents a risk to our customers when we commit to schedules long in advance. Admittedly there is a tension that must be managed here. We do our best to optimize for predictability and accuracy in our disclosure. Our goal is to allow customers to have a high degree of confidence in release dates.
Understanding the Service Pack Lifecycle and Support Policy
A key factor in planning for the deployment planning is our Service Pack Support Policy. Nested within the 5/5 support lifecycle for a major version is the policy for supporting updates.
12 months after we ship a service pack, we discontinue support for the old one. In other words, 12 months after the release of Service Pack 1, we will no longer produce fixes that target the original release of Office or SharePoint. 12 months after Office or SharePoint 2010 Service Pack 2 is available, we no longer produce fixes that target Service Pack 1. (Note that Windows is different, they operate the same policy, but with a 24-month window). The 12-month window gives our customers a full year to test and deploy a Service Pack before the prior baseline exits support.
Consolidating code bases to a new, required baseline ensures that when our customers are ready, they will get the latest updates to Office, and we will be able to maintain a high level of quality by making changes to a more current code base. This is an exercise that benefits our customers as well as ourselves, and it helps ensure the quality of our products improve over time.
Predicting the Contents of a Service Pack Release
This is one of the trickier topics about discussing SP's. Folks want to know well in advance what will be included. Their reasons are legitimate, knowing which of "your" issues are being addressed, or knowing what changes to test can provide insight that reduces a lot of concern. From our perspective, it is often difficult to predict the contents of Service Packs for fear of having to pull a fix out at the last minute. We'd rather sit on the list until we're 100% confident that the change will be included in the SP. Unfortunately there isn't an easy answer to the problem, other than to say that we do our best to balance customer needs for early disclosure vs. not over-promising the release.
Fortunately there is an easy way to compile the vast majority of the SP change list well before its availability, without any help from Microsoft. Service Packs include a roll-up of all fixes released against a baseline to the current state of the code. In other words, all the Cumulative Updates and Public Updates that have already shipped will be included in the release. We publish significant detail about those CU and PU releases when they happen. A portion of the change list for our upcoming SP1 release, then, has already been published (along with the corresponding updates, of course).
Granted, for SP1 we are also addressing a number of other areas that have not yet been released, and we will share additional details about those as the release draws near.
Automatic Updates and Service Packs
Many organizations like to test Service Packs before deploying them to each user. They prefer a window for testing a Service Pack before we push it via Automatic Updates. Consumers or non-IT managed desktops, however, have less of a need to wait for a Service Pack. They can install a service pack earlier and start taking advantages of the fixes in the release.
When we ship a Service Pack, we do not offer it as an Automatic Update right away. We wait a minimum of 90 days before we offer the SP as an Automatic Update. We also provide a 30-day notice before doing so. For SP1, the 30-day notice will take place on this blog.
For all that we do in a Service Pack release, the objective is to provide a current set of updates to our customers to ensure they have the best experience possible with the software. We want to ensure the quality of our products improve over time. We hope this helps clarify some of the details around service packs, and we'll post more on our release types in the future.
In the meantime, you can follow us on Twitter @OfficeUpdates
![]()
