Forum Discussion
Updating File Server OS Best Practice
Hello,
I have a 2008 R2 Server (which is a file share) that I would like to upgrade to 2022. In testing it seems I can create the 2022 server, mirror the files, create the share permissions, rename the old server with appending -old, rename the new server with the name of the old and clients pick it up just fine once DNS is updated. But before I do this in our production environment, I am all ears to suggestions, recommendations, or things I may not have considered. I am aware of in place upgrades, but I like a clean slate.
Give us a bit more info.
Is this a VM or physical? Is the file share on a dedicated drive or the same as the OS?
Let's say if a VM and on a dedicated drive such as "S".
I would build a new 2022 server. Export share info from registry from the old server. (Link provided below.) Then move that S drive from the old VM to the new VM and inport the registry info. You can rename the server to the old server's name or create an CNAME (alias) in DNS, either way original links will work. Down time should be about between 5 - 10 mins.
Did this a few months ago, none of the clients were able to tell anything was changed.
https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/saving-restoring-existing-windows-shares
- Hello,
You should look into Storage Migration Services - it's built-in in Windows Server 2022, and used together with Windows Admin Center, will do the migration job for you - you can still configure everything manually if you wish, but that's a waste of time.
I would avoid reattach an existing disk to a new server - it means you'll also transfer potentially bad configuration with it (partitioning, file system, etc...).Alban1998 These services worked great on newer servers that didn't throw a fit on getting connected, but on the 2008 R2 server with all the prerequisites and updates it wouldn't connect as it kept saying it needed FW 5, when it had 5.1. I built a few 2008 R2 Enterprise servers and updated each of them on and off the domain, different networks, and each time it did the same thing. While it seems like it would be a great tool for the job, moving the disk to the new VM worked great, no issues I have found, and it was quick. I am sure migrating TBs of data would take much longer than moving the disk.
Still a great tool and suggestion. Thank you!
- Sure thing. Just so you know, Storage Migration Service also handles hostname/IP/local accounts migration, check it out ! It's an amazing tool.
Give us a bit more info.
Is this a VM or physical? Is the file share on a dedicated drive or the same as the OS?
Let's say if a VM and on a dedicated drive such as "S".
I would build a new 2022 server. Export share info from registry from the old server. (Link provided below.) Then move that S drive from the old VM to the new VM and inport the registry info. You can rename the server to the old server's name or create an CNAME (alias) in DNS, either way original links will work. Down time should be about between 5 - 10 mins.
Did this a few months ago, none of the clients were able to tell anything was changed.
https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/saving-restoring-existing-windows-sharesFrancisco_M In practice this went really well. I do have concerns about just moving the disk as is, but it worked great and it is probably paranoia of not having done this before and it is all our data. Copying the disk would take quite some time and I don't want to have to mess with differences in data in the hours it would take to copy TBs of data. So, I am going to simply move it as suggested as it worked effortlessly.
Thank you for the suggestion!
Francisco_M it is a VM and the shares are on a separate vmdk.
That sounds like a great idea! I will create a copy of the disk, move it to the new server, make sure everything works and then rename the server. I like it! Going to do this today see how it goes, appreciate the suggestion!
Leavii No, you don't have to create a copy of the disk. It's even easier than that. Use that disk. Since it's a VM. Detach the data disk and use it on new VM. That is if it's shared storage..??
Up to you, yet if it's huge waste of time creating a copy.
Go into VM1 and detach and then go into the new VM2 and attached using same drive letter. Then import the registry ACL info from VM1 and it's all done. That's how I had downtime of 5 - 10 mins.
As always, before any work confirm you have a good backup of the data.
