Option 2 is likely going to be the better bet but there are some caveats: 1) SQL can be a bit fussy about having the server renamed; there is a script you have to run to sort it out
2) Moving over those databases will require you to also recreate the following: a. SQL Agent Jobs (aside from those used by the maintenance plans) b. Logins (SQL accounts will be a bit of a pain) there is a script to handle this as well. DAMIEN SOLODOW Systems Engineer 317.447.6033 (office) 317.447.6014 (fax) HARRISON COLLEGE From: [email protected] [mailto:[email protected]] On Behalf Of Jesse Rink Sent: Monday, August 12, 2013 3:34 PM To: [email protected] Subject: [NTSysADM] sql server upgrade We have an older Windows 2003 R2 x64 VM server which contains SQL2005 x64 on it. I'm planning on getting this box more current... My first option is to: 1. Take a image backup of the VM with our PHD Virtual software 2. Increase the c: drive hard disk in vSphere and then use a partition tool to expand the c: partition (its too small to perform the 2008 R2 upgrade on it) 3. Upgrade 2003 R2 x64 to Windows 2008 R2. 4. Upgrade SQL 2005 to SQL 2008 R2. Anyone had bad experiences going this route? The second option is to: 1. Create a brand new 2008 R2 server with SQL 2008 R2. 2. Detach the 10 DBs from SQL-OLD, copy them over to the SQL-NEW server and re-attach. 3. Decomission the old SQL-OLD server 4. Rename SQL-NEW to SQL-OLD and assign it the same IP address that the original SQL-OLD had. 5. Setup my Maintenance Plans from scratch. I think I'll be good for all my client applications that have specific ODBC settings configured pointing to either the IP address of the SQL box or the computer name/FQDN. Anyone had bad experiences going this route? Leaning more towards option TWO at this time... I tend to like clean installs as opposed to upgrades (generally). JR
