MICROSOFT SUPPORT LIFECYCLE BLOG : Policies

MS08-067 and Unsupported Products

Jared Proudfoot — Sat, 25 Oct 2008 03:55:00 GMT

Before we spend some time talking about the Extended Hotfix Support program for DST, I thought it would be a good idea to address a number of questions we have recently received regarding the release of MS08-067. Most of the questions that we have received have been regarding older, unsupported products and services packs. We’ve received questions regarding Windows 95, Windows NT 3.51, Windows NT 4.0, Windows XP SP1 and Windows 2000 SP3, just to name a few.

Under the Support Lifecycle policy, once a product reaches the end of support we no longer provide any support for that product. What does that mean? Basically, this means we stop providing any new information or assisted support for the product. After the end of support, we leave the knowledgebase information online for a minimum of 12 months. We do not provide security updates, any assisted support (telephone support), nor assistance through Premier or Professional support, etc…

From a security point of view, running an unsupported version should be considered a significant security risk in itself. Since Microsoft does not produce security updates or provide any type of assisted support for unsupported versions, customers are taking a significant risk by running these versions within their environment. If you encounter any types of issues with an unsupported product, there are no Microsoft resources available to help.

Remember, to continue to receive support and security updates, you must be running on a supported product and on a supported service pack version. More information on this can also be found on our website at http://support.microsoft.com/lifecycle/.

Thanks for your continued questions and comments. We’ll get back to the DST discussion within the next week or so.

*This posting is provided "AS IS" with no warranties, and confers no rights.*

What is Extended Hotfix Support?

Jared Proudfoot — Sat, 12 Apr 2008 04:25:00 GMT

As I mentioned in an earlier posting, during the Extended Support phase we no longer provide non-security hotfixes without enrollment in the Extended Hotfix Support program. Simply put, the Extended Hotfix Support program provides the ability to request non-security hotfixes for products that are in the Extended Support phase.

Remember, Extended Hotfix Support (EHS) only provides the opportunity to request a non-security hotfix for a new bug discovered during the Extended Support phase. It has no impact on a customer’s ability to request support, security updates, or other non-security hotfixes created during the Mainstream Support phase.

To enroll in EHS, customers must already have Premier Support. In addition, enrollment in the program must occur within the first 90 days of the product entering the Extended Support phase. If the customer misses this deadline, there may not be an opportunity to enroll in EHS again.

The only exception to the 90 day enrollment rule is for customers with Software Assurance (SA). Customers with Software Assurance on select products are eligible for a benefit which includes the program fee for Extended Hotfix Support and allows enrollment at any time. Essentially, this means that the SA customers only need to sign the appropriate paperwork and pay the per hotfix fee. The products that are included in this benefit are: Microsoft Office Professional, Microsoft Windows Client, Microsoft Exchange Server, Microsoft Operations Manager (MOM), Microsoft SQL Server, Microsoft Systems Management Server (SMS), and Microsoft Windows Server.

Pricing for Extended Hotfix Support consists of an annual program fee, plus an additional fee for each non-security hotfix they receive. Non-security hotfixes produced during the Extended Support phase will not be made available to other customers in the program, without enrollment in EHS or the per hotfix fee. This is to ensure that all customers are treated equal and are being charged the same fees for each hotfix.

Whew… That’s a lot of stuff to cover. I hope it makes the program easier to understand, though. :)

*This posting is provided "AS IS" with no warranties, and confers no rights.*

Why do we end support on the second Tuesday at the end of a quarter?

Jared Proudfoot — Fri, 04 Apr 2008 23:33:00 GMT

Until January 2006, support for products used to expire on the anniversary date of their general availability. This meant that if a product was released on December 1, then it would also expire on December 1st - 5 or 10 years later. We received a lot of feedback from customers that this was not only inconsistent and hard to track, but also very hard to manage. In some cases, we might have 6 or 7 products all expiring on different days in the same month!

In January 2006, we announced a modification to the product expiration policy to address this issue. Now, all product expiration dates are rounded forward to expire on the second Tuesday after the end of the quarter. This means that if we previously had multiple products that would expire in December, with the new policy the new expiration dates would be rounded forward to the second Tuesday in January -- all expiring on the same day. Under this policy, products would only expire four times a year. This is much more predictable for customers and helps ease the management burden of tracking product expiration dates.

You may notice that this timeline also coincides with the second Tuesday security update release cycle. In the event Microsoft releases a security update on the same day that a product is scheduled to end its support lifecycle, support of the security update will continue for a minimum of 30 days.

We’ve received a lot of positive feedback on this change, since it helps makes the product expiration dates easier to understand and manage. What do you think? Does it make it make product expiration more predictable in your environment?

*This posting is provided "AS IS" with no warranties, and confers no rights.*

What’s up with Service Pack support?

Jared Proudfoot — Fri, 21 Mar 2008 19:51:00 GMT

The Service Pack Support policy is sometimes misunderstood by our customers. As I mentioned on some of the previous postings, support in the Mainstream Support and Extended Support phases is only provided at the supported service pack level. This means that you must be running a supported service pack to continue to receive security updates or be eligible for any of our other support options (such as Premier, Pro or Pay Per Incident cases).

When a new service pack is released, Microsoft will provide either 12 or 24 months of support for the previous service pack, varying by product family. We no longer make the decision of 12 or 24 months of support for each individual service pack release. Instead, this decision is made at the product family level (for example, Windows, Office, Servers, or Developer tools) and will be consistent across a product’s service pack releases.

Of course, when support for a product ends, support for the product’s service packs will also end. The product’s Support Lifecycle supersedes the Service Pack Support policy, to ensure that we don’t provide support for a service pack when the parent product is no longer supported.

Let’s try an example... When Windows XP SP2 was released in September 2004, it started the end of support clock for Windows XP SP1. For the Windows product family, we provide 24 months of support for the previous service pack. Therefore, support for Windows XP SP1 ended 24 months following the release of SP2 -- on October 10, 2006. When Windows XP SP3 is released, it will begin the end of support clock for SP2 -- ending 24 months following the release of SP3.

Here's another example, this time using Office 2003. When Office 2003 SP3 was released in September 2007, it started the end of support clock for Office 2003 SP2. Since the Office family provides 12 months of support for the previous service pack, support for Office 2003 SP2 will end on October 14, 2008. Support for Office 2003 SP3 will continue until 12 months following the release of SP4 or support for the product ends.

You may notice that we don't end support for products or service packs on the same date they were released. Instead, we round the end dates to the second Tuesday after the end of the quarter. We'll discuss this in a future posting.

In the meantime, please tell us what you think! Does this better explain the Service Pack Support policy? What can we do better to explain this on our main site?

*This posting is provided "AS IS" with no warranties, and confers no rights.*

An explanation of the Extended Support phase for Business & Developer products

Jared Proudfoot — Mon, 17 Mar 2008 23:04:00 GMT

Extended Support is the second phase of the Support Lifecycle for Business & Developer products. The key differences between the Mainstream Support phase and Extended Support phase are that the “no-charge” support options are no longer available and that we no longer provide new non-security hotfixes. This means that customers will need to open paid support cases (such as Premier, Pro or Pay Per Incident cases) to obtain support for their product. For those customers who require new non-security hotfixes during the Extended Support phase, a special program called Extended Hotfix Support (EHS) is available. I’ll save the detailed discussion about EHS for another posting.

One of the important things to note is that Extended Support is still a publicly supported phase. Many Premier and Pro customers who already open paid cases with Microsoft will notice little difference in the support that is provided in this phase. They will continue to be able to open paid cases, receive security updates, obtain support assistance from their Technical Account Manager, etc… In reality, few customers need Extended Hotfix Support unless they have a history of requesting or requiring non-security hotfixes.

Like the Mainstream Support phase, it is important to note that support is only provided at a supported service pack level.

The Extended Support phase is provided for a minimum of 5 years or 2 years after the second successor product is released, whichever is longer. This means that the Extended Support phase may be extended to longer than 5 years, if the second follow-on product release is delayed. The basic reasoning behind this policy is that we don’t want to completely end support for a product unless there are 2 newer versions of the product for customers to migrate to.

At the end of the Extended Support phase, Business & Developer products are no longer publicly supported. This means that there is no more paid support, no support assistance and no further security updates. Customers are highly encouraged to move a supported product as soon as possible.

Please tell us what you think! Does this better explain the Extended Support phase? What can we do better to explain this on our main site?

*This posting is provided "AS IS" with no warranties, and confers no rights.*

An explanation of the Mainstream Support phase

Jared Proudfoot — Fri, 07 Mar 2008 21:39:00 GMT

I’d like to write a little about the Mainstream Support phase. I think Mainstream Support is probably the best understood phase, but I want to ensure that we discuss this foundational piece before getting into some of the specific policies and offerings.

For all products, the Microsoft Support Lifecycle policy begins with the Mainstream Support phase. In this phase, we are able to provide all of the standard support services that Microsoft offers. For example, in-the-box support, paid incident support, design change requests, non-security hotfixes, security updates and online self-help support may all be available during the Mainstream Support phase.

Consumer products that are released annually are provided a total of 3 years of Mainstream Support. Some examples of these are Microsoft Money, Encarta, Streets & Trips, etc.

For the rest of Consumer, Hardware and Business & Developer products, the Mainstream Support phase is provided for a minimum of 5 years or 2 years after the successor product is released, whichever is longer. This means that the Mainstream Support phase may be extended to longer than 5 years, if the follow-on product release is delayed. A good example of this might be Windows XP. With the updated release date of Windows Vista, Microsoft provided additional Mainstream Support for Windows XP. Mainstream Support for Windows XP will now end approximately 2 years following the release of Windows Vista. The basic reasoning behind this policy is that we don’t want to move a product into Extended Support if there is no newer product to migrate to.

One other important thing to note is that support is only provided at a supported service pack level. We’ll discuss more about this policy in a future posting.

At the end of the Mainstream Support phase, support for Consumer products comes to an end. Business & Developer products, on the other hand, are provided a minimum of another 5 years of support in the Extended Support phase.

Next time, we’ll talk about the Extended Support phase. Please feel free to leave questions or suggestions or future postings!

*This posting is provided "AS IS" with no warranties, and confers no rights.*

History of the Microsoft Support Lifecycle policy

Jared Proudfoot — Fri, 29 Feb 2008 08:19:00 GMT

I wanted to start off the blog with a posting about the history of the Microsoft Support Lifecycle policy. We often get questions about the history of the policy, how it came about and how long it’s actually been in place.

Prior to 2002, Microsoft did not have a centralized team or set of policies to govern the length of support provided for each product or the level of service provided throughout a product’s supported life. Instead, each of the product groups (PGs) was independently responsible for defining the length and terms of support for their individual products. The PGs managed their own support groups, published information regarding their support policies and communicated directly with the customers regarding the supportability of their products.

While this allowed the PGs significant flexibility to support their products according to their business needs, the situation was not ideal for Microsoft customers. Customers often complained that it was difficult to understand how long products were supported and that there was little consistency in the support levels, communication approaches and support availability between PGs. The approach to these policies often differed between the PGs and sometimes even differed between products within the same PG. In addition, these inconsistencies made it difficult for customers to plan their information technology IT upgrade cycles and future product purchases.

By the beginning of 2001 the majority of the PGs had committed to providing support for both the current version and the previous version of their product. Unfortunately, the length of support and services provided still differed between most products. In addition, there were inconsistent requirements for the application of product service packs. Some PGs always required a products current service pack to be applied, while other PGs had a more liberal policy regarding service pack support.

As a result of continued customer feedback, Microsoft Services chartered a team with the responsibility of creating a unified set of support policies that could be applied all Microsoft products. The goal was to create a comprehensive support policy that customers could easily understand, reference and plan for. As a result, in October 2002 Microsoft unveiled the first version of the Microsoft Support Lifecycle. This original version of the policy provided 5 years of Mainstream Support for Consumer products and 5 years of Mainstream Support and 2 years of Extended Support for Business & Developer products.

In 2004, Microsoft announced a major revision to the Microsoft Support Lifecycle. Among the changes announced were expanded lengths of support for Microsoft’s Business & Developer products, clarifications on some of the existing policies, and additional support options for customers who needed support for products that were no longer publicly supported. While there have been some clarifications and minor changes over the years, this is still the same policy that we use today.

Next time, I’d like to get into more details about some of the specific policies and perhaps clear-up some common confusion and misconceptions. In the meantime, please feel free to ask any questions or leave ideas for future postings.

*This posting is provided "AS IS" with no warranties, and confers no rights.*