Account Mapping Target Path Configuration – Google Drive Sources
For multi-user account mapping jobs that have a Google Drive source, the contents of /My Drive will be selected for each account. This results in a target path of /target_destdir/My Drive/[my drive content]. For example, if you specify a target folder of “Files from Google,’ and you have source folder on Google Drive called /My Drive/My Documents, the resulting target path will be “/Files from Google/My Drive/My Documents.”
To eliminate ‘My Drive’ from all target paths, enter a line in the paths tab of your mapping spreadsheet for each account selected for transfer, as shown here:
|SOURCE OWNER||SOURCE PATH||TARGET OWNER||TARGET PATH||RENAME? (Y/N)|
|Janet.Alfonso@company.com||/My Driveemail@example.com||/My Drive/Migration Files||Y|
|Robert.Chu@company.com||/My Drivefirstname.lastname@example.org||/My Drive/Migration Files||Y|
Owners vs. Accounts
The most complex issue with Google Drive migrations is that the Owner of a file or folder can be different from the Account, or Namespace, that the file or folder physically resides in. So you can have a folder called “Sara’s child folder” that is owned by Sara, but it resides in Janet’s account. The following rules ensure that a single instance of every item is transferred to the target, without duplicating data.
Scenario 1: Full path owner and account/namespace user are identical
If all elements in a path (folder and file) are owned by a single given user and also reside in that same user’s namespace, the item will transfer to the mapped target account for that user. Generally, most files in customers’ migrations fall into this category.
Scenario 2: An item (folder or file) is owned by one internal user, but resides in another internal user’s namespace
If an item – folder or file – is owned by one user but physically resides in another user’s namespace, CFP will transfer that item with the owner’s account, provided that the item also exists in the owner’s account.
If, for some reason – and this will be an edge case – the folder or file does not exist in the owner’s account, CFP will transfer the item with a sharee’s account. This sometimes happens if one user:
- creates a folder and shares it with a second user
- that second user mounts the folder on their /My Drive
- the second user creates a file (which they own because they created it) in the mounted folder. In this case (and legacy – i.e., how long ago the file was created on Google – plays into this), the file may only physically reside in the first user’s /My Drive, and CFP will transfer it with that account. The parent folder has been shared with the second user, and that permission will inherit down to the file. So both the first and second user will have access to it on the target as long as you run the job with permissions.
Note that CFP has a very flexible mapping configuration, so if you want to transfer an instance of an item that is owned by one user in a second user’s namespace, you can easily do that via commands in the mapping sheet. You’ll want to do this carefully to avoid transferring duplicate data. When in doubt about where a given item will go, running a simulation will resolve most questions. Contacting CFP support will answer the rest.
Scenario 3: An item (folder or file) is owned by an external user, but resides in an internal user’s namespace
If an external owner has shared a file or folder and a single internal user has mounted it on their /My Drive, the default behavior is that CFP will transfer it with that one sharee. If an externally owned item is shared with more than one user who has mounted the item on their /My Drive, all instances of the item will be filtered. You can unskip an externally owned item and, as long as that GDrive user has sufficient downloading permissions, the item can be transferred to the sharee’s mapped target account. Only a single instance of that item should be unskipped in the entire migration to ensure that there is not duplicate data.
External Users in the Users Tab
External sharees may be left blank in the mapping document and their ACLs will be applied to the target where the external sharees are supported. For externally owned data, the Google admin for the current migration does not have access to the external user’s full /My Drive account, so the strategy used above for internally shared and mounted data cannot take place. So in this case:
- if the externally owned item is shared with one internal user in the Google source tenant AND it is available on their /My Drive, we will transfer the item with that one user. Note that permissions considerations will apply, and if the external owner has not given the sharee download permissions, we cannot transfer the item. Note that we do not transfer any data, externally or internally owned, from the /Shared with Me drive.
- if the externally owned item is shared with more than one user in the Google source tenant, we will look at how many of these users have the item on their /My Drive.
- If only one user has the item on their /My Drive, we will transfer the externally owned item with that one user.
- If an externally owned item is shared with more than one internal user AND it is available on more than one /My Drive, we will skip all instances of the item. It is up to the migration team to select one account to transfer that data. The reason that we do not specify one sharee account as the owner is we don’t know which account is the “correct” account to replace the external owner.
External Groups listed as source sharees in the Groups tab may be mapped to Internal Groups on the target, or they may be skipped.
Alias emails are alternate emails to the primary email for a given account. These may be due to historical changes in the Google account – for example, if the relevant email domain for the tenant changes from subsidiary.com to parentCompany.com, and users receive new email accounts – or in instances where a user simply needs two emails for the same account. When migrating data from Google Drive, this can result in some older files that are shared with email@example.com, and newer ones that are shared with joe@parentCompany.com, when they are actually shared with the same source account.
CFP checks the ids of user metadata associated with owners and sharees, and will merge aliases with the current primary email for the account. In the example here, that means that any files that were shared with the email firstname.lastname@example.org will be listed as being shared with joe@parentCompany.com in the mapping spreadsheet and in CFP reports. Any updates to the primary emails of user accounts should be done prior to any analysis or transfer via CFP to prevent confusion and errors during the migration.
Understanding the Paths and Path Conflicts Tabs of a Google Sourced Mapping Sheet
The map has to do two things:
- accurately list all permissions for the data selected in the job
- implement directives to ensure that only one instance of each folder or file is transferred.
The map will list all shared paths found so that the user has complete information on the data set selected. However, if a sharee has mounted a given folder, and both the owner and sharee’s accounts are selected in the job configuration, that means that the path will be listed twice in the map: once for the owner’s account, and once for the sharee’s account.
|Source Account||Source Owner||Source Path||Skip?||Warnings|
|email@example.comfirstname.lastname@example.org||/My Drive/Root folder/Shared folder|
|email@example.comfirstname.lastname@example.org||/My Drive/Shared folder||Yes||Transferring files accessible to other accounts outside this folder may cause duplication.|
In this case, Bob has shared a folder ‘Shared folder’ with Janet, and she has mounted that folder on her /My Drive. (Janet cannot see the parent folder Root folder that is in Bob’s account, because that hasn’t been shared with her.) However, there’s an issue: we are transferring two instances of the same folder. So what CFP does is to transfer the one instance – and in most cases (as described earlier on this page), it will be the instance that is in the owner’s Source Account – and skips (Skip? set to yes) all other instances of that item. You will see this in the generated spreadsheet.
The end result is that the spreadsheet provides a full account of all sharing relationships throughout the data set, but applies filtering (Skip) commands to ensure only one instance of the item is transferred.
- In the example above, if Bob’s account was not selected in the job configuration, CFP would not report the contents of his account – including ‘/My Drive/Root folder/Shared folder.’ However, we would still automatically skip Janet’s copy of /Shared folder, because part of the map generation process is determining all of the instances of that /Shared folder in the entire Google Drive account – and ensuring that only the one instance of that folder is transferred, regardless of how the full set of accounts is divided up among different jobs in the migration. If you are not transferring Bob’s account at all, you may elect to unskip Janet’s copy of ‘Shared folder,’ and CFP will transfer it.
- You will note that when the spreadsheet generates, there may be some paths in the Paths tab where a given subfolder is still listed twice, and neither one is skipped. However, if you look at the Path Conflicts tab, you should find a parent folder in the one sharee’s account that is skipped – and once a folder is skipped, all children are skipped, unless the children are explicitly unskipped.
Below is a list of roles on Google Drive, and their characteristics. Note that roles on My Drive and Shared are different.
Also be aware that for account mapping jobs going to a Google Drive target, the mapping spreadsheet will list all of the permissions for the selected data. However, folder permissions are not supported for Google Shared (Team) Drive targets. If it is important to preserve permissions, send the data to a personal drive (/My Drive) instead.
|Role (My Drive/Shared)||Description|
|Viewer||Can view files. Cannot edit or download files and, in many instances, cannot list permissions on files. Generally maps to target as a Viewer/Reader role.|
|Commenter||Can view and add comments to Google doc files. Can view other files. Available for files (My Drive or Shared Drive) and Shared Drive root only. Generally maps to target as a Writer role.|
|Editor (My Drive)/Contributor (Shared root)||Can add and edit files. Generally maps to a target as a Writer role.|
|Content Manager (Shared root)||Can add, edit, move, and delete files. Also referred to as File Organizer in some Google documentation for Shared Drives. Generally maps to a target as a Writer role.|
|Owner||The actual owner of the file or folder. Can add, edit, and delete, and in most cases, list permissions. Owner in Google Drive is discrete from the account, or namespace, where the file or folder physically resides. In many instances, owner and namespace may be one and the same, but in some cases, they will be different.|
|can manage content, people, and settings. Can add, edit, move, and delete files. Also referred to as Organizer in some Google documentation for Shared Drives. If there is one Manager, they will be the owner of Shared Drive. If there are multiple managers, one manager will be designated as the owner and the others will be listed in Writer roles – or Co-owner where supported – on the target. You may designate a different owner by editing the spreadsheet if necessary.|