Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Moving SQL Server 2008 R2 to another Machine Expand / Collapse
Author
Message
Posted Thursday, June 23, 2011 8:11 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, August 27, 2014 1:41 PM
Points: 202, Visits: 568
Hi we are planning to move our SQL Server default instance (only instance running) to another machine as an upgrade.

I don't want to lose my SQL logins and Agent jobs and was wondering if it's as simple as detaching and attaching the system databases (like master, msdb, model, tempdb) .

If there are any articles on SQL Server Central, that'll be helpful too. Thanks!


old machine had Windows 2003 R2 Enterprise x86 OS and SQL Server 2008 R2 Enterprise x86

new machine is Windows 2008 R2 x64 and SQL Server 2008 R2 Enterprise x64

Both Intel Xeon platforms
Post #1130455
Posted Thursday, June 23, 2011 8:40 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, August 18, 2014 2:32 PM
Points: 164, Visits: 435
I've had mixed results when it comes to restoring system databases. Lately I've given up on that and used a few other methods to make migrating/consolidating servers easier.

I have used this KB for moving logins (SQL and Domain) between servers and it has worked quite well. I don't need to know the passwords because it uses the password hash to recreate the accounts, and it uses the same login SIDs so there is less account cleanup afterwards.

http://support.microsoft.com/kb/918992

I usually use SSIS to move jobs between servers, although it won't clean up any server-specific calls. I highly recommend going through each job to check for those.
Post #1130488
Posted Thursday, June 23, 2011 9:12 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Friday, December 19, 2014 11:57 AM
Points: 5,888, Visits: 13,062
you can restore the msdb database but it can quickly become messy.

I would definitely advise against it if you use maintenance plans unless you delete them before the move,

If you use proxies these will need recreating which will mean dropping and recreating jobs.

If SSIS packages are stored in msdb they should use some for of external configuration for the server connections.

If service broker is enabled this will need disabling and re-enabling.

So I would only restore msdb if you have a LOT of SSIS packages which don't need altering for a change in server name.


---------------------------------------------------------------------

Post #1130536
Posted Thursday, June 23, 2011 9:23 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, August 27, 2014 1:41 PM
Points: 202, Visits: 568
george sibbald (6/23/2011)
you can restore the msdb database but it can quickly become messy.

I would definitely advise against it if you use maintenance plans unless you delete them before the move,

If you use proxies these will need recreating which will mean dropping and recreating jobs.

If SSIS packages are stored in msdb they should use some for of external configuration for the server connections.

If service broker is enabled this will need disabling and re-enabling.

So I would only restore msdb if you have a LOT of SSIS packages which don't need altering for a change in server name.


Thanks guys. We don't have any SSIS packages on this server.

I do have maintenance plans.

My main concern is making sure the users and sql agent jobs are moved correctly.

I guess for the sql agent jobs, instead of moving msdb I can just script the jobs correct? thanks
Post #1130555
Posted Thursday, June 23, 2011 9:35 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Friday, December 19, 2014 11:57 AM
Points: 5,888, Visits: 13,062

I do have maintenance plans.

My main concern is making sure the users and sql agent jobs are moved correctly.

I guess for the sql agent jobs, instead of moving msdb I can just script the jobs correct? thanks


that would be your best bet. Remember though maintenance plans create jobs, do not script those out and copy over, these are best recreated from scratch I am afraid.


---------------------------------------------------------------------

Post #1130570
Posted Thursday, June 23, 2011 9:35 AM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Thursday, December 11, 2014 1:06 PM
Points: 4,253, Visits: 4,295
master.dbo (6/23/2011)
[quote]george sibbald (6/23/2011)


We don't have any SSIS packages on this server.

I do have maintenance plans.

My main concern is making sure the users and sql agent jobs are moved correctly.

I guess for the sql agent jobs, instead of moving msdb I can just script the jobs correct? thanks


You can create scripts for the Maintenance Plans, Jobs, Logins and Users and execute them on the Destination Server.


For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Post #1130572
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse