File Server Migration to Server 2012 (Part 2)
In part 2 of migrating our main File Server from Windows Server 2008 to Windows Server 2012, we'll look at the logistics of the migration. There's 2 ways that I've identified of going about the move; One-Few-Many and All-At-Once.
One-Few-Many
Under almost all circumstances, whenever you're making a change that's going to affect users or their data, it's generally ill-advised to make one big sweeping change. If something goes wrong, it could be a show-stopper to all of your users. Now everyone's sitting around waiting for you to revert the change you just made. Shame. If you did this during production hours (aka, middle of the day) then double shame.
With the One-Few-Many approach, you're making the same change for one person (usually yourself). If you can't test just yourself then you can at least choose a small group to make the change for. If your change is successful then you can move on to the next larger group, so on and so on. If your change is unsuccessful then you've only briefly interrupted one person or a small group of people. You can revert the change, and go back to the drawing board. This is how most of your changes will be made and new features rolled out in your SysAdmin career.
For our main File Server, were we going to go with the One-Few-Many migration plan, we would need to assign a different hostname and IP address and pick the smallest group of users (which is actually a small department consisting of 4 users). We'd disconnect their current volume on the SAN, export the registry keys from the old file server, reconnect their volume from the SAN on the new file server, import the registry keys, and reboot the server. All of their data will still be there (file and directory permissions intact), all of their shares and share permissions will be there as well. As long as their login scripts are updated to reference the hostname on the new file server rather than the old hostname, when those 4 users login in the morning, their normal drives will be created at logon just like before.
All-At-Once
With the All-At-Once method, just as I'd described in Part 1, we'd disconnect all of the LUNs from the SAN and export the registry keys from the old server, reconnect the LUNs and import the registry keys on the new server, reboot and BAM; New file server is up and running. Provided the new server had the same IP address and hostname, anything that references our old file server (such as all of the login scripts we have for all of our users) will still work and won't need to be changed.
Al though it goes against the conventional wisdom of a staged migration approach like we discussed above, it's less work and easier to revert if there's any issues. It takes about 10 minutes at most to swap the SAN connections and move the proper registry keys. It would take a lot longer and involve far more work to do that for each volume one at a time, editing each users's login script and changing anything else that references the old file server to call the new file server. After actually discussing both options with my boss and demonstrating how simple moving everything is at once (and how it's the same steps in reverse should we need to revert for any reason), we've settled on going with the All-At-Once method.
I'll come back and update this once I actually perform the "migration". In the next part, I'll discuss the features we're looking to enable on our new file server at a greater length including configuration instructions for some of it.
One-Few-Many
Under almost all circumstances, whenever you're making a change that's going to affect users or their data, it's generally ill-advised to make one big sweeping change. If something goes wrong, it could be a show-stopper to all of your users. Now everyone's sitting around waiting for you to revert the change you just made. Shame. If you did this during production hours (aka, middle of the day) then double shame.
With the One-Few-Many approach, you're making the same change for one person (usually yourself). If you can't test just yourself then you can at least choose a small group to make the change for. If your change is successful then you can move on to the next larger group, so on and so on. If your change is unsuccessful then you've only briefly interrupted one person or a small group of people. You can revert the change, and go back to the drawing board. This is how most of your changes will be made and new features rolled out in your SysAdmin career.
For our main File Server, were we going to go with the One-Few-Many migration plan, we would need to assign a different hostname and IP address and pick the smallest group of users (which is actually a small department consisting of 4 users). We'd disconnect their current volume on the SAN, export the registry keys from the old file server, reconnect their volume from the SAN on the new file server, import the registry keys, and reboot the server. All of their data will still be there (file and directory permissions intact), all of their shares and share permissions will be there as well. As long as their login scripts are updated to reference the hostname on the new file server rather than the old hostname, when those 4 users login in the morning, their normal drives will be created at logon just like before.
All-At-Once
With the All-At-Once method, just as I'd described in Part 1, we'd disconnect all of the LUNs from the SAN and export the registry keys from the old server, reconnect the LUNs and import the registry keys on the new server, reboot and BAM; New file server is up and running. Provided the new server had the same IP address and hostname, anything that references our old file server (such as all of the login scripts we have for all of our users) will still work and won't need to be changed.
Al though it goes against the conventional wisdom of a staged migration approach like we discussed above, it's less work and easier to revert if there's any issues. It takes about 10 minutes at most to swap the SAN connections and move the proper registry keys. It would take a lot longer and involve far more work to do that for each volume one at a time, editing each users's login script and changing anything else that references the old file server to call the new file server. After actually discussing both options with my boss and demonstrating how simple moving everything is at once (and how it's the same steps in reverse should we need to revert for any reason), we've settled on going with the All-At-Once method.
I'll come back and update this once I actually perform the "migration". In the next part, I'll discuss the features we're looking to enable on our new file server at a greater length including configuration instructions for some of it.
Comments
Post a Comment