 | |
Replace hardware with other architecture (IA64 -> X64)
microsoft.public.sqlserver.clustering microsoft.public.sqlserver.clustering
 |
| | Thread Tools | Display Modes |
#41
 
| |||
| |||
|
Re: Replace hardware with other architecture (IA64 -> X64) -
05-09-2008
, 08:08 AM
|
No problem. New queestions! I thougth it would be unsupported, that's the reason for the original post. Where is it documented that it's not suppoprted? I'll only found it in unoffiical documents. I intend to use sp_help_revlogin for logins. But I don't get what you mean by pre-move jobs. As the new instance will have the same virtual server name as the old one I can't have them running at the same time. That's why I'll script the jobs aswell. The name is importent, since it's more than 3000 winxp pointing to it. /Peter On Thu, 8 May 2008 10:21:00 -0400, "Geoff N. Hiten" SQLCraftsman (AT) gmail (DOT) com> wrotc: Sorry for the lapse. Moving master and msdb across architectures is NOT supported or recommended. You can pre-move the jobs before the final migration. Logins can be moved easily using this KB article: How to transfer logins and passwords between instances of SQL Server http://support.microsoft.com/kb/246133/en-us |
#42
| |||
| |||
|
|
You can't use the same virtual server name. Active Directory won't let you. You can create a new virtual server name and use DNS to redirect the old name to the new location. Unless your clients are pointing to the old cluster via IP address, this works just fine. Go ahead and script the jobs and set them up on the new server. Set them to disabled. Write a script to enable them when you go live. The idea is ti have as minimal downtime as possible and to have everythign completely scripted so all you are doing is executing scripts, not clicking GUI screens. |
#43
| |||
| |||
|
|
You can't use the same virtual server name. Active Directory won't let you. You can create a new virtual server name and use DNS to redirect the old name to the new location. Unless your clients are pointing to the old cluster via IP address, this works just fine. Go ahead and script the jobs and set them up on the new server. Set them to disabled. Write a script to enable them when you go live. The idea is ti have as minimal downtime as possible and to have everythign completely scripted so all you are doing is executing scripts, not clicking GUI screens. |
#44
| |||
| |||
|
|
You can't use the same virtual server name. Active Directory won't let you. You can create a new virtual server name and use DNS to redirect the old name to the new location. Unless your clients are pointing to the old cluster via IP address, this works just fine. Go ahead and script the jobs and set them up on the new server. Set them to disabled. Write a script to enable them when you go live. The idea is ti have as minimal downtime as possible and to have everythign completely scripted so all you are doing is executing scripts, not clicking GUI screens. |
#45
| |||
| |||
|
|
You can't use the same virtual server name. Active Directory won't let you. You can create a new virtual server name and use DNS to redirect the old name to the new location. Unless your clients are pointing to the old cluster via IP address, this works just fine. Go ahead and script the jobs and set them up on the new server. Set them to disabled. Write a script to enable them when you go live. The idea is ti have as minimal downtime as possible and to have everythign completely scripted so all you are doing is executing scripts, not clicking GUI screens. |
#46
| |||
| |||
|
|
You can't use the same virtual server name. Active Directory won't let you. You can create a new virtual server name and use DNS to redirect the old name to the new location. Unless your clients are pointing to the old cluster via IP address, this works just fine. Go ahead and script the jobs and set them up on the new server. Set them to disabled. Write a script to enable them when you go live. The idea is ti have as minimal downtime as possible and to have everythign completely scripted so all you are doing is executing scripts, not clicking GUI screens. |
#47
| |||
| |||
|
|
You can't use the same virtual server name. Active Directory won't let you. You can create a new virtual server name and use DNS to redirect the old name to the new location. Unless your clients are pointing to the old cluster via IP address, this works just fine. Go ahead and script the jobs and set them up on the new server. Set them to disabled. Write a script to enable them when you go live. The idea is ti have as minimal downtime as possible and to have everythign completely scripted so all you are doing is executing scripts, not clicking GUI screens. |
#48
| |||
| |||
|
|
You can't use the same virtual server name. Active Directory won't let you. You can create a new virtual server name and use DNS to redirect the old name to the new location. Unless your clients are pointing to the old cluster via IP address, this works just fine. Go ahead and script the jobs and set them up on the new server. Set them to disabled. Write a script to enable them when you go live. The idea is ti have as minimal downtime as possible and to have everythign completely scripted so all you are doing is executing scripts, not clicking GUI screens. |
#49
| |||
| |||
|
|
You can't use the same virtual server name. Active Directory won't let you. You can create a new virtual server name and use DNS to redirect the old name to the new location. Unless your clients are pointing to the old cluster via IP address, this works just fine. Go ahead and script the jobs and set them up on the new server. Set them to disabled. Write a script to enable them when you go live. The idea is ti have as minimal downtime as possible and to have everythign completely scripted so all you are doing is executing scripts, not clicking GUI screens. |
#50
| |||
| |||
|
|
You can't use the same virtual server name. Active Directory won't let you. You can create a new virtual server name and use DNS to redirect the old name to the new location. Unless your clients are pointing to the old cluster via IP address, this works just fine. Go ahead and script the jobs and set them up on the new server. Set them to disabled. Write a script to enable them when you go live. The idea is ti have as minimal downtime as possible and to have everythign completely scripted so all you are doing is executing scripts, not clicking GUI screens. |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.