Just trying to establish if this is standard behaviour for the FSMT. During the finalization of the project it is taking a very long time to complete due to what looks like all of the data being copied again. The previous incremental copy that ran took no more than 10mins. I went back in the project and copied the data again just prior to finalizing the project.
Has anyone else seen this behaviour? I believed that it should be doing another incremental copy as part of the process. Defeats the purpose of the tool if it takes about 4-5hours to migrate.
Finalizing copy data process is a part of FSMT to finish the migration project
During this copy phase, the File Server Migration Wizard creates the target folders and begins copying files from the source file servers to the target file server. Open files will be skipped during this phase but will be closed and copied during the Finalize phase.
The wizard shows the copying progress for the entire project and for a selected shared folder as illustrated in the following figure.
As you may notice, if the source server has plenty of data that need to be migrated, it may take several time to finalize the copy process. This actually depend on the quantity of the data that the source server hosts.
At the end of this phase, the File Server Migration Wizard creates a report that describes successful and failed copy attempts. You can repeat this phase multiple times; only changed files will be copied in successive attempts.
For the detail about File Server Migration Toolkit, please refer to the FSMT white paper.
Overview of the Microsoft File Server Migration Toolkit
Hope this can be helpful.
This posting is provided "AS IS" with no warranties, and confers no rights.
- Edited by David Shen Wednesday, November 18, 2009 7:03 AM
Thanks for the comments however I am somewhat confused by this statement. What is the point of performing incremental copies leading up to the finalize stage if during the finalize stage it will copy over the entire data again? Correct me if I am wrong but the whole purpose of either pre-staging data from a restore and performing the incremental copies repeatedly during the 'copy phase' is to minimize the outage during the 'finalize phase' for end users. You effectively want your delta to be that small that this phase completes swiftly. Is this not how the tool is designed?
Step 2 of the finalize phase description in the help file states exactly that an incremental copy is performed and not a entire recopy of all data again. I guess the tool is not working how it should :(
2. Recopy files from source file servers to target file server The File Server Migration Wizard performs the final incremental copy.
Any new or updated files since the previous copy attempts are copied to the target file server. Files that were held open during previous copy attempts are also copied to the target file server.
The wizard generates an error if a target folder exists or if any other problems, such as lack of disk space, prevent the final copy. The errors are logged in the report, and the wizard stops copying to the folder.
This is an old thread, so I'm not going to ask any questions, but for anyone else planning to use this tool, I'm in the middle of a migration now and it is indeed taking a long long time to finalise. The copy stage took about 24 hours and the finalise stage looks like taking at least that, probably more. Since the finalise stage is supposed to be only copying the delta (of which there should be almost no data in my migration), it does indeed seem that the tool is not working as it is supposed to.
Hope more people pick up your comment. I'll add another comment with the same complaint. It took about 24 hrs for our Win2003 to Win2008 file server migration during the copying stage. My understanding based on everything I've read and experience with Win2003 to Win2003 migrations was that the finalize stage indeed is really just the deltas and a fraction of the time for the previous phase. It wasn't.
I didn't open a case then, we just scheduled a wider window and were able to complete it after several more attempts during the weekend. A lot of frustration for sure but I assumed it was just a one-time issue having to do with something quirky in our environment. I'm a consultant so have had to do this a few more times. It clearly not a fluke as we've seen this in a few more instances now. We just push ahead with long migration windows but this is getting tiresome.
Seems i am a year later with your problem.
Sitting in between the migration right now trying to finalize 880 GB of data (772,000 + Files/Folder) from old 2K3 to new 2K8.
Took 1 min to perform increments before i initialized the final sync and found to my horror on the slow phase its running in a limited time window provide.
if someone could tell me , that copying the lanmanserver registry from the old server to new should do the trick? since i have all the the data on the new server which when compared with both servers(files/folder and Size) shows the same.
i got 5 more hours an any useful tips would give me something to move on