Issues with NGSC Takeover Process

[Andy Baerst]

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-Cli...

A consistently reproducible situation is,

1. 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.
2. 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).
3. 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.

[#2]

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, @Stephen Rice, @Randy Wong

Sorry for the shotgun approach. That's the danger of being in an AMA.

[#3]

Sorry Andy,

I'll pass this onto our engineers and have them review and answer.

[#4]

I faced an issue that takeover command only created the folder structure , without any files being copied.

[#5]

Hi @Andy Baerst - 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

[#6]

---

@Andy Baerst wrote:

A consistently reproducible situation is,

1. 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.
2. 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).
3. 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:

1. Everything is working. Old libraries were moved to NGSC. Very little network traffic.
2. Some libraries got stuck.
3. 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...
• 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.

[#7]

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.

[#8]

Hi Andy,

Thanks for the detailed write up.  Let's jump in here

For case #1, can you confirm that your version of Office was one of these versions or higher.  Since you were hitting "Sync"

Office 365 ProPlus	16.0.7167.2*
Office 2016 MSI	16.0.4432.1*
Office 2013 MSI/C2R	15.0.4859.1*

For case #2, let's investigate that.  Expected behavior is for all libraries to be taken over by the OneDrive sync client.  We expect /takeover to be a one time event.  Making you manaully disconnect libraries first defeats the whole purpose :)  could you please right click on the blue cloud icon in your Windows task tray (bottom right corner) and click report a problem.  If you want to link to your helpful sway and submit, we'll investigate.

Thanks,

Pat

[#9]

Hi Pat. Thanks for the reply. Yes, my NGSC version is current and my Office C2R version is greater than the minimum required version. I am not going to pursue the Report a Problem route for two reason. 1) In my experience "Report a Problem" does not get to the level of troubleshooting that I usually hope for. In my experience it usually results in a series of generic How-To emails. If I were to pursue a ticket I would use either a submission through Office 365 or via my MS Partner benefit. But, more important, is 2) as I stated in my original post. I had already opened a ticket with Office 365 support, but I cancelled it because I ran out of clean test cases. I eventually ended up manually interacting with each migration to nudge it along. My post was to explain my experience so others can benefit if appropriate, but I've moved on and have completed our Groove to NGSC migrations for all client endpoints. It's a moot point for me now. Thanks.

[#10]

Hi Andy,

We actually discovered a really good bug thanks to you! In the case of running /takeover in the case where there are multiple libraries syncing with Groove that all resite in the same site, takeover was only taking over one of those libraries at a time.

We have a fix in progress.  In the meantime, your work around will need to be to go to each of the remaining sites on the web client and hit "Sync" for each site, or run /takeover multiple times to get all the sites (not great, we know).  Thanks for reporting this and we'll make sure we get this fixed as soon as we can

[#11]

I am glad that my writeup helped the process of discovering this /takeover bug. Thinking about this fact I am surprised that this bug made it this far. Here is why.

According to your reply, the bug applies to sites with multiple libraries being sync'd. In my world that means every site instance. The only time that it would be possible in any of my worlds to have a single library in a site is if I stopped at the default "Documents" library, but given the limitations of the former Groove.exe client, that was nearly impossible. The Groove.exe client limited sync to 5K items per sync instance. I've always argued that, in most enterprise environments, 5K was minuscule. The result was that we always had to break up libraries into sometimes artificial groupings to satisfy the limitations of the Groove sync engine. So, in my use cases, it was rare to end up with a single library per site.

I am just surprised that my experience was not the norm. I'm assuming that you have to telemetry to know and that's what leads to my surprise that this wasn't caught earlier.

Anyway, I am glad to hear that it's been addressed and will be fixed in future sync client releases.

Andy

[#12]

Is the sync client updated yet for this behaviour? We are currently experiencing the same kind of issues using the most recent NGSC version. Takeover command does not seem ready yet to deploy to all users. A premier ticket has been raised.

[#13]

Hi Particia,

As of today takeover approach still produces Andy's  #1 problem at our client. Can we have an update on the state of this issue?

[#14]

We're having similar issues here. I am both frustrated and unsurprised that something as simple as "transferring multiple libraries from the same site doesn't work at all" made it all the way through to production, and required someone posting here for you to acknowledge a bug. If this behaviour wasn't tested, what was?

[#15]

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