FILE SERVER MIGRATION

[Koldov]

Due to the upcoming demise of 2012R2 I am looking at options for the migration.

 

However the server in question is a bit of a workhorse (usual small school/small budget single server doing all the roles).

 

It was originally, file server, SIMS server, Print Server, DC, WSUS, etc.

 

Now I have spent a long time getting most of these roles of onto VMs and now I'm left with GBs worth of data with some complex legacy shares involved.

 

Before you reply, please bear in mind I am not going to get Azure or Sharepoint up and running before the October half-term so please don't suggest it.

 

I have a new 2019 Server VM up and running, so just need the best/easiest/quickest way to get all data over and with all share permissions intact.

 

Storage Server Migration looks interesting:

 

https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/migrate-data

 

If I read it correctly it will pretty much do everything for me (even changing the new server to the old server name and I.P.), the thing that will make it more complicated is that as there is only one physical server the VM obviously sits on the host (which is the current file server). I will also have to attempt an in-place upgrade to the host at some point as there is just no way to move the data around anywhere to enable me to flatten it and do a fresh install.

 

Robocopy

Storage Migration Service (new?)

File Server Migration (old?)

DFS

[jthompson]

I'm fairly sure that when using the Storage Migration Service, you can opt out of the cutover aspects that would see the new server being given the old server's IP address, etc.

 

After the data transfer phase, which see data and permissions copied/transferred, you just skip the parts of the server cutover phase that you don't want to perform. It's a whilse since I did it myself, so it might be that after the transfer phase is complete, you have to bail out of the migration as a way to avoid any subsequent steps.

[Koldov]

Thanks, I'm still toying with the idea of allowing the I.P. and/or name to move to the new server.

 

All the shares are mapped via servername, so it would save me redoing them all... and the VMs have a dedicated NIC

 

I'm not sure which would cause more carnage, leaving as is, or changing....?

[BKGarry]

I have recently done this, moved from Physical to Virtual while at it (as in about 3 months ago)

 

I used the Storage Migration Service in Windows Admin Centre. Make sure that you have your current file server fully up to date. The cutover will rename the old file server to something else you specify and give it a new IP address and then rename the new one to the name of the old one and give it that IP address. I did it over about 3 evenings, went without any issues at all, and we still have some staff using Offline files on laptops (almost got rid of that now) and they kept on working.

[dmj]

All the shares are mapped via servername, so it would save me redoing them all...

 

This makes things hard IMO.

I would create a DNS entry for the sharenames that points to the servername. This means when you change things around it's a simple DNS change and you don't need to mess with servernames.

 

To take it a step further, point the DNS name at a loadbalancer so you can scale the number of servers with load and shut them down automatically when you don't need them.

[bknaggs]

Is an in place upgrade to 2019 an option? I’ve done it on several 2012R2 servers this summer and not had any problems.

[DrCheese]

Is an in place upgrade to 2019 an option? I’ve done it on several 2012R2 servers this summer and not had any problems.

 

This - Snapshot it, upgrade it & put feet up. Revert snapshot if it fails.

[Koldov]

Hmmmmm, actually I hadn't really thought of it that way round, as I'm going to need to do an in-place anyway... I just had it in my head that I wanted all the roles onto VMs first. Still the ultimate aim though I guess, but I suppose I could do the upgrade first. I just thought it might be safer to have everything off the server OS before I mess with it... If it does go well it certainly seems like the easiest option.

 

A few questions for those that have actually done it....

 

As it's the physical VM host, should I shut down VMs first or leave them running?

 

As it's the physical VM host there's no 'snapshot' option, it did a full WSB of the C:\ drive last night though... so I guess that would be enough to restore it?

[PotNoodleTech]

In place is only useful if the server itself is ok - if it's 8 yr old and creaking then probably would be a better idea to move it onto your newer VM server - I've used microsofts own physical to virtual migration tool before and it worked a treat but that was 6+ years ago so not sure if that still applies.

 

Done lots of in place upgrades this summer from 2012r2 to 2022 or 2019 and all worked.

[jthompson]

If it were me, I'd give the new server a new name and IP, rename the old one and add the old name as an alias on the new server. That way, all the shares that are expecting the old name will still work, but you'll be able to begin updating shares to use some other naming at your leisure.

[choll]

commenting to follow the post

[KK20]

Alias will work, I did this for years. Moving the shares to a DFS isnt a bad one either, you can chop and change backend storage till your hearts content. Inplace upgrade works just fine, ive even backup restored (using WSB) to new hardware THEN inplace upgraded before now. WSB works fine for backup restore to VM too - I did that with almost all of my CURRENT VMs back when 2008R2 was a thing.

 

Dont forget to demote your DC (after promoting another alternative backup) as DC do not play nicely being inplace upgraded (if it will even let you).

[ITGURU]

Robocopy the data then export/import shares from registry

at same time move to dfs for file shares for future proofing

[Jaan]

When we had to retire an old physical File server to a vm (without downtime) we used DFS and had two servers synchronising data.

 

The initial share names and permission were intact. So \\OldServer\user_docs was also accessible via \\domainname.net\user_docs

 

I was able to create a new virtual file server, have both servers set up with distributed file shares and retire the "old" server once all everything had sync'd over.

 

you'll have to make sure all your shares are pointing to domain name for shares and not a server name.

 

https://www.manageengine.com/products/desktop-central/how-to-setup-windows-dfs-share.html

 

I used this method as i needed to physically retire a server box, otherwise i would have done an inplace update with scheduled downtime.

 

We now use dfs shares with one VM file server (now the old physical box is retired).

 

Only thing i would say, its you learn very quickly that sharing via a server name is a pain in backside. We kept our folder structure the same. so it went from

\\file-server\share_name to \\domain.net\share_name

 

we made the changes to any mapped shares BEFORE we retired the old server so that they were accessible during migration