OneDrive for Business Reconfiguration

OneDrive for Business Reconfiguration

Office 365 – Tenant to Tenant Migrations

OneDrive for Business Reconfiguration

Today I’m going to briefly outline Reconfiguring the OneDrive for Business Desktop Application. I say briefly because as a departure from some of our other blogs I’m going to depart from the usual step by step process with screenshots. If you have landed here, you are probably across the finer details of OneDrive.

There are tools around for reconfiguring Outlook profiles from a lot of vendors.  BitTitan has their DeploymentPro which works well in the main but has some limitations like basic Auth and cant be used with MFA.  However, we have yet to see a OneDrive reconfiguration tool.  We believe it could be done because the manual steps and known components are well known.  There are defined registry keys and the ability to mark files as “Free up space” using the attrib command.

Automating this requires careful planning, because the OneDrive config you are wanting to target for reconfiguration could be one of many.  For example I myself have OneDrive connected to my Work tenant, a personal family tenant, my Hotmail account and a few partners we work with where I sync from their SharePoint just the files shared with us.  These all present with their own registry keys at:


So targeting the RegKey that contains your tenant should be straight forward under the Business* keys.  You probably cannot for certain assume Business1 either depending on which one was continued first.  Take your pick in here from DisplayName, UserEmail, SPOReourceID.  DisplayName probably isn’t reliable in case the Tenant Org name got changed at any point.  It’s just a label after all.

BUT… the Partner organisation I sync with is here too.  Under the Accounts\Business1\Tenants key is where that one is, so just blowing away the Busines1 key would cause me a problem.

You could probably confidently run attrib against the value pulled back from UserFolder though.

Short version

In short, the user must unlink their OneDrive for Business client, REBOOT and relink it.  How smooth that is, depends on good upfront communications, the end-user IT maturity, when and how you decommission the users’ access to the source tenant data, and what their identity is set to in the target.  We would HIGHLY recommend having users mark all their Files and Folders in OneDrive as Cloud only.  i.e. Select all, right click and chose the “Free up space” option.


There are several use cases for OneDrive reconfiguration depending on the tenant to tenant migration itself.  Is the Domain name and UPNS migrating as well?  Is it a whole org move to a new tenant, but the Organisation name in Office 365 staying the same?  Is it a divestiture with not all the users migrating?

Path of Least Resistance

Assign users new UPNs and block access back to the legacy tenant

Interestingly the path of least resistance and least chance of unexpected / unwanted behaviour is having your users assigned a brand-new identity (UPN) with a new password and the organisation name being completely different from the last.

Why?  Because then there is categorically no way of confusing legacy identity and data from new data.  The user knows to use a new logon, the Workstation and cached credentials don’t get in a pickle trying to connect to the legacy tenant with legacy credentials.  A new folder in Explorer is presented and the reconfiguration that the end user has to do is clear and straight forward and easily documented.

Also, if the users are assigned a temporary UPN with the intent of switching it later, their ODfB URL is made up of the UPN name and the ODfB client will start with that value in settings.  Both will change over time – but at the mercy of Microsoft timing.  Ergo, having a brand new static UPN is preferable.  Not always possible of course, but for the sake of the blog we’re sticking to that scenario.

Blocking access to the legacy tenant is advised so that users don’t simply carry on working and updating files in the wrong place.

Free up space / Always keep on this device

After unlinking, any files that were set as “Always keep on this device” (locally available) will remain on the Workstation after unlinking.

This is not ideal, as it will be confusing for users.

Once a user has successfully unlinked their account, their normally BLUE OneDrive folders remain and become normal YELLOW Windows Folders.

Users will inevitably have two copies of the same data when they link up OneDrive again.  This could lead to the users’ working in the wrong files, or dragging the whole lot to their new OneDrive in a back-up folder “just in case” or overwriting all the files that have been sync’d as part of the migration effort.  Ideally you really want to steer the users away from “dragging and dropping” “cut or copy / paste” these files into their migrated OneDrive, as that might literally double the size in the target and cause unnecessary network activity.

Free up Space (aka Files on Demand FOD)

If however before unlinking, they had been set as “Free up space / Clear space” then they will disappear from the Workstation after unlinking and don’t become confusing items.

So we STRONGLY recommend getting user to select all their files and folders at some point in advance of the migration date and choose the option to “Free up space” from the right click context option in Windows Explorer.

As discussed earlier this *could* be scripted using attrib,  Depending on how many files and folders the users has, this could take a long time and may even fail for some items.

Cutover Event

Business as usual right?

So on the Monday morning when the users come in, if they don’t immediately unlink their ODfB, (and why would they it’s just sitting in the system tray looking normal so the users don’t believe there is anything to do) then they will just continue to use the legacy OneDrive data.


You have to educate the user and support staff of this process on migration day

REBOOT recommended

This is VERY important if the user is taking over the same UPN otherwise the cached credentials from the previous log on and some other registry information are attempted to be used.

Often it does not go well, and *CAN* you get into a kind of hybrid messed up state that is hard to recover from for the users because they can’t actually get logged on with those creds, and now they can’t unlink again.

This can require and uninstall and reinstall.

Relinking OneDrive for Business

Literally after rebooting the user should just be able to start OneDrive for Business in the normal way.

Users need to be sure to work in the NEW “Blue” files and folders, not the old “Yellow” ones.


  1. Unlink
  2. Reboot
  3. Relink.

For Mobile Devices we always recommend deleting the Outlook and OneDrive App completely and re-installing from the respective App Store

Users that don’t unlink

If they double click the icon in the system tray etc or go to Windows Explorer they will open their normal cached local folder data.  If they choose view online, it will work perfectly (in their eyes) but they will be taken back to the SOURCE tenant.  Same on mobile devices.

How to stop this (working as designed) behaviour?

Conditional Access Policy

Use a Conditional Access policy and block it that way.  This involves the least amount of effort to the user account and can be prepared in advance.

Remove the Office 365 ODfB Licence

Well you can just remove the licenses, right?  Well actually no.

What we have seen is that once a user has ever been granted a SharePoint / OneDrive licence they can always get back to that data via the URL in a browser –  assuming they were permissioned for it in the first place.

The URL still exists for 30 days (and longer for litigation hold)

Change the password and block sign-on

Change the password and block the users is your second best bet.

The downside to this is that you will need to ensure that you are no longer syncing identities (as the blocked user and password details will flow unless you are doing some good attribute re-writes or filtering).

Also, if you need / want users to have the ability to go back and check old data (a common workaround post migration), then you can’t.

And for our next trick… Migrating Teams Private Folders. They say it can;t be done, but it can 🙂