Forum Discussion
Updating File Server OS Best Practice
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
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.
- Francisco_M provided the easiest solution, nothing dirty about it. Separate data volume, separate permissions, nothing gets destroyed in the process, so really no danger of any kind
- Imho, that's quite "quick and dirty" way to do it, and I would strongly recommend against it - that's how people endep in trouble with partitioning, obsolete ReFS versions etc...especially when migrating from 2008 R2 to 2022, which is a huge technical gap.
Alban1998 For me, this being a process I hadn't thought of I simply want to test it. I have nothing to lose as I am not removing the disk from the server but going to test with a copy. It is not something I have thought of or done before, and I feel it is an interesting solution. Keep the discussion going though because I am here seeking information.
Testing with a copy of the disk will trigger the same issues as moving the disk - by examples, you may end up trying to connect a MBR-based disk to your newly build GPT/UEFI server, which is less than ideal.
You need to consider what happens at the operating system layer and not only the virtualization layer - it is simply not that easy.
And that's where Storage Migration Service will help you by taking of pretty much all the stuff.
It's important to keep in touch with newer, supported, efficient tools by Microsoft rather than relying on very old, clunky methods which may bring unexpected issues with them, unless circumstances require it (which is not the case here).
Francisco_M No time at all. I already have backups. I would attach a copy so I would have no down time moving from one to another, testing, trying it out, etc...
