I wouldn't try and copy the system databases from one server to another,
much less from a non-clustered instance to a clustered instance. You are
likely much better off aliasing the old name to the new name using a DNS
record or a client-side alias. Even if you do manage to copy the system
databases, the network name presented to the outside world by the Cluster
won't change so you will not solve your initial problem.

Geoff N.Hiten
Microsoft SQL Server MVP


"KellyVV" <KellyVV (AT) discussions (DOT) microsoft.com> wrote

I am not 100% sure, but my gut tells me that the system database are
different.

The network name presented to the outside world IS the Virtual SQL Instance
name. Again, copying the system databases, even if successful, won't fix
your problem.

You may want to build a test cluster using cheap recycled SCSI hardware or
evena Virtual host (VMWare or Microsoft Virtual Server) as a training
exercise. You can then break it as much as necessary without affecting your
production systems. There is nothing like hands-on experience when you are
planning a major server migration.

Geoff N. Hiten
Microsoft SQL Server MVP

"KellyVV" <KellyVV (AT) discussions (DOT) microsoft.com> wrote

Clustered named instances show up as VirtualServerName\InstanceName. Since
the Virtual Server and the Instance have the same name your system would
start out as Server2\Server2. Renaming a clustered instance is possible but
unsupported and highly unrecommended.

How to change a clustered SQL Server Network Name
http://support.microsoft.com/default...b;en-us;307336

Again, I strongly urge you to look at a DNS-based solution.
http://www.faqs.org/rfcs/rfc2782.html

GNH


"KellyVV" <KellyVV (AT) discussions (DOT) microsoft.com> wrote

The ability to move the system and user databases between a standalone
Enterprise instance and clustered Enterprise server instance as you are
proposing is perfectly possible.
I have not noticed any difference between clustered and non-clustered system
databases, I however have not conducted any comprehensive comparison.

The issues you will more likely encounter here are the same issues as
migrating system databases between standalone instances of SQL.
Have a look at 224071. http://support.microsoft.com/kb/224071.
You may want to evaluate the possibility of migrating your user databases
and specific system information (Logins etc) as an alternative to ensure
your new setup clean.

Your assumptions about the SQL instance names are correct, if I understand
you correctly, are correct: You have a default standalone instance on
ServerX (which will be removed from the network) which you wish to replace
with a ServerX virtual server default instance. The only consideration here
would be that there can not be another preexisting default instance of SQL
installed on the cluster.

Regards

Gary Hope
iSolve Business Solutions
South Africa


"KellyVV" <KellyVV (AT) discussions (DOT) microsoft.com> wrote

Thanks again Geoff.

I wasn't clear on something - this is not a named instance of SQL. Both the
current install and the Virutual SQL Server will be a default instance. I
plan on naming the VIrtual SQL Server - 'Server1', which is the name of our
current stand alone server.

I will check out the links you sent.

Thanks again.

"Geoff N. Hiten" wrote:

The default cluster SQL instance cannot be the same name as a host server.

GNH


"KellyVV" <KellyVV (AT) discussions (DOT) microsoft.com> wrote

Right, the host server will be called something altogether different such as
Cluster1, with cluster nodes Clustera and Clusterb. My virtual SQL Server
name will be the same name as the "old" standalone server.

The new cluster will be built wtih different names entirely.

"Geoff N. Hiten" wrote:

Hello Gary,

Thank you very much for your time and answer!

I will look at the kb article. We were planning on exporting our logins and
sql agent jobs, etc, as a precautionary step anyway. We may decide to go
that route just to be assured of a clean install, as you state.

Thanks again,
Kelly



"Gary Hope" wrote: