Over the years I have seen so many approaches to migrating Windows file server shares to new servers. Most methods are valid and some are down right brilliant uses of native tools. I have an affinity for migrating shares in a specific way that does not utilize the native tools. It has worked really well for me over the years and I want to share it with all those out there that might need help with shares that are problematic.
You may wonder what I mean by problematic. In my experience problematic folder shares are shares that include path too long files/folders, file/folder names with strange characters, and/or a really large number of files/folders (like hundreds of thousands or more). These issues can crash tools like Windows Explorer shell, Robocopy, RichCopy, etc. There are a number of free utilities out there that promise to do this as well, however, I have seen many of these tools fail when I needed them the most. Plus, most of these tools are a pain to operate or have complex interfaces.
That is where the File Server Migration Toolkit comes in. I know what you are thinking. Man, this utility is old. Also, the official Microsoft stance is that it only supports 2003-2008r2 server. True that is does not officially support 2012 or 2012r2, however, it does work the same for both. It just requires some added work than the other operating systems supported. But wait, doesn’t 2012r2 have built in tools to migrate file server shares? Yes it does and it works well. It requires some powershell management however and has no GUI interface. I personally like having a visual view of what is migrating and of the migration status. I hope this still works with 2016 Server, but if it doesn’t I will post about the new migration tools.
Ideal Migration Scenario for FSMT
-File Servers are in the same domain
-Shares are not nested. Nested Shares are tough to manage with FSMT but can be migrated. It is just not ideal to have them in this scenario.
Using FSMT requires that you setup the toolkit on the destination server and link it to the source server. For a 2012/2012r2 destination server, you need to enable .net 3.5. For instructions on how to do that go here. After you install .net 3.5, you need to install FSMT.
Next we need to start a migration project.
Set the name of the project and where you want to save the project configuration.
Next decide whether or not you are using DFS server consolidation migration. I have never used this for DFS migration but it is supported.
Next we set the location for the destination shares. Choose the volume root for the most simple migration and to preserve some paths from the old server. If you need to add a folder as the root of the shares do it before you finalize this part.
Once this is done it is time to add source servers to the migration. Click Add Server… in the bottom left.
Enter the hostname for the server.
Once the server is added we need to take a look at the migration settings for this server. Click on the server to see the settings. There are three check boxes that need to be addressed.
The first is the setting to turn off the source shares when the migration is finished. This one can save you a lot of heartache when you are done moving the data. I have had some applications that still accessed the old shares after a migration because I forgot to turn off the old shares. I recommend that you always use this setting. That way the worst case scenario is that you turn the old shares back on. The NTFS permissions and the data are still intact after this setting goes into affect. The second check box has to do with copying the source NTFS permissions to the destination shares. This can only be done properly if the file servers are in the same forest/domain. If you are moving the data to a new forest/domain I would turn this off and re-create the permissions on the other side. The sub check box can help clean up your NTFS permissions if you have a lot of entries of users that do not exist or cannot be resolved for whatever reason. These will be trimmed during the finalization of the destination shares.
Next we need to take a look at the share names. FSMT likes to append the source server name to the target shares. Simply remove this to preserve the same share name as the source. Do this for the Target location and the Target share. If you have a lot of shares to edit, simply copy the extension that is added and open the XML configuration file in the migration folder. Do a “replace all” with that name and replace it with a blank entry. That should remove the added target share name\location.
Now we are ready to start the migration. Here is a quick break down of how this process works.
The next step is to click the Continue button which starts the validation of settings. The validation makes sure that the destination and source shares are accessible and the destination shares are writable. It tallies how much data is available to copy and how many files/folders need to be copied. If there are any warnings or errors you may not be able to continue and you will need to review the HTML report of why the process cannot continue. Once the settings are validated the copy phase starts.
During the copy phase the data is synced from the source to the destination shares. The new share folders are created and data is copied into them. No shares or permissions are written yet to this data. Once the initial copy is done, you can back up the process and do another copy. Each copy after the initial copy is an incremental copy. This can be done for as long as you need. After each copy an HTML report is created and you would be wise to review it. Warnings about “file path too long” can be ignored. This process is able to copy them without issues. Once you have a cut over time established, you then need to proceed to the Finalize Phase.
The Finalize phase does a final copy of the data. It copies only the changes since the last copy. Once that is done it moves to the slowest part of the process, the “Finalizing Source and Target file servers” process. This process compares the source and destination shares to make sure they are in sync. Then it copies the source NTFS permissions and writes them to the destination share. This can take a long time depending on the number of files and folders and the complexity of the permissions. Once that is done the old shares are turned off and the new shares are created. A final report is generated to review the final phase. If the process fails, it will turn the destination volume back to the copy phase and leave the source shares turned on.
This part is really just to double check that the process finished without missing anything. The reports are clear and the results can be trusted.
This process is pretty simple when you get used to it. There isn’t a lot that goes wrong with it either. I have used this to migrate hundreds of shares and it has never had any major issues. The most common issue I have is the new share permissions need to be adjusted, however, the NTFS permissions are always accurate. This is my go to for migrating Windows server folder shares and should be apart of any Windows Server Admin tool kit.
17 thoughts on “How to: Migrate Windows file server shares with NTFS permissions”
I used to have similar problems too, but after using
“long path tool” everything was solved.
Long path tool is a very useful software
When it comes to user shares and group shares of a large organization, what happens if users don’t stop changing files during migration? Can changes be lost if users change files after the final sync in the Finalize phase has passed? Or will access to the old files (“Stop sharing source folders” checked) be deactivated file by file once NTFS permissions for it are being copied?
The “Stop Sharing source folders” actually turns off the old Shares so they are not accessible from the network using normal user access rights. The idea is to set a cut over or maintenance window of time to finalize the new shares and shutdown the old shares before users are back at it. If you can shut down the old server, you can edit your DNS to create a CNAME with the old server hostname pointing to the new one, as long as the share names are the same, it would be seamless.
Article is good though but I prefer to use a third party software which not only provided NTFS permissions but also multi threaded file transfer, pre scheduled file transfer, email notification when task is done and many more. I have been using this software for 2 years, its a paid one but its amazing!
Which tool do you use?
Hello, have you had a chance to verify if the toolkit is compatible with Server 2016? Thanks!
Not yet. Will update post when I get a chance.
I really appreciate the detailed instructions here. Also wondering about Server 2016. We have two new servers that we’ll be migrating to from two 2008 R2 boxes. I’m not sure about the DFS thing – hoping it’s not something we have on our system!
FSMT works with 2019 server. I have recently used it and it worked well. Still need to install .net 3.5 for it to work.
Once you start the finalize process do the source shares become inaccessible (even if you didn’t set them to be turned off)? Trying to gauge downtime for my migration from 2k3 to 2k12. Copy process seems to have worked well and grabbed the majority of my data.
The source shares will still be available if they were not set to turn off the shares. Any open files during the finalization will be closed however.
Thank you for the very useful article. I have a project migrating file shares from 2008R2 to 2012R2. We have DFS in place. So, once the file/shares migrated to the new server do we have to add the new folder targets to the DFS Name Space? How does that “Add links to DFS namespace” used in this case?
Appreciate your help.
Hi, If you are using DFS, I would just use DFS replication to copy the files to the new server by adding folder targets to the new file server for each share. Then add a replication group for each share using the 2008r2 server as the primary source. Then disable the new folder target until replication is complete. Then enable the new folder targets and test. If all good, then disable the old targets and test again. After a week or so, then decommission the 2008r2 server and remove the replication groups/targets related to it. Done.
I used the FSMT to migrate many file servers in several sites, from 2008R 2 to 2012 R2, using this guide without any trouble. We have DFS but I didn’t use DFS replication for I have read many negative comments in spiceworks. FSMT is a way to go, pretty easy. Thanks a bunch for this guide!