Swapping out 2003 file server cluster for 2008 standalone file server without changing name or IP
I have an immediate need to replace a pair of 2003 Enterprise servers acting as a clustered file server with a standalone 2008 file server.
We've been migrating user data off of this cluster, but the underlying disk is at risk.
I've done this before with file servers (and a SQL server) by doing the following:
1. bring up the new server and storage and join to the domain
2. restore seed data from last full backup.
3. sync data from production system to new system
4. Export share maps from production system registry
5. Import share maps on "new" file server
6. disconnect production system
7. assign IP from the (now old) production server to the new production server (to accomodate any raw ip mapping)
8. drop the NEW system from the domain, change the name to match the OLD system, and re-add to the domain
9. reboot
The above steps have worked flawlessly in the past with single servers and even a SQL server. What I'm uneasy about is the way that server 2003 clusters interact with DNS and AD. Specifically the way they handle the cluster object vs. unique cluster member objects, and handling a roll-back scenario.
Before we begin, I'll be shutting down the passive node. Is there anything else I need to know about how the cluster object is treated in AD? With the active node powered on but disconnected from the network, will I still be able to join the new standalone server to the domain using the same name?
If not, are there specific objects I need to remove from AD prior to joining the new server? I'd like to be able to shut down the new system, restore AD objects, and reconnect the legacy system in a 'worst case scenario' situation.
Thanks!
We've been migrating user data off of this cluster, but the underlying disk is at risk.
I've done this before with file servers (and a SQL server) by doing the following:
1. bring up the new server and storage and join to the domain
2. restore seed data from last full backup.
3. sync data from production system to new system
4. Export share maps from production system registry
5. Import share maps on "new" file server
6. disconnect production system
7. assign IP from the (now old) production server to the new production server (to accomodate any raw ip mapping)
8. drop the NEW system from the domain, change the name to match the OLD system, and re-add to the domain
9. reboot
The above steps have worked flawlessly in the past with single servers and even a SQL server. What I'm uneasy about is the way that server 2003 clusters interact with DNS and AD. Specifically the way they handle the cluster object vs. unique cluster member objects, and handling a roll-back scenario.
Before we begin, I'll be shutting down the passive node. Is there anything else I need to know about how the cluster object is treated in AD? With the active node powered on but disconnected from the network, will I still be able to join the new standalone server to the domain using the same name?
If not, are there specific objects I need to remove from AD prior to joining the new server? I'd like to be able to shut down the new system, restore AD objects, and reconnect the legacy system in a 'worst case scenario' situation.
Thanks!
ASKER
Wouldn't removing the nodes from AD break my cluster configuration?
What would be the best procedure to quickly roll back to the 2003 cluster if necessary? I'd prefer not to have to rebuild the cluster configuration.
What would be the best procedure to quickly roll back to the 2003 cluster if necessary? I'd prefer not to have to rebuild the cluster configuration.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the input. This is scheduled for next week so I'll followup at that time.
ASKER
Okay, so we postponed a bit... We had about 700 users to schedule around.
Anyway, things went pretty flawlessly. We had two shares (out of around 90) that ended up missing permissions, but we did not diagnose. Just re-applied.
Did not test rollback scenario because thankfully we did not have to.
Many thanks!
Anyway, things went pretty flawlessly. We had two shares (out of around 90) that ended up missing permissions, but we did not diagnose. Just re-applied.
Did not test rollback scenario because thankfully we did not have to.
Many thanks!
Exporting and importing registry items from W2K3 to W2012 is not recommended especially for migrating from a cluster to standalone computer. Better use script to rebuild the network shares.
> With the active node powered on but disconnected from the network, will I still be able to join the new standalone server to the domain using the same name?
NO. the cluster nodes must first quit from the AD before another computer joining in the domain using the same computer name.
> If not, are there specific objects I need to
remove from AD prior to joining the new
server?
given above.
> I'd like to be able to shut down the new system, restore AD objects, and reconnect the legacy system in a 'worst case scenario' situation.
that's OK once all objects of the new system have been removed from the AD.
good luck.