Installing just the SQL part of SBS on another Server

[2canSAM]

I am working on a quote for a client and they have Windows Small Business Server 2000 retail installed on a server in the office. They had another company order them a new server and were told this server would work fine with the software they already had. The new server hardware will not work with Server 2000 due to drivers for the newer hardware not being available. Now this other company is telling them they can buy Windows Server 2003 and just install the SQL portion of their old SBS 2000 software onto their new Server 2003. I explained to them that this would not work as the license they have is for SBS 2000 and not for a standalone SQL install and just need to verify I am correct.

Confirmed by Microsoft that you cannot split up the SBS software packages
http://support.microsoft.com/kb/295765

 

[RebateMonger]

It's contrary to the SBS 2000 license to install the included SQL server anywhere but on the SBS server it came with.

Retail SBS 2003 Premium Edition was pretty cheap a year or two ago. About $900 from Newegg.com. I imagine that somebody must have a package for sale somewhere. If you are going to go to all the trouble of installing SBS, might as well have a legal package. An inquiry on one of the national SBS forums (on Yahoo, for instance), would probably dig up somebody with a Retail license for sale.

Assuming their SBS 2000 license isn't OEM, they could consider installing VMWare or Hyper-V Server on the new server and then installing their SBS 2000 in the VM. That setup wouldn't be without its own challenges, but it certainly could be done.

Obviously, they could just buy an SBS 2008 Premium package for about $1800 and be done with it, too. Probably cheaper in the long run....

 

[2canSAM]

It's contrary to the SBS 2000 license to install the included SQL server anywhere but on the SBS server it came with.

Retail SBS 2003 Premium Edition was pretty cheap a year or two ago. About $900 from Newegg.com. I imagine that somebody must have a package for sale somewhere. If you are going to go to all the trouble of installing SBS, might as well have a legal package.

We are actually quoting out SBS 2008 for them, but the other company has quoted them Windows Server 2003 standard and is saying they can just use their existing SQL from their old SBS 2000 install. So of course the competing quote is less than ours and the client was asking me about it today. I told him I was 99.99% positive that it was a violation of the EULA to install the SQL portion of SBS onto another operating system (if you even could) and he kept going back to "Well they said it would work" yeah and they also said a brand new dell t610 server with all the goodies would work with Server 2000.

 

[RebateMonger]

I've edited my original post with a couple of other ideas. But, yeah, installing SBS 2008 Premium is probably the cheapest route in the long run.

 

[Tsaico]

Do they need full SQL? I have found in many applications, SQL express is enough. It comes for free for 2005 and 2008 versions. Here is MS's page on the 2008 version, and I think it there is one for 2005 if they need something older.

http://www.microsoft.com/express/sql/default.aspx

I had a couple of installations that were similar (SBS 2003) and movin them to 2005 express worked well.

And as for VMware, that could work, but keep in mind SBS doesn't like other DC's. Also, if you do not have the hardware to test the conversion over, you are going to have to use the same machine to after you make a VM image of the current server. Meaning, you won't have something ot fall back on if it goes to shit.

I would pitch them the SBS 2008 idea, there are many advantages to the exchange 2007 alone to warrant this, not mentioning the changes in SQL. Most of which is a much lower I/O for the HDs, which translates to much better performance and quicker response time for end user. But definitley take your backup of the current SQL and then throw it into a test machine and go through the migration process. Then take one of their machines, assuming it connects via ODBC vs named pipes, and then point the System DSN or user DNS to the new server instance to test it from a working perspective.

It sounds like the SQL getting busted is a deal breaker, so better get the migration kinks worked out on a tester vs production.