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. 🙂