LinkedIn | FaceBook | Twitter
SQL Server 2008 R2 is now out, and you can get the "Customer Technical Preview" or CTP here: http://technet.microsoft.com/en-us/evalcenter/ee315247.aspx
But it seems like SQL Server 2008 just came out! I'm still installing and upgrading it on the systems I manage. I tend not to focus too much on a new release, but it's foolish, I think, to ignore them until they are out. The organizations I serve depend on me to be aware of the technology in my field, and how it can (or can't) help them do their jobs. That's what I do.
So I need to keep up with the newer releases, even if I don't spend the majority of my time on them. To do that, I need to organize that effort so that I am efficient with my time. I thought I would share the way I evaluate a new release with you, and perhaps you can leverage the information in your own environment.
1. Set up a Virtual Machine with a clean OS, and all security software. I use the MSDN version of Windows Server, at the most common version of my organization, install my anti-virus and all patches, and then save that off to a USB drive. When I'm ready to do my evaluation, I copy it down, fire it up, and install the latest patches. Now I'm ready to run the install - and I always install. I never test an upgrade until I'm all done with the CTP process, since Microsoft doesn't always guarentee that an upgrade from a CTP will work, so I start with a fresh machine for each CTP. THat's why I use VM's for this.
2. Read up on the changes. There are three parts to a new release: some things are deprecated (removed), some things are altered (enhanced or changed), and other things are brand new. I do a web search on the release, normally hitting the MVP sites and Microsoft, as well as SQL Server Central, SSWUG, TechNet, SQL Server Magazines and more. I read the release notes, and then I look at the "What's new" section of Books Online for the new things: http://msdn.microsoft.com/en-us/library/bb510411(SQL.105).aspx. I look for anything that is deprecated that I'm using, and start the plan for migrating that technology. It's probably the most important thing I check. Next I check to see if something is enhanced, which might save me from buying a third party application to deal with any issues I've had. Then I look at the new features and match that up with what I know about the business in my organization. Here's the latest link I'm using for R2: http://blogs.technet.com/dataplatforminsider/archive/2009/08/10/download-sql-server-2008-r2-august-ctp-today.aspx
3. Install and configure the new software. I document any "gotcha's" during the process, but I don't don't panic on these too much. Things change with each CTP. I also test an unattended install.
4. Install a workload. I restore a production database, run an app, run my test scripts, and take a look at any processes I currently use with the new release.
5. Provide feedback. I make sure that I keep my other DBA's in the loop, as well as the rest of the IT team. I also discuss with the business about any changes to licensing and so on that have been announced. I also close the loop with the Microsoft product team using http://connect.microsoft.com, to let them know if I ran into any issues with the CTP. After all, that's why they have the program to begin with, so that they don't release something I can't use.
I wondered what directory/folder, that after you completed a Build, you copied/saved to a USB drive? a whole C: drive or C:\program files and C:\Windows?...
I want a "fresh" VM for next time. I then install SQL Server or whatever else, play with it, and when I'm done I can just copy the "OS Only" VM over the top of it and start clean. In Hyper-V, You can just use a snapshot, but VPC doesn't have that feature.