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.

Settings Phase

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.

 

Copy Phase

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.

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.

Completion Report

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.

Conclusion

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.