Integrating Microsoft Product Lifecycle and Support Policies into IT Operations

“We need consistency and predictability, and a sense of proper placement. We need these things before we can mold the world into what we know it can be.”

– Allan Dare Pearce – lawyer, author

Whenever I assist customers with deploying new SQL Server infrastructures or upgrading existing ones, the one thing that I try to consider is where they are at the moment and where they want to go. This is to make sure that their IT investments are there to support their business objectives and not just appear as cost figures on the balanced sheet. The most common recommendation I make is to “upgrade to the latest version.

Now, don’t get me wrong. It’s not that I get commissions out of selling the latest version of Windows and SQL Server. After all, I myself am still trying to figure out what the real deal is as far as licensing is concerned (I always sum up my recommendation with the phrase “talk to your local Microsoft technical account manager (TAM) to be very sure.”) I’m the type of person who would recommend keeping your costs low as much as you can without sacrificing the important things. The reason I make such recommendation is because I consider the total cost of ownership. And by total, I mean TOTAL. This includes not just the initial cost of buying licenses and hardware but the costs involved in monitoring, supporting, upgrade/migration, high availability, disaster recovery, IT staff training, hardware refresh, etc. The list goes on and on but it definitely varies depending on what the business goals are.

I also look at what the latest version of a Microsoft product is and whether or not a customer is more than two (2) versions behind. For example, at the time of writing, the latest version of SQL Server is version 2014 while the latest version of Windows Server is 2012 R2. If a customer is still on Windows Server 2003 and SQL Server 2005, there is no doubt that I will recommend upgrading to the latest version of both the database and the operating system. Small to medium sized organizations tend to respond faster to upgrade and migration projects than large ones so timing is also important.

Upgrade and migration projects form part of IT operations whether you are running your infrastructure on-premise or on the cloud. So, there is no doubt that you as an IT professional will have to work thru this in your career. That’s why it is important to know the specific support lifecycle of a Microsoft product that you are working with. I’ll use both Windows Server and SQL Server in this blog post to guide you thru how to integrate those information into your IT operations.

  1. Identify the version, edition and build number of the Microsoft product that you are working with. If you are working with Windows Server, find out what version you are running at in your production environment. Is it Windows Server 2003 RTM? Windows Server 2003 R2? Does it have Service Pack 2? Is it 32-bit or 64-bit? The simplest way to find out is to run msinfo32 on your machine. Don’t be confused with the command and the other Microsoft KB articles that describes it. It runs just fine on my Windows Server 2012 R2 x64 machine. And if you are working with SQL Server, you can use the query below to find out these information. You can also refer to this Microsoft KB article for a more comprehensive way to determine the version and edition of SQL Server that you are running. I just use the query below for simplicity’s sake.SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
  2. Search for the product in the Microsoft Support Lifecycle page. Once you’ve identified the version and edition of the product that you’re working with, it’s time to check whether or not you are still supported. This might be a bit scary if you understand what it really means. You can check for the product support lifecycle by using this Microsoft Support Lifecycle webpage. Type the name of the product information that you got from the previous step. For example, let’s say you are working with SQL Server 2005. You can simply type that in the Product Name text box and click the Search button. This will display all of the support lifecycle information pertaining to that product. You can actually use this for almost all of the Microsoft products available in the market.SupportLifeCycle
  3. Identify the product support lifecycle. When you get the results from the search, look for the edition or the service pack information that you got from step #1. Look at the Extended Support End Date column and see if you are still under support. I consider this the latest deadline that your product is considered to be supported. The difference between mainstream support and extended support is sometimes confusing from an operations point of view so I’ve provided a table containing the difference between the two.SupportLifeCycle2What this simply means is that if the product that you are running has gone past the Extended Support End Date, you are on your own. I’ve had a previous customer in 2010 who was still running on SQL Server 6.5 and the only thing I could promise is a “best effort” assistance that is both expensive and cumbersome. Your goal is not to go past the Extended Support End Date. That means, if you are still running SQL Server 2005, you have less than a year – 12-Apr-2016 – before you are left on your own to keep those databases in good working condition.
  4. Plan your next steps based on the product support lifecycle. Since this blog post is all about how to integrate your products’ lifecycle and support policies into your IT operations, you need to make a decision based on your findings and your business objectives. For example, if you are still on SQL Server 2008 (not R2) with Service Pack 1, you need to plan on installing SQL Server 2008 Service Pack 4 to be in a supported state (you can install SQL Server 2008 Service Pack 3 but it can only take you so far.) This means planning on testing your applications, scheduling system downtime and having a rollback strategy as part of the process. This is not as simple as downloading the service pack and installing it. If you are still on SQL Server 2000, now is the time to start an upgrade/migration project. The biggest challenge that customers face when trying to keep their systems in a supported state is when it is now considered mission-critical. This means keeping the system highly available (or minimizing downtime) for the business to use when installing service packs or upgrading/migrating to a newer version. This is where all the efforts in planning and preparation should be invested.

Knowing whether your systems are supported or not is just the beginning. Keeping them supported is a continuous process. That’s why regularly checking the Microsoft Product Support Lifecycle page should be a part of IT operations together with regular monitoring and maintenance. This doesn’t just apply to your servers, it also applies to end-user products as well such as Microsoft Word and LiveMeeting client.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published.