Wow it was over a year ago I wrote the first part in what was intended to be a series documenting my experiences of migrating to Microsoft 365! Better late than never I guess…well in this post we will explore the process of migrating “home” drives or personal user data to OneDrive in Microsoft 365.
Background
The key tenants to the migration approach are fairly commonplace in most organisations, with four distinct phases:
Exchange email migration
Home drive migration
File share migration
SharePoint migration
The plan was migrate all users home drives from on-premise file servers into OneDrive, making the home drives read-only in the process and then finally removing the mapping once all migrations were completed.
Discovery & analysis
Discovery of home drive data
So naturally to start to flesh out how we would migrate all users home drive data to OneDrive we needed to do a little digging to understand our estate and figure out:
Also during this discovery phase we began working with Microsoft FastTrack. If you don’t know much about the service, it is something Microsoft offer to assist customers with their migration projects and best of all it’s FREE!
So once you are set up with the FastTrack service, you still need to do all the discovery and analysis as described above before you can provide the migration tracks to them, in order for them to schedule and run the migrations.
Fast Track also require that you create virtual machines (VM’s) to run the migrations. They calculate the number of VM’s you need based on:
- The total file count of your file share data or SharePoint environment (if supported)
- The total volume of your home drive data
We wanted to multi-purpose our VM’s to also run migrations for other parts of the M365 project. So we had to take the metrics above and provide an average based on what little we knew at the time in order to create enough VM’s (we ended up creating six).
In order to find answers to the above questions, I used the SharePoint Migration Manager. The Migration Manager can be used to create scan-only tasks that will output reports on all your home drive sources and basically enable you to begin scheduling the migrations.
I’ve wrote a separate post on the Migration Manager here, which has full step-by-step instructions (and a video) on how to set up a scan-only task.
Analysis of home drive data
The analysis part of the migration included looking at how we could effectively answer the three main questions above. For the first two questions; how many home drives are there, and how much data do they contain – running the scan-only tasks answered those questions.
How many home drives are there? and how much data do they hold?
To summarise what I did, I created tasks for each top-level home drive folder on each file server that contained the home drive data (for example: \\yourserver\home) and collated the answers to the questions above in one, master spreadsheet.
The scan-only reports included much more granular information about each home drive within the top-level file share, which I downloaded from Migration Manager into a working folder for further analysis if required.
I also found that the summary reports, or key information provided by Migration Manager around failures to be a bit misleading. For example, if the accounts used to read the home drives don’t have access to a particular folder, that doesn’t flag as a failure. You have to open the ItemFailureReport from each task to find out if there were any issues with access or files/ folders themselves.
Coming from on-premises? Be prepared to compare user data
As mentioned earlier, you are expected to provide FastTrack with a list of home drive locations and OneDrive URL destinations in a migration track in order for them to begin the migration.
Because our estate still has an on-premise Active Directory (AD) that didn’t have all users synced, we had to do some checks to make sure all the users from our on-premise AD had O365 accounts and also had OneDrive sites to migrate to.
We used an export of AD on-premise data, compared against Azure AD data and a OneDrive usage report that you can download from here. We used this to flag any accounts that either didn’t have Microsoft 365 accounts, or OneDrive sites, or both.
Migration
Once you get to this point there is no turning back! Well, that’s probably a bit dramatic but I sure wouldn’t want to after doing all the discovery and analysis on the home drive data…
Migration process
When it comes to FastTrack they are the one’s running the migrations for you. So with that there are some limitations that they set out up front:
- FastTrack cannot complete more than 50,000 tasks
- FastTrack cannot migrate more than 1TB of data in a 24 hour period
The migration process itself was a relatively simple one once your migration spreadsheet has been created for each batch of migrations and provided to the FastTrack team via their portal. With your migration dates scheduled with FastTrack, your role then becomes 1) making sure the user base is informed as to when they are being migrated and what to do, 2) liaise with FastTrack as the migrations complete, 3) then handover to the users after they’ve been migrated and finally 4) remediate any post-migration issues. Easy right?
Lessons learned
Aside from the issues and resolutions described below, the biggest thing I took away from the entire process is not to underestimate how much support your user base will require post-migration. We received lots of queries post migration around the change from home drives to OneDrive, some of which may of been addressed by more training, champions etc. but largely was just reacting to the change and not knowing what to do next.
Issues & resolution steps
#1 Not all users had OneDrive
As mentioned earlier in this post, during the analysis of the user data before migrating to OneDrive we discovered several users did not have OneDrive set up.
I’ve wrote a separate post on how to provision OneDrive for Microsoft 365 users that goes through this in more detail.
#2 Migration tasks keep failing
Before the OneDrive migration started in anger, we ran a few pilot migrations just to test the process out more thoroughly. We had setup the migration VM’s and migration agents some months earlier, so when we came to run the pilot migrations, all the migration tasks failed – pretty much immediately. In the logs for the failed tasks we received this error:
Error, the source file share does not exist.
Suggestion, Ensure the source file is an existing network file share and shared with the current user
SharePoint Migration Manager task error
Microsoft have an article on troubleshooting the Migration Manager here, but in this case the issue was actually related to do with expired account credentials running the migration agents. Although the error logs didn’t tell us this, once we re-ran the migration agent setup and “repaired” the agent, re-authenticating the accounts meant the migration tasks ran successfully thereafter.
#3 Permissions issues with files don’t show as “files scanned with issues”
Again, something I’ve touched on earlier but another issue we encountered during the migration was that any permissions issues that occur during the migration are not highlighted in the summary information for a given migration task.
So in the scenario post-migration, if a user gets in touch to say some files/ folders are missing you need to find the migration task, download the task report then comb through the ItemFailureReport to discover what data hasn’t been migrated due to permissions issues.
#4 “Missing” files and the hidden CSC folder
Kind of related to #3, we also encountered issues when switching off Windows Sync Center as part of our migration process. In some cases we had users who had files/ folders that hadn’t successfully synced from their local machine to their home drive, so following the migration and switch off of Sync Center it appeared their files had gone “missing”.
We resolved this by locating the hidden Windows CSC (client side cache) folder C:\\Windows\CSC, which is a location where Windows keeps offline copies of files and folders. Getting access into this location was a bit of a nightmare for us, but once you get access into the location we were able to find all of the reported “missing” files and copy them over to the users OneDrive.
SharePoint Stuff 
2 thoughts on “Tales of a Microsoft 365 migration – OneDrive”