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.
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.
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.
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
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!
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.
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?
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.