I’ve used the SharePoint Migration Tool successfully on numerous occasions but this week I had a very unusual issue.
In the SharePoint Migration Tool log file from a failed migration we found this error:
Scan File Failure: The parent folder was not migrated 0x0111000F
Failed to Read the file: Could not retrieve file’s metadata 0x01310007
For some reason the files could not be read, it was very random as other files in the same folders being migrated did migrate successfully.
The content being migrated was stored in Azure File Storage with local caching. The Migration Tool was using the local network drive mapping (to the cache) and often the content being accessed needed to be retrieved by the cache from Azure.
The issue is sometimes the file isn’t in the cache and the migration tool doesn’t wait for it to download. The result is the file is zero bytes long and as not file metadata to read.
One solution is to connect directly to Azure File Storage rather than using the cache by mapping a drive.
Hopefully this helps someone else with the same problem!
SharePoint lightbulb moments 
Hi Steve,
SharePoint noob here.
Whats the relation between the azure storage and share point? Does the Migration tool use an azure cache and by creating storage account there will it be used as well automatically?
I didn’t get this part as well.
“The Migration Tool was using the local network drive mapping (to the cache) and often the content being accessed needed to be retrieved by the cache from Azure.” I didn’t set anything.
I’m getting this error with few files I need to migrate them to SharePoint in Office 365.
Thank you.
Best regards,
Jonny Moura
Hi Jonny, in this case you can use a service call Azure File Store which uses Azure storage and some local caching to provide low cost file storage in the cloud, accessed via network file shares. The issue is because of the caching the Migration Tool sees the file name but can’t access the file quickly and so errors.
Regards,
Steve
Hi Steve,
I did a bit of research on the date and I could understand, map the drive and point that out inside the Migration tool. I got a better result but still a lot of files with the error. We are planning to migrate that manually unfortunately. Few files with version 12 it will be hard. If you have any better ideas please share and I try again.
Thanks Steve.
Best regards,
Jonny Moura
Hi Jonny, are you getting a specific error with those files? You should see this in the log file generated by the migration tool. Post it here and I’ll take a look for you
Hi Steve,
We get a similar error. We have the SPMT installed on a VM on the same LAN as the file servers with an attached disc used for the working data folder.
Randomly on bigger migrations we get Scan File Failure:Could not retrieve file’s metadata 0x01110009
Could this be down to latency between fetching the file from the Source file server and refencing the cache on the attached disk? I think the working data folder is not local to the VM.
Hi Robert, latency was the root cause of the issue when this occurred for me. If there is any file caching between the file server and the VM running the SPMT then it can also cause issues. I have only experienced this with Azure based storage, but I think the same issue could occur if a SAN has caching or high latency (or both)
I am going to put this out there, I am doing a fileserver migration and also get this error. I have worked out the reason. I have users who have put special characters in the names. For example D:\MainOffice\Doc’s\myimportantfile.doc <- fails on the ' in Doc's
The other one is on hidden files with a . in the front (often from mac's access the folder. so a D:\MainOffice\Doc\ . cloud\myimportantfile.doc
I have over spaced the above to show the . but you get the idea.
As for a fix, it is I am afraid to rename or delete these issues (renaming folders, deleting the not needed hidden ones. Hope this helps someone
Thank you for posting this Tim. I am sure this will help someone.