June 13, 2011 | SQL Server

SQL Server v.Next (Denali) : OS compatibility & upgrade support

Microsoft's Manageability PPM Dan Jones has asked for our feedback on their proposed list of supported operating systems and upgrade paths for the next version of SQL Server. (See the original post). This has generated all kinds of spirited debates on twitter, in protected mailing lists, and in private e-mail. If you're going to be involved in moving to Denali, you should be aware of these proposals and stay on top of the discussion until the results are in. (The media are starting to pick up on this as well, but don't be too afraid of hyper-sensationalized articles like this one.)

Operating System Compatibility

Dan has stated that they plan to support the following operating systems for Denali (and that setup would block on unsupported operating systems):

  • Windows Vista SP2+
  • Windows Server 2008 SP2+
  • Windows 7 SP1+
  • Windows Server 2008 R2 SP1+

I'm okay with this set of operating systems. Some (like Allan Hirt) feel that they should not support Windows Server 2008 at this point. Allan makes some good points, and that if you want to run failover clustering or on Server Core, Windows Server 2008 R2 SP1 really is your only option. But since R2 is x64 only, knocking Windows Server 2008 off the list entirely would mean that there wouldn't be a legitimate home for 32-bit, standalone instances of SQL Server Denali in the data center (let's set aside any tempting jokes about running Vista or Win7 in production). While I'm all for giving 32-bit the kiss of death across the board, this would be a huge blocker for all those companies with investments in 32-bit hardware that is still going strong, and that can't justify the triple-whammy of upgrading their SQL Server licenses, Windows licenses and hardware all at the same time. In fact I suspect most of those still on Windows Server 2008 are only there because in order to move to Windows Server 2008 R2, they'd have to move to x64 hardware. As long in the tooth as x86 is, and as much as this would benefit everyone in many ways (aside from the pocket book), this may be a little rushed. If the goal is to do as little as possible to block Denali adoption, removing Windows Server 2008 from the list is not the best means.

I don't feel all that sympathetic to companies that are still running Windows Server 2003 in their data centers. The adage, "if it ain't broke, don't fix it" certainly can apply here, but there should be another adage that also applies, "if it ain't modern, don't break it." In other words, feel free to continue running Windows Server 2003 on those servers until they die, but don't expect to use those same servers for Denali and beyond. Especially since the end of mainstream support is on the near horizon, even for Windows Server 2008 (July 2013).

A much bigger point of contention here is that Windows XP is no longer on the list at all. I cheered a little when I saw that – let's recall that, by the time Denali is released, Windows XP will be more than 10 years old. In fact its birthday is coming up: it was released to OEM in August of 2001, and went retail in October of the same year. My house isn't 10 years old, I've never owned a car that long, and I'm having a hard time thinking of anything at all that I've owned for longer, other than timeless books and sentimental things. Certainly nothing in the technology sphere.

Yet there are companies out there still running Windows XP. There is a small faction of folks fighting for the "dinosaur" companies with staunch policies that dictate that every single desktop in the enterprise must be running the same operating system and, whether it is evidence of how hard that it is to manage, how stubborn these companies are, or how bad Vista really was, those companies are still running XP company-wide. So the complaint is that such a company is not able to move to Denali at all — even though they will freely admit that there is no barrier to them moving to Denali in the data center — because their DBAs and DB devs have no option to support or manage their SQL Server instances. My argument here is that very few such companies are going to sit on XP on the desktop for 10+ years, but be running bleeding edge software in their data centers. How many of these companies won't let their DBAs run anything newer than XP, but will be an early adopter for Denali? My guess is very few, and that there are plenty of ways to prevent desktop policies from interfering with migrations to Denali. My advice to these large companies with strict OS policies is to make one of these choices:

 
<i><b>Don't move to Denali until you're ready</b></i>
The decision might be to hold off until your desktop situation is in order. This option is obviously not in Microsoft's best interest, but in order to support XP, Microsoft would have to balance the potential loss here with the cost of achieving and validating proper XP compatibility. I'm not sure how it will be weighted; they will likely want to do everything they can to improve upon the adoption rates of SQL Server 2008 R2, for example, which have been sub-par (probably because it was far less appealing for most shops than Denali will be).
 
<i><b> Allow exceptions</b></i>
If you really want to take advantage of Denali, you have to make it easier for your DBAs and DB devs to manage the stuff. If they can't install Dev/Express editions or client tools on their desktops, you're going to make things very hard for them to do so. One option is to relax your stuffy rules and allow them to run a more modern OS. You may make things a little bit harder for your IT/tech support folks, but remember that not everyone in the company needs to run Denali (so complaints like "we'll have to upgrade thousands of desktops" carry little weight), and among your entire staff, the more technical folks are the ones usually requiring the least assistance from IT.
 
 
<i><b>Give your DBAs and DB devs workarounds
</b></i>If you need to move to Denali and your DB folks are forced to be stuck on XP with no tools to manage SQL Server Denali, make it easy for them to implement workarounds. For example:
<ul><li>Have dedicated jump machines in the data center where they can RDP to run management tools - RDP is horrible, but on dedicated machines this should be far more tolerable than RDPing directly to the server. I suspect though, soon enough, they will be complaining about the speed to the point that you will start considering other options.
 
</li><li>Let them run VMs. Even on 32-bit XP they can run a more modern OS in a VM using Virtual PC, VMWare or VirtualBox - I do this all day since I choose to run Mac OS as my primary work environment. This may mean relaxing your supported software policy, but it means you can hold on to your primary operating system policy. One argument against this is for DBAs who can't figure out how to run a VM. Come on, seriously?
 
</li><li>Empower them with the ability to use PowerShell (since it can perform many of the tasks they're used to pointing and clicking to achieve). Not that you're stopping them from doing this now, but make sure they are able to work with IT to be able to work against the data center with as few hoops and complications as possible (think firewall rules, domain trusts, and remote execution policies).
 
</li><li>Dust off your SQL Server 2000 media, and let them install Query Analyzer (which doesn't check for up-level compatibility). I'm guessing they will moan about this huge step backwards, especially since Management Studio really is taking several steps forward with the Denali release.
</li></ul>
 
<i><b>Make it a mission to move everyone off of XP</b></i>
This one kind of speaks for itself. Be proactive. Congratulations on holding out for 10 years, but you're not going to be able to run Windows XP forever. If you're not already thinking about how to make the move, be it one desktop at a time, your DBAs and DB devs first, or en masse, you're going to find yourself behind the 8-ball sooner than you might think. Microsoft can't be the only vendor thinking about dropping XP support, and when they do, they make it a whole lot easier for other vendors to follow suit.

While its longevity may, in and of itself, be saying great things about Windows XP, perpetuating support of this operating system makes things much more complex for Microsoft and for ISVs. To paraphrase a colleague, "the carrot hasn't worked, it's time for the stick." If you're still grasping XP, it really is time to start thinking about letting go, otherwise the world is going to move on without you.

Upgrade Paths

In the past, the upgrade paths from one version of SQL Server to another have always been expressed in terms of absolute version – yes, you can upgrade from SQL Server 2000 to SQL Server 2008; yes, you can upgrade from SQL Server 2005 to SQL Server 2008 R2. Now we have something slightly different, at least as well as I can remember — upgrade paths to Denali don't just require a specific version, they require a specific version at a specific service pack level. Here is the preliminary list from Dan:

  • SQL Server 2005 SP4+
  • SQL Server 2008 SP2+
  • SQL Server 2008 R2 SP1+

In general I'm okay with this, but I'm having a real hard time understanding why SQL Server has to be at a specific service pack level before upgrading. Can't the upgrade include all of the bits required to take, say, 2005 SP2 -> 2005 SP4 -> Denali? I realize they may want to simplify the logic in the installer and keep the media size small, but I don't think that justifies all the extra work and time involved in making every customer *not* at the latest version get there first before running Denali setup. Never mind that for R2 customers, SP1 is not even out yet, and companies typically won't be installing SP1 on the day it comes out. Sure, some do, but definitely not all. Ideally, the list would look like this:

  • SQL Server 2005
  • SQL Server 2008
  • SQL Server 2008 R2

If they are going to insist on a minimum service pack level requirement, they better test all paths (including installing the required service pack immediately following by upgrading to Denali). And when there is an issue, the installer better make it very clear what the problem is, tell users how to resolve it, and do so early on – e.g. don't install just about everything and only fail / roll back the engine upgrade. But even with all that, I see these requirements as merely slowing adoption. If you are excited about Denali in any way, and are not at the above version/service pack levels, don't wait for the day of release — start planning your migration paths now.

 
<i><b>What about SQL Server 2000? </b></i>
For those of you still on SQL Server 2000, it's been long established that Denali will not support upgrades or even direct migrations from SQL Server 2000. This includes backup / restore and detach / attach. What you will need to do in this case is either:<ul><li> upgrade your 2000 instance to one of the supported versions above first, then upgrade to Denali;
 
</li><li>back up your 2000 database, restore it to a 2005, 2008, or 2008 R2 instance, then back it up again from there, and restore it to Denali; or, similarly,
 
</li><li>detach your 2000 database, attach it to a 2005, 2008 or 2008 R2 instance, then detach it from there, and attach it to Denali.
 
(Note that for the backup / detach options, if history is any indication, the specific SP requirement won't apply - you can detach a database from 2000 RTM, for example, and attach it to 2008 R2 CU7 without problem. The requirement is based on minimizing the in-place upgrade testing matrix.)
</li></ul>

If you don't have any in-between licenses to do this, and are planning to use Evaluation Edition, do not go the in-place upgrade route — I haven't tried it, but I'm fairly certain that you can neither upgrade from or upgrade to an Evaluation Edition instance. If you are going to use backup / restore or detach / attach, setting up a placeholder Evaluation Edition should be fine as a stepping stone.

There are other options as well, of course, that may be less resilient and will definitely require more work. For example, you could avoid the in-between hop by using any number of native or 3rd party data migration tools. Just remember that 80 compatibility mode is not supported in Denali, so it might be another story altogether to get your application working on the new version – even if you are currently running in 80 compatibility mode on SQL Server 2008 R2.

What can you do?

If you feel strongly about any of these issues, one way or the other, feel free to leave feedback here, but it will be most effective at Dan's blog post:

http://blogs.msdn.com/b/dtjones/archive/2011/06/10/sql-server-code-name-denali-supported-oses-and-upgrade-paths.aspx

Note that the points up for serious consideration are:

(a) whether to scratch Windows Server 2008 from the list;
(b) whether an in-place upgrade will require a specific service pack level; and,
(c) whether an in-place upgrade will actually completely block or simply warn in the case of an unsupported path.

These decisions aren't set in stone, and he's asking for your feedback. So again, if you have serious opinions about this, please don't sit back and then act mad and surprised when Denali comes out and you're not happy. 🙂

 

10 comments on this post

    • Steve Jones - June 14, 2011, 2:23 AM

      Nice post, and I agree with your points. No reason to support W2K3 or XP, especially from the security perspective as there are a number of features not supported on those OSes.
      If you want Denali, move. Not all your systems, but the ones that need to move to a more modern OS. If not, stick with what you are running. I see nothing wrong with SQL 2K/W2K or W2K3 systems in many places. If they are doing the job, let them continue to run. If you didn't upgrade to 2008 or 2008 R2, why is SQL 11 a push?

    • jchang - June 14, 2011, 5:22 AM

      I suggest not supporting Vista,
      and possibly only supporting W2K8 sp2 in 32-bit mode, ie, 64-bit must be on 64-bit. there are just too many problems and limitations with overly large support matrix

    • Glenn Berry - June 14, 2011, 11:26 PM

      Good post that summed up a heated debate. I don't think x86 (32-bit) hardware is a good argument for perpetuating Windows Server 2008 support.
      All server class processors from both AMD and Intel have had native x64 support for about 4-5 years. IMHO, it would be really a bad idea to install a shiny new copy of Denali on some server that is so old that it does not have x64 support.
      Upgrading to a new version of SQL Server is always a good time to upgrade your OS and your hardware, all at once. You buy a new server, install a fresh copy of the OS and a fresh copy of SQL Server, get everything configured and tested, and then you move on to that new server.
      The hardware cost (for the server itself) is pretty low compared to SQL Server Enterprise licenses.

    • AaronBertrand - June 14, 2011, 11:35 PM

      I have to disagree, Glenn, for a couple of reasons. (1) I know a lot of companies that can't afford to recycle their hardware every 4-5 years, and are still living out the depreciation of their current hardware. (2) One of the points I was trying to make is that not all companies can afford to just go out and buy new hardware, new OS licenses, and new SQL licenses all at once. Some have limited budgets and have to pick one of these things every year or every other year. (3) Sure, hardware is cheap compared to Enterprise licenses. But let's not forget, not everyone is running Enterprise. For the Standard and/or CAL folks, buying new servers is a big chunk of the budget, and please don't discard the work involved as part of the cost.
      Now, could the argument be, then these people shouldn't move to Denali? Of course, that's one argument. But if Microsoft wants to honestly assess which of these restrictions is really going to curb adoption, they have to consider the trade-offs. Currently they believe that Windows 2008 is still definitely in the picture. If you, Allan etc. can convince them otherwise, I'll stand behind the decision. But I can guarantee there will be some folks who won't move to Denali if that is the case. The question everyone is asking (but nobody can answer) is, where is the tipping point?

    • hlaroux - June 15, 2011, 12:15 AM

      Glenn, I agree with your point with one exception. It has been over 6 years (closer to 7) since virtually all server hardware has been x64 capable. Anyone buying a server since 2005 got x64 whether they knew it or not. Supporting x86, especially in a RAM hungry database server at this point is a waste. If you think you can't afford hardware built after 2005 you probably have no idea how much more the electricy and cooling is costing you to run that old way out-dated hardware.

    • Chuck Rummel - June 15, 2011, 3:54 PM

      For better or worse, IIRC they've made similar SP requirements for upgrades before.  
      And it's fascinating (if not completely frustrating) to watch a company try to justify the paradox between wanting to be on the most recent of everything on the server side yet trying to keep workstations on XP.
      @Steve – keeping sql2k/w2k as is might be one thing if on a VM, but if those are physical, that combo is likely running on hardware which has passed it's EOL and I start getting the feeling like I'm rolling the dice against MTBF.  Getting replacement parts for a 7-10 year old server isn't always easy.

    • opc.three - July 2, 2011, 11:27 PM

      I just loaded the Denali CTP and 80 compat mode is an option. I was curious because I heard *= and =* support was going away…which it is blocked even when in 80 mode, so now I am confused. Do you have any info on what's going the future of it?

    • Aaron Bertrand - July 3, 2011, 12:07 AM

      AFAIK *= and =* won't work in any compatibility mode in Denali. Sorry, but that's been announced for a LONG time now, why are you still using it?
      As for 80 compatible mode, yes it still works in CTP1 bit it will not work by RTM (in fact I suspect this will be fixed by the next public CTP).

    • opc.three - July 5, 2011, 6:16 PM

      I did hear it was going away but I do know some folks still being asked to support 80 mode. I personally am not being asked to support it, thank goodness. Everything I have read said Microsoft was only in the habit of supporting the last two versions in terms of compat mode so I was just shocked when I saw it was an option in this CTP.
      While 80 is an option in the CTP, *= queries do fail. But that begs the question: which is it? If they keep 80 mode but do not support *= then is it really a compat mode? Or is this some remnant of the codebase they started with that has yet to be trimmed from the product?

    • AaronBertrand - July 5, 2011, 6:54 PM

      They are *NOT* keeping 80 compat mode. In the first CTP they just hadn't yet cut that option, but I can assure you that it is going away, along with *= syntax.

Comments are closed.