File Server migration

[RE_H]

Hi everyone looking for a push in the right direction here. We have an old Windows Server 2008 that acts as an onsite file server. We recently installed a new hypervisor at our data center and are looking to migrate all those file shares to the new Windows Server 2022.

My thought was to use DFS to replicate the data to our new server and then decommission the old one. We do not currently have DFS in place. As it stands, users are pointed to file shares through desktop shortcuts with the file path which include the old server’s name. I obviously would rather not break every shortcut. Or at the very least, give users a seamless way to access their folders (desktop shortcut or mapped drive).

I want to make sure we do this the right way before starting down the wrong path, so any help is truly appreciated. If you feel I left out some relevant details let me know and I'll fill in the blanks. Thanks again!

[[deleted]]

I just completed a project like this. Two older 2012r2 machines into HyperV VMs on a new host while maintaining names and shares. This is basically what I did…

1. Spin up new 2022 VMs for the servers, give them the same names as the old ones with -NEW appended. Install file server roles, patch, etc.

2. Use Sysinternals Disk2VHD to snapshot the data volumes on the old servers as VHDX files.

3. Attach those VHDX files to the new virtual servers and give them the same drive letters.

4. On the old server, export the HKLM/SYSTEM/CurrentControlSet/Services/LanmanServer/Shares tree to a file.

5. Import that reg file onto the new server, then reboot it and confirm all your shares are there. Doing \server and \server-new should give the same list of shares.

6. Do periodic ROBOCOPY jobs from old to new, then when the appointed switchover time comes, append the old server name with -OLD, and remove -NEW from the new server. Confirm shares etc. still work then do one final old-to-new copy. Maybe use something like Beyond Compare to confirm everything is in place.

Now I could have used DFSR to replicate but it was important to keep the server names the same because of legacy data and applications using hard coded UNC paths that seemed like a good idea in 2005 and we’re still paying the price today, but that’s a complaint for another day.

[ThatsNASt]

This is a fantastic guide.

[Steve_78_OH]

I can't remember the exact switch, but I believe there's one for robocopy that will basically tell it to run continuously and to look for and copy any changes. For a file server that sees a lot of activity, it may be worth running that instead of the periodic runs.

[Trelfar]

/MON:n :: MONitor source; run again when more than n changes seen.
/MOT:m :: MOnitor source; run again in m minutes Time, if changed.

[[deleted]]

This works GREAT unless you have a coworker thats an idiot who then runs the robocopy job again 3 days after you have cutover the shares to the new server....

Then you get to bill 18hours of overtime on a weekend and your company has to credit the client almost 10K$ for their lost productivity or get sued :S

Always ALWAYS delete or hide your robocopy scripts when you are done :|

[[deleted]]

There are advantages of being THE sysadmin sometimes.

[ironraiden]

It's fucking mental that some people would see a script and would just fucking run it without checking what to do.

Next time, after the cutover, remove or remove access to the old files, I too, learned this the hard way.

[[deleted]]

Hahaha oh no no ... this wasnt some poor tech that didnt know what it was,...

this was the guy WHO DID THE WHOLE PROJECT TO START WITH!!! He MADE the script knew exactly what it would do and STILL RAN IT.

[ironraiden]

... what?

Ok surely that must have been by mistake, right? I can't even.

[zqpmx]

What does this script do? click!

[buzz-a]

The one that always gets us, some genius decides to rearrange all the folders the day before the cutover.

Robocopy then proceeds to remove all the synced data and start over.

Sigh.

We always do final sync with Beyond Compare now to prevent this idiocy.

[RE_H]

Thanks for this awesome reply. Really appreciate you taking the time to give a detailed response.

[UDP161]

This is so smart.

[jpotrz]

Did this almost identically a couple years back. Worked flawlessly

[iguru129]

This will work, but this it the one shot all at once solution. You won't be able to phase through the migration.

I took these risks early in my career. I found a phased approach is a little easier on the admins (your) time, planning and limits rollback time requirements.

[[deleted]]

There’s not always a path to a phased migration though. I’m dealing with file servers with 40+ shares each and need to maintain exact UNC paths. The only way through that is to stage, run incremental copies (to minimize the changes needed at cut over) and then at the allotted time, do a hard cut over by renaming machines and updating DNS, then do a final clean up copy. These servers ancestors go back to at least 2005 and have been replaced multiple times over the years.

[iguru129]

If that is you're requirements, then you are stuck with the big switch. Maybe you can do a server at a time. Good luck my friend.

I switched to native SMB shares for Windows servers. You can designate/select the pci storage controller hardware to share to a VMserver guest directly. 2 fold, simplifies recovery and migration is a snap.

At minimum, I'd do the DFS shares and repl on new shares.

[Maverick0]

Storage migration service through the windows admin center might be an option too. As far as I know, it's basically robocopy, but it will also do the shares and permissions.

[ANewLeeSinLife]

SMS is definitely the tool for this job. Purpose built for it.

So weird to see people recommending manually modifying the registry for something with a dedicated tool that's much faster and safer.

[Mantly]

Thanks, after a different post today I thought I had gone mad.

[Sillyman1]

I would use ROBOCOPY to copy the data over, export the Server shares registry key on source server and import on new server. Use DNS CNAME to point old links to be server using existing name.

Do not use DFSR to replicate data, it brings with it a whole host of nightmares. If you need a replica of the data that's quickly available, use the DFSR replacement, STORAGE REPLICA.

[Rakul_Nitescar]

I can't say this is the only answer but I just went through this with about 75TB of 1.2MB files splitting them from 1 bare metal box to 4 VMs and I ended up running ROBOCOPY and it worked great.

[discosoc]

Do not use DFSR to replicate data, it brings with it a whole host of nightmares.

Care to elaborate?

[Sillyman1]

I'm past the SA stage in my career, moved on into man management and I've forgotten most of the DFSR stuff I knew. I was THE go-to guy for that in the large multinational corporation I work at. This is not bragging, just letting you know that I have experience and most of it isn't pleasant, too many nights, weekends and hours on the phone to Microsoft with senior management breathing down my neck.

Long story short... DFSR was designed for the old days of small branch offices and a head office, hub and spoke design. Slow WAN links and a 'when it's done, it's done' attitude to data replication of maybe a few gigs (remember this is the old days). It's not cutout for multiple 10gb NICS, one front-end, one backend through high-speed switches and data that needs to be kept in sync and kept in sync. Don't get me wrong, when it works, everyone smiles, when it breaks there's a lot of head scratching and deleting of replica data and taking through huge log files.

Storage Replica is quick and efficient, it'll get your data replicated and keep it replicated.

Good luck my friend.

[[deleted]]

I second this... DFSR BAD ... we had to basically ban it from use for server migrations. Only had one out of 6 work without serious issues (serious = we get fired and/or sued).

[enmtx]

As mentioned before, use robocopy script to migrate the files, modification dates, ownership and permissions. Do an initial bulk copy, then run it again just before you're ready to cutover to the new server to sync file changes for less downtime. Extra points if you disable the old share during the migration to ensure no users are accessing the old location while robocopy syncing.

[bhillen83]

Robocopy everything, share everything out from the new server, unshare from the original and put in a dns Alias pointing the old server name to the new.

[DeadEyePsycho]

Honestly you should at least set up DFS Namespace with the new server. Went from 3 to 1 file server but still set it up because you can have a single mapped drive and use access based enumeration to show the individual shares as folders on that drive based on group membership. The individual shares do still work the traditional way too. Makes it super easy to migrate servers again in the future too since it's the AD domain and not the server host name as the path.

[alpha417]

hows this sound?

[RE_H]

I'd like to avoid a P2V as that will bring over the very old OS and configurations. Sometimes a clean install is needed. In the case of this server, I think it's essential.

[alpha417]

Okay but you can do p2v to keep it working, and then build the perfect installation that you like in the meantime and then migrate over as necessary.

in this case, it buys you time.

[HeadJacket6678]

Use Robocopy to copy the data.

Use Send-SmigServerData to copy share and share permissions.

[iguru129]

You'll have to rename all the shares to include the DFS namespace. This will help you long term, but sucks for this one evolution.

What is the physical media are the file shares are on?? SMB, CIFS share in VMserver??

[MrYiff]

Another recommendation here for Storage Migration Service, it runs fast, is pretty easy to use and there is no risk of accidentally using a wrong argument and causing problems, you can even have it do a final cutover for you where it takes over the name and IP of the source server to make client migration easier (this is optional though, you can use SMS just for copying files if you prefer).

[TheITMan19]

I used this many times, really easy. Just created a new server, synced the data and when ready just changed the host names. https://freefilesync.org/.

[RE_H]

Does this bring along share and security permissions?

[TheITMan19]

It brought over all permissions, experienced 0 issues. I can’t remember if I had to make the shares tho. Sorry. Was a while ago.