Forum Discussion
Issues with NGSC Takeover Process
I'm checking to see if anyone else has had issues with the OneDrive.exe /takeover process. Specifically, I have not had the documented behavior of SharePoint (groove.exe) to [Company Name] (OneDrive.exe) takeover complete without user intervention. I know that there are a number of blocking conditions, but I'm talking about even on very generic existing library sync's.
This is based on following the guidelines in: https://support.office.com/en-us/article/Transition-from-the-previous-OneDrive-for-Business-Sync-Client-4100df3a-0c96-464f-b0a8-c20de34da6fa?ui=en-US&rs=en-US&ad=US
A consistently reproducible situation is,
- Run %localappdata%\Microsoft\OneDrive\OneDrive.exe /takeover. Sometimes nothing happens, sometimes the one or two existing library syncs will migrate meaning that they are now represented under the new [Company Name] node and also under the old SharePoint node, but not as an active sync. The migration will stop in that condition and both [Company Name] and SharePoint remain.
- Running the OneDrive.exe /takeover command a second time will result in another library being migrated, but most likely not more than one. I have had to run OneDrive.exe /takeover repeatedly (the number of times equal to the number of existing groove.exe sync'd libraries).
- What is also counter to documented behavior is that, when a takeover does occur, I see all documents in the library scrolling through the NGSC Notification Center dialog being shown as downloading. I haven't actually sniffed the wire to watch the transfer occur, but it certainly looks like it's downloading the entire library again which is counter to the documented statement that files won't be re-downloaded.
I opened a ticket with support and pursued it for a while, but my user community is not large enough to provide a good sample of use cases. By the time that I reached ticket submission I had already manually addressed many of the migration issues. I closed the ticket because I felt that I wasn't the right user to be raising the issue since I couldn't provide enough new examples.
So my observation is that, while I was always able to eventually complete a migration, the process was almost never without user intervention as stated in the documentation.
Just to be clear, there are plenty of other issues that can block the migration like broken sync's going into the migration (red x's, stuck syncs) and merge conflicts. We had our share of those, but I am not including them in this write up. I am only talking about libraries that I believe should have been without issue.
The attached image will give you an idea of how the tree may look after running the /takeover command. In the example image 1050 and 1051 were unsyncd libraries that existing in the SharePoint structure prior to migration. They were subsequently removed manually.
I am surprised that there were no replies on this thread. I'm not sure whether to conclude that no one else is experiencing this issue (meaning specific to me...or caused by me) or whether not enough people are using either of the takeover methods. I have reproduced this across multiple tenants, library structures and OS variants so I'm having a hard time believing that it's just me. The other possibility that I was thinking about is that, since migration is a one time deal, that it's just not that important in the long run. Another solution is to just Stop Sync'ing all Groove libraries and then resync them on the NGSC side. My hope for the takeover process was to avoid the unnecessary download. We all know the story. Remote users, low bandwidth users, etc, + multiple GB libraries equals pain. Maybe it's Groove's one last sucker punch to me!
I created a Sway to document my experience.
https://sway.com/EV9tClm5EIqvhHas
I'd still love to know if anyone else experiences the takeover process as documented.
I'll add a few mentions for good measure: Stephen Rose, StephenRice, Randy Wong
Sorry for the shotgun approach. That's the danger of being in an AMA.
- Stephen Rose
Microsoft
Sorry Andy,
I'll pass this onto our engineers and have them review and answer.
Hi ABaerst - thanks for the comprehensive share on this topic. To date, my takeover testing has been with the reg key approach, but for mainstream adoption I was considering the /takeover switch to put some control to the end user. The reg key approach was not without issues either, but most of them were during the "preview" phase of the program, so you expect some issues. I assume you are now on the latest bits - .1212?
Anyway, I will be performing some of my own testing going forward, and will revert if I am seeing similar.
Thanks
Cliff
Hi Andy,
I havent faced the first 2 parts of the issues and I used the reg edit, not the takeover, however Im facing the issue number 3 myself.
What is also counter to documented behavior is that, when a takeover does occur, I see all documents in the library scrolling through the NGSC Notification Center dialog being shown as downloading. I haven't actually sniffed the wire to watch the transfer occur, but it certainly looks like it's downloading the entire library again which is counter to the documented statement that files won't be re-downloaded.
All libraries in my company re-download almost on a daily basis. I have been following up with MS on the issue for 3 weeks almost but they still havent been able to figure it out. It seemed like we were the only one facing the issue until i read your post. I have shared all evidence of the issue to them and they told me to wait till the next update of NGSC but Im skeptical since they havent figured out whats wrong.
For us, we recently moved to OneDrive so we never had to switch from Groove, so this isnt a transition issue.
I faced an issue that takeover command only created the folder structure , without any files being copied.
Andy Baerst wrote:A consistently reproducible situation is,
- Run %localappdata%\Microsoft\OneDrive\OneDrive.exe /takeover. Sometimes nothing happens, sometimes the one or two existing library syncs will migrate meaning that they are now represented under the new [Company Name] node and also under the old SharePoint node, but not as an active sync. The migration will stop in that condition and both [Company Name] and SharePoint remain.
- Running the OneDrive.exe /takeover command a second time will result in another library being migrated, but most likely not more than one. I have had to run OneDrive.exe /takeover repeatedly (the number of times equal to the number of existing groove.exe sync'd libraries).
- What is also counter to documented behavior is that, when a takeover does occur, I see all documents in the library scrolling through the NGSC Notification Center dialog being shown as downloading. I haven't actually sniffed the wire to watch the transfer occur, but it certainly looks like it's downloading the entire library again which is counter to the documented statement that files won't be re-downloaded.
I can confirm numbers 1 and 3 in your list.
We encountered three states:
- Everything is working. Old libraries were moved to NGSC. Very little network traffic.
- Some libraries got stuck.
- Many conflicts in a number of libraries (see below).
I never used the /takeover command a second time and thus cannot confirm your number 2.
Fortunately my colleagues don't have such a large number of synchronized libraries as you have. But still, we encountered all kinds of problems like file conflicts that were not visible before. In one case we had around 400 files that had the name of the computer appended to their file names because they "were conflicting files" (they weren't). It seems that Groove was not able to set some meta-data for those files on SharePoint and thinks they are in conflict. The contents of the files were identical. Their "new versions" were downloaded and thus generated network traffic. I could not check for sure if some libraries were fully downloaded but it seems the number of files downloaded was less than the files in the library on SharePoint.
Just for completeness, below is my personal experience how to handle the transition in the most hassle free way.
This is not an automatic process and cannot be rolled out to customers!
In my opinion the most hassle free way to make the transition is:
- Update your software (Windows, Office). OneDrive should be at 17.3.6743.1212 (it comes with Windows). Office 365 should be at 16.0.7162.2xxx or higher.
- Adjust the setting of your SharePoint to only use the new client. See the bottom most section in https://support.office.com/en-us/article/Enable-users-to-sync-SharePoint-files-with-the-new-OneDrive-sync-client-22e1f635-fb89-49e0-a176-edab26f69614?ui=en-US&rs=en-US&ad=US
- Just un-sync every library that was synced through Groove.
- Move the SharePoint folder from %userprofile% somewhere else as a precaution if your Groove client secretly messed up behind your back without you knowing and prevented some files from getting uploaded to the server while showing "green checkmarks" everywhere.
- Reboot
- Sync everything you like from SharePoint. Your browser will (should) open the new client automatically.
- Compare the new directories with the old versions you moved away before (I use WinMerge). Ignore the files that differ (they are not, it's just their meta-data) but check for missing files.
Hello Patricia Hendricks Balik,
Is there any update on this issue? What is the current status of it?
Takeover command still doesn't work for us :-/
- Microsoft Office 2016 MSO (16.0.7726.1042) 64bit
- Microsoft OneDrive Version 2016 (Build 17.3.6943.0625)
Thank you and best regards,
Ben
