Dan's Blog

I am Principal Program Manager at Microsoft leading the Business Platform Division's (BPD) community team. BPD includes SQL Server, SQL Azure, BizTalk, AppFabric, and other technologies and services.

SQL Server Code Name “Denali” – Supported OSes and Upgrade Paths

SQL Server Code Name “Denali” – Supported OSes and Upgrade Paths

Rate This
  • Comments 45

We are looking for feedback on three items for SQL Server Code Name “Denali”. First, are the supported OSes. Second, are the supported upgrade paths. Third, is the way the installer handles unsupported OSes and upgrade paths. Specifically we want to know if these will slow down your adoption of SQL Server Code Name “Denali”.

1) The current support matrix for OSes is as follows:

  • Windows Vista SP2 or later
  • Windows Server 2008 SP2 or later
  • Windows Server 2008 R2 SP1 or later
  • Windows 7 SP1 or later

2) Denali will support upgrading from these SQL Server versions:

  • SQL Server 2005 SP4 or later
  • SQL Server 2008 SP2 or later
  • SQL Server 2008 R2 SP1 or later

3) The installer is going to block installation on unsupported OSes and it will block unsupported upgrade paths.

If the current support matrix for OSes, the current support matrix for upgrade, or the installation blocks will delay your adoption of of SQL Server called “Denali”, please provide this feedback to us! You can provide us this feedback by adding a comment below or submitting the feedback through the SQL Server Connect.

Leave a Comment
  • Please add 2 and 4 and type the answer here:
  • Post
  • Support for Windows XP is really important for future versions of SQL Server because of the fact that there are many many many native applications (to quote shipping apps from Fedex or UPS) that make good use of SQL Server Express that hosts a small to medium replicated databases combined with .NET/non-.NET applications to accomplish order fulfilments/other critical business processes. On the other hand I believe OS support matrix should look same for .NET framework (the minimum version which is utilized by SQL Server "Denali") and the SQL Server version itself.

  • +1 for no-XP OS support. It's time to move on...(typing on a XP Core i7 laptop here). Although I dislike the SP1/SP2 requirement on Win7/2008/2008R2

    -1 for SQL Upgrade though. I second others in that we should allow upgrade from

    SQL 2005 SP2+, and ANY SQL 2008/2008R2 version

  • Does the "current support matrix for OSes" mean no support for the install of the tools like ssms and bids aswell for OS's like xp?  If so then my company would definately have a problem with it.  We have started the migration toward win7 but it will be years before it is complete.

  • I use XP. I vote for having Denali work on XP.

  • I posted my comments here. In short: good riddance to XP. You are really in a situation where you have 10,000 XP desktops that you won't budge on, *and* you are moving to Denali immediately? Of those, how many need to run SQL Server or Management Studio, honestly (and can't upgrade to Windows 7 individually)? And of those, how many aren't allowed (or can't figure out how) to install a virtual machine? If any, can't they use RDP / PowerShell in the meantime to manage all of those Denali instances you're going to have in production on the day it is released? Lots of workarounds to beat the excuse of clinging to a 10-year old operating system.

    For Santosh who talks about shipped applications from ISVs. Why on earth would you need to upgrade such an app from its current Express version to Denali?

  • Forgot the URL:


  • I agree almost 100% with Aaron.

    I would love to see upgrade paths from especially all SQL 2008 and 2008 R2 SP levels though.

    So much harder to do??

  • Dan,

    If you have to restrict at a service pack level for SQL 2005 then SP3 is still under support (Tomorrows patch mentions SP3) as is SQL2008 SP1 and SQL2008R2 SP1 doesn't exist yet. Restricting the upgrades to service pack levels could mean a double upgrade effort is needed if the upgrade is in place.


  • Good list and I support it. No reason to go backwards anymore. Those companies that still run XP on every desktop and mandate it, or have SQL2K, aren't going to run to Denali. If they think they need it, they'll make exceptions for the people that need it.

    Any IT professional that wants to work on Denali, but has XP at work. Either invest in a machine that you can run it on at home or learn to set up a VM, but there is no reason for MS to invest time or testing efforts into supporting XP at this point.

  • I think the Express Editions should support WinXP. For all other versions I'm fine with the list above.

  • No XP support. No 2k support.

  • I have no concerns with the SQL Server version upgrade paths that are suggested, although a number of the systems I'm responsible for are still on 2000!! :-(

    However, a large number of our servers are Windows Server 2003 R2 and there are no plans at all to upgrade/change these to Server 2008 so from a personal perspective, the proposed support matric for OSes would cause me a problem.


  • - Dan

    I recommend adding Windows 2003 SP2 for the simple reason that most of the shops (in my finite experience) out there have not made the jump to 2008 svr. Second, in an economic downturn this deep companies are very likely NOT to make the jump soon. This will crimp your sales of SQL Server.

    Second, it is silly to create a cranky upgrade path. Why would the upgrade process whine about 2008 sp1 or 2008R2 RTM? Embrace upgrading 2008 RTM and 2008R2 RTM.

  • Its time to move on.

    Spend more time fine-tuning Denali for Vista+, but if its a business decision, then make it a good one but include the costs for supporting XP.

    I work in an organization with 10.000+ PCs (and XP's) and while I won't be able to use Denali anytime soon, I am advocating for the innovation and progress.

    As for the Server 2003 - this one should be definitely supported, way too many solutions won't be migrated for years from this OS.

  • this sounds great.. but the thing that REALLY matters to me is that cube-development in SQL 2005 and newer is like ridiculously complex, and I prefer the cube builder in SQL 2000... Am I still going to be able to build cubes on SQL 2000 (and then migrate them to 2005-2012 for production)??

    When you guys kill SQL 2000 Analysis Services support is when I _CRY_.

Page 2 of 3 (45 items) 123