VMware Cloud Community
HendersonD
Hot Shot
Hot Shot

Migrate file server, Robocopy or migrate VMDKs?

We are running ESXi 6.7 and have a file server running Window Server 2012 R2. The OS is on the C: drive and the shares are on the E: and F: drives. The shares are using NTFS. We would like to migrate this to a new VM running Windows Server 2019. We have two choices of how to handle this migration. We do use DFS namespace which should make re-pointing things after migration easier.

  1. Make new file shares on the new server and use Robocopy to migrate the data. The first run of Robocopy will take some time but subsequent runs go quick since it just copies changed files. Do one last run of Robocopy over a weekend and change DFS to repoint things
  2. Unattach the VMDKs from the old server and then attach them to the new server using a method like this
    https://ssh.guru/q-10-file-server-migration-using-vmware/

Any suggestions on which method to use? We will not be using ReFS on the new file server since ReFS still does not support everything that is supported under NTFS including not supporting disk quotas.

Reply
0 Kudos
7 Replies
IRIX201110141
Champion
Champion

Hi,

if you already have DFS than you can use DFS Replication rather than Robocopy for "migrating" the data to a new server.

But when it is already a Windows 2012 and the NTFS is healthy you also re-use the existing VMDKs in the new VM. But again.. you must touch DFS and modify the DFS tree when your new VM have another windows name.

Regards,
Joerg

Reply
0 Kudos
HendersonD
Hot Shot
Hot Shot

I have never used DFS Relication but have used Robocopy many times so if I go the route of copying the data I will stick with Robocopy

Are there any difference in NTFS versions between Windows Server 2012 R2 and Windows Server 2019?

If there are some substantial differences then copying the data using Robocopy might the route to go

If there are no differences, then dettach/attach VMDKs would be quicker

Reply
0 Kudos
crazycen
Enthusiast
Enthusiast

It is recommended that you copy VMDK by browsing the Datastore or SSH to ESXI, copy the VMDK file to the server2019 directory, and then manually add the hard disk.That's way faster than Robocopy!

vExpert | VCIX | VCP-DCV | VCAP-DCV | VCP-NV
Reply
0 Kudos
HendersonD
Hot Shot
Hot Shot

Two questions

  1. Would this method of moving the VMDKs work fine?
    https://ssh.guru/q-10-file-server-migration-using-vmware/
  2. Are this sizable difference in NTFS under Server 2019 vs. Server 2012 R2 where creating new volumes/drives under Sever 2019 and migrating using Robocopy is the way to go
Reply
0 Kudos
IRIX201110141
Champion
Champion

A newer Windows Version have no problem with an older NTFS and we have done such migration with just "adding" the old existing VMDK to a new fresh VM a couple of times.  There is no answer to the question about what MS have added as features or what happens when enabling Dedup for example on an old ntfs.

Keep in mind that a lot of FileLevelRestore method from all of the Backup vendors works in that way that they just mount an older Windows/NTFS into a current one. So they do the same as you do.

Whats the article from above not covered are the information about the \\shares. The Windows OS keep that information in the windows registry and not as part of the filesystem. So you have to export the stuff from the old system and import the reg keys into the new one or you have to manualy create all shares again.  But both a simple steps.

Regards,

Joerg

Reply
0 Kudos
HendersonD
Hot Shot
Hot Shot

So DFS Namespace has nothing to do with share information, it is just used to repoint things. I still need to export the proper registry keys from the old server and import them into the new server, correct?

Reply
0 Kudos
IRIX201110141
Champion
Champion

Correct.

The DFS "hide" the exact  \\foo\share  and make it interchangeable when needed. If your new fileserver VM get the same servername as your old one than no changes on the DFS are needed.  So when you like you can follow your RoboCopy solution by copy all data to a new and fresh VM with same\different share names but different server name and when your copy(and last sync) is finished you can re-point your DFS Tree entry to the new \\newvm\share. From a client perspective there is no different because the DFS path looks like it looks always... one of the benefits of DFS.

But it sounds its more a Microsoft question than a VMware related one.

Regards,
Joerg

Reply
0 Kudos