The next version of SQL Server (codenamed "Denali"), I suspect, will be released sometime toward the end of 2011; I will stress, however, that this is nothing more than a barely-educated guess. Please don't ask me the actual release date, because I don't know any more than you do; even if I did know more than you do, I wouldn't be able to tell you that. In the meantime, I've had a chance to play with it since October, and now that you have access to it as well (you can download the first public CTP here), I thought I would share my impressions so far – and more importantly, some of the stumbles I've come across.
Before I talk about anything, first I want to highly recommend installing Denali in a virtual machine rather than on your primary workstation. Well, if you have Visual Studio, or SQL Server 2005, 2008 or 2008 R2 installed, and want those tools to continue working. Personally I haven't had any issues – SSMS for Denali, because it is a new Visual Studio shell, can install alongside SSMS for 2008 or 2008 R2, and the basic functionality in each application continues to work fine independently – EXCEPT BIDS PROJECTS. Others, though, have reported issues with items such as SSIS packages (I'm not an SSIS guy, so I will take their word for it, and pass it along to you). I'd also recommend getting all of your Windows updates installed while you are waiting for Denali to finish downloading – this will save you some time later because you'll want to be sure .NET 4.0 Framework, for example, is installed on your machine in advance.
Since SQL Server 2008 R2, I've developed a habit of running the "System Configuration Checker" before bothering to run the actual installation. This lets me know right away about anything I'll have to do before expecting to successfully install SQL Server (and this list seems to get longer with every release).
A new setup "feature"
In the case of Denali, they seem to want you to have this "no-reboot package" in place before installing a SQL Server instance:
If you click on "View detailed report" you will see this text next to the relevant item:
"This rule determines whether the computer has the required update package that ensures that the computer will not have to be rebooted because of the Microsoft .NET Framework 4 installation."
Less reboots is a good thing, right? Let's keep moving, as I'm not sure at this point how many reboots this is really going to save you – especially if you already have the .NET 4.0 Framework installed. If you click on the "Failed" link, you will see this alert, so you can determine what to do:
Now, this is just a simple message box, so the link itself is neither clickable nor copyable. But, the message as a whole *is* copyable. With the Rule Check Result message box focused, click Ctrl + C, then open a copy of Notepad and click Ctrl + V:
Now you can go download the update by copying and pasting the URL (without the trailing period, because that will just bring you to an empty Microsoft Search page). Maybe in a future CTP they will fix this by making the update a part of the installation process (just like they don't give you an error message and an un-clickable download link if you don't have the right level of .NET Framework installed – it's simply one of the steps in setup). So to save yourself this hassle, go install this update now, and reboot, before attempting to install Denali:
Unfortunately, you might notice that, once you click on your relevant platform, you have multiple download files available (this reminds me of the horrible list of cryptic file names you find when downloading a cumulative update):
And the only help you get from the page is, "Download the files most appropriate for you." The first few times I did this, I only installed the first file (KB958488) and rebooted before attempting setup again. This worked okay and allowed the setup support rules to succeed, however at the end of setup I was still forced to reboot in order to finish installation. On my most recent try, I decided to download and install both files (in the order: KB958488 then KB979900), and I still had to reboot at the end of SQL Server setup. Maybe the "no-reboot package" should be renamed the "now with even MORE reboots package." Long story short: be prepared to reboot at least twice, and quite possibly three times, in order to get Denali up and running.
With that out of the way…
Okay, once you have both updates installed and have rebooted, you can start setup again, go to the Installation tab, and select "New SQL Server stand-alone installation or add features to an existing installation." As a side note, please resist the temptation to close the SQL Server Installation Center dialog (you will see two Setup icons in your taskbar while going through the process). Closing the Installation Center will actually cause setup to fail – as far as I can tell, this has yet to be addressed in Denali. See the following Connect item for more information:
Next, you will specify an edition (probably Enterprise Evaluation), say ok to the privacy stuff (and decide if you want to uncheck the usage reporting feature), and install Setup Support Files. When setup has finished this task, a new summary screen will be there, signifying the start of the remainder of setup:
In a default configuration, most folks will have a warning next to the Windows Firewall rule. If you click on the 'Warning' text, here is the dialog you will see:
I've seen several people stop immediately and claim that SQL Server won't install because of some firewall rule. Nothing could be further from the truth – this is just informing you that the firewall is enabled, and that you might have issues connecting to SQL Server from outside of your machine as a result. If you want to read more about this rule and how it might affect your installation, instead of repeating the above process of copying the text from the dialog and then extracting the link from it, I'll supply the link here:
On the next screen, we see one of the new choices implemented during the SQL Server 2008 R2 cycle, called the Setup Role:
Seems straightforward enough – instead of digging into all of the complex options, you can make a choice and ensure that the things you'll need will be pre-selected. I complained about this choice though, since the last option does not seem that intuitive to me:
Personally, I always select the first and default option, "SQL Server Feature Installation," and then customize the features on the next screen. Choosing "All Features with Defaults" will also allow you to customize, but I'm not sure about all of the defaults that are set for you. It seems to me that this just prevents you from having to check all of the checkboxes yourself, since selecting any single item should also select that item with its own defaults. One peculiarity though, "All Features" seems to really be "All Features except Master Data Services" – here is how my Feature Selection screen looked after selecting this option:
Notice that only one box has been left un-checked. (Also, I'm not sure what the "Redistributable Features" heading is doing there if it has no sub-items.) For most of my VM work, I just choose Database Engine Services and Management Tools. I used to be a big proponent of installing Books Online locally, but the web version is much more convenient and self-updating – except in cases where servers are explicitly prohibited from going online. I'm not trying to dissuade you from installing Books Online, I just find that a web-based search is easier and it is also easier to share a URL with other users who may or may not have BOL installed, and may or may not have the same version as you.
Once you've selected your options and clicked Next, you will wait for several seconds until the Installation Rules screen comes up. On multiple installations I have yet to come up with any issues here, but if you do, hopefully they will be straightforward.
Next up will be Instance Configuration. On machines where I will have multiple instances, I try to use *only* named instances. In this case I choose "DENALI" as a Named instance.
Then we move on to Disk Space Requirements. Unless you are on a really cramped VM, you shouldn't haveto do anything here except click Next.
The Server Configuration tab prompts you to choose account names for services. In spite of the recommendation, for local development and testing, I use the "Use the same account for all SQL Server services" button and choose NT AUTHORITY\SYSTEM from the drop-down. I also change SQL Server Agent to start automatically (and leave the Collation tab alone):
On the Database Engine Configuration screen, there are three tabs: Account Provisioning, Data Directories, and FILESTREAM. I typically use Mixed Mode for authentication so that if I need to get into SQL Server it doesn't matter which Windows login I'm using. Note that the sa password policy might be tied to your Windows and/or group policy. You'll also be required to add at least one Windows account to serve as a system administrator – I typically click the "Add Current User" button:
On a virtual machine, I typically leave the Data Directories tab alone, because usually there is only a C:\ … so customizing these options wouldn't be very meaningful (on a real server, on the other hand, this tab will get a lot of use). I also don't use FILESTREAM currently, so I leave that option unchecked.
From this point on, it's pretty much smooth sailing. You can uncheck the checkbox on the Error Reporting screen, if that is your preference. On the Installation Configuration Rules screen, you can see that a bunch of rules are checked, but to me they all seem like rules that would have prevented you from getting this far in the first place, had they failed. If you run into any failures here, I would love to hear about them. The Ready To Install screen simply offers a summary of the options you've chosen. In my experience, the Installation Progress takes about 7 minutes, but this will vary greatly depending on the speed of your machine.
In my case, for one virtual machine, it wasn't such smooth sailing. Partway through the final installation step, I received this error:
For searchability I'm also going to repeat the error in text, and state that the hex equivalent is 0x8007006E, translating to "not found" in Windows-speak:
Error 25541.Failed to open XML file C:\Windows\Microsoft.NET\Framework\v4.0.3031\CONFIG\machine.config, system error: -2147024786
I clicked OK, and then installation proceeded… so I assumed the error couldn't have been that critical. Then when installation finished, I discovered that this prevented the installation of Management Tools, and also led to a program crash at the conclusion of setup (click to embiggen):
As it turns out, I had previously installed a beta of Visual Studio 2010 on this VM, and didn't think to remove it. It also sat idle for several months, during which time RTM was released. This is one reason why I do these things in a VM – I can usually clean things up quite a bit, if I manage to think to do it before setting out on a new adventure. My mistake here was re-using a VM that I had clearly used already for several purposes, and not thoroughly inspecting its up-to-date-ness.
I did file a Connect bug against setup, since the prerequisite checks and the summary both incorrectly identified that .NET 4.0 Framework was already installed. Technically that is correct, but it was not THE version of the framework that setup truly required. Hopefully this check will be more stringent by the time the next CTP rolls out, and more importantly, hopefully there aren't a lot of people out there still sitting on such outdated versions of the .NET 4.0 Framework.
Anyway, to rectify, I simply used Control Panel > Programs and Features to uninstall the Visual Studio beta, then downloaded and installed the .NET 4.0 Framework (using the web installer found here). This required yet another reboot. Then I ran Denali setup again, this time choosing only Management Tools. Installation went off without a hitch – and this time, did not require a reboot. Then I was in business – yay!