Windows Server File Migration Service Guide
Starting from Windows server 2019 we see the introduction of the Windows server file migration service feature. This feature allows you to easily migrate a file server, all of its file shares and folder permissions to new physical or virtual server.
This feature will sync all file shares to a new server, set the same permissions then when you are ready it will assume the old servers IP address and name.
The idea is to make migrating large file servers with complicated permission sets to new servers super easy and end users wont know anything has happened. All of their mapped drives and file and folder shortcuts will work as before. Amazing!
Whats also nice is that you can sync all of the data to azure storage in the background over several days or weeks and cut over to cloud hosted file services.
This is one of the longest guides I’ve written but hopefully it gives you a very in depth guide on how it works and how to migrate an example server to a new one. In this example we migrate an old 2012 member file server to a fresh 2019 installation. Both servers are member servers in the same domain and both are domain joined from the start.
First install all updates to the target server, keep rebooting and installing until its fully updated then install the ‘Windows Admin Center’ application. This application is built to manage servers on your network and is required to manage the file migration service feature.
Install on the target server, accept the terms and press ‘Next’.
The Admin Center is web based to click the link to open it in a browser and press ‘Finish’.
Press ‘Add’ to add both the source and target servers.
Now click ‘Settings’ from the bottom left corner.
Locate ‘Extensions’ from the left hand panel, Click ‘Available extensions’ search for ‘storage’ then click ‘Windows Server Storage Migration Service’ and click ‘Install’.
Once the extension installs, head back to the main screen of the Admin center and click into the target server. Click on ‘Storage Migration Service’ from the left hand menu. Now click ‘Install’ to install the ‘Storage Migration Service’ feature to the target server.
Once the installation completes close the welcome screen.
Time to take a look at the source file server in this lab example. Here the server has five shares and each share has its own set of permissions and different security groups assigned. All of these shares, including the security groups and permissions will get copied to the target server.
Ok, back on the target files server and open up ‘Windows Admin Center’. Click through to manage the target file server and click on ‘Storage Migration Service’ from the left hand menu. Click on ‘New Job’ to start setting up a new migration job.
Give the job a suitable name and press ‘OK’. Notice here you can migrate windows servers, clusters and Linux servers.
Enter the administrator source file server credentials. Here I enter the domain admin credentials and press ‘Next’.
Click on ‘Add a device’ and add the source file server.
Click on the server and click ‘Start scan’.
The scan should complete without any issues and it will list all of the file shares, their type, number of files and size.
Next enter the admin credentials of the target server. In this case I enter the domain admin details again and press ‘Next.
Now specify the destination file server. In this case I enter the FQDN of the target server which in this case is the server we are running the migration from. Note here I select ‘Use an existing server or VM’ but you also have the option to ‘Create a new Azure VM’ to transfer to. Click ‘Next’.
Next you will need to map the share volumes to the desired volumes on the target server. In my case I choose to keep the file shares on the C drive. In your case you will likely want your shares on a second D: partition.
Select the options appropriate for you but see below the options I used in the lab.
Next you will need to run a quick validation check to ensure everything connects correctly. Click on ‘Validate’.
If all goes well the validation check will pass. If it fails its likely due to invalid credentials used.
Now click ‘Start transfer’ to begin copying the files in the background. It’s worth mentioning here that nothing changes on the source file server yet. This process simply gets a copy of the data and permissions setup on the target server. Later on you will then do a final catch up sync and rename the servers.
If all is good each of the shares will copy successfully. You can view the progress by clicking on the ‘SMB detail’ tab.
OK we are now ready to transfer the differences and rename the servers. This is the cut over point so you will need to do this out of hours so there is no one accessing files because the servers will be down during this process. Assuming not too many files have changed this should all complete within an hour but usually a lot less, it just depends on the number and size of files changed or added since the initial copy completed. Click ‘Transfer differences’.
Click ‘Transfer differences’ again to confirm and press ‘Next’ once complete.
Now you can reenter the source file server credentials or just click ‘Next’ to use the stored ones from previous steps.
Now we need to specify which IP address will be used from the source server. In this case I select Adaptor 2 with IP 10.10.0.20. I enter a new IP address which will be used on the source file server: 10.10.0.40. I also specify which adaptor on the target file server the IP address will be assigned to.
The idea here is that the IP address used on the old server will be changed and it’s IP put onto the new server. The old server then gets the new IP we specify here. This is one of the tricks which allows end users to not notice the file shares have changed. Click ‘Next’.
Now you can specify the cut over timeout period, I just keep the defaults and press ‘Next’.
Click ‘Validate’ to ensure everything connects and works as expected. Press ‘Next’.
Now click ‘Start cut over’. The source and target servers may reboot multiple times at this point. Just leave them to it.
Once the process completes the source server will now have a new random name and the IP address we specified during the setup. The server still has its file shares mounted so they are still there if you need to roll back.
On the target server you can see its now assumed the name and IP address of the old server. Now any clients will connect to this new server and no configuration changes will be needed!
If you get here then your migration is complete and you can decommission the old file server in a few days or weeks.
If something went wrong, simply rename the target and source servers back to their originals and update the IP addresses. You can then go through and run the job again once any errors have been resolved.
In my lab example everything cut over as expected and the file shares along with their data and permissions were exactly as per the source server.
Hope you find this article useful!