Moving SQL server to new hardware

I have a domain controller "ServerA". I am going to be replacing this
hardware with a new server - "ServerB". Currently "ServerA" runs SQL 2000
standard and has one instance "ServerA". I have a number of applications
etc, that use data on ServerA. When I bring Server B up, is there a way to
have the instance name to be ServerA and does this still change my
connection strings etc? I am just looking for a way to replace the server,
and not have to change all of my connection strings across the enterprise.
Both serverA and serverB are windows 2003 and both are SQL 2000.
Looking forward to your advice.
See if this helps:
How to move SQL Server from one computer to another
http://vyaskn.tripod.com/moving_sql_server.htm
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Fredrick A. Zilz" <fzilz@.NOSPAM.interhealthusa.com> wrote in message
news:eayAUbuuEHA.2632@.TK2MSFTNGP12.phx.gbl...
I have a domain controller "ServerA". I am going to be replacing this
hardware with a new server - "ServerB". Currently "ServerA" runs SQL 2000
standard and has one instance "ServerA". I have a number of applications
etc, that use data on ServerA. When I bring Server B up, is there a way to
have the instance name to be ServerA and does this still change my
connection strings etc? I am just looking for a way to replace the server,
and not have to change all of my connection strings across the enterprise.
Both serverA and serverB are windows 2003 and both are SQL 2000.
Looking forward to your advice.

Moving SQL server to new hardware

I have a domain controller "ServerA". I am going to be replacing this
hardware with a new server - "ServerB". Currently "ServerA" runs SQL 2000
standard and has one instance "ServerA". I have a number of applications
etc, that use data on ServerA. When I bring Server B up, is there a way to
have the instance name to be ServerA and does this still change my
connection strings etc? I am just looking for a way to replace the server,
and not have to change all of my connection strings across the enterprise.
Both serverA and serverB are windows 2003 and both are SQL 2000.
Looking forward to your advice.See if this helps:
How to move SQL Server from one computer to another
http://vyaskn.tripod.com/moving_sql_server.htm
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Fredrick A. Zilz" <fzilz@.NOSPAM.interhealthusa.com> wrote in message
news:eayAUbuuEHA.2632@.TK2MSFTNGP12.phx.gbl...
I have a domain controller "ServerA". I am going to be replacing this
hardware with a new server - "ServerB". Currently "ServerA" runs SQL 2000
standard and has one instance "ServerA". I have a number of applications
etc, that use data on ServerA. When I bring Server B up, is there a way to
have the instance name to be ServerA and does this still change my
connection strings etc? I am just looking for a way to replace the server,
and not have to change all of my connection strings across the enterprise.
Both serverA and serverB are windows 2003 and both are SQL 2000.
Looking forward to your advice.

Moving SQL server to new hardware

I have a domain controller "ServerA". I am going to be replacing this
hardware with a new server - "ServerB". Currently "ServerA" runs SQL 2000
standard and has one instance "ServerA". I have a number of applications
etc, that use data on ServerA. When I bring Server B up, is there a way to
have the instance name to be ServerA and does this still change my
connection strings etc? I am just looking for a way to replace the server,
and not have to change all of my connection strings across the enterprise.
Both serverA and serverB are windows 2003 and both are SQL 2000.
Looking forward to your advice.See if this helps:
How to move SQL Server from one computer to another
http://vyaskn.tripod.com/moving_sql_server.htm
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Fredrick A. Zilz" <fzilz@.NOSPAM.interhealthusa.com> wrote in message
news:eayAUbuuEHA.2632@.TK2MSFTNGP12.phx.gbl...
I have a domain controller "ServerA". I am going to be replacing this
hardware with a new server - "ServerB". Currently "ServerA" runs SQL 2000
standard and has one instance "ServerA". I have a number of applications
etc, that use data on ServerA. When I bring Server B up, is there a way to
have the instance name to be ServerA and does this still change my
connection strings etc? I am just looking for a way to replace the server,
and not have to change all of my connection strings across the enterprise.
Both serverA and serverB are windows 2003 and both are SQL 2000.
Looking forward to your advice.

Moving SQL 7.0 to New Hardware

Hi,
I've read some articles on the web but none seem to fit my
situation.
We have an application upgrade and at the same time need
to move our SQL 7.0 to new hardware.
The new server will have Windows 2000 and SQL 7.0
installed and then we will upgrade to SQL 2000 at some
point during our application upgrade.
What is the best method of moving our SQL 7.0 databases to
our new hardware?
Thanks in advance.You can either use BACKUP and RESTORE, or sp_detach_db and sp_attach_db.
Make sure you sync users after transferring databases.
Carlos E. Rojas
SQL Server MVP
Co-Author SQL Server 2000 programming by Example
"Larry" <sloberman@.email.chop.edu> wrote in message
news:582901c40081$dd8e7ae0$a301280a@.phx.gbl...
> Hi,
> I've read some articles on the web but none seem to fit my
> situation.
> We have an application upgrade and at the same time need
> to move our SQL 7.0 to new hardware.
> The new server will have Windows 2000 and SQL 7.0
> installed and then we will upgrade to SQL 2000 at some
> point during our application upgrade.
> What is the best method of moving our SQL 7.0 databases to
> our new hardware?
> Thanks in advance.

Moving SQL 7.0 to New Hardware

Hi,
I've read some articles on the web but none seem to fit my
situation.
We have an application upgrade and at the same time need
to move our SQL 7.0 to new hardware.
The new server will have Windows 2000 and SQL 7.0
installed and then we will upgrade to SQL 2000 at some
point during our application upgrade.
What is the best method of moving our SQL 7.0 databases to
our new hardware?
Thanks in advance.You can either use BACKUP and RESTORE, or sp_detach_db and sp_attach_db.
Make sure you sync users after transferring databases.
--
Carlos E. Rojas
SQL Server MVP
Co-Author SQL Server 2000 Programming by Example
"Larry" <sloberman@.email.chop.edu> wrote in message
news:582901c40081$dd8e7ae0$a301280a@.phx.gbl...
> Hi,
> I've read some articles on the web but none seem to fit my
> situation.
> We have an application upgrade and at the same time need
> to move our SQL 7.0 to new hardware.
> The new server will have Windows 2000 and SQL 7.0
> installed and then we will upgrade to SQL 2000 at some
> point during our application upgrade.
> What is the best method of moving our SQL 7.0 databases to
> our new hardware?
> Thanks in advance.

Moving SQL 6.5 from NT 4.0 to W2K3. Please help

Hello,
As part of Active Directory migration (from NT 4.0 to Server 2003
Enterprise), we will be replacing our current SQL server hardware with a
newer server which will be running windows 2003. Can anyone point me to any
document on how to go about doing this please. I am very new to SQL
migration, what are the things that I should be watching? The customer does
not want to upgrade to SQL2000 (prefers to stay with 6.5). Any issues with
doing that?
ThanksHi
SQL 6.5 is not supported on Windows 2003, and neither is SQL Server 7.0
SQL 6.5 is no longer supported since 31-Jan-2002 and SQL 7.0 dies
31-Dec-2005.
SQL 2000 is his only option.
http://support.microsoft.com/gp/lifesrvr
--
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"warsai" <warsai@.discussions.microsoft.com> wrote in message
news:842BB3B4-47AF-499C-B0BC-A91683255F7E@.microsoft.com...
> Hello,
> As part of Active Directory migration (from NT 4.0 to Server 2003
> Enterprise), we will be replacing our current SQL server hardware with a
> newer server which will be running windows 2003. Can anyone point me to
any
> document on how to go about doing this please. I am very new to SQL
> migration, what are the things that I should be watching? The customer
does
> not want to upgrade to SQL2000 (prefers to stay with 6.5). Any issues with
> doing that?
> Thanks
>

Moving SQL 6.5 from NT 4.0 to W2K3. Please help

Hello,
As part of Active Directory migration (from NT 4.0 to Server 2003
Enterprise), we will be replacing our current SQL server hardware with a
newer server which will be running windows 2003. Can anyone point me to any
document on how to go about doing this please. I am very new to SQL
migration, what are the things that I should be watching? The customer does
not want to upgrade to SQL2000 (prefers to stay with 6.5). Any issues with
doing that?
Thanks
Hi
SQL 6.5 is not supported on Windows 2003, and neither is SQL Server 7.0
SQL 6.5 is no longer supported since 31-Jan-2002 and SQL 7.0 dies
31-Dec-2005.
SQL 2000 is his only option.
http://support.microsoft.com/gp/lifesrvr
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"warsai" <warsai@.discussions.microsoft.com> wrote in message
news:842BB3B4-47AF-499C-B0BC-A91683255F7E@.microsoft.com...
> Hello,
> As part of Active Directory migration (from NT 4.0 to Server 2003
> Enterprise), we will be replacing our current SQL server hardware with a
> newer server which will be running windows 2003. Can anyone point me to
any
> document on how to go about doing this please. I am very new to SQL
> migration, what are the things that I should be watching? The customer
does
> not want to upgrade to SQL2000 (prefers to stay with 6.5). Any issues with
> doing that?
> Thanks
>

Moving SQL 6.5 from NT 4.0 to W2K3. Please help

Hello,
As part of Active Directory migration (from NT 4.0 to Server 2003
Enterprise), we will be replacing our current SQL server hardware with a
newer server which will be running windows 2003. Can anyone point me to any
document on how to go about doing this please. I am very new to SQL
migration, what are the things that I should be watching? The customer does
not want to upgrade to SQL2000 (prefers to stay with 6.5). Any issues with
doing that?
ThanksHi
SQL 6.5 is not supported on Windows 2003, and neither is SQL Server 7.0
SQL 6.5 is no longer supported since 31-Jan-2002 and SQL 7.0 dies
31-Dec-2005.
SQL 2000 is his only option.
http://support.microsoft.com/gp/lifesrvr
--
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"warsai" <warsai@.discussions.microsoft.com> wrote in message
news:842BB3B4-47AF-499C-B0BC-A91683255F7E@.microsoft.com...
> Hello,
> As part of Active Directory migration (from NT 4.0 to Server 2003
> Enterprise), we will be replacing our current SQL server hardware with a
> newer server which will be running windows 2003. Can anyone point me to
any
> document on how to go about doing this please. I am very new to SQL
> migration, what are the things that I should be watching? The customer
does
> not want to upgrade to SQL2000 (prefers to stay with 6.5). Any issues with
> doing that?
> Thanks
>

Moving RS to new Hardware

I have two servers, one being the SQL server with RS db, one being the
webserver with reporting services on it. I want to replace this webserver
slowly by installing reporting services on a new server but at the same time
being able to access the reports on the old server until we take it offline.
Should I install RS on new server and point to the existing DB or is there
something special I will have to do to get it to work? I don't want to
create a web farm since the old server is coming offline in the next month
or so but can't do all at once.
Thanks in advance.You can't have two servers pointing to the same database without it being a
webfarm (which is what you say you don't want to do).
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Jason Wood" <jwood63@.hotmail.com> wrote in message
news:QnpGf.11363$915.6027@.southeast.rr.com...
>I have two servers, one being the SQL server with RS db, one being the
> webserver with reporting services on it. I want to replace this webserver
> slowly by installing reporting services on a new server but at the same
> time
> being able to access the reports on the old server until we take it
> offline.
> Should I install RS on new server and point to the existing DB or is there
> something special I will have to do to get it to work? I don't want to
> create a web farm since the old server is coming offline in the next month
> or so but can't do all at once.
> Thanks in advance.
>|||So reinstall and restore RS database and use the command tools to reset the
key?
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:u2swOiNLGHA.3944@.tk2msftngp13.phx.gbl...
> You can't have two servers pointing to the same database without it being
> a webfarm (which is what you say you don't want to do).
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Jason Wood" <jwood63@.hotmail.com> wrote in message
> news:QnpGf.11363$915.6027@.southeast.rr.com...
>>I have two servers, one being the SQL server with RS db, one being the
>> webserver with reporting services on it. I want to replace this
>> webserver
>> slowly by installing reporting services on a new server but at the same
>> time
>> being able to access the reports on the old server until we take it
>> offline.
>> Should I install RS on new server and point to the existing DB or is
>> there
>> something special I will have to do to get it to work? I don't want to
>> create a web farm since the old server is coming offline in the next
>> month
>> or so but can't do all at once.
>> Thanks in advance.
>>
>|||I thought the issue is that you want to have two RS servers both showing the
same reports? And that you want to do this without doing a web farm. The
only way to do that is to have a separate SQL Server database for the
metadata. What I would do is install RS and have it have its own databases
(I don't know the steps to do this when the same SQL Server is hosting two
different RS remotely). Then I would just deploy the same reports to the
second server and manually keep up with changes until you retire the first
RS server. I have my RS and the metadata database on the same box. The data
I am reporting off on is on a variety of servers.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Jason Wood" <jwood63@.hotmail.com> wrote in message
news:HmLGf.11467$915.8413@.southeast.rr.com...
> So reinstall and restore RS database and use the command tools to reset
> the key?
>
> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
> news:u2swOiNLGHA.3944@.tk2msftngp13.phx.gbl...
>> You can't have two servers pointing to the same database without it being
>> a webfarm (which is what you say you don't want to do).
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Jason Wood" <jwood63@.hotmail.com> wrote in message
>> news:QnpGf.11363$915.6027@.southeast.rr.com...
>>I have two servers, one being the SQL server with RS db, one being the
>> webserver with reporting services on it. I want to replace this
>> webserver
>> slowly by installing reporting services on a new server but at the same
>> time
>> being able to access the reports on the old server until we take it
>> offline.
>> Should I install RS on new server and point to the existing DB or is
>> there
>> something special I will have to do to get it to work? I don't want to
>> create a web farm since the old server is coming offline in the next
>> month
>> or so but can't do all at once.
>> Thanks in advance.
>>
>>
>|||Thanks, good point; that's what I will do.
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:udeqjeaLGHA.140@.TK2MSFTNGP12.phx.gbl...
>I thought the issue is that you want to have two RS servers both showing
>the same reports? And that you want to do this without doing a web farm.
>The only way to do that is to have a separate SQL Server database for the
>metadata. What I would do is install RS and have it have its own databases
>(I don't know the steps to do this when the same SQL Server is hosting two
>different RS remotely). Then I would just deploy the same reports to the
>second server and manually keep up with changes until you retire the first
>RS server. I have my RS and the metadata database on the same box. The data
>I am reporting off on is on a variety of servers.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Jason Wood" <jwood63@.hotmail.com> wrote in message
> news:HmLGf.11467$915.8413@.southeast.rr.com...
>> So reinstall and restore RS database and use the command tools to reset
>> the key?
>>
>> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
>> news:u2swOiNLGHA.3944@.tk2msftngp13.phx.gbl...
>> You can't have two servers pointing to the same database without it
>> being a webfarm (which is what you say you don't want to do).
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Jason Wood" <jwood63@.hotmail.com> wrote in message
>> news:QnpGf.11363$915.6027@.southeast.rr.com...
>>I have two servers, one being the SQL server with RS db, one being the
>> webserver with reporting services on it. I want to replace this
>> webserver
>> slowly by installing reporting services on a new server but at the same
>> time
>> being able to access the reports on the old server until we take it
>> offline.
>> Should I install RS on new server and point to the existing DB or is
>> there
>> something special I will have to do to get it to work? I don't want to
>> create a web farm since the old server is coming offline in the next
>> month
>> or so but can't do all at once.
>> Thanks in advance.
>>
>>
>>
>

Moving RS 2005 Reports to new server

Hi Guru,

Currently, we are running our RS 2005 reports on our old hardware and wanted to move them to better server where I’ll be building it tomorrow. On the existing server, we installed both database and reporting services running on the same box but I’m ONLY planning to install reporting service on the new server.

What are the options to move RDL, shared data sources, shared schedules, jobs to the new server? I heard people talked about backing up and restore both ReportServer and ReportServerTempdb databases to the new server would do it. How can I restore or attach these two dbs to new server when we don’t plan to install database services on it?

Please help!

Thanks,

Silaphet,

You probably have to deploy your reports again using Visual Studio.|||YOu can do a backup and restore on the new server of the Report Server database. You will additionally have to backup the encryption key from the old server using the configuration utility and apply / restore it on the new one as the content of the database is encrypted and cannot be decrypted without the key of the old server.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

Moving RS 2005 Reports to new server

Hi Guru,
Currently, we are running our RS 2005 reports on our old hardware and
wanted to move them to better server where I'll be building it
tomorrow. On the existing server, we installed both database and
reporting services running on the same box but I'm ONLY planning to
install reporting service on the new server.
What are the options to move RDL, shared data sources, shared
schedules, jobs to the new server? I heard people talked about backing
up and restore both ReportServer and ReportServerTempdb databases to
the new server would do it. How can I restore or attach these two dbs
to new server when we don't plan to install database services on it?
Please help!
Thanks,
Silaphet,If you are moving only RS and plan on the databases used by RS for its
metadata/object caching to stay where it is then you definitely are not
going to want to touch the databases. When you mention the RDL, shared
datasource, etc etc. These are all in the database. There are no files. You
only need the application to be moved and then pointed to the database. RDL
only exists on the development. When you deploy they are compiled and stored
in the database.
If you have enterprise then you should just treat this like a web farm and
install the new one and have both using the same databases and then remove
the old one once done. Otherwise you need to remove the old one and then
install the new. When you install the new you point it to the databases.
Standard edition does not support web farm (multiple RS all using the same
databases), only enterprise.
Here is a link that deals with totally moving RS (the app and the supporting
databases) which might help you understand the pieces but isn't quite what
you are doing:
http://support.microsoft.com/default.aspx?scid=842425
Bruce Loehle-Conger
MVP SQL Server Reporting Services
<smounkhaty@.bremer.com> wrote in message
news:1165856070.452398.223800@.73g2000cwn.googlegroups.com...
> Hi Guru,
> Currently, we are running our RS 2005 reports on our old hardware and
> wanted to move them to better server where I'll be building it
> tomorrow. On the existing server, we installed both database and
> reporting services running on the same box but I'm ONLY planning to
> install reporting service on the new server.
> What are the options to move RDL, shared data sources, shared
> schedules, jobs to the new server? I heard people talked about backing
> up and restore both ReportServer and ReportServerTempdb databases to
> the new server would do it. How can I restore or attach these two dbs
> to new server when we don't plan to install database services on it?
> Please help!
> Thanks,
> Silaphet,
>

Moving Replication Distributor to new cluster

Hi
What are the gotchas on moving a Replication Distributor to new hardware/a
new cluster?
Kind Regards,
T. Hagen
You have to drop the publications and disable replication on the publisher
before the move. You have to make sure your remote distributor is
clustered - which it appears to be
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"thagen" <thagen@.discussions.microsoft.com> wrote in message
news:23A725E7-ED77-4BD6-A8A6-AF3D91C96D2D@.microsoft.com...
> Hi
> What are the gotchas on moving a Replication Distributor to new hardware/a
> new cluster?
> Kind Regards,
> T. Hagen
|||As well as Hilary's response, and it's a long time since I worked on
clustering a distributor, I recall that the distribution working folder
should be set up as a shared resource on the cluster.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||Thanks Hilary.
There is nothing to be done on the Subscriber side?
And as for the actual steps in moving the Distributor, you have any how-to
on that?
Kind Regards,
Torkild
"Hilary Cotter" wrote:

> You have to drop the publications and disable replication on the publisher
> before the move. You have to make sure your remote distributor is
> clustered - which it appears to be
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "thagen" <thagen@.discussions.microsoft.com> wrote in message
> news:23A725E7-ED77-4BD6-A8A6-AF3D91C96D2D@.microsoft.com...
>
>
|||Perhaps you mean the snapshot share While you can park this anywhere, it
is best on the publisher.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uRXwYO8ZHHA.2316@.TK2MSFTNGP04.phx.gbl...
> As well as Hilary's response, and it's a long time since I worked on
> clustering a distributor, I recall that the distribution working folder
> should be set up as a shared resource on the cluster.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
>
|||You can't move the distributor. You have to disable publishing on the
publisher. Pre-create the distributor on the remote distributor and then
configure your publishers to use this distributor. Then connect to your
publishers and enable replication, and enable it to use the remote
distributor. You will need to configure an administrative link password.
There is a guide in the sample chapter of my book.
http://www.nwsu.com/lowres_replication_ch02.pdf
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"thagen" <thagen@.discussions.microsoft.com> wrote in message
news:3B9C0EF4-E09C-455B-8F5B-9AC1B80BE7D9@.microsoft.com...[vbcol=seagreen]
> Thanks Hilary.
> There is nothing to be done on the Subscriber side?
> And as for the actual steps in moving the Distributor, you have any how-to
> on that?
> Kind Regards,
> Torkild
> "Hilary Cotter" wrote:
|||Yes -thanks for the correction Hilary (snapshot share).
It still makes sense to me though that this should be a shared resource on
the central (shared) array rather than a local node so it can fail over.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com

moving ODBC connections between servers

Hello all,
I was wondering if there is a way to move ODBC connections between SQL servers? We are replacing our current server with newer hardware, and I have pretty much everything figured out except this.
Thanks for any help and/or hints.You can either use Client Network Utility on the client to create an alias, or modify client's registry to forcew an alias, or create an alias in AD for the new server to be known under the old name, or rename the new server to the old name. Take a pick ;)|||I am afraid you lost me.

I am building out an entirely new server to move the databases to, but I also need to move over the ODBC connections listed in the control panel applet.|||Small bump...

Does anyone else have any ideas?|||This is one of those kind of things that cartographers of olde used to mark "Here be dragons"... They didn't know exactly what was there, but they were suspicious that it wasn't good!

The problem is that a machine's ODBC connections depend on drivers, which can depend on... You get the idea. The ODBC connections are pretty much the top layer in a house of cards.

The short answer is that there isn't a really safe and reliable way to move the ODBC connections. It can be done, but unless you know EXACTLY how both of the machines were built, it is probably just a receipe for a disaster. Your best bet is to recreate the ODBC connections manually on the new machine.

-PatP|||This is one of those kind of things that cartographers of olde used to mark "Here be dragons"... They didn't know exactly what was there, but they were suspicious that it wasn't good!

The problem is that a machine's ODBC connections depend on drivers, which can depend on... You get the idea. The ODBC connections are pretty much the top layer in a house of cards.

The short answer is that there isn't a really safe and reliable way to move the ODBC connections. It can be done, but unless you know EXACTLY how both of the machines were built, it is probably just a receipe for a disaster. Your best bet is to recreate the ODBC connections manually on the new machine.

-PatP

Bah! Humbug! Humbug I say! :D

Well, I was hoping to be lazy, but I guess it is not in the cards for me. :(

Thanks for the input folks.|||My initial understanding of your question was, that while moving the server to new HW, you wanted clients NOT to see the difference while retaining their ODBC connections. Now I see that you want to move ODBC Data Sources from your old server to the new one...Doh...You need to go to REGEDIT (be very carefull...oh well, you probably already know) and locate HKEY_LOCAL_MACHINE\SOFTWARE\ODBC. At this point you can either save the entire hive (highlight ODBC and use "Export Registry File..." from Registry menu) or each individual data source (they'll appear in the tree on the left pane as folders) using the same technique. Once the file(-s) is/are exported, you can copy it/them to the new machine and double-click on it/them.

But, as Pat said, watch out for dragons. I'd backup the registry on the target before doing all this, and make sure I can restore successfully. Better yet, test it on a throw-away PC (server or workstation, doesn't matter) and see if you get what you wanted. I've done it several times, but it's your turn now, not mine ;)|||My initial understanding of your question was, that while moving the server to new HW, you wanted clients NOT to see the difference while retaining their ODBC connections. Now I see that you want to move ODBC Data Sources from your old server to the new one...Doh...You need to go to REGEDIT (be very carefull...oh well, you probably already know) and locate HKEY_LOCAL_MACHINE\SOFTWARE\ODBC. At this point you can either save the entire hive (highlight ODBC and use "Export Registry File..." from Registry menu) or each individual data source (they'll appear in the tree on the left pane as folders) using the same technique. Once the file(-s) is/are exported, you can copy it/them to the new machine and double-click on it/them.

But, as Pat said, watch out for dragons. I'd backup the registry on the target before doing all this, and make sure I can restore successfully. Better yet, test it on a throw-away PC (server or workstation, doesn't matter) and see if you get what you wanted. I've done it several times, but it's your turn now, not mine ;)

Aye, I don't mind using my local workstation for the import test to avoid complications in the future.

I did, in fact, see those listings in the registry, my main worry about that was if it did, or did not, transfer security with the connections.|||It transfers EVERYTHING that contains in the registry hive that corresponds to each data source.|||The major problem with this is that some registry settings aren't recognized by earlier driver versions. This copys one part of the registry from one machine to another, without regard to whether the two machines are at the same release/patch levels.

It certainly can be done, but I'd only do this with two servers that I'd built up from bare hardware (so that I knew exactly what was on the machines in the way of ODBC drivers and other files that they rely upon), or if I could run the new one in parallel with the old one for at least 90 days to be sure I hadn't missed some small but crucial detail. I don't think that I'd be willing to risk doing this on a production machine, considering how little time it takes to build the ODBC connections and then I could safely forget about them!

-PatP|||Well, I will say that the OS, SQL and all the patch levels will be the same - corporate spec and all that... The main difference will be the hardware. They are both Compaq(HP) boxes, just one happens to be a nice 8 way machine with 10 gigs of RAM.

:drool:

Moving msdb and model database to a standby machine

Hi
We are planning to do a hardware upgrade for our SQL 2000 STD edition.
I have to activate my standby database.
I am only restoring the standby for my Production database (tg)
But now I need to copy model,msdb DB also to get the jobs.
Can I drop and create the DB from Production using restore methods.
Please let me know.
Tks
Mangesh
"But now I need to copy model..." WHY? model is empty database, template for
new database...
you can restore msdb if you use same version (and sp) and collation on
standby server
1. stop sql agent
2. restore msdb
3. start agent and check agent error log...
Aleksandar Grbic
MCDBA, Senior Database Administrator
"Mangesh Deshpande" wrote:

> Hi
> We are planning to do a hardware upgrade for our SQL 2000 STD edition.
> I have to activate my standby database.
> I am only restoring the standby for my Production database (tg)
> But now I need to copy model,msdb DB also to get the jobs.
> Can I drop and create the DB from Production using restore methods.
> Please let me know.
> Tks
> Mangesh

Moving msdb and model database to a standby machine

Hi
We are planning to do a hardware upgrade for our SQL 2000 STD edition.
I have to activate my standby database.
I am only restoring the standby for my Production database (tg)
But now I need to copy model,msdb DB also to get the jobs.
Can I drop and create the DB from Production using restore methods.
Please let me know.
Tks
Mangesh"But now I need to copy model..." WHY? model is empty database, template for
new database...
you can restore msdb if you use same version (and sp) and collation on
standby server
1. stop sql agent
2. restore msdb
3. start agent and check agent error log...
--
Aleksandar Grbic
MCDBA, Senior Database Administrator
"Mangesh Deshpande" wrote:
> Hi
> We are planning to do a hardware upgrade for our SQL 2000 STD edition.
> I have to activate my standby database.
> I am only restoring the standby for my Production database (tg)
> But now I need to copy model,msdb DB also to get the jobs.
> Can I drop and create the DB from Production using restore methods.
> Please let me know.
> Tks
> Mangesh

Moving msdb and model database to a standby machine

Hi
We are planning to do a hardware upgrade for our SQL 2000 STD edition.
I have to activate my standby database.
I am only restoring the standby for my Production database (tg)
But now I need to copy model,msdb DB also to get the jobs.
Can I drop and create the DB from Production using restore methods.
Please let me know.
Tks
Mangesh"But now I need to copy model..." WHY? model is empty database, template fo
r
new database...
you can restore msdb if you use same version (and sp) and collation on
standby server
1. stop sql agent
2. restore msdb
3. start agent and check agent error log...
Aleksandar Grbic
MCDBA, Senior Database Administrator
"Mangesh Deshpande" wrote:

> Hi
> We are planning to do a hardware upgrade for our SQL 2000 STD edition.
> I have to activate my standby database.
> I am only restoring the standby for my Production database (tg)
> But now I need to copy model,msdb DB also to get the jobs.
> Can I drop and create the DB from Production using restore methods.
> Please let me know.
> Tks
> Mangesh

Moving Log Shipping Monitor

Is it possible to move the log shipping monitor to a different server
without having to re-create the log pairs? hardware on our existing log
shipping monitor server is failing and we need to bring it down,
hopefully for good. We have another server to be used as the monitoring
server and I'm trying to find the best scenario for this change.
Also, is it possible to have more than one log shipping monitor? I'm
thinking of adding some redundency in the event of a server crash.
Thanks,
DannyTry the below steps to change the Monitor Server
1. Script the "Log Shipping Alert - Backup" and "Log Shipping Alert -
Restore" jobs from the current monitor server
2. Run the following query on current monitor server and save the output -
select maintenance_plan_id from msdb.dbo.log_shipping_primaries
select secondary_plan_id from msdb.dbo.log_shipping_secondaries
3. Execute the scripts created in Step 1 on the new monitor server
4. Execute the following stored proc on the new monitor server -
sp_add_log_shipping_primary
@.primary_server_name = '<primary server name>' ,
@.primary_database_name = '<primary database name>'
,@.maintenance_plan_id = '<maintenance Plan ID from first select command
in Step 2>'
,@.backup_threshold = <backup threshold - should be at least 3 times the
freq of
backup job the value is in minutes>
,@.threshold_alert = '14420'
,@.threshold_alert_enabled = 1
,@.planned_outage_start_time = 0
,@.planned_outage_end_time = 0
,@.planned_outage_weekday_mask = 0
5. Execute the following select statement to get the Primary_ID -
select primary_id from msdb.dbo.log_shipping_primaries where
primary_server_name = '<primary server name>' and primary_database_name =
'<primary database name>'
6. Execute the following stored procedure on the new monitor server -
sp_add_log_shipping_secondary @.primary_id = <primary id retrieved in Step 5>
, @.secondary_server_name = '<Secondary Server name>'
, @.secondary_database_name = '<secondary database name>'
, @.secondary_plan_id = '<Comes from second select statement in Step 2>'
, @.copy_enabled = 1
, @.load_enabled = 1
, @.out_of_sync_threshold = <out-of-sync threshold should be at least 3
times
the freq of copy/restore jobs the value is in minutes>
, @.threshold_alert = '14421'
, @.threshold_alert_enabled = 1
, @.planned_outage_start_time = 0
, @.planned_outage_end_time = 0
, @.planned_outage_weekday_mask = 0
7. Execute the following statement on the Primary and secondary servers to
get the current monitor login information. Verify that the customer has 1
for logon type before proceeding with step 8. If they do not have this
field set to 1, tell them
that for the time being we will change the authentication mode to NT and
then we can change this later on once the monitor is completely migrated -
select * from msdb.dbo.log_shipping_monitor
go
8. Execute the following command on both Primary and all secondary servers
to change the monitor information -
delete from msdb.dbo.log_shipping_monitor
go
sp_define_log_shipping_monitor '<New monitor server name>', 1, NULL, 1
go
9. This should complete the migration. Test that the monitor server icon
appears under Management tree (Enterprise Manager). When you click this Log
Shipping Monitor, there should be the new pair that you just added. Once
the jobs are working successfully the last copied/loaded file field will be
updated to
reflect the changes.
Hope this helps
Vishal Gandhi

Moving Log Shipping Monitor

Is it possible to move the log shipping monitor to a different server
without having to re-create the log pairs? Hardware on our existing log
shipping monitor server is failing and we need to bring it down,
hopefully for good. We have another server to be used as the monitoring
server and I'm trying to find the best scenario for this change.
Also, is it possible to have more than one log shipping monitor? I'm
thinking of adding some redundency in the event of a server crash.
Thanks,
DannyTry the below steps to change the Monitor Server
1. Script the "Log Shipping Alert - Backup" and "Log Shipping Alert -
Restore" jobs from the current monitor server
2. Run the following query on current monitor server and save the output -
select maintenance_plan_id from msdb.dbo.log_shipping_primaries
select secondary_plan_id from msdb.dbo.log_shipping_secondaries
3. Execute the scripts created in Step 1 on the new monitor server
4. Execute the following stored proc on the new monitor server -
sp_add_log_shipping_primary
@.primary_server_name = '<primary server name>' ,
@.primary_database_name = '<primary database name>'
,@.maintenance_plan_id = '<maintenance Plan ID from first select command
in Step 2>'
,@.backup_threshold = <backup threshold - should be at least 3 times the
freq of
backup job the value is in minutes>
,@.threshold_alert = '14420'
,@.threshold_alert_enabled = 1
,@.planned_outage_start_time = 0
,@.planned_outage_end_time = 0
,@.planned_outage_weekday_mask = 0
5. Execute the following select statement to get the Primary_ID -
select primary_id from msdb.dbo.log_shipping_primaries where
primary_server_name = '<primary server name>' and primary_database_name ='<primary database name>'
6. Execute the following stored procedure on the new monitor server -
sp_add_log_shipping_secondary @.primary_id = <primary id retrieved in Step 5>
, @.secondary_server_name = '<Secondary Server name>'
, @.secondary_database_name = '<secondary database name>'
, @.secondary_plan_id = '<Comes from second select statement in Step 2>'
, @.copy_enabled = 1
, @.load_enabled = 1
, @.out_of_sync_threshold = <out-of-sync threshold should be at least 3
times
the freq of copy/restore jobs the value is in minutes>
, @.threshold_alert = '14421'
, @.threshold_alert_enabled = 1
, @.planned_outage_start_time = 0
, @.planned_outage_end_time = 0
, @.planned_outage_weekday_mask = 0
7. Execute the following statement on the Primary and secondary servers to
get the current monitor login information. Verify that the customer has 1
for logon type before proceeding with step 8. If they do not have this
field set to 1, tell them
that for the time being we will change the authentication mode to NT and
then we can change this later on once the monitor is completely migrated -
select * from msdb.dbo.log_shipping_monitor
go
8. Execute the following command on both Primary and all secondary servers
to change the monitor information -
delete from msdb.dbo.log_shipping_monitor
go
sp_define_log_shipping_monitor '<New monitor server name>', 1, NULL, 1
go
9. This should complete the migration. Test that the monitor server icon
appears under Management tree (Enterprise Manager). When you click this Log
Shipping Monitor, there should be the new pair that you just added. Once
the jobs are working successfully the last copied/loaded file field will be
updated to
reflect the changes.
Hope this helps
Vishal Gandhi